mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Manuel Estrada Sainz <ranty@debian.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>,
	Greg KH <greg@kroah.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Patrick Mochel <mochel@osdl.org>
Subject: Re: [2.6 PATCH/RFC] Firmware loader - fix races and resource dealloocation problems
Date: Wed, 31 Dec 2003 23:32:44 +0100	[thread overview]
Message-ID: <20031231223244.GO24577@ranty.pantax.net> (raw)
In-Reply-To: <1072169289.2876.57.camel@pegasus>

On Tue, Dec 23, 2003 at 09:48:09AM +0100, Marcel Holtmann wrote:
> Hi Dmitry,
> 
> > > > It seems that implementation of the firmware loader is racy as it
> > > > relies on kobject hotplug handler. Unfortunately that handler runs
> > > > too early, before firmware class attributes controlling the loading
> > > > process, are created. This causes firmware loading fail at least half
> > > > of the times on my laptop.
> > >
> > > Um, why not have your script wait until the files are present?  That
> > > will remove any race conditions you will have.
> > 
> > How long should the userspace wait? One second as Manuel suggested?
> > Indefinitely? Or should the firmware agent have some timeout? If userspace
> > uses a timeout how should it correlate with the timeout on the kernel side?
> 
> the timeout of the kernel (which can be set from userspace) is for the
> whole firmware loading process. What we talk about is waiting a little
> bit before the files become visible for the firmware.agent.
> 
> > I am sorry but I have to disagree with you. Kernel should not call user
> > space until it has all infrastructure in place and is ready. Anything
> > else is just a sloppy practice.
> 
> The firmware.agent script has 3 extra lines to check for the visibility
> of the "loading" file and if it is not present it will sleep one second.
> This is a actual good practice compared to adding much more code to the
> kernel and have an own way of running hotplug.

 I would say that we will get into this with other issues.

 Maybe some generic mechanism could be implemented to make the hotplug
 event wait for the files.

 The least intrusive solution, although it doesn't sound quite clean could be:

 - Kernel side:
 	- sysfs_hotplug_frezze()
 		- Creates a dummy file /sys/.hotplug_frozen
 	- sysfs_hotplug_thaw()
 		- Removes /sys/.hotplug_frozen
 - Userspace:
	- Main hotplug script waits "while [ -f /sys/.hotplug_frozen ]".

 sysfs_hotplug_[frezze|thaw]() should be treated almost like spinlocks,
 so the system's behabiour doesn't get afected.

 Dmitry's patch is probably cleaner, but since I already had written the
 email when I noticed ...

 Happy new year everyone

 	Manuel
 
	

-- 
--- Manuel Estrada Sainz <ranty@debian.org>
                         <ranty@bigfoot.com>
			 <ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.

  parent reply	other threads:[~2003-12-31 22:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-21  6:37 Dmitry Torokhov
2003-12-22  9:37 ` Greg KH
2003-12-22 23:42   ` Marcel Holtmann
2003-12-23  3:29   ` Dmitry Torokhov
2003-12-23  8:48     ` Marcel Holtmann
2003-12-27  5:29       ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 Dmitry Torokhov
2003-12-27  5:29         ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 (patch 1/2) Dmitry Torokhov
2003-12-27  5:30           ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 (patch 2/2) Dmitry Torokhov
2003-12-31 21:31             ` Greg KH
2003-12-31 22:16           ` [2.6 PATCH/RFC] Firmware loader fixes - take 2 (patch 1/2) Manuel Estrada Sainz
2003-12-31 22:32       ` Manuel Estrada Sainz [this message]
2003-12-31 23:03         ` [2.6 PATCH/RFC] Firmware loader - fix races and resource dealloocation problems Greg KH
2003-12-22 23:05 ` Manuel Estrada Sainz
2003-12-22 23:22   ` Greg KH
2003-12-26 17:29     ` Manuel Estrada Sainz

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=20031231223244.GO24577@ranty.pantax.net \
    --to=ranty@debian.org \
    --cc=dtor_core@ameritech.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mochel@osdl.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

all inboxes | Powered by JetHome®