From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [PATCH 2/2] fs: Make write(2) interruptible by a signal Date: Mon, 14 Nov 2011 07:16:26 -0700 Message-ID: <20111114141626.GD4387@parisc-linux.org> References: <1321269030-6019-1-git-send-email-jack@suse.cz> <1321269030-6019-3-git-send-email-jack@suse.cz> <20111114121556.GB4616@localhost> <20111114123446.GE5230@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Wu Fengguang , "linux-fsdevel@vger.kernel.org" , Al Viro , "k-mio@sx.jp.nec.com" , Andrew Morton , Christoph Hellwig To: Jan Kara Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:40792 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751217Ab1KNOQ2 (ORCPT ); Mon, 14 Nov 2011 09:16:28 -0500 Content-Disposition: inline In-Reply-To: <20111114123446.GE5230@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Nov 14, 2011 at 01:34:46PM +0100, Jan Kara wrote: > On Mon 14-11-11 20:15:56, Wu Fengguang wrote: > > > @@ -2407,6 +2407,10 @@ static ssize_t generic_perform_write(struct file *file, > > > iov_iter_count(i)); > > > > > > again: > > > + if (signal_pending(current)) { > > > > signal_pending looks more useful than fatal_signal_pending in that it > > covers normal signals too. However it's exactly the broader coverage > > that makes it an interface change -- will this possibly break casually > > written applications? > Yeah, this is upto discussion. Historically, write() (or any other system > call) could have returned EINTR. In fact, write() to a socket can return > EINTR even now. But you are right that we didn't return EINTR from write() > to a regular file. So if you prefer to never return EINTR from a write to a > regular file, I can change the check since I'm also slightly worried that > some badly written app can notice. No, this is not up for discussion. You can't return short writes (or reads). This is why the 'fatal_signal_pending' API exists -- if the signal is fatal, the task is never returned to, so its bug (not checking the return from read/write) is not exposed. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."