linux-kernel - Re: vfs-scale, d_revalidate from nfsd

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 15 Jan 2011 12:47:32 +0900
From:	"J. R. Okajima" <hooanon05@...oo.co.jp>
To:	Nick Piggin <npiggin@...il.com>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: vfs-scale, d_revalidate from nfsd


Nick Piggin:
> Of course. I was discussing it with Miklos yesterday too, but haven't
> finished getting a proposal together.
>
> The main idea here would be to just pass in a flags parameter rather
> thank poking in nd to get the rcu-walk status. That would solve this
> problem and also avoid nd for most filesystems that don't care about
> it.

Let me make sure.
- add a flag parameter to ->d_revalidate. not remove the panameter nd.
- FS ->d_revalidate() will (probably) return -ECHILD when LOOKUP_RCU is
  set.
Right?


Then how about the callers?
Current sequence is
- NFSD calls lookup_one_len
- __lookup_hash
- do_revalidate
- d_revalidate
{
	status = dentry->d_op->d_revalidate(dentry, nd);
	if (status == -ECHILD) {
		;;;
		status = dentry->d_op->d_revalidate(dentry, nd);
	}
}

There will be no change in NFSD but VFS d_revalidate(), such like this?
VFS d_revalidate()
{
	if (nd) {
		dentry->d_op->d_revalidate(dentry, nd, nd->flags);
		if (-ECHILD) {
			dentry->d_op->d_revalidate(dentry, nd, nd->flags);
		}
	} else
		return dentry->d_op->d_revalidate(dentry, NULL, 0);
}


J. R. Okajima
--
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/