Re: Possible bug in ACPI

[Andrew Morton <akpm@osdl.org>]

We appear to have a fatal memory leak in ACPI.  It's a shame this was
known about in the -rc series but not fixed then.

Dalibor, please raise a full and new report at bugzilla.kernel.org.

> On Sat, 2 Dec 2006 21:51:40 +0100 Dalibor Straka <dast@panelnet.cz> wrote:
> On Thu, Nov 09, 2006 at 02:04:16PM -0800, Andrew Morton wrote:
> > 
> > If this bug is still present in 2.6.19-rc5 could you please raise a report
> > at bugzilla.kernel.org?
> > 
> > Thanks.
> > 
> > On Tue, 19 Sep 2006 23:47:24 +0200
> > Dalibor Straka <dast@panelnet.cz> wrote:
> > 
> > > Hello,
> > > 
> > > I am often running out of memory. It looks like an ACPI code is guilty:
> > > dast@lili:~$ grep -i acpi /proc/slabinfo 
> > > Acpi-Operand        3076   3127     64   59    1 : tunables  120   60 8 : slabdata     53     53      0
> > > Acpi-ParseExt         16     59     64   59    1 : tunables  120   60 8 : slabdata      1      1      0
> > > Acpi-Parse            76     92     40   92    1 : tunables  120   60 8 : slabdata      1      1      0
> > > Acpi-State        1644960 1644960     80   48    1 : tunables  120   60 8 : slabdata  34270  34270      0
> > > Acpi-Namespace      1177   1232     32  112    1 : tunables  120   60 8 : slabdata     11     11      0
> > > dast@lili:~$ free
> > > Mem:        899280     892472       6808          0      82212 77936
> > > -/+ buffers/cache:     732324     166956
> > > Swap:      2634620     243052    2404568
> > > dast@lili:~$ uname -a
> > > Linux lili 2.6.18-rc7 #1 SMP Sun Sep 17 15:01:00 CEST 2006 x86_64
> > > 
> > > 
> > > Actualy the Acpi-State's memory is increasing slowly in minutes:
> > > Acpi-State         16176  16176     80   48    1 : tunables  120   60 8 : slabdata    337    337      0
> > > Acpi-State         18816  18816     80   48    1 : tunables  120   60 8 : slabdata    392    392      0
> > > Acpi-State         19200  19200     80   48    1 : tunables  120   60 8 : slabdata    400    400      0
> > > Acpi-State         20160  20160     80   48    1 : tunables  120   60 8 : slabdata    420    420      0
> > > 
> > > I am not familiar with kernel sources, but i can do c pretty well.
> > > BTW: Bios says i have 1024MB, but kernel sees 899MB :-?. The system is
> > > pure HP nx6325. It happens with all the recent kernels .18-rc* .17.* and
> > > debian's distribution 2.6.17-1-amd64-k8-smp.
> > > 
> > > Please Cc: to me, I read lkml only when I have a good mood.
> 
> 
> Hello,
> 
> the bug is present again in 2.6.19 but not in 19-rc5 and not in 19-rc6.
> The only thing changed in drivers/acpi/ is osl.c and procesor_perflib.c.
> --- ./processor_perflib.c       2006-09-20 05:42:06.000000000 +0200
> +++ /usr/src/linux-2.6.19/drivers/acpi/processor_perflib.c
> 2006-12-01 00:34:06.000000000 +0100
> @@ -83,10 +83,8 @@
>                 goto out;
>  
>         ppc = (unsigned int)pr->performance_platform_limit;
> -       if (!ppc)
> -               goto out;
>  
> -       if (ppc > pr->performance->state_count)
> +       if (ppc >= pr->performance->state_count)
>                 goto out;
>  
>         cpufreq_verify_within_limits(policy, 0,
> --- osl.c	2006-12-02 21:40:57.000000000 +0100
> +++ /usr/src/linux-2.6.19-rc6/drivers/acpi/osl.c	2006-11-18 13:38:01.000000000 +0100
> @@ -73,6 +73,7 @@
>  static acpi_osd_handler acpi_irq_handler;
>  static void *acpi_irq_context;
>  static struct workqueue_struct *kacpid_wq;
> +static struct workqueue_struct *kacpi_notify_wq;
>  
>  acpi_status acpi_os_initialize(void)
>  {
> @@ -91,8 +92,9 @@
>  		return AE_NULL_ENTRY;
>  	}
>  	kacpid_wq = create_singlethread_workqueue("kacpid");
> +	kacpi_notify_wq = create_singlethread_workqueue("kacpi_notify");
>  	BUG_ON(!kacpid_wq);
> -
> +	BUG_ON(!kacpi_notify_wq);
>  	return AE_OK;
>  }
>  
> @@ -104,7 +106,7 @@
>  	}
>  
>  	destroy_workqueue(kacpid_wq);
> -	destroy_workqueue(kacpid_notify_wq);
> +	destroy_workqueue(kacpi_notify_wq);
>  
>  	return AE_OK;
>  }
> @@ -567,10 +569,7 @@
>  
>  static void acpi_os_execute_deferred(void *context)
>  {
> -	struct acpi_os_dpc *dpc = NULL;
> -
> -
> -	dpc = (struct acpi_os_dpc *)context;
> +	struct acpi_os_dpc *dpc = (struct acpi_os_dpc *)context;
>  	if (!dpc) {
>  		printk(KERN_ERR PREFIX "Invalid (NULL) context\n");
>  		return;
> @@ -605,14 +604,12 @@
>  	struct acpi_os_dpc *dpc;
>  	struct work_struct *task;
>  
> -	ACPI_FUNCTION_TRACE("os_queue_for_execution");
> -
>  	ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
>  			  "Scheduling function [%p(%p)] for deferred execution.\n",
>  			  function, context));
>  
>  	if (!function)
> -		return_ACPI_STATUS(AE_BAD_PARAMETER);
> +		return AE_BAD_PARAMETER;
>  
>  	/*
>  	 * Allocate/initialize DPC structure.  Note that this memory will be
> @@ -625,26 +622,20 @@
>  	 * from the same memory.
>  	 */
>  
> -	dpc =
> -	    kmalloc(sizeof(struct acpi_os_dpc) + sizeof(struct work_struct),
> -		    GFP_ATOMIC);
> +	dpc = kmalloc(sizeof(struct acpi_os_dpc) +
> +			sizeof(struct work_struct), GFP_ATOMIC);
>  	if (!dpc)
> -		return_ACPI_STATUS(AE_NO_MEMORY);
> -
> +		return AE_NO_MEMORY;
>  	dpc->function = function;
>  	dpc->context = context;
> -
>  	task = (void *)(dpc + 1);
>  	INIT_WORK(task, acpi_os_execute_deferred, (void *)dpc);
> -
> -	if (!queue_work(kacpid_wq, task)) {
> -		ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
> -				  "Call to queue_work() failed.\n"));
> -		kfree(dpc);
> +	if (!queue_work((type == OSL_NOTIFY_HANDLER)?
> +			kacpi_notify_wq : kacpid_wq, task)) {
>  		status = AE_ERROR;
> +		kfree(dpc);
>  	}
> -
> -	return_ACPI_STATUS(status);
> +	return status;
>  }
>  
>  EXPORT_SYMBOL(acpi_os_execute);