public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Fredrickson <creslin@digium.com>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Device Driver Etiquette
Date: Fri, 1 Jun 2007 12:47:07 -0500	[thread overview]
Message-ID: <a714c0e137cf5cf814e790e3fdef23c8@digium.com> (raw)

Greetings,

I maintain a device driver that has been bitten by the transition to 4K 
stacks.  It is a T1/E1 line interface PCI card driver that is 
maintained outside of the kernel, although is used by a significant 
number of people.  The card has a part for doing echo cancellation, but 
it is accessed through a vendor API which (when we received it) was 
quite stack heavy.  It used the stack for a number of large data 
structures, although I have moved a great deal of them (particularly 
the larger ones) onto the heap instead of the stack.  Although this has 
reduced stack usage to the point where it is usable within 4K stacks, 
on some code paths, it can still use quite a bit of stack space (though 
under 4K) for local variables and a handful of small data structures.  
The problem is that in order to initialize and use the echo canceler, 
there is a firmware load portion which takes a noticeable period of 
time (~5-10 seconds).  That is done through this stack heavy portion of 
the code.

The problem that I am seeing is that while this card is loading its 
firmware, there are other device interrupts that occur, and if enough 
levels of interrupt happen, it overflows the stack.  Oh, the firmware 
load occurs in the context of an ioctl, FWIW.

My solution was to disable interrupts while the firmware was being 
loaded using local_irq_save/local_irq_restore, although that seems to 
be a naughty thing to do, especially given the long period of time it 
takes to load the firmware on the card.

My question is this: is there a way to either work around the problem I 
am seeing with the stack without recompiling the kernel with 8K stack 
size or without disabling irqs for such a long period of time (which I 
think is not a nice thing to do either) OR is it acceptable (although 
not nice) to simply fix it this way, by disabling irqs while it loads 
the firmware?

Thanks,
Matthew Fredrickson
Kernel Developer
Digium, Inc.


             reply	other threads:[~2007-06-01 18:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-01 17:47 Matthew Fredrickson [this message]
2007-06-01 18:38 ` Device Driver Etiquette Lee Revell
2007-06-01 22:28   ` H. Peter Anvin
2007-06-02 15:05 ` Satyam Sharma
2007-06-02 23:22 ` Arjan van de Ven
2007-06-03  1:45   ` Satyam Sharma
  -- strict thread matches above, loose matches on Subject: below --
2007-06-01 23:16 Daniel J Blueman
     [not found] <12467610.159201180797054019.JavaMail.root@jupiler.digium.com>
2007-06-02 15:12 ` Matt Fredrickson
2007-06-03 11:22   ` Daniel J Blueman
     [not found] <17916027.160971180851607681.JavaMail.root@jupiler.digium.com>
2007-06-03  6:20 ` Matt Fredrickson

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=a714c0e137cf5cf814e790e3fdef23c8@digium.com \
    --to=creslin@digium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox