mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Gautham R Shenoy <ego@in.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>, 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 18:24:23 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0705111812270.3986@woody.linux-foundation.org> (raw)
In-Reply-To: <20070512004057.GA540@tv-sign.ru>



On Sat, 12 May 2007, Oleg Nesterov wrote:
> 
> However, in my opininon THAT PATCH has nothing to do with this problem.
> It just improves the code that we already have.

Sure. 

However, I think it does it THE WRONG WAY, and doesn't actually fix the 
much deeper problems with the freezer, as shown by the fact that the lock 
is *still* broken for other cases.

So, here's a summary:

 - we should not take the lock inside the function, because taking it 
   there is fundamentally wrong, and leaves all the *other* races in 
   place.

 - if you actually want to solve the other races, the lock needs to be 
   taken by the caller, in which case taking it in the callee is obviously 
   (again) wrong.

 - or then, we accept that the race wasn't fixed AT ALL, and you add other 
   code to _other_ places to handle the case where you froze the wrong 
   thread (or didn't freeze the right one).

   And I'm not making that up. Look at most of the other patches in that 
   series: they are _exactly_ about the scenario I'm outlining.

 - the whole "kernel thread vs user thread" thing is the wrong thing to 
   check in the first place, since we just should never touch kernel 
   threads in the first place, and anything that wants to freeze user 
   space should have disabled exec_usermodehelper() at a higher level

That's why I'm so unhappy. The "fix" is going in the wrong direction. Each 
fix on their own may be an "improvement", but the end result of many of 
the fixes is a total mess!

We can continue to add bandaids to something broken, until it "works". But 
the end result, while "working", is not actually any better. Quite the 
reverse - the end result of something like that is that you add all these 
magic rules and special cases.

So in the end one ugly design decision leads to broken locking, which in 
turn leads to other cases where you add more broken code, which just leads 
to a situation where nobody actually understands what the *design* is, 
because there simply *isn't* any design - it's just a hodge-podge of "but 
this fixes a bug" ad-hoc "fixes".

			Linus

  parent reply	other threads:[~2007-05-12  1:25 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 [this message]
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
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.0705111812270.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®