> On 09/10, KOSAKI Motohiro wrote: > > > > 1) moving cread_guard_mutex itself > > - no increase execve overhead > > -> very good > > - it also prevent parallel ptrace > > No, it doesn't. Only PTRACE_ATTACH needs this mutex, and as Roland > pointed out it also needs write_lock(tasklist) which is worse. So > this change doesn't make any practical harm for ptrace. I see, thanks. > > > 2) move in_exec_mm to signal_struct too > > -> very hard. oom-killer can use very few lock because it's called > > from various place. now both ->mm and ->in_exec_mm are protected > > task_lock() and it help to avoid messy. > > Yes. But, if ->in_exec_mm is only used by oom_badness(), then I think > you can use task_lock(tsk->group_leader). oom_badness() needs tasklist > anyway, this means it can't race with de_thread() changing the leader. > But up to you. Good idea. will fix. > > Another very minor nit (but again, up to you). Perhaps exec_mmap() > could clear ->in_exec_mm (in task_struct or signal_struct, this doesnt > matter), it takes task_lock(current) anyway (and at this point current > is always the group leader). Thanks. will fix. > > > Let's move ->cred_guard_mutex from task_struct to signal_struct. It > > naturally prevent multiple-threads-inside-exec. > > Reviewed-by: Oleg Nesterov <oleg@xxxxxxxxxx> > > > This is very minor, but perhaps you can also fix a couple of comments > which mention task->cred_guard_mutex, > > fs/exec.c:1109 the caller must hold current->cred_guard_mutex > kernel/cred.c:328 The caller must hold current->cred_guard_mutex > include/linux/tracehook.h:153 @task->cred_guard_mutex Will fix, of cource. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
