diff options
| author | riastradh <riastradh@NetBSD.org> | 2020-05-24 17:26:18 +0000 |
|---|---|---|
| committer | riastradh <riastradh@NetBSD.org> | 2020-05-24 17:26:18 +0000 |
| commit | c2506c42f6f94f25ab6ef91d05c7e77677b19a2a (patch) | |
| tree | 0debc69a38e6ecaeb6d6626c707b7d589687dcba /external/mit/libuv/dist/docs/code/plugin | |
| parent | 1200af1fcfb10f6c9abda568963cd033f60c2106 (diff) | |
Fix races in sdmmc tasks and teach ld@sdmmc to abort xfers on detach.
- Teach sdmmc_add_task to queue it only if not already queued.
- Remove now-redundant logic to avoid repeated queueing elsewhere.
- Teach sdmmc_del_task to wait until task has completed.
- Call sdmmc_del_task in various needful places.
- Replace abuse of pcq by a lock and a tailq.
(pcq is multi-producer, _single_-consumer, but there are potentially
multiple consumers here and really only one producer.)
- Teach ld_sdmmc to abort xfers on detach.
(Mechanism is kinda kludgey but it'll do for now; any effort one is
tempted to spend overhauling this should be spent overhauling sdmmc
to support proper asynchronous commands.)
- Make sure ld_sdmmc_discard either returns failure or eventually calls
ldenddiscard.
XXX Currently ld_sdmmc_detach aborts xfers _before_ ldbegindetach has
has committed to detaching or not. This is currently necessary to
avoid a deadlock because ldbegindetach waits for xfers to drain --
which strikes me as wrong; ldbegindetach shouldn't wait for anything,
and should only make the decision to commit to detaching or not so
the caller can decide whether to abort xfers before we actually wait
for them in ldenddetach.
XXX pullup -- although this changes some kernel symbols (sdmmc_add_task
and sdmmc_del_task), it shouldn't affect any existing modules; the only
module that uses sdmmc is ld_sdmmc.kmod, which is `.if 0' in the build
so there shouldn't be any of them floating around.
Diffstat (limited to 'external/mit/libuv/dist/docs/code/plugin')
0 files changed, 0 insertions, 0 deletions
