lkml.org 
[lkml]   [2006]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH, RFC] reimplement flush_workqueue()
    On 12/18, Andrew Morton wrote:
    >
    > On Mon, 18 Dec 2006 01:34:16 +0300
    > Oleg Nesterov <oleg@tv-sign.ru> wrote:
    >
    > > NOTE: I removed 'int cpu' parameter, flush_workqueue() locks/unlocks
    > > workqueue_mutex unconditionally. It may be restored, but I think it
    > > doesn't make much sense, we take the mutex for the very short time,
    > > and the code becomes simpler.
    > >
    >
    > Taking workqueue_mutex() unconditionally in flush_workqueue() means
    > that we'll deadlock if a single-threaded workqueue callback handler calls
    > flush_workqueue().

    Well. But flush_workqueue() drops workqueue_mutex before going to sleep ?

    flush_workqueue(single_threaded_wq);
    ...
    mutex_lock(&workqueue_mutex);
    ...
    mutex_unlock(&workqueue_mutex);
    wait_for_completition();
    handler runs,
    calls flush_workqueue(),
    workqueue_mutex is free

    > It's an idiotic thing to do, but I think I spotted a site last week which
    > does this. scsi? Not sure..

    Ok, it is time to sleep. I'll look tomorrov and re-send if flush_cpu_workqueue()
    really needs "bool workqueue_mutex_is_locked" parameter.

    Oleg.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-12-19 01:47    [W:4.188 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site