linux-kernel - Questions about Exportfs / kernel nfs server / dentrys (2.6.9)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <35a82d00609151147q1157343bg1e3ddbdf264119b7@mail.gmail.com>
Date:	Fri, 15 Sep 2006 11:47:15 -0700
From:	"Scott Baker" <smbaker@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Questions about Exportfs / kernel nfs server / dentrys (2.6.9)

Hello,

I'm trying to understand some code in exportfs. The particular code is
in find_exported_dentry. Here is some pseudocode from
find_exported_dentry. I've stripped out the error-checking code and
included invariants that describe what I believe is going on.

INPUT: struct dentry *pd
/* struct dentry *pd is a disconnected dentry that we want to connect.
* it was probably created with d_alloc_anon. Note that IS_ROOT(pd)
* is TRUE.
*/

/* call export ops to get parent of pd */
ppd = CALL(nops, get_parent)(pd);

/* call export ops to get name of pd */
CALL(nops, get_name)(ppd, nbuf, pd)

/* perform a lookup using the name we received. We know that pd is a
* child of ppd, and we know that pd's name is 'nbuf', so the lookup
* should succeed and return us a non-anonymous dentry.
*/
npd = lookup_one_len(nbuf, ppd, strlen(nbuf));
/* In my test run, pd != ndp. This is because pd is an anonymous dentry
* and npd is a non-anonymous one, containing a name. Code comments
* say this is alright.
*/

if (IS_ROOT(pd)) {
     /* something went wrong, we have to give up */
    break;
}

The function is failing for me on that last IS_ROOT check in the if
statement. What I'm confused about is when was pd supposed to have
gone from unconnected to connected? In my test runs, npd is connected
but pd is not. They both have the same inode number. They both point
to the same inode.

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