All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-pcmcia@lists.infradead.org
Subject: Re: pcmcia: release_class patch concern
Date: Tue, 28 Jun 2005 01:41:00 -0500	[thread overview]
Message-ID: <200506280141.01223.dtor_core@ameritech.net> (raw)
In-Reply-To: <20050628061400.GA9019@isilmar.linta.de>

On Tuesday 28 June 2005 01:14, Dominik Brodowski wrote:
> Hi Dmitry,
> 
> On Mon, Jun 27, 2005 at 11:56:49PM -0500, Dmitry Torokhov wrote:
> > Hi Dominik,
> > 
> > I noticed that Linus committed the patch from you that introduces waiting
> > for completion in module's exit routine. I believe it is a big no-no
> 
> Is it really? Any PCI driver which calls pci_unregister_driver() waits for
> completion (-> driver_unregister() -> wait_for_completion(&drv->unloaded) ).
>

Driver objects don't linger around - teardown is straightforward and
attribute access protected with bumping up module's reference count.
So it usually works out pretty well. 

> 
> > as something like this will wedge the kernel:
> > 
> > 	rmmod <module> < /sys/path/to/devices/attribute
> 
> Why would anybody issue such a command?

This is just the simpliest method to illustrate the problem. I am sure
someone could come up with a more realistic example. I think Al Viro
mentioned it some time ago, but I can't find his post...

> But it even wouldn't succeed, as 
> the module usage count would be >0 if there are attributes below
> /sys/class/pcmcia_socket/
...
> So I could have left the other wait_for_completion out, as it should never
> actually _wait_. Nonethteless, I consider it to be a safeguard.

Since the completion will never be actually used I'd rather not have it
at all - I believe it sets bad example.
 
-- 
Dmitry

      reply	other threads:[~2005-06-28  6:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-28  4:56 pcmcia: release_class patch concern Dmitry Torokhov
2005-06-28  6:14 ` Dominik Brodowski
2005-06-28  6:41   ` Dmitry Torokhov [this message]

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=200506280141.01223.dtor_core@ameritech.net \
    --to=dtor_core@ameritech.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pcmcia@lists.infradead.org \
    --cc=linux@dominikbrodowski.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.