提交 · ea9d73cfec09cccbc22044d1a6d87620e2884ba7 · openeuler / Kernel

31 5月, 2022 40 次提交

config: change CONFIG_DMATEST from y to m · ea9d73cf

由 Chao Liu 提交于 5月 31, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I59Q07
CVE: NA

--------------------------------

Simple DMA test client. Say N unless you're debugging a DMA Device driver.
It doesn't need to be compiled into the vmlinux, change it to m.
Signed-off-by: NChao Liu <liuchao173@huawei.com>
Reviewed-by: NKai Liu <kai.liu@suse.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ea9d73cf

perf: Fix sys_perf_event_open() race against self · c36d6048

由 Peter Zijlstra 提交于 5月 31, 2022

stable inclusion
from stable-v5.10.118
commit 3ee8e109c3c316073a3e0f83ec0769c7ee8a7375
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I593PQ
CVE: CVE-2022-1729

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3ee8e109c3c316073a3e0f83ec0769c7ee8a7375

--------------------------------

commit 3ac6487e upstream.

Norbert reported that it's possible to race sys_perf_event_open() such
that the looser ends up in another context from the group leader,
triggering many WARNs.

The move_group case checks for races against itself, but the
!move_group case doesn't, seemingly relying on the previous
group_leader->ctx == ctx check. However, that check is racy due to not
holding any locks at that time.

Therefore, re-check the result after acquiring locks and bailing
if they no longer match.

Additionally, clarify the not_move_group case from the
move_group-vs-move_group race.

Fixes: f63a8daa ("perf: Fix event->ctx locking")
Reported-by: NNorbert Slusarek <nslusarek@gmx.net>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c36d6048

blk-mq: fix kabi broken by "blk-mq: Use request queue-wide tags for tagset-wide sbitmap" · 26eda960

由 Yufen Yu 提交于 5月 31, 2022

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I597XM
CVE: NA

---------------------------
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

26eda960

blk-mq: fix use-after-free in blk_mq_exit_sched · 580c1a56

由 Ming Lei 提交于 5月 31, 2022

mainline inclusion
from mainline-v5.14-rc1
commit f0c1c4d2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I597XM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0c1c4d2864ed614f90d2da1bab1a1c42907b940

--------------------------------

tagset can't be used after blk_cleanup_queue() is returned because
freeing tagset usually follows blk_clenup_queue(). Commit d97e594c
("blk-mq: Use request queue-wide tags for tagset-wide sbitmap") adds
check on q->tag_set->flags in blk_mq_exit_sched(), and causes
use-after-free.

Fixes it by using hctx->flags.

Reported-by: syzbot+77ba3d171a25c56756ea@syzkaller.appspotmail.com
Fixes: d97e594c ("blk-mq: Use request queue-wide tags for tagset-wide sbitmap")
Cc: John Garry <john.garry@huawei.com>
Signed-off-by: NMing Lei <ming.lei@redhat.com>
Tested-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NJohn Garry <john.garry@huawei.com>
Link: https://lore.kernel.org/r/20210609063046.122843-1-ming.lei@redhat.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

580c1a56

blk-mq: Use request queue-wide tags for tagset-wide sbitmap · 3fd6dd28

由 John Garry 提交于 5月 31, 2022

mainline inclusion
from mainline-v5.14-rc1
commit d97e594c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I597XM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d97e594c51660bea510a387731637b894651e4b5

--------------------------------

The tags used for an IO scheduler are currently per hctx.

As such, when q->nr_hw_queues grows, so does the request queue total IO
scheduler tag depth.

This may cause problems for SCSI MQ HBAs whose total driver depth is
fixed.

Ming and Yanhui report higher CPU usage and lower throughput in scenarios
where the fixed total driver tag depth is appreciably lower than the total
scheduler tag depth:
https://lore.kernel.org/linux-block/440dfcfc-1a2c-bd98-1161-cec4d78c6dfc@huawei.com/T/#mc0d6d4f95275a2743d1c8c3e4dc9ff6c9aa3a76b

In that scenario, since the scheduler tag is got first, much contention
is introduced since a driver tag may not be available after we have got
the sched tag.

Improve this scenario by introducing request queue-wide tags for when
a tagset-wide sbitmap is used. The static sched requests are still
allocated per hctx, as requests are initialised per hctx, as in
blk_mq_init_request(..., hctx_idx, ...) ->
set->ops->init_request(.., hctx_idx, ...).

For simplicity of resizing the request queue sbitmap when updating the
request queue depth, just init at the max possible size, so we don't need
to deal with the possibly with swapping out a new sbitmap for old if
we need to grow.
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NMing Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/1620907258-30910-3-git-send-email-john.garry@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
conflict:
	block/blk-mq-sched.c
	block/blk-mq-sched.h
	block/blk-mq-tag.c
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

3fd6dd28

blk-mq: Some tag allocation code refactoring · f67108d7

由 John Garry 提交于 5月 31, 2022

mainline inclusion
from mainline-v5.14-rc1
commit 56b68085
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I597XM
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56b68085e536eff2676108f2f8356889a7dbbf55

--------------------------------

The tag allocation code to alloc the sbitmap pairs is common for regular
bitmaps tags and shared sbitmap, so refactor into a common function.

Also remove superfluous "flags" argument from blk_mq_init_shared_sbitmap().
Signed-off-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NMing Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/1620907258-30910-2-git-send-email-john.garry@huawei.comSigned-off-by: NJens Axboe <axboe@kernel.dk>
conflict:
	block/blk-mq.c
Signed-off-by: NYufen Yu <yuyufen@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f67108d7

arm64: Add memmap reserve range check to avoid conflict · d1f92782

由 Peng Liu 提交于 5月 31, 2022

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I59AN8
CVE: NA
backport: openEuler-22.03-LTS

--------------------------------

The user specificed memmap-reserve range may overlap in-use memory
region, and users are hard to avoid this due to KASLR. Thus, the
reduplicative memmap-reserve range should be ignored. Furthermore,
to be consistent with INITRD, the range that not in a memory region
will also be ignored.

Fixes: d05cfbd9 ("arm64: Add support for memmap kernel parameters")
Signed-off-by: NPeng Liu <liupeng256@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d1f92782

ext4: add reserved GDT blocks check · 8d3549b9

由 Zhang Yi 提交于 5月 31, 2022

hulk inclusion
category: bugfix
bugzilla: 186835, https://gitee.com/openeuler/kernel/issues/I59KJ1?from=project-issue
CVE: NA

---------------------------

We capture a NULL pointer issue when resizing a corrupt ext4 image which
freshly clear resize_inode feature (not run e2fsck). It could be simply
reproduced by following steps. The problem is because of the
resize_inode feature was cleared, and it will convert the filesystem to
meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was
not cleared together, so could we mistakenly call reserve_backup_gdb()
and passing an uninitialized resize_inode to it when adding new group
descriptors.

 mkfs.ext4 /dev/sda 3G
 tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck
 mount /dev/sda /mnt
 resize2fs /dev/sda 8G

 ========
 BUG: kernel NULL pointer dereference, address: 0000000000000028
 CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748
 ...
 RIP: 0010:ext4_flex_group_add+0xe08/0x2570
 ...
 Call Trace:
  <TASK>
  ext4_resize_fs+0xbec/0x1660
  __ext4_ioctl+0x1749/0x24e0
  ext4_ioctl+0x12/0x20
  __x64_sys_ioctl+0xa6/0x110
  do_syscall_64+0x3b/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f2dd739617b
 ========

The fix is simple, add a check in ext4_resize_fs() to make sure that the
es->s_reserved_gdt_blocks is zero when the resize_inode feature is
disabled.
Signed-off-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: Nzhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8d3549b9

ax25: Fix UAF bugs in ax25 timers · ec094c24