From: yangerkun <yangerkun@huawei.com>
To: <stable@vger.kernel.org>, <vbabka@suse.cz>,
<gregkh@linuxfoundation.org>, <linux-mm@kvack.org>,
<open-iscsi@googlegroups.com>, <cleech@redhat.com>
Cc: "zhangyi (F)" <yi.zhang@huawei.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
<liuyongqiang13@huawei.com>,
"Zhengyejian (Zetta)" <zhengyejian1@huawei.com>,
Yang Yingliang <yangyingliang@huawei.com>,
<chenzhou10@huawei.com>
Subject: Re: [QUESTION] WARNNING after 3d8e2128f26a ("sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output")
Date: Fri, 2 Apr 2021 15:24:48 +0800 [thread overview]
Message-ID: <3a321bdb-66d0-978f-cbb2-f40cbe4beb86@huawei.com> (raw)
In-Reply-To: <5837f5d9-2235-3ac2-f3f2-712e6cf4da5c@huawei.com>
Emm...
Actually, the problem exist for stable branch like 4.19 after fix for
CVE-2021-27365 which include the follow two patch:
2efc459d06f1 ("sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs
output")
ec98ea7070e9 ("scsi: iscsi: Ensure sysfs attributes are limited to
PAGE_SIZE")
在 2021/4/2 15:16, yangerkun 写道:
> sysfs_emit(3d8e2128f26a ("sysfs: Add sysfs_emit and sysfs_emit_at to
> format sysfs output")) has a hidden constraint that the buf should be
> alignment with PAGE_SIZE. It's OK since 59bb47985c1d ("mm, sl[aou]b:
> guarantee natural alignment for kmalloc(power-of-two)") help us to solve
> scenes like CONFIG_SLUB_DEBUG or CONFIG_SLOB which will break this.
>
>
> But since lots of stable branch(we reproduce it with 4.19 stable) merge
> 3d8e2128f26a ("sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs
> output") without 59bb47985c1d ("mm, sl[aou]b: guarantee natural
> alignment for kmalloc(power-of-two)"), we will get the follow warning
> with command 'cat /sys/class/iscsi_transport/tcp/handle' once we enable
> CONFIG_SLUB_DEBUG and start kernel with slub_debug=UFPZ!
>
>
> Obviously, we can backport 59bb47985c1d ("mm, sl[aou]b: guarantee
> natural alignment for kmalloc(power-of-two)") to fix it. But this will
> waste some memory to ensure natural alignment which seems unbearable for
> embedded device. So for stable branch like 4.19, can we just remove the
> warning in sysfs_emit since the only user for it is iscsi, and seq_read
> + sysfs_kf_seq_show can ensure that the buf in sysfs_emit must be aware
> of PAGE_SIZE. Or does there some other advise for this problem?
>
>
> # without 59bb47985c1d + 1G ram
> [root@localhost ~]# free
> total used free shared buff/cache
> available
> Mem: 947336 169960 389732 896 387644
> 624216
> Swap: 0 0 0
>
> # merge with 59bb47985c1d + 1G ram
> [root@localhost ~]# free
> total used free shared buff/cache
> available
> Mem: 947340 175176 374396 896 397768
> 618964
> Swap: 0 0 0
> [root@localhost ~]#
>
>
> [ 37.683332] ------------[ cut here ]------------
> [ 37.692747] invalid sysfs_emit: buf:00000000f75441ab
> [ 37.693914] WARNING: CPU: 1 PID: 576 at fs/sysfs/file.c:577
> sysfs_emit+0xb9/0xe0
> [ 37.694861] Modules linked in:
> [ 37.695264] CPU: 1 PID: 576 Comm: cat Not tainted
> 4.19.183-00023-gdf225d326e8c #7
> [ 37.696210] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31
> 04/01/2014
> [ 37.697866] RIP: 0010:sysfs_emit+0xb9/0xe0
> [ 37.698387] Code: 47 c9 c3 48 83 05 76 33 b3 04 01 48 89 fe 48 c7 c7
> 64 08 bb 8a 48 83 05 7c 33 b3 04 01 e8 13 7f be 00 48 83 05 77 33 b3 04
> 01 <0f> 0b 48 83 05 75 33 b3 04 01 48 83 05 73
> [ 37.700713] RSP: 0018:ffffc90000af7cf8 EFLAGS: 00010202
> [ 37.701370] RAX: 0000000000000000 RBX: ffff88803e0e4c00 RCX:
> 0000000000000006
> [ 37.702261] RDX: 0000000000000007 RSI: 0000000000000006 RDI:
> ffff888039455bf0
> [ 37.703171] RBP: ffffc90000af7d48 R08: 00000000000002f8 R09:
> 0000000000000005
> [ 37.704079] R10: 00000000000002f7 R11: ffffffff8bd9534d R12:
> ffff88801a013740
> [ 37.705001] R13: ffff88803db37a08 R14: ffff88803db37a30 R15:
> ffff88803db37a48
> [ 37.705918] FS: 00007fcb96411580(0000) GS:ffff888039440000(0000)
> knlGS:0000000000000000
> [ 37.706956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 37.707692] CR2: 00007fcb88cf0000 CR3: 000000001a501000 CR4:
> 00000000000006e0
> [ 37.708607] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 37.709520] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> 0000000000000400
> [ 37.710427] Call Trace:
> [ 37.710784] show_transport_handle+0x3e/0x60
> [ 37.711338] dev_attr_show+0x22/0x60
> [ 37.711808] sysfs_kf_seq_show+0xc6/0x190
> [ 37.712332] kernfs_seq_show+0x25/0x30
> [ 37.712862] seq_read+0xe1/0x540
> [ 37.713292] ? __handle_mm_fault+0xba3/0x1c70
> [ 37.713866] kernfs_fop_read+0x36/0x230
> [ 37.714371] __vfs_read+0x3c/0x230
> [ 37.714819] ? handle_mm_fault+0x1d1/0x340
> [ 37.715345] vfs_read+0xb5/0x1b0
> [ 37.715774] ksys_read+0x67/0x130
> [ 37.716218] __x64_sys_read+0x1e/0x30
> [ 37.716701] do_syscall_64+0x95/0x3d0
> [ 37.717175] ? do_async_page_fault+0x2e/0x190
> [ 37.717747] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 37.718406] RIP: 0033:0x7fcb963363f2
> [ 37.718881] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 8a 41 0a 00 e8 75 f0
> 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f
> 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 04
> [ 37.721290] RSP: 002b:00007ffea78dff18 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000000
> [ 37.722264] RAX: ffffffffffffffda RBX: 0000000000020000 RCX:
> 00007fcb963363f2
> [ 37.723169] RDX: 0000000000020000 RSI: 00007fcb88cf1000 RDI:
> 0000000000000003
> [ 37.724100] RBP: 00007fcb88cf1000 R08: 00007fcb88cf0010 R09:
> 0000000000000000
> [ 37.725039] R10: 0000000000000022 R11: 0000000000000246 R12:
> 0000000000020f00
> [ 37.725945] R13: 0000000000000003 R14: 0000000000020000 R15:
> 0000000000020000
> [ 37.726857] ---[ end trace fbd5b85cd7d85530 ]---
>
> .
next prev parent reply other threads:[~2021-04-02 7:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-02 7:16 yangerkun
2021-04-02 7:24 ` yangerkun [this message]
2021-04-02 7:45 ` Greg KH
2021-04-02 14:41 ` Matthew Wilcox
2021-04-07 12:14 ` yangerkun
2021-04-07 13:21 ` Joe Perches
2021-04-07 13:49 ` yangerkun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a321bdb-66d0-978f-cbb2-f40cbe4beb86@huawei.com \
--to=yangerkun@huawei.com \
--cc=chenzhou10@huawei.com \
--cc=cleech@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-mm@kvack.org \
--cc=liuyongqiang13@huawei.com \
--cc=open-iscsi@googlegroups.com \
--cc=stable@vger.kernel.org \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.com \
--cc=yangyingliang@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=zhengyejian1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox