Comment 11 for bug 103044

Follow-up: this does not seem to be exactly the same issue. I've just tried the test case found in bug #137765 and it does not OOPS. However, bonnie++ doesn't seem to work correctly. I'm not sure if that's intended or not so I'll leave the interpretation to you.

Unionfs layout:
laga@laga-desktop:/unionfs$ mount
10.0.10.1:/opt/ltsp/i386 on /mnt type nfs (rw,addr=10.0.10.1)
tmpfs on /mnt2 type tmpfs (rw)
/home/laga/unionfs on /unionfs type unionfs (rw,dirs=/mnt2/=rw:/mnt=nfsro)

With 10.0.10.1 actually being localhost. Here's bonnie's output:

laga@laga-desktop:/unionfs/home/laga$ bonnie++
Writing with putc()...Can't putc() - disk full?

However, the disk is not full:

laga@laga-desktop:/unionfs/home/laga$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 7,5G 5,1G 2,1G 71% /
varrun 197M 216K 197M 1% /var/run
varlock 197M 0 197M 0% /var/lock
udev 197M 44K 197M 1% /dev
devshm 197M 0 197M 0% /dev/shm
lrm 197M 34M 163M 18% /lib/modules/2.6.22-14-generic/volatile
10.0.10.1:/opt/ltsp/i386
                      7,5G 5,1G 2,1G 71% /mnt
tmpfs 197M 2,8M 194M 2% /mnt2
/home/laga/unionfs 197M 2,8M 194M 2% /unionfs

I have tried to reproduce the OOPS I posted above with a union layout similar to how my diskless clients use unionfs:
/home/laga/unionfs on /unionfs type unionfs (rw,dirs=/mnt2/=rw:/mnt=nfsro)
10.0.10.1:/opt/ltsp/i386/ on /test/nfs type nfs (rw,addr=10.0.10.1)
/opt/ltsp/images/i386.img on /test/squashfs type squashfs (ro,loop=/dev/loop0)
unionfs on /test/union type unionfs (rw,dirs=/test/nfs/=rw:/test/squashfs/=ro)

I've just completed a full run of bonnie on /test/union/ and it hasn't crashed. Also, sudo find /test/union/ works without a problem. It's noteworthy that the squashfs contains the same files as the nfs mount (more or less), maybe it wasn't a smart move to do that :)

To make up for my silliness, I created another union with a different nfs share on top of the squashfs. This was the same nfs share which caused the OOPS when booting my diskless client (which now contains everything written by the client during booting). Immediately when running find . /test/union/, the kernel OOPSes again. I'm attaching the log.

I'd like to create a proper test case, but I'm running out of time for tonight unfortunately. I hope the backtrace will provide enough insight. If not, let me know and I'll come up with a sane way to reproduce the problem.