lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 26 Apr 2009 19:10:56 -0700 (PDT) From: Roland McGrath <roland@...hat.com> To: Oleg Nesterov <oleg@...hat.com> Cc: Jeff Dike <jdike@...toit.com>, linux-kernel@...r.kernel.org Subject: Re: copy_process() && ti->flags (Was: PT_DTRACE && uml) > dup_task_struct()->setup_thread_stack() copies parent's ti->flags. > > Why? Which flags should be actually copied? I must have missed > something, but whats wrong with the patch below? I suspect it just evolved that way as the default case of how copy_process() is written: copy whole structs, and then fix them up. Almost all the details of struct thread_info are arch-specific, so whether copy-and-fix or start-from-zero is better really has to be decided by each arch maintainer. Your next two questions are not about UML, but about arch/x86 code. Those should be directed to the x86 maintainers, whom you did not CC. > OK, it is wrong. On x86 we should at least copy TIF_IA32. But > why should we copy, say, TIF_DEBUG? TIF_DEBUG is set when task->thread.debugregN fields have interesting values. The semantics today are that those values are copied, so copying TIF_DEBUG too makes the child's context switches do what they should. This illustrates the general point: since the overall policy defaults to copying, then what actually keeps the code simpler overall is to have the same default at each substructure (and so it is for thread_struct and thread_info). If some things should be cleared, they are cleared explicitly. Hence, to clear TIF_DEBUG one would have to do it on purpose, and would be required to think about what TIF_DEBUG means and that clearing thread->debugregN goes along with it. (And at this point, one would then realize that one can't do it without changing the user-visible semantics.) > Actually, I don't understand why don't we use TS_IA32 instead of > TIF_IA32. Only current can change this flag, perhaps it makes sense > to move it in thread_info->status. However, it is tested by other threads asynchronously. The stated use of TS_* flags is things only tested by current or when current is stopped (e.g. TS_COMPAT). In other uses like TASK_SIZE_OF(), get_gate_vma(), etc., that might not be so. It might be so on x86 that there can never be any modification to ti->status that could momentarily clear some bit, but that is not formally said to be required. > copy_process()->clear_tsk_thread_flag(TIF_SIGPENDING) looks unneeded > in any case... It goes along with init_sigpending(). But it's actually potentially wrong in case of shared_pending signals. Do recalc_sigpending_tsk() if anything. As I think you intend to point out, it is always pretty harmless to leave TIF_SIGPENDING set. (get_signal_to_deliver will just figure it out.) So I think that should just be removed, independent of your other questions. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists