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 5EA61C021B1 for ; Thu, 20 Feb 2025 18:08:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D24AB440207; Thu, 20 Feb 2025 13:08:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CAD9628031A; Thu, 20 Feb 2025 13:08:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B275B440207; Thu, 20 Feb 2025 13:08:52 -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 923EC28031A for ; Thu, 20 Feb 2025 13:08:52 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3594B53B7C for ; Thu, 20 Feb 2025 18:08:52 +0000 (UTC) X-FDA: 83141108904.28.458018B Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf19.hostedemail.com (Postfix) with ESMTP id 3BAEF1A0017 for ; Thu, 20 Feb 2025 18:08:50 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KFSoEDCM; spf=pass (imf19.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740074930; 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=D53WxB+5XGbLoWd50Ahi6aTeZn7Ht74o0ERsJkFY5B4=; b=8hDh+fwaYX+Z9MitRiTzf6dNPjpjtnCnkiS0SY+E7tgL0TjyNGuhIzsWN2Y3HonmuJLe54 5brKbbK+uEAS1qglaCEb51ZRQNzW3we9eonEQ6M2udQeTav94R/F8TuDz3DUzV62VaRxPA ctTJB9uJIma8yoDJv60qFsWDCPEe0kk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KFSoEDCM; spf=pass (imf19.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.180 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740074930; a=rsa-sha256; cv=none; b=mHsYDnIp32UC4aJ8L6dGWA43gD8I8WmUSkOlvRA9tEz4Q2riarOeo75eMYtiCibPBabnqE bo7HTSEHC5oOBa2O4Pv0Lzvn7UfDDuuYe/sD6E0ADgFBUa1TsvmJdAdN04Bi2z926cbuqg Fm5Ox+JiaOQJ4M9k9M3YJJ8MojPKGcI= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-22117c396baso7705ad.1 for ; Thu, 20 Feb 2025 10:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740074929; x=1740679729; 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=D53WxB+5XGbLoWd50Ahi6aTeZn7Ht74o0ERsJkFY5B4=; b=KFSoEDCM5Mlq1fvbfK4//tZXgz2VaaKkwBBK2xQcICxVZ6yhPtiVfweuKTm0kQWD7e bVY1q4rTZiHrTv8asraVEvv4Kv9baP2Lb7r5DVM/JBThzM8xGNM1UgJdhDxliMUsDbIj ChT8ObnufMhkCLB3VPze/7w1eeoV5VM9cFlh/GeCusPGm44x56Li2euX6rr1aCy9rK1H Sx6Rb5ttGX3ii6QuFS4Ld58wYFGxYMKXCKlSG7mzQgA/ocZ1isunJLVbVoyi4wYzyKBt Ue9PZa3vGoivzBYaD42NG5HnRI2iU8c9ljm8UpLJo1Mqu5FwUvnFz1FcfDubWFmGV5FU jA8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740074929; x=1740679729; 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=D53WxB+5XGbLoWd50Ahi6aTeZn7Ht74o0ERsJkFY5B4=; b=bMdU6pLIc7fXckIg8TpAOZ31HPKZOoKVvEBlekWV+6iPjO1T77CK5o4i/lOJ5L3JLO sI3dn2JT5FKm+ZtoZhqHXeV7cX8MeHxOm3neYg0ZBq445FSFs/ZAmHlpJ2CXP2QRc73p N7QYLy3it/RDEdoyeCOTwP1Pi9086Y1Z3ouwgR0tRUZRtl6lHP3e6kR/6pLgjgWlVN85 P5mmrn6PyQ8pu4cQGRRIeUkyDnGoKMveYL9g9OJiTxqDnJXvhzTIbBmeatnGyJJHWM+8 cojiClmDzFPaLRc3QinlwvkLE7qIv0/EshdUrePeDaUrpPj45avJ33KzT+B5+Kuo7xqV hxpg== X-Forwarded-Encrypted: i=1; AJvYcCVJv6EWNPmwHBR6NgNUi82UI+El04suM0LASUXEkWUjrrspp+xNj7iFADokQcu92M7wXs9f+3ofbQ==@kvack.org X-Gm-Message-State: AOJu0YwRIioQamdk2graa5McufZCc491XAoapw6nWlDKNVQjpEFBvEVH ATd7JjUbSUM5J9TUQoDmazst8mb90IvmY8xyrkuwPj5l4hAGSsnjEflp8pqBxfX9ABsAZ9+OXvx aKTML1nTu1nCZkO4iOo8mAuNuOs+tI+YKqK0O X-Gm-Gg: ASbGncuwl+/QN8YFIUaYqvkoA+WYiJbpgoWKQcdhaDdCsGAsTVi+lImwGQQCFSUmV/p DPu2qaHLItG+FR4DeOFE6LTH8/OJz0ItvNjYt5J8YliV8bk9ZkuqDEzp9z0Uq5sWC4uxSb7cs/i yzDG2Rl1ciQ9r8NNRZCNiGPt4xcG8= X-Google-Smtp-Source: AGHT+IGZYPDV28Cz7sYINJpTnmjw8EhukaY1/WmWGcdUtzSTAPhvLJwj66QqkFOK0m59IebD7nMgwWPPoi4mjkkZ9So= X-Received: by 2002:a17:902:d584:b0:212:26e:1b46 with SMTP id d9443c01a7336-2218ffb83a8mr3053025ad.23.1740074928718; Thu, 20 Feb 2025 10:08:48 -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: From: Kalesh Singh Date: Thu, 20 Feb 2025 10:08:36 -0800 X-Gm-Features: AWEUYZldDtJoTDPcjQKD0pHhJ973ZEAcjadmBHGExUTRQr9Y3pOVfjnjWolS78o Message-ID: Subject: Re: [PATCH 0/4] mm: permit guard regions for file-backed/shmem mappings To: Suren Baghdasaryan Cc: Lorenzo Stoakes , David Hildenbrand , 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 3BAEF1A0017 X-Stat-Signature: 4bb9df7jc8om3fe5bbpetn1d4ij7oe7a X-Rspam-User: X-HE-Tag: 1740074930-833200 X-HE-Meta: U2FsdGVkX1+rBbX5H9psn5vsEi5bxdEmlTrHte3hpOH581WHSZCRC3Y1bujsTZoYRclNo49k1KaE/stz8uQqmZEX5H0YYS5zlyz8y9hJXM1LQsShAQd1/kWU7cBhOvkUMpinSOvdtY9PE5KnVs44i6oZZ3TLztWGhM/by8OuJhY7i1IQc1LPB6YwUW4LE7wkvqtGwXE0opzySKbunu0hVQgbI7a+RQlbD3Omeg8UzHfvN0l1LTnJJYRX2nDnpsHfl83dc+jIr7xuFeW7ppIXIWr4cg1gmXPusAUGoM48RRzSi86ezh+5lb44E6XNig+6jELMCS4S88RKYbqudgvASRi6VimMmpkDIgCfjbwoc+UCBPqp8/AEznd5QCu1s7WwNhHjYfqGga9jfoqTQAi+HoKCDD6CrL2V+6iAn2n4pvuIOKb0TExOMJ/sDIABEANg5/kEDavq+3x8l2QlmCYSpSSKgATpSiyRoeCIQIrMy9VBGSwjOtggLeYMOr64WlgCOXzl6rcH+6d8yGAONtcGg5GfitGgWtK3tHVTACiETP4zue/uquu1/5bYVzmsHd82afbNWJDEHcZwD0VqoHx4nlP9wrPoXqG/Ns5F8KUX574N/lkplF1vsh9fGlA4x/7tM6l4qepcP/5Cbb7clzZGPWQYEfM12Pgg3dE6mOWOAdH5kUknFg7yQZFxs8/5HdjKZ/bGL0XHEOgF8G7iKhj/x0JLh9YGd6cgZWV9gkqDEzyZUeZ4BfxkaEqXusr5h8ihyVS6yHm7bUYnarUyyazVbkh7UVJTkFPglW0YtrMBwpsvbwGt4o4QpN1HFXPiGAA9eLG5PxW5kY6nYt4o+vkWqD9BDWoPBqmPAa+wSzbksjfm+Nkixt6IFCrY2wdV8NHVbYPpj/BEEjdLZ22TOWuQ86sbjyaPXtlmmr8IfUfM99K+FC2IzMPO7MUJyZsYYe5jTFXnRfuohAsOgBG/dK4 puG0nNM3 mIZM0U6m7ZZWo8wpRlG11JYSGP+HT8ljPkDwcm7kBeh2mqB+9zEPMktcDRYj0qPlRO6Wc1n4MekfDTIvHOzf5AOv29hPSWsXDaO0/3yR0QvoO85MqdjAeQnnN/ZsVadjQSYBytZEmiRXWEo7jOGhfKwrriZDl73eEpINpEjW59Zi5Z1XDrdJzUiDj2nEm5udPXM3frKBwfNnqQjcCEFy8afify4niGkgexIXoi6VWL2lJ4XBEpIE7mTdD7A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.368687, 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 8:22=E2=80=AFAM Suren Baghdasaryan wrote: > > 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 le= t's you react > > > > > > > on his questions IMHO more emotionally than it should have be= en. > > > > > > > > > > > > This is wholly unfair, I have been very reasonable in response = to this > > > > > > thread. I have offered to find solutions, I have tried to under= stand the > > > > > > problem in spite of having gone to great lengths to try to disc= uss the > > > > > > limitations of the proposed approach in every venue I possibly = could. > > > > > > > > > > > > I go out of my way to deal professionally and objectively with = what is > > > > > > presented. Nothing here is emotional. So I'd ask that you pleas= e 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 = will > > > > > 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 = think is bad > > > > behaviour :) > > > > > > > > I just meant to say, in my view, that there was no basis, but I app= reciate > > > > miscommunications happen. > > > > > So apologies if I came off as being difficult or rude, it actuall= y > > > wasn't > > > > intended. And to re-emphasise - I have zero personal issue with any= body in this > > > > thread whatsoever! > > > > > > It sounded to me like you were trying to defend your work (again, IMH= O too > > > emotionally, and I might have completely misinterpreted that) and slo= wly > > > 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= well > > have communicated terribly, so apologies on my side too. Hi everyone, Thank you for all the discussion. I don't find any personal issues with the communication in this thread, but I appreciate David being the object voice of reason. I understand it can be frustrating since you have made many efforts to communicate these tradeoffs. Unfortunately these issues were not known for the file-backed ELF guard regions for my particular use case. > > 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... > Suren's use case is different from mine and this design fits perfectly for anon guard regions from the allocator. :) So I think in conclusion, these aren't VMAs and shouldn't be treated as such; we will advertise them from pagemap for those who need to know. -- Kalesh > 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, t= he > > > 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 = people > > > might be mislead), and see if/how we could sort out these requirement= s. But > > > we can likely not make it perfect in any possible way (I'm sure there= are > > > plenty of use cases where what we currently have is more than suffici= ent). > > > > 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 page= s > > but be good to be able to go into more depth. > > > > > > > > > > I just want to find the best way forward, technically and am will= ing to > > > do > > > > whatever work is required to make the guard region implementation a= s good as it > > > > possibly can be. > > > > > > > > > > > > > > Note that the whole "Honestly David you and the naming. .." thing= could 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 'ton= gue-in-cheek' > > > > style, which is what this was meant to be... so I think herein lies= the 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 mean= t to be said > > > > in a jolly tone with a wink... > > > > > > > > I think maybe I should learn my lesson with these things, I thought= the ':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 e= ver > > > criticized the way I communicate upstream, or even told me to abstain= from > > > certain communication. > > > > I wish I could say the same haha, so perhaps this was a problem on my s= ide > > 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= not > > 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 = this > > if it isn't so. > > > > But I understand that of course, you may have interpreted it as so, due= to > > 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 t= hat a > > > couple of beers and a bit of self-reflection on my communication styl= e 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 sm= aps that reads > > > > > > > > the page tables, then reading /proc/$pid/pagemaps and readi= ng page tables > > > > > > > > TWICE that seems inefficient vs. just reading /proc/$pid/ma= ps, then reading > > > > > > > > /proc/$pid/pagemaps and reading page tables once. > > > > > > > > > > > > > > Right; I recently wished that we would have an interface to o= btain more VMA > > > > > > > flags without having to go through smaps > > > > > > > > > > > > Well maybe that lends itself to the idea of adding a whole new = interface in > > > > > > general... > > > > > > > > > > An extended "maps" interface might be reasonable, that allows for= exposing > > > > > more things without walking the page tables. (e.g., flags) > > > > > > > > > > Maybe one could have an indicator that says "ever had guard regio= ns in this > > > > > mapping" without actually walking the page tables. > > > > > > > > Yeah this is something we've discussed before, but it's a little fr= aught. Let's > > > > say it was a VMA flag, in this case we'd have to make this flag 'st= icky' and not > > > > impact merging (easy enough) to account for splits/merges. > > > > > The problem comes in that we would then need to acquire the VMA w= rite > > > lock to do > > > > it, something we don't currently require on application of guard re= gions. > > > > > > Right, and we shouldn't write-lock the mmap. We'd need some way to ju= st > > > 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 w= ith > > Suren's work with VMAs allocated via SLAB_TYPESAFE_BY_RCU, putting the = lock > > 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 espe= cially > > > for large ones (including when they are split and the indicator is wr= ong), > > > 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 abou= t VMA flags > > > > implying differences in VMAs in this one instance (though we do alr= eady do this > > > > for VM_SOFTDIRTY). > > > > > > > > I saw this as possibly something like VM_MAYBE_GUARD_REGIONS or som= ething. > > > > > > Yes. > > > > > > -- > > > Cheers, > > > > > > David / dhildenb > > > > > > > Best, Lorenzo