All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Kimberly Brown <kimbrownkd@gmail.com>
Cc: Michael Kelley <mikelley@microsoft.com>,
	Long Li <longli@microsoft.com>,
	Sasha Levin <Alexander.Levin@microsoft.com>,
	Stephen Hemminger <sthemmin@microsoft.com>,
	Dexuan Cui <decui@microsoft.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>,
	linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used
Date: Mon, 4 Mar 2019 08:38:42 +0100	[thread overview]
Message-ID: <20190304073842.GD23573@kroah.com> (raw)
In-Reply-To: <20190303211128.GA2071@ubu-Virtual-Machine>

On Sun, Mar 03, 2019 at 04:11:28PM -0500, Kimberly Brown wrote:
> On Sun, Mar 03, 2019 at 09:05:43AM +0100, Greg KH wrote:
> > On Fri, Mar 01, 2019 at 02:18:24PM -0500, Kimberly Brown wrote:
> > > +/*
> > > + * Channel-level attribute_group callback function. Returns the permission for
> > > + * each attribute, and returns 0 if an attribute is not visible.
> > > + */
> > > +static umode_t vmbus_chan_attr_is_visible(struct kobject *kobj,
> > > +					  struct attribute *attr, int idx)
> > > +{
> > > +	const struct vmbus_channel *channel =
> > > +		container_of(kobj, struct vmbus_channel, kobj);
> > > +
> > > +	/* Hide the monitor attributes if the monitor mechanism is not used. */
> > > +	if (!channel->offermsg.monitor_allocated &&
> > > +	    (attr == &chan_attr_pending.attr ||
> > > +	     attr == &chan_attr_latency.attr ||
> > > +	     attr == &chan_attr_monitor_id.attr))
> > > +		return 0;
> > > +
> > > +	return attr->mode;
> > > +}
> > > +
> > > +static struct attribute_group vmbus_chan_group = {
> > > +	.attrs = vmbus_chan_attrs,
> > > +	.is_visible = vmbus_chan_attr_is_visible
> > > +};
> > > +
> > >  static struct kobj_type vmbus_chan_ktype = {
> > >  	.sysfs_ops = &vmbus_chan_sysfs_ops,
> > >  	.release = vmbus_chan_release,
> > > -	.default_attrs = vmbus_chan_attrs,
> > 
> > Why did you remove this line?
>  
> I removed the default attributes because vmbus_chan_attrs contains
> non-default attributes. You suggested that I use one attribute_group and
> an is_visible() callback for the device-level attributes (see
> https://lore.kernel.org/lkml/20190226081848.GA15659@kroah.com/). I
> assumed (possibly incorrectly) that I should do the same for these
> channel-level attributes.

That is fine to have a callback, but why did you have to remove the
default attribute pointer?  The two should have nothing to do with each
other.

> > >  };
> > >  
> > >  /*
> > > @@ -1571,6 +1624,12 @@ int vmbus_add_channel_kobj(struct hv_device *dev, struct vmbus_channel *channel)
> > >  	if (ret)
> > >  		return ret;
> > >  
> > > +	ret = sysfs_create_group(kobj, &vmbus_chan_group);
> > 
> > Why are you adding these "by hand"?  What was wrong with using the
> > default attribute group pointer?  You also are not removing the
> > attributes :(
> 
> Are you referring to default_attrs in kobj_type? It's not an
> attribute_group pointer, it's a pointer to an attribute pointer array.
> The problem with using default_attrs is that all of the attributes are
> visible.

It shouldn't, the is_visable() callback will be called on each attribute
when the group is created by the core.  Did that not work properly when
you tested this?

> I'm fairly certain that the monitor attributes are being removed.
> sysfs_create_group() uses the attribute_group's is_visible() callback to
> control the attribute visibility. And, when I look at the sysfs files, I
> can see that the monitor sysyfs files are removed.

I mean you are not removing the group when the device goes away, not
that the individual files are not present.  If you leave the pointer to
default_attributes there, the core will properly remove the sysfs
attributes when the device is removed from the system.  Otherwise you
just "get lucky" if the attributes are removed or not.

> In v3, I proposed moving the monitor attributes to a special
> attribute_group and adding that group manually when needed. Do you
> prefer that approach for the channel-level monitor attributes?

No need for a special group here, just use the is_visable() callback
like you currently are, all should be fine.  I think you are adding more
code than you need to in order to get this to all work properly :)

thanks,

greg k-h

  reply	other threads:[~2019-03-04  7:38 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  9:57 [PATCH 0/2] Drivers: hv: vmbus: Fix sysfs functions that display monitor id and page data Kimberly Brown
2019-02-08  9:58 ` [PATCH 1/2] Drivers: hv: vmbus: Change server monitor_pages index to 0 Kimberly Brown
2019-02-08 22:28   ` Stephen Hemminger
2019-02-08 10:01 ` [PATCH 2/2] Drivers: hv: vmbus: Display nothing in sysfs if monitor_allocated not set Kimberly Brown
2019-02-08 22:32   ` Stephen Hemminger
2019-02-11  7:01     ` Kimberly Brown
2019-02-11 18:02       ` Stephen Hemminger
2019-02-14  6:11         ` Kimberly Brown
2019-02-14 19:50           ` Stephen Hemminger
2019-02-19  5:37 ` [PATCH v2 0/2] Drivers: hv: vmbus: Fix sysfs functions that display monitor id and page data Kimberly Brown
2019-02-19  5:38   ` [PATCH v2 1/2] Drivers: hv: vmbus: Change server monitor_pages index to 0 Kimberly Brown
2019-02-20 14:35     ` Michael Kelley
     [not found] ` <cover.1550554279.git.kimbrownkd@gmail.com>
2019-02-19  5:38   ` [PATCH v2 2/2] Drivers: hv: vmbus: Return -EINVAL if monitor_allocated not set Kimberly Brown
2019-02-20 16:11     ` Michael Kelley
2019-02-26  5:35     ` [PATCH v3] Drivers: hv: vmbus: Expose monitor data when channel uses monitor pages Kimberly Brown
2019-02-26  8:18       ` Greg KH
2019-03-01 19:18       ` [PATCH v4] Drivers: hv: vmbus: Expose monitor data only when monitor pages are used Kimberly Brown
2019-03-02 18:39         ` Michael Kelley
2019-03-03 21:40           ` Kimberly Brown
2019-03-03  8:05         ` Greg KH
2019-03-03 21:11           ` Kimberly Brown
2019-03-04  7:38             ` Greg KH [this message]
2019-03-08 22:46         ` [PATCH v5] " Kimberly Brown
2019-03-09  7:21           ` Greg KH
2019-03-12  0:04             ` Kimberly Brown
2019-03-19  4:04           ` [PATCH v6] " Kimberly Brown
2019-03-19  9:26             ` Greg KH
2019-03-20 20:18             ` Michael Kelley
2019-03-21  3:57             ` Sasha Levin
2019-03-21 15:55               ` Michael Kelley

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=20190304073842.GD23573@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Alexander.Levin@microsoft.com \
    --cc=decui@microsoft.com \
    --cc=haiyangz@microsoft.com \
    --cc=kimbrownkd@gmail.com \
    --cc=kys@microsoft.com \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longli@microsoft.com \
    --cc=mikelley@microsoft.com \
    --cc=sthemmin@microsoft.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.