Re: BUG: mmapfile/writev spurious zero bytes still in the wild

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 3 Oct 2008 21:44:14 +1000 Bron Gondwana <brong@fastmail.fm> wrote:

> On Tue, Jun 17, 2008 at 02:20:49PM -0700, Linus Torvalds wrote:
> 
> [reminder from way back: this bug was caused by writev containing 
> mmaped pages that weren't paged in, it's 64 bit only.  It
> particularly affects Cyrus Imapd's database formats]
> 
> > On Tue, 17 Jun 2008, Linus Torvalds wrote:
> > > 
> > > Hmm. Something like this *may* salvage it.
> > > 
> > > Untested, so far (I'll reboot and test soon enough), but even if it fixes 
> > > things, it's not really very good. 
> > 
> > Ok, so I just rebooted with this, and it does indeed fix the bug.
> > 
> > I'd be happier with a more complete fix (ie being byte-accurate and 
> > actually doing the partial copy when it hits a fault in the middle), but 
> > this seems to be the minimal fix, and at least fixes the totally bogus 
> > return values from the x86-64 __copy_user*() functions.
> 
> Has this been revisited since?  I haven't noticed, but I really only
> skim LKML - have to save some time in the day for my real job[tm] of
> keeping an email service running!
> 
> > Not that I checked that I got _all_ cases correct (and maybe there are 
> > other versions of __copy_user that I missed entirely), but Bron's 
> > test-case at least seems to work properly for me now.
> > 
> > Bron? If you have a more complete test-suite (ie the real-world case that 
> > made you find this), it would be good to verify the whole thing. 
> 
> It's been fine for us since, but unfortunately most of the world is
> still running distribution "stable" kernels.  I've just been helping a
> user who's getting corrupted flat file databases on Ubuntu's stable 64
> bit xen kernels, and it looks like it's the same issue.
> 
> Is there a standard way to tell backporters "you really need to add this
> patch for your users' sanity"?

Yes, there is.  We backport the patch into earlier kernel releases and
that action _should_ wake the distros up to take a look at the fix.

This particular fix (42a886af728c089df8da1b0017b0e7e6c81b5335) was
included in 2.6.26 and also is present in 2.6.25.17, but not 2.6.25. 
So we did backport it into 2.6.25.x.  Maybe distros were slow or errant
in picking up the patch.