linux-kernel - Re: [PATCH -mm -v8 0/3] Lockless memory allocator and list

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]

Date:	Fri, 17 Dec 2010 23:35:01 +0800
From:	huang ying <huang.ying.caritas@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Huang Ying <ying.huang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Borislav Petkov <bp@...en8.de>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Dirk Hohndel <Dirk.Hohndel@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Brown,Len" <len.brown@...el.com>,
	"Luck,Tony" <tony.luck@...el.com>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [PATCH -mm -v8 0/3] Lockless memory allocator and list

On Fri, Dec 17, 2010 at 8:22 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Fri, 2010-12-17 at 08:20 +0800, Huang Ying wrote:
>> On Thu, 2010-12-16 at 17:24 +0800, Peter Zijlstra wrote:
>> > On Thu, 2010-12-16 at 14:59 +0800, Huang Ying wrote:
>> > > This patchset adds a lockless memory allocator and a lock-less
>> > > list.
>> >
>> > Still no users the allocator, and no attempt to unify the existing
>> > lockless list implementations.
>> >
>> > I'm getting very tired of this Huang.
>>
>> I just want to do that in the next step after merging the data structure
>> itself. The first user of the allocator is APEI, which will go ACPI
>> tree, lockless list in irq_work will go tip tree, lockless list in xlist
>> will go net tree.
>>
>> We must merge the data structure with its users together?
>
> Yes -- that's how new infrastructure gets merged. Because if we don't
> agree with the users (I don't) there is no point in merging these things
> either.
>
> I would really like you to stop posting code and talk to the EDAC guys.
> You just keep on posting the same crap over and over again without
> making any kind of progress what so ever.
>
> So stop pushing your crap, _please_, and talk to the EDAC and other RAS
> guys and come up with something together.
>
> I haven't heard a single other RAS guy agree with your approach, and I'm
> getting really sick of you just pushing your stuff without even wanting
> to talk to them.
>
> I don't want to see a single line of code from you until you've talked
> with other RAS folks and they agree that your bits make sense.
>
> So let me put it in simple words: unless there's a non-Intel RAS guy
> signing off on your patches I'm objecting to them.

Please take a look at the patchset, this patchset is not RAS specific,
it is not hardware error reporting infrastructure or hardware error
reporting interface. This is just lock-less data structure. So this is
not a RAS patchset. Why I must get non-Intel RAS guys' signing off for
a non-RAS patchset?

I will not post my original hardware error reporting infrastructure or
interface after this patchset. Although I may use some part of this
patchset in APEI code, that is just driver internal data structure
usage, not general hardware error reporting infrastructure or
interface.

> The thing is, a unified RAS infrastructure is much more useful for
> admins, it means they can use the same tools regardless of what platform
> they're running on.
>
> Now I know creating such a thing seems daunting, but at least give it a
> try, its better to have tried and failed that not attempted at all, at
> worst you'll learn what you did wrong and can try to do better the
> second time around.

I have tried to do that with my original hardware error reporting
interface patchset. It is really generic, simple and can help RAS
guys. But it seems that no many people like it, and no many people
really take a look at it. So I stop doing that now.

And I remember the recent consensus on hardware error reporting is to
use printk. Although I think it will be better if we have some other
tool-oriented interface too. I will work on printk based hardware
error reporting interface firstly.

Best Regards,
Huang Ying
--
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/