Linux wireless drivers development
 help / color / mirror / Atom feed
From: Maxime Bizon <mbizon@freebox.fr>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linux-wireless@vger.kernel.org, Johannes Berg <johannes.berg@intel.com>
Subject: Re: [PATCH] cfg80211: fix potential deadlock regression
Date: Wed, 28 Aug 2013 21:49:49 +0200	[thread overview]
Message-ID: <1377719389.559.9.camel@sakura.staff.proxad.net> (raw)
In-Reply-To: <1370377370-23055-1-git-send-email-johannes@sipsolutions.net>


On Tue, 2013-06-04 at 22:22 +0200, Johannes Berg wrote:
 
> -	rtnl_lock();
>  
>  	res = device_add(&rdev->wiphy.dev);
> +	if (res)
> +		return res;

I just ran across a regression caused by this commit

I'm again getting uevent notifications for wireless devices that are not
yet properly registered (ENODEV on NL80211 when using sysfs phy id)

I originally  fixed the bug by taking the cfg80211 mutex across the
whole registration:

commit 5a652052fedbd7869572c757dd2ffc2ed420c69d
Author: Maxime Bizon <mbizon@freebox.fr>
Date:   Wed Jul 21 17:21:38 2010 +0200

    cfg80211: fix race between sysfs and cfg80211
    
    device_add() is called before adding the phy to the cfg80211 device
    list.
    
    So if a userspace program uses sysfs uevents to detect new phy
    devices, and queries nl80211 to get phy info, it can get ENODEV even
    though the phy exists in sysfs.
    
    An easy workaround is to hold the cfg80211 mutex until the phy is
    present in sysfs/cfg80211/debugfs.


It does not seem we can reverse the rfkill_register() and device_add()
because wiphy dev is a parent of rfkill dev.

any idea to fix this ?

Thanks,

-- 
Maxime



  reply	other threads:[~2013-08-28 19:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-04 20:22 [PATCH] cfg80211: fix potential deadlock regression Johannes Berg
2013-08-28 19:49 ` Maxime Bizon [this message]
2013-08-30 12:23   ` Johannes Berg
2013-09-02 10:26     ` Maxime Bizon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1377719389.559.9.camel@sakura.staff.proxad.net \
    --to=mbizon@freebox.fr \
    --cc=johannes.berg@intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox