On Fri, Feb 6, 2015 at 8:39 AM, Peter Zijlstra wrote:
>
> I like the macro one though; I worry a wee bit about non-documented
> cases through. If someone is doing something way subtle we'll break it
> :/
Yeah, I agree. And I wonder how much we should even care. People who
do this thing by hand -
On Fri, Feb 06, 2015 at 08:02:41AM -0800, Linus Torvalds wrote:
> On Fri, Feb 6, 2015 at 3:50 AM, Peter Zijlstra wrote:
> >
> > Also, set_current_state(TASK_RUNNING) is almost always pointless, nobody
> > cares about that barrier, so make it go away.
>
> I'd rather not mix this with the patch, an
On Fri, Feb 6, 2015 at 3:50 AM, Peter Zijlstra wrote:
>
> Also, set_current_state(TASK_RUNNING) is almost always pointless, nobody
> cares about that barrier, so make it go away.
I'd rather not mix this with the patch, and wonder if we should just
do that globally with some preprocessor magic. We
On Thu, Feb 05, 2015 at 10:14:36PM +0100, Bruno Prémont wrote:
> The loop is now replaced by a single WARN() trace - I guess expected:
> From my reading of the thread fixing pccardd/sched TASK_RUNNING usage/check
> is another issue left for the future.
Yeah, something like the below will make it
On Thu, 29 January 2015 Linus Torvalds wrote:
> On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote:
> >
> > The WARN() was already changed to a WARN_ONCE().
>
> Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up
> always happening.
>
> So I think the right fix is to:
>
> -
* Peter Zijlstra wrote:
> On Thu, Jan 29, 2015 at 05:25:07PM -0800, Linus Torvalds wrote:
>
> > PeterZ, please don't make "debugging" patches like this. Ever
> > again. Because this was just stupid, and it took me too long
> > to realize that despite the warning being shut up, the debug
> > p
On Sun, Feb 01, 2015 at 12:09:32PM -0800, Linus Torvalds wrote:
> Now, I have the patch that removes that thing (but I was hoping to get
> it from the scheduler tree before doing rc7, which seems to not have
> happened), but yes, that together with your patch seems like it should
> fix all the nast
On Sat, Jan 31, 2015 at 01:54:36PM -0800, Linus Torvalds wrote:
> On Sat, Jan 31, 2015 at 12:16 PM, Peter Zijlstra wrote:
> >
> > All the stuff it flagged are genuinely wrong, albeit not disastrously
> > so, things mostly just work.
>
> I really disagree.
>
> They weren't wrong. They *could* occ
Dne 30.1.2015 v 02:49 Rafael J. Wysocki napsal(a):
On Thursday, January 29, 2015 05:12:11 PM Linus Torvalds wrote:
On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki wrote:
On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote:
Yeah, but the debug check is triggering worse behavior,
On 02/01, Linus Torvalds wrote:
>
> On Sun, Feb 1, 2015 at 11:43 AM, Oleg Nesterov wrote:
> >
> > And personally I agree. sched_annotate_sleep() looks self-documented, it
> > is clear that it is used to suppress the warning.
>
> But *that's not the problem*.
>
> If it was just silencing the warnin
On Sun, Feb 1, 2015 at 11:43 AM, Oleg Nesterov wrote:
>
> And personally I agree. sched_annotate_sleep() looks self-documented, it
> is clear that it is used to suppress the warning.
But *that's not the problem*.
If it was just silencing the warning, things would be fine.
But it is actively scr
On 01/31, Peter Zijlstra wrote:
>
> On Sat, Jan 31, 2015 at 10:32:23AM -0800, Linus Torvalds wrote:
> > On Fri, Jan 30, 2015 at 7:47 AM, Oleg Nesterov wrote:
> > >
> > > Perhaps sched_annotate_sleep() shouldn't depend on
> > > CONFIG_DEBUG_ATOMIC_SLEEP
> > > too...
> >
> > Ugh. That thing is horr
On Sat, Jan 31, 2015 at 12:16 PM, Peter Zijlstra wrote:
>
> All the stuff it flagged are genuinely wrong, albeit not disastrously
> so, things mostly just work.
I really disagree.
They weren't wrong. They *could* occasionally result in extra
reschedules, but that was never wrong to begin with.
On Sat, Jan 31, 2015 at 10:32:23AM -0800, Linus Torvalds wrote:
> On Fri, Jan 30, 2015 at 7:47 AM, Oleg Nesterov 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
On Fri, Jan 30, 2015 at 7:47 AM, Oleg Nesterov 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
On Thu, Jan 29, 2015 at 05:25:07PM -0800, Linus Torvalds wrote:
> PeterZ, please don't make "debugging" patches like this. Ever again.
> Because this was just stupid, and it took me too long to realize that
> despite the warning being shut up, the debug patch was still actively
> doing bad bad thin
On Thu, 29 Jan 2015 17:25:07 Linus Torvalds wrote:
> On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds wrote:
> >
> > The WARN() was already changed to a WARN_ONCE().
>
> Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up
> always happening.
>
> So I think the right fix is to:
>
On 01/29, Linus Torvalds wrote:
>
> (a) it actually changes behavior for a debug vs non-debug kernel,
> which is a really bad idea to begin with
Perhaps sched_annotate_sleep() shouldn't depend on CONFIG_DEBUG_ATOMIC_SLEEP
too...
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe
On Thursday, January 29, 2015 05:25:07 PM Linus Torvalds wrote:
> On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds
> wrote:
> >
> > The WARN() was already changed to a WARN_ONCE().
>
> Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up
> always happening.
>
> So I think the righ
On Thu, Jan 29, 2015 at 5:25 PM, Linus Torvalds
wrote:
>
> Ingo, maybe you'd want to apply this through the scheduler tree, the
> way you already did the WARN_ONCE() thing.
Side note: I can obviously just commit it myself, but for things that
have obvious maintainers I tend to try to try to push
On Thursday, January 29, 2015 05:12:11 PM Linus Torvalds wrote:
> On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki wrote:
> > On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote:
> >>
> >> Yeah, but the debug check is triggering worse behavior, requiring
> >> bisecting back to the debu
On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds
wrote:
>
> The WARN() was already changed to a WARN_ONCE().
Oh, but I notice that the "__set_current_state(TASK_RUNNING) ends up
always happening.
So I think the right fix is to:
- warn once like we do
- but *not* do that __set_current_state()
On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki wrote:
> On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote:
>>
>> Yeah, but the debug check is triggering worse behavior, requiring
>> bisecting back to the debug commit.
>
> Yes, it is.
>
> So I'm wondering is anyone is working on fix
On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote:
> On 01/21/2015 05:12 PM, Davidlohr Bueso wrote:
> > On Wed, 2015-01-21 at 22:37 +0100, Bruno Prémont wrote:
> >> On Wed, 21 January 2015 Bruno Prémont wrote:
> >>> On Tue, 20 January 2015 Linus Torvalds wrote:
> On Tue, Jan 20, 20
On 01/21/2015 05:12 PM, Davidlohr Bueso wrote:
> On Wed, 2015-01-21 at 22:37 +0100, Bruno Prémont wrote:
>> On Wed, 21 January 2015 Bruno Prémont wrote:
>>> On Tue, 20 January 2015 Linus Torvalds wrote:
On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
>
> No idea yet which rc is t
On Wed, 2015-01-21 at 22:37 +0100, Bruno Prémont wrote:
> On Wed, 21 January 2015 Bruno Prémont wrote:
> > On Tue, 20 January 2015 Linus Torvalds wrote:
> > > On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
> > > >
> > > > No idea yet which rc is the offender (nor exact patch), but on my not
On Wed, 21 January 2015 Bruno Prémont wrote:
> On Tue, 20 January 2015 Linus Torvalds wrote:
> > On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
> > >
> > > No idea yet which rc is the offender (nor exact patch), but on my not
> > > so recent UP laptop with a pccard slot I have 2 pccardd kern
On Tue, 20 January 2015 Linus Torvalds wrote:
> On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont wrote:
> >
> > No idea yet which rc is the offender (nor exact patch), but on my not
> > so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
> > converting my laptop into a heater.
> >
On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont
wrote:
>
> No idea yet which rc is the offender (nor exact patch), but on my not
> so recent UP laptop with a pccard slot I have 2 pccardd kernel threads
> converting my laptop into a heater.
>
> lspci for affected nodes:
> 02:06.0 CardBus bridge [060
On Sun, 18 January 2015 Linus Torvalds wrote:
> Another week, another -rc.
>
> Fairly normal release, although I'd wish that by rc5 we'd have calmed
> down even further. But no, with some of the driver tree merges in
> particular, this is actually larger than rc4 was.
>
> That said, it's not li
ncy typos
ARM: dra7xx: Fix counter frequency drift for AM572x errata i856
ARM: omap5/dra7xx: Enable booting secondary CPU in HYP mode
Linus Torvalds (1):
Linux 3.19-rc5
Linus Walleij (1):
ARM: nomadik: fix up leftover device tree pins
Louis Langholtz (1):
kern
31 matches
Mail list logo
