All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Durgadoss R <durgadoss.r@intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Jean Delvare <khali@linux-fr.org>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp
Date: Wed, 09 May 2012 09:56:17 +0000	[thread overview]
Message-ID: <20120509095617.GB15630@ericsson.com> (raw)
In-Reply-To: <20120509072339.GB21556@otc-wbsnb-06>

On Wed, May 09, 2012 at 03:23:39AM -0400, Kirill A. Shutemov wrote:
> On Wed, May 09, 2012 at 10:09:06AM +0300, Kirill A. Shutemov wrote:
> > On Tue, May 08, 2012 at 09:39:40AM -0700, Guenter Roeck wrote:
> > > On Tue, 2012-05-08 at 06:49 -0400, Kirill A. Shutemov wrote:
> > > > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> > > > 
> > > > Let's rework code to allow arbitrary number of cores on a CPU, not
> > > > limited by hardcoded array size.
> > > > 
> > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > > > ---
> > > >  v4:
> > > >    - address issues pointed by Guenter Roeck;
> > > >  v3:
> > > >    - drop redundant refcounting and checks;
> > > >  v2:
> > > >    - fix NULL pointer dereference. Thanks to R, Durgadoss;
> > > >    - use mutex instead of spinlock for list locking.
> > > > ---
> > > 
> > > Hi Kirill,
> > > 
> > > unfortunately now we have another race condition :(. See below ...
> > 
> > Ughh..
> > 
> > > > @@ -557,11 +579,22 @@ exit_free:
> > > >  static int __devexit coretemp_remove(struct platform_device *pdev)
> > > >  {
> > > >  	struct platform_data *pdata = platform_get_drvdata(pdev);
> > > > -	int i;
> > > > +	struct temp_data *tdata;
> > > >  
> > > > -	for (i = MAX_CORE_DATA - 1; i >= 0; --i)
> > > > -		if (pdata->core_data[i])
> > > > -			coretemp_remove_core(pdata, &pdev->dev, i);
> > > > +	for (;;) {
> > > > +		mutex_lock(&pdata->temp_data_lock);
> > > > +		if (!list_empty(&pdata->temp_data_list)) {
> > > > +			tdata = list_first_entry(&pdata->temp_data_list,
> > > > +					struct temp_data, list);
> > > > +			list_del(&tdata->list);
> > > > +		} else
> > > > +			tdata = NULL;
> > > > +		mutex_unlock(&pdata->temp_data_lock);
> > > > +
> > > > +		if (!tdata)
> > > > +			break;
> > > > +		coretemp_remove_core(tdata, &pdev->dev);
> > > > +	}
> > > >  
> > > Unfortunately, that results in a race condition, since the tdata list
> > > entry is gone before the attribute file is deleted.
> > > 
> > > I think you can still use list_for_each_entry_safe, only outside the
> > > mutex, and remove the list entry at the end of coretemp_remove_core()
> 
> I haven't got how list_for_each_entry_safe() will be really safe without
> the lock.
> 
We know that it by itself won't be called multiple times. So the only question is 
if the functions to add/remove a core can be called while coretemp_remove is called,
or if that is mutually exclusive (not that the current code handles this case).

Fortunately, there is a function to block CPU removal/insertion: get_online_cpus()
and put_online_cpus(). I have no idea if it is necessary to protect coretemp_remove()
with it, but it might be on the safe side anyway.

> > > after deleting the attribute file. Just keep the code as it was, and
> > > remove the list entry (mutex-protected) where core_data[] was set to
> > > NULL.
> > 
> > I think
> > 
> > if (tdata)
> > 	return -ENODEV;
> > 
> > in show methods will fix the issue. Right?
> 
> It won't. Stupid me.
> 
> But the check + kref seems will work...
> 
Yes, but would be way too complicated.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	Durgadoss R <durgadoss.r@intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Jean Delvare <khali@linux-fr.org>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp data
Date: Wed, 9 May 2012 02:56:17 -0700	[thread overview]
Message-ID: <20120509095617.GB15630@ericsson.com> (raw)
In-Reply-To: <20120509072339.GB21556@otc-wbsnb-06>

On Wed, May 09, 2012 at 03:23:39AM -0400, Kirill A. Shutemov wrote:
> On Wed, May 09, 2012 at 10:09:06AM +0300, Kirill A. Shutemov wrote:
> > On Tue, May 08, 2012 at 09:39:40AM -0700, Guenter Roeck wrote:
> > > On Tue, 2012-05-08 at 06:49 -0400, Kirill A. Shutemov wrote:
> > > > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> > > > 
> > > > Let's rework code to allow arbitrary number of cores on a CPU, not
> > > > limited by hardcoded array size.
> > > > 
> > > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > > > ---
> > > >  v4:
> > > >    - address issues pointed by Guenter Roeck;
> > > >  v3:
> > > >    - drop redundant refcounting and checks;
> > > >  v2:
> > > >    - fix NULL pointer dereference. Thanks to R, Durgadoss;
> > > >    - use mutex instead of spinlock for list locking.
> > > > ---
> > > 
> > > Hi Kirill,
> > > 
> > > unfortunately now we have another race condition :(. See below ...
> > 
> > Ughh..
> > 
> > > > @@ -557,11 +579,22 @@ exit_free:
> > > >  static int __devexit coretemp_remove(struct platform_device *pdev)
> > > >  {
> > > >  	struct platform_data *pdata = platform_get_drvdata(pdev);
> > > > -	int i;
> > > > +	struct temp_data *tdata;
> > > >  
> > > > -	for (i = MAX_CORE_DATA - 1; i >= 0; --i)
> > > > -		if (pdata->core_data[i])
> > > > -			coretemp_remove_core(pdata, &pdev->dev, i);
> > > > +	for (;;) {
> > > > +		mutex_lock(&pdata->temp_data_lock);
> > > > +		if (!list_empty(&pdata->temp_data_list)) {
> > > > +			tdata = list_first_entry(&pdata->temp_data_list,
> > > > +					struct temp_data, list);
> > > > +			list_del(&tdata->list);
> > > > +		} else
> > > > +			tdata = NULL;
> > > > +		mutex_unlock(&pdata->temp_data_lock);
> > > > +
> > > > +		if (!tdata)
> > > > +			break;
> > > > +		coretemp_remove_core(tdata, &pdev->dev);
> > > > +	}
> > > >  
> > > Unfortunately, that results in a race condition, since the tdata list
> > > entry is gone before the attribute file is deleted.
> > > 
> > > I think you can still use list_for_each_entry_safe, only outside the
> > > mutex, and remove the list entry at the end of coretemp_remove_core()
> 
> I haven't got how list_for_each_entry_safe() will be really safe without
> the lock.
> 
We know that it by itself won't be called multiple times. So the only question is 
if the functions to add/remove a core can be called while coretemp_remove is called,
or if that is mutually exclusive (not that the current code handles this case).

Fortunately, there is a function to block CPU removal/insertion: get_online_cpus()
and put_online_cpus(). I have no idea if it is necessary to protect coretemp_remove()
with it, but it might be on the safe side anyway.

> > > after deleting the attribute file. Just keep the code as it was, and
> > > remove the list entry (mutex-protected) where core_data[] was set to
> > > NULL.
> > 
> > I think
> > 
> > if (tdata)
> > 	return -ENODEV;
> > 
> > in show methods will fix the issue. Right?
> 
> It won't. Stupid me.
> 
> But the check + kref seems will work...
> 
Yes, but would be way too complicated.

Guenter


  reply	other threads:[~2012-05-09  9:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-08 10:49 [lm-sensors] [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp Kirill A. Shutemov
2012-05-08 10:49 ` [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp data Kirill A. Shutemov
2012-05-08 16:39 ` [lm-sensors] [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp Guenter Roeck
2012-05-08 16:39   ` [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp data Guenter Roeck
2012-05-09  7:09   ` [lm-sensors] [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp Kirill A. Shutemov
2012-05-09  7:09     ` [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp data Kirill A. Shutemov
2012-05-09  7:23     ` [lm-sensors] [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp Kirill A. Shutemov
2012-05-09  7:23       ` [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp data Kirill A. Shutemov
2012-05-09  9:56       ` Guenter Roeck [this message]
2012-05-09  9:56         ` Guenter Roeck
2012-05-09 10:16         ` [lm-sensors] [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp Kirill A. Shutemov
2012-05-09 10:16           ` [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp data Kirill A. Shutemov
2012-05-09 10:32           ` [lm-sensors] [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp Guenter Roeck
2012-05-09 10:32             ` [PATCH, v4] hwmon: coretemp: use list instead of fixed size array for temp data Guenter Roeck

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=20120509095617.GB15630@ericsson.com \
    --to=guenter.roeck@ericsson.com \
    --cc=ak@linux.intel.com \
    --cc=durgadoss.r@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=khali@linux-fr.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.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.