Re: kern/46990: tmpfs_gro_genealogy() panic - rename/rmdir race condition not handled

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

The following reply was made to PR kern/46990; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost,
        Wolfgang.Stukenbrock%nagler-company.com@localhost
Cc: 
Subject: Re: kern/46990: tmpfs_gro_genealogy() panic - rename/rmdir race 
condition not handled
Date: Thu, 20 Sep 2012 15:39:56 +0000

    Date: Thu, 20 Sep 2012 14:50:01 +0000
    From: Wolfgang.Stukenbrock%nagler-company.com@localhost
 
    The comment in tmpfs_rename.c tmpfs_gro_genealogy() that dnode may
    not be NULL is simply not true. Need to check if dnode is NULL and
    return an error (e.g. ENOENT) instead.
 
 I'm not sure this analysis is correct.  If tmpfs_rmdired_p(vp) is
 false, then VP_TO_TMPFS_NODE(vp)->tn_spec.tn_dir.tn_parent is
 guaranteed to be nonnull, provided that vp is locked.  Can you enable
 DIAGNOSTIC and see what earlier kassert fires?  Also, have you
 reproduced the problem in HEAD too?
 
 I suspect that this not a rename locking issue in particular so much
 as tmpfs locking issue in general -- if I recall correctly, after
 netbsd-5, rmind rototilled the tmpfs locking some time before I
 committed changes to fix tmpfs_rename last year.
 
 Can we see your patches to back-port tmpfs_rename?