AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-25 02:30:52 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity

Add cycle_kernel_lock()

Browse Source 
A number of driver functions are so obviously trivial that they do not need
the big kernel lock - at least not overtly.  It turns out that the
acquisition of the BKL in driver open() functions can perform a sort of
poor-hacker's serialization function, delaying the open operation until the
driver is certain to have completed its initialization.  Add a simple
cycle_kernel_lock() function for these cases to make it clear that there is
no need to *hold* the BKL, just to be sure that we can acquire it.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Jonathan Corbet 2008-05-18 14:27:41 -06:00
parent 6606470dd1
commit 0b28067688
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
include/linux/smp_lock.h
View File

@ -27,11 +27,24 @@ static inline int reacquire_kernel_lock(struct task_struct *task)
extern void __lockfunc lock_kernel(void) __acquires(kernel_lock);
extern void __lockfunc unlock_kernel(void) __releases(kernel_lock);
/*
* Various legacy drivers don't really need the BKL in a specific
* function, but they *do* need to know that the BKL became available.
* This function just avoids wrapping a bunch of lock/unlock pairs
* around code which doesn't really need it.
*/
static inline void cycle_kernel_lock(void)
{
lock_kernel();
unlock_kernel();
}
#else
#define lock_kernel() do { } while(0)
#define unlock_kernel() do { } while(0)
#define release_kernel_lock(task) do { } while(0)
#define cycle_kernel_lock() do { } while(0)
#define reacquire_kernel_lock(task) 0
#define kernel_locked() 1