linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Brian King <brking@linux.vnet.ibm.com>
To: Nathan Fontenot <nfont@austin.ibm.com>
Cc: linuxppc-dev@ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] Split the memory_block structure
Date: Tue, 13 Jul 2010 09:00:44 -0500	[thread overview]
Message-ID: <4C3C718C.6080402@linux.vnet.ibm.com> (raw)
In-Reply-To: <4C3B37CE.50802@austin.ibm.com>

On 07/12/2010 10:42 AM, Nathan Fontenot wrote:
> @@ -123,13 +130,20 @@
>  static ssize_t show_mem_removable(struct sys_device *dev,
>  			struct sysdev_attribute *attr, char *buf)
>  {
> -	unsigned long start_pfn;
> -	int ret;
> -	struct memory_block *mem =
> -		container_of(dev, struct memory_block, sysdev);
> +	struct list_head *pos, *tmp;
> +	struct memory_block *mem;
> +	int ret = 1;
> +
> +	mem = container_of(dev, struct memory_block, sysdev);
> +	list_for_each_safe(pos, tmp, &mem->sections) {
> +		struct memory_block_section *mbs;
> +		unsigned long start_pfn;
> +
> +		mbs = list_entry(pos, struct memory_block_section, next);
> +		start_pfn = section_nr_to_pfn(mbs->phys_index);
> +		ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
> +	}

I don't see you deleting anyting from the list in this loop. Why do you need
to use list_for_each_safe? That won't protect you if someone else is messing
with the list.

> 
> -	start_pfn = section_nr_to_pfn(mem->phys_index);
> -	ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>  	return sprintf(buf, "%d\n", ret);
>  }
> 


> @@ -238,19 +252,40 @@
>  static int memory_block_change_state(struct memory_block *mem,
>  		unsigned long to_state, unsigned long from_state_req)
>  {
> +	struct memory_block_section *mbs;
> +	struct list_head *pos;
>  	int ret = 0;
> +
>  	mutex_lock(&mem->state_mutex);
> 
> -	if (mem->state != from_state_req) {
> -		ret = -EINVAL;
> -		goto out;
> +	list_for_each(pos, &mem->sections) {
> +		mbs = list_entry(pos, struct memory_block_section, next);
> +
> +		if (mbs->state != from_state_req)
> +			continue;
> +
> +		ret = memory_block_action(mbs, to_state);
> +		if (ret)
> +			break;
> +	}

Would it be better here to loop through all the sections and ensure they
are in the proper state first before starting to change the state of any
of them? Then you could easily return -EINVAL if one or more is in
the incorrect state and wouldn't need to the code below.

> +	if (ret) {
> +		list_for_each(pos, &mem->sections) {
> +			mbs = list_entry(pos, struct memory_block_section,
> +					 next);
> +
> +			if (mbs->state == from_state_req)
> +				continue;
> +
> +			if (memory_block_action(mbs, to_state))
> +				printk(KERN_ERR "Could not re-enable memory "
> +				       "section %lx\n", mbs->phys_index);
> +		}
>  	}
> 
> -	ret = memory_block_action(mem, to_state);
>  	if (!ret)
>  		mem->state = to_state;
> 
> -out:
>  	mutex_unlock(&mem->state_mutex);
>  	return ret;
>  }


> @@ -498,19 +496,97 @@
> 
>  	return mem;
>  }
> +static int add_mem_block_section(struct memory_block *mem,
> +				 int section_nr, unsigned long state)
> +{
> +	struct memory_block_section *mbs;
> +
> +	mbs = kzalloc(sizeof(*mbs), GFP_KERNEL);
> +	if (!mbs)
> +		return -ENOMEM;
> +
> +	mbs->phys_index = section_nr;
> +	mbs->state = state;
> +
> +	list_add(&mbs->next, &mem->sections);

I don't think there is sufficient protection for this list. Don't we
need to be holding a lock of some sort when adding/deleting/iterating
through this list? 

> +	return 0;
> +}

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center

  parent reply	other threads:[~2010-07-13 14:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 15:27 [PATCH 0/7] De-couple sysfs memory directories from memory sections Nathan Fontenot
2010-07-12 15:42 ` [PATCH 1/7] Split the memory_block structure Nathan Fontenot
2010-07-13  6:18   ` KAMEZAWA Hiroyuki
2010-07-13 15:44     ` Nathan Fontenot
2010-07-13 14:00   ` Brian King [this message]
2010-07-13 15:59     ` Nathan Fontenot
2010-07-12 15:43 ` [PATCH 2/7] Create the new 'end_phys_index' file Nathan Fontenot
2010-07-12 15:44 ` [PATCH 3/7] Update the [register,unregister]_memory routines Nathan Fontenot
2010-07-13  6:20   ` KAMEZAWA Hiroyuki
2010-07-13 15:46     ` Nathan Fontenot
2010-07-12 15:45 ` [PATCH 4/7] Allow sysfs memory directories to be split Nathan Fontenot
2010-07-13  6:28   ` KAMEZAWA Hiroyuki
2010-07-13 15:51     ` Nathan Fontenot
2010-07-14  0:35       ` KAMEZAWA Hiroyuki
2010-07-14  3:18         ` Nathan Fontenot
2010-07-14  3:25           ` KAMEZAWA Hiroyuki
2010-07-14  8:30             ` KAMEZAWA Hiroyuki
2010-07-14  3:26         ` Dave Hansen
2010-07-14 17:16           ` Nathan Fontenot
2010-07-12 15:46 ` [PATCH 5/7] update the mutex name in the memory_block struct Nathan Fontenot
2010-07-12 15:47 ` [PATCH 6/7] Update sysfs node routines for new sysfs memory directories Nathan Fontenot
2010-07-12 15:48 ` [PATCH 7/7] Enable multiple memory sections per sysfs memory directory for powerpc/pseries Nathan Fontenot
2010-07-16  7:13 ` [PATCH 0/7] De-couple sysfs memory directories from memory sections Greg KH
2010-07-16 15:41   ` Nathan Fontenot

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=4C3C718C.6080402@linux.vnet.ibm.com \
    --to=brking@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nfont@austin.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).