lkml.org 
[lkml]   [2013]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] pci-sysfs: replace mutex_lock with mutex_trylock to avoid potential deadlock situation
On Fri, Jan 25, 2013 at 11:57 AM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Fri, Jan 25, 2013 at 9:44 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> [+cc Yinghai]
>>
>> On Fri, Jan 25, 2013 at 3:02 AM, Gu Zheng
>
> Hi, Gu,
>
> Can you check if two patches in
>
> http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-pci-root-bus-hotplug-part3
>
> could solve your problem?
>
> http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=277df390baeab7ba6aa136356b677a096c890c0c
>
> PCI: Rescan bus using callback method too
>
>
> http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=282e2db3b58d56b5236ee755e1527574df0d298e
>
> PCI, sysfs: Clean up rescan/remove with scheule_callback

You ignored and clipped my concerns about similar synchronization
issues outside sysfs, so let me quote it again here:

I'm sorry that you tripped over this deadlock, because now I'm worried
about related locking issues outside sysfs :) The mutex you're
fiddling with is only in sysfs, but the routines *protected* by that
mutex are used in other places, too. So what happens when a hotplug
driver does a rescan at the same time a user does a rescan or remove
via sysfs? I don't even know what the rules are for protecting
scan/remove, but I don't have confidence that the issue you're fixing
is the only one.

If we're going to fix the sysfs deadlock (and we should), I want to
either see an argument for why we don't have a problem outside of
sysfs, or I want to fix sysfs and non-sysfs at the same time.

Bjorn


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