Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp514414ybl; Thu, 23 Jan 2020 03:01:02 -0800 (PST) X-Google-Smtp-Source: APXvYqwE0UJ3UO1aHGSgj2dawwUiWMlHds7FO3nZj8R5qzPVnReLomuYSCpUPEobGSg3s+ERhkLv X-Received: by 2002:a05:6830:1615:: with SMTP id g21mr11142315otr.49.1579777262770; Thu, 23 Jan 2020 03:01:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579777262; cv=none; d=google.com; s=arc-20160816; b=cnJ4X+wKWTCgdO7d2sSSIpdMn+l5eQVAkZTaWhoF/uDOsZeiSQNWixCZte189DKRrH uwg3wHEph2yq2WULCfXENFPi64UawpYxjjrX+BHXO95j4xbltA4T1/7TypmtPbI+wxSU clzJnMWf/EO0qypkNFzNvW2W0PsqsB/tJc9PU1bMPN4oTgsAJyeU8jvO3RYhG1+Uskav S2fyWZhxdYgUvOWuH6PgSQ5kdbCozhbhfP+JDSBXtyatDlfzVDjtZuFUVmLh57Zu0GsE AQadxtWynjzx14v86ArYEiGyQcxCdysGXfpJ6N0vb9SafOCGypGN95ERYjg3K71T/qz1 aQgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=HLfndF9RAt4g+AGkbC5qXfhi2W5ru43lrY+OrFwE77c=; b=eeVooe9+pXvzgabEToSzRGka28AqtjdmkmIvBVKMLulhf4akwEgVVmemWnr0EsSkYk Q31RRlDPGoak1pMhsCStq/RAiqpN6flWUB+lLTX8SQqKphrdspauZJn65XQ2uCqPvUKE WQXSY4Mo4PsD+KppWgBcC8sB3hxj0dF0hhFpVlnpBXNVlhFrpSsWsdiI8hhWKd/U7Vwv lFKX+Rjqtps20NG9IYVeY/0N5NLBAuSSAVfnHBa0OcHzN/ncpTI5XMawi6WlaB4tcNw+ iYjCNVQlTyCXyLVqhtoGA4WPbsinm/jMZ4kOuRV8jS/TVHnDvnxBW3GsKLQDGGgHm/LL FsUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=HSStN14F; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 65si811580oif.14.2020.01.23.03.00.50; Thu, 23 Jan 2020 03:01:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=HSStN14F; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729159AbgAWK71 (ORCPT + 99 others); Thu, 23 Jan 2020 05:59:27 -0500 Received: from bilbo.ozlabs.org ([203.11.71.1]:34149 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729108AbgAWK7Q (ORCPT ); Thu, 23 Jan 2020 05:59:16 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 483K5r5snRz9sSQ; Thu, 23 Jan 2020 21:59:12 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1579777154; bh=HLfndF9RAt4g+AGkbC5qXfhi2W5ru43lrY+OrFwE77c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HSStN14FpEBPLwZGlx8oA+ZZNFfWdzHQErga4zK0XJhZfzP21D9wVvy2nuua2Mcro coc6kYH0eO3TodIQoXW3uHMTv0a3Qpku4sXMmh6C1rqkRglSS/MAUic6YqP0/byH0G ZJ7pawYuL1pjqPlF2vm4ykwCpFBmFOSc0iYPFqJZo0mEpsJQ76+wJbrBrKrEo9nmNs ZgSBsLMbn5gSujjwiM9+A2Ut5yJUmDY0rLKA8hcDKkIQJCPsjUpvQ3nRRKQRMY/OPV I80FJuKhnIDrVr9c3L0OKrBKo50KaQQi2hgOJyv7mbq1cJ3kvDlZyYKoDIRW7yeq51 dxF8E/uUq8TlQ== From: Michael Ellerman To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 5/6] powerpc/32s: prepare prevent_user_access() for user_access_end() In-Reply-To: <824b69f5452d1d41d12c4dbd306d4b8f32d493fc.1579715466.git.christophe.leroy@c-s.fr> References: <12a4be679e43de1eca6e5e2173163f27e2f25236.1579715466.git.christophe.leroy@c-s.fr> <824b69f5452d1d41d12c4dbd306d4b8f32d493fc.1579715466.git.christophe.leroy@c-s.fr> Date: Thu, 23 Jan 2020 21:59:07 +1100 Message-ID: <87pnfaiglg.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > In preparation of implementing user_access_begin and friends > on powerpc, the book3s/32 version of prevent_user_access() need > to be prepared for user_access_end(). > > user_access_end() doesn't provide the address and size which > were passed to user_access_begin(), required by prevent_user_access() > to know which segment to modify. > > The list of segments which where unprotected by allow_user_access() > are available in current->kuap. But we don't want prevent_user_access() > to read this all the time, especially everytime it is 0 (for instance > because the access was not a write access). > > Implement a special direction case named KUAP_SELF. In this case only, > the addr and end are retrieved from current->kuap. Can we call it KUAP_CURRENT? ie. "use the KUAP state in current" cheers