From: William Lee Irwin III <wli@holomorphy.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Christoph Lameter <christoph@lameter.com>,
Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [PATCH 0/7] abstract pagetable locking and pte updates
Date: Mon, 1 Nov 2004 17:55:49 -0800 [thread overview]
Message-ID: <20041102015549.GR2583@holomorphy.com> (raw)
In-Reply-To: <4186E41E.5080909@yahoo.com.au>
On Tue, Nov 02, 2004 at 12:34:22PM +1100, Nick Piggin wrote:
> Why do you say the audits need to be better? No doubt there will
> still be bugs, but I didn't just say "ahh let's remove the lock
> from around the tlb operations and pray it works".
> I could very well be missing something though - You must be
> seeing some fundamental problems or nasty bugs to say that it's
> been designed it in a vacuum, and that the audits are no good...
> What are they please?
How many times does it take? No, and I'm not looking for you. You have
the burden of proof.
You yourself claimed you hadn't audited the things. The question
this raised was rather obvious:
If you didn't even look at them, how do you have any idea
it's going to work for them?
All that needs to be supplied is sufficient evidence, collected
from 20 spots around the VM (arch code), and for that matter, in
summary form ("I audited all architectures"). This should not be in
the form of a lie, not to imply you would do that. The sparc64 analysis
you gave is actually somewhat off but it doesn't really matter so long
as there's actual diligence instead of simultaneous claims of
sufficiency and non-diligence.
I am not even looking at the code. I have my own work to do. I
respectfully ask that when you do your own, you exercise the kind
of diligence I described above as opposed to the kind of affiar you
described in your announcement.
-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-11-02 1:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-29 7:20 Nick Piggin
2004-10-29 7:20 ` [PATCH 1/7] " Nick Piggin
2004-10-29 7:21 ` [PATCH 2/7] " Nick Piggin
2004-10-29 7:21 ` [PATCH 3/7] " Nick Piggin
2004-10-29 7:21 ` [PATCH 4/7] " Nick Piggin
2004-10-29 7:22 ` [PATCH 5/7] " Nick Piggin
2004-10-29 7:23 ` [PATCH 6/7] " Nick Piggin
2004-10-29 7:23 ` [PATCH 7/7] " Nick Piggin
2004-10-29 7:46 ` [PATCH 0/7] " William Lee Irwin III
2004-11-02 0:15 ` Christoph Lameter
2004-11-02 0:54 ` William Lee Irwin III
2004-11-02 1:34 ` Nick Piggin
2004-11-02 1:55 ` William Lee Irwin III [this message]
2004-11-02 2:38 ` Nick Piggin
2004-11-02 6:57 ` William Lee Irwin III
2004-11-02 17:55 ` Christoph Lameter
2004-10-29 11:45 ` Nick Piggin
2004-10-29 20:52 ` William Lee Irwin III
2004-10-30 2:46 ` Nick Piggin
2004-11-02 0:19 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041102015549.GR2583@holomorphy.com \
--to=wli@holomorphy.com \
--cc=christoph@lameter.com \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox