[PATCH v3 3/5] arm64: mte: implement CONFIG_ARM64_MTE_COMP
Andy Shevchenko
andriy.shevchenko at linux.intel.com
Tue Jul 18 10:17:51 PDT 2023
On Tue, Jul 18, 2023 at 05:33:37PM +0200, Alexander Potapenko wrote:
> On Mon, Jul 17, 2023 at 3:49 PM Andy Shevchenko
> <andriy.shevchenko at linux.intel.com> wrote:
> > On Mon, Jul 17, 2023 at 01:37:06PM +0200, Alexander Potapenko wrote:
...
> However it doesn't seem to be very picky.
>
> $ scripts/kernel-doc -v -none arch/arm64/include/asm/mtecomp.h
>
> warns about e.g. parameter name mismatch, but does not care about the
> missing return section.
-Wreturn is missing
...
> > Also
> > why you put the descriptions in to the header file? It's a bit unusual for the
> > exported ones.
>
> https://docs.kernel.org/doc-guide/kernel-doc.html was not specific on
> this, and I thought anyone wanting to understand how an interface
> works would prefer reading the header rather than the implementation.
> I can move the comments to arch/arm64/mm/mtecomp.c if you think it's a
> better place for them.
With the kernel doc in the C file you may also comment the internal ones and
generate documentation only for exported ones. This is not possible with h.
...
> > > +void ea0_ranges_to_tags(u8 *r_tags, short *r_sizes, int r_len, u8 *tags);
> > In both cases signed integer may be promoted with a sign. Is it a problem here?
> Not sure if you mean r_len or r_sizes,
Mostly about the latter.
> but all those values are >= 0
> and <= 256, so there should be no problems.
> (shorts could have been ints as well, we are just saving some stack
> space in ea0_compress()/ea0_decompress()).
Then why they are signed? Please, justify that.
Signdness prone to subtle and hard to hunt errors due to integer promotions.
...
> > > +#include <linux/bits.h>
> > > +#include <linux/bitmap.h>
> >
> > bitmap guarantees that bits.h will be included.
>
> I am following the IWYU principle here, and I believe it's a good thing to do.
> I've seen cases where these transitive dependencies rotted after some
> refactoring, but the fact was only noticed in certain configurations.
> Also, there's an ongoing work by Ingo Molnar to speed up kernel builds
> by optimizing headers
> (https://lwn.net/ml/linux-kernel/YdIfz+LMewetSaEB@gmail.com/), and it
> relies on explicit dependencies which are easier to untangle.
Yes, but we have some guarantees. E.g., we don't include compiler*.h
when types.h is included, because of the guarantees.
Otherwise your code misses _a lot_ of headers.
...
> > Can you make it unsigned and start from 0?
>
> Changed to start with 0, but I am a bit hesitant about making it
> unsigned: it is now no more special than a loop variable.
Signdness is a beast in C, needs always an additional justification.
...
> > > + int i, j, pos = 0;
> >
> > Wouldn't be more correct to have this assignment inside the first for-loop?
>
> Do you mean setting it back to 0 on every iteration of the outer loop?
Yes.
> We sure don't want that, since pos is the location in the tags[] array
> where the next tag is written.
OK!
...
> > > +#define RANGES_INLINE ea0_size_to_ranges(8)
> >
> > Don't forget to undef it when not needed.
>
> Ok, will do.
> Shall I undef the constants above as well (e.g. BITS_PER_TAG)?
> The intuitive answer is "no",
Correct.
> but then there should be some difference between those and RANGES_INLINE?
Yes, one is widely used constant and one is a _localized_ helper.
...
> > > +static void bitmap_write(unsigned long *bitmap, unsigned long value,
> > > + unsigned long *pos, unsigned long bits)
> >
> > Please, don't use reserved namespace. Yours is ea0, use it:
> > ea0_bitmap_write()! Same to other similarly named functions.
>
> Done.
> However there are two parallel namespaces now: "ea0" for the
> compression algorithm, and "memcomp" for the module initialization and
> data structures.
> Dunno if it makes sense to merge them (and rename the .c file accordingly).
Your choice. Mu point, just do prefix it with something meaningful.
...
> > > + u8 r_tags[256];
> > > + int r_len = ARRAY_SIZE(r_tags);
> >
> No, it is the length of the arrays (both r_tags and r_sizes).
> Below you make a good point it will spare us a kernel.h dependency,
> but for the sake of keeping the code error-prone we probably shouldn't
> assume r_tags is a byte array.
It's a common practice even outside of Linux kernel to use sizeof() against
char arrays. I don't see the point to have the ARRAY_SIZE() complication here.
...
> > > + snprintf(name, ARRAY_SIZE(name), "mte-tags-%d", size);
You see, if you grep for similar calls I'm pretty sure the order of 2 of power
of 10 will be the difference between sizeof()/ARRAY_SIZE() if the latter even
occurs at least once.
--
With Best Regards,
Andy Shevchenko
More information about the linux-arm-kernel
mailing list