From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6258AE7717D for ; Wed, 11 Dec 2024 09:44:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E40E98D0015; Wed, 11 Dec 2024 04:44:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DC5EB8D0013; Wed, 11 Dec 2024 04:44:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1A888D0015; Wed, 11 Dec 2024 04:44:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 9EB778D0013 for ; Wed, 11 Dec 2024 04:44:02 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3060C1407DA for ; Wed, 11 Dec 2024 09:44:02 +0000 (UTC) X-FDA: 82882191462.16.D95BE0C Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf04.hostedemail.com (Postfix) with ESMTP id 0315D40007 for ; Wed, 11 Dec 2024 09:43:35 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZWWoxuFo; spf=pass (imf04.hostedemail.com: domain of amir73il@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733910230; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=k0J1AWg+bzB1T7PXoJrhM6/zrY07tqFzRe4i5kAQBdA=; b=OAYfbEQBtQjauAS0kwjtQV9Pd7G3ehhsX1HpItqSqmfPVMgmIvvLd0bS/Xf9zZq5P4NGrW xWeoclsnqvmUJsS6/chi+ms/KDfHlnoNz3lvHgCisSjFC5ExP6QYzLI/6dRXVC3MjhFA5L IeOIhlTvUAnRknTpQ8wPZkB0k3ekSP8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ZWWoxuFo; spf=pass (imf04.hostedemail.com: domain of amir73il@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733910230; a=rsa-sha256; cv=none; b=EvzYtFDrj82eg+ha9hxHyDBZhvsjQq0jls/QZLSet6TnmBdUrnXQatDKIYvWZfmxwvElST B8rwY3DZv/bjyD9dTF4rA5jfs40lrqwyoIAV99Upa5yGZXFYh6dYhYGjyrIGyiOQa9Esa7 54zikRRAVu+badX8sw/cwAaGglCAk68= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5cec9609303so7791272a12.1 for ; Wed, 11 Dec 2024 01:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733910239; x=1734515039; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=k0J1AWg+bzB1T7PXoJrhM6/zrY07tqFzRe4i5kAQBdA=; b=ZWWoxuFoBJeJn1KYip9gATOb4SBJb+ka722sxVo8SzYSHSZwXEDk4syXTFSbtVToQP gVNPYfmvwDdooxBx17Gzs7VGJAtZRYhZOIJ1OY63jpPGP1yuL05xUYcGALEgHOTVStse eMiz2o2PNehq8irmMnwMNQqInw4pgRpHQyH3B1f5wRHq6IMPS/qUKnuz52SAplco4+D7 vlE71KcLXKkyP01J1kk+29TsCKe49rDjjTUoztV20+KP2m1xv96JVFidYPWfkzQ2zpIK qbGecDCWNHrEDMbx9tY6sIBlQMuWUcmTjF82F/dBqa8+KBxyLWtC3KuDh1ZLBX8axknq 7nsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733910239; x=1734515039; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k0J1AWg+bzB1T7PXoJrhM6/zrY07tqFzRe4i5kAQBdA=; b=YjtcyFrlt2YLcfsofuFUT08BcocQa0rbZLbxpDB2M1pcrPr6CJajMX8dWIRpPLi8fc /V0wzQJhgtOmaVRwzKIo5+9eRDI+JeptMj2DnRtZuJeKmMBhVuy3+ZPR57A0uDeiZNQe No/OFAm+EAXH6OpssCQs15uehzNLc2IgbHRYXHmOvk2NpJY3kSy+vHm9w06uTh0ZCJfS xHBRj8weU3njYmV+Tf5/NQpOzkyL8yup/dDo1RlC8NoM5DS9ayAo23uPJYdNQUBQzBtG aQcabLq3TXZb4kGL5leJxerLNIagNCba/ZLT1CGDPcLcH331nGD2dIOdpB4pr9FCl986 VeaA== X-Forwarded-Encrypted: i=1; AJvYcCUkNKVErDk1avR8KXyEfhvXxayEbImq62RaBE+1SoDC0VoPpFnkKdBmd2iH9KPEjs0vVyYlTp6PMA==@kvack.org X-Gm-Message-State: AOJu0Ywn+F0CCJGZEfgdgQyeKrYtmbwqOQyJiGXGrnvGXj5hmWDzdzN2 s4Ma3/QZqDZmqyHneZaHDs06awhSvsfCLkHQNS773gTBbzMutu8BQYdTvtANnfs7c+6440QQc/2 nQmKXYwT2lRLa8KIwr0xNJXCY42s= X-Gm-Gg: ASbGncuXtQ7/vJx00b6n31ysAYrjxvaM1AQjLHxAF5hC+f7FJ++4VibR8scRm75uS5j zfSMouuBelL5c5wveSbHEwK00Xa3SYOKODlI= X-Google-Smtp-Source: AGHT+IECwjvvXTCm18ZNhzpNsVfvMgAYb0Igg1GaZbhBstEzIex/MmnE2qw17IwrVw7WFaTAWc2QyexN13LFArF2wy0= X-Received: by 2002:a05:6402:234f:b0:5d2:7346:3ecb with SMTP id 4fb4d7f45d1cf-5d433081e4amr1775865a12.12.1733910238320; Wed, 11 Dec 2024 01:43:58 -0800 (PST) MIME-Version: 1.0 References: <20241205143038.3260233-1-tujinjiang@huawei.com> <69b72e3d-b101-4641-9ce5-51346c93a98d@lucifer.local> <041dcc1a-0630-27b9-661b-8c64a3775426@huawei.com> <568698a0-c2f2-45d8-9d8b-e22e942fa422@huawei.com> In-Reply-To: <568698a0-c2f2-45d8-9d8b-e22e942fa422@huawei.com> From: Amir Goldstein Date: Wed, 11 Dec 2024 10:43:46 +0100 Message-ID: Subject: Re: [PATCH -next] ovl: respect underlying filesystem's get_unmapped_area() To: Kefeng Wang Cc: Lorenzo Stoakes , Jinjiang Tu , miklos@szeredi.hu, akpm@linux-foundation.org, vbabka@suse.cz, jannh@google.com, linux-mm@kvack.org, linux-unionfs@vger.kernel.org, sunnanyong@huawei.com, yi.zhang@huawei.com, Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 0315D40007 X-Stat-Signature: 7smsesw1i3ht4xgf1dktwy9rroqs7yzt X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1733910215-455001 X-HE-Meta: U2FsdGVkX18T7Ux7pxm2tg42qBawUgt4/xEvka+2vqxZGXz7Gr9ZlPxhMfF2/V9LpAitYOjTqQIcX6B4mb7q6ubRITxHcLZWXfWf+0nMgOExlaHCyoSkUdObHrnARfGNHsS7gPr2/1jbCXZtaRkYO/6zi/ZIxrpR0sPAWZAHciiZOGymiImmilYZ1EdilMDz8JQva21FtN1H5UbAtielO0YrazRSADykcBjWNvpWcrlbbgqEpWB94DhRAN1N1uNR3j/84AY5cA/HpXCdwR7+9YE8jGxCgaMzt8GBmdHs07Sc0cuFyic+fsccIojvlYWN5OepZt8HJ4HPe/RSBf+eu3VoDyEOY1wI8EFcoteEAO5N0twCsFq/hjqu9IigFXAKPfzjKjrbqSR7zNG6+IpXVNUQMDBL5MdPYtTa0N1O8+z0Iq+Fz0eLsV2C2+y/zW8yLvNN+VMgOvVrpodb+XhhWHh30a6EbTUqksBN17oDIRYpu6m5qVFJus1wM3OlgOmdanrH9Br+11V/ykSgq2LbcQsl9/puET1dzfFocqEtz/xYdyqiCQBFUKuLtXil2ufrwleCZ/xRnyGbctlPvcfB5kYCEFMUMyk5RhRizABe/YGLEKz/1u20Y4QbUTMtjsMYQEamCyJet5FwdMmsFlfA9QRMLEvIAu3rg+FqtbbS7EUTpkRAXkYIqWnTRne/oYTl1y9DDIP0Fxd83ezPkaVJuLvmEIPzyaP3gJRc7q9lBA1loOHebAaeU8k2OzlefoYk+v7UsXcInS4hWvW3ueGOue8FO5FWAw3LX5h5mMBBJX4+IG1UGS9e71RdHmYNlewmKB5tW0Qe+PMgazV7pT9rppEEt8zcyvjckexzH1q0c11ru5h7r4/77QWpoYhH8Gao6ft2f1LIaHiCSXAGr0OwP84Dzjs713aHBZmbVrHfQBvEAz8eKXi9gVSKbh06buX1sRTwMBW7+VYlzKfc6o9 1qnQ+6Jy IqbwoppZcZK/XN8ZA7wA9Vk8gcr8PKnmB+CTSe/CHnxYsM6rJ8RUJSsBdE8/ucMXolveLqJ0EeL8sU97CDxj+Fn+jCRoz0r2n/KYOIxsXalwXky+d9mglcFvf9rZgQqgkO/JCBrRAz1LpW8iHbUwpsg/MQcZ6urGEceBJ78v5HNfu/IQDiLCidpjb6GGo73e63/D1F2ShRyCs+Swt8Hc2oks5/M2hXFm12b3AMNDMKV/BMD8gOJAzlY+MFMyzh1Bj+Qqsfh4/JAABvywiqvDZ4MkM9x9Ao8jOzVey6T575M3o4mxhdbZSEfZXuvrg6BGL8PKyN6d+fxbtAdjJCBI0iMREa/FSgMM19shI3ia7YruaQUB+GDXalH/wfbrjadavzkK2900X+XS4QqeNmBBOn35bfgFMDHN35KcACLvf9+3CxJ68t6vvXEbhaiersIVirITm52zCG2VuHEY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.088175, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Dec 10, 2024 at 8:19=E2=80=AFAM Kefeng Wang wrote: > > > > On 2024/12/6 20:58, Amir Goldstein wrote: > > On Fri, Dec 6, 2024 at 11:45=E2=80=AFAM Kefeng Wang wrote: > >> > ... > >> > >> So maybe use mm_get_unmapped_area() instead of __get_unmapped_area(), > >> something like below, > >> > >> +static unsigned long ovl_get_unmapped_area(struct file *file, > >> + unsigned long addr, unsigned long len, unsigned long p= goff, > >> + unsigned long flags) > >> +{ > >> + struct file *realfile; > >> + const struct cred *old_cred; > >> + > >> + realfile =3D ovl_real_file(file); > >> + if (IS_ERR(realfile)) > >> + return PTR_ERR(realfile); > >> + > >> + if (realfile->f_op->get_unmapped_area) { > >> + unsigned long ret; > >> + > >> + old_cred =3D ovl_override_creds(file_inode(file)->i_sb= ); > >> + ret =3D realfile->f_op->get_unmapped_area(realfile, ad= dr, len, > >> + pgoff, flags); > >> + ovl_revert_creds(old_cred); > >> + > >> + if (ret) > >> + return ret; > >> + } > >> + > >> + return mm_get_unmapped_area(current->mm, file, addr, len, pgof= f, > >> flags); > >> +} > >> > >> Correct me If I'm wrong. > >> > > > > You just need to be aware of the fact that between ovl_get_unmapped_are= a() > > and ovl_mmap(), ovl_real_file(file) could change from the lower file, t= o the > > upper file due to another operation that initiated copy-up. > > Not sure about this part(I have very little knowledge of ovl), do you > mean that we could not use ovl_real_file()? The ovl_mmap() using > realfile =3D file->private_data, we may use similar way in > ovl_get_unmapped_area(). but I may have misunderstood. > First of all, you may add to your patch: Acked-by: Amir Goldstein I think this patch is fine as is. w.r.t. question about ovl_override_creds(), I think it is good practice to user mounter credentials when calling into real fs methods, regardless of the fact that in most cases known today the ->get_unmapped_area() methods do not check credentials. My comment was referring to the fact that ovl_real_file(file), when called two subsequent times in a row (once from ovl_get_unmapped_area() and then again from ovl_mmap()) may not return the same realfile. This is because during the lifetime of an overlayfs file/inode, its realino= de/ realfile can change once, in the event known as "copy-up", so you may start by calling ovl_get_unmapped_area() on a lower ext4 realfile and then = end up actually mapping an upper tmpfs realfile, because someone has opened the overlayfs file for write in the meanwhile. I guess in this corner case, the alignment may be wrong, or just too strict= for the actual mapping, but it is not critical, so just FYI. There are worse issues with mmap of overlayfs file documented in: https://docs.kernel.org/filesystems/overlayfs.html#non-standard-behavior "If a file residing on a lower layer is opened for read-only and then memory mapped with MAP_SHARED, then subsequent changes to the file are not reflected in = the memory mapping." Thanks, Amir.