Pull up following revision(s) (requested by riastradh in ticket #566):

	sys/dev/sdmmc/ld_sdmmc.c: revision 1.43

ld@sdmmc(4): Hack around deadlock in cache sync on detach.

Yanking a card triggers the sdmmc discovery task, which runs in the
sdmmc task thread, to detach any attached child devices.

Detaching ld@sdmmc triggers a cache flush (via ldbegindetach ->
disk_begindetach -> ld_lastclose -> ld_flush -> ioctl DIOCCACHESYNC),
which is implemented by scheduling a task to do sdmmc_mem_flush_cache
and then waiting for it to complete.

The sdmmc_mem_cache_flush is done by an sdmmc task so it happens
after all previously scheduled I/O operations -- that way the cache
flush doesn't complete until the previously scheduled I/O operations
are complete.

However, when the cache flush task is issued from the discovery task,
this doesn't work, because the cache flush task can't start until the
discovery task has returned -- but the discovery task won't return
until the cache flush task has completed.

To work around this deadlock, which usually happens only when the
device has been yanked anyway so further I/O would be lost anyway,
just do the cache flush synchronously in DIOCCACHESYNC if we're
running in the task thread.

This isn't quite right -- implementation details of the task thread
shouldn't bleed into ld@sdmmc, and running the cache sync _before_
any subsequently scheduled I/O tasks is asking for trouble -- but it
should serve to avoid the deadlock in PR kern/57870 until we can fix
a host of concurrency bugs in sdmmc by fixing the locking scheme and
running discovery in a separate thread from tasks.


(martin)