Re: Move struct file RCU handling into the slab allocator?

["Paul E. McKenney" <paulmck@us.ibm.com>]

On Wed, Jun 21, 2006 at 03:36:10PM -0700, Christoph Lameter wrote:
> On Sat, 17 Jun 2006, Paul E. McKenney wrote:
> 
> > Careful performance testing is needed as well, the validity check does
> > appear to me to be pretty lightweight, but this stuff is a bit sensitive
> > to performance.
> 
> Jens has done some testing with another approach like this and found a 
> good increase in speed.

And I would be much more concerned if the change was in the single-threaded
fastpath in fget_light(), to be sure.  But getting a view of multi-threaded
performance of this particular patch for a variety of workloads is still
warranted.

> > Some one less than a philistine than I might argue that this should
> > go back to the original name of f_list.  ;-)
> 
> Did that in V2 of the patch.

Cool!

> > o	Not sure whether hfs_file_release()s check for zero f_count
> > 	still works, but am quite concerned.  HFS experts?
> > 
> > o	Ditto for hfsplus_file_release().  And for affs_file_release().
> 
> That is not a problem since the object has not been returned to the slab 
> yet so it cannot have been reused.

Good enough!

							Thanx, Paul

>                                    A problem could occur if one could
> now establish a new reference to the object while it has a zero count. 
> But if that would be possible then we would be already in trouble.
> 
> The RCU check is only used to guarantee that the object is not
> vanishing from under us while we increase the refcount if it was not 
> zero. Since it is zero in these cases that will never occur.
> 
> In order to generate a wrong alias situation the following needs to 
> happen:
> 
> process 1		process 2:
> 
> do table lookup
> 			free the filp structure (refcount becomes zero)
> 			modify table
> 			create a new filp structure (same address)
> 			increment counter to 1
> inc_if_nonzero
> (counter becomes two)
> 
> <now we have a wrong reference>
> 
> put_filp (reduce refcount)
> 
> Table lookup fails->fget fails.
> 
>