linux-kernel - Re: [RFC PATCH 0/3] Fix SLQB on memoryless configurations V2

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]

Message-ID: <20090922132018.GB25965@csn.ul.ie>
Date:	Tue, 22 Sep 2009 14:20:19 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Sachin Sant <sachinp@...ibm.com>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	Pekka Enberg <penberg@...helsinki.fi>,
	heiko.carstens@...ibm.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Tejun Heo <tj@...nel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [RFC PATCH 0/3] Fix SLQB on memoryless configurations V2

On Tue, Sep 22, 2009 at 06:35:05PM +0530, Sachin Sant wrote:
> Mel Gorman wrote:
>> On Tue, Sep 22, 2009 at 10:33:11AM +0530, Sachin Sant wrote:
>>   
>>> Mel Gorman wrote:
>>>     
>>>> On Mon, Sep 21, 2009 at 01:54:12PM -0400, Christoph Lameter wrote:
>>>>         
>>>>> Lets just keep SLQB back until the basic issues with memoryless nodes are
>>>>> resolved.
>>>>>             
>>>> It's not even super-clear that the memoryless nodes issues are entirely
>>>> related to SLQB. Sachin for example says that there was a stall issue
>>>> with memoryless nodes that could be triggered without SLQB. Sachin, is
>>>> that still accurate?
>>>>         
>>> I think there are two different problems that we are dealing with.
>>>
>>> First one is the SLQB not working on a ppc64 box which seems to be specific
>>> to only one machine and i haven't seen that on other power boxes.The patches
>>> that you have posted seems to allow the box to boot, but eventually it hits
>>> the stall issue(related to percpu dynamic allocator not working on ppc64),
>>> which is the second problem we are dealing with.
>>>
>>>     
>>
>> Ok, I've sent out V3 of this. It's only a partial fix but it's about as
>> far as it can be brought until the other difficulties are resolved.
>>   
> Thanks Mel.
>
>>   
>>> The stall issue seems to be much more critical as it is affecting almost
>>> all of the power boxes that i have tested with (4 in all).
>>> This issue is seen with Linus tree as well and was first seen with
>>> 2.6.31-git5 (0cb583fd..) 
>>>
>>> The stall issue was reported here:
>>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-September/075791.html
>>>
>>>     
>>
>> Can you bisect this please?
>>   
> The problem seems to have been introduced with
> commit ada3fa15057205b7d3f727bba5cd26b5912e350f.
>
> Specifically this patch : powerpc64: convert to dynamic percpu allocator
>

That is commit c2a7e818019f20a5cf7fb26a6eb59e212e6c0cd8.

> If i revert this patch i am able to boot latest git
> on a powerpc box.
>

Ok, this is then independent of the corruption I was seeing which I now
believe is based entirely within SLQBs handling of remote nodes. I was based
on 2.6.31 with SLQB applied on top. This patch was applied in a time after
the baseline I was working from.

Tejun, have you looked at that stall problem? Sorry if you have already,
I haven't dug around for related threads.

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