Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp92207pxb; Thu, 7 Jan 2021 22:54:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJxoj9b9SP4djGKeVgMOaZoatmAZL3lMu3aI2sGeKQ3Q76PJ8MDuZEjTb9CCNQ54TBOVO/mm X-Received: by 2002:aa7:d354:: with SMTP id m20mr4159063edr.195.1610088850729; Thu, 07 Jan 2021 22:54:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610088850; cv=none; d=google.com; s=arc-20160816; b=kzP8t7cREL/6TKzGsjA8YviT+LmqO9KCyZTQPOAq6g/835nNiswaLcOaFrSznoTkgB LpnDdt/srdyHXcPbH2H9YW009bXVBiVvav+77R3P2za4ZAXZ6WTLEFUM6qwguiMLDNIW d7KYEe+So+1SCcwM3PfvmfhK4+FYSlpvjthbmvvYMBioKmfMpiAft0V9Sp3ZH/zLlNv3 bsbcn7JBro58DKBej1WMWqc7ZISifpFXp7bOSrlT6pvDZWAk2hKtiTY76DTb7Dv1qqt+ VAdN3ZREmiHVGDeucFIRhkKQKT7FflhqcU/ZzStxIsFfjGJFF7TgYPXK7+mI2m4r52b+ uI5A== 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=Wzyp42Y/lj++KjHKOxs1ShZyoOY8xn/qj6cjvbthZ+E=; b=XtL+xWQ1WlCPZV309GdgQ7SLnZ0pHKHfPEvjBY99H9LcqfbPxXxidYK7j3Vm00G7T2 hoYG+gOpL3jttAiHQwnc/95E1XvO6yNhV0tTuHBoh6bTfUHkjuFHJtRX215ik/Khxpo/ PfTTELzjraH3Dfdhs6734QvHtKAiAs0PSXs7zurNWbMZOD6sHtBwy+kYWTLsgixVWWs+ j8U7wT7+uNxFWc6FaPfLyzOkg4k+GUxqibYPlVhwjViq3Q0+H4xmpqFYC723kdKrqw/g BR7IdlUQHPX+umv8uBxopy0yh2+l6IgV6XOTiIQDEPfvDDfkaFY8gbSFzmTCYbghy4DV a/xw== 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 q24si3241562eji.722.2021.01.07.22.53.46; Thu, 07 Jan 2021 22:54:10 -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 S1726740AbhAHGwx (ORCPT + 99 others); Fri, 8 Jan 2021 01:52:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40484 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726484AbhAHGww (ORCPT ); Fri, 8 Jan 2021 01:52:52 -0500 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A4CEC0612F4; Thu, 7 Jan 2021 22:52:12 -0800 (PST) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kxld1-008Ges-Bm; Fri, 08 Jan 2021 06:52:07 +0000 Date: Fri, 8 Jan 2021 06:52:07 +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: <20210108065207.GP3579531@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 Wait, that's this very thread, starting with the posting I'd been replying to. Really confused now... Was that a private bug report and an equally private discussion? That's what I wanted to see... Anyway, I'm more than half-asleep right now; will get back to that in the morning.