lkml.org 
[lkml]   [2014]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH part1 v5 5/7] PCI: Add pci_dummy_ops to isolate pci device temporarily
>>>> +	spin_lock_irqsave(&pci_freeze_lock, flags);
>>>> + ops = pci_bus_set_ops(bus, &pci_dummy_ops);
>>>> + bus->save_ops = ops;
>>>> + spin_unlock_irqrestore(&pci_freeze_lock, flags);
>>>
>>> Against what exactly are you locking here?
>>
>> I want to use this spin lock to serialize freeze device and unfreeze device.
>
> Yes, but against what? I am sorry I should have been more explicit.
> You are using these functions only in pci_scan_single_device()


Hi Oliver, thanks very much for your detailed analysis. My original intention to use
pci_freeze_lock to serialize pci_bus_freeze_device() and pci_bus_unfreeze_device(),
because I think these two functions maybe used in other places, although currently
only used in pci_scan_single_device().
Like:

CPU A CPU B
pci_bus_freeze_device() pci_bus_unfreeze_device()
pci_bus_set_ops(bus, &pci_dummy_ops);
pci_bus_set_ops(bus, bus->save_ops); ---> here, save_ops is NULL, it's bad.
bus->save_ops = ops;


>
>
> CPU A CPU B
> pci_bus_freeze_device() wait
> bus->save_ops = ops {valid} wait
> ... pci_bus_freeze_device()
> wait bus->save_ops = ops
> {pci_dummy_ops !}
> pci_bus_unfreeze_device() wait
> pci_bus_set_ops(bus, bus->save_ops)
>
> You see the problem?
>

Yes, this is a issue, good catch. I should add a refcount to avoid this situation.

> If this function ever races with itself, the locking is useless.
> If it doesn't race with itself, the locking is not needed.
> If this function can really race with itself, you need a refcount
> for freezing.

Thanks again!




>
>
>
> .
>


--
Thanks!
Yijing



\
 
 \ /
  Last update: 2014-02-11 03:21    [W:1.958 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site