lkml.org 
[lkml]   [2013]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 04/10] PCI: Destroy pci dev only once
Date
On Saturday, November 30, 2013 12:38:26 AM Rafael J. Wysocki wrote:
> On Tuesday, November 26, 2013 06:26:54 PM Yinghai Lu wrote:
> > On Tue, Nov 26, 2013 at 5:24 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >
> > > So assume pci_destroy_dev() is called twice in parallel for the same dev
> > > by two different threads. Thread 1 does the atomic_inc_and_test() and
> > > finds that it is OK to do the device_del() and put_device() which causes
> > > the device object to be freed. Then thread 2 does the atomic_inc_and_test()
> > > on the already freed device object and crashes the kernel.
> > >
> > thread2 should still hold one extra reference.
> > that is in
> > device_schedule_callback
> > ==> sysfs_schedule_callback
> > ==> kobject_get(kobj)
> >
> > pci_destroy_dev for thread2 is called at this point.
> >
> > and that reference will be released from
> > sysfs_schedule_callback
> > ==> kobject_put()...
>
> Well, that would be the case if thread 2 was started by device_schedule_callback(),
> but again, for example, it may be trim_stale_devices() started by acpiphp_check_bridge()
> that doesn't hold extra references to the pci_dev. [Well, that piece of code
> is racy anyway, because it walks bus->devices without locking. Which is my
> fault too, because I overlooked that. Shame, shame.]
>
> Perhaps we can do something like the (untested) patch below (in addition to the
> $subject patch). Do you see any immediate problems with it?

Ah, I see one. It will break pci_stop_bus_device() and pci_remove_bus_device().
So much for being clever.

Moreover, it looks like those two routines above are racy too for the same
reason?

Rafael



\
 
 \ /
  Last update: 2013-11-30 01:01    [W:0.084 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site