linux-kernel - Device Driver Etiquette

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Jun 2007 12:47:07 -0500
From:	Matthew Fredrickson <creslin@...ium.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Device Driver Etiquette

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/