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 CE1BBE7717F for ; Tue, 10 Dec 2024 07:09:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D1F56B012A; Tue, 10 Dec 2024 02:09:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 381726B012B; Tue, 10 Dec 2024 02:09:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24B366B012C; Tue, 10 Dec 2024 02:09:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 044356B012A for ; Tue, 10 Dec 2024 02:09:08 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B092740FC4 for ; Tue, 10 Dec 2024 07:09:08 +0000 (UTC) X-FDA: 82878171768.19.15FD375 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf08.hostedemail.com (Postfix) with ESMTP id 5126616000E for ; Tue, 10 Dec 2024 07:08:50 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 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=1733814524; 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=+0tv9RTZyc0ZZ1s6QPkC6upYQnmOKI0TcTVd9NWS9Nw=; b=8MvFg1YQfR8u6GmupMo/wfsX1LNztF11qFoyH5+7MZWuQbU62Y77eIp9VxT4T/0lV9Ih19 hZSer2tOxVz8A+qssm7LRQ3cfk1qWZz4t+kqvxSjYJ+S2rgek4mmQLh80zbr3MC0ew3jx0 9kyp+iopu+VSM9WtCnp2tDlLfeLfd+Q= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 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=1733814524; a=rsa-sha256; cv=none; b=1QLIQ0NlnZdklFVcJxUyJYa7zonGsIwwlA9vE2C1ZEeSva2y++tj7dPBwPbRzH73ILDz5f h/aGS1ZFPByT6cAoxTr9bHoNDmXpQ3r3nOGjd+lhuILXgU4d00wuoLmtaIcq1yRBdG4bnH Yl4G1PYjSFsLRDmml2szOT5SqlUI07o= Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Y6qYK5nBGzRhmG; Tue, 10 Dec 2024 15:07:17 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id A55431402E2; Tue, 10 Dec 2024 15:09:01 +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; Tue, 10 Dec 2024 15:09:01 +0800 Message-ID: <21f75d9e-dbe4-44d5-a3fc-65f6358bd429@huawei.com> Date: Tue, 10 Dec 2024 15:09:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next] ovl: respect underlying filesystem's get_unmapped_area() To: Lorenzo Stoakes CC: 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> Content-Language: en-US From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5126616000E X-Rspam-User: X-Stat-Signature: k7pc1bwbksecjaerkezgbr6nj3hd1znc X-HE-Tag: 1733814530-524123 X-HE-Meta: U2FsdGVkX18BFpbx9yLnk1hQpF10kjtSHOPUQJw/OnWEBUszzXPJbqixOZYvWvNqK1k3ceWcnUwuKqeYx8IQOmhgdl5vj7GbvpH0q5bhgRPwp40NXVQTm6Unvg+rfXAefF8EJzubT3NnC7/RGrSHnv5V7kp+LlIgae74+TVIw9wMPJnyktQgY7TMLStxIBFYKvV77jn580abUzUhagQJhuH3IjZFYyfObJN/zJZRsF+popTNseN7paYORF1V7AXSqBn3w9h/NmekrARMdV9+cUCkahPCRb9QVDeO6WCxj3VlbDjsRuP/VfmX8F5VYJE4l0eC0p7lxSqsvQwNgBiHUdNfwUHasxSDejxb+Dg0yPklQgMr0DYoMjB1Re8NZiMADj+vV+3m+KC82Ozy/nNQ760hzCvVE5ex2ujDzBav+e5cI0h4G1c4X6uwulhENhKYGiY9OiJYrg5mnu3XZw281GPwzKRk+zORFyIUbSNLh+j5s7aq1k3WnRO3KNmw84ZaoIbePRDCLEeEGGIBmZWFkOsTjTePmvdpe6PrIp0tO50KObzWn68QDVWXg16nF/gNAZNo3D/RyfU2PC7Z3fd0FsOo5ObiKuMdNPzsf8lqSIfFAW8YwHZH7Ep/IT1x+2F3lT6Nm3Z+f2hcvKSuLfR6xt6zoAT26d7LtWbLI5pJTGMPvHXb5n+DeBhVG0jEbYa96G5NyNPGuDSbCKZMmPwAwt3I9qJXX2O2RMGTRGNfjxo0WMwxpxu/CPBhX76f4b62bq2D+T0Ee628ZfvZM1bCBMEiPP6vS2KyW/02OGvycs6XUljBDIcrRjC4Zc5L5Hzvo/ZdxH940p9nf4ZFdTGCvNV4JMIOfnm3T6t9gYtuKhbR8QSmER5GAEhsd2lZsvn2d1WhDJHCrGBuBGTrDLBkRh88xCtdjhqV+ze+vWfVWmmEHtwKcLpoKxhImsBNHGWYG/OWo9IdyryuGFNQz7L 7RWd+20p inAFnw2Yn5rM5nhQUlGYFf2HUZukahGBa4s7cp64nWhnlivVYqhwlUPSHfUmjNQD3KshGtuSS4+WiIMVoqTTXYEtpUmAiYDxBbIg9w0UY4cVFBz8KOrXPS3KkW6vWr4cEI9S118X2+8fWqfgvIHg8ec1zMRS1FvJx/Aaf6ogjrE8JK0iZq4DT8lDS94sm7iV3X9TtlCwbnOVr68HXoBUT17LkqIFAcz5hfY9g 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/6 19:53, Lorenzo Stoakes wrote: > On Fri, Dec 06, 2024 at 06:45:11PM +0800, 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); > > Credentials stuff necessary now you're not having security_mmap_addr() > called etc.? Not familiar with ovl, but we convert from file to realfile, adding cred to prevent potential problems. maybe Amir could help to confirm it :) > >> + >> + if (ret) >> + return ret; > > Surely you'd unconditionally return in this case? I don't think there's any case > where you'd want to fall through. Yes, should directly return. > >> + } >> + >> + return mm_get_unmapped_area(current->mm, file, addr, len, pgoff, >> flags); >> +} >> >> Correct me If I'm wrong. >> >> Thanks. >> > > I mean this doesn't export anything we don't want exported so this is fine > from that perspective :) > > And I guess in principle this is OK in that __get_unmapped_area() would be > invoked on the overlay file, will do the required arch_mmap_check(), then > will invoke your overlay handler. > > I did think of suggesting invoking the f_op directly, but it feels icky > vs. just supporting large folios. > > But actually... hm I realise I overlooked the fact that underlying _files_ > will always provide a large folio-aware handler. > > I'm guessing you can't use overlayfs somehow with a MAP_ANON | MAP_SHARED > mapping or similar, thinking of: > > if (file) { > ... > } else if (flags & MAP_SHARED) { > /* > * mmap_region() will call shmem_zero_setup() to create a file, > * so use shmem's get_unmapped_area in case it can be huge. > */ > get_area = shmem_get_unmapped_area; > } > > But surely actually any case that works with overlayfs will have a file and > so... yeah. > > Hm, I actually think this should work. > > Can you make sure to do some pretty thorough testing on this just to make > sure you're not hitting on any weirdness? > Great, I thin Jinjiang could continue to this work.