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 13:34:46 +0100 Message-ID: <20111114123446.GE5230@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , "linux-fsdevel@vger.kernel.org" , Al Viro , "k-mio@sx.jp.nec.com" , Andrew Morton , Christoph Hellwig To: Wu Fengguang Return-path: Received: from cantor2.suse.de ([195.135.220.15]:56096 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752081Ab1KNMfH (ORCPT ); Mon, 14 Nov 2011 07:35:07 -0500 Content-Disposition: inline In-Reply-To: <20111114121556.GB4616@localhost> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. Honza > > > + status = -EINTR; > > + break; > > + } -- Jan Kara SUSE Labs, CR