lkml.org 
[lkml]   [2009]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRE: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads
    (Resending with 80 column restriction) 

    > -----Original Message-----
    > From: Pavel Machek [mailto:pavel@ucw.cz]
    > Sent: Sunday, November 08, 2009 1:57 PM
    > To: Dasgupta, Romit
    > Cc: Rafael J. Wysocki; linux-omap@vger.kernel.org;
    > linux-kernel@vger.kernel.org; linux-pm@lists.linux-foundation.org
    > Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be
    > exited kernel threads
    >
    > On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
    > > > Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be
    > exited kernel
    > > > threads
    > > >
    > > > Hi!
    > > >
    > > > > Kicks out a frozen thread from the refrigerator when an
    > active thread has
    > > > > invoked kthread_stop on the frozen thread.
    > ...
    > > > > @@ -49,7 +50,7 @@ void refrigerator(void)
    > > > >
    > > > > for (;;) {
    > > > > set_current_state(TASK_UNINTERRUPTIBLE);
    > > > > - if (!frozen(current))
    > > > > + if (!frozen(current) || (!current->mm
    > && kthread_should_stop()))
    > > > > break;
    > > > > schedule();
    > > >
    > > > Well, what if the thread does some processing before
    > stopping? That
    > > > would break refrigerator assumptions...
    > >
    > > The suspend thread will block until the 'to be stopped'
    > thread clears up. That is what any call to kthread_stop would
    > boil down to. The target thread would anyway be out of the
    > refrigerator so I am not sure what assumption you mean here.
    > Eventually, the target thread would clear up and wake up the
    > suspend thread and then things would go on as usual.
    >
    > (Please format to 80 columns).
    >
    > No, I do not get it.
    >
    > Lets say we have
    >
    > evil_data_writer thread that needs to be stopped becuase it writes to
    > filesystem
    >
    > nofreeze random_stopper thread
    >
    > now we create the suspend image, and start writing it out. But that's
    > okay, evil_data_writer is stopped so it can't do no harm. But now
    > random_stopper decides to thread_stop() the evil_data_writer, and this
    > new code allows it to exit the refrigerator, *do some writing*, and
    > then stop.
    >
    > That's bad, right?
    evil_data_writer will enter refrigerator after invoking 'try_to_freeze'. This
    should be followed by a call to kthread_should_stop. There it decides if it
    needs to exit the thread (after cleanups if necessary) or not. I have seen that
    the bdi_writeback_task function is like that. It does not care if there is
    pending data to be written if it detects that someone have invoked a
    'kthread_stop' on it. It simply exits. I have seen some other kernel threads
    that do not follow this and I think that probably is not right.


    \
     
     \ /
      Last update: 2009-11-08 12:13    [W:0.026 / U:30.700 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site