linux-kernel - Re: [GIT PULL] Driver core fix for 4.5-rc4

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:	Sun, 14 Feb 2016 13:33:18 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senpartnership.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Driver core fix for 4.5-rc4

On Sun, Feb 14, 2016 at 1:21 PM, James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> This means that when you pass an object to a caller(in this case, the
> bus_find_device), you pass it with an incremented refcount on the
> embedding object, which is what the caller cares about.  What happens
> to the klist_node is entirely internal to the callee subsystem.  So you
> never have to worry about the klist_node being freed, because it's
> embedded in the object the caller holds a reference to and thus can't
> be freed.

So in this case I didn't actually look at the caller, my reaction was
more to the klist code itself - it doesn't seem to use that
kref_get_unless_zero()" model anywhere else. So the new code just
looked a bit out-of-place which in turn made me worry.

As long as there's a reference there that means that things can't go
away, I guess I'm happy.

> Yes, that looks fine too.  I was basically assuming the compiler would
> optimise away the double setting of i->i_cur.

Usually the compiler won't be able to. Things like
"kref_get_unless_zero()" end up using ordered atomic ops (ie there's a
memory clobber in there), and gcc will do "I had better make sure
everything written to memory is up-to-date because now we're going
atomics".

So even when things are inlined and gcc sees everything and could in
theory move things around, doing so around atomics and reference
counts is not going to happen (and would be very much not ok - think
about the compiler starting to reorder memory accesses around people
doing things like that, and shudder).

                  Linus