netdev - Re: [syzbot] INFO: task hung in __lru_add_drain

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>] [day] [month] [year] [list]

Message-ID: <87h7eya87g.ffs@tglx>
Date:   Mon, 06 Sep 2021 01:55:31 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Hillf Danton <hdanton@...a.com>,
        syzbot <syzbot+a9b681dcbc06eb2bca04@...kaller.appspotmail.com>
Cc:     eric.dumazet@...il.com, hdanton@...a.com,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] INFO: task hung in __lru_add_drain_all

On Sat, Sep 04 2021 at 16:07, Hillf Danton wrote:
>
> See if ieee80211_iface_work is burning more CPU cycles than thought, given the
> bound workqueue work blocked for more than 143 seconds.
>
> #syz test git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -1494,6 +1494,7 @@ static void ieee80211_iface_work(struct
>  
>  		kfree_skb(skb);
>  		kcov_remote_stop();
> +		cond_resched();
>  	}
>  
>  	/* process status queue */
> @@ -1504,6 +1505,7 @@ static void ieee80211_iface_work(struct
>  		kfree_skb(skb);
>  
>  		kcov_remote_stop();
> +		cond_resched();
>  	}
>  
>  	/* then other type-dependent work */
> --

Again. What are you trying to achieve here? 

ieee80211_iface_work() is a work function invoked from a worker thread
in preemptible task context.

The kernel config used for this has CONFIG_PREEMPT=y, which means that
the context in which you are sprinkling cond_resched() is already fully
preemtible and the only reason for this fail would be a fatal bug in the
scheduler core or in the preemption mechanism. Pretty unlikely to go
unnoticed for anything else than for this particular reproducer.

Can you please stop waisting precious compute power?

Thanks,

        tglx