[Unionfs] unionfs with mmap support breaks apt-get

[Shaya Potter]

On Thu, 2006-03-23 at 10:20 +0100, Michael Prokop wrote:
> * Shaya Potter <spotter at cs.columbia.edu> [20060323 00:10]:
> > On Wed, 2006-03-22 at 23:37 +0100, Michael Prokop wrote:
> 
> > > starting with mmap support in unionfs the current cvs snapshots
> > > cause problems with apt-get on Debian running kernel 2.6.16.
> 
> > > Running 'apt-get update; apt-get upgrade' results in:
> 
> > > [...]
> > > E: I wasn't able to locate file for the $FOO package. This might
> > > mean you need to manually fix this package.
> 
> > > I had no time to take a closer look at apt's sources, but it
> > > definitely uses mmap. So far I just tracked down that it's related
> > > to the mmap support within unionfs:
> 
> > really? I use it w/ apt-get all the time.
> [...]
> 
> Yes. I'm running dpkg version 1.13.17, apt version 0.6.43.3 using an
> up2date Debian unstable system with kernel 2.6.16 and unionfs with
> the "Knoppix-like layout" in Live-CD mode.

ok, I've reproduced this problem w/ plain unionfs-1.1.3 (seems I have
been using it by accident, instead of my patched for mmap stuff).

I need to look at the mmap code, but it might not be an mmap bug, but
something else in unionfs.

hit this oops when trying to test it with plain unionfs

Modules linked in: zap interpos ext2 unionfs nilfs libcrc32c nfsd
exportfs lockd sunrpc ocfs2_dlmfs ocfs2_dlm ocfs2_nodemanager configfs
sctp af_packet i2c_piix4 i2c_core lock_dlm dlm cman gfs lock_harness
dm_mod qla2300 qla2xxx scsi_transport_fc sg sr_mod sd_mod scsi_mod
ide_cd cdrom tg3 psmouse rtc ext3 jbd mbcache ide_disk ide_generic
serverworks piix ide_core unix
CPU:    0
EIP:    0060:[<f8dcdbd4>]    Tainted: GF     VLI
EFLAGS: 00010292   (2.6.11.12-smp)
EIP is at unionfs_file_revalidate+0x74/0x2840 [unionfs]
eax: 00000000   ebx: 000000ac   ecx: 00000000   edx: f8dd7159
esi: 00000000   edi: 00000001   ebp: f8dd7159   esp: ec2c7c98
ds: 007b   es: 007b   ss: 0068
Process apt-get (pid: 11239, threadinfo=ec2c6000 task=f694e540)
Stack: f8dda340 f8dd7159 000000ac 00000004 f8dda480 f8ddfbe0 f8dd7159
f8dda340
       000000ac ed950880 00000286 f8dd3fb4 00000001 c0169b5d 00000000
00000286
       00000000 f8dd3fb4 00000000 f8dd8054 0000029b 00000000 00000001
ed950880
Call Trace:
 [<f8dd3fb4>] fist_dprint_internal+0x14/0x80 [unionfs]
 [<c0169b5d>] fasync_helper+0x9d/0xe0
 [<f8dd3fb4>] fist_dprint_internal+0x14/0x80 [unionfs]
 [<f8dd28c3>] unionfs_flush+0x73/0xbed [unionfs]
 [<f8dd21ba>] unionfs_file_release+0x13a/0x3e0 [unionfs]
 [<c01a3951>] _atomic_dec_and_lock+0x31/0x50
 [<c016f052>] dput+0x152/0x1d0
 [<c0157f4e>] __fput+0xbe/0x120
 [<c0156536>] filp_close+0x76/0x90
 [<c011b0a4>] put_files_struct+0x64/0xd0
 [<c011bd86>] do_exit+0xd6/0x330
 [<f92753c6>] hijack_do_exit+0x166/0x8d0 [zap]
 [<c0103190>] apic_timer_interrupt+0x1c/0x24
 [<c01039b8>] die+0x188/0x190
 [<c0111d2a>] do_page_fault+0x2da/0x5d5
 [<c0111bec>] do_page_fault+0x19c/0x5d5
 [<c01a3951>] _atomic_dec_and_lock+0x31/0x50
 [<c016f052>] dput+0x152/0x1d0
 [<c0111a50>] do_page_fault+0x0/0x5d5
 [<c0103213>] error_code+0x2b/0x30
 [<c015007b>] setup_swap_extents+0x14b/0x2d0
 [<c01551d5>] sys_ftruncate+0x65/0x1b0
 [<c0102793>] syscall_call+0x7/0xb
Code: ac 00 00 00 89 4c 24 1c 89 54 24 18 89 44 24 08 89 6c 24 04 c7 04
24 40 a3 dd f8 e8 d7 63 00 00 8b 4c 24 64 8b 49 08 89 4c 24 48 <8b> 59
4c 85 db 74 6f 8b 4b 18 8b 53 20 39 d1 0f 8f 9f 27 00 00

which corresponds to an oops on

ret = (struct unionfs_dentry_info *)(dent)->d_fsdata;

in __dtopd()

which is from

lock_dentry() in unionfs_file_revalidate()

I don't know why plain unionfs would have a null upper dentry in a
struct file.