[PATCH] Revert "driver: block: release the lo_work_lock before queue_work"

[PATCH] Revert "driver: block: release the lo_work_lock before queue_work"

[zhaoyang.huang]

From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>

This reverts commit ad934fc1784802fd1408224474b25ee5289fadfc.

loop_queue_work should be strictly serialized to loop_process_work since
the lo_worker could be freed without noticing new work has been queued
again.

Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
 drivers/block/loop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 68c943a77e41..c05fe27a96b6 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -894,8 +894,8 @@ static void loop_queue_work(struct loop_device *lo, struct loop_cmd *cmd)
 		cmd_list = &lo->rootcg_cmd_list;
 	}
 	list_add_tail(&cmd->list_entry, cmd_list);
-	spin_unlock_irq(&lo->lo_work_lock);
 	queue_work(lo->workqueue, work);
+	spin_unlock_irq(&lo->lo_work_lock);
 }
 
 static void loop_set_timer(struct loop_device *lo)
-- 
2.25.1

Re: [PATCH] Revert "driver: block: release the lo_work_lock before queue_work"

[Jens Axboe]

On Tue, 18 Feb 2025 14:58:35 +0800, zhaoyang.huang wrote:
> This reverts commit ad934fc1784802fd1408224474b25ee5289fadfc.
> 
> loop_queue_work should be strictly serialized to loop_process_work since
> the lo_worker could be freed without noticing new work has been queued
> again.
> 
> 
> [...]

Applied, thanks!

[1/1] Revert "driver: block: release the lo_work_lock before queue_work"
      commit: 02b3c61aab443d8c1cc7d7eb0ae0a8d86b547224

Best regards,
-- 
Jens Axboe

Re: [PATCH] Revert "driver: block: release the lo_work_lock before queue_work"

[Christoph Hellwig]

On Tue, Feb 18, 2025 at 02:58:35PM +0800, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> 
> This reverts commit ad934fc1784802fd1408224474b25ee5289fadfc.
> 
> loop_queue_work should be strictly serialized to loop_process_work since
> the lo_worker could be freed without noticing new work has been queued
> again.

Btw, if you care about the lock contention you might want to split out
the trivial non-cgroup version into a separate helper or at least
branch and reduce the lock hold time there.