netdev - RE: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop

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:   Tue, 17 Jan 2017 18:15:19 +0000
From:   Elad Nachman <EladN@...at.com>
To:     David Miller <davem@...emloft.net>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus
 syscall endless loop

Any thought about limiting the amount of busy polling?
Say if more than X polls are done within a jiffy, then at least for preemptable kernels you can sleep for a jiffy inside the syscall to yield the CPU for a while?

Thanks,

Elad.

-----Original Message-----
From: David Miller [mailto:davem@...emloft.net]
Sent: יום ג 17 ינואר 2017 19:58
To: Elad Nachman <EladN@...at.com>
Cc: netdev@...r.kernel.org
Subject: Re: Kernel 4.6.7-rt14 kernel workqueue lockup - rtnl deadlock plus syscall endless loop

From: Elad Nachman <EladN@...at.com>
Date: Tue, 17 Jan 2017 17:39:03 +0000

> What's more odd about this is that it's very unusual and strange for a
> kernel function to invoke the restart mechanism because a lock is
> being held - the point of the restart mechanism is to allow userspace
> signal handlers to run, so it should only be used when there's a
> signal pending. I think this is a hack in the IPv6 code to work around
> some other issue.

It's not unusal at all, if you actually grep for this under net/ you will see that it is in fact a common code pattern.

It prevents deadlocks because the sysfs and other nodes that we are operating with can be unregistered by other threads of control holding the RTNL mutex.  If we don't break out, we won't release our reference and therefore the RTNL mutex holding entity cannot make forward progress.

This behavior is therefore very much intentional.
IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.