From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-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-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*i:sk:1581525, H*f:sk:1581525, Magalhaes, Lucas 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 17:17:00 -0000 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 X-SW-Source: 2020-02/txt/msg00516.txt.bz2 * 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 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? 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