On Mon, Jul 26, 2010 at 08:51:50PM +0200, Tejun Heo wrote:

Hello,

On 07/26/2010 06:31 PM, Michael S. Tsirkin wrote:

quoted

quoted

On 07/26/2010 06:05 PM, Tejun Heo wrote:

quoted

* Placing try_to_freeze() could be a bit annoying.  It shouldn't be
  executed when there's a work to flush.

BTW why is this important?
We could always get another work and flush right after
try_to_freeze, and then flush would block for a long time.

BTW the vhost patch you sent does not do this at all.
I am guessing it is because our thread is not freezable?

Yeap, I think so.

quoted

quoted

* Similar issue exists for kthread_stop().  The kthread shouldn't exit
  while there's a work to flush (please note that kthread_worker
  interface allows detaching / attaching worker kthread during
  operation, so it should remain in consistent state with regard to
  flushing).

Not sure I agree here. Users must synchronise flush and stop calls.
Otherwise a work might get queued after stop is called, and
you won't be able to flush it.

For freeze, it probably is okay but for stop, I think it's better to
keep the semantics straight forward.

What are the semantics then? What do we want stop followed
by queue and flush to do?

 It may be okay to do otherwise
but having such oddity in generic interface is nasty and may lead to
surprises which can be pretty difficult to track down later on.  It's
just a bit more of annoyance while writing the generic code, so...

Thanks.

-- 
tejun