[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 7/8] x86/setup: simplify handling of initrdidx when no initrd present

Hi Jan,

On 25/02/2020 12:34, Jan Beulich wrote:
On 24.02.2020 14:31, Julien Grall wrote:
On 21/02/2020 16:59, Jan Beulich wrote:
On 01.02.2020 01:33, David Woodhouse wrote:
From: David Woodhouse <dwmw@xxxxxxxxxxxx>

Remove a ternary operator that made my brain hurt.

Personally I'd prefer the code to stay as is, but if Andrew agrees
with this being an improvement, then I also wouldn't want to stand
in the way. If it is to go in I have a few small adjustment requests:

Replace it with something simpler that makes it somewhat clearer that
the check for initrdidx < mbi->mods_count is because mbi->mods_count
is what find_first_bit() will return when it doesn't find anything.

Especially in light of the recent XSA-307 I'd like to ask that we
avoid imprecise statements like this: Afaict find_first_bit() may
also validly return any value larger than the passed in bitmap

Is it? I though that all the callers are now returning 'size' in all the
error cases.

Taking (part of) the x86 example:

#define find_next_bit(addr, size, off) ({                                   \
    unsigned int r__;                                                       \
    const unsigned long *a__ = (addr);                                      \
    unsigned int s__ = (size);                                              \
    unsigned int o__ = (off);                                               \
    if ( o__ >= s__ )                                                       \
        r__ = s__;                                                          \

This is what did get adjusted, guaranteeing "size" to be returned for
too large an "offset".

    else if ( __builtin_constant_p(size) && s__ <= BITS_PER_LONG )          \
        r__ = o__ + __scanbit(*(const unsigned long *)(a__) >> o__, s__);   \

Yet this was (deliberately) left untouched. Without s__ getting
replaced by s__ - o__ it may still produce a value larger than
"size", though.

Ah I missed this part.

Further, even if all current implementations obeyed by the more
strict rule, this still wouldn't mean callers are actually permitted
to assume such. The more strict rule would then also need to be
written down, such that it won't get violated again in the future
(by changes to an existing arch's implementation, or by a new port

To be honest, the rule should be written down in any case. The current one is not necessarily an obvious one and also differ from what Linux folks can expect.

Regarding future port, the number of architectures in Linux using custom bitops are fairly limited (AFAICT only arm32 and unicore32). All the rest (including x86) using a generic implementation.

On Xen, Arm64 is already using the generic implementation. Is there any particular concern to use it for x86 as well?

If not, I can pull a patch to use the generic implementation on x86/arm32. This would solve the discrenpancies in find_*_bit implementations.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.