Received: by 2002:ab3:72d2:0:b0:1f6:158b:59e2 with SMTP id p18csp722411ltf; Thu, 6 Oct 2022 13:23:44 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4383YncaXkOjtlqefQwQ5iI421wiMvDoIn6o9akcvJiCGsy2voLjiZYpcCg0AZ6+5xHhrQ X-Received: by 2002:a17:90b:4a4e:b0:20b:d3f:3c82 with SMTP id lb14-20020a17090b4a4e00b0020b0d3f3c82mr4621247pjb.23.1665087823957; Thu, 06 Oct 2022 13:23:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665087823; cv=none; d=google.com; s=arc-20160816; b=tSa5YMjn0I1+ti2RRGLxHOG59DEL4YXscJDbv6jw3hKPbOhocwEXTNlGQvE5x/btwW pd78EMF/VJCcrATYvNU6ANsb/fVNAUpv1N6lUXPxRgEBmeW+lmJQU9olZfMt5skCJhRJ Kq99OKpniCffnd5G2wIJNxhl6XD/i5bLTIksyk1WVQ0dLbX9Yy66/rh77tY/Nf7zHNkM aFSUuOTvqhr/WME/NxgTN+bIj6zRl+Zz+lJ3JxPU5Npo7UaVILuecWTAvae/Jyg8LTM/ l2jwFjV+1eLFaPQJ0BVpZzRgaP60zxsiZYfkg2F5JGHr9vzvnurX6Npo3vfXQAjJ/nkC F3Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=nwpPOlYCS85qc1YpNruI7rje5teNtWicQtAVcUz+CVw=; b=HsCjnZxQiMACZ828LkhMBfQyXzxagtxyVExmMKp5Ka4Sm74MInuLmsYNqvLHNG3v07 qMrA/AhtqDgkz3pS0tQpFZsE3zal4EkUqH5OaLwGbWUUtHxWUGxxF7x6OBRqg5Dp6Hm5 BQJpS4MYriG0g3nQIn/Er5YBNXdJwNcwVkRtpKxHbVt9TZyBaK4OZTG0y5oXFHwbACc7 nFh5gELpFS1Q5uJaZJhQar+EGIXk68U87MmJI6cR9tS1eIi+TpdzE9YNM6Oje/w3bqqY nS4opXpFbvP2EHSlBl+52mapd0oz/LMh0IsGi292cgSXCLrDYx2A4iNhSRY8lPlwzfCs Z50w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="JeKOMg/L"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a12-20020a17090abe0c00b00200973e8b7esi436105pjs.33.2022.10.06.13.23.19; Thu, 06 Oct 2022 13:23:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="JeKOMg/L"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231872AbiJFUPc (ORCPT + 99 others); Thu, 6 Oct 2022 16:15:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40428 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230148AbiJFUPa (ORCPT ); Thu, 6 Oct 2022 16:15:30 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B084AA02DF for ; Thu, 6 Oct 2022 13:15:27 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1665087325; 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: in-reply-to:in-reply-to:references:references; bh=nwpPOlYCS85qc1YpNruI7rje5teNtWicQtAVcUz+CVw=; b=JeKOMg/L46on+VSwXNzEiu1BCdZ5KEPWcMKOcwF1JwwznwnuldL6K7BGEEgiohDIMzG3ik 4mUtkVzcSOHl2cJlfozZ9gYpSf1K7wSJlcT19ppzXYj4q7i78J/2GQssduSsaRDi9D1qJ4 XfEEGAZHGZgfOBbz6dwpid13heOHRir5E11uzYcI/ZBlwjq5V6zzYqKOhY5s/po564zjZJ 8POH9MdvKUui+vNYflMjbNZQwdr7o4ufd/L4D0PnrQOIxiH+t2RMB8jTEE7VTwNolSHxjm lA1MqLu784QMUmvQmChBlS/Ty3rp4oAN9Pb32ENoj74tKnKTQjCifubQOOB96w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1665087325; 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: in-reply-to:in-reply-to:references:references; bh=nwpPOlYCS85qc1YpNruI7rje5teNtWicQtAVcUz+CVw=; b=tF28kg7R0TjGfYFr0uSV3c561CfnrmZMMvAAeqRecmU/d9jVo/Rc0FAmJ+PBYDs3Ut3dhD eM/D+6bcKqoOmZBw== To: "Guilherme G. Piccoli" , "Luck, Tony" , "linux-kernel@vger.kernel.org" , "x86@kernel.org" Cc: "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "hpa@zytor.com" , "Lutomirski, Andy" , "kernel-dev@igalia.com" , "kernel@gpiccoli.net" , "Yu, Fenghua" , Joshua Ashton , Paul Gofman , Pavel Machek , Pierre-Loup Griffais , Melissa Wen Subject: Re: [PATCH] x86/split_lock: Restore warn mode (and add a new one) to avoid userspace regression In-Reply-To: <9d9d2d5c-1b7a-721b-f0e2-f591bb170723@igalia.com> References: <20220928142109.150263-1-gpiccoli@igalia.com> <9d9d2d5c-1b7a-721b-f0e2-f591bb170723@igalia.com> Date: Thu, 06 Oct 2022 22:15:24 +0200 Message-ID: <87pmf4bter.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 28 2022 at 17:56, Guilherme G. Piccoli wrote: > On 28/09/2022 17:24, Luck, Tony wrote: >> [...] >> Why not just use the workaround suggested in that bug report: >> >> "so manual switching from default setting to split_lock_detect=off helps as workaround here" >> >> If you add this extra mode, I'm going to argue that the kernel default >> should be "seq" rather than "warn". So these game players will need >> to add a split_lock_detect=off (or warn) option. >> > > Hi Tony, thanks for your response. The workaround is the way to > circumvent the issue for now, but not all users want (or know how) to > deal with the kernel parameters. If a distro wants to default to show a > warning only, but don't break performance so hard, this would be > currently impossible. That Kconfig knob is patently bad. The only sane choice for a generic distro kernel is to slow down the offenders simply because split lock is a trivial unpriviledged DoS. Run a split locker in a tight loop and watch your shiny new multicore system degrading into a machine from the 80s. So unless the distro provides a "special broken games" kernel the users will still need to fiddle with the command line. Attack vector prevention has precedence over broken applications. That's what command line options or sysctls are for. > The main/big issues here are two: defaulting to the disruptive behavior > (with no way of building a kernel not defaulting to that without > patching), and not having a way to warn about split locking without > breaking the performance, hence the new mode "seq". Which is a misnomer and tells absolutely nothing. If we add a new parameter then we name it something like "mitigate" and make it the default. But a way better solution is to add a sysctl knob which allows to disable the slowdown mechanics and that allows distros to give the user an trivial knob in the GUI to switch to "I don't care. My broken game is more important!" mode, while still maintaining the only sensible default of preventing damage for the general use case of the generic distro kernel. Thanks, tglx