All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Vishal Verma <vishal.l.verma@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Oscar Salvador" <osalvador@suse.de>,
	<linux-kernel@vger.kernel.org>, <nvdimm@lists.linux.dev>,
	<linux-cxl@vger.kernel.org>, David Hildenbrand <david@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Huang Ying <ying.huang@intel.com>, <linux-mm@kvack.org>,
	Joao Martins <joao.m.martins@oracle.com>
Subject: Re: [PATCH v6 2/4] dax/bus: Use guard(device) in sysfs attribute helpers
Date: Fri, 15 Dec 2023 09:15:45 -0800	[thread overview]
Message-ID: <657c89c16d5f5_269bd294bd@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <2023121515-litigate-finished-76dd@gregkh>

Greg Kroah-Hartman wrote:
> On Thu, Dec 14, 2023 at 10:25:27PM -0700, Vishal Verma wrote:
> > Use the guard(device) macro to lock a 'struct device', and unlock it
> > automatically when going out of scope using Scope Based Resource
> > Management semantics. A lot of the sysfs attribute writes in
> > drivers/dax/bus.c benefit from a cleanup using these, so change these
> > where applicable.
> 
> Wait, why are you needing to call device_lock() at all here?  Why is dax
> special in needing this when no other subsystem requires it?
> 
> > 
> > Cc: Joao Martins <joao.m.martins@oracle.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
> > ---
> >  drivers/dax/bus.c | 143 ++++++++++++++++++++++--------------------------------
> >  1 file changed, 59 insertions(+), 84 deletions(-)
> > 
> > diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> > index 1ff1ab5fa105..6226de131d17 100644
> > --- a/drivers/dax/bus.c
> > +++ b/drivers/dax/bus.c
> > @@ -294,13 +294,10 @@ static ssize_t available_size_show(struct device *dev,
> >  		struct device_attribute *attr, char *buf)
> >  {
> >  	struct dax_region *dax_region = dev_get_drvdata(dev);
> > -	unsigned long long size;
> >  
> > -	device_lock(dev);
> > -	size = dax_region_avail_size(dax_region);
> > -	device_unlock(dev);
> > +	guard(device)(dev);
> 
> You have a valid device here, why are you locking it?  How can it go
> away?  And if it can, shouldn't you have a local lock for it, and not
> abuse the driver core lock?

Yes, this is a driver-core lock abuse written by someone who should have
known better. And yes, a local lock to protect the dax_region resource
tree should replace this. A new rwsem to synchronize all list walks
seems appropriate.

  reply	other threads:[~2023-12-15 17:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-15  5:25 [PATCH v6 0/4] Add DAX ABI for memmap_on_memory Vishal Verma
2023-12-15  5:25 ` [PATCH v6 1/4] Documentatiion/ABI: Add ABI documentation for sys-bus-dax Vishal Verma
2023-12-15  5:25 ` [PATCH v6 2/4] dax/bus: Use guard(device) in sysfs attribute helpers Vishal Verma
2023-12-15  5:56   ` Matthew Wilcox
2023-12-15  6:33     ` Verma, Vishal L
2023-12-15 16:14       ` gregkh
2023-12-15  7:27   ` Greg Kroah-Hartman
2023-12-15 17:15     ` Dan Williams [this message]
2023-12-15 17:32       ` Verma, Vishal L
2023-12-15 17:53         ` gregkh
2023-12-19 15:27   ` Jonathan Cameron
2023-12-15  5:25 ` [PATCH v6 3/4] mm/memory_hotplug: export mhp_supports_memmap_on_memory() Vishal Verma
2023-12-15  5:25 ` [PATCH v6 4/4] dax: add a sysfs knob to control memmap_on_memory behavior Vishal Verma
2023-12-15  7:53   ` Huang, Ying

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=657c89c16d5f5_269bd294bd@dwillia2-mobl3.amr.corp.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=joao.m.martins@oracle.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nvdimm@lists.linux.dev \
    --cc=osalvador@suse.de \
    --cc=vishal.l.verma@intel.com \
    --cc=ying.huang@intel.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.