From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 2/2] fs: Make write(2) interruptible by a signal Date: Mon, 14 Nov 2011 16:30:47 +0100 Message-ID: <20111114153047.GL5230@quack.suse.cz> 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> <20111114141626.GD4387@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , Wu Fengguang , "linux-fsdevel@vger.kernel.org" , Al Viro , "k-mio@sx.jp.nec.com" , Andrew Morton , Christoph Hellwig To: Matthew Wilcox Return-path: Received: from cantor2.suse.de ([195.135.220.15]:43877 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753107Ab1KNPbJ (ORCPT ); Mon, 14 Nov 2011 10:31:09 -0500 Content-Disposition: inline In-Reply-To: <20111114141626.GD4387@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon 14-11-11 07:16:26, Matthew Wilcox wrote: > 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. By "can't return" you mean userspace need not be expecting it so we shouldn't break it or is there some standard which forbids it? Just curious... Honza -- Jan Kara SUSE Labs, CR