grep for "unchecked" in the kernel/verver subdirectory (of a vserver+grsec patch that i made before)... that will give you a list of "unchecked" atomic definitions, which means they don't cause a refcount overflow panic in the kernel (if you enabled refcount checking). But as i said, i'm not 100% sure that 's pax-stuff. grtz... Rik Bobbaers -- http://harry.enzoverder.be linux/unix/system/network/security/hardware admin infrastructure architect > On 08/11/2010 09:24, Rik Bobbaers wrote: >> >> But... You will run into problems with a vs+pax patch when your >> refcounters overflow (iirc that's a pax feature). So there is some >> patching that needs to be done on some vserver related things. I'll try >> to >> upload a patch for that (on top of the linux + pax + vserver) patch. >> This >> way, you can easily "make new patches" if new versions of pax or vserver >> come out. (it's definately not much... but check the refcount bugs in >> the >> mailinglist archives and you'll know what i'm talking about). > > Thanks Rik > > So far the only extra patch I have on 2.6.35 is pasted below. This > solves a compile issue only. (Note that I see the write_locks are > changed to spin_locks in the 2.6.36 patch.) > > However, I haven't *yet* found any ref count issues in the mailing > list? I did find the thread subject: "Kernel bug in __sock_sendmsg", > however, that's got quite a bit patch in it? > > What I did find was a discussion from Natanael Copa back in 2008 > suggesting we go pax+vserver only and your thoughts on the extra bits of > grsec which are useful. I wonder if it would be worth pulling out some > of the extra (simpler) bits of grsec into standalone patch - In an ideal > world grsec team might even maintain it for us... > > Grateful if you can send over any fixes to pax+vserver as you get the time > > Cheers > > Ed W > > > --- kernel/vserver/context.c.orig 2010-11-08 08:59:43.080799733 +0000 > +++ kernel/vserver/context.c 2010-11-08 10:57:28.192871022 +0000 > @@ -122,7 +122,7 @@ > // preconfig fs entries > for (index = 0; index < VX_SPACES; index++) { > write_lock(&init_fs.lock); > - init_fs.users++; > + atomic_inc(&init_fs.users); > write_unlock(&init_fs.lock); > new->vx_fs[index] = &init_fs; > } > @@ -197,7 +197,7 @@ > > fs = xchg(&vxi->vx_fs[index], NULL); > write_lock(&fs->lock); > - kill = !--fs->users; > + kill = atomic_dec_and_test(&fs->users); > write_unlock(&fs->lock); > if (kill) > free_fs_struct(fs); > --- kernel/vserver/space.c.orig 2010-11-08 08:59:43.084798404 +0000 > +++ kernel/vserver/space.c 2010-11-08 10:52:06.376871197 +0000 > @@ -220,7 +220,7 @@ > if (mask & CLONE_FS) { > write_lock(&fs_cur->lock); > current->fs = fs; > - kill = !--fs_cur->users; > + kill = atomic_dec_and_test(&fs_cur->users); > write_unlock(&fs_cur->lock); > } > > @@ -278,7 +278,7 @@ > if (mask & CLONE_FS) { > write_lock(&fs_vxi->lock); > vxi->vx_fs[index] = fs; > - kill = !--fs_vxi->users; > + kill = atomic_dec_and_test(&fs_vxi->users); > write_unlock(&fs_vxi->lock); > } > >