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] [day] [month] [year] [list]

Date:   Tue, 2 Apr 2019 14:45:59 +0300
From:   Yury Norov <yury.norov@...il.com>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        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 Mon, Apr 01, 2019 at 10:10:33PM +0200, Rasmus Villemoes wrote:
> 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.

There are enough examples of conditionally defined functions without
stubs, I don't see any problem with it. Anyways, if you don't like
doing that, moving the code and declarations to new files would help.

> So I'd prefer a simple linker
> error should any user outside NUMA ever appear. Which I very highly doubt.

Linker errors are usually less specific and much longer to obtain
at the linker-stage, which is not good.

> > 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).

I probably don't understand the argument. If we find bitmap.c polluted, we
should try clean it, right?