Received: by 10.192.165.148 with SMTP id m20csp1459174imm; Thu, 10 May 2018 11:00:53 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrnzqkvRoTEQBBnTolRx6jxtL/DA5fup5MLnamw4nr+NXzTXRgzVgCrVsTFsmxi+vVjstWM X-Received: by 2002:a62:3c10:: with SMTP id j16-v6mr2289683pfa.7.1525975253345; Thu, 10 May 2018 11:00:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525975253; cv=none; d=google.com; s=arc-20160816; b=fneD+ahTcFeU+ybugp5YZjRPu+ivAs5rMxzKFSqObYx6c3lcdXXkOBicy51oEWjrKG rWX6v+0/bQWT7a13ZrWtueRwBbY/ekD2WqbJBeIICA466CV4G+RIGAVWzKA8x3ULAIvA Vn2Hw2jmQ2WkJNK90AJsqpfQ/D3Ek4U01iHsYHwRXO05pfZClByCAhnpi6KE1JwGJav6 GdKRa8b2/KtKH+u5SWXpkCzmm6WQn3RU+OwFKBu9KLrMY4aAThU2UpF7EGuLkL3ADGp5 TFroOgchcfxeom6rF6in2AA6rNcBTuJZu8tDgOscZQE2cXLvPQErigdLRWn3ft7g0C6+ c+hA== 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:dkim-signature:arc-authentication-results; bh=O3OBjPIdjrdmvPooe0oSKGxB7vq29SoLKKxE7hXVmxE=; b=n+5HaACAiBoEqrZuGvL8YfLZ0clCST2S8rPEK2AYqOaaolGbFX81q72KPKQ4tLZtOJ z+HL5ZkNFaBRcQemJCG4rydVGKMqxnxRkjhA8kglSUrcuuiwrZcJ3DV7PyvJcN7bmjbb vyxRmH2ZKDfrXuCYzf5nZJR40Cqv7BacHfM6aGyxFs6kqM6DNGtevhmDN7SjWYZd9TU1 u2aszVE7W+Z8o0LV14B9UQ/95A2ltSt7KSuyH1SZeclpEsP7N5XcmvX/XQcaEUkFtTnP tirotidiZ9LGtquL4cbSPqyTPba0lAwN6EgKKIicufH4iWs3Lh3SczG1oIIuNTXkHMUb ZlUw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WIzZFCym; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u136-v6si1075817pgb.136.2018.05.10.11.00.38; Thu, 10 May 2018 11:00:53 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=WIzZFCym; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966811AbeEJR6k (ORCPT + 99 others); Thu, 10 May 2018 13:58:40 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:38469 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966718AbeEJR6i (ORCPT ); Thu, 10 May 2018 13:58:38 -0400 Received: by mail-pg0-f66.google.com with SMTP id n9-v6so1284827pgq.5; Thu, 10 May 2018 10:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=O3OBjPIdjrdmvPooe0oSKGxB7vq29SoLKKxE7hXVmxE=; b=WIzZFCymjjD41BqT27RdVKWBXK0aaDrdRWsVXCcA8rhst5fEyjTMUH8q8cHXvRsqF5 sRDQiPAQ1eNG362IXt8DYSr92x9v1yE0JKXr9MCht3jrAN5EuPdEYyNdzebthKU4BYsX Ug26SAVw636AMW6J2Y4pDih3Os9CF8G/HaNS6uF6RKvGg/bxX41JZik+oXM7AmEEpaZm bwBHDh3Olt9HX1ygBXrVro/dlWxaYPGjTO0oKuEyGu5ShwbcqTtWvGIqZmIBAe+DdDmL 9M+4vPlDIG1QimIx9Flh2V+eSKgcgT/vmfm+2G2IG8WUhewHFqOfOlFWaYC5HKmeBgBW djew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=O3OBjPIdjrdmvPooe0oSKGxB7vq29SoLKKxE7hXVmxE=; b=hILYBIg+gWr/DJwL7QloBzDhBeuwDdBsNKSFDhY2YQuwzDg1lk59eYRF9Ily6nnNDg HKQVTwWI48rBgtmjrsJpY93sAMjtcPYPXICLw4vAq2cZ8eN14sfTWuotzyxEgAHgwIYQ hROFmdAaC0VmsFoAdd4iljg9hS6z/AMluWtKsHnwqJq9BDR0aEsOPjmWrWC8IlrYb291 0Sw4f1rOZxIgedywvShi6eP6OkGwbJwoJHjZoszOqM+MXgiBRND4pQpNM/t3VTvObkW3 ibcA1QPVUeJVj3/bOkgR6ORlWWk1oaRGv4LZPUG7sIsl0vu3ueR2f9muR53mi2WkbA/F KW/w== X-Gm-Message-State: ALKqPwc3VhiQG/9NRT8ZWE3NcUUZjKFzvy6FbFm+3stX/eh/h938p5+A MmU+IopGXlbX/Qz2/NMLGOg= X-Received: by 2002:a63:b443:: with SMTP id n3-v6mr1824336pgu.81.1525975117734; Thu, 10 May 2018 10:58:37 -0700 (PDT) Received: from ast-mbp.dhcp.thefacebook.com ([2620:10d:c090:200::4:c752]) by smtp.gmail.com with ESMTPSA id h75-v6sm4844706pfh.148.2018.05.10.10.58.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 10:58:36 -0700 (PDT) Date: Thu, 10 May 2018 10:58:35 -0700 From: Alexei Starovoitov To: Borislav Petkov Cc: Peter Zijlstra , Yonghong Song , mingo@kernel.org, torvalds@linux-foundation.org, ast@fb.com, daniel@iogearbox.net, linux-kernel@vger.kernel.org, x86@kernel.org, netdev@vger.kernel.org, kernel-team@fb.com, Thomas Gleixner Subject: Re: [PATCH bpf v3] x86/cpufeature: bpf hack for clang not supporting asm goto Message-ID: <20180510175833.nujqinu26mydeape@ast-mbp.dhcp.thefacebook.com> References: <20180504033119.2130788-1-yhs@fb.com> <20180510100634.GZ12217@hirez.programming.kicks-ass.net> <20180510155240.5s2fpgm2fwal3jlj@ast-mbp.dhcp.thefacebook.com> <20180510162028.GB16130@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510162028.GB16130@pd.tnic> User-Agent: NeoMutt/20180223 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 10, 2018 at 06:20:28PM +0200, Borislav Petkov wrote: > On Thu, May 10, 2018 at 08:52:42AM -0700, Alexei Starovoitov wrote: > > That makes me wonder what happened with "we do not break user space" rule? > > As someone already pointed out on IRC, arch/x86/include/asm/cpufeature.h > is solely a kernel header so nothing but kernel should include it. So > forget the userspace breakage "argument". libbcc is a library. It's not only used by bcc scripts, but by production services that compile bpf programs with clang. Without this kernel fix the companies won't be able to upgrade the kernel. Even if we could somehow hack libbcc and workaround in user space (which is not possible as already explained), it's a long dependency chain to recompile and upgrade core services before upgrading the kernel which makes even theoretical user space fix impractical. I see no option, but to fix the kernel. Regardless whether it's called user space breakage or kernel breakage.