On Fri, Oct 19, 2012 at 10:12 AM, Robert P. J. Day
[off-list ref] wrote:

  working my way through work queues and read this in workqueue.h:

/**
 * flush_scheduled_work - ensure that any scheduled work has run to completion.
 *
 * Forces execution of the kernel-global workqueue and blocks until its
 * completion.
 *
 * Think twice before calling this function!  It's very easy to get into
 * trouble if you don't take great care.  Either of the following situations
 * will lead to deadlock:
 *
 *      One of the work items currently on the workqueue needs to acquire
 *      a lock held by your code or its caller.
 *
 *      Your code is running in the context of a work routine.
 *
 * They will be detected by lockdep when they occur, but the first might not
 * occur very often.  It depends on what work items are on the workqueue and
 * what locks they need, which you have no control over.
 *
 * In most situations flushing the entire workqueue is overkill; you merely
 * need to know that a particular work item isn't queued and isn't running.
 * In such cases you should use cancel_delayed_work_sync() or
 * cancel_work_sync() instead.
 */

  and yet, there are quite a few drivers that do just that:

$ grep -rw flush_scheduled_work drivers
drivers/scsi/scsi_scan.c:       flush_scheduled_work();
drivers/scsi/qla2xxx/qla_target.c:              flush_scheduled_work();
drivers/leds/leds-blinkm.c:             flush_scheduled_work();
drivers/acpi/osl.c:      * which invoke flush_scheduled_work/acpi_os_wait_events_complete
drivers/staging/olpc_dcon/olpc_dcon.c:  flush_scheduled_work();
drivers/staging/rtl8192u/r8192U_core.c://       flush_scheduled_work();
drivers/staging/wlan-ng/prism2usb.c:            flush_scheduled_work();
drivers/staging/iio/light/tsl2563.c:    flush_scheduled_work();
drivers/staging/iio/light/tsl2563.c:    flush_scheduled_work();
drivers/staging/rtl8712/usb_intf.c:     flush_scheduled_work();
drivers/message/fusion/mptscsih.c:      flush_scheduled_work();
drivers/rtc/rtc-dev.c:                  flush_scheduled_work();
drivers/rtc/rtc-88pm860x.c:     flush_scheduled_work();
drivers/misc/mei/main.c:        flush_scheduled_work();
drivers/misc/mei/main.c:        flush_scheduled_work();
... snip, even more after this ...

  so what's up with that?  it seems inconsistent to describe that
kernel-wide routine as "overkill" while a number of drivers continue
to use it.

rday

Robert,

I saw a thread about disk i/o that may relate.  At least with disk
buffers in the block layer, it appeared it was an all or nothing
situation for flushing the queues.  So if a upper level wanted to
ensure write A completed prior to write B, the only option was:

- write A (places data in the block queue)
- flush buffers and write all data in the block queue regardless of source
- write B (places data in the block queue)

I gathered that several of the people in the thread were surprised at
the lack of granularity, but no better solution was offered, nor even
proposed for the future.

Thus, I "assume" the calls you see in the block i/o stack are truly needed.

Greg