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 5765AC021B1 for ; Thu, 20 Feb 2025 16:22:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA0924401F9; Thu, 20 Feb 2025 11:22:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C4F614401F0; Thu, 20 Feb 2025 11:22:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AF0794401F9; Thu, 20 Feb 2025 11:22:15 -0500 (EST) 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 95EE44401F0 for ; Thu, 20 Feb 2025 11:22:15 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 042FEA501E for ; Thu, 20 Feb 2025 16:22:14 +0000 (UTC) X-FDA: 83140840230.20.D2536C6 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf08.hostedemail.com (Postfix) with ESMTP id 0475D160002 for ; Thu, 20 Feb 2025 16:22:10 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uGmUVGPC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740068531; a=rsa-sha256; cv=none; b=UsFxPT5TZTNVoLrPiv9Sn7Dl0YAPv+4ITZBxubV0eHKaBID4z09iiQ8J4ZaucIFn2tWONd vOTVhf4U1aYYJI6iBe+4jhEK6pPevIuItqiMUNhXDcZfcfXhrPWzyGy6D4ohXuuHl7m162 BeAcYQQ5S5oJv8nbsYZD9l1Uro/d9oU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uGmUVGPC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740068531; 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=C5RWv4Oht+LsTsTvLtn0X1kIsGJ2QBZ4Q1SHZfo5328=; b=zx1APF51lVssoT8Ml3Y0y944sy1cOY8uqrYh9Bocx2YKjqyl+ZbfgKRcmHelvOw3dR6jVL 2/LGHbiywF9Yum+cniVxJIuQbBPxJD0Gl8ArdlOl+Boa0tGPnb26Sc8h/c935VZEh1SeFy lo4YoxCeTlvjj1EtVMaGwhLBfTeHdh0= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4393ee912e1so53955e9.1 for ; Thu, 20 Feb 2025 08:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740068529; x=1740673329; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=C5RWv4Oht+LsTsTvLtn0X1kIsGJ2QBZ4Q1SHZfo5328=; b=uGmUVGPCE+yZZYWMMmF9iL+7hWESzwv0nMFKB3EEzLyCzAdJd825dTuGv7cgRcPxgc WiKmVJnFbe8/eD5nWojOxxOO7PDpMnHgaGVWySMha4wf9epg5yyOY+mFvo7NIJgBxjrY WeL6fnAndLqI2ySSBpcY5Bo2/phMeJaSNW/uwTaqja656nbpXBAnjeM0+65EsTzl7jFr /PmTiC+8lsatD5Fa/7Bz0cwSIm85HBukgduEe1ZRHLDKw819Tyhx++aZqGJUAsPZLP/R HmrGt9NaEK6r+AwTVIImHSvrrd1HpUn2CaJARvkH4KOmaD4hHOz8BNYTo4E8fWHeK5JC f9EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740068529; x=1740673329; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C5RWv4Oht+LsTsTvLtn0X1kIsGJ2QBZ4Q1SHZfo5328=; b=rfyIeSwH5ADZOIbvPT4tQX0z09QW41eJskAiNOmTciCg7e+f3cmhTB/RBbWotbXlFO XNiq2OdHiUAhQnv+LzP7BoU01P8IMsQUfUy9l8ZpLyy7Z4X8ogoMY8EeawbFtKluu5K5 u7pqmFI47pAPf+Ha/lDcbAZi/5o88dI2IgBhl9Ihdgtvwtp6ZyrObJC3KLDcV7pgK/Gd 6GnZqSJVNBcL5E8HoF4VC3Kxgq4GSa2Pc34jUa3P0Fi0QcKdeOFz/pUvvmtgie6k181+ wTCnftRI4pkTwfltAOh2sUTqG6WAMwSjev7kdSBhOu90jlGTT749hjcSLVt/L6cxN6WE h2VA== X-Forwarded-Encrypted: i=1; AJvYcCWgmn+KirmKw5mUM6iWncjXeGgilTEomz0Z1nvK5fIFqgiRW5xIeN5EHs7OoNJ2dFj2WDt2POVYPQ==@kvack.org X-Gm-Message-State: AOJu0YwazbM8Aw4zb8xSwGXZo8qR+TSNa5gDz3heSuP+1rbg7ecBp/MY tdY6L/3T+7LrsHc0z631+0hqaOAPGDTygTbGW5/vaPBWSSgODCCzVNctY/SZ2qJ6wppKHawfS0b bojLY53tgJzZvs8BvsrsA+Gp8PSQK1wXycwVC X-Gm-Gg: ASbGncsxPxRgTkCgAVA1uzetg43OR//5AbTd1BDWffsepgMXdd9vvG+oDdRS1TxSw92 acZJ/UVyhrbiklPS//dLor8bNIYkFmHe2UuMZ/bz392bO5eXa8NNgJGNCeVaiKQKw1Q+uz/0c X-Google-Smtp-Source: AGHT+IEOrIguQcBOjXWtiHCKwopXN+WtboolRWXtVmDAQGp+1Z6t0KvSTIc5/WYVKx9BFIkZehap41ICQaQzIQ/Xh1c= X-Received: by 2002:a05:600c:210f:b0:439:7fc2:c7ad with SMTP id 5b1f17b1804b1-439a4767feamr1201225e9.7.1740068528532; Thu, 20 Feb 2025 08:22:08 -0800 (PST) MIME-Version: 1.0 References: <6e356431-5ac9-4363-b876-78a69ae7622a@lucifer.local> <4aa97b5c-3ddc-442b-8ec9-cc43ebe9e599@redhat.com> <387f3516-99f2-41e9-967e-4b051a8d21b8@redhat.com> <72e044ba-64af-49c0-8b87-ead508654fb7@lucifer.local> <4f5a9c19-9bdd-47eb-bb14-205e3dcced90@redhat.com> <1e959451-2534-44b7-bf62-bc75305048fe@lucifer.local> <31a007c0-884f-495d-ba27-08e3e0dd767d@lucifer.local> In-Reply-To: <31a007c0-884f-495d-ba27-08e3e0dd767d@lucifer.local> From: Suren Baghdasaryan Date: Thu, 20 Feb 2025 08:21:54 -0800 X-Gm-Features: AWEUYZmUc3XJIdBmrSxEVAYvHGFXnZ-DZGtTP2XuTCRhGTOphXLfooYmt5dVI1Y Message-ID: Subject: Re: [PATCH 0/4] mm: permit guard regions for file-backed/shmem mappings To: Lorenzo Stoakes Cc: David Hildenbrand , Kalesh Singh , Andrew Morton , "Liam R . Howlett" , Matthew Wilcox , Vlastimil Babka , "Paul E . McKenney" , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shuah Khan , linux-kselftest@vger.kernel.org, linux-api@vger.kernel.org, John Hubbard , Juan Yescas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 0475D160002 X-Rspamd-Server: rspam12 X-Stat-Signature: mqpkypjpkpbgmwrbk6gn31wprthqyxmg X-HE-Tag: 1740068530-326708 X-HE-Meta: U2FsdGVkX1/6rWBIzcf8/SaDivLJrwx0rQ6b3Mpc+Zr0vpY03olm4tB4aUdArZ1EWWNidXoNb+ii5+hV+yjL5A5Z4PQiljh4HUcfPlodD4MtwxyX47hF3X+e8WK2JihHV/zvV4miT0Wn/+OEKjdVky0o2DDvR4ntryfjEYQ6uDqVmHhz9kY/wBKm8H04p/locDUsrNQJIASjVXR2fLgcaOuF197HGgeCdbatKn0kz2bAqd68frLGTUHQ8M5hisiHG7uGIREFkehJkx//hyTdZKrIra8ZX/HV6uOj+HCV1UVVZt9Sh/g9hN5LvKiv7wPFdjnfRrF1SHoxQi5puUgbh+FeTqDBNklfiz035HZfZvMup1Y2WYaVYZx7Zc+HvKgBTvBUNQ9wwcv528UFBEtgMPz6Yrnol/rzkeX37LZWhdy+FmP0RC+AsmYLQKGMHD0qBsmKmEaWWlYsmZQgLkvRfv2T6AxHPFHlP1DcSuYfEfC/eZBAPfXcBggMyHJeHo5KoM/GTxZ5pNHttjgiFXFlSXLSoKT8zjDHpFMOEpTChiNNVsTvNGJGFuHfU1yYMziY8H6j6uYKr4DG2aKdzHK27K42B8vjS1h003gzJypjZm1d8h4SpW8hCOUqGLYiXt4InskbUj7qyfDsjagC22uBpLclflX2aXH13RXHAChAlactaWqgJ6QrBz4NVnFv/BuEo3KRi5YKM8vy8bGJxOB0r1DC9m+JlsrZ/GZyo58/GWYE8DjIDaSx9bFZ97fgJuOm5HMS/P7FuZQqas/Gy34u34Xumwguk9AnAHnv/0YTlvxK3snGXihM+MO3o2uYT4kY34O/Oh8Us2J+ZQ8xKu5bhz1Qbk57uvo0V34Aoh4/bDUPwtD2G9Y04hMBqwVJH3ybgn+npU2cnbZEM1Djf5nDFWhwlGP28js9Ot+3/YBMyAcESCBfFU2wPbzEmAEshMnJ0XjU9KgNKuDUK78CswN orSVXdfV 0Yv4WdhkiXDFuV8atRPOqj6FwfnmRVhGIkILtBY3OHPL3IGs8A7fmbxrP4Zc79RuLibvHLwMldDO0RsdtMcqNnIPDVHZyYnWzj/gjXZkBg/PeRsh+Olb7fm5+ALH73g1jyhRieC7S3OP5RyavNE1nwpwWfCUvvCOSpWLfhY9VenNi1UnAq+rpsXdj7tHzBlOdaQBYph95ZoGWx/FL/vaPGOALeNkgYKtl6Mdw X-Bogosity: Ham, tests=bogofilter, spamicity=0.426032, 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 Thu, Feb 20, 2025 at 5:18=E2=80=AFAM Lorenzo Stoakes wrote: > > On Thu, Feb 20, 2025 at 01:44:20PM +0100, David Hildenbrand wrote: > > On 20.02.25 11:15, Lorenzo Stoakes wrote: > > > On Thu, Feb 20, 2025 at 11:03:02AM +0100, David Hildenbrand wrote: > > > > > > Your conclusion is 'did not participate with upstream'; I don't= agree with > > > > > > that. But maybe you and Kalesh have a history on that that let'= s you react > > > > > > on his questions IMHO more emotionally than it should have been= . > > > > > > > > > > This is wholly unfair, I have been very reasonable in response to= this > > > > > thread. I have offered to find solutions, I have tried to underst= and the > > > > > problem in spite of having gone to great lengths to try to discus= s the > > > > > limitations of the proposed approach in every venue I possibly co= uld. > > > > > > > > > > I go out of my way to deal professionally and objectively with wh= at is > > > > > presented. Nothing here is emotional. So I'd ask that you please = abstain > > > > > from making commentary like this which has no basis. > > > > > > > > I appreciate everything you write below. But this request is just > > > > impossible. I will keep raising my opinion and misunderstandings wi= ll > > > > happen. > > > > > > Well I wouldn't ask you not to express your opinion David, you know I= respect > > > and like you, and by all means push back hard or call out what you th= ink is bad > > > behaviour :) > > > > > > I just meant to say, in my view, that there was no basis, but I appre= ciate > > > miscommunications happen. > > > > So apologies if I came off as being difficult or rude, it actually > > wasn't > > > intended. And to re-emphasise - I have zero personal issue with anybo= dy in this > > > thread whatsoever! > > > > It sounded to me like you were trying to defend your work (again, IMHO = too > > emotionally, and I might have completely misinterpreted that) and slowl= y > > switching to "friendly fire" (towards me). Apologies from my side if I > > completely misunderstood/misinterpreted that. > > Right this was not at all my intent, sorry if it seemed that way. I may w= ell > have communicated terribly, so apologies on my side too. Sorry for being late to the party. Was sick for a couple of days. Lorenzo is right, there was a breakdown in communication at Google and he has all the rights to be upset. The issue with obfuscators should have been communicated once it was discovered. I was in regular discussions with Lorenzo but wasn't directly involved with this particular project and wasn't aware or did not realize that the obfuscator issue renders guards unusable for this usecase. My apologies, I should have asked more questions about it. I suspect Lorenzo would have implemented this anyway... To make guard regions work for this usecase, first we (Android) need to abstract /proc/pid/maps accesses. Only then we can use additional interfaces like /proc/pid/pagemaps to obtain guard region information. I'll start figuring out what it takes to insert such an abstraction. Thanks, Suren. > > > > > To recap: what we have upstream is great; you did a great job. Yes, the > > mechanism has its drawbacks, but that's just part of the design. > > Thanks :) > > > > > Some people maybe have wrong expectations, maybe there were > > misunderstandings, or maybe there are requirements that only now pop up= ; > > it's sometimes unavoidable, and that's ok. > > > > We can try to document it better (and I was trying to find clues why pe= ople > > might be mislead), and see if/how we could sort out these requirements.= But > > we can likely not make it perfect in any possible way (I'm sure there a= re > > plenty of use cases where what we currently have is more than sufficien= t). > > Sure and I"m very open to adding a documentation page for guard regions, = in > fact was considering this very thing recently. I already added man pages > but be good to be able to go into more depth. > > > > > > > I just want to find the best way forward, technically and am willin= g to > > do > > > whatever work is required to make the guard region implementation as = good as it > > > possibly can be. > > > > > > > > > > > Note that the whole "Honestly David you and the naming. .." thing c= ould have > > > > been written as "I don't think it's a naming problem." > > > > > > I feel like I _always_ get in trouble when I try to write in a 'tongu= e-in-cheek' > > > style, which is what this was meant to be... so I think herein lies t= he basis of > > > the miscommunication :) > > > > > > I apologise, the household is ill, which maybe affects my judgment in= how I > > > write these, but in general text is a very poor medium. It was meant = to be said > > > in a jolly tone with a wink... > > > > > > I think maybe I should learn my lesson with these things, I thought t= he ':p' > > > would make this clear but yeah, text, poor medium. > > > > > > Anyway apologies if this seemed disrespectful. > > > > No worries, it's hard to really make me angry, and I appreciate your > > openness and your apology (well, and you and your work, obviously). > > > > I'll note, though, if my memory serves me right, that nobody so far eve= r > > criticized the way I communicate upstream, or even told me to abstain f= rom > > certain communication. > > I wish I could say the same haha, so perhaps this was a problem on my sid= e > honestly. I do have a habit of being 'tongue in cheek' and failing to > communicate that which I did say the last time I wouldn't repeat. It is n= ot > intended, I promise. > > As the abstain, was more a British turn of phrase, meaning to say - I > dispute the claim that this is an emotional thing and please don't say th= is > if it isn't so. > > But I understand that of course, you may have interpreted it as so, due t= o > my having failed to communicate it well. > > Again, I must say, text remains replete with possibilities for > miscommunication, misunderstanding and it can so often be difficult to > communicate one's intent. > > But again of course, I apologise if I overstepped the line in any way! > > > > > That probably hurt most, now that a couple of hours passed. Nothing tha= t a > > couple of beers and a bit of self-reflection on my communication style = can't > > fix ;) > > Ugh sorry, man. Not my intent. And it seems - I literally OWE YOU pints > now. :) we will fix this at lsf... > > Perhaps owe Kalesh some too should he be there... will budget > accordingly... :P > > > > > [...] > > > > > > > > > Yeah that's a good point, but honestly if you're reading smap= s that reads > > > > > > > the page tables, then reading /proc/$pid/pagemaps and reading= page tables > > > > > > > TWICE that seems inefficient vs. just reading /proc/$pid/maps= , then reading > > > > > > > /proc/$pid/pagemaps and reading page tables once. > > > > > > > > > > > > Right; I recently wished that we would have an interface to obt= ain more VMA > > > > > > flags without having to go through smaps > > > > > > > > > > Well maybe that lends itself to the idea of adding a whole new in= terface in > > > > > general... > > > > > > > > An extended "maps" interface might be reasonable, that allows for e= xposing > > > > more things without walking the page tables. (e.g., flags) > > > > > > > > Maybe one could have an indicator that says "ever had guard regions= in this > > > > mapping" without actually walking the page tables. > > > > > > Yeah this is something we've discussed before, but it's a little frau= ght. Let's > > > say it was a VMA flag, in this case we'd have to make this flag 'stic= ky' and not > > > impact merging (easy enough) to account for splits/merges. > > > > The problem comes in that we would then need to acquire the VMA wri= te > > lock to do > > > it, something we don't currently require on application of guard regi= ons. > > > > Right, and we shouldn't write-lock the mmap. We'd need some way to just > > atomically set such an indicator on a VMA. > > Hm yeah, could be tricky, we definitely can't manage a new field in > vm_area_struct, this is a very sensitive subject at the moment really wit= h > Suren's work with VMAs allocated via SLAB_TYPESAFE_BY_RCU, putting the lo= ck > into the VMA and the alignment requirements. > > Not sure what precedent we'd have with atomic setting of a VMA flag for > this... could be tricky. > > > > > I'll also note that it might be helpful for smallish region, but especi= ally > > for large ones (including when they are split and the indicator is wron= g), > > it's less helpful. I don't have to tell you about the VMA merging > > implications, probably it would be like VM_SOFTDIRTY handling :) > > Yeah indeed now we've simplified merging a lot of possibilities emerge, > this is one! > > > > > > > > > We'd also have to make sure nothing else makes any assumptions about = VMA flags > > > implying differences in VMAs in this one instance (though we do alrea= dy do this > > > for VM_SOFTDIRTY). > > > > > > I saw this as possibly something like VM_MAYBE_GUARD_REGIONS or somet= hing. > > > > Yes. > > > > -- > > Cheers, > > > > David / dhildenb > > > > Best, Lorenzo