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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 838B1C433F5 for ; Tue, 14 Sep 2021 23:43:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5E7A0610D1 for ; Tue, 14 Sep 2021 23:43:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235966AbhINXow (ORCPT ); Tue, 14 Sep 2021 19:44:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233774AbhINXou (ORCPT ); Tue, 14 Sep 2021 19:44:50 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB124C061764 for ; Tue, 14 Sep 2021 16:43:30 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id n4so455669plh.9 for ; Tue, 14 Sep 2021 16:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=8O+Hy6We6pSl0DNT8xui4/8ZZ/lZgMhSAyPrG/8P2Ww=; b=oBbEAG+7FvjkbqO7CpvRLFUIxM3766nu3aMkROo6iWBNl+TYiwyE3gtvbgifiEov3l 2Gq682Im2gXqCtjoMObMjTRSsP+KYH/KoviNQzjlvP/qqw+cFHzSPBfVUzhciitBkEMf QstU8wTvI4+7x9gztxTlEhQv1RUiS4pBfuP+otYpBsQJxscX/Xnh6GT/c3k8aG4KKvBJ 9Vag7UGjME5jWsPFG0J4KmhykpaX+b2ydeG/za6E6zL3r8w2ohtyp8MGw++ceNfpPws0 OVJYrvSM/1tKBRHoZfvWibTBQOJMZ/t3efk2/xjycZ2Z2uBqAdX546KLbLMwFiyZOolx Ky/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=8O+Hy6We6pSl0DNT8xui4/8ZZ/lZgMhSAyPrG/8P2Ww=; b=ZqP5uOEh7WtBNtoUBfFxEUgPsvWe+2VRzsqjb/RNKTaPQHC9K+7MfW5S3X5HwRJunb T87A2QZ6bT2ojHUSDNtuISRhRJe0xFK60pL1ZC7qKd/jcb7Vyh+gVLXDs3a+lbOPOZ3f ObfzYXuFrJvholVEjCJFg0xiwiIDfLYxlSpdzlcsZNBmSe/h6JoKZxlFInXD6kcwM3UE m3J6KJ8chZLZWO0V/nARkC7AGSV9uIqMlMoFX/W7M+d73L1Swah3DXE3flgdBw4v9pCR lxGfAx9w0rGgeG7iAsd4XgeF6W6mv3ZQ1WHPnFlprh3VvUkg2fQXITBXd0F36zkWDMBM xA1Q== X-Gm-Message-State: AOAM530/iCEAmzBPPb3jLq4Ys31UTaW0G2ATZ0P8PHRWLefoAne7lbCH 4MfKiBH+vPfY7DBS12S1BxJT3ppLBzhrJQ== X-Google-Smtp-Source: ABdhPJyj23XbbLxNyB4sJkNtXn+USgxVzCsmWrwtl0ite0P6RNMul8bZnegi9bZ3G4X1QsMqKyJIFg== X-Received: by 2002:a17:90a:f002:: with SMTP id bt2mr4963401pjb.207.1631663010164; Tue, 14 Sep 2021 16:43:30 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id v23sm11084092pff.155.2021.09.14.16.43.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Sep 2021 16:43:29 -0700 (PDT) Date: Tue, 14 Sep 2021 23:43:25 +0000 From: Sean Christopherson To: Peter Gonda Cc: kvm list , Marc Orr , Paolo Bonzini , Brijesh Singh , stable@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: SEV: Acquire vcpu mutex when updating VMSA Message-ID: References: <20210914200639.3305617-1-pgonda@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Tue, Sep 14, 2021, Peter Gonda wrote: > That looks reasonable to me. I didn't know if changes headed for LTS > should be smaller so I avoided doing this refactor. From: > https://www.kernel.org/doc/html/v4.11/process/stable-kernel-rules.html#stable-kernel-rules > seems to say less than 100 lines is ideal. Most the rules are more like guidelines ;-) In seriousness, there's a balance to be had between minimizing the diff and keeping everything maintainable. E.g. if the fix is kept small and then the upstream code is immediately refactored, any future fixes to the refactored code will be harder to backport. And the actual fix would also be poorly tested in upstream since folks would be testing the refactored version of the code. > I guess this could also be a "theoretical race condition” anyways so maybe > not for LTS anyways. If there's doubt, write a test :-) The "theoretical race condition" thing is to discourage people from backporting fixes for ridiculously tiny windows that may or may not be exploitable. This is a giant gaping chasm that userspace can drive a car through, e.g. literally "do KVM_RUN at the same time".