From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [GIT PULL] VFIO fixes for v4.1-rc2 Date: Fri, 01 May 2015 12:48:57 -0600 Message-ID: <1430506137.4472.262.camel@redhat.com> References: <1430502057.4472.255.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Oleg Nesterov , linux-kernel , kvm To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, 2015-05-01 at 11:37 -0700, Linus Torvalds wrote: > On Fri, May 1, 2015 at 10:40 AM, Alex Williamson > 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