[asterisk-bugs] [DAHDI-linux 0018604]: [patch] fails to compile against kernel 2.6.37 without CONFIG_BKL

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18604 
====================================================================== 
Reported By:                jkroon
Assigned To:                
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   18604
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     acknowledged
JIRA:                       DAHDI-752 
Reviewboard Link:            
====================================================================== 
Date Submitted:             2011-01-12 07:28 CST
Last Modified:              2011-01-24 02:58 CST
====================================================================== 
Summary:                    [patch] fails to compile against kernel 2.6.37
without CONFIG_BKL
Description: 
dahdi-linux refuses to compile against the 2.6.37 kernel unless CONFIG_BKL
is set.  CONFIG_BKL is set to die very soon.
====================================================================== 

---------------------------------------------------------------------- 
 (0130915) jkroon (reporter) - 2011-01-24 02:58
 https://issues.asterisk.org/view.php?id=18604#c130915 
---------------------------------------------------------------------- 
Hi, sorry for the delay.  Ran into some other issues.

I'm unable to clone the svn HEAD (something regarding OPTIONS request
failing), and I'm unsure of how to configure git for proxy use to get to
github, so I'm afraid I'll just have to hope the patch I'm about to attach
will apply to trunk.  Sorry.

Also, the semaphore patches looks good, thanks for pointing those out.

I've opted to use a mutex over a spinlock specifically due to calls to
printk and kfree in ioctl_load_zone - as far as I understand there are up
to four updates to global_dialparams that we want to happen "atomically" so
I need to lock over the for(;;) loop, that loop contains printk and kfree
calls, whilst there seems to be indications that kfree is in fact OK under
spinlock use I don't think the same can be said for the printk.

As it stands I've tried to keep the code to NOT use {un,}lock_kernel if
HAVE_UNLOCKED_IOCTL doesn't exist, but to use it if we're using the
unlocked ioctl and CONFIG_BKL is set (if both HAVE_UNLOCKED_IOCTL and
CONFIG_BKL is set).  Additionally, the mutex on global_dialparams is
unconditional.  I've used a mutex instead of a spinlock as per the
explanation above. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-24 02:58 jkroon         Note Added: 0130915                          
======================================================================