uevent / call_usermoderrelated breakage on suspend to disk [Was: Re: PCMCIA-related breakage on suspend to disk]

[Dominik Brodowski]

Hi,

On Tue, Dec 20, 2005 at 11:53:31AM -0800, Patrick Mochel wrote:
> > Hi,
> >
> > No, it doesn't seem so...
> >
> > The actual hang appears in this call trace (many functions left out...)
> >
> > drivers/pcmcia/cs.c:	socket_resume
> > drivers/pcmcia/cs.c:	socket_insert
> > drivers/pcmcia/cs.c:	pcmcia_device_add
> > drivers/base/core.c:	device_register
> > drivers/base/core.c:	device_add
> > 		(additional info:
> > 			if ((error = device_pm_add(dev)))
> > 		 is never reached, as the pr_debug() didn't show up...)
> > lib/kobject_uevent.c:	kobject_hotplug
> >
> > 	pr_debug ("%s: %s %s seq=%llu %s %s %s %s %s\n",
> > 		  __FUNCTION__, argv[0], argv[1], (unsigned long long)seq,
> > 		  envp[0], envp[1], envp[2], envp[3], envp[4]);
> >
> > 	is still shown, it then hangs either in
> >
> > --->	send_uevent(action_string, kobj_path, envp, GFP_KERNEL);
> >
> > 	or
> >
> > --->	retval = call_usermodehelper (argv[0], argv, envp, 0);
> >
> >
> > What to do?
> > a) fix send_uevent or call_usermodehelper to not lock up in the
> > 	resume-when-suspending-to-disk-path
> > b) make device_add fail if in
> > 	resume-when-suspending-to-disk-path
> > c) disable device-adding in drivers/pcmcia/cs.c:socket_resume() if in
> > 	resume-when-suspending-to-disk-path
> 
> I think that (c) is the best approach. If it can happen in the subsystems,
> that's great, though perhaps there is core infrastructure that must be in
> place for it to work in general..

Unfortunately, the PCMCIA subsystem doesn't know enough -- AFAICS there is
no system-wide flag which yells "we're just waking up to store the image to
disk, don't worry!" -- which is exactly which we'd need here...

> We (the core) should resume all devices that are present, then discard all
> devices that have data structures but are not present, then add all new
> devices.

Uh, I do not think any new devices should be handled between the snapshot
being taken and the image written to disk. There's just nothing we can do
with them -- we can't inform udev about them, we can't ask userspace to
configure them, we can't even _add_ them to the device tree for the system
will lock...

> Maybe we can eventually do all of those things simultaneously, but I see
> no problem with serializing them, even long-term.

So I'd vote for a) or b), but not adding some special tweak (c) to some
specific subsystem especially exposed to trouble.

Thanks,
	Dominik