All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Borislav Petkov <bp@alien8.de>,
	Narasimhan V <Narasimhan.V@amd.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	stable@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] memblock:fix validation of NUMA coverage
Date: Fri, 14 Jun 2024 10:31:21 +0300	[thread overview]
Message-ID: <Zmvxyc5xguxefBwo@kernel.org> (raw)
In-Reply-To: <663e80fc-6785-4ac5-ae74-e5f26d938f49@suse.com>

On Fri, Jun 14, 2024 at 08:01:33AM +0200, Jan Beulich wrote:
> On 13.06.2024 19:38, Linus Torvalds wrote:
> > On Thu, 13 Jun 2024 at 10:09, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> >>
> >> Is there some broken scripting that people have started using (or have
> >> been using for a while and was recently broken)?
> > 
> > ... and then when I actually pull the code, I note that the problem
> > where it checked _one_ bogus value has just been replaced with
> > checking _another_ bogus value.
> > 
> > Christ.
> > 
> > What if people use a node ID that is simply outside the range
> > entirely, instead of one of those special node IDs?
> > 
> > And now for memblock_set_node() you should apparently use NUMA_NO_NODE
> > to not get a warning, but for memblock_set_region_node() apparently
> > the right random constant to use is MAX_NUMNODES.
> > 
> > Does *any* of this make sense? No.
> > 
> > How about instead of having two random constants - and not having any
> > range checking that I see - just have *one* random constant for "I
> > have no range", call that NUMA_NO_NODE,
> 
> Just to mention it - my understanding is that this is an ongoing process
> heading in this very direction. I'm not an mm person at all, so I can't
> tell why the conversion wasn't done / can't be done all in one go.

Nah, it's an historical mess and my oversight.
 
> Jan

-- 
Sincerely yours,
Mike.

  reply	other threads:[~2024-06-14  7:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-13 14:09 [GIT PULL] memblock:fix validation of NUMA coverage Mike Rapoport
2024-06-13 17:09 ` Linus Torvalds
2024-06-13 17:38   ` Linus Torvalds
2024-06-14  6:01     ` Jan Beulich
2024-06-14  7:31       ` Mike Rapoport [this message]
2024-06-14  8:17     ` Mike Rapoport
2024-06-14 16:28       ` Linus Torvalds
2024-06-13 19:30 ` pr-tracker-bot

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=Zmvxyc5xguxefBwo@kernel.org \
    --to=rppt@kernel.org \
    --cc=Narasimhan.V@amd.com \
    --cc=bp@alien8.de \
    --cc=jbeulich@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.