* Pavel Machek <pavel@xxxxxx> wrote: > Hi! > > > >> >> --- a/kernel/exit.c > > >> >> +++ b/kernel/exit.c > > >> >> @@ -835,7 +835,7 @@ void do_exit(long code) > > >> >> /* > > >> >> * Make sure we are holding no locks: > > >> >> */ > > >> >> - debug_check_no_locks_held(tsk); > > >> >> + debug_check_no_locks_held(); > > >> > > > >> > Is task guaranteed == current? > > >> > > >> Yes, the first line of do_exit is: > > >> struct task_struct *tsk = current; > > > > > > Aha, I understand it now. > > > > > > Accessing current is slower than local variable. So your "new" code > > > will work but will be slower. Please revert this part. > > > > Using current instead of passing in tsk was done at Andrew Morton's > > suggestion, and makes no difference from the freezer's perspective > > since it would have to use current to get the task to pass in, so I'm > > going to leave it as is. > > Well, current is: > > static inline struct thread_info *current_thread_info(void) > { > register unsigned long sp asm ("sp"); > return (struct thread_info *)(sp & ~(THREAD_SIZE - 1)); > } That's the old 32-bit x86 trick to compute 'current' from the kernel stack pointer. It can be done better - for example on platforms with optimized percpu variables (x86-64) it looks like this: static inline struct thread_info *current_thread_info(void) { struct thread_info *ti; ti = (void *)(this_cpu_read_stable(kernel_stack) + KERNEL_STACK_OFFSET - THREAD_SIZE); return ti; } Which turns the computation of 'current' into a single instruction. For example, to access current->pid [which fields is at offset 0x2a4], we get: 3ad0: 65 48 8b 04 25 00 00 mov %gs:0x0,%rax 3ad7: 00 00 3ad9: 8b 80 a4 02 00 00 mov 0x2a4(%rax),%eax I also agree with the removal of the 'tsk' parameter because the function itself internally assumes that tsk == current. [ We could perhaps rename the function to debug_check_no_locks_held_curr(), to make it clear it operates on the current task. ] Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html