* [GIT PULL] dlm updates for 5.3
@ 2019-07-09 16:57 David Teigland
2019-07-11 4:05 ` Linus Torvalds
0 siblings, 1 reply; 3+ messages in thread
From: David Teigland @ 2019-07-09 16:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
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(-)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GIT PULL] dlm updates for 5.3
2019-07-09 16:57 [GIT PULL] dlm updates for 5.3 David Teigland
@ 2019-07-11 4:05 ` Linus Torvalds
2019-07-11 14:30 ` David Teigland
0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2019-07-11 4:05 UTC (permalink / raw)
To: David Teigland; +Cc: Linux List Kernel Mailing
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GIT PULL] dlm updates for 5.3
2019-07-11 4:05 ` Linus Torvalds
@ 2019-07-11 14:30 ` David Teigland
0 siblings, 0 replies; 3+ messages in thread
From: David Teigland @ 2019-07-11 14:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux List Kernel Mailing
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-11 14:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-09 16:57 [GIT PULL] dlm updates for 5.3 David Teigland
2019-07-11 4:05 ` Linus Torvalds
2019-07-11 14:30 ` David Teigland
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.