Re: PUFFS lookup/reclaim race

[David Laight <david%l8s.co.uk@localhost>]

On Fri, Jul 13, 2012 at 12:34:20AM +0000, Emmanuel Dreyfus wrote:
> Hi
> 
> I spend days tracking down a race condition in PUFFS lookup. Here is how it
> fails:
> 
> - vnode V for file F is associated with cookie C
> 
> - enter puffs_vnop_lookup(), looking up file F
> - puffs_vnop_lookup() sends PUFFS_LOOKUP to userland
> - userland finds cookie C for F, sends reply to kernel
> - someone else in kernel do vput(V),  puffs_vnop_reclaim(V) is called
> - puffs_vnop_reclaim(V) sends PUFFS_RECLAIM for C
> - userland reclaim cookie C
> 
> - puffs_vnop_lookup() gets its PUFFS_LOOKUP reply with cookie C
> - puffs_vnop_lookup() calls puffs_cookie2vnode() and do not find a vnode
> - puffs_vnop_lookup() calls puffs_getvnode() and get vnode V from freelist
> - puffs_vnop_lookup() sets V's cookie to C and returns
> 
> Next PUFFS operation on V will crash the filesystem, since C has been 
> reclaimed in userland and is now invalid.
> 
> Understanding how it happens is nice, now the next question is: how
> can I fix it? The only way I can think of is to prevent inactive from
> recycling the vnode if a lookup is in progress anywhere in the filesystem.
> Any better idea?

Reference count the cookie somehow?

Maybe a 3-way handshake somewhere - so userspace doesn't actually free
the cookie until later, you might only need a sequence number for
these requests.

        David

-- 
David Laight: david%l8s.co.uk@localhost