From: gregkh@linuxfoundation.org <gregkh@linuxfoundation.org>
To: linux-aspeed@lists.ozlabs.org
Subject: [PATCH v3 06/13] peci: Add device detection
Date: Tue, 16 Nov 2021 07:26:28 +0100 [thread overview]
Message-ID: <YZNPFGPXfCLfJMq3@kroah.com> (raw)
In-Reply-To: <368c990c30c5bacde15ac4bce5db8389aea3ec9c.camel@intel.com>
On Mon, Nov 15, 2021 at 10:35:23PM +0000, Winiarska, Iwona wrote:
> On Mon, 2021-11-15 at 19:49 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 15, 2021 at 07:25:45PM +0100, Iwona Winiarska wrote:
> > > +void peci_device_destroy(struct peci_device *device)
> > > +{
> > > +???????bool killed;
> > > +
> > > +???????device_lock(&device->dev);
> > > +???????killed = kill_device(&device->dev);
> >
> > Eeek, why call this?
> >
> > > +???????device_unlock(&device->dev);
> > > +
> > > +???????if (!killed)
> > > +???????????????return;
> >
> > What happened if something changed after you unlocked it?
>
> We either killed it, or the other caller killed it.
>
> >
> > Why is kill_device() required at all?? That's a very rare function to
> > call, and one that only one "bus" calls today because it is very
> > special (i.e. crazy and broken...)
>
> It's used to avoid double-delete in case of races between peci_controller
> unregister and "manually" removing the device using sysfs (pointed out by Dan in
> v2). We're calling peci_device_destroy() in both callsites.
> Other way to solve it would be to just have a peci-specific lock, but
> kill_device seemed to be well suited for the problem at hand.
> Do you suggest to remove it and just go with the lock?
Yes please, remove it and use the lock.
Also, why are you required to have a sysfs file that can remove the
device? Who wants that?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "Winiarska, Iwona" <iwona.winiarska@intel.com>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
"andrew@aj.id.au" <andrew@aj.id.au>,
"Luck, Tony" <tony.luck@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"d.mueller@elsoft.ch" <d.mueller@elsoft.ch>,
"jdelvare@suse.com" <jdelvare@suse.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"olof@lixom.net" <olof@lixom.net>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"linux@roeck-us.net" <linux@roeck-us.net>,
"zweiss@equinix.com" <zweiss@equinix.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
"bp@alien8.de" <bp@alien8.de>, "joel@jms.id.au" <joel@jms.id.au>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH v3 06/13] peci: Add device detection
Date: Tue, 16 Nov 2021 07:26:28 +0100 [thread overview]
Message-ID: <YZNPFGPXfCLfJMq3@kroah.com> (raw)
In-Reply-To: <368c990c30c5bacde15ac4bce5db8389aea3ec9c.camel@intel.com>
On Mon, Nov 15, 2021 at 10:35:23PM +0000, Winiarska, Iwona wrote:
> On Mon, 2021-11-15 at 19:49 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 15, 2021 at 07:25:45PM +0100, Iwona Winiarska wrote:
> > > +void peci_device_destroy(struct peci_device *device)
> > > +{
> > > + bool killed;
> > > +
> > > + device_lock(&device->dev);
> > > + killed = kill_device(&device->dev);
> >
> > Eeek, why call this?
> >
> > > + device_unlock(&device->dev);
> > > +
> > > + if (!killed)
> > > + return;
> >
> > What happened if something changed after you unlocked it?
>
> We either killed it, or the other caller killed it.
>
> >
> > Why is kill_device() required at all? That's a very rare function to
> > call, and one that only one "bus" calls today because it is very
> > special (i.e. crazy and broken...)
>
> It's used to avoid double-delete in case of races between peci_controller
> unregister and "manually" removing the device using sysfs (pointed out by Dan in
> v2). We're calling peci_device_destroy() in both callsites.
> Other way to solve it would be to just have a peci-specific lock, but
> kill_device seemed to be well suited for the problem at hand.
> Do you suggest to remove it and just go with the lock?
Yes please, remove it and use the lock.
Also, why are you required to have a sysfs file that can remove the
device? Who wants that?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "Winiarska, Iwona" <iwona.winiarska@intel.com>
Cc: "linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"Hansen, Dave" <dave.hansen@intel.com>,
"zweiss@equinix.com" <zweiss@equinix.com>,
"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
"pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"linux@roeck-us.net" <linux@roeck-us.net>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"jdelvare@suse.com" <jdelvare@suse.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
"Luck, Tony" <tony.luck@intel.com>,
"andrew@aj.id.au" <andrew@aj.id.au>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"olof@lixom.net" <olof@lixom.net>
Subject: Re: [PATCH v3 06/13] peci: Add device detection
Date: Tue, 16 Nov 2021 07:26:28 +0100 [thread overview]
Message-ID: <YZNPFGPXfCLfJMq3@kroah.com> (raw)
In-Reply-To: <368c990c30c5bacde15ac4bce5db8389aea3ec9c.camel@intel.com>
On Mon, Nov 15, 2021 at 10:35:23PM +0000, Winiarska, Iwona wrote:
> On Mon, 2021-11-15 at 19:49 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 15, 2021 at 07:25:45PM +0100, Iwona Winiarska wrote:
> > > +void peci_device_destroy(struct peci_device *device)
> > > +{
> > > + bool killed;
> > > +
> > > + device_lock(&device->dev);
> > > + killed = kill_device(&device->dev);
> >
> > Eeek, why call this?
> >
> > > + device_unlock(&device->dev);
> > > +
> > > + if (!killed)
> > > + return;
> >
> > What happened if something changed after you unlocked it?
>
> We either killed it, or the other caller killed it.
>
> >
> > Why is kill_device() required at all? That's a very rare function to
> > call, and one that only one "bus" calls today because it is very
> > special (i.e. crazy and broken...)
>
> It's used to avoid double-delete in case of races between peci_controller
> unregister and "manually" removing the device using sysfs (pointed out by Dan in
> v2). We're calling peci_device_destroy() in both callsites.
> Other way to solve it would be to just have a peci-specific lock, but
> kill_device seemed to be well suited for the problem at hand.
> Do you suggest to remove it and just go with the lock?
Yes please, remove it and use the lock.
Also, why are you required to have a sysfs file that can remove the
device? Who wants that?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
To: "Winiarska, Iwona" <iwona.winiarska@intel.com>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
"jae.hyun.yoo@linux.intel.com" <jae.hyun.yoo@linux.intel.com>,
"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
"andrew@aj.id.au" <andrew@aj.id.au>,
"Luck, Tony" <tony.luck@intel.com>,
"Hansen, Dave" <dave.hansen@intel.com>,
"d.mueller@elsoft.ch" <d.mueller@elsoft.ch>,
"jdelvare@suse.com" <jdelvare@suse.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"olof@lixom.net" <olof@lixom.net>,
"rdunlap@infradead.org" <rdunlap@infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"arnd@arndb.de" <arnd@arndb.de>,
"linux@roeck-us.net" <linux@roeck-us.net>,
"zweiss@equinix.com" <zweiss@equinix.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
"bp@alien8.de" <bp@alien8.de>, "joel@jms.id.au" <joel@jms.id.au>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH v3 06/13] peci: Add device detection
Date: Tue, 16 Nov 2021 07:26:28 +0100 [thread overview]
Message-ID: <YZNPFGPXfCLfJMq3@kroah.com> (raw)
In-Reply-To: <368c990c30c5bacde15ac4bce5db8389aea3ec9c.camel@intel.com>
On Mon, Nov 15, 2021 at 10:35:23PM +0000, Winiarska, Iwona wrote:
> On Mon, 2021-11-15 at 19:49 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 15, 2021 at 07:25:45PM +0100, Iwona Winiarska wrote:
> > > +void peci_device_destroy(struct peci_device *device)
> > > +{
> > > + bool killed;
> > > +
> > > + device_lock(&device->dev);
> > > + killed = kill_device(&device->dev);
> >
> > Eeek, why call this?
> >
> > > + device_unlock(&device->dev);
> > > +
> > > + if (!killed)
> > > + return;
> >
> > What happened if something changed after you unlocked it?
>
> We either killed it, or the other caller killed it.
>
> >
> > Why is kill_device() required at all? That's a very rare function to
> > call, and one that only one "bus" calls today because it is very
> > special (i.e. crazy and broken...)
>
> It's used to avoid double-delete in case of races between peci_controller
> unregister and "manually" removing the device using sysfs (pointed out by Dan in
> v2). We're calling peci_device_destroy() in both callsites.
> Other way to solve it would be to just have a peci-specific lock, but
> kill_device seemed to be well suited for the problem at hand.
> Do you suggest to remove it and just go with the lock?
Yes please, remove it and use the lock.
Also, why are you required to have a sysfs file that can remove the
device? Who wants that?
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-16 6:26 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-15 18:25 [PATCH v3 00/13] Introduce PECI subsystem Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 01/13] dt-bindings: Add generic bindings for PECI Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 02/13] dt-bindings: Add bindings for peci-aspeed Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 03/13] ARM: dts: aspeed: Add PECI controller nodes Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 04/13] peci: Add core infrastructure Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 05/13] peci: Add peci-aspeed controller driver Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-19 11:48 ` Govert Overgaauw
2021-11-15 18:25 ` [PATCH v3 06/13] peci: Add device detection Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:49 ` Greg Kroah-Hartman
2021-11-15 18:49 ` Greg Kroah-Hartman
2021-11-15 18:49 ` Greg Kroah-Hartman
2021-11-15 18:49 ` Greg Kroah-Hartman
2021-11-15 22:35 ` Winiarska, Iwona
2021-11-15 22:35 ` Winiarska, Iwona
2021-11-15 22:35 ` Winiarska, Iwona
2021-11-15 22:35 ` Winiarska, Iwona
2021-11-16 6:26 ` gregkh [this message]
2021-11-16 6:26 ` gregkh
2021-11-16 6:26 ` gregkh
2021-11-16 6:26 ` gregkh
2021-11-17 23:19 ` Winiarska, Iwona
2021-11-17 23:19 ` Winiarska, Iwona
2021-11-17 23:19 ` Winiarska, Iwona
2021-11-17 23:19 ` Winiarska, Iwona
2021-11-15 18:25 ` [PATCH v3 07/13] peci: Add sysfs interface for PECI bus Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 08/13] peci: Add support for PECI device drivers Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 09/13] peci: Add peci-cpu driver Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 10/13] hwmon: peci: Add cputemp driver Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-16 0:52 ` Guenter Roeck
2021-11-16 0:52 ` Guenter Roeck
2021-11-16 0:52 ` Guenter Roeck
2021-11-16 0:52 ` Guenter Roeck
2021-11-17 22:20 ` Winiarska, Iwona
2021-11-17 22:20 ` Winiarska, Iwona
2021-11-17 22:20 ` Winiarska, Iwona
2021-11-17 22:20 ` Winiarska, Iwona
2021-11-15 18:25 ` [PATCH v3 11/13] hwmon: peci: Add dimmtemp driver Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 12/13] docs: hwmon: Document PECI drivers Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` [PATCH v3 13/13] docs: Add PECI documentation Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-15 18:25 ` Iwona Winiarska
2021-11-17 3:56 ` [PATCH v3 00/13] Introduce PECI subsystem Zev Weiss
2021-11-17 3:56 ` Zev Weiss
2021-11-17 3:56 ` Zev Weiss
2021-11-17 3:56 ` Zev Weiss
2021-11-17 23:25 ` Winiarska, Iwona
2021-11-17 23:25 ` Winiarska, Iwona
2021-11-17 23:25 ` Winiarska, Iwona
2021-11-17 23:25 ` Winiarska, Iwona
2021-11-18 12:19 ` Tomer Maimon
2021-11-18 12:19 ` Tomer Maimon
2021-11-18 21:51 ` Winiarska, Iwona
2021-11-18 21:51 ` Winiarska, Iwona
2021-11-18 21:51 ` Winiarska, Iwona
2021-11-18 21:51 ` Winiarska, Iwona
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=YZNPFGPXfCLfJMq3@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-aspeed@lists.ozlabs.org \
/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.