在 2021/6/8 下午8:01, Dmitry Vyukov 写道:
On Tue, Jun 8, 2021 at 11:47 AM Hao Xu <haoxu@xxxxxxxxxxxxxxxxx> wrote:
在 2021/6/5 上午4:22, syzbot 写道:
syzbot has bisected this issue to:
commit 24369c2e3bb06d8c4e71fd6ceaf4f8a01ae79b7c
Author: Pavel Begunkov <asml.silence@xxxxxxxxx>
Date: Tue Jan 28 00:15:48 2020 +0000
io_uring: add io-wq workqueue sharing
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17934777d00000
start commit: f88cd3fb Merge tag 'vfio-v5.13-rc5' of git://github.com/aw..
git tree: upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=14534777d00000
console output: https://syzkaller.appspot.com/x/log.txt?x=10534777d00000
kernel config: https://syzkaller.appspot.com/x/.config?x=82d85e75046e5e64
dashboard link: https://syzkaller.appspot.com/bug?extid=ea2f1484cffe5109dc10
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16d5772fd00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10525947d00000
Reported-by: syzbot+ea2f1484cffe5109dc10@xxxxxxxxxxxxxxxxxxxxxxxxx
Fixes: 24369c2e3bb0 ("io_uring: add io-wq workqueue sharing")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
This is not a bug, the repro program first set RLIMIT_NPROC to 0, then
submits an unbound work whcih raises a warning of
WARN_ON_ONCE(!acct->max_workers). Since unbound->max_workers is
task_rlimit(current, RLIMIT_NPROC), so it is expected.
Hi Hao,
Then this is a mis-use of WARN_ON. If this check is intended for end
users, it needs to use pr_err (also print understandable message and
no stack trace which is most likely not useful for end users):
https://elixir.bootlin.com/linux/v5.13-rc5/source/include/asm-generic/bug.h#L71
Agree, pr_err/pr_warn is better here.
