Re: Got suggestions to reduce the locks in stacker.c?

crispinat_private

David Wheeler wrote:

> Greg KH <gregat_private> said:
> > I would hate to see the benchmark runs with a lock being grabbed for
> > every security hook.  I think you just set back the whole "no more BKL"
> > posse a few years  [:)]
> Suggestions welcome.  Got any?
>
> One approach is my previous approach - if I can force
> writing of pointers to be atomic (any suggestions on how to do so?),
> and people are willing to accept certain weaknesses (e.g., tasks
> in the process of catching up may call or also call dummy operations),
> it doesn't really need the locks at all. 

In 1996, I wrote a paper describing how to do exactly that:

    "Fast Concurrent Dynamic Linking for an Adaptive Operating System"
    <ftp://cse.ogi.edu/pub/dsrg/synthetix/iccds96.ps.gz>. Crispin Cowan,
    Charles Krasic
    <http://www.cse.ogi.edu/%7Ekrasic>,
    Calton Pu <http://www.cse.ogi.edu/%7Ecalton>, and Jonathan Walpole
    <http://www.cse.ogi.edu/%7Ewalpole>. Presented at the /International
    conference on Configurable Distributed Systems (ICCDS'96)/, May 6-8,
    1996, Annapolis, MD.

What it provides is a funky data structure that looks kinda like a 
function pointer, but with asymmetric locking. Locking a function for 
*use* (i.e. calling the function) is relatively fast, while locking the 
function for *change* (changing the function pointer) is relatively 
slow. The fast/call path was measured to be faster than ordinary locks 
on the same hardware, for both HP-PA/HPUX, and for x86/Linux.

Recently, I asked Chris Wright to look at this algorithm precisely for 
the module unloading problem. Chris's conclusion was that this approach 
is not really feasible for mainstream Linux inclusion. The problem is 
that the funky Crispy Function Pointers get called from all through the 
kernel, and while they are faster than locks, the are a LOT slower than 
function calls. Linus is unlikely to accept the overhead that my funky 
function calls impose.

> Forcing a module to "never quite unload" also solves much. 

That is the approach that I favor: to the extent that unloading requires 
locking, don't support unloading. From discussions at Ottawa, this 
approach has increasing support among kernel maintainers.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                      http://wirex.com/~crispin/
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

X-
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module