[GIT PULL] dlm updates for 5.3

[GIT PULL] dlm updates for 5.3

[David Teigland]

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(-)

Re: [GIT PULL] dlm updates for 5.3

[Linus Torvalds]

On Tue, Jul 9, 2019 at 9:57 AM David Teigland <teigland@redhat.com> 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

Re: [GIT PULL] dlm updates for 5.3

[David Teigland]

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