All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Niklas Schnelle <schnelle@linux.ibm.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org, Pierre Morel <pmorel@linux.ibm.com>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	Viktor Mihajlovski <mihajlov@linux.ibm.com>
Subject: Re: [RFC 1/1] s390/pci: expose UID checking state in sysfs
Date: Thu, 14 Jan 2021 14:58:54 +0100	[thread overview]
Message-ID: <YABOHuejsuriwSPn@kroah.com> (raw)
In-Reply-To: <20210114134453.bkfik4zjt5ehz6d5@wittgenstein>

On Thu, Jan 14, 2021 at 02:44:53PM +0100, Christian Brauner wrote:
> On Thu, Jan 14, 2021 at 02:20:10PM +0100, Niklas Schnelle wrote:
> > 
> > 
> > On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
> > > On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
> > >> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> > >>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
> > >>>> We use the UID of a zPCI adapter, or the UID of the function zero if
> > >>>> there are multiple functions in an adapter, as PCI domain if and only if
> > >>>> UID Checking is turned on.
> > >>>> Otherwise we automatically generate domains as devices appear.
> > >>>>
> > >>>> The state of UID Checking is thus essential to know if the PCI domain
> > >>>> will be stable, yet currently there is no way to access this information
> > >>>> from userspace.
> > >>>> So let's solve this by showing the state of UID checking as a sysfs
> > >>>> attribute in /sys/bus/pci/uid_checking
> > > 
> > >>>> +/* Global zPCI attributes */
> > >>>> +static ssize_t uid_checking_show(struct kobject *kobj,
> > >>>> +				 struct kobj_attribute *attr, char *buf)
> > >>>> +{
> > >>>> +	return sprintf(buf, "%i\n", zpci_unique_uid);
> > >>>> +}
> > >>>> +
> > >>>> +static struct kobj_attribute sys_zpci_uid_checking_attr =
> > >>>> +	__ATTR(uid_checking, 0444, uid_checking_show, NULL);
> > >>>
> > >>> Use DEVICE_ATTR_RO instead of __ATTR.
> > >>
> > >> It's my understanding that DEVICE_ATTR_* is only for
> > >> per device attributes. This one is global for the entire
> > >> Z PCI. I just tried with BUS_ATTR_RO instead
> > >> and that works but only if I put the attribute at
> > >> /sys/bus/pci/uid_checking instead of with a zpci
> > >> subfolder. This path would work for us too, we
> > >> currently don't have any other global attributes
> > >> that we are planning to expose but those could of
> > >> course come up in the future.
> > > 
> > > Ah, I missed the fact that this is a kobj_attribute, not a
> > > device_attribute.  Maybe KERNEL_ATTR_RO()?  Very few uses so far, but
> > > seems like it might fit?
> > > 
> > > Bjorn
> > > 
> > 
> > KERNEL_ATTR_* is currently not exported in any header. After
> > adding it to include/linuc/sysfs.h it indeed works perfectly.
> > Adding Christian Brauner as suggested by get_maintainers for
> > their opinion. I'm of course willing to provide a patch
> 
> Hey Niklas et al. :)
> 
> I think this will need input from Greg. He should be best versed in
> sysfs attributes. The problem with KERNEL_ATTR_* to me seems that it's
> supposed to be kernel internal. Now, that might just be a matter of
> renaming the macro but let's see whether Greg has any better idea or
> more questions. :)

The big question is, why are you needing this?

No driver or driver subsystem should EVER be messing with a "raw"
kobject like this.  Just use the existing DEVICE_* macros instead
please.

If you are using a raw kobject, please ask me how to do this properly,
as that is something that should NEVER show up in the /sys/devices/*
tree.  Otherwise userspace tools will break.

thanks,

greg k-h

  reply	other threads:[~2021-01-14 13:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11  9:38 [RFC 0/1] PCI: s390 global attribute "UID Checking" Niklas Schnelle
2021-01-11  9:38 ` [RFC 1/1] s390/pci: expose UID checking state in sysfs Niklas Schnelle
2021-01-12 21:50   ` Bjorn Helgaas
2021-01-13  7:47     ` Niklas Schnelle
2021-01-13 18:55       ` Bjorn Helgaas
2021-01-14 13:20         ` Niklas Schnelle
2021-01-14 13:44           ` Christian Brauner
2021-01-14 13:58             ` Greg Kroah-Hartman [this message]
2021-01-14 15:06               ` Niklas Schnelle
2021-01-14 15:17                 ` Greg Kroah-Hartman
2021-01-14 15:51                   ` Niklas Schnelle
2021-01-14 16:14                     ` Greg Kroah-Hartman
2021-01-15 11:20                       ` Niklas Schnelle
2021-01-15 12:02                         ` Greg Kroah-Hartman
2021-01-15 15:29                         ` Bjorn Helgaas
2021-01-15 16:15                           ` Niklas Schnelle
2021-01-21 15:31                           ` Niklas Schnelle
2021-01-21 15:54                             ` Bjorn Helgaas
2021-01-21 16:11                               ` Greg Kroah-Hartman
2021-01-21 17:04                               ` Niklas Schnelle
2021-01-21 17:28                                 ` Greg Kroah-Hartman
2021-01-21 17:43                                   ` Niklas Schnelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YABOHuejsuriwSPn@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mihajlov@linux.ibm.com \
    --cc=oberpar@linux.ibm.com \
    --cc=pmorel@linux.ibm.com \
    --cc=schnelle@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.