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 D2B67E7717D for ; Wed, 11 Dec 2024 15:02:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51C806B0093; Wed, 11 Dec 2024 10:02:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CC0B6B0095; Wed, 11 Dec 2024 10:02:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 394796B0098; Wed, 11 Dec 2024 10:02:04 -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 19B916B0093 for ; Wed, 11 Dec 2024 10:02:04 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9730CA11DD for ; Wed, 11 Dec 2024 15:02:03 +0000 (UTC) X-FDA: 82882992822.05.D289289 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf29.hostedemail.com (Postfix) with ESMTP id 45C3D120053 for ; Wed, 11 Dec 2024 15:01:22 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733929292; 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; bh=AQoaZfYapp+37nIXT/J/UjkojBs6FiSi4OaKItTJOIE=; b=iOu8NvoFk3vEv3NBERpANmvAs7p1wUQ0imrAN4M6dYbfb6dlwgzC+nujr5LdNIAkgJwUg8 I59e5GvpoCLZLORT1S0UNtGGv511PzlP8d4S18cVo6n/C3Swf6wx5x5EaNyGy14Y3XphOC uWlD7iZerLUaluXMpU2h3JO0KooptYs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733929292; a=rsa-sha256; cv=none; b=asIAOAxyijTmBMd1ddir9wsiCsm8IG/F9i4dpjH5gkggLMiw7ujLIDFeQuYN/j58Khra3z S0k577mIfG1VTaoaFg9i8NCsNQT4/NZJWAnwnW2XHnVdolRaGK4faWM/023qXVatMS6uIU 7wkw/x2E1pOEjJFOND+SnbcFCcGBJGM= Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Y7dz54TT6zHwtG; Wed, 11 Dec 2024 22:58:57 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id C7E061401F4; Wed, 11 Dec 2024 23:01:50 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 11 Dec 2024 23:01:50 +0800 Message-ID: <88a1f4e4-8c3a-447c-a207-df754f1ab67d@huawei.com> Date: Wed, 11 Dec 2024 23:01:49 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next] ovl: respect underlying filesystem's get_unmapped_area() To: Amir Goldstein CC: Lorenzo Stoakes , Jinjiang Tu , , , , , , , , , Matthew Wilcox 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> Content-Language: en-US From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 45C3D120053 X-Rspam-User: X-Stat-Signature: cmwgge4on1a3qd1h3ntzn1jxq8pidfcj X-HE-Tag: 1733929282-881066 X-HE-Meta: U2FsdGVkX1/PdNWpXFlO0TO6YcMDweOGAngJVPXfV4w6X+6vpg8yvRQnW44aPlS0R23NPcbDiKCWUP8tzCmoQsSTgZNo2W2fGY2Yq8qJ78CF1Nq9q1VwCQAgb/BQiOamHs2LE3AXbRtftMdY61GlxSYG3aq4qdvnMEMe+a/peAkroWeHaubgpHXe9LqNxynKIdpUEEeC05O4zDK4CsmeXMclrisTHr8f1hcLbmjpp6Qf8PDX0/blXoXePJQE8R2v5F56FA8BsO6zqKCSW5Qieg8581H+oIIDj07ePydFsPQYDS8JvhAkZnnRZ5kvLCLrFpmluQoIdpO/0Jy4dxdAKPG6aIidm4fubhdU2plVfu8lI84ySe45/BWkcpBdTtWGD/UYmFp7QJAmMycsOSymOoTcf/pJ7vSVi2Chm14v7wI6kqCKNx03mT5efpaQKCdpHRoD/gk0WYBctfK7XunAHrUXTnoYPY7/HpQI+O1OpZWDpOMSwzQqKZEoklKTiJutHKrzI7BQSsEnvVEgPkDSYVcJvYJL+OtxKPf/SI1t/kUkuz3fWiDiImHndavyGSBrAOrQA/LoGlxi1epB8V3kP0RIarSvCvaMSSEJG+xrtguza/GI/MNR96IKnKzDMpjdMpwjF5SMH1CCagVUVfUZbodrLGnlTUYpGGqxsHAsJKU7Q95YJ6aiobQ89gVzce2mR+Ex7hqoJ7mg5WlDYqTfvq1W7XUVAQKV0Oh09C7WhgNn5Uun80unEQTpGxWS3P5nxhA9v76c80JFflPV8ckSmLsRyEDA4ZgNUuY712VW4sMjEj/Hkgnn/zUXnJT1EMicyO2fKvdIme82rKsXZfZiDGNECKjpNDGeHQXm4QY+mLbrpC69ho/ULAdMiBrSgs3kORK4K8W3wcpo3BMuONTMRthtcjLj7LHYisGia6G+hBve9T+qCxL3q+vYC4FjazImDJi9Gt+fj4Pvm4uhqdv npmZhlGp UU+qhXr4MzT4XX4yxGgZYEupqi0PLK+LFDO5HJqZqu2RIcjKvmyMyw/MrOR5U26NJ9GZa0KeBNnj8ZfZ+4gO3ooIa+S2MG/sy4b8sjlHX1xKkASoaXPLICZl+7HCFXKfq1opcsMxsLzJn457I8KFAy0LpjiRvFc44WaM4fO3j/l9ZKmgUpJcBD6Mg41BKmE+BIYU1PDVM2EmAJV75+boKAgQ2Y9nf4xybCAr3WBg2jBtEO0/B1aNkPSwna07z1lE80it+cS+YTuogcMh0SDaKhMGTSuRau4dSIfcLa+fik2YbC9W+aiV6x3NQ+yQS/8QjdhtYqgPglBv1/jn8jRrQNCyLgw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 2024/12/11 17:43, Amir Goldstein wrote: > On Tue, Dec 10, 2024 at 8:19 AM Kefeng Wang wrote: >> >> >> >> On 2024/12/6 20:58, Amir Goldstein wrote: >>> On Fri, Dec 6, 2024 at 11:45 AM 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 pgoff, >>>> + unsigned long flags) >>>> +{ >>>> + struct file *realfile; >>>> + const struct cred *old_cred; >>>> + >>>> + realfile = ovl_real_file(file); >>>> + if (IS_ERR(realfile)) >>>> + return PTR_ERR(realfile); >>>> + >>>> + if (realfile->f_op->get_unmapped_area) { >>>> + unsigned long ret; >>>> + >>>> + old_cred = ovl_override_creds(file_inode(file)->i_sb); >>>> + ret = realfile->f_op->get_unmapped_area(realfile, addr, len, >>>> + pgoff, flags); >>>> + ovl_revert_creds(old_cred); >>>> + >>>> + if (ret) >>>> + return ret; >>>> + } >>>> + >>>> + return mm_get_unmapped_area(current->mm, file, addr, len, pgoff, >>>> flags); >>>> +} >>>> >>>> Correct me If I'm wrong. >>>> >>> >>> You just need to be aware of the fact that between ovl_get_unmapped_area() >>> and ovl_mmap(), ovl_real_file(file) could change from the lower file, to 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 = 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 Thanks, > > 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 realinode/ > 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. Got it, thanks for your detail explanation. > > 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. Yes, not critical, at least not too much worse. Ovl is always lack of vma THP alignment or some other VMA allocation requirements. > 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." I think we could ignore above issue in this fixup and if there is a need to check vm_flags in ->get_unmapped_area(), we could deal with it later. And Jinjiang, please send a v2 according to all the discussion. Thanks. > > Thanks, > Amir.