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 E2DDCC83030 for ; Tue, 1 Jul 2025 00:15:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48E146B00A6; Mon, 30 Jun 2025 20:15:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 466616B00A9; Mon, 30 Jun 2025 20:15:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A4096B00AA; Mon, 30 Jun 2025 20:15:19 -0400 (EDT) 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 2A45A6B00A6 for ; Mon, 30 Jun 2025 20:15:19 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D0F381D140F for ; Tue, 1 Jul 2025 00:15:18 +0000 (UTC) X-FDA: 83613776316.18.F6993E2 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf11.hostedemail.com (Postfix) with ESMTP id 25AFE4000F for ; Tue, 1 Jul 2025 00:15:17 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LLv4oFBr; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751328917; 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=aDRWPXmklWTA7c1dpxd7HnCZEO3d3jxC+/P9KGU1j74=; b=kB7U7vbpIzquj1SogbrS25LmLT/gwXLmk0Sd2KkRfxlcvB/ta7XfXnCdC0wQ66LkEn5KFX OxsoeCXYZvdr/fYh6K+f6tRonh3AKqzU/yn6WXUgRd+6yZ9v8pLpirp+x9V8ihayWp6pim u/pCNI8fAg7M5Qqjfb/Fz5QYvBuUPXg= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LLv4oFBr; spf=pass (imf11.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751328917; a=rsa-sha256; cv=none; b=MHHJTnYhbU+RIDxSEfSFasdL8Rl0JqhxoM2J24Ay3e8ZeY3r9i1BZcZl69uR1x4LWKBNGj /SKZ2/9DF9ij9BRH9IjQVH9mKCX+EX47SJb5MeNtFHW+ogFq2w/AlSX3RkOv9tRgIjvE86 BnfyOK/rIeKqwgXyG10gSlTpMhLAwMs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 4D40E60053; Tue, 1 Jul 2025 00:15:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18655C4CEE3; Tue, 1 Jul 2025 00:15:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1751328915; bh=ku90VFfylAoMLWqTj/QMTIzfueRufunLQSXYhHf56S8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LLv4oFBrgJbFl6AYbTuI9dWMfMThbxv+4JyBHOS067X0azzyM9P/qDe98vnNq9tbH 7b+xjqhR96pLIFezeQql06VfFZNU6Ezm5f5FEzFxVhewOtSncIvPcDcfcYwUYDm0M7 I20c80mGv7lVoGEU3IqHeKBaW+m9y1Hl+oIwAXuA= Date: Mon, 30 Jun 2025 17:15:14 -0700 From: Andrew Morton To: Lorenzo Stoakes Cc: Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Suren Baghdasaryan , Muchun Song , Mike Rapoport , Hugh Dickins , James Houghton , "Liam R . Howlett" , Nikita Kalyazin , Michal Hocko , David Hildenbrand , Andrea Arcangeli , Oscar Salvador , Axel Rasmussen , Ujwal Kundur Subject: Re: [PATCH v2 0/4] mm/userfaultfd: modulize memory types Message-Id: <20250630171514.62e447f8890ad01577a9f00a@linux-foundation.org> In-Reply-To: <92265a41-7e32-430c-8ab2-4e7680609624@lucifer.local> References: <20250627154655.2085903-1-peterx@redhat.com> <92265a41-7e32-430c-8ab2-4e7680609624@lucifer.local> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 25AFE4000F X-Stat-Signature: et5tt4ac6cdqq7siw8sk3aruu19yatz7 X-HE-Tag: 1751328917-838301 X-HE-Meta: U2FsdGVkX19rc/O1q2TLN/5h43oHPWdBrmytfursan5+NxIircwbg/s/aiCJEWKe+jx0Wun0Co30ZHs26PpWN19iIUglz1e3pXS0Qf5BQllRIrpM7HpVQ2i/x9OePMUZST6Um8Gj6RfpPf6kk8g8VjPYKi0Qq+CxXisnPEQT+WKq2pRqELz6mB2fF2X7qtU/mgcj8hycbfhqdOWVjgHwcQCU61j/WHeFQSiZf6vF+Omn2WCmpahaWwG5gAYrMl5jmG2Rp1CpSQW1j2W9kMpHZA7htPshifCjoSSuyAxS3CcphJB8qAPxwgKgHOXuw9QfDyaCE30JlV7Vl7ae+adL9jcy2Dmyjh5zMvW/fiiTubNNKWlltyvlaDLjgJSMHdXqruos+OSz2KrnfgTL82azgrE7wXmK0DsQSX9lrs4vUl5Jhqzix3eQmdhCXaAhR1UzMA8j2PE88sTKLwNF/SazJHojRqoUNgd/I15gilpfUKzpYDIM8DBn99JdLvBJB3jOgKADJnXuU5I4LGcYiVLIzA6qm16GxGJRFjo0iLJ6sWr/2iqYc0do9UMQHtbgUfAX4VP4FGhC65bXRf0UdjzHr5Zg7/kEbsrbhHYTRbdoC47qcCMJOcRK1kHSuxSw6l20OmXstd2k0jnJ46wLkGzWO18n1vcD64ORL98TEgD1ktBOL2kf3liE55Bzee6L3ObRVRCzzFXTTbwiqGI7Z1FF0T3B4UFE1+i1liaDeBiCzDwIxdEeozpqOmnYD23ggecAQtu4FKxsUNx45ltwvyQ2Ah81XYF8T9QQughkAg0y8JPMVM+SLPezmSWIUa4COaBV84QoQLmqDJ4JLbjbszys977YZLOgYLrFiFGjiCiWpnWQoEAfynBPWtCmOk29h3T4d7FRkZuEMflmsjGve6daoHd4k5C5umqefZDjplYv5AUXCi/7zmYKXcUK9tnjv1kpFssZQJpzqAk/3AVhAzH FFKC8lg9 KTVlOzIO1VMdfQ112S951IrUlJPMhEDj0AMELda/Q7lS5l1Oo9ZNA5MiqD1pM/LIdGDMXU+3PbCYW+QkqbhaSdWTOW9HuCrlsmxxiRs/VyhnBxI7wiA86KrJ3WPA8fKGSHerRZu2GRdizPb7uNRtCsUkGwHV5ZmTDEHFmZtvUYM/OrC89x+5vSI515HbM/kFc1FPnacEwYCgaPNLuF1/4u5iLEN8G6P5j4WRSZMHMfv+ExIJEapqfdYY/WkdomCdgKcH44z3zf5Hg8kGyJO0ofCLdOPRKKEOLpECmKiEsYHh5nyZMUbq9gHhZTFcZCfIytGKuCt+HWL0ezQe5HgPXMTHKUw== 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 Mon, 30 Jun 2025 11:29:30 +0100 Lorenzo Stoakes wrote: > > It also means this series does not depend on anything. It's a pure > > refactoring of userfaultfd internals to provide a generic API, so that > > other types of files, especially RAM based, can support userfaultfd without > > touching mm/ at all. > > I'm very concerned that this change will simply move core mm functionality out > of mm and into drivers where it can bitrot and cause subtle bugs? > > You're proposing providing stuff like page table state and asking for a folio > back from a driver etc. > > I absolutely am not in favour of us providing core mm internals like this to > drivers, and I don't want to see us having to EXPORT() mm internals just to make > module-ised uffd code work (I mean I just will flat out refuse to do that). > > I think we need to think _very_ carefully about how we do this. > > I also feel like this series is at a really basic level and you've not fully > determined what API calls you need. > > I agree that it's sensible to be incremental, but I feel like you sort of need > to somewhat prove the case that you can jump from 'incremental version where we > only support code in mm/' to supporting arbitrary file system code that might be > modules. > > Because otherwise you're basically _guessing_ that you can do this, possibly, in > the future and maybe it's just not the right approach but that's not clear yet? Thanks, this is pretty fundamental stuff so I'll push this series back into mm-new while we think about it. Soon, please - I don't want people to be basing new work on something which might go away,