mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Gautham R Shenoy <ego@in.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Oleg Nesterov <oleg@tv-sign.ru>, Pavel Machek <pavel@ucw.cz>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH 1/7] Freezer: Read PF_BORROWED_MM in a nonracy way
Date: Fri, 11 May 2007 16:29:03 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0705111625300.3986@woody.linux-foundation.org> (raw)
In-Reply-To: <200705120122.07177.rjw@sisk.pl>



On Sat, 12 May 2007, Rafael J. Wysocki wrote:
>
> We use this function (ie. kernel/power/process.c:is_user_space()) to
> distinguish kernel threads from user space processes.  Therefore we make it
> always return true for user space processes and always return false for kernel
> threads.  In the latter case we need to use the task_lock() to ensure that the
> result is as desired (ie. false), because otherwise it might be racing with
> either fs/aio.c:use_mm() or fs/aio.c:unuse_mm().

But there is no race protection in the *caller*, so if it can ever return 
one or the other, what protects it from changing once the caller returns?

And if the value can change (because some thread uses "use_mm()"), then 
the caller cannot rely on the value that got returned.

So you migt as well not return any value at all, since the returned value 
is apparently meaningless once the lock has been released.

In other words: "The lock, it does nothing".

		Linus

  parent reply	other threads:[~2007-05-11 23:30 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-10 22:35 [PATCH 0/7] Freezer bugfixes Rafael J. Wysocki
2007-05-10 22:36 ` [PATCH 1/7] Freezer: Read PF_BORROWED_MM in a nonracy way Rafael J. Wysocki
2007-05-11 19:39   ` Andrew Morton
2007-05-11 20:21     ` Oleg Nesterov
2007-05-11 20:40     ` Rafael J. Wysocki
2007-05-11 22:56       ` Linus Torvalds
2007-05-11 23:20         ` Oleg Nesterov
2007-05-11 23:32           ` Linus Torvalds
2007-05-11 23:48             ` Oleg Nesterov
2007-05-12  0:05               ` Oleg Nesterov
2007-05-12  0:08               ` Linus Torvalds
2007-05-12  0:40                 ` Oleg Nesterov
2007-05-12  1:01                   ` Oleg Nesterov
2007-05-12  1:24                   ` Linus Torvalds
2007-05-12  9:01                     ` Rafael J. Wysocki
2007-05-12 10:45                       ` Rafael J. Wysocki
2007-05-12 14:18                         ` Oleg Nesterov
2007-05-12 16:35                           ` Rafael J. Wysocki
2007-05-12 16:58                             ` Oleg Nesterov
2007-05-12 17:16                               ` Rafael J. Wysocki
2007-05-12 17:43                     ` Oleg Nesterov
2007-05-12  1:11                 ` Rafael J. Wysocki
2007-05-11 23:22         ` Rafael J. Wysocki
2007-05-11 23:25           ` Andrew Morton
2007-05-12  0:16             ` Rafael J. Wysocki
2007-05-11 23:29           ` Linus Torvalds [this message]
2007-05-12  0:01             ` Rafael J. Wysocki
2007-05-12  8:16               ` Gautham R Shenoy
2007-05-12  9:27                 ` Rafael J. Wysocki
2007-05-12 10:13                   ` Gautham R Shenoy
2007-05-12 10:41                     ` Rafael J. Wysocki
2007-05-12 10:52                       ` Gautham R Shenoy
2007-05-12 11:34                         ` Rafael J. Wysocki
2007-05-12 14:25                   ` Oleg Nesterov
2007-05-12 14:59                     ` migrate_dead_tasks() vs sleep-after-exit_notify() problems? Oleg Nesterov
2007-05-10 22:37 ` [PATCH 2/7] Freezer: Close potential race between refrigerator and thaw_tasks Rafael J. Wysocki
2007-05-10 22:38 ` [PATCH 3/7] Freezer: Fix vfork problem Rafael J. Wysocki
2007-05-10 22:39 ` [PATCH 4/7] Freezer: Take kernel_execve into consideration Rafael J. Wysocki
2007-05-10 22:41 ` [PATCH 5/7] Freezer: Fix kthread_create vs freezer theoretical race Rafael J. Wysocki
2007-05-10 22:43 ` [PATCH 6/7] Freezer: Fix PF_NOFREEZE vs freezeable race Rafael J. Wysocki
2007-05-10 22:44 ` [PATCH 7/7] Freezer: Move frozen_process to kernel/power/process.c Rafael J. Wysocki

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=alpine.LFD.0.98.0705111625300.3986@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@tv-sign.ru \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /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®