linux-kernel - Re: [PATCH] Add debugging aid for memory initialisation problems

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, 27 Nov 2006 14:56:55 +0000 (GMT)
From:	Mel Gorman <mel@....ul.ie>
To:	Andi Kleen <ak@...e.de>
Cc:	akpm@...l.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Add debugging aid for memory initialisation problems

On Mon, 27 Nov 2006, Andi Kleen wrote:

> On Monday 27 November 2006 15:08, Mel Gorman wrote:
>> A number of bug reports have been submitted related to memory initialisation
>> that would have been easier to debug if the PFN of page addresses were
>> available. The dmesg output is often insufficient to find that information
>> so debugging patches need to be sent to the reporting user.
>
> So how many new lines does that add overall?

I don't know for sure, but it's probably around the 150 LOC mark from 
about 12 patches, mainly in page_alloc.c. A significant portion of the 
patches were documentation, comments and providing debugging information. 
As it is, any bug fix or improvement in that code will now apply to all 
architectures using the API, not just one.

I expect the net code difference to drop as some of the mem= parsing 
(which currently does not always work AFAIK) gets handled in generic 
rather than arch-specific code. These type of cleanups will take a while. 
I would also expect the net difference to drop if more architectures used 
the API instead of arch-specific code but I couldn't test on all arches.

> Your memmap patches overall
> were already one of the most noisy additions we had for a very long time.
>

The worst of the noise should be over now. The last patch I sent isn't 
necessary. I only sent it on because it would have cut down on the time 
needed to fix Andre's issue.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
-
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/