From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id EA21F1F45E for ; Wed, 12 Feb 2020 16:46:13 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:content-type:mime-version :content-transfer-encoding:in-reply-to:references:from:subject :to:cc:message-id:date; q=dns; s=default; b=OHCkIln0bdnlvSvTYU/E CkKH5Htc0aniJQVronyD2BGCZ2/8wG9irlOhXFuWlmDuis24fqcgb/Y5xn+0qacn kNujpcHEE2lPOjkXIiFO4QLfKZ+QEmO5XfbzydV2WQsKDFcZ3MHbRGXH3VSypTU9 D0UOBCckv9hBYQDIVwKjjSk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:content-type:mime-version :content-transfer-encoding:in-reply-to:references:from:subject :to:cc:message-id:date; s=default; bh=bTKBlm0RYS8tvDzFNCQWXpqFup 8=; b=MH0vDmtWtZVZvXCKLHqPDjzu/BdLV9r4C+xzVrwcQsrw2zFkpDYX8xZccw 6VJS93Pyyrtggw9Gt/0xVit/KbtGYduyTRpDrVKDMrv9Tj9mamABYUnehorg3l61 NRy/SMP77zLQC8V2Z7zh9lsHEvIqLl4E0miGMvBVrUKfMfBY4= Received: (qmail 51036 invoked by alias); 12 Feb 2020 16:46:10 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 51013 invoked by uid 89); 12 Feb 2020 16:46:09 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx0a-001b2d01.pphosted.com Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <87sgjhhzs6.fsf@oldenburg2.str.redhat.com> References: <20200207134604.29046-1-lamm@linux.ibm.com> <87wo8y45rb.fsf@oldenburg2.str.redhat.com> <158142979256.10397.17115376921242536449@localhost.localdomain> <87sgjhhzs6.fsf@oldenburg2.str.redhat.com> From: "Lucas A. M. Magalhaes" Subject: Re: [PATCH] Fix tst-pkey expectations on pkey_get To: Florian Weimer Cc: libc-alpha@sourceware.org Message-ID: <158152595856.31885.18040915151106001420@localhost.localdomain> User-Agent: alot/0.8.1 Date: Wed, 12 Feb 2020 13:45:58 -0300 > >> Thanks. Is the patch really correct for 32-bit userspace? > >>=20 > > > > Thanks for pointing it out. Even in 32-bit mode the mtspr will effect a= ll > > 64 bits and there is no 32 bit limitation for AMR. I will try to setup > > a 32 bit userspace machine with pkeys enabled to test this out. >=20 > Thanks. We may have to tweak the constraints a little bit, though. >=20 Actually there is a problem in this regard we may encounter. We cannot ensure that in a context change the upper bits of the GPR will remain the same. We could either 1. Restrict the usage of the upper pkeys on 32bits. Maybe the kernel already restrict already on pkey_alloc. 2. Make it ppc64 specific. > >> On x86, the hardware has write-disable and read-write-disable flags > >> instead, which matches the original UAPI interfaces. This is why no > >> translation is necessary. > > > > Excuse my ignorance. How this translation problem influences the signal > > handling behaviour? >=20 > The signal handling behavior is just different. If I recall correctly, > x86 always resets PKRU to a mostly-disable value, while POWER inherits > the AMR value from the interrupted thread. The POWER behavior seems > more useful to me, but that depends on what the programmer tries to do. >=20 What do you suggest for this. To change x86 behavior or too change the test to accept both behaviors? > I think I have posted x86 patches for changing the behavior, too. >=20 I could not find it.