linux-kernel - Re: WARNING: at kernel/resource.c:189 __release

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]

Date:	Sat, 01 Dec 2007 13:00:34 +0100
From:	Jiri Slaby <jirislaby@...il.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	<drzeus@...eus.cx>
Subject: Re: WARNING: at kernel/resource.c:189 __release_resource

On 12/01/2007 09:12 AM, Jiri Slaby wrote:
> On 11/30/2007 11:58 PM, Bjorn Helgaas wrote:
>> On Friday 30 November 2007 03:49:55 pm Jiri Slaby wrote:
>>> On 11/30/2007 10:08 PM, Bjorn Helgaas wrote:
>>>> On Thursday 29 November 2007 05:42:07 pm Andrew Morton wrote:
>>>>> On Thu, 29 Nov 2007 16:40:37 -0700
>>>>>> Maybe we could either remove the pnp_{stop,start}_dev() calls
>>>>>> from the suspend/resume path, or move the PNP resource management
>>>>>> out of pnp_{start,stop}_dev().
>>>>>>
>>>>>> Bjorn
>>>>>>
>>>>>> [1] http://lkml.org/lkml/2005/11/30/39
>>>>> So was this particular problem caused/exposed by
>>>>> pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch,
>>>>> or is
>>>>> it in mainline?
>>>> I'm pretty sure this problem is caused by that patch, so we
>>>> we shouldn't see this in mainline.
>>>>
>>>> Jiri, can you try the additional patch below, please?
>>>>
>>>> Index: linux-mm/drivers/pnp/driver.c
>>>> ===================================================================
>>>> --- linux-mm.orig/drivers/pnp/driver.c	2007-11-30
>>>> 13:58:25.000000000 -0700
>>>> +++ linux-mm/drivers/pnp/driver.c	2007-11-30 13:59:37.000000000
>>>> -0700
>>>> @@ -161,13 +161,6 @@
>>>>  			return error;
>>>>  	}
>>>>  
>>>> -	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE) &&
>>>> -	    pnp_can_disable(pnp_dev)) {
>>>> -		error = pnp_stop_dev(pnp_dev);
>>>> -		if (error)
>>>> -			return error;
>>>> -	}
>>>> -
>>>>  	if (pnp_dev->protocol && pnp_dev->protocol->suspend)
>>>>  		pnp_dev->protocol->suspend(pnp_dev, state);
>>>>  	return 0;
>>>> @@ -185,12 +178,6 @@
>>>>  	if (pnp_dev->protocol && pnp_dev->protocol->resume)
>>>>  		pnp_dev->protocol->resume(pnp_dev);
>>>>  
>>>> -	if (!(pnp_drv->flags & PNP_DRIVER_RES_DO_NOT_CHANGE)) {
>>>> -		error = pnp_start_dev(pnp_dev);
>>>> -		if (error)
>>>> -			return error;
>>>> -	}
>>>> -
>>>>  	if (pnp_drv->resume)
>>>>  		return pnp_drv->resume(pnp_dev);
>>>>  
>>> No, it breaks suspend.
>> Thanks for trying it.  What are the symptoms?  I'd like to understand
>> why we need to stop the devices before suspend.
> 
> Ho hum, it's not so easy, it's kind of nondeterministic now. Maybe
> some other
> issue. If I remove 8250* modules from the kernel, it works. Otherwise
> it locks
> in the middle of suspend after disks and graphics go down no matter if
> the patch
> has been applied or not. Trying to investigate this further...

I didn't get it. Maybe some trolls poking around or something (maybe the
ext3 breakage which fsck fixed). It works after recompilation of the
whole tree. And the important part -- the warning has gone. Just a note,
fold this -fix into it:

diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index f5b64ee..b0fc3ee 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -170,7 +170,6 @@ static int pnp_bus_resume(struct device *dev)
 {
 	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
 	struct pnp_driver *pnp_drv = pnp_dev->driver;
-	int error;
 
 	if (!pnp_drv)
 		return 0;
--
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/