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 2DF6EC38142 for ; Wed, 1 Feb 2023 09:03:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 87F8E280002; Wed, 1 Feb 2023 04:03:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 83010280001; Wed, 1 Feb 2023 04:03:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D141280002; Wed, 1 Feb 2023 04:03:48 -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 59D8E280001 for ; Wed, 1 Feb 2023 04:03:48 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1F237AB422 for ; Wed, 1 Feb 2023 09:03:48 +0000 (UTC) X-FDA: 80418135336.06.C1E4286 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 6A9CC20021 for ; Wed, 1 Feb 2023 09:03:45 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VHieKH+8; spf=pass (imf13.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675242226; 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=a8vyRUGLmPZw1cx7uiPTXStMX6sS7pJs7SRmtCoOPQ0=; b=tT1qSBncu2r3SB6Rb3i+vYeGAQ6Wi2TRa0c7TnvI++9qpudXUWfrqUSpBQlw4Czbf2wr8G ZvEaSxRpobPLLgEp4qvrEWVWeBq/Kdlw57rDKdUvphwnXvWArNS1otH72YvbQ89z4tA9Zz UWo3aRW66ZzrR5T2wfeXjftoWdey5JU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VHieKH+8; spf=pass (imf13.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675242226; a=rsa-sha256; cv=none; b=Q5c8B46UWVGi0RipBKaOPoNByxPz6XP3i839ijdwGN7Ojfz0mfl1qFnCaRWqyABJvK8znY URXJM6f5w+dIGwz9RYsVtYdoPWXuG/vqaDuTfFVjQT35D/PJA448HcCIHCH1EtvCQdHBZs 9ArZxQ8HiZkjrBXQdtA28XSTqXV6ymE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675242224; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=a8vyRUGLmPZw1cx7uiPTXStMX6sS7pJs7SRmtCoOPQ0=; b=VHieKH+81BnrFUUaC40Fh+X+C52Lobd6CfII0YiBk6Kyyk/Ym5fzUpzk6es+KP9/QwbLqX NNcO2ePOniaa96rXu0/ioxW1PRLRycWVQAWLrFVSWisHoJcMspJIt5mfOMeQ7dmY0Y7Dpj dD8RkD5Wde67VvAIbnWZ+FrpvnJaHso= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-397-NVV-nM4kP7OhyG2Rv6H6fA-1; Wed, 01 Feb 2023 04:03:43 -0500 X-MC-Unique: NVV-nM4kP7OhyG2Rv6H6fA-1 Received: by mail-wm1-f71.google.com with SMTP id l5-20020a1ced05000000b003db300f2e1cso694243wmh.0 for ; Wed, 01 Feb 2023 01:03:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a8vyRUGLmPZw1cx7uiPTXStMX6sS7pJs7SRmtCoOPQ0=; b=DBfCzPDxNe4vdpeqgapz94/z8gM8IFAC6tRUWMH+IlcbI0JOHyIF0GRrt9wbSmZp0x S7aweu/HhB4b3ZBkecCjTqyjfvhew0szhf2jKokic/qph+rG+cpXx4NV2Gfz4g6iArn3 esqy8AZXfF3iOC9nWRf1Fl7iRD3N/nwy8Q/hca3M7AZn/T9Pv6Z04kbzkUbYRh2Y0/pB zfT4JejBg+L40H7d4ZiX+vGrMabDc/z6BzGcxF4sJ4/HRtT9pFAmTEgd3ckY/oD98FGp PPpHgAC+KzcMtNrgaa/dFVJGfX8E9RwaVOsELy9dwlEGc6ea67rxMHWUb7NFMPMjBAII PUqw== X-Gm-Message-State: AO0yUKXno0dcR49zTYRRIeIYuvkSCKsjF1FcN8AGyWh351wsaRyzI/T6 ABd7ChPZBOCGa1nzafcluuNB5lrukEjw9TOxtDC8/3P/pyVYL8aRZNl7Q7P/1Rm/le5B0qv1lCk TajtQ0G7/pv4= X-Received: by 2002:a05:600c:3b9d:b0:3d2:3be4:2d9a with SMTP id n29-20020a05600c3b9d00b003d23be42d9amr1322238wms.20.1675242222459; Wed, 01 Feb 2023 01:03:42 -0800 (PST) X-Google-Smtp-Source: AK7set/gMluqZSQ5LKXrgZW/yePv93crC07VbTZ6hjsNCTASxrv++pCMxw86gG10oZFOIcmNhL6zeQ== X-Received: by 2002:a05:600c:3b9d:b0:3d2:3be4:2d9a with SMTP id n29-20020a05600c3b9d00b003d23be42d9amr1322185wms.20.1675242222113; Wed, 01 Feb 2023 01:03:42 -0800 (PST) Received: from ?IPV6:2003:cb:c705:3100:e20e:4ace:6f25:6a79? (p200300cbc7053100e20e4ace6f256a79.dip0.t-ipconnect.de. [2003:cb:c705:3100:e20e:4ace:6f25:6a79]) by smtp.gmail.com with ESMTPSA id p16-20020a05600c469000b003a84375d0d1sm1100168wmo.44.2023.02.01.01.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Feb 2023 01:03:41 -0800 (PST) Message-ID: Date: Wed, 1 Feb 2023 10:03:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH v5 18/39] mm: Handle faultless write upgrades for shstk To: "Edgecombe, Rick P" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "fweimer@redhat.com" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "pavel@ucw.cz" , "andrew.cooper3@citrix.com" , "oleg@redhat.com" , "Yang, Weijiang" , "akpm@linux-foundation.org" , "Lutomirski, Andy" , "bp@alien8.de" , "jamorris@linux.microsoft.com" , "hjl.tools@gmail.com" , "tglx@linutronix.de" , "Schimpe, Christina" , "x86@kernel.org" , "mike.kravetz@oracle.com" , "linux-doc@vger.kernel.org" , "arnd@arndb.de" , "john.allen@amd.com" , "rppt@kernel.org" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" Cc: "Yu, Yu-cheng" References: <20230119212317.8324-1-rick.p.edgecombe@intel.com> <20230119212317.8324-19-rick.p.edgecombe@intel.com> <7f63d13d-7940-afb6-8b25-26fdf3804e00@redhat.com> <50cf64932507ba60639eca28692e7df285bcc0a7.camel@intel.com> <1327c608-1473-af4f-d962-c24f04f3952c@redhat.com> <8c3820ae1448de4baffe7c476b4b5d9ba0a309ff.camel@intel.com> <4d224020-f26f-60a4-c7ab-721a024c7a6d@redhat.com> <899d8f3baaf45b896cf335dec2143cd0969a2d8a.camel@intel.com> <27b141c06c37da78afca7214ec7efeaf730162d9.camel@intel.com> <6a38779c1539c2bcfeb6bc8251ed04aa9b06802e.camel@intel.com> <0e29a2d0-08d8-bcd6-ff26-4bea0e4037b0@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: 6er5gh9qoa7gzoix3ha6crsr3pw77uu1 X-Rspam-User: X-Rspamd-Queue-Id: 6A9CC20021 X-Rspamd-Server: rspam06 X-HE-Tag: 1675242225-425181 X-HE-Meta: U2FsdGVkX19+Q5u3SKrwSyxxBimEqcveqYU++XqYHGNgjgcUPqUit+S6b1kREDX3eQoS2RBMTJdtfZQhyKjd6D3eoW8x13tfEuDV9KekPcDWsbnU+B8DEagDZUg4Ldud8JqbdMBL2wwW5zKpPHDkxzOfsvJhAHIGvFQ/B34ErBoXb6LoP2xy6iCsaDKkNhfb5ShqOgLtPWusQ3vNfWhZiaMtWKXwWrQPFn8Owh08t33ISwpPUYheYxJpI3QjwmnTH2FYiU+9dTgUtzbw9T7jBPehzrCwxrPcbP4R9p/xoI9RVHUul7ksOuNjwuP4lpE1MQZc1Wc9IPwsfJNEe9HHpI0G1TA503vkp7PI11f0CTnph3LeaFP5r14bqunNIOBl9x+Fc/fPBEa+KPMm4SIwWCz1wgEF7BOleCqB2tUNAW9rlWad05oDWSaEa3V02QsGzldeFWrSGWLZ4VE0qRPNACwcd1BzrIOfmUaYmF++2iPsU9XmjGdarQwHI/XdffsYBBns/upWM5E3S6nYlQyXfR9xsrXZJQjzzitScQocM5zqq20AA2wLLmVjNjVpxKpndD+3/tOWYjj+cvjpcpmVOhPIquxxznwDrpK0LtI6BLN3Cmb5rdV+yLsqPcQrtEwlkKEzgBX3KRyfO8+JQpBk9+mV+zpwDIrDxIvLJdqCvU1xw82zhCtfhFlvCqLmWCQ8Crdx14tfmO/9BHg0eCXA4D2QOwKszmkEPMIyGx2i/i/OrLQ/TalTbG+XRvnoMrvtf8VRCeMD5ysQ/OHg3I72HrVDi1JHIElc3rff8GRYR+LwEQRSz1itTz6iGKPJQZ6ltb0xo3PyJDP+FZLIVinCXA3PewPzezW8d1ZWit29WSM/TR49ERu36riB/DxaEoVRTP/EaObfj6amHanqKo/6rFuUxoaYvfTeHehp5i7XQ+wn4UXosFUAnruG6WjCOZBwu6rikDiqMScnwZcGZf8 7CyShAI3 vvoU5jy8h/VUAfhAGtsjptivQs/p+EkThNItqJgGFpA6fMnt6z3Mo9wo+K6EUFW/cTsUWHznWh76nVCnYbgQnb/m7lykjMcEHC4o8bn9CBF+qV+xDZcrqdHK4VWzpH/X4RrErrJAOqekAdhJyEX+oD4NIQ7GdpSh0ulQcImh7hSh3+dIiuDVE7Plgi6x1NfWgrvF/S6OkpHkuQcDWjsW+qPgETIU38E/7QmUI0jYWi0etFDvgMvw7+WHGOn78ZH0iQ5fMfJLi1v8qyAo7vaqvBL9GOgny9Qh3hwr6vAfYLHHDYJvY/F6WGgQSj2330ZWaJXH96HhdGAHAtZGrPJBnrKETrAsnRjLryzJ+xJsOT1uwlt77JfxYoxF5ByztKWduo+dXK+Ilz0HPuSDJsuGK+l/HGwbsSB6Xbl/miHvpRr8SHKgkFCiUFl4T1ptQKa0QNZ4LUThZGxsg3d0lpmNENlqkMdvnVo8opYcXfJ9h+2vwpvAek8ucVkkVvIvTVU9b4RS0 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 01.02.23 00:33, Edgecombe, Rick P wrote: > On Tue, 2023-01-31 at 09:46 +0100, David Hildenbrand wrote: >> Sure ... >> >> but I reconsidered :) >> >> Maybe there is a cleaner way to do it and avoid the "NULL" argument. >> >> What about having (while you're going over everything already): >> >> pte_mkwrite(pte, vma) >> pte_mkwrite_kernel(pte) >> >> The latter would only be used in that arch code where we're working >> on >> kernel pgtables. We already have pte_offset_kernel() and >> pte_alloc_kernel_track(), so it's not too weird. > > Hmm, one downside is the "mk" part might lead people to guess > pte_mkwrite_kernel() would make it writable AND a kernel page (like > U/S=0 on x86). Instead of being a mkwrite() that's useful for setting > on kernel PTEs. At least I wouldn't worry about that too much. We handle nowhere in common code user vs. supervisor access that way explicitly (e.g., mkkernel), and it wouldn't even apply on architectures where we cannot make such a decision on a per-PTE basis. > > The other problem is that one of NULL passers is not for kernel memory. > huge_pte_mkwrite() calls pte_mkwrite(). Shadow stack memory can't be > created with MAP_HUGETLB, so it is not needed. Using > pte_mkwrite_kernel() would look weird in this case, but making > huge_pte_mkwrite() take a VMA would be for no reason. Maybe making > huge_pte_mkwrite() take a VMA is the better of those two options. Or > keep the NULL semantics... Any thoughts? Well, the reason would be consistency. From a core-mm point of view it makes sense to handle this all consistency, even if the single user (x86) wouldn't strictly require it right now. I'd just pass in the VMA and call it a day :) -- Thanks, David / dhildenb