From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 28323175A7C for ; Mon, 13 Apr 2026 00:32:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776040323; cv=none; b=LlFVy4PHEN3lbII7j7ErjaOGfoLZDOzO2b+jFEnQXvi3Um1NLOeN5JQYEAUgb7F/W0dbep5iga9lPSto7j7Kx/DgLYCdYXAB8SD/4a2139MMaprPbhqad3VBdneuKJHWQwRo55/2JT3h7PZRJFk4bM8DtjEp5XieeNKVm3yXHWg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776040323; c=relaxed/simple; bh=iiS7YHHYEiwoAeGB+s46aUzFjLh12MYL7w338whrfAM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=khQh6eluaKQy0hOktLY0PhWzL7OWg9sohrq0v5aGVVFGKvF8rctAPCIwFddS27nQTIyyLb0AQ4o7laX+qWEWzHUDFVHpUS7k8z1ru1apo1smqjl/CroSAkj95Dg1s+O4oCsDdRC0PhceyucRul82mEvFhxSne2zS2i9l1I3gz0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=cjL2WriJ; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="cjL2WriJ" Date: Mon, 13 Apr 2026 02:31:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1776040310; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bpCWJlcrlR/qj7FSw6XNBtjxoMJCffd/yR4SSdNFmK8=; b=cjL2WriJ3wbT04wJsWXnqx56tW72qtAxPBsqsSwmosYyCWwK4c4p+qjtaJ71LcJAD6GBwd bYwTDxnHm1TghSFwj36CP4uSIvPrhkT8BCGcGmULoH3n3jVe8RJRZMb3V9WCBXXb5m6PV/ PtMpWmKwyzoOWBMmdbe1/MachgGMF78= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Thorsten Blum To: Jakub Kicinski Cc: "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Tim Bird , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next v2 1/2] keys, dns: drop unused upayload->data NUL terminator Message-ID: References: <20260409225703.158552-4-thorsten.blum@linux.dev> <20260412141004.22c6686c@kernel.org> <20260412170508.1f33a371@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260412170508.1f33a371@kernel.org> X-Migadu-Flow: FLOW_OUT On Sun, Apr 12, 2026 at 05:05:08PM -0700, Jakub Kicinski wrote: > On Mon, 13 Apr 2026 01:04:54 +0200 Thorsten Blum wrote: > > On Sun, Apr 12, 2026 at 02:10:04PM -0700, Jakub Kicinski wrote: > > > On Fri, 10 Apr 2026 00:57:02 +0200 Thorsten Blum wrote: > > > > In dns_resolver_preparse(), do not NUL-terminate ->data and allocate one > > > > byte less. The NUL terminator is never used and only ->datalen bytes are > > > > accessed. > > > > > > I can't see where this is used at all. > > > Please write better commit messages, there's no way this 1 byte > > > is worth the amount of time I wasted trying to review this :/ > > > > The point of patch 1/2 is not the removed NUL terminator itself, but to > > prepare for patch 2/2, which adds __counted_by() and requires ->datalen > > to match the number of elements in ->data. > > > > Currently, that is not the case because ->data includes an extra NUL > > despite never being used as a C string. Removing the unused terminator > > makes the length match the allocation size and allows adding the > > __counted_by() annotation. > > > > I can fold this into the __counted_by() patch if you prefer. > > I understand that part, but I don't get where the data from which > the terminating character is removed, is used. Only other access > I saw was freeing it, the rest of the callback seem to looking > at the error, not the data.. ->data and ->datalen are used in multiple places. For example, in dns_query() in net/dns_resolver/dns_query.c: upayload = user_key_payload_locked(rkey); len = upayload->datalen; if (_result) { ret = -ENOMEM; *_result = kmemdup_nul(upayload->data, len, GFP_KERNEL); if (!*_result) goto put; } In cifs_set_cifscreds() in fs/smb/client/connect.c: /* find first : in payload */ payload = upayload->data; delim = strnchr(payload, upayload->datalen, ':');