linux-kernel - Re: [RFC] get_write_access()/deny_write_access() without inode->i

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:	Mon, 20 Jun 2011 08:55:38 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] get_write_access()/deny_write_access() without inode->i_lock

On Sun, Jun 19, 2011 at 4:51 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>        I'm seriously tempted to throw away i_lock uses in
> {get,deny}_write_access(), as in the patch below.  The question is, how
> badly will it suck on various architectures?  I'd expect it to be not
> worse than the current version, but...

It might be worse, because doing a read-before-write can turn a single
cache operation ("get for write") into multiple cache operations ("get
for read" followed by "make exclusive").

We had that exact issue with some other users of the "read + cmpxchg" model.

The way we fixed it before was to simply omit the read, and turn that
into a "guess".

In other words, I'd suggest you get rid of the "atomic_read()"
entirely, and just assume that the write counter was zero to begin
with. Even if that is a wrong assumption (and it probably isn't all
that wrong), it can actually be more efficient to essentiall go
through the loop twice: the first time yoou use the cmpxchg as just an
odd way to do a read. It basically bcomes a read-with-write-intent,
and solves the cacheline issue.

At that point, it's likely faster in pretty much all cases except for
UP (where the spinlocks just go away, and "cmpxchg" is slower than
normal code).

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