Hi Linus,
Please pull dlm updates from tag:
git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm.git dlm-5.3
Apart from a couple trivial fixes, the more notable fix makes the dlm
continuing waiting for a user space result if a signal interrupts the
wait event.
Thanks,
Dave
David Teigland (1):
dlm: Fix test for -ERESTARTSYS
David Windsor (1):
dlm: check if workqueues are NULL before flushing/destroying
Greg Kroah-Hartman (1):
dlm: no need to check return value of debugfs_create functions
Mark Syms (1):
dlm: retry wait_event_interruptible in event of ERESTARTSYS
fs/dlm/debug_fs.c | 21 ++-------------------
fs/dlm/dlm_internal.h | 8 ++++----
fs/dlm/lockspace.c | 6 ++++--
fs/dlm/lowcomms.c | 18 ++++++++++++------
fs/dlm/main.c | 5 +----
5 files changed, 23 insertions(+), 35 deletions(-)
On Tue, Jul 9, 2019 at 9:57 AM David Teigland <[email protected]> wrote:
>
> Apart from a couple trivial fixes, the more notable fix makes the dlm
> continuing waiting for a user space result if a signal interrupts the
> wait event.
What? No.
That's not sensible at all.
If wait_event_interruptible() returns -ERESTARTSYS, it means that we
have a signal pending.
And if we have a signal pending, then you can't go back and call
wait_event_interruptible() in a loop, because the signal will
*continue* to be pending, so now your "wait event" becomes a kernel
busy loop.
If you don't want to react to signals, then you shouldn't use the
"interruptible()" version of wait-event.
I'm not pulling this. Because the code looks completely and utterly wrong to me.
Am I missing something? Feel free to educate me and re-submit.
Linus
On Wed, Jul 10, 2019 at 09:05:21PM -0700, Linus Torvalds wrote:
> If wait_event_interruptible() returns -ERESTARTSYS, it means that we
> have a signal pending.
>
> And if we have a signal pending, then you can't go back and call
> wait_event_interruptible() in a loop, because the signal will
> *continue* to be pending, so now your "wait event" becomes a kernel
> busy loop.
>
> If you don't want to react to signals, then you shouldn't use the
> "interruptible()" version of wait-event.
Right, a simple wait_event looks obvious; I'll have the submitters test
that before sending that next time around. I'll put together another pull
with the two trivial commits.
Thanks
Dave