[Unionfs] repeatable kernel BUG in unionfs 2.1.3

Erez Zadok ezk at cs.sunysb.edu
Wed Sep 12 09:46:05 EDT 2007


In message <46E77248.2080702 at cs.columbia.edu>, Shaya Potter writes:
> 
> 
> Erez Zadok wrote:
> > In message <46E70D14.5010303 at cs.columbia.edu>, Shaya Potter writes:
> >> Just compiled unionfs into 2.6.22.6 and have a repeatable BUG() in a 
> >> stress test of mine that unionfs seems to tickle.
> >>
> >> My unionfs is slightly modified to allow up to 512 branches (simple 
> >> header define change).  In this case, I was up to 85 branches when this 
> >> occured.
> >>
> >> here's the backtrace
> > 
> > But the trace shows that the failure happens deep inside ext3, not unionfs.
> > So I'm not sure this is a unionfs bug.  It still could be, if unionfs is
> > doing something that indirectly causes ext3 to oops.
> 
> I blame it on the original author of the mmap code :) <whistle>

The mmap code has changed quite a bit since then... :-)

mmap in stacking works much better, esp. under heavy memory pressure (such
as your scenario), when the mmap methods call vfs_read/write.  However, it
can't be done for ->writepage b/c it doesn't get have a struct file to
pass.  We could make a fake struct file, but you can figure out how well
that'll be received on lkml.

Erez.


More information about the unionfs mailing list