From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>, WeiLiu <wl@xen.org>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@arm.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] UBSAN report in find_next_bit()
Date: Tue, 25 Jun 2019 03:38:34 -0600 [thread overview]
Message-ID: <5D11EB9A020000780023ADEF@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <a6616d8c-af45-c3d7-24e7-f4b513fdc008@citrix.com>
>>> On 24.06.19 at 18:24, <andrew.cooper3@citrix.com> wrote:
>> else if ( (node = next_node(node, nodemask)) >= MAX_NUMNODES )
>> node = first_node(nodemask);
>
> On x86, MAX_NUMNODES is 64, and this part of get_free_buddy() loops over
> nodes {0..63}. next_node() expands to find_next_bit(..., node+1) which
> passes offset == size on the final iteration.
>
> find_next_bit() has an optimisation for bitmaps of 64 or fewer bits
> which does:
>
>> else if ( __builtin_constant_p(size) && s__ <= BITS_PER_LONG )
>> r__ = o__ + __scanbit(*(const unsigned long *)(a__) >> o__, s__);
>
> UBSAN takes objection to the shift, which in this case is a shift by 64.
>
> The code in __find_next_bit() makes it clear that offset == size is a
> valid condition, which would suggest that the bug is with the optimisation.
Oh, in particular the ASSERT() there is indeed very clear.
> However, this conclusion contradicts the views of c/s b20079da9 which
> decided that offset == size is not a valid condition.
And that was based on how x86'es find_next{,_zero}_bit() as well
as ...
> ARM64's find_next_bit() explicitly copes with offset >= size, and while
> I don't speak ARM asm well enough to work out whether
> _find_first_bit_le() copes with offset == size, the vgic.c code
> definitely expects it to function in this way.
... Arm32's _find_next{,_zero}_bit_le. You've named the issue the x86
logic has. Arm32's, afaict, will read one byte past the array when offset
and size match and are a multiple of 8.
> As a result, I think the reasoning in c/s b20079da9 is false, and that
> change needs re-adjusting. I also think that x86's optimisation for
> size == 64 should be considered buggy and fixed. TBH, I'm not sure the
> optimisation is worthwhile having in the first place.
The question though is whether, alongside offset == size potentially
being meant to be valid, offset > size is to be treated like such, too.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-06-25 9:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-24 16:24 [Xen-devel] UBSAN report in find_next_bit() Andrew Cooper
2019-06-25 9:38 ` Jan Beulich [this message]
2019-06-25 10:14 ` Julien Grall
2019-06-25 10:12 ` Julien Grall
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=5D11EB9A020000780023ADEF@prv1-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=julien.grall@arm.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).