netdev - Re: 回复: INFO: rcu detected stall in tc_modify

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Jul 2020 11:36:18 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Dmitry Vyukov <dvyukov@...gle.com>
Cc:     "Zhang, Qiang" <Qiang.Zhang@...driver.com>,
        syzbot <syzbot+9f78d5c664a8c33f4cce@...kaller.appspotmail.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "fweisbec@...il.com" <fweisbec@...il.com>,
        "jhs@...atatu.com" <jhs@...atatu.com>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>
Subject: Re: 回复: INFO: rcu detected stall in tc_modify_qdisc



On 7/30/20 10:44 AM, Vinicius Costa Gomes wrote:
> Hi,
> 
> Dmitry Vyukov <dvyukov@...gle.com> writes:
> 
>> On Wed, Jul 29, 2020 at 9:13 PM Vinicius Costa Gomes
>> <vinicius.gomes@...el.com> wrote:
>>>
>>> Hi,
>>>
>>> "Zhang, Qiang" <Qiang.Zhang@...driver.com> writes:
>>>
>>>> ________________________________________
>>>> 发件人: linux-kernel-owner@...r.kernel.org <linux-kernel-owner@...r.kernel.org> 代表 syzbot <syzbot+9f78d5c664a8c33f4cce@...kaller.appspotmail.com>
>>>> 发送时间: 2020年7月29日 13:53
>>>> 收件人: davem@...emloft.net; fweisbec@...il.com; jhs@...atatu.com; jiri@...nulli.us; linux-kernel@...r.kernel.org; mingo@...nel.org; netdev@...r.kernel.org; syzkaller-bugs@...glegroups.com; tglx@...utronix.de; vinicius.gomes@...el.com; xiyou.wangcong@...il.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?
> 
> I admit that I am on the fence on that argument: do not let even root
> crash the system (the point that my code is crashing the system gives
> weight to this side) vs. root has great powers, they need to know what
> they are doing.
> 
> The argument that I used to convince myself was: root can easily create
> a bunch of processes and give them the highest priority and do
> effectively the same thing as this issue, so I went with a the "they
> need to know what they are doing side".
> 
> A bit more on the specifics here:
> 
>   - Using a small interval size, is only a limitation of the taprio
>   software mode, when using hardware offloads (which I think most users
>   do), any interval size (supported by the hardware) can be used;
> 
>   - Choosing a good lower limit for this seems kind of hard: something
>   below 1us would never work well, I think, but things 1us < x < 100us
>   will depend on the hardware/kernel config/system load, and this is the
>   range includes "useful" values for many systems.
> 
> Perhaps a middle ground would be to impose a limit based on the link
> speed, the interval can never be smaller than the time it takes to send
> the minimum ethernet frame (for 1G links this would be ~480ns, should be
> enough to catch most programming mistakes). I am going to add this and
> see how it looks like.
> 
> Sorry for the brain dump :-)


I do not know taprio details, but do you really need a periodic timer ?

Presumably there is no need to fire a timer before next packet departure time ?