Received-SPF: pass (google.com: domain of linux-kernel+bounces-162779-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 29 Apr 2024 10:47:46 -0700
From: Dan Williams <dan.j.williams@intel.com>
To: Lukas Wunner <lukas@wunner.de>, Dan Williams <dan.j.williams@intel.com>
CC: <gregkh@linuxfoundation.org>, Pierre-Louis Bossart
	<pierre-louis.bossart@linux.intel.com>, Marc Herbert
	<marc.herbert@intel.com>, "Rafael J. Wysocki" <rafael@kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-pci@vger.kernel.org>,
	<linux-coco@lists.linux.dev>, <alsa-devel@alsa-project.org>
Subject: Re: [PATCH 1/3] sysfs: Fix crash on empty group attributes array
Message-ID: <662fdd4283b0b_1487294a7@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <170863444851.1479840.10249410842428140526.stgit@dwillia2-xfh.jf.intel.com>
 <170863445442.1479840.1818801787239831650.stgit@dwillia2-xfh.jf.intel.com>
 <ZiYrzzk9Me1aksmE@wunner.de>
 <662beb6ad280f_db82d29458@dwillia2-xfh.jf.intel.com.notmuch>
 <Ziv9984CJeQ4muZy@wunner.de>
 <662d2ca522cc6_b6e02942d@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <Zi1qtKNwcyydP4c2@wunner.de>
 <662d6f24528d7_b6e0294d2@dwillia2-mobl3.amr.corp.intel.com.notmuch>
 <Zi4gK8rs7jjdJOh8@wunner.de>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Zi4gK8rs7jjdJOh8@wunner.de>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?q5WigdSkbMQObc5ZoEOA72cCFwIdC7fhbNFDt/k4ckQzUD0O76fPtre/gf+/?=
 =?us-ascii?Q?R6IurGllebd1zIYpMSNjhThntE/qwjS4hBLslF7zk608QPVDUw0S66YGAhQR?=
 =?us-ascii?Q?OPgB5e8Lh/HLkMBnX461gXc+7gKTeQDhe4Ty3HqHSqPemeEn8Zl9F46pw3Az?=
 =?us-ascii?Q?pQklmLwfwCRuMVuq0vOGF2THdTtdcfeJ5V++AznhwxMf8T+Ok9r8W1Fa8yzc?=
 =?us-ascii?Q?IpoloFQBiTCNDQi+sK4mpP4XiDET+g6q2k/Hf6FI3uFhF1BfjcmqUZjnLaxD?=
 =?us-ascii?Q?srEBRAKJ4EkKzHo6rnTvhi3Ndgmoaezn86FwUuRs9uQatsO8y0mzJ295t7yA?=
 =?us-ascii?Q?qWMxWCU58DHic6EwljkiGSQeP6h0B1rTLTHHCPIj76qgLwwumUBcfvqom86G?=
 =?us-ascii?Q?T9p6B/uaKV6bfuwd2J/MBSDIfqZSvNTTSTw6e839bE1yvtn1yNtuZ/VlUR7m?=
 =?us-ascii?Q?0eXL4G7dXnnIbRnvvX8Gpp4jIsNHPFCIXPMQs+qrkRJ2bBGdxGxrCzwmntxi?=
 =?us-ascii?Q?+GbwvKgaujiXFUuBzo2q+fV0ZQTR7M77Ij8IkbX5TBiM0HEOtjHOew33VA28?=
 =?us-ascii?Q?b9uruo/SZnR+kpKqDOYCWaqMyiNbPocWvkQV+Nst4jrxp1uOJGUs3KMEJVhR?=
 =?us-ascii?Q?FeCnxVfGql9q/5fgByk0CVYbW10phCFsHQqXr4mQhKw5z1q+xnypjy8Mx6By?=
 =?us-ascii?Q?Eh9KrVPGTaVtpofifOLzhndNa0V7KzRDbjlyXYn/z6nJzvfRSZv3MVKVIscK?=
 =?us-ascii?Q?5Am5JmHU03uFAf+0RihzqtfofrS70wC7A4iE/nihHjFcNUj5c5ghpwpRPSNu?=
 =?us-ascii?Q?L4JDEFI+yr3kHJu+YOSQT368fyqEmrfYRtsCRRL81A7XCYWE6GjGN6b8b3GJ?=
 =?us-ascii?Q?jcK/emnFSjHA8nUZ4CvtYcpfAAc3QaDzXIV68mjVqHSzfVC64LgzHG22E/LA?=
 =?us-ascii?Q?C8x6+DM2gqEvrNFm+K9QrNuDdE0/YdPQzYHsAYafeoRa95i4sYjwBQmnPUnU?=
 =?us-ascii?Q?MpaoZc9BxkNKsGgfzlPxgzkTeiS8DKmSlGl+9rk3VP+0QYNpjpE30ln1amFJ?=
 =?us-ascii?Q?Cqmgs6vorF670xpBCxRFH/iVTPYcwe6dnsUk81fAQVZa4K/whcWI1Dp3eTxp?=
 =?us-ascii?Q?Xuv4jpPOs4ffUl/ysm+fdiv2rkTeOkHcgq5E1P0u/o2mPb1BNLnZx9Be7R4c?=
 =?us-ascii?Q?dUuJPhkO4dGGotu0cRL/OWh2LNLZLewMCvD6LJ81mX4Fpstwb/FEqA2al2GI?=
 =?us-ascii?Q?N+lrokIWQyTu7vSvViJ8s0g2S7oDsS6lOP3GEtTgJ7Yf4uCnZmHOsE3ANeJG?=
 =?us-ascii?Q?dHO8RfJIiWTIt5BHxlLrtN0P+CwolkpGCGpWZSdQsjOPmY1vMbqqt9aFekjN?=
 =?us-ascii?Q?LUzcArFKF2x5MT/jnq0GZ+qwn+TWmB9YHkqiakiUBHrc74iKeTAylQIdqDOe?=
 =?us-ascii?Q?+9zyzB2vce6/ACEE80hTEDnaZe9ResLsQo5FcG3DPveUsd56qgZOQPKiGzi3?=
 =?us-ascii?Q?tMBrwaIcViWQk1wCXDoU6saHxiFCTvAa882L1Tk2PzH4Svsu4M/goswTAq2T?=
 =?us-ascii?Q?Il3CjYOKU53ZyrZpsPLP3dFowUpyebais/P5WUGS8dYjc+68k/3BcSyOo7zE?=
 =?us-ascii?Q?WA=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 2fa1bc50-5749-498a-1dc0-08dc68747c32
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2024 17:47:49.0411
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: tpOY1n4FABfLQ8V2amT8j72hFtjPjdAToRWJif6EgOD5zmT8CTb7rRIUTfEjyQ9DFoazm1cY0StWTlBqxIKVou9/QAD+5P5eW7gCn4ZmylU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7133
X-OriginatorOrg: intel.com

Lukas Wunner wrote:
> On Sat, Apr 27, 2024 at 02:33:24PM -0700, Dan Williams wrote:
> > Lukas Wunner wrote:
> > > Perhaps an optional ->is_group_visible() callback in struct attribute_group
> > > which gets passed only the struct kobject pointer?
> > > 
> > > At least for PCI device authentication, that would be sufficient.
> > > I could get from the kobject to the corresponding struct device,
> > > then determine whether the device supports authentication or not.
> > > 
> > > Because it's a new, optional callback, there should be no compatibility
> > > issues.  The SYSFS_GROUP_INVISIBLE return code from the ->is_visible()
> > > call for individual attributes would not be needed then, at least in my
> > > use case.
> > 
> > That's where I started with this, but decided it was overkill to
> > increase the size of that data structure globally for a small number of
> > use cases.
> 
> Memory is cheap and memory-constrained devices can set CONFIG_SYSFS=n.

That sounds severe, but point taken that someone could config-off the
cases that need this extension.

> There aren't that many struct attribute_groups and this is just
> 8 additional bytes on a 64-bit machine.  (There are way more
> struct attribute than struct attribute_group.)  The contortions
> necessary to overload individual attribute ->is_visible() callbacks
> to also govern the group's visibility aren't worth it.

I agree that most systems would not care about growing this structure,
but the same is true for almost all other data structure growth in the
kernel. It is a typical kernel pastime to squeeze functionality into
existing data structures.

> Having an ->is_group_visible() callback has the additional benefit that
> the mode of directories no longer needs to be hardcoded to 0755 in
> sysfs_create_dir_ns(), but can be set to, say, 0500 or 0700 or 0511,
> depending on the use case.  So more flexibility there as well.

Unnecessary growth is unnecessary growth. In this case all the known use
cases can use the SYSFS_GROUP_INVISIBLE flag returned from is_visible().
The awkwardness around cases that want to have an empty attributes array
and invisible group directory is noted and puts the solution on notice
for running afoul of the sunk cost fallacy in the future.