Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp1333021iog; Sat, 25 Jun 2022 06:45:29 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sbIKkXc0luZ8mvl6FOn6+puRqLqSUZLR7pY25PMOS9dkA9Xwzn99gBf7hjBylzp2B3tGKm X-Received: by 2002:a05:6402:d5c:b0:435:6e2f:245b with SMTP id ec28-20020a0564020d5c00b004356e2f245bmr5177599edb.145.1656164729037; Sat, 25 Jun 2022 06:45:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656164729; cv=none; d=google.com; s=arc-20160816; b=qtOcOSRwaajSBWhir+vW4kRfWFG7d39La9JFjzVaA/e72UtBNX2pUOkU+azCtg5c/I Svg25OSVQCyU8YZgKBaS4e5iODLmo/VUN2n2QHob0MiLq4BJ9zOyUw48y5WZvvtZIJ+f 1QmifVfa0aXfHQr++JOUWvZRmeW6vVGF4wcLETgEYSXJe1ORDAVQjGjBBo4wIr08qnTe aPd0bilUzvb0r6Zr6YLSTWnl/mMntJ22Lnb66sfwM0T7kmzDO8iBmU2ApORMH6uWsLxx Wafz0DmDU+8b/fHJ/XhEXfnAeuZzXzePUTNTOMddiWz5C8aCpBheQYVGtjPTTrGUwGY4 sg6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=kg4H+IKy87dxQj7m2msI04pKtAzzztXICYYExK5g4PY=; b=UrsWBoTOqK2J52HKQD/7Q1x4ygEyUIR0EVr7j5eOhcUW/j0bvhv6Va8hJvJqzSlLr+ WtgYdhEl14NMMjSi+aNlcaamnQm7UA50lO7HJGRAMiWb9Kfx5ltlEr+JvW+2f/d/pb6j dWHmxCXHkBatiiwII2pyCoCed6YcwmxtNZmtCcS36sH5cYY6TpHn0AxzkEJgeG3I6gyH ObXdIGygJ5n7ldWPN8mBBGOwXItn4Zew3ntwjNmAy4se3Av5ro0bs94rGJjaZkFNrutP NFGZ5lWuX44RLflVkS1Nbd91HneS2EjC048ct6PyQIoQ+D1YIAqQm0+JRgxuVaOmm9A/ 954g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w20-20020a50d794000000b004355e63f6a3si6238368edi.530.2022.06.25.06.45.03; Sat, 25 Jun 2022 06:45:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233033AbiFYNSi (ORCPT + 99 others); Sat, 25 Jun 2022 09:18:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233032AbiFYNSi (ORCPT ); Sat, 25 Jun 2022 09:18:38 -0400 Received: from mail.meizu.com (unknown [14.29.68.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D5881EAD8 for ; Sat, 25 Jun 2022 06:18:34 -0700 (PDT) Received: from IT-EXMB-1-125.meizu.com (172.16.1.125) by mz-mail04.meizu.com (172.16.1.16) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sat, 25 Jun 2022 21:18:34 +0800 Received: from localhost.localdomain (172.16.255.36) by IT-EXMB-1-125.meizu.com (172.16.1.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Sat, 25 Jun 2022 21:18:31 +0800 From: Even To: CC: , , , Even Subject: [PATCH] erofs: Wake up all waiters after z_erofs_lzma_head ready. Date: Sat, 25 Jun 2022 21:18:09 +0800 Message-ID: <20220625131809.6081-1-chenyuwen1@meizu.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [172.16.255.36] X-ClientProxiedBy: IT-EXMB-1-126.meizu.com (172.16.1.126) To IT-EXMB-1-125.meizu.com (172.16.1.125) X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,MAY_BE_FORGED, SPF_HELO_NONE,SPF_SOFTFAIL,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When the user mounts the erofs second times, the decompression thread may hung. The problem happens due to a sequence of steps like the following: 1) Task A called z_erofs_load_lzma_config which obtain all of the node from the z_erofs_lzma_head. 2) At this time, task B called the z_erofs_lzma_decompress and wanted to get a node. But the z_erofs_lzma_head was empty, the Task B had to sleep. 3) Task A release nodes and push nodes into the z_erofs_lzma_head. But task B was still sleeping. One example report when the hung happens: task:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000 Workqueue: erofs_unzipd z_erofs_decompressqueue_work Call Trace: __schedule+0x281/0x760 schedule+0x49/0xb0 z_erofs_lzma_decompress+0x4bc/0x580 ? cpu_core_flags+0x10/0x10 z_erofs_decompress_pcluster+0x49b/0xba0 ? __update_load_avg_se+0x2b0/0x330 ? __update_load_avg_se+0x2b0/0x330 ? update_load_avg+0x5f/0x690 ? update_load_avg+0x5f/0x690 ? set_next_entity+0xbd/0x110 ? _raw_spin_unlock+0xd/0x20 z_erofs_decompress_queue.isra.0+0x2e/0x50 z_erofs_decompressqueue_work+0x30/0x60 process_one_work+0x1d3/0x3a0 worker_thread+0x45/0x3a0 ? process_one_work+0x3a0/0x3a0 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Signed-off-by: Even --- fs/erofs/decompressor_lzma.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/erofs/decompressor_lzma.c b/fs/erofs/decompressor_lzma.c index 05a3063cf2bc..5e59b3f523eb 100644 --- a/fs/erofs/decompressor_lzma.c +++ b/fs/erofs/decompressor_lzma.c @@ -143,6 +143,7 @@ int z_erofs_load_lzma_config(struct super_block *sb, DBG_BUGON(z_erofs_lzma_head); z_erofs_lzma_head = head; spin_unlock(&z_erofs_lzma_lock); + wake_up_all(&z_erofs_lzma_wq); z_erofs_lzma_max_dictsize = dict_size; mutex_unlock(&lzma_resize_mutex); -- 2.25.1