July 2017 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

naming conventions
by John de la Garza July 23, 2017

July 23, 2017

Are there naming conventions that are preferred for functions? I'm seeing somethings named foo_free, free_foo, foo_init, init_foo, etc. Consistency provides names that are easy to guess/learn. examples from: linux/kernel/fork.c #################################### static void free_thread_stack(struct task_struct *tsk) { kmem_cache_free(thread_stack_cache, tsk->stack); } void thread_stack_cache_init(void) { thread_stack_cache = kmem_cache_create("thread_stack", THREAD_SIZE, THREAD_SIZE, 0, NULL); BUG_ON(thread_stack_cache == NULL); } if (init_new_context(p, mm))

1 0

Re: kthread_stop always returning -EINTR?
by valdis.kletnieks＠vt.edu July 18, 2017

July 18, 2017

On Tue, 18 Jul 2017 15:13:08 -0300, Martin Galvan said: > I thought kthread_create/bind don't actually run the thread function? > At least that's what the comment says. It's the wake_up_process() that causes the problem... > > * If threadfn() may call do_exit() itself, the caller must ensure > > * task_struct can't go away. > > > > Your function calls do_exit() itself. It's surprising that your kernel > > didn't explode when the tasx_struct went away. > > Yeah, my bad. I'm guessing I should've just returned zero? That's not the problem. The problem is the task_struct went away when you called do_exit(), and it can do so in between the two lines wake_up_process() and kthread_stop(). Classic race condition. > > Looking at the code of > > kthread_stop, there's phenomenally little error checking (as most heavily-called > > kernel functions tend to be). It just assumes that 'thread' points at > > a valid thread structure and runs with it, with the result that you get back > > possibly random trash as 'result'. > > Would it be worth it to send out a patch to add some error checking? > I'd be happy to fix this. It will be NAK'ed *really* fast. It's assumed that kernel programmers know what they're doing, so if their kernel breaks because they call kthread_stop() on a non-existent thread, it's their own fault. It *tells* you flat out: * If threadfn() may call do_exit() itself, the caller must ensure * task_struct can't go away. > > Two important kernel concepts: Locking and reference counting. Use them wisely. > > Will do, though I'm not sure how those would apply here since (AFAIK) > there are no variables shared between the threads. It's not variables shared between the threads. What you're doing here is more the equivalent of returning the address of a variable in the stack: int *dont_do_this() { int a; return (&a); } Except here, it's not an int, it's a whole task_struct that you're doing a use-after-release.

2 3

kthread_stop always returning -EINTR?
by Martin Galvan July 18, 2017

July 18, 2017

Hi everyone! I'm doing a bit of testing on the Linux kthread functions, and have the following module: #include <linux/module.h> #include <linux/kthread.h> #include <linux/sched.h> #include <linux/smp.h> #include <linux/cpumask.h> #include <linux/err.h> MODULE_LICENSE("GPL"); int function(void *data) { printk(KERN_DEBUG "CPU: %u\n", smp_processor_id()); do_exit(0); /* Not sure if this is ok */ } /* Function executed upon loading driver */ int __init init_module(void) { unsigned int cpu; printk(KERN_DEBUG "init\n"); for_each_present_cpu(cpu) { struct task_struct *thread = kthread_create(function, NULL, "Thread %u", cpu); if (!IS_ERR(thread)) { int result; /* Bind the thread to the current core */ kthread_bind(thread, cpu); /* Start the thread */ wake_up_process(thread); /* Wait for the thread function to complete */ result = kthread_stop(thread); printk(KERN_DEBUG "Thread %u stopped with result %d\n", cpu, result); } else { printk(KERN_ALERT "Could not create a thread bound to core number %u\n", cpu); break; } } return 0; } /* Function executed when unloading module */ void cleanup_module(void) { printk(KERN_DEBUG "exit\n"); } >From what I understood, I should be able to see all the "CPU: ..." prints before init_module ends. However, kthread_stop is always returning -EINTR, as if wake_up_process wasn't actually being called. What am I doing wrong? (Please CC me directly when you answer this)

2 1

new sysctl tunable knob for tcpip
by Massimo Sala July 18, 2017

July 18, 2017

I have an idea about a new sysctl knob. It is under net.ipv4. q1) which is the right kernel m-list to discuss it ? 2) any suggestion how to gain the critical mass of consensus ? 3) at first : is it mandatory to code the patch ? optional ... but better for 2) ? best regards, Sala

3 2

[PATCH v4] staging: rtl8723bs: Place constant at the right.
by Shreeya Patel July 18, 2017

July 18, 2017

Move constant to the right of the relational operator to follow the pattern which is more common in kernel code". Problem found by checkpatch. Signed-off-by: Shreeya Patel <shreeya.patel23498(a)gmail.com> --- Changes in v4: -Make the commit message more appropriate. drivers/staging/rtl8723bs/core/rtw_btcoex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/core/rtw_btcoex.c b/drivers/staging/rtl8723bs/core/rtw_btcoex.c index 3c5cb78..01f78d1 100644 --- a/drivers/staging/rtl8723bs/core/rtw_btcoex.c +++ b/drivers/staging/rtl8723bs/core/rtw_btcoex.c @@ -55,7 +55,7 @@ void rtw_btcoex_ConnectNotify(struct adapter *padapter, u8 action) void rtw_btcoex_MediaStatusNotify(struct adapter *padapter, u8 mediaStatus) { - if ((RT_MEDIA_CONNECT == mediaStatus) + if ((mediaStatus == RT_MEDIA_CONNECT) && (check_fwstate(&padapter->mlmepriv, WIFI_AP_STATE) == true)) { rtw_hal_set_hwreg(padapter, HW_VAR_DL_RSVD_PAGE, NULL); } -- 2.7.4

2 1

[PATCH 390/390] staging:rtl8723bs:core:rtw_btcoex: Fixed checkpatch.pl warning on 'Comparisons should place the constant on the right side of the test'.
by Shreeya Patel July 18, 2017

July 18, 2017

Fixed a coding style issue. Signed-off-by: Shreeya Patel <shreeya.patel23498(a)gmail.com> --- drivers/staging/rtl8723bs/core/rtw_btcoex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8723bs/core/rtw_btcoex.c b/drivers/staging/rtl8723bs/core/rtw_btcoex.c index 3c5cb78..01f78d1 100644 --- a/drivers/staging/rtl8723bs/core/rtw_btcoex.c +++ b/drivers/staging/rtl8723bs/core/rtw_btcoex.c @@ -55,7 +55,7 @@ void rtw_btcoex_ConnectNotify(struct adapter *padapter, u8 action) void rtw_btcoex_MediaStatusNotify(struct adapter *padapter, u8 mediaStatus) { - if ((RT_MEDIA_CONNECT == mediaStatus) + if ((mediaStatus == RT_MEDIA_CONNECT) && (check_fwstate(&padapter->mlmepriv, WIFI_AP_STATE) == true)) { rtw_hal_set_hwreg(padapter, HW_VAR_DL_RSVD_PAGE, NULL); } -- 2.7.4

2 1

why inode reference i_count = 1 for all executable and libraries ?
by Lev Olshvang July 12, 2017

July 12, 2017

1 0

Camera Driver
by Wasim Akram July 12, 2017

July 12, 2017

What is the difference between iso buffer and sio buffer in camera driver code ?

1 0

Query regarding kernel modules intercepting system call.
by Ajinkya Surnis July 9, 2017

July 9, 2017

Hi guys, I'm new to kernelnewbies and this is my first question in the list. I'm working on system call interception (for open() system call) and I got one problem: I have two kernel modules (mod1 and mod2) and both of them are trying to intercept open() syscall. I've loaded mod1 first and then mod2. The mod1 intercepted open() by: original_open1 = sys_call_table[__NR_open]; sys_call_table[__NR_open] = mod1_open; Here original_open1 would be sys_open. After this, mod2 intercepted open() by: original_open2 = sys_call_table[__NR_open]; sys_call_table[__NR_open] = mod2_open; Here, original_open2 would be mod1_open() since mod1 was loaded first. Now, the problem is: Suppose I unload mod1 first and open() system call gets executed, then mod2_open() would get called, which ultimately calls mod1_open(). Since mod1 is already unloaded, calling mod1_open() caused panic (since the function pointer is no longer a valid memory region). I need some mechanism to avoid this problem. Basically, I want a solution which facilitates loading/unloading the modules (which intercept same syscall) in any random order without causing any panic. Is there some kind of facility such that while unloading the module (`mod2` here), the module will broadcast the message to all other modules that it's being unloaded and instead of refering to `original_open2()` the other modules should use `original_open1()`. Your help would really be appreciated. Thanks, Ajinkya.

5 13

is `mixing declarations and code' allowed?
by Shiyao Ma July 8, 2017

July 8, 2017

Hi, One thing I feel very un-comfortable when writing kernel module code is the warning of `mixing declarations and code'. Is `mixing declarations and code' still frowned upon by kernel developers? Or is it just a history burden that for some reason one can not mix `declarations and code'? Best,

2 2