[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    RE: [PATCH][RFC] inode->u.nfs_i allocated separately
From:       Alexander Viro <viro () math ! psu ! edu>
Date:       2001-06-29 19:14:39
[Download RAW message or body]



On Fri, 29 Jun 2001, Lever, Charles wrote:

> the fs-private implementations on these systems allocate the
> in-core vnode struct, and usually allocate the private area
> right off the end of the fs-independent part of the vnode.
> then they plant a pointer in the vnode to the fs-private area.
> 
> so a vnode and it's corresponding fs-private struct are allocated
> at the same time.

Funny... 'cause ffs_vget() on one of "these systems" contains the following:

         * If this MALLOC() is performed after the getnewvnode()
         * it might block, leaving a vnode with a NULL v_data to be
         * found by ffs_sync() if a sync happens to fire right then,
         * which will cause a panic because ffs_sync() blindly
         * dereferences vp->v_data (as well it should).
         */
        MALLOC(ip, struct inode *, sizeof(struct inode), 
            ump->um_malloctype, M_WAITOK);

        /* Allocate a new vnode/inode. */
        error = getnewvnode(VT_UFS, mp, ffs_vnodeop_p, &vp);
        if (error) {
[snip]
                FREE(ip, ump->um_malloctype);
                return (error);
        }
        bzero((caddr_t)ip, sizeof(struct inode));
        /*
         * FFS supports lock sharing in the stack of vnodes
         */
        vp->v_vnlock = &vp->v_lock;
        lockinit(vp->v_vnlock, PINOD, "inode", 0, LK_CANRECURSE);
        vp->v_data = ip;
        ip->i_vnode = vp;

and it sure as hell doesn't look like what you described. Same code is
in ext2_vget(). nfs_vget() got
        /*
         * Allocate before getnewvnode since doing so afterward
         * might cause a bogus v_data pointer to get dereferenced
         * elsewhere if zalloc should block.
         */
        np = zalloc(nfsnode_zone);
                
        error = getnewvnode(VT_NFS, mntp, nfsv2_vnodeop_p, &nvp);
        if (error) {
                if (nfs_node_hash_lock < 0)
                        wakeup(&nfs_node_hash_lock);
                nfs_node_hash_lock = 0;
                *npp = 0;
                zfree(nfsnode_zone, np);
                return (error);
        }
        vp = nvp;
        bzero((caddr_t)np, sizeof *np);
        vp->v_data = np;
        np->n_vnode = vp;
in it.

All on FreeBSD-CURRENT - grep and you'll see. <checks OpenBSD-CURRENT>
Yup, same picture (+ usual set of races, AFAICS).

<checks 4.4BSD-Alpha> Same picture here, so I'd say that all 4.4 derivatives
are likely to share that.

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org

[prev in list] [next in list] [prev in thread] [next in thread]