[OpenAFS-devel] problems with current cvs on linux - oops's, possibly related to 1.32-1.34 changes in osi_vnodeops.c

Neulinger, Nathan nneul@umr.edu
Thu, 14 Mar 2002 12:52:45 -0600


I wonder if the allocked entry of the sysname state isn't getting set
back to zero somewhere.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]=20
> Sent: Thursday, March 14, 2002 12:44 PM
> To: Neulinger, Nathan
> Cc: openafs-devel@openafs.org; chas@cmf.nrl.navy.mil; Ted Anderson
> Subject: Re: [OpenAFS-devel] problems with current cvs on=20
> linux - oops's, possibly related to 1.32-1.34 changes in=20
> osi_vnodeops.c
>=20
>=20
> In a closer look there is DEFINITELY a double-free going on.  I just
> caught the following while breakpoints are set in both
> osi_AllocLargeSpace() and osi_FreeLargeSpace():
>=20
> Breakpoint 2, osi_FreeLargeSpace (adata=3D0xc77a9000)
>     at ../afs/afs_osi_alloc.c:71
> 71          AFS_STATCNT(osi_FreeLargeSpace);
> (gdb)=20
> Continuing.
>=20
> Breakpoint 2, osi_FreeLargeSpace (adata=3D0xc4170000)
>     at ../afs/afs_osi_alloc.c:71
> 71          AFS_STATCNT(osi_FreeLargeSpace);
> (gdb)=20
> Continuing.
>=20
> Breakpoint 2, osi_FreeLargeSpace (adata=3D0xc4170000)
>     at ../afs/afs_osi_alloc.c:71
> 71          AFS_STATCNT(osi_FreeLargeSpace);
>=20
>=20
> Notice that it's trying to free 0xc4170000 twice?  This last free()
> is coming from:
>=20
> (gdb) where
> #0  osi_FreeLargeSpace (adata=3D0xc4170000) at =
../afs/afs_osi_alloc.c:71
> #1  0xc8896a5d in afs_linux_dentry_revalidate (dp=3D0xc3823260, =
flags=3D0)
>     at ../afs/osi_vnodeops.c:847
> #2  0xc01420fd in cached_lookup (parent=3D0xc662d7c0,=20
> name=3D0xc5349f98, flags=3D0)
>     at namei.c:249
>=20
> Unfortunately I didn't get a backtrace on the pentultimate=20
> free().  I'll
> keep working on it.  But this is definitely the cause of the=20
> problem --
> the same packet is getting onto the freelist twice.
>=20
> -derek
>=20
> "Neulinger, Nathan" <nneul@umr.edu> writes:
>=20
> > Derek was able to trace down the reason for the fault witn kgdb. I'd
> > guess it likely has something to do with these recent changes to
> > osi_vnodeops.c. I'll take a closer look, but I'm not really familiar
> > with what's going on in the code here.=20
> >=20
> > -- Nathan
> >=20
> > ------------------------------------------------------------
> > Nathan Neulinger                       EMail:  nneul@umr.edu
> > University of Missouri - Rolla         Phone: (573) 341-4841
> > Computing Services                       Fax: (573) 341-4216
> >=20
> >=20
> > -----Original Message-----
> > From: Neulinger, Nathan=20
> > Sent: Thursday, March 14, 2002 12:29 PM
> > To: 'Derek Atkins'
> > Subject: RE: Have you had a succesful build+use with=20
> current openafs?
> >=20
> >=20
> > FYI Looks like it was probably introduced in 1.33 of osi_vnodeops.c.
> > There were a bunch of changes for revalidate_dnode.
> >=20
> > -- Nathan
> >=20
> > ------------------------------------------------------------
> > Nathan Neulinger                       EMail:  nneul@umr.edu
> > University of Missouri - Rolla         Phone: (573) 341-4841
> > Computing Services                       Fax: (573) 341-4216
> >=20
> >=20
> > > -----Original Message-----
> > > From: Derek Atkins [mailto:warlord@MIT.EDU]=20
> > > Sent: Thursday, March 14, 2002 12:23 PM
> > > To: Neulinger, Nathan
> > > Subject: Re: Have you had a succesful build+use with=20
> current openafs?
> > >=20
> > >=20
> > > Yep.  kgdb.sf.net.  Requires two systems with a "serial" line
> > > between them.  In my case I'm using vmware :)
> > >=20
> > > We should definitely report this to openafs-devel!  I'll look a
> > > bit more but I've only got about 30 minutes more I can sink into
> > > this today.
> > >=20
> > > -derek
> > >=20
> > > "Neulinger, Nathan" <nneul@umr.edu> writes:
> > >=20
> > > > Goody! :)
> > > >=20
> > > > Thanks. That's reassuring, nothing like having a bug=20
> like this screw
> > > > with your head when you think that you've made a whole=20
> > > bunch of changes
> > > > that should not have any affect on code behavior.
> > > >=20
> > > > Are you using the kernel debugger patches? I definately=20
> > > should dig into
> > > > that some time.=20
> > > >=20
> > > > -- Nathan
> > > >=20
> > > > ------------------------------------------------------------
> > > > Nathan Neulinger                       EMail:  nneul@umr.edu
> > > > University of Missouri - Rolla         Phone: (573) 341-4841
> > > > Computing Services                       Fax: (573) 341-4216
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Derek Atkins [mailto:warlord@MIT.EDU]=20
> > > > > Sent: Thursday, March 14, 2002 12:17 PM
> > > > > To: Neulinger, Nathan
> > > > > Subject: Re: Have you had a succesful build+use with=20
> > > current openafs?
> > > > >=20
> > > > >=20
> > > > > Here is the stack trace of what's going on.  I have=20
> no idea why
> > > > > freePacketList is being set to '1'.  I'll keep=20
> looking, but this
> > > > > is clearly not "just you" :)
> > > > >=20
> > > > > -derek
> > > > >=20
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0xc8863031 in osi_AllocLargeSpace (size=3D720) at=20
> > > > > ../afs/afs_osi_alloc.c:201
> > > > > 201         if ( tp ) freePacketList =3D tp->next;
> > > > > (gdb) where
> > > > > #0  0xc8863031 in osi_AllocLargeSpace (size=3D720) at=20
> > > > > ../afs/afs_osi_alloc.c:201
> > > > > #1  0xc8872a91 in afs_DoBulkStat (adp=3D0xc8936658,=20
> dirCookie=3D480,=20
> > > > >     areqp=3D0xc5347e68) at ../afs/afs_vnop_lookup.c:426
> > > > > #2  0xc8874c25 in afs_lookup (adp=3D0xc8936658,=20
> > > aname=3D0xc13ded80 "CVS",=20
> > > > >     avcp=3D0xc5347ec4, acred=3D0xc412a000) at=20
> > > > > ../afs/afs_vnop_lookup.c:1190
> > > > > #3  0xc8896c14 in afs_linux_lookup (dip=3D0xc8936658,=20
> dp=3D0xc13ded20)
> > > > >     at ../afs/osi_vnodeops.c:993
> > > > > #4  0xc0142175 in real_lookup (parent=3D0xc79210c0,=20
> > > > > name=3D0xc5347f4c, flags=3D0)
> > > > >     at namei.c:284
> > > > > #5  0xc0142936 in path_walk (name=3D0xc76bf011 "",=20
> > > > > nd=3D0xc5347f98) at namei.c:564
> > > > > #6  0xc014313a in __user_walk (name=3D0xbfffb820=20
> > > > > "../../src/doc/CVS", flags=3D9,=20
> > > > >     nd=3D0xc5347f98) at namei.c:805
> > > > > #7  0xc013fcf6 in sys_stat64 (filename=3D0xbfffb820=20
> > > > > "../../src/doc/CVS",=20
> > > > >     statbuf=3D0xbfff96b0, flags=3D1075171668) at stat.c:337
> > > > > #8  0xc0106fcb in system_call () at af_packet.c:1879
> > > > > (gdb) p tp
> > > > > $1 =3D (struct osi_packet *) 0x1
> > > > > (gdb) p freePacketList
> > > > > $2 =3D (struct osi_packet *) 0x1
> > > > >=20
> > > > > --=20
> > > > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media=20
> Laboratory
> > > > >        Member, MIT Student Information Processing=20
> Board  (SIPB)
> > > > >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA=20
>     N1NWH
> > > > >        warlord@MIT.EDU                        PGP key=20
> available
> > > > >=20
> > >=20
> > > --=20
> > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > >        Member, MIT Student Information Processing Board  (SIPB)
> > >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> > >        warlord@MIT.EDU                        PGP key available
> > >=20
> > _______________________________________________
> > OpenAFS-devel mailing list
> > OpenAFS-devel@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-devel
>=20
> --=20
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available
>=20