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 <[email protected]> > > Never being used where?
Does this conversation [1] with Jakub answer your question? [1] https://lore.kernel.org/lkml/[email protected]/ > 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
