Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp36799pxf; Wed, 24 Mar 2021 20:10:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwowe3j3NrrbAXPi8oPpzF9le+nnaYoE2Z4oaUqbW7yv6AhTwBiOUTCWxtOtOSfrh0HBQvw X-Received: by 2002:aa7:c1d8:: with SMTP id d24mr6637601edp.290.1616641816009; Wed, 24 Mar 2021 20:10:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616641816; cv=none; d=google.com; s=arc-20160816; b=V28fgqE3a0qd5kjbSAdISgr8aVrZTkfTvrk8EpDHhCjn7ZrpsKhbOaeKQ09rYdHSJG P4SRbA3paWSecRjALKhRRdcEVFrEuLP1CTeztK9dRhDH+FMLOfT2FH1/fLejiDREfK3R bbznTr76TeCiPDm35QjTMM7hLSETCGKhvYgyA0O7FAYUT4qXCxexoG0HK8ab0v+uU6sD QyDDIyTScCRKOzzGqSWMGLhpECL8fFWzHm9wVBGHldNavI2kOPAQKeBBxdavcCwjUmJ2 L0s19193AFCZ0bXTi5kXl5Gvwk9r6fP7d/6TA7tEFLfKHchWbDigA/kH+Ulx4O9xaant GZOQ== 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=9Srn0HCzRuEqmBIHGKCIDIj1QJnrtcGxEweWmfp41Hk=; b=m9Bz+CBmE8OjP1bLAoaTqEmxPj1iRrXekL+1eKqfksh66LXC44VTIyFGT5ULRG8wRX NiSonHZoR/r5PA2XLku3SR73VAqStLY/FCXojuNh+R5DqKKDwLgxhEd0bDxYz4/IrF8I MfDH6VLKCwlHZGs+M+ol5X5FIViYgXdS9OQvYYKRZpfXG/uyAPaeGaTd7Rz7uhFOBVfZ LvkAWw/qWMMRv5yEZjb4gf0SVDaQsO7viY6ebqZzIR9oss273xGroGFGEuCaRXEUbJkD HhjEMV0M3ZPxyyzL4euFNben2Cb7VkuVijMu/zi4CgSPnyBN1pJxv2YG/birbrwG2SCk FE2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b="blJB3/bF"; 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=REJECT sp=REJECT dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pk25si3294194ejb.402.2021.03.24.20.09.52; Wed, 24 Mar 2021 20:10:15 -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=pass header.i=@android.com header.s=20161025 header.b="blJB3/bF"; 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=REJECT sp=REJECT dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235897AbhCXOCq (ORCPT + 99 others); Wed, 24 Mar 2021 10:02:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235859AbhCXOCa (ORCPT ); Wed, 24 Mar 2021 10:02:30 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1750AC0613DE for ; Wed, 24 Mar 2021 07:02:30 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id 14so1343675wrz.12 for ; Wed, 24 Mar 2021 07:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=9Srn0HCzRuEqmBIHGKCIDIj1QJnrtcGxEweWmfp41Hk=; b=blJB3/bFvQgdsZFjA+/2zACn4ORPdcyIG+PyUh7o/pVWFmLyVnFIRI0DJxPPn3na3g inpIOlx9DPXatv/jjh7lLKY/A2zld01pxkuerRfrZexXJsma2InqZjZL6YVamwojcRAb ua/kXomby2Ter8CUenDlr7Imi9TUivVVp3AcbN2yIDi4sGya76j/l2u800HBGEnUW9E1 zIT3G5XkaT7Ir/8h7xHZ4levDa2Jym3IyRCiBSKR8cLWFLGGbAPwGAmbMpEZBzHZg76u nsmafsfP1hdOBT9U8iQaHt9XtmplU5xBcglj2JwAmNAw7qRdJToR8NEBMayYrsvIxUhN pogw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9Srn0HCzRuEqmBIHGKCIDIj1QJnrtcGxEweWmfp41Hk=; b=KclrYeQMY1OhFuCqXzN/U0Y9eASkJ8THQ/74k9wZ+CFyO5ixw8V3Ztf/RgTjfepGAW dOU53i+bRQkdpYA3qSIlBBwVXC1CYVuai0hQIGyCLsXYKKIsuhdV/bCjG+Cba5rB+JhQ KXh72HIVtOqYGLLHgMN2GkcVO1NhxVRJ2kUYo3bIsnXBTaah0UoZeXTWBOsik2WpuZ1N 2z4Fpg1u1/mHGGwpIioYRXdbzsO0UFCC1fi0jrU029jwiEBmcWh3YVofURFO4lARzwdD A/xxbZA6AhG6gj/4B72ODicijGarT8IfY8W+4YporDhSQUlO1DxhfoveUtGjp/co2oKg +chQ== X-Gm-Message-State: AOAM533kulXkE4An0thrrWMaJpnGmKfoo1j6v2caZhiYtJRfNYzvdj5y h2jv4QxCUhx2vHp5VNL2t2wHtw== X-Received: by 2002:adf:e508:: with SMTP id j8mr3686199wrm.141.1616594548397; Wed, 24 Mar 2021 07:02:28 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:e547:d6b6:59e3:4a81]) by smtp.gmail.com with ESMTPSA id b17sm3358310wrt.17.2021.03.24.07.02.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Mar 2021 07:02:27 -0700 (PDT) Date: Wed, 24 Mar 2021 14:02:26 +0000 From: Alessio Balsini To: Rokudo Yan Cc: Alessio Balsini , Miklos Szeredi , Akilesh Kailash , Amir Goldstein , Antonio SJ Musumeci , David Anderson , Giuseppe Scrivano , Jann Horn , Jens Axboe , Martijn Coenen , Palmer Dabbelt , Paul Lawrence , Peng Tao , Stefano Duo , Zimuzo Ezeozue , fuse-devel@lists.sourceforge.net, kernel-team@android.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND V12 1/8] fs: Generic function to convert iocb to rw flags Message-ID: References: <24bb27b5804fb64238f2f9c1f3c860d5@sslemail.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 24, 2021 at 03:43:12PM +0800, Rokudo Yan wrote: > On 1/26/21 12:46 AM, Alessio Balsini wrote: > > On Mon, Jan 25, 2021 at 03:30:50PM +0000, Alessio Balsini wrote: > > > OverlayFS implements its own function to translate iocb flags into rw > > > flags, so that they can be passed into another vfs call. > > > With commit ce71bfea207b4 ("fs: align IOCB_* flags with RWF_* flags") > > > Jens created a 1:1 matching between the iocb flags and rw flags, > > > simplifying the conversion. > > > > > > Reduce the OverlayFS code by making the flag conversion function generic > > > and reusable. > > > > > > Signed-off-by: Alessio Balsini > > > --- > > > fs/overlayfs/file.c | 23 +++++------------------ > > > include/linux/fs.h | 5 +++++ > > > 2 files changed, 10 insertions(+), 18 deletions(-) > > > > > > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > > > index bd9dd38347ae..56be2ffc5a14 100644 > > > --- a/fs/overlayfs/file.c > > > +++ b/fs/overlayfs/file.c > > > @@ -15,6 +15,8 @@ > > > #include > > > #include "overlayfs.h" > > > +#define OVL_IOCB_MASK (IOCB_DSYNC | IOCB_HIPRI | IOCB_NOWAIT | IOCB_SYNC) > > > + > > > struct ovl_aio_req { > > > struct kiocb iocb; > > > struct kiocb *orig_iocb; > > > @@ -236,22 +238,6 @@ static void ovl_file_accessed(struct file *file) > > > touch_atime(&file->f_path); > > > } > > > -static rwf_t ovl_iocb_to_rwf(int ifl) > > > -{ > > > - rwf_t flags = 0; > > > - > > > - if (ifl & IOCB_NOWAIT) > > > - flags |= RWF_NOWAIT; > > > - if (ifl & IOCB_HIPRI) > > > - flags |= RWF_HIPRI; > > > - if (ifl & IOCB_DSYNC) > > > - flags |= RWF_DSYNC; > > > - if (ifl & IOCB_SYNC) > > > - flags |= RWF_SYNC; > > > - > > > - return flags; > > > -} > > > - > > > static void ovl_aio_cleanup_handler(struct ovl_aio_req *aio_req) > > > { > > > struct kiocb *iocb = &aio_req->iocb; > > > @@ -299,7 +285,8 @@ static ssize_t ovl_read_iter(struct kiocb *iocb, struct iov_iter *iter) > > > old_cred = ovl_override_creds(file_inode(file)->i_sb); > > > if (is_sync_kiocb(iocb)) { > > > ret = vfs_iter_read(real.file, iter, &iocb->ki_pos, > > > - ovl_iocb_to_rwf(iocb->ki_flags)); > > > + iocb_to_rw_flags(iocb->ki_flags, > > > + OVL_IOCB_MASK)); > > > } else { > > > struct ovl_aio_req *aio_req; > > > @@ -356,7 +343,7 @@ static ssize_t ovl_write_iter(struct kiocb *iocb, struct iov_iter *iter) > > > if (is_sync_kiocb(iocb)) { > > > file_start_write(real.file); > > > ret = vfs_iter_write(real.file, iter, &iocb->ki_pos, > > > - ovl_iocb_to_rwf(ifl)); > > > + iocb_to_rw_flags(ifl, OVL_IOCB_MASK)); > > > file_end_write(real.file); > > > /* Update size */ > > > ovl_copyattr(ovl_inode_real(inode), inode); > > > diff --git a/include/linux/fs.h b/include/linux/fs.h > > > index fd47deea7c17..647c35423545 100644 > > > --- a/include/linux/fs.h > > > +++ b/include/linux/fs.h > > > @@ -3275,6 +3275,11 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags) > > > return 0; > > > } > > > +static inline rwf_t iocb_to_rw_flags(int ifl, int iocb_mask) > > > +{ > > > + return ifl & iocb_mask; > > > +} > > > + > > > static inline ino_t parent_ino(struct dentry *dentry) > > > { > > > ino_t res; > > > -- > > > 2.30.0.280.ga3ce27912f-goog > > > > > > > For some reason lkml.org and lore.kernel.org are not showing this change > > as part of the thread. > > Let's see if replying to the email fixes the indexing. > > > > Regards, > > Alessio > > > > Hi, Alessio > > This change imply IOCB_* and RWF_* flags are properly aligned, which is not > true for kernel version 5.4/4.19/4.14. As the patch ("fs: align IOCB_* flags > with RWF_* flags") is not back-ported to these stable kernel branches. The > issue was found when applying these patches > to kernel-5.4(files open with passthrough enabled can't do append write). I > think the issue exists in AOSP common kernel too. > Could you please fix this? > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce71bfea207b4d7c21d36f24ec37618ffcea1da8 > > https://android-review.googlesource.com/c/kernel/common/+/1556243 > > Thanks > yanwu Hi yanwu, Correct, this change depends on commit ce71bfea207b ("fs: align IOCB_* flags with RWF_* flags"), and this dependency is satisfied upstream. Being FUSE passthrough a new feature and not a bugfix, I'm not planning to do any backporting to LTS kernels (and GregKH won't probably accept it). Android is a different story (and slightly out of topic here). We are looking forward to have FUSE passthrough enabled on Android as most of the user data is handled by FUSE. We liked the performance improvements and non-intrusiveness of the change both for the kernel and for userspace, so we started supporting this in android12-5.4+ kernel branches. We are not planning to maintain the feature to older kernels though (we can't add features to already released), and this is why FUSE passthrough is not merged there. To answer your question, in AOSP the officially supported kernels already have the flags alignment change merged, and a not supported backporting to older kernels (i.e., 4.14 and 4.19) is already available: https://android-review.googlesource.com/q/%2522BACKPORT:+fs:+align+IOCB_*+flags+with+RWF_*+flags%2522+-status:abandoned Thanks, Alessio