linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <jhovold@gmail.com>
To: Li Zhong <zhong@linux.vnet.ibm.com>
Cc: Johan Hovold <jhovold@gmail.com>, Tejun Heo <tj@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	rafael.j.wysocki@intel.com
Subject: Re: [PATCH] USB: serial: fix sysfs-attribute removal deadlock
Date: Fri, 25 Apr 2014 12:15:01 +0200	[thread overview]
Message-ID: <20140425101501.GD2206@localhost> (raw)
In-Reply-To: <1398392217.2805.150.camel@ThinkPad-T5421.cn.ibm.com>

On Fri, Apr 25, 2014 at 10:16:57AM +0800, Li Zhong wrote:
> On Thu, 2014-04-24 at 16:52 +0200, Johan Hovold wrote:

> > No, this isn't self removal. The driver-attribute (not device-attribute)
> > store operation simply grabs a lock that is also held while the driver
> > is being deregistered at module unload. Taking a reference to the module
> > in this case will prevent deregistration while store is running.
> > 
> > But it seems like this can be solved for usb-serial by simply not
> > holding the lock while deregistering.
> 
> I didn't look carefully about this lock. 
> 
> But I'm not sure whether there are such requirements for driver
> attributes:
> 
> some lock needs be grabbed in the driver attributes store callbacks, and
> the same lock also needs to be grabbed during driver unregister. 
> 
> If we have such requirements currently or in the future, I think they
> could all be solved by breaking active protection after get the module
> reference.

Yes, if we find any such cases, but I don't think it should be done
generally (as in one of your earlier posts).

Active protection is usually exactly what prevents the driver from being
deregistered, and would only need to be broken to avoid any ABBA
deadlocks from being reported by lockdep (the module reference would be
enough to prevent the actual deadlock).

Thanks,
Johan

  reply	other threads:[~2014-04-25 10:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-23  9:32 [PATCH] USB: serial: fix sysfs-attribute removal deadlock Johan Hovold
2014-04-23 14:19 ` Tejun Heo
2014-04-24  8:29   ` Li Zhong
2014-04-24 14:35     ` Tejun Heo
2014-04-24 14:52       ` Johan Hovold
2014-04-25  2:16         ` Li Zhong
2014-04-25 10:15           ` Johan Hovold [this message]
2014-04-28  0:39             ` Li Zhong
2014-05-02 15:20               ` Tejun Heo
2014-04-25 13:59           ` Alan Stern
2014-04-28  1:58             ` Li Zhong
2014-04-25  2:15       ` Li Zhong
2014-04-25 13:54         ` Alan Stern
2014-04-25 15:13           ` Johan Hovold
2014-04-28  1:55           ` Li Zhong

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=20140425101501.GD2206@localhost \
    --to=jhovold@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    --cc=zhong@linux.vnet.ibm.com \
    /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;
as well as URLs for NNTP newsgroup(s).