linux-kernel - Re: [RESEND AGAIN][PATCH] pcmcia: move unbind/rebind into dev_pm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1207101010360.1308-100000@iolanthe.rowland.org>
Date:	Tue, 10 Jul 2012 10:20:20 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Christian Lamparter <chunkeey@...glemail.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	<linux-pcmcia@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [RESEND AGAIN][PATCH] pcmcia: move unbind/rebind into
 dev_pm_ops.complete

On Tue, 10 Jul 2012, Christian Lamparter wrote:

> > > So, my question now: Would you accept the pcmcia patch if I add the
> > > "USB: Don't rebind..." as a reference to why the re-add needs to be
> > > done in complete? Or do you think that I should bug the pm people
> > > (and Alan - since he wrote that it is "not allowed") in this case
> > > so I can link their official answer to this patch?
> > 
> > Well I could grab it and give it a little bit of testing in linux-next.
> > But I'd be super-reluctant to send such a patch upstream without
> > detailed input from Alan/Greg/Rafael/Dominik/etc.
> Alright, I've added them in the 'CC'.
> 
> To Alan:
> Can you please tell me, if you (still) know the details why the "re-add"
> is not allowed in _resume callback (see patch message & commit id from
> above: USB: Don't rebind before "complete")?

It's a little complicated.  The basic idea is that the PM core needs to
send suspend and resume messages to every device in the right order,
and it can't do that if new devices are being added at the same time.  
That's one of the main reasons we created the "prepare" and "complete" 
callbacks.

However the situation really isn't quite that rigid.  In particular, 
adding new children during a resume callback shouldn't cause much of
problem because the children don't need to be resumed anyway (since 
they were never suspended).  On the other hand, if you do it you will 
get a dev_warn() from the PM core, something like "parent should not be 
sleeping".

Still, it is considered bad form and should be avoided if possible.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/