From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Allison Subject: Re: [PATCH 2/2] fs: Make write(2) interruptible by a signal Date: Mon, 14 Nov 2011 10:44:06 -0800 Message-ID: <20111114184406.GB5493@samba2> 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> <20111114153047.GL5230@quack.suse.cz> Reply-To: Jeremy Allison Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Matthew Wilcox , 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 fn.samba.org ([216.83.154.106]:34495 "EHLO lists.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752710Ab1KNSoJ (ORCPT ); Mon, 14 Nov 2011 13:44:09 -0500 Content-Disposition: inline In-Reply-To: <20111114153047.GL5230@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Nov 14, 2011 at 04:30:47PM +0100, Jan Kara wrote: > 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... This *WILL* break userspace code if you return short writes on a filesystem fd. Guarenteed. I originally wrote code in Samba to take care of it back before I learned the difference between "slow" and "fast" interruptable system calls (see W.R.Stevens for details). Don't return short writes or reads on a filesystem fd. Jeremy.