[Unionfs] mmap unionfs bug

[Erez Zadok]

In message <cfa94dc20710051657y4d855892h301ef72e52c2a083 at mail.gmail.com>, "Ryan Finnie" writes:
> I'm getting apt errors when running a root on unionfs2.  It looks like
> this was already discovered in Ubuntu:
> 
> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/144001
> 
> and a workaround was made for apt, but it was never reported to
> unionfs.  Note Colin Watson's explanation halfway down.
> 
> Thanks,
> RF

Ryan, thanks for the pointer.  I included Colin's text below for reference.

> > Colin Watson  wrote on 2007-09-22:  (permalink)> 
> 
> > This is also a kernel bug. The manual page for msync() says:
> > 
> > RETURN VALUE
> >        On success, zero is returned. On error, -1 is returned, and errno
> > is set appropriately.
> >
> > 
> > Yet here an strace shows:
> > 
> >   msync(0xb630c000, 8564, MS_SYNC) = 524288
> > 
> > This is AOP_WRITEPAGE_ACTIVATE, which include/linux/fs.h says may be
> > returned by writepage() methods on address space mappings. Like some other
> > parts of the kernel, unionfs returns this from its writepage() method. The
> > call chain appears to go like this: sys_msync -> do_fsync ->
> > filemap_fdatawrite -> __filemap_fdatawrite -> __filemap_fdatawrite_range
> > -> do_writepages -> generic_writepages -> write_cache_pages -> __writeback
> > -> unionfs_writepage. When unionfs_writepage returns
> > AOP_WRITEPAGE_ACTIVATE, write_cache_pages does check for this and unlocks
> > the page, but it doesn't sanitise the return code (I don't know exactly
> > where this ought to happen). As a result, that return code wrongly
> > propagates all the way back up to userspace.
> > 
> > It is possible to work around this in apt by simply checking msync() < 0
> > rather than msync() != 0; I've tested this and 'apt-get update' now works
> > fine. I'll upload this now, which will be good enough for beta.

Yes, I'd say is a kernel bug.  It shouldn't return 524288
(AOP_WRITEPAGE_ACTIVATE) but something more sane.  *Unless* Linux decided to
change the semantics of msync(2), in which case user programs will have to
change!

I'll post a question on this to lkml/fsdevel.

Erez.