linux-kernel - Re: [RFC PATCH] memory driver: make phys_index/end_phys_index reflect the start/end section number

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:	Tue, 08 Apr 2014 16:27:39 +0800
From:	Li Zhong <zhong@...ux.vnet.ibm.com>
To:	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, nfont@...ux.vnet.ibm.com,
	gregkh@...uxfoundation.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Dave Hansen <dave.hansen@...el.com>,
	Zhang Yanfei <zhangyanfei@...fujitsu.com>
Subject: Re: [RFC PATCH] memory driver: make phys_index/end_phys_index
 reflect the start/end section number

On Fri, 2014-04-04 at 10:29 +0900, Yasuaki Ishimatsu wrote:
> (2014/04/02 17:56), Li Zhong wrote:
> > I noticed the phys_index and end_phys_index under
> > /sys/devices/system/memory/memoryXXX/ have the same value, e.g.
> > (for the test machine, one memory block has 8 sections, that is
> >   sections_per_block equals 8)
> >
> > # cd /sys/devices/system/memory/memory100/
> > # cat phys_index end_phys_index
> > 00000064
> > 00000064
> >
> > Seems they should reflect the start/end section number respectively, which
> > also matches what is said in Documentation/memory-hotplug.txt
> >
> > This patch tries to modify that so the two files could show the start/end
> > section number of the memory block.
> >
> > After this change, output of the above example looks like:
> >
> > # cat phys_index end_phys_index
> > 00000320
> > 00000327
> >
> > Signed-off-by: Li Zhong <zhong@...ux.vnet.ibm.com>
> > ---
> 
> Good catch! This is a bug. So I think the bug should be fixed.
> 
> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>

Thank you all for the review. 

If Dave and others don't have further objections, it seems this small
userspace incompatibility could be accepted by most of us, and I don't
need to make a version 2. 

Thanks, Zhong 

> Thanks,
> Yasuaki Ishimatsu
> 
> >   drivers/base/memory.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> > index bece691..b10f2fa 100644
> > --- a/drivers/base/memory.c
> > +++ b/drivers/base/memory.c
> > @@ -114,7 +114,7 @@ static ssize_t show_mem_start_phys_index(struct device *dev,
> >   	struct memory_block *mem = to_memory_block(dev);
> >   	unsigned long phys_index;
> >
> > -	phys_index = mem->start_section_nr / sections_per_block;
> > +	phys_index = mem->start_section_nr;
> >   	return sprintf(buf, "%08lx\n", phys_index);
> >   }
> >
> > @@ -124,7 +124,7 @@ static ssize_t show_mem_end_phys_index(struct device *dev,
> >   	struct memory_block *mem = to_memory_block(dev);
> >   	unsigned long phys_index;
> >
> > -	phys_index = mem->end_section_nr / sections_per_block;
> > +	phys_index = mem->end_section_nr;
> >   	return sprintf(buf, "%08lx\n", phys_index);
> >   }
> >
> >
> >
> > --
> > 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/
> >
> 
> 
> --
> 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/
> 


--
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/