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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 029CD1F45E for ; Wed, 12 Feb 2020 17:17:31 +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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=xAd0/f7dJiaNybvvo4tv88SsErhazWnaJEjwCEVee1J qiGkakmDY0XsHWGgxVFxTKg+Ov2OpHzGTh8XwKpuOac1kKVxrIs5q1i2nu5dYMq5 jPNgG9r94TpdtMhuJf+DnvcEV1AEe0KjOBNtBOeOKOhz/ntiUA97DRCmwLkTzWgo = 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=4jUxGa3Zzvjl3Mb01F1hpjfV654=; b=mNDSr28Ztr+a3xaYj sxV9RKTtvlfy5OlStQjzFjA8GqfDhX2aaDC5KVwG6ZBgKDyK0zhePG6eIR59+N76 w4Wj99y8WC+cFnmaiU/hgjJVt4lNm10JC6N1wVMOC1+Fpr7/Qbh6c5pHtTdylaVY n8L6VN5nqar2wxwWee1OOi/79c= Received: (qmail 29688 invoked by alias); 12 Feb 2020 17:17:29 -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 29666 invoked by uid 89); 12 Feb 2020 17:17:29 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-delivery-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581527845; 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=zZFLCsxqvB0e8cVrsRf4S9fUkX8zup3rpG6TcjehVhY=; b=hF2Gs1xHsdRbnGtu7XIUMhpcn+Czserknqb9UgSTdSYLlP+w8+7Ars/3t8X5o9+ALlDJkw mXCLvtp3TiCrTcje2jtj478QH8dXPiF7cBaj9GN/cnsJU09rUhOv2kwwOXPtudJcVx/j0/ g4kpAwEjXtH687+29Bk8raJicfBoPXQ= From: Florian Weimer To: "Lucas A. M. Magalhaes" Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] Fix tst-pkey expectations on pkey_get 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> <158152595856.31885.18040915151106001420@localhost.localdomain> Date: Wed, 12 Feb 2020 18:17:12 +0100 In-Reply-To: <158152595856.31885.18040915151106001420@localhost.localdomain> (Lucas A. M. Magalhaes's message of "Wed, 12 Feb 2020 13:45:58 -0300") Message-ID: <87eeuzendz.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable * Lucas A. M. Magalhaes: >> >> 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 = all >> > 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. Option 2 is fine with me. >> >> 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 signa= l >> > 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? For now: 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. It was a kernel patch: Thanks, Florian