From: Alex Williamson <alex.williamson@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
kvm <kvm@vger.kernel.org>
Subject: Re: [GIT PULL] VFIO fixes for v4.1-rc2
Date: Fri, 01 May 2015 12:48:57 -0600 [thread overview]
Message-ID: <1430506137.4472.262.camel@redhat.com> (raw)
In-Reply-To: <CA+55aFziVpH1qyf8M+GdJxh3oJWd84pdJbo94kuMfSi1QscLew@mail.gmail.com>
On Fri, 2015-05-01 at 11:37 -0700, Linus Torvalds wrote:
> On Fri, May 1, 2015 at 10:40 AM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> >
> > - Flush signals on interrupted wait to retain polling interval (Alex Williamson)
>
> This cannot *possibly* be right. If I read this patch right, you're
> randomly just getting rid of signals. No way in hell is that correct.
>
> "flush_signals()" is only for kernel threads, where it's a hacky
> alternative to actually handling them (since kernel threads never
> rreturn to user space and cannot really "handle" a signal). But you're
> doing it in the ->remove handler for the device, which can be called
> by arbitrary system processes. This is not a kernel thread thing, as
> far as I can see.
>
> If you cannot handle signals, you damn well shouldn't be using
> "wait_event_interruptible_timeout()" to begin with. Get rid of the
> "interruptible", since it apparently *isn't* interruptible.
>
> So I'm not pulling this.
Ok. It seemed like useful behavior to be able to provide some response
to the user in the event that a ->remove handler is blocked by a device
in-use and the user attempts to abort the action. Thanks for reviewing,
Alex
next prev parent reply other threads:[~2015-05-01 18:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 17:40 [GIT PULL] VFIO fixes for v4.1-rc2 Alex Williamson
2015-05-01 18:37 ` Linus Torvalds
2015-05-01 18:48 ` Alex Williamson [this message]
2015-05-01 20:23 ` Linus Torvalds
2015-05-01 22:03 ` Alex Williamson
2015-05-01 19:38 ` [PATCH] signals: Generate warning when flush_signals() is called from non-kthread context Ingo Molnar
2015-05-02 8:30 ` NeilBrown
2015-05-02 16:27 ` Linus Torvalds
2015-05-07 12:54 ` Peter Zijlstra
2015-05-04 17:35 ` Oleg Nesterov
2015-05-07 13:33 ` Jiri Kosina
2015-05-07 22:37 ` NeilBrown
2015-05-02 11:56 ` Evgeniy Polyakov
2015-05-02 16:33 ` Richard Weinberger
2015-05-03 17:34 ` Oleg Nesterov
2015-05-04 16:45 ` [PATCH 0/1] signals: don't abuse __flush_signals() in selinux_bprm_committed_creds() Oleg Nesterov
2015-05-04 16:45 ` [PATCH 1/1] " Oleg Nesterov
2015-05-04 19:43 ` Paul Moore
2015-05-04 19:43 ` Paul Moore
2015-05-06 10:19 ` [PATCH] signals: Generate warning when flush_signals() is called from non-kthread context Ingo Molnar
2015-05-01 20:11 ` [GIT PULL] VFIO fixes for v4.1-rc2 Richard Weinberger
2015-05-01 21:09 ` Richard Weinberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1430506137.4472.262.camel@redhat.com \
--to=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.