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]
Message-ID: <20100812215246.GK31363@ZenIV.linux.org.uk>
Date:	Thu, 12 Aug 2010 22:52:46 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Takashi Iwai <tiwai@...e.de>, Eric Paris <eparis@...hat.com>,
	Jiri Slaby <jirislaby@...il.com>,
	Pekka Enberg <penberg@...nel.org>,
	Thomas Meyer <thomas@...3r.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.36: Sound stop working

On Thu, Aug 12, 2010 at 02:41:51PM -0700, Linus Torvalds wrote:

> Yeah. The f_count stuff is disgusting. This revert patch makes things
> work for me again. And I suspect it's the right thing to do
> regardless. I reacted to that ugly __fput() hackery when I pulled the
> fanotify tree, but I let it slide. I clearly should have let my taste
> guide me more.
> 
> fsnotify playing games with fput/fget is almost certainly totally wrong.
> 
> Al, what was the problem that caused you to think that we want to have
> a 'struct file' here? Is it just the fact that some of those fsnotify
> things use that 'path' structure that is embedded in the parent? But
> isn't the simplest fix for that to just _copy_ the "struct path"
> rather than pass the "struct file" around?

I agree that what this crap is doing to f_count is blatantly wrong,
of course - no arguments here.  I *do* have a reason to want struct
file, but not that way, TYVM.

Basically, dentry_open() is not even promised to work on arbitrary
dentry.  Thanks to !@#!@#!@#!@# intents crap we are not promised
that the damn thing won't need setup by ->lookup/->d_revalidate.
We _are_ more or less promised that it'll work while the file is
opened (provided that /proc/*/fd/* is openable), but that's it.

It's not an API that can be made to work on an arbitrary dentries.  If
caller knows what it's dealing with, it's OK, but not in general.  And
no, I'm not fond of that situation, to put it mildly.

I'll see what can be done to fix that mess more or less right way...
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ