[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