Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1685491pxb; Thu, 7 Oct 2021 12:52:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYxy3QmYZpe4NM81RgGZ8RZH9rTawXU0K5LkBn6CfAChJz4d0QMhUEuKMZWs/K1WdsVyTk X-Received: by 2002:a05:6a00:1748:b0:44c:ca52:b261 with SMTP id j8-20020a056a00174800b0044cca52b261mr3628750pfc.17.1633636350184; Thu, 07 Oct 2021 12:52:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633636350; cv=none; d=google.com; s=arc-20160816; b=daNub3ZdxP3o1O162UH0SDVNCNXQLYkjDDNi4Ng1RlhrFfwYNS+LepSVa08kUlP7wG MDIth1C0/v6j6KFwPm3PnFfm6xpK6jHcSgkZ4NXGvHU2nKSSRTgV5/+TmNOjBX+BMWcD eK/cCa1mhjP1/Hs8Yh1rTbar2cPLkk/8gtpxT83RgogDX7j5kV5icpKDhe4Sfd5FCgU1 8Nl3LrAzrNdoZlsdG1rooE0tP3OW+v4FXzC1oq7+Ctl+oM0B84BrjM0DwcFdPyYzKII1 gtIyOASRMGLXtXwwIi3D31nwY5VdrA5KFDKvrFM269XfIEohFFTE2y2FOn42HJK2M8nW imMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=IpVV/iS/slfiNLSYszxf18SrC9/xTM7dslxkNEPwfTI=; b=reqEze4pGowhwz//04ZK9FEbs7yAM5Q3EjOs7IcOHBzhwza60ZFjuABwGrwTf9nkFH U1TFC3v8zdC5D2Rcqn6oEOUUqNcqWuDL+O7J/NPt0cF5f4clNqaKZHNW8rV9U10C4IUR EWxnoxKynPIut7GWHDyHYkZMEJKjIRMqz7tYFaW8yg5/5ZnJ5PRv486BjAb1I7mqgR60 oHLJaTEnTwT1imJeVCFQ/tRyHN4AnBZyHARXT4zvYXOPZdyWE1m5bJImbUogtDD4rDVb 96YRIWvR9KTPMNF6xO41O4UxQ5smCCQExQjPMViqoNOEc+Saqg2HQiHfaEpAyfSZrF5b LHjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=pp9QUGn1; 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 q2si17697818pfj.127.2021.10.07.12.52.17; Thu, 07 Oct 2021 12:52:30 -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; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=pp9QUGn1; 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 S243811AbhJGSxx (ORCPT + 99 others); Thu, 7 Oct 2021 14:53:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233866AbhJGSxx (ORCPT ); Thu, 7 Oct 2021 14:53:53 -0400 Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DE09C061755 for ; Thu, 7 Oct 2021 11:51:59 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id d18so7879712vsh.1 for ; Thu, 07 Oct 2021 11:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IpVV/iS/slfiNLSYszxf18SrC9/xTM7dslxkNEPwfTI=; b=pp9QUGn1eEBn3Igh3E0wg9uT0yoMtbtkUl5FSHZp2vad6jTD1p3Txoy0dnuAS17+Ob V+NVa5snrCfTZFfiHA1K7laFRTbGlJTTKEK3Ti3voS4/Ol2eQj8DzR1Kq9G361kvPwRM J7U4Cos3yEM6/U7XJUNg+2vDgAT7p99VTd0I8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IpVV/iS/slfiNLSYszxf18SrC9/xTM7dslxkNEPwfTI=; b=1jPBDCyqdaoyrS7zd7Ce9lKE54rf5R+cJ8v/aBB86E0KVMAHtSnfeWbHGt+8cNcs5X 9aZF0bdUCKhhXsjpwcCG2ifqKK/ptaOTQDyo9RtoucDXJmSTZ2tStiPiuSABmgA8PbRW 4/MiEkzwc+KjRVAEklhXBVqrG0nBb+VYjhEsX7hNJtSRcLH1Xsz22oGddcpJUl2XzdMC yEh5LsE9mqN+P6zfAyxvApc34sYdPSbKpnlEle84xjneWsRSUAkBhltvkG4zJXrbIe7C iF3L9rXaTZzs5SeNcFjAxIPBNjkQA/UpzFvbX1X4W22N/mXzcKKqKfwFbaYkrs2n5a6R gqCA== X-Gm-Message-State: AOAM532h7xv6gmQkop5OEhQlr+VTxJ/MhFGQB+eLprb6AbGWA7mngFP6 frR6AZ1Gh8HxFFvHo4ibwC60e21KhHmUhe/LeMPfXA== X-Received: by 2002:a05:6102:3c3:: with SMTP id n3mr6474901vsq.19.1633632718216; Thu, 07 Oct 2021 11:51:58 -0700 (PDT) MIME-Version: 1.0 References: <20210923130814.140814-1-cgxu519@mykernel.net> <20210923130814.140814-7-cgxu519@mykernel.net> <17c5aba1fef.c5c03d5825886.6577730832510234905@mykernel.net> <17c5adfe5ea.12f1be94625921.4478415437452327206@mykernel.net> <20211007144646.GL12712@quack2.suse.cz> <17c5b3e4f2b.113dc38cd26071.2800661599712778589@mykernel.net> In-Reply-To: <17c5b3e4f2b.113dc38cd26071.2800661599712778589@mykernel.net> From: Miklos Szeredi Date: Thu, 7 Oct 2021 20:51:47 +0200 Message-ID: Subject: Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation To: Chengguang Xu Cc: Jan Kara , Amir Goldstein , linux-fsdevel , overlayfs , linux-kernel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Oct 2021 at 16:53, Chengguang Xu wrote: > > ---- =E5=9C=A8 =E6=98=9F=E6=9C=9F=E5=9B=9B, 2021-10-07 22:46:46 Jan Kara= =E6=92=B0=E5=86=99 ---- > > On Thu 07-10-21 15:34:19, Miklos Szeredi wrote: > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu wr= ote: > > > > > However that wasn't what I was asking about. AFAICS ->write_in= ode() > > > > > won't start write back for dirty pages. Maybe I'm missing som= ething, > > > > > but there it looks as if nothing will actually trigger writebac= k for > > > > > dirty pages in upper inode. > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overl= ayfs ->writepages and > > > > overlayfs' ->writepages will be called by vfs writeback function (= i.e writeback_sb_inodes). > > > > > > Right. > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > You could but then you'd have to make sure you have I_DIRTY_SYNC alway= s set > > when I_DIRTY_PAGES is set on the upper inode so that your ->write_inod= e() > > callback gets called. Overall I agree the logic would be probably simp= ler. > > > And it's not just for simplicity. The I_SYNC logic in writeback_single_inode() is actually necessary to prevent races between instances on a specific inode. I.e. if inode writeback is started by background wb then syncfs needs to synchronize with that otherwise it will miss the inode, or worse, mess things up by calling ->write_inode() multiple times in parallel. So going throught writeback_single_inode() is actually a must AFAICS. Thanks, Miklos