linux-kernel - Re: RFC: PNP: do not stop/start devices in suspend/resume path

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: <20071205185012.GA27526@parisc-linux.org>
Date:	Wed, 5 Dec 2007 11:50:13 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Jiri Slaby <jirislaby@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pm@...ts.linux-foundation.org, drzeus@...eus.cx,
	linux-acpi@...r.kernel.org, Adam Belay <ambx1@....rr.com>,
	Matthieu Castet <castet.matthieu@...e.fr>,
	Li Shaohua <shaohua.li@...el.com>, Len Brown <lenb@...nel.org>
Subject: Re: RFC: PNP: do not stop/start devices in suspend/resume path

On Wed, Dec 05, 2007 at 11:24:18AM -0700, Bjorn Helgaas wrote:
> This means we will not disable the device and release its
> resources.  The driver suspend method typically does not release
> its resources in the suspend path.  For example, if we have:
> 
>   03f8-03ff : 00:06
>     03f8-03ff : serial
> 
> pnp_stop_dev() would release the 00:06 region, which still
> has a child.  This causes a warning from __release_resource
> and corrupts /proc/ioports.

So, I put the warning in there because I genuinely didn't know if we
were doing this, and if so what the semantics should be.

I'm quite happy to see resources with children being released -- I just
want to know what we should do with those children.  As the first person
to come across this problem, I think you get to decide the semantics.

It seems to me from this description that all we want to do is reparent
the children -- which is easy enough to do; just a matter of twizzling
all the ->parent pointers of the children; the ->sibling of the resource
before the one being released and the ->sibling of the last child of the
one being released.

If you think it's a genuine bug that happens to have been caught by this
check, I'm happy to see the check being useful, and we don't need to
allow the removal of resources.

The only thing is, if you're going to be re-acquiring these resources
upon resume, you'll need to use insert_resource() instead of
request_region() because the child will now be in that spot.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/