Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp2666959iog; Sun, 26 Jun 2022 23:43:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1ttxe3JCEhxCYHOBuau8FfKajTMGa/FPDzgmcynWiTb4kx4AnyPJsE85iGYp2UcyDgeZCo3 X-Received: by 2002:a17:90a:e7c7:b0:1ec:99eb:ff3a with SMTP id kb7-20020a17090ae7c700b001ec99ebff3amr18696241pjb.204.1656312203812; Sun, 26 Jun 2022 23:43:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656312203; cv=none; d=google.com; s=arc-20160816; b=V+PPHM95rabI5td596ggbkCZj/tOXgLBDt6z/PkN6zUjeGd/U2Ey4oN35frFwEvZTj uFmdqO6z2xhvADy+32pFLt2hlAalv0kOo/F0Gvwy2/njaPQEZS0/AsmTMPeS6SJ7Tv8k dKmBGNCtaCguEqWVh4yNJbo68yWIPzfyZLJdn3G/a2S0SKgL6dpEl4rAzDuqDXD7bMzf Raw9U2oK87PBGVeLF8v2z5Y+QxCWWH3d4Wz/4HNExhbGWUJwEtHubkbOXRG9zPqywW1n SFNdIdn80p3QZucZApWfYmuUYEBlgue2Y0I1dY4uDd7SvwnRcrfwAq+uHEDx2vci1hR6 oeBA== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=aKdV0e12G2v2Y44Jx02VPyrx6WvHYDijPMlZIJS5OmM=; b=SB4xE332A5Ydh9P2Tm3UPROwKjEhZBdZCfOQUXPhCBj264U2fgJHQUOtJqT9pnpMSs Di/GLhRID+f0wOYcvxavJ0+G21Jof/wDGqdOr+mcjSpmZwOwY9fTXXNPGWRyrckDEV4n Vauz+viJJkKvK22fx7T2XqNdHSo/2mbuqfjhQaFmquefxYEQ6uGPgvA9wnec4XHV/ysP XaUpU3gIwz93s6jPgW+woOJE2l2cM7n/1QS7NhI9RSb+9qeEJcsTGE+y70hFKpWX11KF Is66yBpFIIBFt+x4b4OpHPyMG6Ac464ykhRemaoI2hSLockJUxJmWB0AG8zcSf2gA2za /LHg== 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 e18-20020a056a001a9200b0051b98c3d62asi7832447pfv.233.2022.06.26.23.43.11; Sun, 26 Jun 2022 23:43:23 -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 S230182AbiF0Gk6 (ORCPT + 99 others); Mon, 27 Jun 2022 02:40:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35096 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232425AbiF0Gkt (ORCPT ); Mon, 27 Jun 2022 02:40:49 -0400 Received: from mail.meizu.com (edge05.meizu.com [157.122.146.251]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52A0C2BF9 for ; Sun, 26 Jun 2022 23:40:46 -0700 (PDT) Received: from IT-EXMB-1-125.meizu.com (172.16.1.125) by mz-mail12.meizu.com (172.16.1.108) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 27 Jun 2022 14:40:44 +0800 Received: from chenyuwen-VirtualBox.meizu.com (172.16.32.26) 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; Mon, 27 Jun 2022 14:40:43 +0800 From: Yuwen Chen To: CC: , , , , Subject: [PATCH] erofs: wake up all waiters after z_erofs_lzma_head ready Date: Mon, 27 Jun 2022 06:40:41 +0800 Message-ID: <20220626224041.4288-1-chenyuwen1@meizu.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [172.16.32.26] 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.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12, KHOP_HELO_FCRDNS,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: Yuwen Chen Reviewed-by: Gao Xiang --- 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