All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
	peter@hurleysoftware.com, rjw@rjwysocki.net,
	torvalds@linux-foundation.org, tglx@linutronix.de,
	eparis@redhat.com, umgwanakikbuti@gmail.com, marcel@holtmann.org,
	ebiederm@xmission.com, davem@davemloft.net,
	fengguang.wu@intel.com
Subject: Re: [PATCH 2/7] wait: Reimplement wait_event_freezable()
Date: Fri, 31 Oct 2014 22:53:42 +0100	[thread overview]
Message-ID: <20141031215342.GA27823@redhat.com> (raw)
In-Reply-To: <20141031213802.GA25881@redhat.com>

On 10/31, Oleg Nesterov wrote:
>
> On 10/31, Peter Zijlstra wrote:
> >
> > Provide better implementations of wait_event_freezable() APIs.
> >
> > The problem is with freezer_do_not_count(), it hides the thread from
> > the freezer, even though this thread might not actually freeze/sleep
> > at all.
>
> I agree, wait_event_freezable() is awful. But could you clarify "at all" ?
>
> Sure, the task can be preempted right after it sets, it can do a lot
> of things before it calls schedule(), it can be woken after that and
> it can run again and do something else before freezer_count() calls
> try_to_freeze(), etc.
>
> Is this what you meant?
>
>
> > +#define __wait_event_freezable(wq, condition)				\
> > +	(void)___wait_event(wq, condition, TASK_INTERRUPTIBLE, 0, 0,	\
> > +			    schedule(); try_to_freeze())
>
> I don't think this can work. wait_event_freezable() should be used by
> kernel threads and thus we can't rely on TIF_SIGPENDING, freeze_task()
> simply does wake_up_state(TASK_INTERRUPTIBLE) in this case.
>
> Just for example, suppose that try_to_freeze_tasks() calls freeze_task()
> before this kthread sets current->state = TASK_INTERRUPTIBLE. In this
> case __wait_event_freezable()->schedule() will happily sleep and
> try_to_freeze_tasks() will fail.
>
> That is why I tried to suggest cmd == freezable_schedule(). Still not
> good, but at least this narrows the window and (perhaps) we can improve
> this freezable_schedule() later.
>
> But on a second thought... Probably cmd => try_to_freeze(); schedule();
> should work. Or just
>
> 	#define __wait_event_freezable(wq, condition)	\
> 		__wait_event_interruptible(wq, ({ try_to_freeze(); (condition); }))
>
> which looks simpler.

Ah, but I forgot about another problem... can't we finally kill this ugly
"long save = current->state" code in __refrigerator() ? Nobody seem to
understand why we are doing this, and this looks just wrong.

And this doesn't allow us to do try_to_freeze() + schedule().

Oleg.


  parent reply	other threads:[~2014-10-31 21:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-31 11:10 [PATCH 0/7] Various fixes for nested sleep stuff Peter Zijlstra
2014-10-31 11:10 ` [PATCH 1/7] sched,wait: Fix a kthread race with wait_woken() Peter Zijlstra
2014-10-31 22:13   ` Oleg Nesterov
2014-10-31 11:10 ` [PATCH 2/7] wait: Reimplement wait_event_freezable() Peter Zijlstra
2014-10-31 17:41   ` Peter Zijlstra
2014-10-31 21:38   ` Oleg Nesterov
2014-10-31 21:48     ` Peter Zijlstra
2014-10-31 21:53     ` Oleg Nesterov [this message]
2014-10-31 11:10 ` [PATCH 3/7] wait: Remove wait_event_freezekillable() Peter Zijlstra
2014-10-31 11:10 ` [PATCH 4/7] audit,wait: Fixup kauditd_thread wait loop Peter Zijlstra
2014-10-31 11:10 ` [PATCH 5/7] rfcomm: Fix broken wait construct Peter Zijlstra
2014-10-31 11:10 ` [PATCH 6/7] netdev: Fix sleeping inside wait event Peter Zijlstra
2014-10-31 11:10 ` [PATCH 7/7] sched: Use WARN_ONCE for the might_sleep() TASK_RUNNING test Peter Zijlstra
2014-10-31 22:42   ` Oleg Nesterov
2014-11-03  7:56     ` Peter Zijlstra

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=20141031215342.GA27823@redhat.com \
    --to=oleg@redhat.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=eparis@redhat.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mingo@kernel.org \
    --cc=peter@hurleysoftware.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=umgwanakikbuti@gmail.com \
    /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.