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 D0952C3A5A7 for ; Thu, 8 Dec 2022 15:17:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B46E8E0005; Thu, 8 Dec 2022 10:17:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 251638E0001; Thu, 8 Dec 2022 10:17:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F21068E0005; Thu, 8 Dec 2022 10:17:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D89788E0001 for ; Thu, 8 Dec 2022 10:17:35 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B99DA80ED6 for ; Thu, 8 Dec 2022 15:17:35 +0000 (UTC) X-FDA: 80219493270.26.9CB8C58 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id A729910001B for ; Thu, 8 Dec 2022 15:17:33 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UnqpZvUt; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670512653; 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=1TCrGY30xtqKhvpkZ91gzI+bfZZQwx6XMMEYmjyVbA4=; b=yoGFU2BUQEN4wkpNly5W+TS0Jr6zBd+kHwySsAQ2tW/WdeSDGGDhpvxo77sPBGMQiECO5I bocRJb7v7kEYEZcjRyPiIjKV3uXtPcJFwTiS5fwRgo9MJ5IqThbny+bLBbn6Mo1DrNdoK7 vxF40nl/Yh8AA5kR9gmb/EicuvII8tE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UnqpZvUt; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670512653; a=rsa-sha256; cv=none; b=BoO57Wd2PEbUZD9OPIwSXVpq4P4Ms1F6R7FftbdfuxF/Mxf0CGQ+vDFBL/zqk4ZnLc254+ toXea2MZMAz10VgxU6P1gxQc2eEeQbeCXpITpSRwQqLbLxRZOxdpCEcUBlz3ZSufpioBnQ 8JAEnCijRcfSTaE520hlugd0xnTd6Xk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670512653; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1TCrGY30xtqKhvpkZ91gzI+bfZZQwx6XMMEYmjyVbA4=; b=UnqpZvUtIHuG2xz3v3hwW4v1jCjv4W6YDqPFoyZ/fmmgQngp5BWkrLtmsX7DyScWASsGUL 5zPhUhHKkkQpc/c1OxYM+bRtY1O644RP8LDVJCDwTzn0u/uZwsdnbvt/HL3ZSqI4vfOh9P Y58p8dqO1elz/h4vTvEcSOR1wfgLtQY= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-332-BIM8HaVtN_eANiXxPQm9GQ-1; Thu, 08 Dec 2022 10:17:31 -0500 X-MC-Unique: BIM8HaVtN_eANiXxPQm9GQ-1 Received: by mail-qk1-f200.google.com with SMTP id s7-20020a05620a0bc700b006fcb1a3bb9dso1722692qki.15 for ; Thu, 08 Dec 2022 07:17:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1TCrGY30xtqKhvpkZ91gzI+bfZZQwx6XMMEYmjyVbA4=; b=BrsbpACjduCI36ppuH9sdZnY+Ljeci+bn1PPbQYU1ZMYYHOPoAtNNo5rUOxfym7Bs0 8hNNUU+SIKugd16vTrYYqQhfOshoEinMnRoRUxfyJyO6lAEQl8tq8/rP0KuccxzoFwlB 2jPOR5YVJm3MHq4eKDhvY98ZAJqoKwU1Tit3/cjNrg3eqGPtp2b/hO0lyf49GiKcLlmt qOdOF1g3YPiwqqg6WAppo0jfyGUH3h+zLvR4mv7vyR7JDLYEvMdiY/Ie6bL5AXOMW8n6 fZOX5sWIH233oIfMsPqQkWRmAdisgwr63ZnVo1lgdN6BUifvlkZrfI2gCPOM5A/qwaE2 HY2g== X-Gm-Message-State: ANoB5pnmpYZwEconZmFUutCbdyunkuq6S2EOOnX3aUNs+jfFyeZHzGAr HbAwLkqyvwfO2p2Y9IkH9GE3wDwSdIDj2MLNdLbNeDN0rLTaepC6ccKOuQcfyz+YimnXlzg1I8p 2989j/2jgMtI= X-Received: by 2002:a05:622a:4a17:b0:3a5:3c5e:7b67 with SMTP id fv23-20020a05622a4a1700b003a53c5e7b67mr3659180qtb.37.1670512651095; Thu, 08 Dec 2022 07:17:31 -0800 (PST) X-Google-Smtp-Source: AA0mqf7xIQ66ISuHWGhfM3iVFJxH0myy6pVHyIzFHhJhtBI9sCg9WI0NXgOhibs7AlkbCRvBltMwCQ== X-Received: by 2002:a05:622a:4a17:b0:3a5:3c5e:7b67 with SMTP id fv23-20020a05622a4a1700b003a53c5e7b67mr3659149qtb.37.1670512650788; Thu, 08 Dec 2022 07:17:30 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-46-70-31-27-79.dsl.bell.ca. [70.31.27.79]) by smtp.gmail.com with ESMTPSA id c4-20020a05620a268400b006ec62032d3dsm19471430qkp.30.2022.12.08.07.17.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Dec 2022 07:17:29 -0800 (PST) Date: Thu, 8 Dec 2022 10:17:28 -0500 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ives van Hoorne , stable@vger.kernel.org, Andrew Morton , Hugh Dickins , Alistair Popple , Mike Rapoport , Nadav Amit , Andrea Arcangeli Subject: Re: [PATCH RFC] mm/userfaultfd: enable writenotify while userfaultfd-wp is enabled for a VMA Message-ID: References: <20221202122748.113774-1-david@redhat.com> <690afe0f-c9a0-9631-b365-d11d98fdf56f@redhat.com> <19800718-9cb6-9355-da1c-c7961b01e922@redhat.com> <92173bad-caa3-6b43-9d1e-9a471fdbc184@redhat.com> <5a626d30-ccc9-6be3-29f7-78f83afbe5c4@redhat.com> <53e52007-e556-332d-ec4d-5fe48a90e9b0@redhat.com> MIME-Version: 1.0 In-Reply-To: <53e52007-e556-332d-ec4d-5fe48a90e9b0@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A729910001B X-Stat-Signature: qtuncebjx1xsgm5kg1schws843c4oah9 X-HE-Tag: 1670512653-648925 X-HE-Meta: U2FsdGVkX18bCNljLZeDfS7n+FIfPABdfSjZ80Jn/NdTZBgvE5Mv7WDCwu0yPL7zbdSjYXUmJbFBAId7YfOQd8j9E+CgnDayYgFuf4ss4jr7DdQmBBeO4P3yl+UHhdQs8JjIPGnclJq3u8Zvjnq8sRPGZY4mirNEAKASjmADar6Zxeg7A1D545KRnHCHHBEAAcNAFQ2MUg2QHmbfC6ecJ14+Hsz7pzOp5FJjFG2PZDCFnwOukctfbDkqwS3w/LtbuKmnHiOmOFzHKY16zTEFwBIMVp0h4yFjU8gU4O2h3MXWIqdvYMhnAsd+NzMwclpcq60CEVMnwA08OGyMuPb8X8qYKEwJMGlicAQsVIlt+XOeNDShVYVlSpdnf4JMiECi8MrvFmsMNkt4ND6TqUV3xoYvHIeDN89HG9a3MAQQuXXDHTbkFe1EBuMECRHH9krWKNTPrpwBIYR27bwOH3fOdXxm88c31eyR97d1golWgnurU366XI/4iBCmuz8WGkrKbLsuRQ5//oLNgCXj8nXh2OifMaUA9qedf9K9lCBW9V2jPGAc6/127NBWx40qekPxkE1r0huvr8kqGELoHROj1zUWeO74yEuilT8q7x6dEjPDkmVfapMxxmSD3io0fQwXzdyAPbn4i5NzfvAoh+LLVmOgISYFEMqic9bY/BJFOwQxu4c43MJM+glTvUafWDz+pZq+eUpdcgnJ1ScazwZaV6oOpKFot+TnjOgsMpkZ7k4DtL3G3bghg9YZ2tK7BQPPkHIZJtwp/KECBVwWZm12Lu0wYUmwJ+pIY6lxGIA+bGYsDBSADM+A/o3ps+Bjb1gm9BqtlvTWO6IRYACS2Ym5p8zdpSC6G00C6NkNf6Pm8iEghC1xMZEKF+t+xbVCK8fRQsbfn53Xfd86NO36sNHRstBWjuhVH+mqcrFh5TkMSUYXzj0ncxWK3iEKoBy+YeWo/rMtWfZEquCInsgPhF7 wjd42d3l 0xIgVWSM65QGEriSlSU+1cKpiYgYLRg/t3mzjqv/0m8tf1L59t9bRPO4+FvPmsjl6z//Iv0sC1aq7/S4tKaucs08Y+ot0HeV4wDDom6AS1whhSTcPI8YmAm1uBQbg9o+WUL2TqZuIUUr3PxnGgD5A/ihXW+W5baqNhRxl7rHUf2VMEAzsqR/T3fO2/Q== 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: On Wed, Dec 07, 2022 at 09:10:41PM +0100, David Hildenbrand wrote: > Now, my 2 cents on the whole topic regarding "supported", "not supported" > etc: > > (1) If something is not supported we should bail out or at least warn > the user. I'm pretty sure there are other uffd-wp dummy users like > me. Skimming over the man userfaultfd page nothing in particular > regarding PROT_WRITE, mprotect(), ... maybe I looked at the wrong > page. > (2) If something is easy to support, support it instead of having all > these surprises for users and having to document them and warn the > user. Makes all these discussions regarding what's supported, what's > a valid use case, etc ... much easier. > (3) Inconsistency confuses users. If something used to work for anon, > in an ideal world, we make shmem behave in a similar, non-surprising > way. > (4) There are much smarter people like me with much more advanced > magical hats. I'm pretty sure they will come up with use cases that > I am not even able to anticipate right now. > (5) Users will make any imaginable mistake possible and point at the > doc, that nothing speaks against it and that the system didn't bail > out. > > Again, just my 2 cents. Maybe the dos and don'ts of userfaultfd-wp are > properly documented already and we just don't bail out. I just don't know how to properly document it with all the information. If things missing we can always work on top, but again I hope we don't go too far from what will become useful. Note that I never said mprotect is not supported... AFAIR there is a use case where one can (with non-cooperative mode) use uffd-wp to track a process who does mprotect. For anon uffd-wp it should work already, now this also reminded me maybe yes with the vm_page_prot patch for shmem from you it'll also work with shmem and it's still good to have that. In that case IIUC we'll just notify uffd-wp first then with SIGBUS. Said that, it's still unclear how these things are used altogether in an intended way. Let me give some examples. - What if uffd-wp is registered with SIGBUS mode? How it'll work with mprotect(RO) too which also use SIGBUS? - What if uffd-wp tracks a process that also use uffd-wp? Now nest cannot work, but do we need to document it explicitly, or should we just implemented nesting of uffd-wp? - Even if uffd-wp seems to work well with mprotect(RO), what about all the rest modes combined? Uffd has missing and minor mode, mprotect can do more than RO. One thing we used to discuss but a slight different case: what happens if one registers with uffd missing and also mprotect(NONE)? When the page accessed IIUC we will notify SIGBUS first instead of uffd because IIRC we'll check vma flags earlier. Is this the behavior we wanted? What's the expected behavior? This will also be a different order we notify comparing to the case of "uffd-wp with mprotect(RO)" because in that case we notify uffd-wp before SIGBUS. Should we revert the order there just to align with everything? Sorry to dump these examples. What I wanted to say is to me there're just so many things to consider and that's just a start. I am not sure whether it'll be even worth it to decide which should be the right order and make everything very much defined, even if I still think 99% of the people will not even care, when someone cares as a start from 1% then 0.99% of them will find that they can actually do it cleaner with other approaches with the same kernel facilities. What about the last 0.01%? They're the driven force to enhance the kernel, that's always my understanding. They'll either start to ask: "hey I have a use case that want to use uffd with mprotect() in this way, and that cannot be done by existing infras. Would it make sense to allow it to happen?". Or they come with patches. That's how things evolve to me. These may be seen as excuses of not having proper documentation, personally sometimes it's not easy for me to draw the line myself on which should be properly documented and which may not be needed. What I worry is over engineer and we spend time on things that may not as important or more priority than something else. Going back - the solo request I was asking to not use a mprotect example is mprotect is really not the one that the majority should use for using uffd-wp. It's not easy to help people understand the problem at all. That's all for that. Thanks, -- Peter Xu