Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3544145ybc; Thu, 21 Nov 2019 09:53:02 -0800 (PST) X-Google-Smtp-Source: APXvYqzGYQVx3LHyezlCO6ncxAHnht2QmU+f/S0OzFsAk8jC/anRRbKFjtIX6lOK1HOoS07tqhp4 X-Received: by 2002:a5d:6789:: with SMTP id v9mr12320746wru.344.1574358782435; Thu, 21 Nov 2019 09:53:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574358782; cv=none; d=google.com; s=arc-20160816; b=ROowA6DHL99c+lEw7YggjryjdKbuvADblUq//7dgmlAmE+SEmJyljZIsIqrrgXuMBY 3abGONfyoT8Xq0cBPV48UvZsvCBHrlYV1/EfwwS6kQCzKoRCNx+isnoBRl+DogSla5bh QzULcNVJ6u4cH5VsbACkSeof37PkQrVBfqKDmhjMxwCiUUpHBT86DHzfP/TdS6JozJBe lpGmt6lIZyKIM6/IzTWowQrRq89AbCI2XhiyV3bNi2ry1LXI14FLjuASgpAv8OZC8RqN MtUgp1kGW707xBKYecr2R4+ncNT0vqcYl5HtgOdtvYftdEZLXrq/vzG4qZwom0Tocx5j Bh/w== 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=5AqD9FmfhbM+FnyZKsnl/6b6dcGgxz26SKDO/IP72MQ=; b=LW99mH4f9XJF0oZrLgB41rPYdBLkgAAtC2UeWxlHhn3S+lWXpwWb3lbq6vZw9OhghR b6u6NpgFUF/Txf38SMFFEhGGhKZ/OXOzRhYMorDvA58uvgA4CibsIfHP/ltrmMQL/+Fk iJRoDP3vOY4KPaPdsPqNWOLtpom89E4ToM0DenweJCZP50qDTBKOkAW3fM0BuO6Oa2NA 5gPnsktz1bkMxwAkjVVMF5l5QJ2q9FghqYs1MFUmvGfpBnIqHnawB1+GNcbmFv5bRVaV 5F1/3SLqmQ+0ntPnjONsKsBqgZkxmJpxIYXGKZbM+Ri09Xgh8BDku19bfpBgQnLosS42 /j9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=a72zGENT; 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 bt12si2545394edb.85.2019.11.21.09.52.36; Thu, 21 Nov 2019 09:53:02 -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=a72zGENT; 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 S1726658AbfKURvR (ORCPT + 99 others); Thu, 21 Nov 2019 12:51:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:44766 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726279AbfKURvR (ORCPT ); Thu, 21 Nov 2019 12:51:17 -0500 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 6921A2067D for ; Thu, 21 Nov 2019 17:51:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574358676; bh=w4NAhbBGXkWtjvEN68neI3i+vdEAQADQDNA6Ic6Csho=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=a72zGENTurAjwkxNrguv79ToysR9/vqimQ1KABqMtEiifaIv0dEL73uz2CbLeAamh AOz5ifQ6VbgP0OHLQXfT4maGV5cH/4tR7B9OGBLUEbdPGKRckM9368baApMZMCUy42 US87iNGQsF8JenXCksNW0uj7LqKmXZ89cuZ6EgJs= Received: by mail-wr1-f52.google.com with SMTP id i12so5474198wrn.11 for ; Thu, 21 Nov 2019 09:51:16 -0800 (PST) X-Gm-Message-State: APjAAAUWuW9bKYg2Pp+wF2/wh8RIwrCfjqIqnKUSOS4kl0hBEfi53ie6 Ydo4IapqIPqp4FRJXEXTXneVaqcs6zn4Zc2ru9J2qg== X-Received: by 2002:adf:b457:: with SMTP id v23mr12299661wrd.149.1574358674973; Thu, 21 Nov 2019 09:51:14 -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> <3481175cbe14457a947f934343946d52@AcuMS.aculab.com> In-Reply-To: <3481175cbe14457a947f934343946d52@AcuMS.aculab.com> From: Andy Lutomirski Date: Thu, 21 Nov 2019 09:51:03 -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: David Laight Cc: Ingo Molnar , Peter Zijlstra , Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Tony Luck , Ashok Raj , Ravi V Shankar , 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 Thu, Nov 21, 2019 at 9:43 AM David Laight wrote: > > From: Ingo Molnar > > Sent: 21 November 2019 17:12 > > * Peter Zijlstra wrote: > ... > > > This feature MUST be default enabled, otherwise everything will > > > be/remain broken and we'll end up in the situation where you can't use > > > it even if you wanted to. > > > > Agreed. > > Before it can be enabled by default someone needs to go through the > kernel and fix all the code that abuses the 'bit' functions by using them > on int[] instead of long[]. > > I've only seen one fix go through for one use case of one piece of code > that repeatedly uses potentially misaligned int[] arrays for bitmasks. > Can we really not just change the lock asm to use 32-bit accesses for set_bit(), etc? Sure, it will fail if the bit index is greater than 2^32, but that seems nuts. (Why the *hell* do the bitops use long anyway? They're *bit masks* for crying out loud. As in, users generally want to operate on fixed numbers of bits.) --Andy