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, 16 May 2015 01:10:27 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Dave Chinner <david@...morbit.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Neil Brown <neilb@...e.de>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU
 symlinks

On Sat, May 16, 2015 at 09:38:08AM +1000, Dave Chinner wrote:

> > Both readdir() and path component lookup are technically read
> > operations, so why the hell do we use a mutex, rather than just
> > get a read-write lock for reading? Yeah, it's that (d) above. I
> > might trust xfs and ext4 to get their internal exclusions for
> > allocations etc right when called concurrently for the same
> > directory. But the others?
> 
> They just use a write lock for everything and *nothing changes* -
> this is a simple problem to solve.
> 
> The argument "filesystem developers are stupid" is not a
> compelling argument against changing locking. You're just being
> insulting, even though you probably don't realise it.

Er...  Remember the clusterfuck around the ->i_size and alignment
checks on XFS DIO writes?  Just this cycle.  Correctness of XFS
locking is nothing to boast about - it *is* convoluted as hell and you
guys are not superhuman enough to reliably spot the problems in that nest
of horrors.  Nobody is.

PS: I've no idea whether I'm being insulting or not and frankly, I don't give
a damn; unlike Linus I hadn't signed off on the "code of conflict" nonsense.
Anyone who feels like complaining is quite welcome to it.
--
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