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 5A4B7E7717F for ; Fri, 13 Dec 2024 01:51:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C2A806B0085; Thu, 12 Dec 2024 20:51:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BDBE76B0089; Thu, 12 Dec 2024 20:51:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA2476B008A; Thu, 12 Dec 2024 20:51:53 -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 8C9076B0085 for ; Thu, 12 Dec 2024 20:51:53 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F2E251C7A48 for ; Fri, 13 Dec 2024 01:51:52 +0000 (UTC) X-FDA: 82888258530.19.7F5AED4 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf19.hostedemail.com (Postfix) with ESMTP id 62A531A0015 for ; Fri, 13 Dec 2024 01:51:23 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf19.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734054699; a=rsa-sha256; cv=none; b=7oU9S8u8mCWSqlSYtXWgNB/P5FRljfUAWORwe111E+J5Td6m528NN0ZiMb0Wrpk6SG5tlo eJaBrSq1Va+n2eMigJcV4nPCi9vOlaImF0oxAFoEhvn1fZ+1fVpHTHzrLnE7xbq+25eHYx K6qMvoV22uA95J7iNxWnz40pUWbEWis= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf19.hostedemail.com: domain of tujinjiang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=tujinjiang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734054699; 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=JgXlwj2Q2Xk4cwcqrWUDqgzApOSWZcxGr5ao2p6FRyw=; b=Y4vfoUFk52FSaBcTeJEjukdHnHFJ10EvkXHte3b6y9Ds7aIqbdPaq/J+Kq2c8tFRt/6WSL xu7hEHyx9zuoE4gfqvf+3yowH9e8xcUTIwhb49HHZxLcRU1IwqLNV9Clbd7MfY0EbEizHq A9mtzrcjHSpNj1bF1COGaEAdevlY4fw= Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Y8XLF461Rz11Lyn; Fri, 13 Dec 2024 09:48:37 +0800 (CST) Received: from kwepemo200002.china.huawei.com (unknown [7.202.195.209]) by mail.maildlp.com (Postfix) with ESMTPS id 93B20180214; Fri, 13 Dec 2024 09:51:45 +0800 (CST) Received: from [10.174.179.13] (10.174.179.13) by kwepemo200002.china.huawei.com (7.202.195.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 13 Dec 2024 09:51:44 +0800 Message-ID: <847f8485-7996-fd82-b660-83fb798fda95@huawei.com> Date: Fri, 13 Dec 2024 09:51:43 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [PATCH -next] ovl: respect underlying filesystem's get_unmapped_area() To: Kefeng Wang , Amir Goldstein CC: Lorenzo Stoakes , , , , , , , , , 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> <88a1f4e4-8c3a-447c-a207-df754f1ab67d@huawei.com> From: Jinjiang Tu In-Reply-To: <88a1f4e4-8c3a-447c-a207-df754f1ab67d@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.13] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemo200002.china.huawei.com (7.202.195.209) X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 62A531A0015 X-Stat-Signature: o5ngbss35n87zfqtn9imqxrn3tes4jbs X-HE-Tag: 1734054683-820874 X-HE-Meta: U2FsdGVkX1/fXBk696cpBiqIMzhjyp7qNE1XcynTY9z+8R3Ie2upurmwq+M5DUpvjq9ybSGtoyAZ9eKk2hLsgrFzGtlxUGvcBB+nY9m9ryhVBTOJPlR4cI7G8lNKlCOG+2d9uLtdAGeYtbNrP466jQ5oB63q88qOaM870B1VZ6OLzzYaMgDlpUtrKg98eISMebxf/9t0jmo4tmOnKqBbRX+nSOn0gnhvqxFHClluHk6Is8BmEaneDXfTwbyfJnwBCmfMchim84OkQvGIEMeTEDP04QWfNEm/UNHTWu7xt8iiPfn+boBV2hqYQYlVTgfqlZs8kWhYs8DK6GUL7d1s/n4Z+Rph78affRxv5heHZzCNVBNCfuHw0ZdCryPhu93yMbP6E4sfUpJhtL93PaB7VM6FBtyA4p/bHUMD3byiCliz1X+Z0IjJxxMWwt3zkGq4RT7ajRTxRWss7F90nS5skjrZgaFVhOe0Tp37V8FpiZ1tKNYCIxksyrsmGZgk3WHky0jWUWOdD1iKrbXJVRu4qjtHzET3auoQCdE47jdyHmUaJJ91fWg7j3yv21kQjele5bfvujnxJLu9CtKQ1YAw45wndAc65KN5TjWkZkMN1KwJRGWFcaQtbY5wLOm5aLk5BRzQSoo9mH4hvgb2tW+zdZ7loG/A6Qi675dtYSAasnApnCmFHx4E7UcyIvvaUAQRbadjMeyEtPZA6KZQYqMEsNzsDNWq6zMw+f2UmETt9e8rvFknLOBisIu+i1IM5xJ/+tNNCu859LBcFi3TiiFJOjAtzBfIiJlNyPIXHhDM8DGwGdwd+Cq+77l5lIV9Rn7QEhNBUpZtF9UKoGMwtVbtig5iW6Z0F3ohTrQKkyfEl4TsxZLj9HsvcOxJSpImkq/ve+C877SemIG2+Ln2UPZUwQkGgsFDM0DDGGWpexVj8sAYcwdGY82oyu6NRw/T9slOtbe3nD4rIKpumiu4t/0 5XZ4OT7D hCWGNtkKFxXQyYzUDrOejHcKsIyr+V071L+LsSNGg6QOxiYhws7JiWeeVSAehu9CjAPQhpxjdo9kYjhOEV/oeLJBDljVtukCzytYrhBAQLCmEaegdcZdh9Pkhaioky4VObrZ2VFkP/3AG5AvolREiXuqSwPAsnHsfY8LfIiPE7IuuB4O7gi4MXQr+ZnNQeKsZvnepHjipY6ZIjWxd9TEPMx9w6NnpHUWvyUV0aHZ/ZdHopJt98MYo1G0HiMgcRkeaExnC6wVDnSnChRa18BQ46cDNHuHpMPaBxsr9tYSpyyy4VOE= 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: 在 2024/12/11 23:01, Kefeng Wang 写道: > > > 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. OK, I will send it later. > > Thanks. > >> >> Thanks, >> Amir. >