Messages in this thread | | | From | Dmitry Vyukov <> | Date | Thu, 30 Jul 2020 07:58:16 +0200 | Subject | Re: 回复: INFO: rcu detected stall in tc modify qd isc |
| |
On Wed, Jul 29, 2020 at 9:13 PM Vinicius Costa Gomes <vinicius.gomes@intel.com> wrote: > > Hi, > > "Zhang, Qiang" <Qiang.Zhang@windriver.com> writes: > > > ________________________________________ > > 发件人: linux-kernel-owner@vger.kernel.org <linux-kernel-owner@vger.kernel.org> 代表 syzbot <syzbot+9f78d5c664a8c33f4cce@syzkaller.appspotmail.com> > > 发送时间: 2020年7月29日 13:53 > > 收件人: davem@davemloft.net; fweisbec@gmail.com; jhs@mojatatu.com; jiri@resnulli.us; linux-kernel@vger.kernel.org; mingo@kernel.org; netdev@vger.kernel.org; syzkaller-bugs@googlegroups.com; tglx@linutronix.de; vinicius.gomes@intel.com; xiyou.wangcong@gmail.com > > 主题: INFO: rcu detected stall in tc_modify_qdisc > > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 181964e6 fix a braino in cmsghdr_from_user_compat_to_kern() > > git tree: net > > console output: https://syzkaller.appspot.com/x/log.txt?x=12925e38900000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267 > > dashboard link: https://syzkaller.appspot.com/bug?extid=9f78d5c664a8c33f4cce > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > syz repro: > > https://syzkaller.appspot.com/x/repro.syz?x=16587f8c900000 > > It seems that syzkaller is generating an schedule with too small > intervals (3ns in this case) which causes a hrtimer busy-loop which > starves other kernel threads. > > We could put some limits on the interval when running in software mode, > but I don't like this too much, because we are talking about users with > CAP_NET_ADMIN and they have easier ways to do bad things to the system.
Hi Vinicius,
Could you explain why you don't like the argument if it's for CAP_NET_ADMIN? Good code should check arguments regardless I think and it's useful to protect root from, say, programming bugs rather than kill the machine on any bug and misconfiguration. What am I missing?
Also are we talking about CAP_NET_ADMIN in a user ns as well (effectively nobody)?
| |