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]

Message-ID: <BANLkTikUi9M1Mx4L54vJOP0SK0P3yAz=uQ@mail.gmail.com>
Date:	Mon, 20 Jun 2011 09:22:32 -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 Mon, Jun 20, 2011 at 9:13 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Er...  The current mainline does atomic_read() followed by atomic_inc(),
> so we get the same thing (plus the spin_lock()/spin_unlock()), don't we?

Yes. Unless the spinlock is in the same cacheline. No reason not to
fix that, though.

Of course, if the "ETXTBUSY" case is the common case (which I doubt),
then not doing the write at all would be the optimal case. But I doubt
that case is even worth really worrying about ;)

> For get_write_access() it's probably the right assumption for everything but
> /dev/tty*; for deny_write_access() it's not - a lot of binaries are run by
> more than one process...

Note the fact that EVEN IF WE GUESS INCORRECTLY, performance is likely
better by guessing rather than reading, unless you know the thing is
already in the local CPU cache.

Doing the loop twice instead of once is still *much* faster than an
extra cache transaction that goes to the bus (or L3 or whatever).

> FWIW, I wonder what will the things look like on ll/sc architectures;

There are no ll/sc architectures worth worrying about, so I don't
think that's the primary concern.  That said, I don't disagree with
creating a "atomic_inc_unless_negative()" helper.

                     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/