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

[Christoph Lameter <clameter@sgi.com>]

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.

> 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.

> 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. 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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/