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

[Linus Torvalds]

On Sun, Feb 14, 2016 at 1:21 PM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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