linux-kernel - Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ad8cb18-ba77-c659-4f44-4ab4f810f9f1@rasmusvillemoes.dk>
Date:   Mon, 1 Apr 2019 22:10:33 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Yury Norov <yury.norov@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, Yury Norov <ynorov@...vell.com>
Subject: Re: PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by
 CONFIG_NUMA

On 30/03/2019 19.54, Yury Norov wrote:
> Hi Rasmus!
> 
>> From: Rasmus Villemoes <linux@...musvillemoes.dk>
>> Sent: Saturday, March 30, 2019 12:53:51 AM
>> To: Rasmus Villemoes; Andrew Morton; Andy Shevchenko
>> Cc: Yury Norov; linux-kernel@...r.kernel.org
>> Subject: [PATCH 2/2] lib/bitmap.c: guard exotic bitmap functions by CONFIG_NUMA
>>
>> The bitmap_remap, _bitremap, _onto and _fold functions are only used,
>> via their node_ wrappers, in mm/mempolicy.c, which is only built for
>> CONFIG_NUMA. The helper bitmap_ord_to_pos used by these functions is
>> global, but its only external caller is node_random() in lib/nodemask.c,
>> which is also guarded by CONFIG_NUMA.
> 
> Nice catch. I think you should protect declaration of those functions
> in include/linux/bitmap.h as well.

Yeah, well, it's not that simple, because one would also need to wrap
the static inline __nodes_onto etc. in ifdefs. Normally, there'd be an
#else branch defining simple static inline replacements that always fail
or return 0, but we can't do that here. So I'd prefer a simple linker
error should any user outside NUMA ever appear. Which I very highly doubt.

> I'm concerned about pollution of such a generic portion of code with
> subsystem-related #ifdefs. Would it make more sense to move numa-specific
> stuff to lib/bitmap_numa.c and include/linux/bitmap_numa.h (or *_nodemask.h,
> or whatever)?

Well, yes, that might be better, but a lot bigger patch. One could also
argue that bitmap.c is _already_ polluted with subsystem specific code
(though not in the form of preprocessor directives).

Dunno, I'll defer to Andrew's judgment.

Rasmus