[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-25 11:20 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0131020) jkroon (reporter) - 2011-01-25 11:20
 https://issues.asterisk.org/view.php?id=18604#c131020 
---------------------------------------------------------------------- 
It did ... works now.

I've also included some goto fixes in dahdi_ioctl_loadzone that removes a
few calls to kfree and instead leaves the free'ing after the error_exit
label.  I also noticed three goto's out of the for() loop around which I'm
locking, as such I've added a unlock_error_exit which first unlocks the
mutex before returning.

The single return that I've updated wouldn't cause a memory leak (both z
and work was being freed and was as a result of z->name = kasprintf()
failure, but my feeling is rather safe than sorry.

I also don't see a cleaner way for ensuring the mutex is unlocked than
adding the extra unlock_error_exit label.

In dahdi_ioctl_set_dialparams I only lock after copy_from_user().  I
mention this because gdp = &global_dialparams _before_ I take the lock.  It
should be noted that taking the address of global_dialparams doesn't access
the struct, thus this is safe.

I can confirm that the code compiles both with and without CONFIG_BKL. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-25 11:20 jkroon         Note Added: 0131020                          
======================================================================