spinlock variable protection

spinlock variable protection

[Matwey V. Kornilov]

Hi,

I have the following code

         int ret = 0;
         unsigned long irqflags;

         spin_lock_irqsave(&lock, irqflags);

         //...
         ret = hdl->count;
         //...

         spin_unlock_irqrestore(&lock, irqflags);
         return ret;

I would like to be sure, that ret will not be optimized out. I think 
compiler can convert the code to equivalent:

         unsigned long irqflags;

         spin_lock_irqsave(&lock, irqflags);

         //...
         //...

         spin_unlock_irqrestore(&lock, irqflags);
         return hdl->count;

But this is not what I want, because I use lock to protect hdl and want 
to return hdl->count value as it was in protected section.

spinlock variable protection

[buyitian]

> ? 2015?1?30??20:43?"Matwey V. Kornilov" <matwey.kornilov@gmail.com> ???
> 
> Hi,
> 
> I have the following code
> 
>         int ret = 0;
>         unsigned long irqflags;
> 
>         spin_lock_irqsave(&lock, irqflags);
> 
>         //...
>         ret = hdl->count;
>         //...
> 
>         spin_unlock_irqrestore(&lock, irqflags);
>         return ret;
> 
> I would like to be sure, that ret will not be optimized out. I think 
> compiler can convert the code to equivalent:
> 
>         unsigned long irqflags;
> 
>         spin_lock_irqsave(&lock, irqflags);
> 
>         //...
>         //...
> 
>         spin_unlock_irqrestore(&lock, irqflags);
>         return hdl->count;
> 
> But this is not what I want, because I use lock to protect hdl and want 
> to return hdl->count value as it was in protected section.
> 
> 
Please check the assembly code to double confirm the GCC behavior.
Why will GCC change the order as what you mentioned? Only assembly code can tell you.



> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

spinlock variable protection

[Matwey V. Kornilov]

2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
>>
> Please check the assembly code to double confirm the GCC behavior.
> Why will GCC change the order as what you mentioned? Only assembly code can tell you.

It does not change at the moment. I think it can change it.

Because from line
  ret = hdl->count;
until line
  return ret;
there is no access to either ret or hdl->count. So it is reasonable to
optimizer to think that their values are the same and eliminate
unneeded variable.

-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp://0x2207 at jabber.ru

spinlock variable protection

[Malte Vesper]

Spinlocks imply memory barriers as far as I am aware...

Read here: 
http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1634

On 30/01/15 14:20, Matwey V. Kornilov wrote:
> 2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
>> Please check the assembly code to double confirm the GCC behavior.
>> Why will GCC change the order as what you mentioned? Only assembly code can tell you.
> It does not change at the moment. I think it can change it.
>
> Because from line
>    ret = hdl->count;
> until line
>    return ret;
> there is no access to either ret or hdl->count. So it is reasonable to
> optimizer to think that their values are the same and eliminate
> unneeded variable.
>

spinlock variable protection

[Matwey V. Kornilov]

Nice, thank you
30.01.2015 18:24 ???????????? "Malte Vesper" <
malte.vesper@postgrad.manchester.ac.uk> ???????:

> Spinlocks imply memory barriers as far as I am aware...
>
> Read here: http://lxr.free-electrons.com/source/Documentation/memory-
> barriers.txt#L1634
>
> On 30/01/15 14:20, Matwey V. Kornilov wrote:
>
>> 2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
>>
>>> Please check the assembly code to double confirm the GCC behavior.
>>> Why will GCC change the order as what you mentioned? Only assembly code
>>> can tell you.
>>>
>> It does not change at the moment. I think it can change it.
>>
>> Because from line
>>    ret = hdl->count;
>> until line
>>    return ret;
>> there is no access to either ret or hdl->count. So it is reasonable to
>> optimizer to think that their values are the same and eliminate
>> unneeded variable.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150130/d9af5564/attachment.html 

spinlock variable protection

[Arun KS]

Hi,

On Fri, Jan 30, 2015 at 8:53 PM, Malte Vesper
<malte.vesper@postgrad.manchester.ac.uk> wrote:
> Spinlocks imply memory barriers as far as I am aware...
>
> Read here:
> http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1634

And may be here aswell,

http://lxr.free-electrons.com/source/Documentation/memory-barriers.txt#L1233

Thanks,
Arun
>
> On 30/01/15 14:20, Matwey V. Kornilov wrote:
>> 2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
>>> Please check the assembly code to double confirm the GCC behavior.
>>> Why will GCC change the order as what you mentioned? Only assembly code can tell you.
>> It does not change at the moment. I think it can change it.
>>
>> Because from line
>>    ret = hdl->count;
>> until line
>>    return ret;
>> there is no access to either ret or hdl->count. So it is reasonable to
>> optimizer to think that their values are the same and eliminate
>> unneeded variable.
>>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

spinlock variable protection

[Nicholas Mc Guire]

On Fri, 30 Jan 2015, Matwey V. Kornilov wrote:

> 2015-01-30 16:52 GMT+03:00 buyitian <buyitian@gmail.com>:
> >>
> > Please check the assembly code to double confirm the GCC behavior.
> > Why will GCC change the order as what you mentioned? Only assembly code can tell you.
> 
> It does not change at the moment. I think it can change it.
> 
> Because from line
>   ret = hdl->count;
> until line
>   return ret;
> there is no access to either ret or hdl->count. So it is reasonable to
> optimizer to think that their values are the same and eliminate
> unneeded variable.
>
If your worry is that it will optimize it out then pack it into
an ACCESS_ONCE and that should prevent GCC from doing so.
for your case I think ret = ACCESS_ONCE(hdl->count);
would be sufficient.

thx!
hofrat