[lkml]   [2009]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    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

    > 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.


     \ /
      Last update: 2009-04-27 04:13    [W:0.031 / U:15.512 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site