Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 15 Jun 2023 10:29:49 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Dan Williams <dan.j.williams@intel.com>
Cc:     "Wilczynski, Michal" <michal.wilczynski@intel.com>,
        alison.schofield@intel.com,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andy Lutomirski <luto@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Mike Rapoport <rppt@kernel.org>, x86@kernel.org,
        linux-cxl@vger.kernel.org, linux-acpi@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Derick Marks <derick.w.marks@intel.com>
Subject: Re: [PATCH v2 1/2] x86/numa: Introduce numa_fill_memblks()
Message-ID: <20230615082949.GA1683497@hirez.programming.kicks-ass.net>
References: <cover.1686712819.git.alison.schofield@intel.com>
 <9fcc548a6b4727cb2538e5227d7bad2e94e6adaf.1686712819.git.alison.schofield@intel.com>
 <03945e1f-caf6-3e5c-babc-d30e4e02b65e@intel.com>
 <6489b23bc67e0_142af829456@dwillia2-xfh.jf.intel.com.notmuch>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6489b23bc67e0_142af829456@dwillia2-xfh.jf.intel.com.notmuch>
Precedence: bulk

On Wed, Jun 14, 2023 at 05:27:39AM -0700, Dan Williams wrote:
> Wilczynski, Michal wrote:
> > On 6/14/2023 6:35 AM, alison.schofield@intel.com wrote:

> > > +static int __init cmp_memblk(const void *a, const void *b)
> > > +{
> > > +	const struct numa_memblk *ma = *(const struct numa_memblk **)a;
> > > +	const struct numa_memblk *mb = *(const struct numa_memblk **)b;
> > 
> > Is this casting necessary? ?
> 
> This is idiomatic for sort() comparison handlers.

Aside of that, it *is* actually required, since sort() does indirect
calls to it's cmp_func_t argument the Control Flow Integrity (CFI, not
to be confused with Call-Frame-Information) stuff has a hard requirement
that function signatures match.

At the very least clang builds should warn if you do indirect calls with
non-matching signatures these days. And kCFI enabled builds will get you
a runtime error if you manage to ignore that warning.

> > > +
> > > +	if (ma->start != mb->start)
> > > +		return (ma->start < mb->start) ? -1 : 1;
> > > +
> > > +	/* Caller handles duplicate start addresses */
> > > +	return 0;
> > > +}