public inbox for linux-kernel@vger.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: [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:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 ` Guenter Roeck
2012-05-09  7:09   ` Kirill A. Shutemov
2012-05-09  7:23     ` Kirill A. Shutemov
2012-05-09  9:56       ` Guenter Roeck [this message]
2012-05-09 10:16         ` Kirill A. Shutemov
2012-05-09 10:32           ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox