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 12627C3600C for ; Tue, 8 Apr 2025 08:20:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC8136B000E; Tue, 8 Apr 2025 04:20:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C776F6B0010; Tue, 8 Apr 2025 04:20:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B40546B0011; Tue, 8 Apr 2025 04:20:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 97BC16B000E for ; Tue, 8 Apr 2025 04:20:33 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 23E0EACB3C for ; Tue, 8 Apr 2025 08:20:34 +0000 (UTC) X-FDA: 83310179988.17.54542C2 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf27.hostedemail.com (Postfix) with ESMTP id 863234000E for ; Tue, 8 Apr 2025 08:20:32 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FYcXVTGl; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744100432; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sbvVM1LJYLU+RQtbC2wLJiPYiQ2nrHl0etB1S+A/dJE=; b=udvWuqFO7WxoETTUiNlgLAq+KHInZiYY92gEs37iq62zdbhc0vxmH1eOOBJ2xFJdwgdXAg HmPXt6SPSWPKPfeZiNACChSsS2X1vhpRyHudmt9bTz+aK+kmizW0THGoQfesyQ5r3h4Mij MjA5ROlKptemehBcllo4F5NdK2cZvpY= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FYcXVTGl; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf27.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744100432; a=rsa-sha256; cv=none; b=k6PkGqK+vH5si/a4S/DtlsPHkloOSqTzTjAQTX+X5QC+Q24Wq4oyClch18cqy+KpjEgbKP Yz3nzOCEYHvVorb6DA5qEC+M7Enxpgk/0enwk/CgZGZ9y0KXKG4SfXMBgsGlOobvYRsxmH DzXs33I7gMgLjfqW9LE3cKZqoZBRL7o= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 2D8FDA48F55; Tue, 8 Apr 2025 08:15:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FA34C4CEE5; Tue, 8 Apr 2025 08:20:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744100431; bh=Gl8aKp8YPTXV6vYNBx5WZb1Y3vIRz7X/10qClRoa1ho=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FYcXVTGlrj2UFsKmrHbtAvoofgPMX1u0d6/CD4+V20TsvQnKdJo/EEAz0ikU+VAr1 7r52Uw+Gu45agIKqKyDefSxnQzdeQn6Fd9/5cJaiURAE8N+Kr0ovvZ0yBQrJLmkzV6 WHbbu8ECVse8tCKEnlhAaJ4Fsbz252zkvHUSpotiA+g2jHUikFrKCxnNxPgm39PkMx 9PtG3+DrijSJRsOvkYrvMni0IomOKoe39NtmUlTTzItNtIBqj9UJ1VY4l2hbvitIqa Y73UdqZhs1k9+w24iUFvuIEvpottq85HsCI2Qw2/DlHbCd0G0+rBI47iHbPwmZI2gz c6D121dAJJPgw== Date: Tue, 8 Apr 2025 10:20:22 +0200 From: Christian Brauner To: David Hildenbrand Cc: "Liam R. Howlett" , Nikita Kalyazin , Ackerley Tng , Vishal Annapurve , Fuad Tabba , akpm@linux-foundation.org, pbonzini@redhat.com, shuah@kernel.org, viro@zeniv.linux.org.uk, muchun.song@linux.dev, hughd@google.com, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, jack@suse.cz, lorenzo.stoakes@oracle.com, jannh@google.com, ryan.roberts@arm.com, jthoughton@google.com, peterx@redhat.com, graf@amazon.de, jgowans@amazon.com, roypat@amazon.co.uk, derekmn@amazon.com, nsaenz@amazon.es, xmarcalx@amazon.com Subject: Re: [PATCH v3 0/6] KVM: guest_memfd: support for uffd minor Message-ID: <20250408-wegrand-eifrig-355127b5d3a3@brauner> References: <20250404154352.23078-1-kalyazin@amazon.com> <2iggdfimgfke5saxs74zmfrswgrxmmsyxzphq4mdfpj54wu4pl@5uiia4pzkxem> <63j2cdjh6oxzb5ehtetiaolobp6zzev7emgqvvfkf5tuwlnspx@7h5u4nrqwvsc> <2bohfxnbthvf3w4kz5u72wj5uxh5sb5s3mbhdk5eg2ingkpkqg@ylykphugpydy> <9326367c-977d-4d55-80bd-f1ad3673f375@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9326367c-977d-4d55-80bd-f1ad3673f375@redhat.com> X-Rspamd-Server: rspam01 X-Stat-Signature: gnso7i9gpm7zrxabsgws6wz9mafp9yqn X-Rspam-User: X-Rspamd-Queue-Id: 863234000E X-HE-Tag: 1744100432-525950 X-HE-Meta: U2FsdGVkX1/C/TzWnsP4x5bwzSQzX+5CtSPZqkfcZ4gKGgpfUILK/WcC7QaBYw6CnUfsdfVAqdthBzyftj+HZBj1jjvfXbuIR8Srr0gPzTFC5LabjHTqcBNByO7OI9Kc6mSNQU0xekycNdn2aC5EZAhCE3qPi5mf6Fzm4e4/0U7yTBLXt3BtY6J+RlWv0EIgUnbfEicTM3x6d20ZVc2slJc8+qygVKoAO9mypZGuTSvFDxEpfxXntGXmyDmbEGO3giKA799YMxmLGAbOqZVX9P7Uu3HQJ+YByNCrTEVW3BkKuAw7/9xNQTxNt4gwOvNothHj9P5lQJwvP/Gkd0VNyivjazLTecJ4r3X0bfMGqXUzpknOy8zw/6jW5dkea11at22z+DGMRHd7ORZi66h3RcOFYmgYH+nbfH84fhSqZy1tnDSQkleZAgZnCUt24Y4LaerGv/0BaW03AsREm4xvpcRyCQgO3+prXeQi/x+UHsXoZU0JSvQvLbDwpX1ScaZT+yFwm8Qd44pu76IQuj3UfqCgU1SOcm7T1pCv7XzWb1/DnIBUhAr+lNox4xbYWGRrt5qTFig/AuPWas34Omb8C6U1tC8Gj3u/TOFM4gnYsiNDB+WtnEGs48fch1VoSoEUDuiplkPWKI0H594AMnsuuLtpUCuhmaLAC6eRXqTWBLST0hcU70eWD0hdSJsxBWbCrxCDMKEYKp1Lvv59zEgiExoIgYDp+AGTURDPk9GR8gkUMeI3+4l0o6i88U1mplHnsil4sTgIJrE/vOfme8HqqrJQpbxr58VR+K1Yn66XkGDmv6dPFJOFjuok0LIuIoygc4sKWbRvVsokjq2gSBFy5JO7a814+z9gKxl8Fh8vRzs1tRWp6F7MavZA79TxfUcbC2mxOU0ZombyDKwFHzcLAfUXUUtzEzOty/lVAJWDV1E44GnEJJcPWoZV6nrtP+4OhW64/vQhqe/SSqCY5r5 wDWxzEju ao/DK6saSc2OAM2Hz4L/0zCx29AgRyDC1WstdTfrGVbxXaWpFd2hzAk94AeybXoYzLHLZmW06w3rGVoQa0hMp2Bb63USyUM7U+T0iVSi7hWZOn5izsGdd/3owdaoDL/3pbMbTRO14Lmbo6zk0XdU/8Ez1dgNVnU0kv4agW5glz+Db2Whld8+SakRGEws7S3hqIzywrO3FSh8mGE4z/4evnP+X7fHVKt1uTaQ5cOmpGjzYGv4WhsheNPz3ok2jMRHSOmCoSwYNQ695sOiuLokcGibqFtBPlIH48j8MBYrcSUmPDVISydJZHaW33ZFeAYDKd1sZknUx92zjnRjuIgU3haWuwwov47mZY28h+LqEkyPxaRAP90J7WCzVvA== 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, Apr 07, 2025 at 04:46:48PM +0200, David Hildenbrand wrote: > On 07.04.25 16:24, Liam R. Howlett wrote: > > * Nikita Kalyazin [250407 10:05]: > > > > > > > ... > > > > > > > > > > All of this is extremely confusing because the onus of figuring out what > > > > the final code will look like is put on the reviewer. As it is, we have > > > > issues with people not doing enough review of the code (due to limited > > > > time). One way to get reviews is to make the barrier of entry as low as > > > > possible. > > > > > > > > I spent Friday going down a rabbit hole of patches referring to each > > > > other as dependencies and I gave up. It looks like I mistook one set of > > > > patches as required vs them requiring the same in-flight ones as your > > > > patches. > > > > > > > > I am struggling to see how we can adequately support all of you given > > > > the way the patches are sent out in batches with dependencies - it is > > > > just too time consuming to sort out. > > > > > > I'm happy to do whatever I can to make the review easier. I suppose the > > > extreme case is to wait for the dependencies to get accepted, effectively > > > serialising submissions, but that slows the process down significantly. For > > > example, I received very good feedback on v1 and v2 of this series and was > > > able to address it instead of waiting for the dependency. Would including > > > the required patches directly in the series help? My only concern is in > > > that case the same patch will be submitted multiple times (as a part of > > > every depending series), but if it's better, I'll be doing that instead. > > > > Don't resend patches that someone else is upstreaming, that'll cause > > other problems. > > > > Three methods come to mind: > > > > 1. As you stated, wait for the dependencies to land. This is will mean > > what you are working against is well tested and won't change (and you > > won't have to re-spin due to an unstable base). > > > > 2. Combine them into a bigger patch set. I can then pull one patch set > > and look at the parts of interest to the mm side. > > > > 3. Provide a git repo with the necessary changes together. > > > > I think 2 and 3 together should be used for the guest_memfd patches. > > Someone needs to be managing these to send upstream. See the discussion > > in another patch set on guest_memfd here [1]. > > The issue is that most extensions are fairly independent from each other, > except that they built up on Fuad's mmap support, > > Sending all together as one thing might not be the best option. > > Once basic mmap support is upstream, some of the extensions (e.g., directmap > removal) can go in next. > > So until that is upstream, I agree that tagging the stuff that builds up on > that is the right thing to do, and providing git trees is another very good > idea. > > I'll prioritize getting Fuad's mmap stuff reviewed. (I keep saying that, I > know) Fwiw, b4 allows to specify dependencies so you can b4 shazam/am and it will pull in all prerequisite patches: b4 prep --edit-deps Edit the series dependencies in your defined $EDITOR (or core.editor)