Re: [PATCH net-next v3 1/2] keys, dns: drop unused upayload->data NUL terminator

[Thorsten Blum <thorsten.blum@linux.dev>]

On Sat, May 09, 2026 at 12:21:01AM +0300, Jarkko Sakkinen wrote:
> On Mon, Apr 27, 2026 at 01:44:23PM +0200, Thorsten Blum wrote:
> > ->data includes an extra NUL terminator despite never being used as a C
> > string and only accessing ->datalen bytes. Remove the redundant NUL
> > terminator and allocate one byte less in dns_resolver_preparse().
> > 
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> 
> Never being used where?

Does this conversation [1] with Jakub answer your question?

[1] https://lore.kernel.org/lkml/adw5cvtPfx1SWQq9@linux.dev/

> Let me go this through.
> 
> I read this from the documentation:
> 
>   /*
>    * Preparse instantiation data for a dns_resolver key.
>    *
>    * For normal hostname lookups, the data must be a NUL-terminated string, with
>    * the NUL char accounted in datalen.

This documents prep->data and prep->datalen, which must be
NUL-terminated and is checked here in dns_resolver_preparse():

	if (!data || data[datalen - 1] != '\0')
		return -EINVAL;

According to this, datalen (prep->datalen really) must include the NUL
terminator, otherwise -EINVAL is returned.

However, my patch is about upayload->data and upayload->datalen, and
upayload->data currently has a trailing '\0', which upayload->datalen
doesn't account for (a mismatch that prevents adding __counted_by).

> So what is confusing here for me is that should upayload, which is
> original data with options and '\0'.
> 
> So my question is which is the regression here:
> 
> 1. Incorrect length. Then the fix would be simply setting length as
>    'result_len + 1', which aligns also with the snippet of documentation
>    I pasted.

This would be an option, but there is currently no consumer of
upayload->data in the kernel that uses the trailing '\0'.

> 2. Unnecessary '\0'.

Yes, '\0' is an unnecessary extra byte that no consumer of
upayload->data uses, and my patch removes it.

> If there is an issue, your commit is lacking fixes tag and cc tag to the
> author of potentially failing commit.

It's just an unused extra byte that prevents adding __counted_by(),
which is otherwise harmless, hence no fixes tag.

Thanks,
Thorsten