From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E94B4C43217 for ; Thu, 20 Oct 2022 11:13:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230254AbiJTLNj (ORCPT ); Thu, 20 Oct 2022 07:13:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231267AbiJTLNh (ORCPT ); Thu, 20 Oct 2022 07:13:37 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3AB7119BC4; Thu, 20 Oct 2022 04:13:32 -0700 (PDT) Received: from zn.tnic (p200300ea9733e710329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:9733:e710:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 5AF701EC01A9; Thu, 20 Oct 2022 13:13:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1666264406; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=j2i2KgCp3P7IRZRg0PairiL8EiPXc7wkVc3ASgZ2HEs=; b=nvGUaSvR6A9hfSBZvJ2166fkCoN9jlFe7Fz9VBt1MIcQ9aCGKXY9k1PjxuqUW6hj1PLxCz o3aYLOAoDJ0TbLhc52+8EmfoJdd0E/dLM7hI2Twbaq9PVxSx5pMQQK2e6JGboEmfVImLQz 6GMqiNGgihuUQoLtrN87k/YQWhoBmuo= Date: Thu, 20 Oct 2022 13:13:22 +0200 From: Borislav Petkov To: Maxim Levitsky Cc: Herbert Xu , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Pawan Gupta , Ingo Molnar , Josh Poimboeuf , Namhyung Kim , Tony Luck , Paolo Bonzini , "H. Peter Anvin" , Arnaldo Carvalho de Melo , Thomas Gleixner , Alexander Shishkin , Tim Chen , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Jiri Olsa , Mark Rutland , linux-perf-users@vger.kernel.org, "open list:CRYPTO API" Subject: Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Message-ID: References: <20220718141123.136106-1-mlevitsk@redhat.com> <20220718141123.136106-2-mlevitsk@redhat.com> <3cc09554f20231aecdf0cd762a282c42aee9273c.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3cc09554f20231aecdf0cd762a282c42aee9273c.camel@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Thu, Oct 20, 2022 at 01:21:30PM +0300, Maxim Levitsky wrote: > I agree with you, however this patch series is just > refactoring/hardening of the kernel - if the kernel can avoid crashing > - why not. Because we're already drowning in patches which are trying to fix real problems. If we open the floodgates on alleged hardening just because some other part of the stack is misbehaving, there'll be no end of it. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette