* Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 10:21 AM, Thomas Gleixner wrote:
> >
> > This was a draft patch. I made it a WARN_ON_ONCE() already.
>
> Ok, good.
>
> I really wish we could just get rid of BUG_ON(). It was a bad
> idea, and it makes it easy for people to do the wrong thing
On Thu, Feb 21, 2013 at 10:21 AM, Thomas Gleixner wrote:
>
> This was a draft patch. I made it a WARN_ON_ONCE() already.
Ok, good.
I really wish we could just get rid of BUG_ON(). It was a bad idea,
and it makes it easy for people to do the wrong thing. Sadly, we have
tons of them.
On Thu, 21 Feb 2013, Linus Torvalds wrote:
> On Wed, Feb 20, 2013 at 1:00 PM, Thomas Gleixner wrote:
> > */
> > void irq_exit(void)
> > {
> > +#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > +#else
> > + BUG_ON(!irqs_di
On Wed, Feb 20, 2013 at 1:00 PM, Thomas Gleixner wrote:
> */
> void irq_exit(void)
> {
> +#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +#else
> + BUG_ON(!irqs_disabled();
> +#endif
Guys, STOP DOING THIS!
Adding BUG_ON()'s j
2013/2/21 Thomas Gleixner :
> On Thu, 21 Feb 2013, Frederic Weisbecker wrote:
> Second thoughts. I probably go for your minimal fix for stable and
> then push my version on top of it to Linus only.
Thanks, I feel more comfortable with that. Then I'll try to iterate
over archs to finally remove tha
On Thu, 21 Feb 2013, Frederic Weisbecker wrote:
> 2013/2/21 Thomas Gleixner :
> > On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
> >> 2013/2/20 Thomas Gleixner :
> >> > That's not a fix. That's an hack.
> >>
> >> I know it looks that way. That's because it's a pure regression fix,
> >> minimal for
2013/2/21 Thomas Gleixner :
> On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
>> 2013/2/20 Thomas Gleixner :
>> > That's not a fix. That's an hack.
>>
>> I know it looks that way. That's because it's a pure regression fix,
>> minimal for backportability.
>>
>> I'm distinguishing two different thing
On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
> 2013/2/20 Thomas Gleixner :
> > That's not a fix. That's an hack.
>
> I know it looks that way. That's because it's a pure regression fix,
> minimal for backportability.
>
> I'm distinguishing two different things here: the fact that some archs
>
2013/2/20 Thomas Gleixner :
> On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
>
>> As it stands, irq_exit() may or may not be called with
>> irqs disabled, depending on __ARCH_IRQ_EXIT_IRQS_DISABLED
>> that the arch can define.
>>
>> It makes tick_nohz_irq_exit() unsafe. For example two
>> interrup
On Wed, 20 Feb 2013, Frederic Weisbecker wrote:
> As it stands, irq_exit() may or may not be called with
> irqs disabled, depending on __ARCH_IRQ_EXIT_IRQS_DISABLED
> that the arch can define.
>
> It makes tick_nohz_irq_exit() unsafe. For example two
> interrupts can race in tick_nohz_stop_sched_
10 matches
Mail list logo
