On Mon, Feb 13, 2017 at 06:42:56AM -0500, David Windsor wrote:
I'm not sure this is a sound argument for not converting to
refcount_t.
It's an argument again the way how this patch was sent. Please take care
of all the trivial conversions first, and then do anything non-trivial
on a case by case basis.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 13, 2017 at 7:12 AM, Christoph Hellwig [off-list ref] wrote:
On Mon, Feb 13, 2017 at 06:42:56AM -0500, David Windsor wrote:
quoted
I'm not sure this is a sound argument for not converting to
refcount_t.
It's an argument again the way how this patch was sent. Please take care
of all the trivial conversions first, and then do anything non-trivial
on a case by case basis.
This is actually what we're currently doing.
The vast majority of atomic_t to refcount_t conversions are trivial,
as they most always follow the pattern:
1. Initialize the atomic_t refcounter to 1.
2. Perform shared object get/put operations.
3. Free the shared object when its refcount becomes 0.
We've identified a handful of instances in which steps 1 and 3 are
different from above (i.e. initializing refcounts to 0, freeing
objects when refcount is non-zero, etc.). The above patch addresses
one of these instances in NFS.
Thanks,
David