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,
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.
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, 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 go
On Fri, Feb 6, 2015 at 3:50 AM, Peter Zijlstra pet...@infradead.org 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
On Fri, Feb 06, 2015 at 08:02:41AM -0800, Linus Torvalds wrote:
On Fri, Feb 6, 2015 at 3:50 AM, Peter Zijlstra pet...@infradead.org 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
On Fri, Feb 6, 2015 at 8:39 AM, Peter Zijlstra pet...@infradead.org 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
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:
>
> -
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:
- warn once
* 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
> >
* Peter Zijlstra pet...@infradead.org 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
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
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*
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 Sat, Jan 31, 2015 at 01:54:36PM -0800, Linus Torvalds wrote:
On Sat, Jan 31, 2015 at 12:16 PM, Peter Zijlstra pet...@infradead.org 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
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 r...@rjwysocki.net wrote:
On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote:
Yeah, but the debug check is
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 nasty
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
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
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
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 o...@redhat.com wrote:
Perhaps sched_annotate_sleep() shouldn't depend on
CONFIG_DEBUG_ATOMIC_SLEEP
too...
Ugh. That thing is
On 02/01, Linus Torvalds wrote:
On Sun, Feb 1, 2015 at 11:43 AM, Oleg Nesterov o...@redhat.com 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
On Sun, Feb 1, 2015 at 11:43 AM, Oleg Nesterov o...@redhat.com 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
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
>
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
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
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 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:
- warn
On Fri, Jan 30, 2015 at 7:47 AM, Oleg Nesterov o...@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
On Sat, Jan 31, 2015 at 10:32:23AM -0800, Linus Torvalds wrote:
On Fri, Jan 30, 2015 at 7:47 AM, Oleg Nesterov o...@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
On Sat, Jan 31, 2015 at 12:16 PM, Peter Zijlstra pet...@infradead.org 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
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 things.
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
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
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
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
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,
On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds
torva...@linux-foundation.org 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
On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki r...@rjwysocki.net 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
On Thursday, January 29, 2015 05:12:11 PM Linus Torvalds wrote:
On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki r...@rjwysocki.net 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
On Thu, Jan 29, 2015 at 5:25 PM, Linus Torvalds
torva...@linux-foundation.org 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
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, 2015 at 6:02 AM,
On Thursday, January 29, 2015 05:25:07 PM Linus Torvalds wrote:
On Thu, Jan 29, 2015 at 5:12 PM, Linus Torvalds
torva...@linux-foundation.org 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.
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
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
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 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
so recent
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 kernel threads
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 the offender (nor
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.
lspci
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
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
On Tue, Jan 20, 2015 at 6:02 AM, Bruno Prémont
bonb...@linux-vserver.org 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
On Sun, 18 January 2015 Linus Torvalds torva...@linux-foundation.org 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.
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):
kernel: avoid overflow in cmp_range
Malcolm
: 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):
kernel: avoid overflow in cmp_range
Malcolm Priestley (2):
staging: vt6655: vnt_tx_packet Fix corrupted tx packets
62 matches
Mail list logo
