On Wed, Mar 8, 2023 at 2:43 PM Peter Xu peterx@redhat.com wrote:
All nitpicks below.
On Wed, Mar 08, 2023 at 02:19:31PM -0800, Axel Rasmussen wrote:
+static inline bool uffd_flags_has_mode(uffd_flags_t flags, enum mfill_atomic_mode expected) +{
return (flags & MFILL_ATOMIC_MODE_MASK) == ((__force uffd_flags_t) expected);+}
I would still call it uffd_flags_get_mode() or uffd_flags_mode(), "has" sounds a bit like there can be >1 modes set but it's not.
I want a helper which does the comparison, instead of just returning the mode, because it avoids all callers needing to do the __force cast themselves to appease sparse.
How about uffd_flags_mode_is() ?
+static inline uffd_flags_t uffd_flags_set_mode(uffd_flags_t flags, enum mfill_atomic_mode mode) +{
return flags | ((__force uffd_flags_t) mode);+}
IIUC this __force mostly won't work in any way because it protects e.g. illegal math ops upon it (to only allow bitops, iiuc) but here it's an OR so it's always legal..
So I'd just drop it and also clear the mode mask to be very clear it sets the mode right, rather than any chance of messing up when set twice:
flags &= ~MFILL_ATOMIC_MODE_MASK; return flags | mode;
Without this __force, "make C=1" gives errors like this:
./include/linux/userfaultfd_k.h:66:16: warning: restricted uffd_flags_t degrades to integer ./include/linux/userfaultfd_k.h:66:22: warning: incorrect type in return expression (different base types) ./include/linux/userfaultfd_k.h:66:22: expected restricted uffd_flags_t ./include/linux/userfaultfd_k.h:66:22: got unsigned int
This is because the mode being passed in is effectively an integer, so the | expression loses the restricted type. Casting the mode first like this appeases sparse.
An alternative would be to do the cast in the definition of the mode values up-front; but as we noticed before, we can't really usefully do that with it still being an enum (so we'd have to hard-code things like the mode mask, etc.)
I do completely agree about clearing the mask bits first, to avoid mistakes. I'll send an updated version with that change. If we're going to have an inline helper anyway to do that, for me it makes less sense to switch away from the num approach (basically the benefit of that would be to avoid needing this cast, and therefore the helper; but if we want the helper anyway for other reasons ...).
But feel free to ignore this if there's no other reason to repost, I don't think it matters a huge deal.
Acked-by: Peter Xu peterx@redhat.com
Thanks,
-- Peter Xu