It looks like we need to do a lock_super around those sections to
prevent the race (the branchman functions already use it, but obviously
it seems that revalidation and the putmap checking code need to as
well).

Charles

On Mon, 2005-10-10 at 22:34 -0400, Shaya Potter wrote:
> On Mon, 2005-10-10 at 17:44 -0400, Shaya Potter wrote:
> > it seems that branch manipulation and unionfs_file_revalidate can race
> > 
> > from unionfs_file_revalidate
> > -----------
> >     if (!unionfs_d_revalidate(dentry, 0) && !d_deleted(dentry)) {
> >                 err = -ESTALE;
> >                 goto out;
> >         }
> >         fist_print_dentry("file revalidate in", dentry);
> > 
> >         sb = dentry->d_sb;
> >         PASSERT(sb);
> >         sbgen = atomic_read(&stopd(sb)->usi_generation);
> >         dgen = atomic_read(&dtopd(dentry)->udi_generation);
> >         fgen = atomic_read(&ftopd(file)->ufi_generation);
> >         if (sbgen > dgen) {
> >                 FISTBUG("The dentry is not up to date!\n");
> >         }
> > ------------
> > 
> > if the branch structure would change somewhere between udi_generation
> > being set and usi_generation being read, one would hit this FISTBUG
> > (which I just did).
> 
> another possible race resulting in oops? (this is my modified unionfs,
> but I doubt my changes would have caused this, though its possible).  It
> seemed to occur right when a branching operation was happening.
> 
> ASSERTION FAILED: putmap (null) at /root/unionfs-sparse/commonfops.c:41
> (branchput_gen)
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
>  printing eip:
> f96c78ff
> *pde = 00000000
> Oops: 0002 [#1]
> PREEMPT
> Modules linked in: unionfs ocfs2 nfsd exportfs lockd sunrpc ocfs2_dlmfs
> ocfs2_dlm ocfs2_nodemanager configfs sctp ipv6 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:[<f96c78ff>]    Tainted: GF     VLI
> EFLAGS: 00010282   (2.6.11.12)
> EIP is at unionfs_file_revalidate+0x13e7f/0x14cf0 [unionfs]
> eax: 0000005b   ebx: f96fbb20   ecx: 00000000   edx: 10000000
> esi: 00000000   edi: de926e00   ebp: d09c7b7c   esp: d7793ecc
> ds: 007b   es: 007b   ss: 0068
> Process as (pid: 5018, threadinfo=d7792000 task=d26a6020)
> Stack: f96fbf00 f96f68c6 f96f66f2 f96fbb20 00000029 f96f3dbe f96f3d8c
> f96fbb20
>        000000ad d2953980 d0b3e348 00000000 00000000 ce11f300 ce3883e4
> 00000000
>        00000000 00000000 00000000 0000000f 00000011 de926e00 0000004c
> 000005e8
> Call Trace:
>  [<f956916d>] unionfs_read+0x6d/0x280 [unionfs]
>  [<c0151be5>] vfs_read+0xe5/0x160
>  [<c0151f01>] sys_read+0x51/0x80
>  [<c010272f>] syscall_call+0x7/0xb
> Code: c6 68 6f f9 89 4c 24 04 b8 29 00 00 00 bb 20 bb 6f f9 89 44 24 10
> b8 f2 66 6f f9 0f 45 d0 89 5c 24 0c 89 54 24 08 e8 01 c4 a4 c6 <c6> 05
> 00 00 00 00 00 e9 42 2e ff ff c7 04 24 c0 bf 6f f9 b8 25
> 
> 
> _______________________________________________
> unionfs mailing list
> [email protected]
> http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs

_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs

Reply via email to