Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752650AbbEAUXY (ORCPT ); Fri, 1 May 2015 16:23:24 -0400 Received: from mail-ie0-f181.google.com ([209.85.223.181]:36362 "EHLO mail-ie0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751932AbbEAUXV (ORCPT ); Fri, 1 May 2015 16:23:21 -0400 MIME-Version: 1.0 In-Reply-To: <1430506137.4472.262.camel@redhat.com> References: <1430502057.4472.255.camel@redhat.com> <1430506137.4472.262.camel@redhat.com> Date: Fri, 1 May 2015 13:23:20 -0700 X-Google-Sender-Auth: 462eoFdyPZJrwC-4JMxCMouMa0g Message-ID: Subject: Re: [GIT PULL] VFIO fixes for v4.1-rc2 From: Linus Torvalds To: Alex Williamson Cc: Oleg Nesterov , linux-kernel , kvm Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1961 Lines: 46 On Fri, May 1, 2015 at 11:48 AM, Alex Williamson wrote: > > 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. Well, that kind of notification *might* be useful, but at the cost of saying "somebody tried to send you a signal, so I am now telling you about it, and then deleting that signal, and you'll never know what it actually was"? That's not useful, that's just wrong. Now, what might in theory be useful - but I haven't actually seen anybody do anything like that - is to start out with an interruptible sleep, warn if you get interrupted, and then continue with an un-interruptible sleep (leaving the signal active). But even that sounds like a very special case, and I don't think anything has ever done that. In general, our signal handling falls into three distinct categories: (a) interruptible (and you can cancel the operation and return "try again") (b) killable (you can cancel the operation, knowing that the requester will be killed and won't try again) (c) uninterruptible where that (b) tends to be a special case of an operation that technically isn't really interruptible (because the ABI doesn't allow for retrying or error returns), but knowing that the caller will never see the error case because it's killed means that you can do it. The classic example of that is an NFS mount that is mounted "nointr" - you can't return EINTR for a read or a write (because that invalidates POSIX) but you want to let SIGKILL just kill the process in the middle when the network is hung. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/