linux-kernel - Re: [-mm PATCH] register_memory/unregister

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080213120746.FB76.Y-GOTO@jp.fujitsu.com>
Date:	Wed, 13 Feb 2008 14:09:55 +0900
From:	Yasunori Goto <y-goto@...fujitsu.com>
To:	Dave Hansen <haveblue@...ibm.com>,
	Badari Pulavarty <pbadari@...ibm.com>
Cc:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	lkml <linux-kernel@...r.kernel.org>, greg@...ah.com,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [-mm PATCH] register_memory/unregister_memory clean ups

Thanks Badari-san.

I understand what was occured. :-)

> On Tue, 2008-02-12 at 13:56 -0800, Badari Pulavarty wrote:
> > > > +   /*
> > > > +    * Its ugly, but this is the best I can do - HELP !!
> > > > +    * We don't know where the allocations for section memmap and usemap
> > > > +    * came from. If they are allocated at the boot time, they would come
> > > > +    * from bootmem. If they are added through hot-memory-add they could be
> > > > +    * from sla or vmalloc. If they are allocated as part of hot-mem-add
> > > > +    * free them up properly. If they are allocated at boot, no easy way
> > > > +    * to correctly free them :(
> > > > +    */
> > > > +   if (usemap) {
> > > > +           if (PageSlab(virt_to_page(usemap))) {
> > > > +                   kfree(usemap);
> > > > +                   if (memmap)
> > > > +                           __kfree_section_memmap(memmap, nr_pages);
> > > > +           }
> > > > +   }
> > > > +}
> > > 
> > > Do what we did with the memmap and store some of its origination
> > > information in the low bits.
> > 
> > Hmm. my understand of memmap is limited. Can you help me out here ?
> 
> Never mind.  That was a bad suggestion.  I do think it would be a good
> idea to mark the 'struct page' of ever page we use as bootmem in some
> way.  Perhaps page->private? 

I agree. page->private is not used by bootmem allocator.

I would like to mark not only memmap but also pgdat (and so on)
for next step. It will be necessary for removing whole node. :-)


>  Otherwise, you can simply try all of the
> possibilities and consider the remainder bootmem.  Did you ever find out
> if we properly initialize the bootmem 'struct page's?
> 
> Please have mercy and put this in a helper, first of all.
> 
> static void free_usemap(unsigned long *usemap)
> {
> 	if (!usemap_
> 		return;
> 
> 	if (PageSlab(virt_to_page(usemap))) {
> 		kfree(usemap)
> 	} else if (is_vmalloc_addr(usemap)) {
> 		vfree(usemap);
> 	} else {
> 		int nid = page_to_nid(virt_to_page(usemap));
> 		bootmem_fun_here(NODE_DATA(nid), usemap);
> 	}
> }
> 
> right?

It may work. But, to be honest, I feel there are TOO MANY allocation/free
way for memmap (usemap and so on). If possible, I would like to
unify some of them. I would like to try it.

Bye.

-- 
Yasunori Goto 


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