[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AM5PR0701MB18732AA38AAB6E39A92FA6E3A07F0@AM5PR0701MB1873.eurprd07.prod.outlook.com>
Date: Wed, 18 Jan 2017 09:57:08 +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
OK, how about reflecting the state of the rtnl lock to user space via the /proc file system?
This way I can test it before using sysctl on the relevant proc files to avoid live-lock.
Thanks,
Elad.
-----Original Message-----
From: David Miller [mailto:davem@...emloft.net]
Sent: יום ג 17 ינואר 2017 21:06
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 18:15:19 +0000
> 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?
We cannot yield there, because we must return immediately from this
context in order to drop the sysctl locks and references.
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.
Powered by blists - more mailing lists