All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Christoph Hellwig <hch@infradead.org>,
	Kristian Benoit <kbenoit@opersys.com>,
	linux-kernel@vger.kernel.org
Subject: Re: network driver disabled interrupts in PREEMPT_RT
Date: Tue, 14 Jun 2005 07:58:55 +0200	[thread overview]
Message-ID: <20050614055855.GA29397@elte.hu> (raw)
In-Reply-To: <20050613190310.GB4308@infradead.org>


* Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jun 13, 2005 at 08:56:42PM +0200, Ingo Molnar wrote:
> > 
> > * Kristian Benoit <kbenoit@opersys.com> wrote:
> > 
> > > Hi,
> > > I got lots of these messages when accessing the net running
> > > 2.6.12-rc6-RT-V0.7.48-25 :
> > > 
> > > "network driver disabled interrupts: tg3_start_xmit+0x0/0x629 [tg3]"
> > > 
> > > it seem to come from net/sched/sch_generic.c.
> > 
> > does the patch below fix it?
> 
> Wouldn't it be much more useful to add spin_trylock_irq?

you are right, a spin_trylock_irqsave() call would be much cleaner.

i think i should explain why you are seeing such hacks in the PREEMPT_RT 
patch: generally we are trying to achieve near-100% driver API 
compatibility (that of course is also one of the requirements for any of 
this to hit mainline), so i'm marking any deviations with _nort or _rt 
postfixes (depending on where the change in semantics is needed). I 
consider them temporary hacks, so i'm usually trying to keep the 
original form of the code, so that i can go back later and fix it.

I had these hacks in tg3.c for some time, and i thought i could drop 
them now that local_irq_*() uses the soft IRQ-flag - but i was wrong.  
One example of the _rt/_nort marking process is e.g. the earlier RCU API 
related grossness, which went away with Paul's PREEMPT_RCU aproach and 
now PREEMPT_RT is fully compatible with the RCU API. Fortunately, 
assymetric local_irq_* + spin_lock_* uses (which are perfectly legal!)  
are relatively rare. Extending the spinlock APIs and converting all 
upstream code would be a good approach to solve this problem, as it's 
also a cleanup. (It would probably also make static lock analysis 
easier.)

	Ingo

  reply	other threads:[~2005-06-14  6:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-13 18:45 network driver disabled interrupts in PREEMPT_RT Kristian Benoit
2005-06-13 18:56 ` Ingo Molnar
2005-06-13 19:03   ` Christoph Hellwig
2005-06-14  5:58     ` Ingo Molnar [this message]
2005-06-17  2:53     ` Herbert Xu
2005-06-13 19:56   ` Kristian Benoit
2005-06-15 12:36   ` Serge Noiraud
2005-06-15 13:05     ` Ingo Molnar
2005-06-15 13:08       ` Serge Noiraud
2005-06-21 13:18         ` Ingo Molnar
2005-07-05 12:17           ` Serge Noiraud

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=20050614055855.GA29397@elte.hu \
    --to=mingo@elte.hu \
    --cc=hch@infradead.org \
    --cc=kbenoit@opersys.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.