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 <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html