Re: [PATCH 2/2] Make write(2) interruptible by a signal

[Matthew Wilcox <matthew@wil.cx>]

On Wed, Nov 23, 2011 at 12:29:48PM -0800, Andrew Morton wrote:
> > Still, if it's ***only*** for SIGKILL, we'll probably be OK, since
> > for that one case there's no chance userspace can intercept the signal,
> > so it can't do any recovery anyway.  (I could imagine some HPC program
> > doing a massive 2GB write, and some user of that program depending on
> > the fact that he can kill it at a predefined place by sending a SIGKILL
> > and knowing that the file would be written up to that 2GB chunk --- but
> > that's clearly an edge situation, as opposed to something that would
> > effect most GNOME and KDE apps.) We just need to make sure we never try
> > to do this for any other signal that could be caught, such as SIGINT or
> > SIGQUIT or (worse yet) SIGTSTP.
> 
> That it is a fatal SIGKILL means that the *current* application doesn't
> care.  But other processes will sometimes notice this change. 
> Previously if an app did write(file, 128k) and was hit with SIGKILL, it
> would write either 0 bytes or 128k bytes.  Now, it can write 36k bytes,
> yes?  If the target file consisted of a stream of 128k records then the
> user will claim, with some justification, that Linux corrupted it.

On the other hand, if there was a crash mid-write, they might also get a
36k write that actually hit media (right?  Or do we guarantee that on
reboot you see a multiple of 128k?)

We could put in some nice code that rewinds i_size to where it used to
be if the write was interrupted.  Or do we need to?  Presumably write_end
would not have been called, so i_size would not have been updated.

> Dunno.  People do lots of weird and flakey things.  I have a suspicion
> that we'll be hearing back from them about this change.

The problem is that we may not hear from them for 6 years ... or whenever
they decide to move off RHEL 3.

-- 
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."