Hi!

I've split some of the patches from the string patch set, as these are
obvious bug fixes that are trivial to accept.

I've reset the version number of the patch set to 1, to not conflict
with the version numbering of the string series.


Have a lovely day!
Alex

Alejandro Colomar (3):
  array_size.h: Add ENDOF()
  mm: Fix benign off-by-one bugs
  kernel: Fix off-by-one benign bugs

 include/linux/array_size.h | 6 ++++++
 kernel/kcsan/kcsan_test.c  | 4 ++--
 mm/kfence/kfence_test.c    | 4 ++--
 mm/kmsan/kmsan_test.c      | 2 +-
 4 files changed, 11 insertions(+), 5 deletions(-)

-- 
2.51.0

On Thu, 25 Sep 2025 15:20:28 +0200 Alejandro Colomar <alx@kernel.org> wrote:

> I've split some of the patches from the string patch set, as these are
> obvious bug fixes that are trivial to accept.
> 
> I've reset the version number of the patch set to 1, to not conflict
> with the version numbering of the string series.

fyi, there's nothing here which is usable in an introductory [0/N]
cover letter.

Documentation/process/submitting-patches.rst should explain the
conventions here, but it is presently silent.

The [0/N] is an overview of the whole patchset - why it was created,
what value it provides to our users and perhaps to kernel developers
themselves.  It discusses alternative approaches, possible drawbacks,
prior work, all that stuff.  And it provides a high-level description
of the proposed implementation,

Potentially lots of words, and it's quite important.  In the case of
your patchset, it's one short sentence (sorry).

The words you did include are short-term development things, unsuitable
for inclusion in the permanent kernel record.  Such material *is*
important and useful, but should be added after the "^---$" separator,
to tell everyone that this material isn't for permanent inclusion.

Patchset seems reasonable, I guess.  But I'm not loving "ENDOF".  End
of what - is that like __etext?  "ARRAY_END" matches "ARRAY_SIZE" quite
nicely, no?  And it much better describes what the thing does.

Hi Andrew,

On Thu, Sep 25, 2025 at 01:48:14PM -0700, Andrew Morton wrote:
> On Thu, 25 Sep 2025 15:20:28 +0200 Alejandro Colomar <alx@kernel.org> wrote:
> 
> > I've split some of the patches from the string patch set, as these are
> > obvious bug fixes that are trivial to accept.
> > 
> > I've reset the version number of the patch set to 1, to not conflict
> > with the version numbering of the string series.
> 
> fyi, there's nothing here which is usable in an introductory [0/N]
> cover letter.
> 
> Documentation/process/submitting-patches.rst should explain the
> conventions here, but it is presently silent.
> 
> The [0/N] is an overview of the whole patchset - why it was created,
> what value it provides to our users and perhaps to kernel developers
> themselves.  It discusses alternative approaches, possible drawbacks,
> prior work, all that stuff.  And it provides a high-level description
> of the proposed implementation,
> 
> Potentially lots of words, and it's quite important.  In the case of
> your patchset, it's one short sentence (sorry).
> 
> The words you did include are short-term development things, unsuitable
> for inclusion in the permanent kernel record.

Thanks!  I'll keep it in mind.  BTW, I didn't know the cover letters
were stored anywhere.  By 'the permanent kernel record' you mean that
cover letters are stored in a merge commit message or something like
that?  It would be useful to have that documented.  I didn't know.

I can send a v2 with a better cover letter, if you want.

>  Such material *is*
> important and useful, but should be added after the "^---$" separator,
> to tell everyone that this material isn't for permanent inclusion.

Okay, I'll keep that in mind.

> Patchset seems reasonable, I guess.  But I'm not loving "ENDOF".  End
> of what - is that like __etext?  "ARRAY_END" matches "ARRAY_SIZE" quite
> nicely, no?  And it much better describes what the thing does.

ENDOF() matches countof(), which is the standard name for ARRAY_SIZE().

<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3550.pdf#subsubsection.0.6.5.4.5>
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3550.pdf#section.0.7.21>

I've never loved ARRAY_SIZE, as I have a macro sizeof_array() which
gives me the size of an array in bytes (and guarantees that the input is
an array).  The name nelementsof() --or the shorter NELEMS()-- seems
more appropriate, IMO, since what it returns is "the number of elements
of an array".  However, the C Committee hated it so much that I couldn't
get them to standardize it.  I'm content enough with countof().


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

On Thu, Sep 25, 2025 at 01:48:14PM -0700, Andrew Morton wrote:
> Patchset seems reasonable, I guess.  But I'm not loving "ENDOF".  End
> of what - is that like __etext?  "ARRAY_END" matches "ARRAY_SIZE" quite
> nicely, no?  And it much better describes what the thing does.

And it's really ARRAY_BEYOND. ;) I don't really like having APIs that
require holding pointers that are actively invalid, either.

u8 array[10];
u8 *first = array; // valid address
u8 *last = &array[ARRAY_SIZE(array) - 1]; // valid address

for (u8 *c = first; c <= last; c++)
  putc(*c);
// c would now be invalid but has left scope so it cannot be used

-- 
Kees Cook