--- - branch: netbsd-10 date: Sat Feb 3 12:39:17 UTC 2024 files: - new: 1.42.4.1 old: '1.42' path: src/sys/dev/sdmmc/ld_sdmmc.c pathrev: src/sys/dev/sdmmc/ld_sdmmc.c@1.42.4.1 type: modified id: 20240203T123917Z.bfa91ba4c27348991b0f636a61739ba4f596f7a9 log: "Pull up following revision(s) (requested by riastradh in ticket #566):\n\n\tsys/dev/sdmmc/ld_sdmmc.c: revision 1.43\n\nld@sdmmc(4): Hack around deadlock in cache sync on detach.\n\nYanking a card triggers the sdmmc discovery task, which runs in the\nsdmmc task thread, to detach any attached child devices.\n\nDetaching ld@sdmmc triggers a cache flush (via ldbegindetach ->\ndisk_begindetach -> ld_lastclose -> ld_flush -> ioctl DIOCCACHESYNC),\nwhich is implemented by scheduling a task to do sdmmc_mem_flush_cache\nand then waiting for it to complete.\n\nThe sdmmc_mem_cache_flush is done by an sdmmc task so it happens\nafter all previously scheduled I/O operations -- that way the cache\nflush doesn't complete until the previously scheduled I/O operations\nare complete.\n\nHowever, when the cache flush task is issued from the discovery task,\nthis doesn't work, because the cache flush task can't start until the\ndiscovery task has returned -- but the discovery task won't return\nuntil the cache flush task has completed.\n\nTo work around this deadlock, which usually happens only when the\ndevice has been yanked anyway so further I/O would be lost anyway,\njust do the cache flush synchronously in DIOCCACHESYNC if we're\nrunning in the task thread.\n\nThis isn't quite right -- implementation details of the task thread\nshouldn't bleed into ld@sdmmc, and running the cache sync _before_\nany subsequently scheduled I/O tasks is asking for trouble -- but it\nshould serve to avoid the deadlock in PR kern/57870 until we can fix\na host of concurrency bugs in sdmmc by fixing the locking scheme and\nrunning discovery in a separate thread from tasks.\n" module: src subject: 'CVS commit: [netbsd-10] src/sys/dev/sdmmc' unixtime: '1706963957' user: martin