Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp91228pxb; Thu, 7 Jan 2021 22:51:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHyehdrczHrPQL7Wa7miOHsdbuFUhb+exAghicEnOX3IxkqjGyxyZsiJDBEIt7QrLpMpJT X-Received: by 2002:a50:e84d:: with SMTP id k13mr4176016edn.154.1610088697393; Thu, 07 Jan 2021 22:51:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610088697; cv=none; d=google.com; s=arc-20160816; b=bAbxtz9UuKgRV8hrs00ybaBf/zIYm/rbZWhgUp94wl5AME/yYB0V2LfO8WE4SNbsn9 LB72l3ulSxWCZ/qpNzQoAxGabZqfPVIQPT1YnF4j0cG0MKARPUzypUYqPI+VjEJ4EqwN NhdRakDw/y8g3tnjga0tyThUTWcKqsSY0MfXyeqFPwNADVDrrP+lmSBswwdoKegil1+F GBvSDua94WkmBTKjVbv/RVH534ehlvMM8UyKP98/C8n9bse+1QQKlWCCEXa0HJR3ScyB 1AbNtwT0rjsrVNLNYiI+JV4Pe3S4UHhw45Vz7XleW0oayWX9RouRyGCCOdPrUyoAPiOh 8Xiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=2HnHO/BP2NABf1TcS0OHGv6QS0WKiDonOhfJm+mwmoA=; b=zI9EUt0UoWcwPO3Fee2B6hEW4VHy0Px9pHOwDplgKdjnBDVC5koG6WVEBi2UIY/O/d ytEDOAp/2/G8MS+xXoouLHxj4/ltun6kEgSKNiXNYgEK4hjfsuxWae2tS39AguJGMAyJ lIcs7RL3oz0jcFBlv/M5ZQnFG9Vw8t2hjraw3jvgeO6gScdQbjzam5eiergXXJ+HTiwg gwvH5QqAfNdQjFBti4YaCLxhggKSl4zZq6BNLk47hdkMuGULZpzK4qPSmUffFYOFJNJa GDoTMjq67NrGTVVkC5L4cA/h22c1XCYVCxmTfxqBIFztYH25jAfSJKLOA2xpKtOEPuUS Tuug== 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 g5si3306684ejw.724.2021.01.07.22.51.13; Thu, 07 Jan 2021 22:51:37 -0800 (PST) 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 S1727333AbhAHGsF (ORCPT + 99 others); Fri, 8 Jan 2021 01:48:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725308AbhAHGsE (ORCPT ); Fri, 8 Jan 2021 01:48:04 -0500 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5022CC0612F5; Thu, 7 Jan 2021 22:47:24 -0800 (PST) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxlYO-008GZK-Fc; Fri, 08 Jan 2021 06:47:20 +0000 Date: Fri, 8 Jan 2021 06:47:20 +0000 From: Al Viro To: Sedat Dilek Cc: Jens Axboe , linux-fsdevel , "linux-kernel@vger.kernel.org" , Oleg Nesterov , Song Liu Subject: Re: [PATCH] fs: process fput task_work with TWA_SIGNAL Message-ID: <20210108064720.GO3579531@ZenIV.linux.org.uk> References: <20210108052651.GM3579531@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 08, 2021 at 07:21:52AM +0100, Sedat Dilek wrote: > On Fri, Jan 8, 2021 at 6:30 AM Al Viro wrote: > > > > On Tue, Jan 05, 2021 at 11:29:11AM -0700, Jens Axboe wrote: > > > Song reported a boot regression in a kvm image with 5.11-rc, and bisected > > > it down to the below patch. Debugging this issue, turns out that the boot > > > stalled when a task is waiting on a pipe being released. As we no longer > > > run task_work from get_signal() unless it's queued with TWA_SIGNAL, the > > > task goes idle without running the task_work. This prevents ->release() > > > from being called on the pipe, which another boot task is waiting on. > > > > > > Use TWA_SIGNAL for the file fput work to ensure it's run before the task > > > goes idle. > > > > > > Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") > > > Reported-by: Song Liu > > > Signed-off-by: Jens Axboe > > > > > > --- > > > > > > The other alternative here is obviously to re-instate the: > > > > > > if (unlikely(current->task_works)) > > > task_work_run(); > > > > > > in get_signal() that we had before this change. Might be safer in case > > > there are other cases that need to ensure the work is run in a timely > > > fashion, though I do think it's cleaner to long term to correctly mark > > > task_work with the needed notification type. Comments welcome... > > > > Interesting... I think I've missed the discussion of that thing; could > > you forward the relevant thread my way or give an archive link to it? > > See [1]. > > - Sedat - > > [1] https://marc.info/?t=160987156600001&r=1&w=2 Thanks; will check tomorrow.