linux-kernel - Re: [GIT PULL] notification tree - fsnotify assumes incorrectly positive parent dentry

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:	Tue, 30 Jun 2009 08:46:29 +0800
From:	Jeremy Kerr <jk@...abs.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Eric Paris <eparis@...hat.com>, Al Viro <viro@...iv.linux.org.uk>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] notification tree - fsnotify assumes incorrectly positive parent dentry

Linus,

> Hmm. It does sound like a reasonable assumption, though. Maybe spufs
> should be fixed to have an inode for all directories?

We have inodes for all directories, it's just the order which we set 
things up. When a new 'spu context' (ie, a directory with a bunch of 
files) is created, we add the parent dentry, populate it with files 
(positive dentries), then instantiate the parent.

There's no specific need to do it in this order, it just makes the code 
a little simpler - we just 'stitch the parent in' once everything else 
has completed successfully, so less stuff to do in the error path.

> A NULL d_inode means that something is a negative dentry, and a
> negative dentry shouldn't have children.

OK. If this is a general invariant, then I'll get a change to spufs 
going to do the setup in the right order.

Cheers,

Jeremy
--
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/