> Lemme be clear: I'm being the devil's advocate here on purpose because
> I want to make sure we don't walk into some privacy thing we haven't
> thought about at the time.

Sure. It's good to look at this from other perspectives.  There may be some
software-as-a-service thing where the provider of the service doesn't want
a simple way to reveal that jobs are being migrated around a pool of systems.

> So I guess 0400, root:root would be the correct thing to do - admins can
> then change permissions later or so. Rather than making it readable by
> everyone by default and leaving it to people to tighten it after boot.

Yup.  If someone has a tool that needs ppin, but they don't want to run
as root they can just add either of:

	chown notrootadmin /sys/devices/system/cpu/cpu*/topology/ppin

or

	chmod 444 /sys/devices/system/cpu/cpu*/topology/ppin

to some /etc/rc* file.

-Tony

On Mon, Jan 31, 2022 at 07:29:55PM +0000, Luck, Tony wrote:
> Yup.  If someone has a tool that needs ppin, but they don't want to run
> as root they can just add either of:

...

Ok then. I guess I can queue your next version and we'll see what
happens.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

> Ok then. I guess I can queue your next version and we'll see what
> happens.

Thanks. I'll move those bogus initializations of .msr_ppin to the right
patch. Add Greg's Ack's and repost a new version after re-testing.

-Tony

Systems that do not support a Protected Processor Identification Number
currently report:

	# cat /sys/devices/system/cpu/cpu0/topology/ppin
	0x0

which is confusing/wrong.

Add a ".is_visible" function to suppress inclusion of the ppin file.

Fixes: ab28e944197f ("topology/sysfs: Add PPIN in sysfs under cpu topology")
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
 drivers/base/topology.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/base/topology.c b/drivers/base/topology.c
index e9d1efcda89b..706dbf8bf249 100644
--- a/drivers/base/topology.c
+++ b/drivers/base/topology.c
@@ -152,9 +152,21 @@ static struct attribute *default_attrs[] = {
 	NULL
 };
 
+static umode_t topology_is_visible(struct kobject *kobj,
+				   struct attribute *attr, int unused)
+{
+	struct device *dev = kobj_to_dev(kobj);
+
+	if (attr == &dev_attr_ppin.attr && !topology_ppin(dev->id))
+		return 0;
+
+	return attr->mode;
+}
+
 static const struct attribute_group topology_attr_group = {
 	.attrs = default_attrs,
 	.bin_attrs = bin_attrs,
+	.is_visible = topology_is_visible,
 	.name = "topology"
 };
 
-- 
2.35.1

On Wed,  6 Apr 2022 15:01:50 -0700 Tony Luck <tony.luck@intel.com> wrote:

> Systems that do not support a Protected Processor Identification Number
> currently report:
> 
> 	# cat /sys/devices/system/cpu/cpu0/topology/ppin
> 	0x0
> 
> which is confusing/wrong.
> 
> Add a ".is_visible" function to suppress inclusion of the ppin file.
> 
> --- a/drivers/base/topology.c
> +++ b/drivers/base/topology.c
> @@ -152,9 +152,21 @@ static struct attribute *default_attrs[] = {
>  	NULL
>  };
>  
> +static umode_t topology_is_visible(struct kobject *kobj,
> +				   struct attribute *attr, int unused)
> +{
> +	struct device *dev = kobj_to_dev(kobj);
> +
> +	if (attr == &dev_attr_ppin.attr && !topology_ppin(dev->id))
> +		return 0;
> +
> +	return attr->mode;
> +}
> +
>  static const struct attribute_group topology_attr_group = {
>  	.attrs = default_attrs,
>  	.bin_attrs = bin_attrs,
> +	.is_visible = topology_is_visible,
>  	.name = "topology"
>  };

x86_64 allnoconfig:

drivers/base/topology.c: In function 'topology_is_visible':
drivers/base/topology.c:158:24: warning: unused variable 'dev' [-Wunused-variable]
  158 |         struct device *dev = kobj_to_dev(kobj);
      |                        ^~~

I suggest this be fixed in the topology_ppin() stub implementation.  Do
it as a nice inlined C function which avoids such problems.  Rather
than as a crappy macro which causes them...

> I suggest this be fixed in the topology_ppin() stub implementation.  Do
> it as a nice inlined C function which avoids such problems.  Rather
> than as a crappy macro which causes them...

Greg already fixed this in his tree by dropping the local variable.

Fix should propagate to linux-next today.

-Tony