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 391371F5A2 for ; Fri, 7 Feb 2020 18:22:30 +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=JPPJJMujMfp4xtq8kyT+DKnlOjQ4oAHGvzuJfjwr44a z/jpR7lttv/yRU9LeOKf4O2MGdCQm3sW2X6IKTDZDFVXDnk0Osw8wQ/L0uIUPudZ kY18U7nmU9l2K7NVZbAoRnv1FadReHQE2W1Im8J/9tQzYx6TRGCDLHjxZHFxghF8 = 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=Oe8jP+MUsNUGWgZ0e7adkzfvzmI=; b=GwcRHpUU1bD8YZGvN fDuWSmEBUlIvQD97/zpt6piuuYuLmUy5WSAgI3XbM1HRtN1JR14THB064STkNAns VovEne+ABhou1EwfT5EfDX2rgnh2E8xfbkOcDs5eygDHoqwUpFnBJZGww4/cRqJK 674zzvzXP1WTcejQkXdeIWF4ts= Received: (qmail 87502 invoked by alias); 7 Feb 2020 18:22:27 -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 87483 invoked by uid 89); 7 Feb 2020 18:22:26 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: us-smtp-1.mimecast.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581099744; 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=XdTkkan4pkxQuLjQmvxLUr8kZ2MY84xaDSvssYDJF8k=; b=ehtBqTjjQ3v8J2Z5shCSHdPGXa1MU61cjByZJPHnkNWhENkZ0xodi6VTWSOHpJ8G9+VVBv 8qcWjttghWoWKRmzUIBt38w4zNN5O7zh7dQ/i9inNNthdW+KOgF2X15/ZkiG21cmVCIWye aBI2adS4QUn3MZJg/EimFA7rPReuQPA= 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> Date: Fri, 07 Feb 2020 19:22:16 +0100 In-Reply-To: <20200207134604.29046-1-lamm@linux.ibm.com> (Lucas A. M. Magalhaes's message of "Fri, 7 Feb 2020 10:46:04 -0300") Message-ID: <87wo8y45rb.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable * Lucas A. M. Magalhaes: > Florian, Your patch including pkey_set and pkey_get looks good to me. > Can you merge it? This one > https://sourceware.org/ml/libc-alpha/2018-05/msg00760.html. Thanks. Is the patch really correct for 32-bit userspace? > With this there will be one failure on this test on powerpc machines. > The test expects that during a signal handling the pkey_get returns > PKEY_DISABLE_ACCESS for all keys. In my tests it returns the same > permissions as before the signal. I couldn't find where this is done for > x86. Is this kernel implementation? POWER has read-disable and write-disable flags which work independently. The kernel-defined flags cannot represent the read-disable configuration. At the time, there was no read-disable flag allocated in the kernel. Has this changed? (See the =E2=80=9DTranslate=E2=80=9D commen= ts in my patch.) 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. Thanks, Florian