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:	Mon, 21 Apr 2008 19:29:52 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Shi Weihua <shiwh@...fujitsu.com>, akpm@...ux-foundation.org,
	balbir@...ux.vnet.ibm.com, xemul@...nvz.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, hugh@...itas.com
Subject: Re: [PATCH]Fix usemap for DISCONTIG/FLATMEM with not-aligned zone
 initilaization.

On Mon, 21 Apr 2008 11:12:32 +0100
Mel Gorman <mel@....ul.ie> wrote:

> On (21/04/08 11:20), KAMEZAWA Hiroyuki didst pronounce:
> > On Sat, 19 Apr 2008 02:25:56 +0900 (JST)
> > kamezawa.hiroyu@...fujitsu.com wrote:
> >  
> > > >What about something like the following? Instead of expanding the size of
> > > >structures, it sanity checks input parameters. It touches a number of places
> > > >because of an API change but it is otherwise straight-forward.
> > > >
> > > >Unfortunately, I do not have an IA-64 machine that can reproduce the problem
> > > >to see if this still fixes it or not so a test as well as a review would be
> > > >appreciated. What should happen is the machine boots but prints a warning
> > > >about the unexpected PFN ranges. It boot-tested fine on a number of other
> > > >machines (x86-32 x86-64 and ppc64).
> > > >
> > > ok, I'll test today if I have a chance. At least, I think I can test this
> > > until Monday. but I have one concern (below)
> > > 
> > I tested and found your patch doesn't work.
> > It seems because all valid page struct is not initialized.
> 
> The fact I didn't calculate end_pfn properly as pointed out by Dave Hansen
> didn't help either. If that was corrected, I'd be surprised if the patch
> didn't work. If it is broken, it implies that arch-specific code is using
> PFN ranges that do not contain valid memory - something I find surprising.
> 
I noticed and fixed end_pfn but did not work....If necessary, I'll check it
again....

Thanks,
-Kame

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ