mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>,
	Alan Stern <stern@rowland.harvard.edu>,
	"Linux-pm mailing list" <linux-pm@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [linux-pm] [GIT PULL] One more power management fix for 2.6.37
Date: Thu, 4 Nov 2010 20:55:31 +0100	[thread overview]
Message-ID: <201011042055.31779.rjw@sisk.pl> (raw)
In-Reply-To: <AANLkTikfGJOMpnvwJ4tTW3EXVGayyT=3s5iyhGbhKz8_@mail.gmail.com>

On Thursday, November 04, 2010, Linus Torvalds wrote:
> On Thu, Nov 4, 2010 at 9:24 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >
> > OK, so I think we can relax the locking in dpm_[suspend/resume]_noirq() to
> > avoid executing callbacks under dpm_list_mtx, like in the (untested) patch
> > below.
> 
> ABSOLUTELY NOT.
> 
> If you drop the lock in the middle of the loop, you should remove the
> lock around the loop entirely. There is absolutely no difference
> between "drop lock in the middle" and "don't take lock at all".
> 
> Either that list traversal needs the lock or it does not. There is no
> "it needs the lock, but not while doing random crap X in the middle of
> traversal".

Your're right,  it only makes sense to either leave it or remove it entirely.

> If nothing can possibly change the list while calling the device, then
> you don't need the lock. And if something _can_ change the list,
> dropping the lock means that the list is no longer trustworthy and you
> can't just continue in the middle.

At this point, if everyone does everything right, there should be nothing
running in parallel with us that will attempt to modify the list.  So, I'd say
let's drop the lock completely.

Thanks,
Rafael

  reply	other threads:[~2010-11-04 19:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29 21:58 Rafael J. Wysocki
2010-11-02 21:49 ` Linus Torvalds
2010-11-03  2:56   ` Rafael J. Wysocki
2010-11-03 17:40     ` Linus Torvalds
2010-11-03 18:36       ` Linus Torvalds
2010-11-03 21:18         ` [linux-pm] " Dominik Brodowski
2010-11-04  5:04           ` Rafael J. Wysocki
2010-11-04  6:27             ` Dominik Brodowski
2010-11-04 13:24               ` Rafael J. Wysocki
2010-11-04 14:50                 ` Alan Stern
2010-11-09 23:39                   ` Rafael J. Wysocki
2010-11-10  0:49                     ` Linus Torvalds
2010-11-10  3:22                       ` Alan Stern
2010-11-10 20:51                         ` Rafael J. Wysocki
2010-11-15 15:20                           ` Alan Stern
2010-11-04 17:07                 ` Linus Torvalds
2010-11-04 19:55                   ` Rafael J. Wysocki [this message]
2010-11-04 17:19     ` Linus Torvalds

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=201011042055.31779.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=linux@dominikbrodowski.net \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®