Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp805482ybc; Fri, 22 Nov 2019 13:28:53 -0800 (PST) X-Google-Smtp-Source: APXvYqx+rIVA5JwOyu3JU/H9t8xaqGlLJDHnhkNnL5TPsMEAnce9S6BK58eYJX1jffZP3NjS8TDB X-Received: by 2002:a50:9713:: with SMTP id c19mr3854572edb.206.1574458133649; Fri, 22 Nov 2019 13:28:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574458133; cv=none; d=google.com; s=arc-20160816; b=ObaNAkUKrlRQe5B/vlh0iXp7UPwozZP3uvMW6nC2eFcXg3TG8YzRqKt+XNNUvG1jrA uD9kOaXS1Li2BxPHPoEZmy/8aZ5/Br3vuzUgAm0xEdlevU/+472WjFYgVHenrmHqBQKU 0/mKZTEA8vfDu++1tJV4Z8QhUIjAwXbrJO1MYblBPgY91y8qw4B8nQSapMq64eMXH6wR mphTSZ8JglHyqQtaGZeiDqd/x+RxZIDpw3d0yy6SAqUd0av0uWHMByzv9qzGYqnY9H8R 6R8Ly+zVgPHAXOyosBZ63g2NA5Hv2aw7tqCob9aVAMcw58HeLb1PNfoZOo8nOnVh59OE obtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RMD2owLISsN7z80z9PFy8bqtMOKkF9Sm6OtWj0dIWTY=; b=MfV/FP+wjZV3aoiiFCv+7FN0OoW8AHxLzqSc2FaaPQNhMbFjEFuMLDsGB1dfmH8IUx N8xXJDAWYkbJUe3C/6A5PUYu9HO6Ohhx4oxV8dzy+nHcdmCfg3wibGGW8Rns/fM2m41c 0w72OCr3u7J6+YcA51zUrmzmfn607C8eBADT9XC8wIaTgPNBTFyqpGeZJzm48eBNFtpA Y8NNQp2GbeBqYryu2vqPHtCyI9XUJQPkdJr+ky0bmuOqpv3QlWuJkex6W9n7O+MPCz7n cWAsKhZ4s2XS7yGVVu8iozfUZSqqaj7/MwI0BbansSrqIq24ZPisCf4mx8gEVF05d7gk zfOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=KFLa8Gfr; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h17si5425862ejq.121.2019.11.22.13.28.15; Fri, 22 Nov 2019 13:28:53 -0800 (PST) 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=@kernel.org header.s=default header.b=KFLa8Gfr; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726840AbfKVV0A (ORCPT + 99 others); Fri, 22 Nov 2019 16:26:00 -0500 Received: from mail.kernel.org ([198.145.29.99]:59792 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726568AbfKVV0A (ORCPT ); Fri, 22 Nov 2019 16:26:00 -0500 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 17A452070E for ; Fri, 22 Nov 2019 21:25:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574457959; bh=FKzKBV4TrdrboPXJLjDitQfRN7V8x3JRJ+NB94Pa52I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=KFLa8Gfrw+96ytj7yfFR1oAct0LFyIj/vBsqSwf/g89Vcbw9gYI2MHkK0uw/oSkzM oSfrdbI2LjNvvK/GJSh8WqSejYfOYYpI7TI2pkE0ScpnNx6DTMNNgtAapHeICHZxhi pUg9wBztBNYIOy+VUYIYrJG51Q1j2NoPE0H9Ud9Q= Received: by mail-wm1-f49.google.com with SMTP id n188so7295183wme.1 for ; Fri, 22 Nov 2019 13:25:59 -0800 (PST) X-Gm-Message-State: APjAAAUEivmufSfcBArehKoTe8yWmkEoXpDgl62S7PeO9nyTEkIFow6t HlM6B/d8F6W231bUdtQoxEepBDXzVP6C2hLB/IyRfA== X-Received: by 2002:a1c:1f8d:: with SMTP id f135mr7047041wmf.79.1574457957590; Fri, 22 Nov 2019 13:25:57 -0800 (PST) MIME-Version: 1.0 References: <1574297603-198156-1-git-send-email-fenghua.yu@intel.com> <1574297603-198156-7-git-send-email-fenghua.yu@intel.com> <20191121060444.GA55272@gmail.com> <20191121130153.GS4097@hirez.programming.kicks-ass.net> <20191121171214.GD12042@gmail.com> <20191121173444.GA5581@agluck-desk2.amr.corp.intel.com> <20191122105141.GY4114@hirez.programming.kicks-ass.net> <20191122152715.GA1909@hirez.programming.kicks-ass.net> <3908561D78D1C84285E8C5FCA982C28F7F4DD20D@ORSMSX115.amr.corp.intel.com> <20191122202345.GC2844@hirez.programming.kicks-ass.net> <20191122204204.GA192370@romley-ivt3.sc.intel.com> In-Reply-To: <20191122204204.GA192370@romley-ivt3.sc.intel.com> From: Andy Lutomirski Date: Fri, 22 Nov 2019 13:25:45 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by kernel parameter To: Fenghua Yu Cc: Peter Zijlstra , "Luck, Tony" , Ingo Molnar , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , "Raj, Ashok" , "Shankar, Ravi V" , linux-kernel , x86 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 22, 2019 at 12:29 PM Fenghua Yu wrote: > > On Fri, Nov 22, 2019 at 09:23:45PM +0100, Peter Zijlstra wrote: > > On Fri, Nov 22, 2019 at 06:02:04PM +0000, Luck, Tony wrote: > > > > it requires we get the kernel and firmware clean, but only warns about > > > > dodgy userspace, which I really don't think there is much of. > > > > > > > > getting the kernel clean should be pretty simple. > > > > > > Fenghua has a half dozen additional patches (I think they were > > > all posted in previous iterations of the patch) that were found by > > > code inspection, rather than by actually hitting them. > > > > I thought we merged at least some of that, but maybe my recollection is > > faulty. > > At least 2 key fixes are in TIP tree: > https://lore.kernel.org/lkml/157384597983.12247.8995835529288193538.tip-bot2@tip-bot2/ > https://lore.kernel.org/lkml/157384597947.12247.7200239597382357556.tip-bot2@tip-bot2/ I do not like these patches at all. I would *much* rather see the bitops fixed and those patches reverted. Is there any Linux architecture that doesn't have 32-bit atomic operations? If all architectures can support them, then we should add set_bit_u32(), etc and/or make x86's set_bit() work for a 4-byte-aligned pointer. --Andy