- 03 6月, 2023 17 次提交
-
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188527, https://gitee.com/openeuler/kernel/issues/I6O3HO CVE: NA -------------------------------- need_replace will be set to 1 if no-Faulty mreplace exists, and mreplace will be deref later. However, the latter check of mreplace might set mreplace to NULL, null-ptr-deref occurs if need_replace is 1 at this time. Fix it by merging two checks into one. Fixes: ee37d731 ("md/raid10: Fix raid10 replace hang when new added disk faulty") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188787, https://gitee.com/openeuler/kernel/issues/I78YIW CVE: NA -------------------------------- When we remove a disk which has replacement, first set rdev to NULL and then set replacement to rdev, finally set replacement to NULL (see raid10_remove_disk()). If io is submitted during the same time, it might read both rdev and replacement as NULL, and io will not be submitted. rdev -> NULL read rdev replacement -> NULL read replacement Fix it by reading replacement first and rdev later, meanwhile, use smp_mb() to prevent memory reordering. Fixes: 475b0321 ("md/raid10: writes should get directed to replacement as well as original.") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188804, https://gitee.com/openeuler/kernel/issues/I78YIS CVE: NA -------------------------------- When add a new disk to raid10, it will traverse conf->mirror from start and find one of the following mirror: 1. mirror->rdev is set to WantReplacement and it have no replacement, set new disk to mirror->replacement. 2. no rdev, set new disk to mirror->rdev. There is a array as below (sda is set to WantReplacement): Number Major Minor RaidDevice State 0 8 0 0 active sync set-A /dev/sda - 0 0 1 removed 2 8 32 2 active sync set-A /dev/sdc 3 8 48 3 active sync set-B /dev/sdd Use 'mdadm --add' to add a new disk to this array, the new disk will become sda's replacement instead of add to removed position, which is confusing for users. Meanwhile, after new disk recovery success, sda will be set to Faulty. Prioritize adding disk to 'removed' mirror is a better choice. In the above scenario, the behavior is the same as before, except sda will not be deleted. Before other disks are added, continued use sda is more reliable. Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix, https://gitee.com/openeuler/kernel/issues/I71EKW bugzilla: 188628 CVE: NA -------------------------------- We first set rdev to WantRemove, and check if there is any io pending, if so, we will clear flag and return busy in raid10_remove_disk(). io will loss as below: raid10_remove_disk set WantRemove write rdev if WantRemove do not submit io if rdev->nr_pending clear WantRemove return BUSY read rdev get error data Fix it by md_error the rdev which io pending while removing. When the code reaches this point, it means this rdev will be removed later, so setting it as faulty has little impact. Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188533, https://gitee.com/openeuler/kernel/issues/I6O7YB CVE: NA -------------------------------- commit ceff49d9 ("md/raid1: fix a race between removing rdev and access conf->mirrors[i].rdev") fix a null-ptr-deref about raid1. There is same bug in raid10 and fix it in the same way. There is no sync_thread running while removing rdev, no need to check the flag in raid10_sync_request(). Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188380, https://gitee.com/openeuler/kernel/issues/I6GISC CVE: NA -------------------------------- commit fe630de0 ("md/raid10: avoid deadlock on recovery.") allowed normal io and sync io to exist at the same time. Task hung will occur as below: T1 T2 T3 T4 raid10d handle_read_error allow_barrier conf->nr_pending-- -> 0 //submit sync io raid10_sync_request raise_barrier ->will not be blocked ... //submit to drivers raid10_read_request wait_barrier conf->nr_pending++ -> 1 //retry read fail raid10_end_read_request reschedule_retry add to retry_list conf->nr_queued++ -> 1 //sync io fail end_sync_read __end_sync_read reschedule_retry add to retry_list conf->nr_queued++ -> 2 ... handle_read_error freeze_array wait nr_pending == nr_queued+1 ->1 ->3 //task hung retry read and sync io will be added to retry_list(nr_queued->2) if they fails. raid10d() called handle_read_error() and hung in freeze_array(). nr_queued will not decrease because raid10d is blocked, nr_pending will not increase because conf->barrier is not released. Fix it by moving allow_barrier() after raid10_read_request(). raise_barrier() will wait for nr_waiting to become 0. Therefore, sync io and regular io will not be issued at the same time. We also removed the check of nr_queued. It can be 0 but don't need to be blocked. MD_RECOVERY_RUNNING always is set after this patch, because all sync io is waitting in raise_barrier(), remove it, too. Fixes: fe630de0 ("md/raid10: avoid deadlock on recovery.") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Yu Kuai 提交于
mainline inclusion from mainline-v6.1-rc1 commit ed2e063f category: bugfix bugzilla: 188380, https://gitee.com/openeuler/kernel/issues/I6GISC CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=ed2e063f92c44c891ccd883e289dde6ca870edcc -------------------------------- Currently the nasty condition in wait_barrier() is hard to read. This patch factors out the condition into a function. There are no functional changes. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Acked-by: NPaul Menzel <pmenzel@molgen.mpg.de> Reviewed-by: NLogan Gunthorpe <logang@deltatee.com> Acked-by: NGuoqing Jiang <guoqing.jiang@linux.dev> Signed-off-by: NSong Liu <song@kernel.org> conflict: drivers/md/raid10.c Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188628, https://gitee.com/openeuler/kernel/issues/I6WKDR CVE: NA -------------------------------- There is no limit to the number of io for raid10 plug, whitch may result in excessive memory usage and potential softlockup when a large number of io are submitted at once. There is no good way to fix it now, just add schedule point to prevent softlockup. Fixes: 57c67df4 ("md/raid10: submit IO from originating thread instead of md thread.") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Jiang Li 提交于
mainline inclusion from mainline-v6.2-rc1 commit b611ad14 category: bugfix bugzilla: 188662, https://gitee.com/openeuler/kernel/issues/I6UMUF CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=b611ad14006e5be2170d9e8e611bf49dff288911 -------------------------------- fail run raid1 array when we assemble array with the inactive disk only, but the mdx_raid1 thread were not stop, Even if the associated resources have been released. it will caused a NULL dereference when we do poweroff. This causes the following Oops: [ 287.587787] BUG: kernel NULL pointer dereference, address: 0000000000000070 [ 287.594762] #PF: supervisor read access in kernel mode [ 287.599912] #PF: error_code(0x0000) - not-present page [ 287.605061] PGD 0 P4D 0 [ 287.607612] Oops: 0000 [#1] SMP NOPTI [ 287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G U 5.10.146 #0 [ 287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022 [ 287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod] [ 287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ...... [ 287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202 [ 287.656347] RAX: 0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000 [ 287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff888105986800 [ 287.670634] RBP: ffffc90000433da0 R08: 0000000000000000 R09: c0000000ffffefff [ 287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800 [ 287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: ffff888100b6b500 [ 287.692052] FS: 0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000 [ 287.700149] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4: 0000000000350ee0 [ 287.713033] Call Trace: [ 287.715498] raid1d+0x6c/0xbbb [raid1] [ 287.719256] ? __schedule+0x1ff/0x760 [ 287.722930] ? schedule+0x3b/0xb0 [ 287.726260] ? schedule_timeout+0x1ed/0x290 [ 287.730456] ? __switch_to+0x11f/0x400 [ 287.734219] md_thread+0xe9/0x140 [md_mod] [ 287.738328] ? md_thread+0xe9/0x140 [md_mod] [ 287.742601] ? wait_woken+0x80/0x80 [ 287.746097] ? md_register_thread+0xe0/0xe0 [md_mod] [ 287.751064] kthread+0x11a/0x140 [ 287.754300] ? kthread_park+0x90/0x90 [ 287.757974] ret_from_fork+0x1f/0x30 In fact, when raid1 array run fail, we need to do md_unregister_thread() before raid1_free(). Signed-off-by: NJiang Li <jiang.li@ugreen.com> Signed-off-by: NSong Liu <song@kernel.org> Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188553, https://gitee.com/openeuler/kernel/issues/I6TNFX CVE: NA -------------------------------- rdev->del_work has not been queued to md_rdev_misc_wq and flush_workqueue will not flush it if tow threads add and remove same device. sysfs might WARN duplicate filename as below. //T1 //T2 mdadm write super add success remove unbind_rdev_from_array md_ioctl flush_workqueue INIT_WORK queue_work md_add_new_disk duplicate filename dev-xxx Check if there is any kobj with the same name, and return busy if true. Fixes: 5792a285 ("md: avoid a deadlock when removing a device from an md array via sysfs") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188553, https://gitee.com/openeuler/kernel/issues/I6TNFX CVE: NA -------------------------------- If we want to remove a device, first we delete it from mddev->disks list, then init rdev->del_work to put it (see unbind_rdev_from_array()). flush_rdev_wq() traverses mddev->disks to check if there is any pending rdev->del_work, if so, flush it. Howerver, rdev will not be in the list of mddev->disks if rdev->del_work exists, and flush_workqueue() will never be executed. Replace it with flush_workqueue() to ensure del_work has been completed when adding devices. Fixes: cc1ffe61 ("md: add new workqueue for delete rdev") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 David Sloan 提交于
mainline inclusion from mainline-v6.0-rc3 commit 5e8daf90 category: bugfix bugzilla: 188015, https://gitee.com/openeuler/kernel/issues/I6OERX CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=5e8daf906f890560df430d30617c692a794acb73 -------------------------------- A race condition still exists when removing and re-creating md devices in test cases. However, it is only seen on some setups. The race condition was tracked down to a reference still being held to the kobject by the rdev in the md_rdev_misc_wq which will be released in rdev_delayed_delete(). md_alloc() waits for previous deletions by waiting on the md_misc_wq, but the md_rdev_misc_wq may still be holding a reference to a recently removed device. To fix this, also flush the md_rdev_misc_wq in md_alloc(). Signed-off-by: NDavid Sloan <david.sloan@eideticom.com> [logang@deltatee.com: rewrote commit message] Signed-off-by: NLogan Gunthorpe <logang@deltatee.com> Signed-off-by: NSong Liu <song@kernel.org> Conflict: drivers/md/md.c Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Jinke Han 提交于
mainline inclusion from mainline-v6.0-rc1 commit 14a6e2eb category: bugfix bugzilla: 188088, https://gitee.com/openeuler/kernel/issues/I66GIL CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=14a6e2eb7df5c7897c15b109cba29ab0c4a791b6 ---------------------------------------------------------------------- In our test of iocost, we encountered some list add/del corruptions of inner_walk list in ioc_timer_fn. The reason can be described as follows: cpu 0 cpu 1 ioc_qos_write ioc_qos_write ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } When the io.cost.qos file is written by two cpus concurrently, rq_qos may be added to one disk twice. In that case, there will be two iocs enabled and running on one disk. They own different iocgs on their active list. In the ioc_timer_fn function, because of the iocgs from two iocs have the same root iocg, the root iocg's walk_list may be overwritten by each other and this leads to list add/del corruptions in building or destroying the inner_walk list. And so far, the blk-rq-qos framework works in case that one instance for one type rq_qos per queue by default. This patch make this explicit and also fix the crash above. Signed-off-by: NJinke Han <hanjinke.666@bytedance.com> Reviewed-by: NMuchun Song <songmuchun@bytedance.com> Acked-by: NTejun Heo <tj@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220720093616.70584-1-hanjinke.666@bytedance.comSigned-off-by: NJens Axboe <axboe@kernel.dk> Conflicts: block/blk-rq-qos.h block/blk-wbt.c Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Li Nan 提交于
hulk inclusion category: bugfix bugzilla: 188152, https://gitee.com/openeuler/kernel/issues/I67BPT CVE: NA ------------------------------- adjust_inuse_and_calc_cost() use spin_lock_irq and IRQ will enable when unlock. DEADLOCK might happen if we have held other locks before: ================================ WARNING: inconsistent lock state 5.10.0-02758-g8e5f91fd772f #26 Not tainted -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 {IN-HARDIRQ-W} state was registered at: __lock_acquire+0x3d7/0x1070 lock_acquire+0x197/0x4a0 __raw_spin_lock_irqsave _raw_spin_lock_irqsave+0x3b/0x60 bfq_idle_slice_timer_body bfq_idle_slice_timer+0x53/0x1d0 __run_hrtimer+0x477/0xa70 __hrtimer_run_queues+0x1c6/0x2d0 hrtimer_interrupt+0x302/0x9e0 local_apic_timer_interrupt __sysvec_apic_timer_interrupt+0xfd/0x420 run_sysvec_on_irqstack_cond sysvec_apic_timer_interrupt+0x46/0xa0 asm_sysvec_apic_timer_interrupt+0x12/0x20 irq event stamp: 837522 hardirqs last enabled at (837521): [<ffffffff84b9419d>] __raw_spin_unlock_irqrestore hardirqs last enabled at (837521): [<ffffffff84b9419d>] _raw_spin_unlock_irqrestore+0x3d/0x40 hardirqs last disabled at (837522): [<ffffffff84b93fa3>] __raw_spin_lock_irq hardirqs last disabled at (837522): [<ffffffff84b93fa3>] _raw_spin_lock_irq+0x43/0x50 softirqs last enabled at (835852): [<ffffffff84e00558>] __do_softirq+0x558/0x8ec softirqs last disabled at (835845): [<ffffffff84c010ff>] asm_call_irq_on_stack+0xf/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&bfqd->lock); <Interrupt> lock(&bfqd->lock); *** DEADLOCK *** 3 locks held by kworker/2:3/388: #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0 #1: ffff8881176bfdd8 ((work_completion)(&td->dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0 #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 stack backtrace: CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kthrotld blk_throtl_dispatch_work_fn Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x167 print_usage_bug valid_state mark_lock_irq.cold+0x32/0x3a mark_lock+0x693/0xbc0 mark_held_locks+0x9e/0xe0 __trace_hardirqs_on_caller lockdep_hardirqs_on_prepare.part.0+0x151/0x360 trace_hardirqs_on+0x5b/0x180 __raw_spin_unlock_irq _raw_spin_unlock_irq+0x24/0x40 spin_unlock_irq adjust_inuse_and_calc_cost+0x4fb/0x970 ioc_rqos_merge+0x277/0x740 __rq_qos_merge+0x62/0xb0 rq_qos_merge bio_attempt_back_merge+0x12c/0x4a0 blk_mq_sched_try_merge+0x1b6/0x4d0 bfq_bio_merge+0x24a/0x390 __blk_mq_sched_bio_merge+0xa6/0x460 blk_mq_sched_bio_merge blk_mq_submit_bio+0x2e7/0x1ee0 __submit_bio_noacct_mq+0x175/0x3b0 submit_bio_noacct+0x1fb/0x270 blk_throtl_dispatch_work_fn+0x1ef/0x2b0 process_one_work+0x83e/0x13f0 process_scheduled_works worker_thread+0x7e3/0xd80 kthread+0x353/0x470 ret_from_fork+0x1f/0x30 Fixes: b0853ab4 ("blk-iocost: revamp in-period donation snapbacks") Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 Yu Kuai 提交于
hulk inclusion category: bugfix bugzilla: 188033, https://gitee.com/openeuler/kernel/issues/I663ZP CVE: NA -------------------------------- iocost is based on rq_qos, which can only work for request based device, thus it doesn't make sense to configure iocost for bio based device. Signed-off-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/895 PR sync from: Liu Jian liujian56@huawei.com https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/H22NWZPMQBGSVUV22ISL3FTVOXQH676J/ Link:https://gitee.com/openeuler/kernel/pulls/899 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Liu Jian 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I79J3X CVE: N/A ---------------------------------------------------- It is already enabled by default on the x86 and loongarch platforms, so let's enable it on the arm64 platform. Signed-off-by: NLiu Jian <liujian56@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawe.com> (cherry picked from commit ace86952)
-
- 02 6月, 2023 6 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/881 Currently, the bitfield of HWCAP2_WFXT is (1 << 23) inconsistent with mainline set (1UL << 31). To avoid possible uapi break, keep the bitfield consistent with mainline. Link:https://gitee.com/openeuler/kernel/pulls/888 Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Yanan Wang 提交于
mainline inclusion from mainline-v5.19-rc1 commit b2c4caf3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I78WD0 ------------------------------------------------- Currently, the bitfield of HWCAP2_WFXT is (1 << 23) inconsistent with mainline set (1UL << 31). To avoid possible uapi break, keep the bitfield consistent with mainline. Signed-off-by: NYanan Wang <wangyanan55@huawei.com> (cherry picked from commit c0da3054)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/860 Backport upstream commit 7adc6885 powercap: intel_rapl: add support for Emerald Rapids to OLK-5.10 to enable intel_rapl driver on EMR. Intel-kernel issue: https://gitee.com/openeuler/intel-kernel/issues/I77XHY Test: /sys/devices/virtual/powercap/intel-rapl/ will be available on EMR platform after this commit is merged. Known issue: N/A Default config change: N/A Link:https://gitee.com/openeuler/kernel/pulls/885 Reviewed-by: Jason Zeng <jason.zeng@intel.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhang Rui 提交于
mainline inclusion from mainline-v6.3-rc1 commit 7adc6885 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I77XHY CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7adc6885259edd4ef5c9a7a62fd4270cf38fdbfb Intel-SIG: commit 7adc6885 powercap: intel_rapl: add support for Emerald Rapids Backported to OLK-5.10 to enable intel_rapl driver on EMR. ------------------------------------- Add Emerald Rapids to the list of supported processor models in the Intel RAPL power capping driver. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NXiaolong Wang <xiaolong.wang@intel.com> (cherry picked from commit a4a34465)
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @stinft 1.#I7A2PB 2.#I7A2PK 3.#I7A2SA 4.#I7A2V2 5.#I7A2VV Link:https://gitee.com/openeuler/kernel/pulls/878 Reviewed-by: Chengchang Tang <tangchengchang@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/877 There are worse performance with the 'Fixes' when running "./lat_ctx -P $SYNC_MAX -s 64 16". The 'Fixes' which allocates memory for p->prefer_cpus even if "prefer_cpus" not be set. Before the 'Fixes', only test "p->prefer_cpus", after, add test "!cpumask_empty(p->prefer_cpus)" which causing performance degradation. select_task_rq_fair ->set_task_select_cpus ->prefer_cpus_valid ---- test cpumask_empty(p->prefer_cpus) Link:https://gitee.com/openeuler/kernel/pulls/879 Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
- 01 6月, 2023 17 次提交
-
-
由 Hui Tang 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A718 -------------------------------- There are worse performance with the 'Fixes' when running "./lat_ctx -P $SYNC_MAX -s 64 16". The 'Fixes' which allocates memory for p->prefer_cpus even if "prefer_cpus" not be set. Before the 'Fixes', only test "p->prefer_cpus", after, add test "!cpumask_empty(p->prefer_cpus)" which causing performance degradation. select_task_rq_fair ->set_task_select_cpus ->prefer_cpus_valid ---- test cpumask_empty(p->prefer_cpus) Fixes: ebeb84ad ("cpuset: Introduce new interface for scheduler ...") Signed-off-by: NHui Tang <tanghui20@huawei.com> (cherry picked from commit d8f77f89)
-
由 Chengchang Tang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2VV --------------------------------------------------------------- When running rdma with the kasan version, the following error will be reported: [ 9013.831512] BUG: sleeping function called from invalid context at kernel/workqueue.c:3111 [ 9013.839719] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 7938, name: ib_send_bw [ 9013.847917] preempt_count: 1, expected: 0 [ 9013.851932] RCU nest depth: 0, expected: 0 [ 9013.856034] INFO: lockdep is turned off. [ 9013.859963] CPU: 28 PID: 7938 Comm: ib_send_bw Kdump: loaded Tainted: G W O 6.3.0-rc4+ #1 [ 9013.869360] Hardware name: To be filled by O.E.M. HixxxxEVB 1P 2T2N V2.1.5/To be filled by O.E.M., BIOS HixxxxEVB 1P 2T2N V2.1.5 05/04/ 23 [ 9013.881883] Call trace: [ 9013.884322] dump_backtrace+0xac/0xf0 [ 9013.887984] show_stack+0x20/0x38 [ 9013.891294] dump_stack_lvl+0xbc/0x120 [ 9013.895040] dump_stack+0x1c/0x28 [ 9013.898350] __might_resched+0x1c8/0x348 [ 9013.902271] __might_sleep+0x78/0xf8 [ 9013.905841] __flush_work+0x118/0x718 [ 9013.909501] __cancel_work_timer+0x228/0x2d8 [ 9013.913769] cancel_delayed_work_sync+0x1c/0x30 [ 9013.918296] cleanup_dca_context+0x48/0x1e8 [hns_roce_hw_v2] [ 9013.923998] hns_roce_unregister_udca+0x3c/0x98 [hns_roce_hw_v2] [ 9013.930043] hns_roce_dealloc_ucontext+0x15c/0x180 [hns_roce_hw_v2] [ 9013.936348] uverbs_destroy_ufile_hw+0xd0/0x160 [ 9013.940877] ib_uverbs_close+0x3c/0x170 [ 9013.944709] __fput+0xfc/0x3c8 [ 9013.947761] ____fput+0x18/0x30 [ 9013.950898] task_work_run+0x130/0x1b8 [ 9013.954643] do_exit+0x4f0/0xfa8 [ 9013.957867] do_group_exit+0x60/0xf8 [ 9013.961437] get_signal+0xf2c/0x1018 [ 9013.965009] do_notify_resume+0x2d0/0x1560 [ 9013.969102] el0_svc+0x98/0xa0 [ 9013.972152] el0t_64_sync_handler+0xb8/0xc0 [ 9013.976332] el0t_64_sync+0x1a4/0x1a8 This issue is introduced by DCA aging feature. To stop aging work during dca unload, cacel_delayed_work_sync() is called which cannot be used in an atomic context. At the same time, in order to avoid concurrency in this process, a spin lock is used for protection. But in fact, the aging of DCA is triggered during IO, and the unloading process of DCA is included in the process of ucontext detroy or driver uninstallation. At this time, all the QPs has been released. So, there is no concurrency in this process, and the spinlock here is redundant. This patch removes the unnecessary spinlock. Fixes: d3caaebd ("RDMA/hns: Optimize user DCA perfermance by sharing DCA status") Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
-
由 Junxian Huang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2V2 --------------------------------------------------------------- When vf check fails, the current code dealloc ib_dev without kfree hr_dev->priv. This patch fixes this error. Fixes: a39f16a1 ("RDMA/hns: fix the error of RoCE VF based on RoCE Bonding PF") Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
-
由 Junxian Huang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2SA --------------------------------------------------------------- Currently, direct wqe is not supported for wr-list. RoCE driver excludes direct wqe for wr-list by judging whether the number of wr is 1. For a wr-list where the second wr is a length-error atomic wr, the post-send driver handles the first wr and adds 1 to the wr number counter firstly. While handling the second wr, the driver finds out a length error and terminates the wr handle process, remaining the counter at 1. This causes the driver mistakenly judges there is only 1 wr and thus enters the direct wqe process, carrying the current length-error atomic wqe. This patch fixes the error by adding a judgement whether the current wr is a bad wr. If so, use the normal doorbell process but not direct wqe despite the wr number is 1. Fixes: a77e1f87 ("RDMA/hns: Remove the condition of light load for posting DWQE") Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
-
由 Junxian Huang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2V2 --------------------------------------------------------------- This patch fixes inaccurate error label name in init instance. Fixes: 6f5f556d ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT") Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
-
由 Junxian Huang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2PB --------------------------------------------------------------- Remove VF extend configuration since the relative registers are configured in firmware currently. Fixes: 7e3913a7 ("RDMA/hns: Support getting max QP number from firmware") Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
-
由 Chengchang Tang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2PK --------------------------------------------------------------- Since the maximum length of the sgl entry is 4G, if MR is greater than 4G, there is a probability that the sg entry length will overflow which would lead to a iommu map failure. Since the largest RoCE packet is 2G, there will be no DMA operation exceeding 2G at one time. We adjust the DMA max seg size from 4G to 2G to ensure that the length of the sgl entry will not overflow and flip. Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
-
由 Junxian Huang 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2SA --------------------------------------------------------------- The only supported length of atomic wr in kernel space is 8. The driver needs to check the length before post send. Fixes: 00a59d30 ("RDMA/hns: Optimize wqe buffer filling process for post send") Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/866 PR sync from: Li Huafei <lihuafei1@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/QXUYQDQ4DEHNVIFCOSKUQF5GRGQKLRPI/ Link:https://gitee.com/openeuler/kernel/pulls/871 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @openeuler-sync-bot Origin pull request: https://gitee.com/openeuler/kernel/pulls/863 PR sync from: Jialin Zhang <zhangjialin11@huawei.com> https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/UAMVHA4ICOFJJXDMX2CXEV6TEZSY7Y7U/ Pull new CVEs: CVE-2023-22998 cgroup bugfix from Gaosheng Cui sched bugfix from Xia Fukun block bugfixes from Zhong Jinghua and Yu Kuai iomap and ext4 bugfixes from Baokun Li md and eulerfs bugfixes from Yu Kuai -- 2.25.1 Link:https://gitee.com/openeuler/kernel/pulls/872 Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
-
由 Harshit Mogalapalli 提交于
stable inclusion from stable-v5.10.173 commit c5fe3fba1b7bfecb6f17f93a433782b8500fe377 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6IKWF CVE: CVE-2023-22998 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c5fe3fba1b7bfecb6f17f93a433782b8500fe377 -------------------------------- In virtio_gpu_object_shmem_init() we are passing NULL to PTR_ERR, which is returning 0/success. Fix this by storing error value in 'ret' variable before assigning shmem->pages to NULL. Found using static analysis with Smatch. Fixes: 64b88afb ("drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling") Signed-off-by: NHarshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: NDmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit 1c498218)
-
由 Dmitry Osipenko 提交于
stable inclusion from stable-v5.10.171 commit 87c647def389354c95263d6635c62ca0de7d12ca category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6IKWF CVE: CVE-2023-22998 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=87c647def389354c95263d6635c62ca0de7d12ca -------------------------------- commit 64b88afb upstream. Previous commit fixed checking of the ERR_PTR value returned by drm_gem_shmem_get_sg_table(), but it missed to zero out the shmem->pages, which will crash virtio_gpu_cleanup_object(). Add the missing zeroing of the shmem->pages. Fixes: c2496873 ("drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init") Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com> Signed-off-by: NDmitry Osipenko <dmitry.osipenko@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-2-dmitry.osipenko@collabora.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NOvidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit 98019109)
-
由 Miaoqian Lin 提交于
stable inclusion from stable-v5.10.171 commit 0a4181b23acf53e9c95b351df6a7891116b98f9b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6IKWF CVE: CVE-2023-22998 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0a4181b23acf53e9c95b351df6a7891116b98f9b -------------------------------- commit c2496873 upstream. Since drm_prime_pages_to_sg() function return error pointers. The drm_gem_shmem_get_sg_table() function returns error pointers too. Using IS_ERR() to check the return value to fix this. Fixes: 2f2aa137 ("drm/virtio: move virtio_gpu_mem_entry initialization to new function") Signed-off-by: NMiaoqian Lin <linmq006@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20220602104223.54527-1-linmq006@gmail.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NOvidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit bb502cea)
-
由 Xiu Jianfeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I798WQ CVE: NA ---------------------------------------------------------------------- We found a refcount UAF bug as follows: refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 342 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x148 Workqueue: events cpuset_hotplug_workfn Call trace: refcount_warn_saturate+0xa0/0x148 __refcount_add.constprop.0+0x5c/0x80 css_task_iter_advance_css_set+0xd8/0x210 css_task_iter_advance+0xa8/0x120 css_task_iter_next+0x94/0x158 update_tasks_root_domain+0x58/0x98 rebuild_root_domains+0xa0/0x1b0 rebuild_sched_domains_locked+0x144/0x188 cpuset_hotplug_workfn+0x138/0x5a0 process_one_work+0x1e8/0x448 worker_thread+0x228/0x3e0 kthread+0xe0/0xf0 ret_from_fork+0x10/0x20 then a kernel panic will be triggered as below: Unable to handle kernel paging request at virtual address 00000000c0000010 Call trace: cgroup_apply_control_disable+0xa4/0x16c rebind_subsystems+0x224/0x590 cgroup_destroy_root+0x64/0x2e0 css_free_rwork_fn+0x198/0x2a0 process_one_work+0x1d4/0x4bc worker_thread+0x158/0x410 kthread+0x108/0x13c ret_from_fork+0x10/0x18 The race that cause this bug can be shown as below: (hotplug cpu) | (umount cpuset) mutex_lock(&cpuset_mutex) | mutex_lock(&cgroup_mutex) cpuset_hotplug_workfn | rebuild_root_domains | rebind_subsystems update_tasks_root_domain | spin_lock_irq(&css_set_lock) css_task_iter_start | list_move_tail(&cset->e_cset_node[ss->id] while(css_task_iter_next) | &dcgrp->e_csets[ss->id]); css_task_iter_end | spin_unlock_irq(&css_set_lock) mutex_unlock(&cpuset_mutex) | mutex_unlock(&cgroup_mutex) Inside css_task_iter_start/next/end, css_set_lock is hold and then released, so when iterating task(left side), the css_set may be moved to another list(right side), then it->cset_head points to the old list head and it->cset_pos->next points to the head node of new list, which can't be used as struct css_set. To fix this issue, introduce CSS_TASK_ITER_STOPPED flag for css_task_iter. when moving css_set to dcgrp->e_csets[ss->id] in rebind_subsystems(), stop the task iteration. Reported-by: NGaosheng Cui <cuigaosheng1@huawei.com> Link: https://www.spinics.net/lists/cgroups/msg37935.html Fixes: f9a25f77 ("cpusets: Rebuild root domain deadline accounting information") Signed-off-by: NXiu Jianfeng <xiujianfeng@huaweicloud.com> Signed-off-by: NGaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit e52586f4)
-
由 Xia Fukun 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6YJJQ CVE: NA ---------------------------------------- The function sd_llc_free_all() will be called to release allocated resources when space allocation for the scheduling domain structure fails. However, this function did not check if sd is a null pointer when releasing sdd resources, resulting in an error: "Unable to handle kernel paging request at virtual address". Fix this issue by adding null pointer discrimination. Fixes: 79bec4c6 ("sched/topology: Provide hooks to allocate data shared per LLC") Signed-off-by: NXia Fukun <xiafukun@huawei.com> Reviewed-by: Nsongping yu <yusongping@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit d73bbd3f)
-
由 Zhong Jinghua 提交于
hulk inclusion category: bugfix bugzilla: 187268, https://gitee.com/openeuler/kernel/issues/I76JDY CVE: NA ---------------------------------------- In the block_ioctl, we can pass in the unsigned number 0x8000000000000000 as an input parameter, like below: block_ioctl blkdev_ioctl blkpg_ioctl blkpg_do_ioctl copy_from_user bdev_add_partition add_partition p->start_sect = start; // start = 0x8000000000000000 Then, there was an warning when submit bio: WARNING: CPU: 0 PID: 382 at fs/iomap/apply.c:54 Call trace: iomap_apply+0x644/0x6e0 __iomap_dio_rw+0x5cc/0xa24 iomap_dio_rw+0x4c/0xcc ext4_dio_read_iter ext4_file_read_iter ext4_file_read_iter+0x318/0x39c call_read_iter lo_rw_aio.isra.0+0x748/0x75c do_req_filebacked+0x2d4/0x370 loop_handle_cmd loop_queue_work+0x94/0x23c kthread_worker_fn+0x160/0x6bc loop_kthread_worker_fn+0x3c/0x50 kthread+0x20c/0x25c ret_from_fork+0x10/0x18 Stack: submit_bio_noacct submit_bio_checks blk_partition_remap bio->bi_iter.bi_sector += p->start_sect // bio->bi_iter.bi_sector = 0xffc0000000000000 + 65408 .. loop_queue_work loop_handle_cmd do_req_filebacked pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset // pos < 0 lo_rw_aio call_read_iter ext4_dio_read_iter __iomap_dio_rw iomap_apply ext4_iomap_begin map.m_lblk = offset >> blkbits ext4_set_iomap iomap->offset = (u64) map->m_lblk << blkbits // iomap->offset = 64512 WARN_ON(iomap.offset > pos) // iomap.offset = 64512 and pos < 0 This is unreasonable for start + length > disk->part0.nr_sects. There is already a similar check in blk_add_partition(). Fix it by adding a check in bdev_add_partition(). Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com> Reviewed-by: NYu Kuai <yukuai3@huawei.com> Reviewed-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit 1ae011cf)
-
由 Tudor Ambarus 提交于
stable inclusion from stable-v5.10.180 commit 0dde3141c527b09b96bef1e7eeb18b8127810ce9 category: bugfix bugzilla: 188791,https://gitee.com/openeuler/kernel/issues/I76XUJ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0dde3141c527b09b96bef1e7eeb18b8127810ce9 -------------------------------- commit 4f043518 upstream. When modifying the block device while it is mounted by the filesystem, syzbot reported the following: BUG: KASAN: slab-out-of-bounds in crc16+0x206/0x280 lib/crc16.c:58 Read of size 1 at addr ffff888075f5c0a8 by task syz-executor.2/15586 CPU: 1 PID: 15586 Comm: syz-executor.2 Not tainted 6.2.0-rc5-syzkaller-00205-gc9661827 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 crc16+0x206/0x280 lib/crc16.c:58 ext4_group_desc_csum+0x81b/0xb20 fs/ext4/super.c:3187 ext4_group_desc_csum_set+0x195/0x230 fs/ext4/super.c:3210 ext4_mb_clear_bb fs/ext4/mballoc.c:6027 [inline] ext4_free_blocks+0x191a/0x2810 fs/ext4/mballoc.c:6173 ext4_remove_blocks fs/ext4/extents.c:2527 [inline] ext4_ext_rm_leaf fs/ext4/extents.c:2710 [inline] ext4_ext_remove_space+0x24ef/0x46a0 fs/ext4/extents.c:2958 ext4_ext_truncate+0x177/0x220 fs/ext4/extents.c:4416 ext4_truncate+0xa6a/0xea0 fs/ext4/inode.c:4342 ext4_setattr+0x10c8/0x1930 fs/ext4/inode.c:5622 notify_change+0xe50/0x1100 fs/attr.c:482 do_truncate+0x200/0x2f0 fs/open.c:65 handle_truncate fs/namei.c:3216 [inline] do_open fs/namei.c:3561 [inline] path_openat+0x272b/0x2dd0 fs/namei.c:3714 do_filp_open+0x264/0x4f0 fs/namei.c:3741 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f72f8a8c0c9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f72f97e3168 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 00007f72f8bac050 RCX: 00007f72f8a8c0c9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020000280 RBP: 00007f72f8ae7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd165348bf R14: 00007f72f97e3300 R15: 0000000000022000 Replace le16_to_cpu(sbi->s_es->s_desc_size) with sbi->s_desc_size It reduces ext4's compiled text size, and makes the code more efficient (we remove an extra indirect reference and a potential byte swap on big endian systems), and there is no downside. It also avoids the potential KASAN / syzkaller failure, as a bonus. Reported-by: syzbot+fc51227e7100c9294894@syzkaller.appspotmail.com Reported-by: syzbot+8785e41224a3afd04321@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=70d28d11ab14bd7938f3e088365252aa923cff42 Link: https://syzkaller.appspot.com/bug?id=b85721b38583ecc6b5e72ff524c67302abbc30f3 Link: https://lore.kernel.org/all/000000000000ece18705f3b20934@google.com/ Fixes: 717d50e4 ("Ext4: Uninitialized Block Groups") Cc: stable@vger.kernel.org Signed-off-by: NTudor Ambarus <tudor.ambarus@linaro.org> Link: https://lore.kernel.org/r/20230504121525.3275886-1-tudor.ambarus@linaro.orgSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NYang Erkun <yangerkun@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com> (cherry picked from commit 0d4053b9)
-