On Fri, Sep 22, 2023 at 3:30 PM Yury Norov [off-list ref] wrote:

On Fri, Sep 22, 2023 at 09:57:32AM +0200, Alexander Potapenko wrote:

quoted

quoted

quoted

+     unsigned long val, bit;
+     int i;
+
+     /* Setting/getting zero bytes should not crash the kernel. */
+     bitmap_write(NULL, 0, 0, zero_bits);
+     val = bitmap_read(NULL, 0, zero_bits);
+     expect_eq_ulong(0, val);

No, val is undefined.

Why? bitmap_read(..., ..., 0) always returns 0.

Because it's unexpected and most likely wrong to pass 0 bits. We
guarantee that bitmap_read() will return immediately, and will not
touch the memory. But we don't guarantee that we return any specific
value.

Fair enough, I'll remove the expect_eq_ulong() from the test in v6 and
will also add the requirement for nbits to be nonzero to the doc
comments for bitmap_read() and bitmap_write().

It's not a hot path, at least now, and we can spend few extra cycles
to clear output register and return 0, but user should not rely on it
in any way, especially in a test that is intended to show an example
of using the new API.

Ok, for now I'll keep the "return 0" part.

Consider a less relaxed environment, where we really have to count
cycles. In such environment, we'd return a content of the 1st input
argument, just because it's already in R0, and compiled doesn't have
to:

    mov r0, #0
    ret

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel