Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp13910268pxu; Mon, 4 Jan 2021 07:44:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwsdfyBYFtq+ncXjr/7VEgwneobXbqbJN3JsvKDBZm2//priMuRvG6jC6/9TkD2y/EpvtuX X-Received: by 2002:a05:6402:1803:: with SMTP id g3mr72346605edy.10.1609775085149; Mon, 04 Jan 2021 07:44:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609775085; cv=none; d=google.com; s=arc-20160816; b=Ediuy7IqeH9MpSvSeKHay0snWDioxNrFG9NuuwCS8XPVnROOGLFQ2za+g6gNDBbKqi qEK19I6hCA3Ur3LwFBaoQZJiCT1xZ/xYNiiW6qg0jxNrYO1XaV3OntJYQKuUEQqDvGZf twWrmWaSC1DEGxmgMWNj8Vf7QDsZW8Bp8jLCU2tmOwuuB0w8nJ4Hyw3B75ukBQ7ENu1T tqU9f+OB16IvldJ5+AZduNO00UCw0TrQv9pKGwXXVtgjk14OCTP8naJ+elRQ1pNcHXKB Ddl32b6RCos8PgmH7x8JwRnm8d6UE1+WE+gLwqiIz4FlUO7G8o8LoRo5j8ZCa5HSM8ne a13Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=gyojpWNSzgtWyJREo2LjY5m6YVWxrpfHvlQARKlxkEw=; b=LsFKhnDw3Wcm2P5jAeSChEQd194twoZmUG6JDssUAceWpz51xIbPIg/1JXf4zdjmHa RICMi5konHMk0hhmOrSSapMAwBV77VD8VC7Re/CaMHiRXPAfCyvtAzFQdNC/t/Tje6Ug L7VeP3Qn9dB5oNoWC0OLi4AB7IYn07/aNPktQvuxENtGmn3ux+/MNp8mVuXN/TsNHNcD LVPpFxP3+oX/S0viVDpnU+7osjbP+vw5L5pSdCt01jPuemEi8v6S1oIjFrjedov8RebY CNJRaNj9IGtH1x9FvscTAbbn3fShfBKo4y9R4tPbLg7yolGUPDjJcoG/l+MFg7mUD6g+ /BSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gD4kq5qz; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q25si30701382edw.87.2021.01.04.07.44.22; Mon, 04 Jan 2021 07:44:45 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gD4kq5qz; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727674AbhADPlu (ORCPT + 99 others); Mon, 4 Jan 2021 10:41:50 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:37100 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727612AbhADPlt (ORCPT ); Mon, 4 Jan 2021 10:41:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1609774822; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gyojpWNSzgtWyJREo2LjY5m6YVWxrpfHvlQARKlxkEw=; b=gD4kq5qzAc/dPSdKlX5HxYf/aeOyDC9KEogz4bZ9PF8Tx0asuyLVXzXCvjIDeUzyfW8puL 4QXf6Pktx4gM/8MP2zaMctBEkW/fc4Xo4+O1Xb8w4aMlhgMcG8Gy36i/DtJq3RPUwdWB8P yU5301+SX8IOrLQOm3Jkyq8qWz9mj9k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-284-ZkUzEKOJPZ-_fMl2pDh-tw-1; Mon, 04 Jan 2021 10:40:19 -0500 X-MC-Unique: ZkUzEKOJPZ-_fMl2pDh-tw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A13B81800D41; Mon, 4 Jan 2021 15:40:16 +0000 (UTC) Received: from horse.redhat.com (ovpn-115-2.rdu2.redhat.com [10.10.115.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id 336E8271AB; Mon, 4 Jan 2021 15:40:16 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id A3AF1220BCF; Mon, 4 Jan 2021 10:40:15 -0500 (EST) Date: Mon, 4 Jan 2021 10:40:15 -0500 From: Vivek Goyal To: Amir Goldstein Cc: Matthew Wilcox , Sargun Dhillon , linux-fsdevel , linux-kernel , overlayfs , Jeff Layton , Miklos Szeredi , Jan Kara , NeilBrown , Al Viro , Christoph Hellwig , Chengguang Xu Subject: Re: [PATCH 3/3] overlayfs: Report writeback errors on upper Message-ID: <20210104154015.GA73873@redhat.com> References: <20201221195055.35295-4-vgoyal@redhat.com> <20201223182026.GA9935@ircssh-2.c.rugged-nimbus-611.internal> <20201223185044.GQ874@casper.infradead.org> <20201223192940.GA11012@ircssh-2.c.rugged-nimbus-611.internal> <20201223200746.GR874@casper.infradead.org> <20201223202140.GB11012@ircssh-2.c.rugged-nimbus-611.internal> <20201223204428.GS874@casper.infradead.org> <20210104151424.GA63879@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 04, 2021 at 05:22:07PM +0200, Amir Goldstein wrote: > > > Since Jeff's patch is minimal, I think that it should be the fix applied > > > first and proposed for stable (with adaptations for non-volatile overlay). > > > > Does stable fix has to be same as mainline fix. IOW, I think atleast in > > mainline we should first fix it the right way and then think how to fix > > it for stable. If fixes taken in mainline are not realistic for stable, > > can we push a different small fix just for stable? > > We can do a lot of things. > But if we are able to create a series with minimal (and most critical) fixes > followed by other fixes, it would be easier for everyone involved. I am not sure this is really critical. writeback error reporting for overlayfs are broken since the beginning for regular mounts. There is no notion of these errors being reported to user space. If that did not create a major issue, then why suddenly volatile mounts make it a critical issue. To me we should fix the issue properly which is easy to maintain down the line and then worry about doing a stable fix if need be. > > > > > IOW, because we have to push a fix in stable, should not determine > > what should be problem solution for mainline, IMHO. > > > > I find in this case there is a correlation between the simplest fix and the > most relevant fix for stable. > > > The porblem I have with Jeff's fix is that its only works for volatile > > mounts. While I prefer a solution where syncfs() is fixed both for > > volatile as well as non-volatile mount and then there is less confusion. > > > > I proposed a variation on Jeff's patch that covers both cases. > Sargun is going to work on it. What's the problem with my patches which fixes syncfs() error reporting for overlayfs both for volatile and non-volatile mount? Thanks Vivek