From: "Martin J. Bligh" <Martin.Bligh@us.ibm.com>
To: Samuel Ortiz <sortiz@dbear.engr.sgi.com>
Cc: Andrea Arcangeli <andrea@suse.de>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
Linus Torvalds <torvalds@transmeta.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] stop null ptr deference in __alloc_pages
Date: Fri, 08 Mar 2002 13:50:49 -0800 [thread overview]
Message-ID: <37610000.1015624249@flay> (raw)
In-Reply-To: <Pine.LNX.4.33.0203081325560.18968-100000@dbear.engr.sgi.com>
In-Reply-To: <Pine.LNX.4.33.0203081325560.18968-100000@dbear.engr.sgi.com>
>> I should have also mentioned that:
>>
>> 1) I shouldn't need the SGI patch, though it might help performance.
>
> Why shouldn't you need it ? It is NUMA generic, and totally arch
> independent.
I just mean the kernel shouldn't panic if I don't have it.
> And it actually helps performance. I also allows the kernel to have a
> single memory allocation path. I think it is cleaner than calling _alloc_pages()
> from numa.c
>
>> 2) The kernel panics without my fix, and runs fine with it.
> I hope so :-)
> But your fix is at the same time useless and harmless for UMA machines.
Yup, though I suppose we could shave off a couple of nanoseconds by
surrounding my little check with #ifdef CONFIG_NUMA.
> OTOH, the SGI patch doesn't modify __alloc_pages(). I think I'm a little
> too picky here...
With the #ifdef, I won't really do this either (at least for the code generated).
The SGI patch is probably a good thing, and I'll pick it up and try it
sometime soon. The only real problem is that it's not in the mainline
already. Until such time as it gets there, the fix I posted is trivial,
and easily seen to be correct (well, I'm biased ;-) ), and should get
shoved into the mainline much easier.
M.
next prev parent reply other threads:[~2002-03-08 21:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-08 19:36 [PATCH] stop null ptr deference in __alloc_pages Martin J. Bligh
2002-03-08 20:14 ` Samuel Ortiz
2002-03-08 20:49 ` Martin J. Bligh
2002-03-08 21:16 ` Martin J. Bligh
2002-03-08 21:37 ` Samuel Ortiz
2002-03-08 21:50 ` Martin J. Bligh [this message]
2002-03-08 22:40 ` Samuel Ortiz
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=37610000.1015624249@flay \
--to=martin.bligh@us.ibm.com \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=sortiz@dbear.engr.sgi.com \
--cc=torvalds@transmeta.com \
/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