All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wen Congyang <wency@cn.fujitsu.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: linux-acpi@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: acpi_memhotplug.c: don't allow to eject the memory device if it is being used
Date: Wed, 07 Nov 2012 09:39:30 +0800	[thread overview]
Message-ID: <5099BBD2.4020003@cn.fujitsu.com> (raw)
In-Reply-To: <20121106140545.GB11566@mwanda>

At 11/06/2012 10:05 PM, Dan Carpenter Wrote:
> On Tue, Nov 06, 2012 at 10:10:11AM +0800, Wen Congyang wrote:
>> At 11/06/2012 02:11 AM, Dan Carpenter Wrote:
>>> Hello Wen Congyang,
>>>
>>> The patch 306859f13dc1: "acpi_memhotplug.c: don't allow to eject the
>>> memory device if it is being used" from Nov 3, 2012, leads to the
>>> following Smatch warning:
>>> drivers/acpi/acpi_memhotplug.c:367 acpi_memory_remove_memory()
>>> 	 warn: inconsistent returns mutex:&mem_device->list_lock:
>>> 	locked (357,361) unlocked (367)
>>
>> Thanks for pointing it out.
>>
>> The patch 306859f13dc1 is in akpm's tree, and it conflicts with another
>> patch in linux-pm's tree. So Andrew Morton drops them.
>>
>> I will resend them based on linux-pm's next tree.
> 
> Ok. Today's linux-next version 85fcb3758c10e "ACPI / memory-hotplug:
> introduce a mutex lock to protect the list in acpi_memory_device"
> has a similar problem and should be fixed as well.
> 
>    319  static int acpi_memory_remove_memory(struct acpi_memory_device *mem_device)
>    320  {
>    321          int result;
>    322          struct acpi_memory_info *info, *n;
>    323  
>    324          mutex_lock(&mem_device->list_lock);
>    325          list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
>    326                  if (info->enabled) {
>    327                          result = remove_memory(info->start_addr, info->length);
>    328                          if (result)
>    329                                  return result;
>                                         ^^^^^^^^^^^^^
> We are still holding the lock here.

Yes, I found this problem.

Thanks
Wen Congyang

> 
>    330                  }
>    331  
>    332                  list_del(&info->list);
>    333                  kfree(info);
>    334          }
>    335          mutex_unlock(&mem_device->list_lock);
>    336  
>    337          return 0;
>    338  }
> 
> regards,
> dan carpenter
> 
> 


  reply	other threads:[~2012-11-07  1:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 18:11 acpi_memhotplug.c: don't allow to eject the memory device if it is being used Dan Carpenter
2012-11-06  2:10 ` Wen Congyang
2012-11-06 14:05   ` Dan Carpenter
2012-11-07  1:39     ` Wen Congyang [this message]
2012-11-08  9:33     ` Wen Congyang
2012-11-08  9:58       ` Rafael J. Wysocki
2012-11-08 10:03         ` Wen Congyang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5099BBD2.4020003@cn.fujitsu.com \
    --to=wency@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.