public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Oleg Nesterov" <oleg@redhat.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Peter Hurley" <peter@hurleysoftware.com>,
	"Davidlohr Bueso" <dave@stgolabs.net>,
	"Bruno Prémont" <bonbons@linux-vserver.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ilya Dryomov" <ilya.dryomov@inktank.com>,
	"Mike Galbraith" <umgwanakikbuti@gmail.com>
Subject: Re: Linux 3.19-rc5
Date: Sat, 31 Jan 2015 21:16:01 +0100	[thread overview]
Message-ID: <20150131201601.GZ2896@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CA+55aFwW139HZ6aNi_2Jf36kx53znZMKS1QO_4JVXJJYsSG6=A@mail.gmail.com>

On Sat, Jan 31, 2015 at 10:32:23AM -0800, Linus Torvalds wrote:
> On Fri, Jan 30, 2015 at 7:47 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > Perhaps sched_annotate_sleep() shouldn't depend on CONFIG_DEBUG_ATOMIC_SLEEP
> > too...
> 
> Ugh. That thing is horrible. The naming doesn't make it obvious at all
> that it's actually making sure that we have state set to TASK_RUNNING,
> and I could easily imagine that it would cause similar "busy-loops
> while scheduling" issues if anybody ever uses it in the wrong context.

The alternative was putting unconditional __set_task_state(TASK_RUNNING)
things in a few code paths. I didn't want to cause the extra code in
case we didn't need them. Particularly the include/net/sock.h one, as I
know the network people are cycle counters.

But this function should indeed be used very rarely. Currently we're at
5 instances.

> So I really think that whole thing is a sign of "the debug
> infrastructure is buggy, and people are introducing fragile things to
> just shut up the false positives".

Aside from this one annotation, which is used in cases where we broke
out of the wait loop but haven't reset task state yet, there have not
really been false positives.

All the stuff it flagged are genuinely wrong, albeit not disastrously
so, things mostly just work.

Should I make the default wait_event() safe against sleeps? It would
make it slightly more expensive, but on the whole that should not really
be a problem.

Alternatively we should provide an alternative to wait_event() that
allows sleeps, but I'm failing to come up with a good name.

> I don't know how to fix it. I really get the feeling that the whole
> new "nested sleep" detection code was a mistake to begin with, since
> it wasn't even a real bug, and it has now created more bugs than it
> ever detected afaik.

I appreciate I caused you some pain here, and I'm very sorry for that.
But I do think we should be little more careful with task::state, on
occasion things do go wrong there and funny stuff happens.

  reply	other threads:[~2015-01-31 20:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-18  9:17 Linux 3.19-rc5 Linus Torvalds
2015-01-19 18:02 ` Bruno Prémont
2015-01-20  6:24   ` Linus Torvalds
2015-01-21 20:37     ` Bruno Prémont
2015-01-21 21:37       ` Bruno Prémont
2015-01-21 22:12         ` Davidlohr Bueso
2015-01-21 22:54           ` Peter Hurley
2015-01-30  1:22             ` Rafael J. Wysocki
2015-01-30  1:12               ` Linus Torvalds
2015-01-30  1:25                 ` Linus Torvalds
2015-01-30  1:35                   ` Linus Torvalds
2015-01-30  2:06                   ` Rafael J. Wysocki
2015-01-30 15:47                   ` Oleg Nesterov
2015-01-31 18:32                     ` Linus Torvalds
2015-01-31 20:16                       ` Peter Zijlstra [this message]
2015-01-31 21:54                         ` Linus Torvalds
2015-02-02 13:19                           ` Peter Zijlstra
2015-02-01 19:43                         ` Oleg Nesterov
2015-02-01 20:09                           ` Linus Torvalds
2015-02-01 20:19                             ` Oleg Nesterov
2015-02-02 15:34                             ` Peter Zijlstra
2015-01-31  9:16                   ` Bruno Prémont
2015-01-31  9:48                   ` Peter Zijlstra
2015-02-03 11:18                     ` Ingo Molnar
2015-02-05 21:14                   ` Bruno Prémont
2015-02-06 11:50                     ` Peter Zijlstra
2015-02-06 16:02                       ` Linus Torvalds
2015-02-06 16:39                         ` Peter Zijlstra
2015-02-06 16:46                           ` Linus Torvalds
2015-01-30  1:49                 ` Rafael J. Wysocki
2015-02-02  9:48                   ` Zdenek Kabelac

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=20150131201601.GZ2896@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bonbons@linux-vserver.org \
    --cc=dave@stgolabs.net \
    --cc=ilya.dryomov@inktank.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peter@hurleysoftware.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox