From patchwork Thu Feb 27 13:37:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 230171 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05C53C11D3D for ; Thu, 27 Feb 2020 14:41:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CED1124656 for ; Thu, 27 Feb 2020 14:41:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582814498; bh=Z0QB+7rbGiC2m9djwmXluZUo1zPDh54RPm/F68tzhII=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=xYJ1fydt/+v6Fciqe5dYyddAKqb24gcroV7AGo8CIuOfiqMU/mLsunxfA3lzGKfEB lrfavXJtgeOMkbKriwm9yNDyT/usRzJIOW/e4q3Z6KLYypPNzKq4EnPikfDpT3AjkE BCav4y7paQRP92i6j7uo9x9H34HUFpzOq/e+PWlE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730958AbgB0NvP (ORCPT ); Thu, 27 Feb 2020 08:51:15 -0500 Received: from mail.kernel.org ([198.145.29.99]:50246 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731353AbgB0NvO (ORCPT ); Thu, 27 Feb 2020 08:51:14 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 857E420578; Thu, 27 Feb 2020 13:51:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582811474; bh=Z0QB+7rbGiC2m9djwmXluZUo1zPDh54RPm/F68tzhII=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CQVhge7BRA6RhDEPR5NSOfezOGl8HNKSVr/TFTTVKVkIV+hFsiuZDpN/Lx7KUsLoq 0xHm2VbGqJSr6fzoWmQjXBPbsYZOV4fV28BeVQKFTe5vQczesFfYZTn0mxvHr+9I3v 4QtWK5XO63hQoFJjY1Xmp2q08tI0jdUhK0FH6iQM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Shijie Luo , Theodore Tso , Jan Kara , stable@kernel.org Subject: [PATCH 4.9 146/165] ext4: add cond_resched() to __ext4_find_entry() Date: Thu, 27 Feb 2020 14:37:00 +0100 Message-Id: <20200227132252.150786910@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200227132230.840899170@linuxfoundation.org> References: <20200227132230.840899170@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Shijie Luo commit 9424ef56e13a1f14c57ea161eed3ecfdc7b2770e upstream. We tested a soft lockup problem in linux 4.19 which could also be found in linux 5.x. When dir inode takes up a large number of blocks, and if the directory is growing when we are searching, it's possible the restart branch could be called many times, and the do while loop could hold cpu a long time. Here is the call trace in linux 4.19. [ 473.756186] Call trace: [ 473.756196] dump_backtrace+0x0/0x198 [ 473.756199] show_stack+0x24/0x30 [ 473.756205] dump_stack+0xa4/0xcc [ 473.756210] watchdog_timer_fn+0x300/0x3e8 [ 473.756215] __hrtimer_run_queues+0x114/0x358 [ 473.756217] hrtimer_interrupt+0x104/0x2d8 [ 473.756222] arch_timer_handler_virt+0x38/0x58 [ 473.756226] handle_percpu_devid_irq+0x90/0x248 [ 473.756231] generic_handle_irq+0x34/0x50 [ 473.756234] __handle_domain_irq+0x68/0xc0 [ 473.756236] gic_handle_irq+0x6c/0x150 [ 473.756238] el1_irq+0xb8/0x140 [ 473.756286] ext4_es_lookup_extent+0xdc/0x258 [ext4] [ 473.756310] ext4_map_blocks+0x64/0x5c0 [ext4] [ 473.756333] ext4_getblk+0x6c/0x1d0 [ext4] [ 473.756356] ext4_bread_batch+0x7c/0x1f8 [ext4] [ 473.756379] ext4_find_entry+0x124/0x3f8 [ext4] [ 473.756402] ext4_lookup+0x8c/0x258 [ext4] [ 473.756407] __lookup_hash+0x8c/0xe8 [ 473.756411] filename_create+0xa0/0x170 [ 473.756413] do_mkdirat+0x6c/0x140 [ 473.756415] __arm64_sys_mkdirat+0x28/0x38 [ 473.756419] el0_svc_common+0x78/0x130 [ 473.756421] el0_svc_handler+0x38/0x78 [ 473.756423] el0_svc+0x8/0xc [ 485.755156] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [tmp:5149] Add cond_resched() to avoid soft lockup and to provide a better system responding. Link: https://lore.kernel.org/r/20200215080206.13293-1-luoshijie1@huawei.com Signed-off-by: Shijie Luo Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman --- fs/ext4/namei.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -1445,6 +1445,7 @@ restart: /* * We deal with the read-ahead logic here. */ + cond_resched(); if (ra_ptr >= ra_max) { /* Refill the readahead buffer */ ra_ptr = 0;