summaryrefslogtreecommitdiffstats
path: root/module/zfs/zpl_ctldir.c
diff options
context:
space:
mode:
authorBrian Behlendorf <[email protected]>2013-08-14 16:18:58 -0700
committerBrian Behlendorf <[email protected]>2013-08-15 15:20:36 -0700
commit34e143323e359b42bc9d06dd19cc4b1f13091283 (patch)
treed38649ddbcacd0c45d4f4c26242e180c1d742113 /module/zfs/zpl_ctldir.c
parent0bc7a7a75429f3f5dc68e57dfad4c5fb84a48558 (diff)
Fix z_wr_iss_h zio_execute() import hang
Because we need to be more frugal about our stack usage under Linux. The __zio_execute() function was modified to re-dispatch zios to a ZIO_TASKQ_ISSUE thread when we're in a context which is known to be stack heavy. Those two contexts are the sync thread and what ever thread is performing spa initialization. Unfortunately, this change introduced an unlikely bug which can result in a zio being re-dispatched indefinitely and never being executed. If during spa initialization we handle a zio with ZIO_PRIORITY_NOW it will be moved to the high priority queue. When __zio_execute() is called again for the zio it will mis- interpret the context and re-dispatch it again. The system will get stuck spinning re-dispatching the zio and making no forward progress. To fix this rare issue __zio_execute() has been updated not to re-dispatch zios on either the ZIO_TASKQ_ISSUE or ZIO_TASKQ_ISSUE_HIGH task queues. In practice this issue was rarely reported and can usually be fixed by rebooting the system and importing the pool again. Signed-off-by: Brian Behlendorf <[email protected]> Closes #1455
Diffstat (limited to 'module/zfs/zpl_ctldir.c')
0 files changed, 0 insertions, 0 deletions