Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2131427imm; Thu, 18 Oct 2018 09:29:41 -0700 (PDT) X-Google-Smtp-Source: ACcGV61HIH1nmxObhsoCxWGlTI/PF+k9aC/pcVS2bD5WueK3FCOR3DLjvuuqDMrLc3S/6iNmdig9 X-Received: by 2002:a63:88c1:: with SMTP id l184-v6mr28515703pgd.431.1539880180984; Thu, 18 Oct 2018 09:29:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539880180; cv=none; d=google.com; s=arc-20160816; b=XzO85LAYrBYZCIfKcJLQYS9eHh3Mv7tnQfJUDzLFYamdV3qv07SSH4mwHbrtMYG9fX 64cRcQWyIaVbU6pMm2y4AEQvWTCRQ/8YCzrlv0LKTaZ/ZHYQ8zTwpvM4IEZa4T7X+DOI oVuRudcLQoOT/ugKAbWl0xO53Fz8cqzZjQACZ4m4dpFxxKp9sUuWRxQDHzvUmZbzpg+9 1ngG2+kTHw0D3od9KlYz0GiLg0qwr7ekuUtOOd/8WY6Dier8vg44vsbpl/1aZDC/WFOw XDBGro03HoeqbBXuZkAO/6SvAMydV6k+q69olYxWGi7z2sG5vIP+JdY0aN7ZJw9aBgxr Ikzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=bKdRg0qHq4Gm7nb2hMMyR7fJCS54Pouz+9kYR7Dga+k=; b=j43+473YgIkIQvJjS/3SDADxXX9xQX7p47xW3PGhPlIu+FrV7FY+lzZP99ZpJmQQHu uam8gNVIpkSk1kJVrY6FBFsurZEy7uqsRY7a8p/wDLAkwo781Iwpn302qDS69VflrtHW PFnFeo+4pf8tnXbM5o7YwQeCFQSuzYlT8+62SXul9MmNMNZ/ZTdfod+A+J6tmkvsF6Wl hTA2xkU3lPpseFxBoaMSbuaptXyIlfQCA64X1VhpBpeXST3Gn0O0XuwODErobcef9/J6 NbmxXo34ohN/3Gvi2h+Sj9KOIK9mnHXiHrndDVvmXD5WDnkZ4pd7kjJQBxpvQ7sIFN0C S07A== ARC-Authentication-Results: i=1; mx.google.com; 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 u10-v6si914224plr.366.2018.10.18.09.29.25; Thu, 18 Oct 2018 09:29:40 -0700 (PDT) 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; 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 S1728585AbeJSA2g (ORCPT + 99 others); Thu, 18 Oct 2018 20:28:36 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:35388 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727402AbeJSA2g (ORCPT ); Thu, 18 Oct 2018 20:28:36 -0400 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1gDB8G-0005ZO-Ss; Thu, 18 Oct 2018 18:26:45 +0200 Date: Thu, 18 Oct 2018 18:26:44 +0200 From: Sebastian Andrzej Siewior To: Andy Lutomirski Cc: Dave Hansen , LKML , X86 ML , Paolo Bonzini , Radim Krcmar , kvm list , "Jason A. Donenfeld" , Rik van Riel Subject: Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads Message-ID: <20181018162644.qqjkzoqn2fleyi2b@linutronix.de> References: <20181004140547.13014-1-bigeasy@linutronix.de> <20181004140547.13014-6-bigeasy@linutronix.de> <39e0a55f-4920-cfde-9bef-09c51109d211@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen > wrote: > > > > On 10/04/2018 07:05 AM, Sebastian Andrzej Siewior wrote: > > > The PKRU value is not set for kernel threads because they do not have > > > the ->initialized value set. As a result the kernel thread has a random > > > PKRU value set which it inherits from the previous task. > > > It has been suggested by Paolo Bonzini to set it for kernel threads, too > > > because it might be a fix. > > > I *think* this is not required because the kernel threads don't copy > > > data to/from userland and don't have access to any userspace mm in > > > general. > > > However there is this use_mm(). If we gain a mm by use_mm() we don't > > > have a matching PKRU value because those are per thread. It has been > > > suggested to use 0 as the PKRU value but this would bypass PKRU. > > > > > > Set the initial (default) PKRU value for kernel threads. > > > > We might want to do this for cleanliness reasons... Maybe. > > > > But this *should* have no practical effects. Kernel threads have no > > real 'mm' and no user pages. They should not have do access to user > > mappings. Protection keys *only* apply to user mappings. Thus, > > logically, they should never be affected by PKRU values. > > > > So I'm kinda missing the point of the patch. > > use_mm(). So. I would drop that patch from queue. Anyone feels different about it? Sebastian