From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D8B5F2F3C13; Tue, 3 Mar 2026 05:14:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772514859; cv=none; b=VPU5oa76a1pQD/NODM4fjp1VF5Iit+/e5v3nlbWPVO9AbUUkki+olOggeIItFy6zmGb5a9ALLiPTIaUSLQyQEAV72w7XrAPAYeweWxnNzgbM3qByaI2l3BmnkLdsEaqZRtwxsdMX/crNzfOauVdxCfLnlpGAJcH4h4tunDRCKqU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772514859; c=relaxed/simple; bh=7m9ZjhjRNAg9hXnTGJRUAFGz0aoFKhEAaHxEknmS5z8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OvH7HtmNQyZPd4UCEmAt3mqVaXUK2iO4UlbyoohYybZAcx492hNJhtAfVjhJrP9wHRgtrs7aYtHJt8Uy/A0PFSc1TJKDlPxY/+34yyT2vdkX9NprJAKIn6RC6yseiji4Wi56LGwaL/25n4DqUrgWg2nD/jch2NK3VitGesIuAjY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H9NiNSYL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H9NiNSYL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA1E9C116C6; Tue, 3 Mar 2026 05:14:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772514859; bh=7m9ZjhjRNAg9hXnTGJRUAFGz0aoFKhEAaHxEknmS5z8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=H9NiNSYLwpPLk3ImbcKZXjrBIlZ1C2xhJHG/JeKnqarBhLMLVMAGJxP5dHJOtH66l 3FlJEq+W2uKDRxQqNaD+84AYOghJF8bTStPM+1f12N+tiAOzsU9pIyUzUPvKoS6PnY lQLRPMAN09LW8R9B6eIA/OJK3/fQIVYQ7iioKMlTBeAUN8SIywTcUE9VH9Hf3FL/qz 6yWs0RwjqxrX36Vgga6SeZndHPT580yNa5zDG1X/KORyMSqCr+pO75UQGPCgj7TLNx Ywmj0Hp1aYULSECuvDmS3n8912JmBNCN+SjjSh2I9jCpmzbcHJ6Oazg7462CAVcEdy c0HRmsfMTKIIg== Date: Mon, 2 Mar 2026 21:14:19 -0800 From: "Darrick J. Wong" To: Bill Wendling Cc: linux-kernel@vger.kernel.org, Carlos Maiolino , Gogul Balakrishnan , Arman Hasanzadeh , Kees Cook , linux-xfs@vger.kernel.org, codemender-patching+linux@google.com Subject: Re: [PATCH] xfs: annotate struct xfs_attr_list_context with __counted_by_ptr Message-ID: <20260303051419.GD57948@frogsfrogsfrogs> References: <20260303015646.2796170-1-morbo@google.com> Precedence: bulk X-Mailing-List: linux-xfs@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: <20260303015646.2796170-1-morbo@google.com> On Tue, Mar 03, 2026 at 01:56:35AM +0000, Bill Wendling wrote: > Add the `__counted_by_ptr` attribute to the `buffer` field of `struct > xfs_attr_list_context`. This field is used to point to a buffer of > size `bufsize`. > > The `buffer` field is assigned in: > 1. `xfs_ioc_attr_list` in `fs/xfs/xfs_handle.c` > 2. `xfs_xattr_list` in `fs/xfs/xfs_xattr.c` > 3. `xfs_getparents` in `fs/xfs/xfs_handle.c` (implicitly initialized to NULL) > > In `xfs_ioc_attr_list`, `buffer` was assigned before `bufsize`. Reorder > them to ensure `bufsize` is set before `buffer` is assigned, although > no access happens between them. > > In `xfs_xattr_list`, `buffer` was assigned before `bufsize`. Reorder > them to ensure `bufsize` is set before `buffer` is assigned. > > In `xfs_getparents`, `buffer` is NULL (from zero initialization) and > remains NULL. `bufsize` is set to a non-zero value, but since `buffer` > is NULL, no access occurs. > > In all cases, the pointer `buffer` is not accessed before `bufsize` is > set. > > This patch was generated by CodeMender and reviewed by Bill Wendling. > Tested by running xfstests. > > Signed-off-by: Bill Wendling > --- > Cc: Carlos Maiolino > Cc: "Darrick J. Wong" > Cc: Gogul Balakrishnan > Cc: Arman Hasanzadeh > Cc: Kees Cook > Cc: linux-xfs@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Cc: codemender-patching+linux@google.com > --- > fs/xfs/libxfs/xfs_attr.h | 2 +- > fs/xfs/xfs_handle.c | 2 +- > fs/xfs/xfs_xattr.c | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/xfs/libxfs/xfs_attr.h b/fs/xfs/libxfs/xfs_attr.h > index 8244305949de..4cd161905288 100644 > --- a/fs/xfs/libxfs/xfs_attr.h > +++ b/fs/xfs/libxfs/xfs_attr.h > @@ -55,7 +55,7 @@ struct xfs_attr_list_context { > struct xfs_trans *tp; > struct xfs_inode *dp; /* inode */ > struct xfs_attrlist_cursor_kern cursor; /* position in list */ > - void *buffer; /* output buffer */ > + void *buffer __counted_by_ptr(bufsize); /* output buffer */ Looks reasonable, but ... how hard will it be to port __counted_by_ptr to userspace? Files in fs/xfs/libxfs/ get ported to userspace xfs. I see that it maps to an __attribute__. Does that get us any new gcc typechecking magic? --D > > /* > * Abort attribute list iteration if non-zero. Can be used to pass > diff --git a/fs/xfs/xfs_handle.c b/fs/xfs/xfs_handle.c > index d1291ca15239..2b8617ae7ec2 100644 > --- a/fs/xfs/xfs_handle.c > +++ b/fs/xfs/xfs_handle.c > @@ -443,8 +443,8 @@ xfs_ioc_attr_list( > context.dp = dp; > context.resynch = 1; > context.attr_filter = xfs_attr_filter(flags); > - context.buffer = buffer; > context.bufsize = round_down(bufsize, sizeof(uint32_t)); > + context.buffer = buffer; > context.firstu = context.bufsize; > context.put_listent = xfs_ioc_attr_put_listent; > > diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c > index a735f16d9cd8..544213067d59 100644 > --- a/fs/xfs/xfs_xattr.c > +++ b/fs/xfs/xfs_xattr.c > @@ -332,8 +332,8 @@ xfs_vn_listxattr( > memset(&context, 0, sizeof(context)); > context.dp = XFS_I(inode); > context.resynch = 1; > - context.buffer = size ? data : NULL; > context.bufsize = size; > + context.buffer = size ? data : NULL; > context.firstu = context.bufsize; > context.put_listent = xfs_xattr_put_listent; > > -- > 2.53.0.473.g4a7958ca14-goog > >