Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp465035pxa; Wed, 19 Aug 2020 06:31:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfIaQykJB8svMH/0a/P7UNDmRcV69YZ/A2cRMLkZ3bHRcSPdwCftaz16nAFjD60X83uQEk X-Received: by 2002:a17:906:d181:: with SMTP id c1mr24550853ejz.181.1597843865760; Wed, 19 Aug 2020 06:31:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597843865; cv=none; d=google.com; s=arc-20160816; b=YdPFvI4Ee3t2a8bLKqQ7Maj8f+jFUu68G8Uy6/pKT6+4Jm5Pd2x1pBp45koEjcVzhx U60C86V4WVcgo02lW4qKpzPyUb7QLs9W9p30PkjvQWKMsnfIBii5PrL8VexWl5y7C1e/ rlAju//xAr78xMtlN505vQYlmzNcUR7Nk61p6ca3TMN4x6FRgfchepZJTqtrs19Gl+oP qdhgE8076TALDFQACySufQgUxnbPvqXwcSJ6VobqbUIuhsujB0b6WcKcEBYBqLLT0bv9 wyTKfgZga4MoXjI/S9eIbPpmQO5x+jvoGPu1+rxlkkKZipq1XVN8UA4pzCycYWpgGnrr H89A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :reply-to:message-id:subject:cc:to:from:date; bh=gZHcnh5lE577zzeXgZfRJ27UY4QgLNMeVW/WhTSVJlA=; b=eKB5TGzMjfINeRJiMHlFjbUF7SrAx1S7iCrYcL5KM2HZ/Sk2AXx1UcD+BE385fxG7Z sAEcGURMiQdMB45/eBemnwwl6nqwL4/aybHWGbHNSsyd6Smh4UhRIAh4Ak3kR5MMGSbU u9TRp0YWBdWJtbUZ56Yb5PMfH8CGVtxAKaB4+JH9G3L0cy/DT8qJLcg7esgQ1soDo6zU SubFpa29VwO5KCf5BrLFNSmNTS94SOmk4sBTidwFhWziYUyA9JbkauATMbI2ArOyAfPo F2vhWPvq2u2x7BVuWwmjJHO7lK5aNDqYpOteB9CEhCq1QloKSAul737GE7x+NUf0EE5m HL5g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id qk3si3432716ejb.253.2020.08.19.06.30.40; Wed, 19 Aug 2020 06:31:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726560AbgHSN3m (ORCPT + 99 others); Wed, 19 Aug 2020 09:29:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:34772 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726752AbgHSN3j (ORCPT ); Wed, 19 Aug 2020 09:29:39 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3E53AACC6; Wed, 19 Aug 2020 13:30:03 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 3E33CDA703; Wed, 19 Aug 2020 15:28:31 +0200 (CEST) Date: Wed, 19 Aug 2020 15:28:31 +0200 From: David Sterba To: Xianting Tian Cc: clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] btrfs: prevent hung check firing during long sync IO Message-ID: <20200819132831.GL2026@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Xianting Tian , clm@fb.com, josef@toxicpanda.com, dsterba@suse.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200819101451.24266-1-tian.xianting@h3c.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200819101451.24266-1-tian.xianting@h3c.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 19, 2020 at 06:14:51PM +0800, Xianting Tian wrote: > For sync and flush io, it may take long time to complete. > So it's better to use wait_for_completion_io_timeout() in a > while loop to avoid prevent hung check and crash(when set > /proc/sys/kernel/hung_task_panic). I wonder if long running IO should trigger the panic/kill of the task at all. A warning means that the system is under load but as long as it's making some progress it should be ok, and that seems to be a separate case from a task that's not making any progress (and terminating it is probably the best option). > This is similar to prevent hung task check in submit_bio_wait(), > blk_execute_rq(). I see, adding that workaround to btrfs would be 3rd occurence and this should go into a wrapper, eg. wait_for_completion_io_nowarn with examples where this should be used.