[Unionfs] mmap unionfs bug

[Erez Zadok]

In message <cfa94dc20710162145y54dc65a7o4ea421c362614e55 at mail.gmail.com>, "Ryan Finnie" writes:
> On 10/16/07, Erez Zadok <ezk at cs.sunysb.edu> wrote:
> > Ryan, I brought the issue up on lkml, and there was some discussion about
> > ensuring that msync(2) never returns AOP_WRITEPAGE_ACTIVATE back to
> > userland.  In addition, based on recommendations from Pekka, I've got this
> > patch tested well on 2.6.23.1.  I plan to test it on all the backports and
> > then release it officially.  But in the mean time, it'd be very useful if
> > anyone who's noted problems with msync(2) (esp. when using unionfs w/ tmpfs)
> > to try this patch below.  I especially like it if you can try it with an
> > unpatched apt-get and see if when it calls msync(2), does it ever get
> > AOP_WRITEPAGE_ACTIVATE back.
> 
> Thank you, looks like we have a winner!  It patched cleanly against
> 2.1.6 for 2.6.22 and Debian's 2.6.22-4 source tree + other junk needed
> for Finnix to work.

Good to know.

> I can now do an "apt-get check" without issues.  However, at the
> beginning of an "apt-get update", I get this:
> 
> unionfs: error creating directory tree for rename, bindex = 1, err = -30
> unionfs: error creating directory tree for rename, bindex = 1, err = -30
> unionfs: error creating directory tree for rename, bindex = 1, err = -30

Nah, these are harmless "informational debugging" messages (esp. since 30 is
EROFS, an expected outcome of copyup).  As the code had been getting more
stable, I've been gradually converting those absolute printk's into
pr_debug's, esp. for messages that shouldn't clutter the syslog unless the
user/sysadmin really needs to know about it.  And of course, one can always
turn on CONFIG_UNION_FS_DEBUG to get all the gory messages.

> However, the update operation seems to complete successfully.  Is this
> a concern?
> 
> Ryan

Erez.