lkml.org 
[lkml]   [2012]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][CFT][CFReview] execve and kernel_thread unification work
    I just looked through the "powerpc: split ret_from_fork" commit in
    your for-next branch, and I have a couple of comments.

    First, on 64-bit powerpc, if kernel_thread() is called on a function
    in a module, and that function returns, we'll then jump to do_exit
    with r2 pointing to the module's TOC rather than the main kernel's
    TOC, with disastrous results. It would be easily solved by adding a

    ld r2,PACATOC(r13)

    before the branch to .do_exit in the 64-bit ret_from_kernel_thread().
    Maybe no-one ever calls kernel_thread() on a function in a module
    today, but I don't want to rely on that being true forever, especially
    since it's only one more instruction to guard against the possibility.

    Secondly, while the code as you have it is correct, to my mind it
    would be cleaner to put the function descriptor address in r14 on
    64-bit, rather than the function text address, and then dereference it
    to get the TOC and text address at the point of doing the call. That
    would reduce the differences between 32-bit and 64-bit in
    copy_thread() and make it more obvious that ret_from_kernel_thread()
    is setting the right TOC value in r2.

    In fact copy_thread() doesn't need to set r2 in the 32-bit case, since
    _switch() sets r2 to the task_struct for the task it's switching to,
    and ignores the r2 value in the stack frame. So with my suggestion
    copy_thread() wouldn't need to set childregs->gpr[2] at all (for the
    kernel thread case).

    Paul.


    \
     
     \ /
      Last update: 2012-10-11 11:41    [W:2.563 / U:0.312 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site