lkml.org 
[lkml]   [2016]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: kthread_stop insanity (Re: [[DEBUG] force] 2642458962: BUG: unable to handle kernel paging request at ffffc90000997f18)
    On 06/27, Andy Lutomirski wrote:
    >
    > On Mon, Jun 27, 2016 at 7:54 AM, Oleg Nesterov <oleg@redhat.com> wrote:
    > >
    > >> Is there seriously no way to directly wait for a struct task_struct to
    > >> exit? Could we, say, kmalloc the completion (or maybe even the whole
    > >> struct kthread) and (ick!) hang it off ->vfork_done?
    > >
    > > Sure we can... And yes, I think we need to alloc the whole struct kthread.
    > > Just another (unfortunate) complication, the current code is simple.
    > >
    > > And probably kthread/kthread_stop should switch to task_work_exit().
    >
    > Want to send a patch? I could do it, but you understand this code
    > much better than I do.

    Well, I'll try to do this tomorrow unless you do it.

    The problem is not the wait_for_completion(vfork_done) in kthread_stop(),
    we can avoid this immediately if we change it to use task_work_add().

    The problem is to_live_kthread(). And damn, it seems to me that in the
    long term we can simpy kill "struct kthread" altogether. All we need is
    kthread_data() and this is just a pointer. flags,cpu,parked should go
    into smp_hotplug_thread.

    But this needs changes, so meanwhile we will have to kmalloc() it and
    free in free_task().

    Or perhaps you can simply move "struct kthread" into task_struct as as
    temporary/ugly but trivial fix, then we can think more.

    Oleg.

    \
     
     \ /
      Last update: 2016-06-27 19:41    [W:3.631 / U:0.852 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site