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 993C7C433F5 for ; Fri, 29 Apr 2022 15:59:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378691AbiD2QCY (ORCPT ); Fri, 29 Apr 2022 12:02:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48996 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235747AbiD2QCV (ORCPT ); Fri, 29 Apr 2022 12:02:21 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F1F8684EE3 for ; Fri, 29 Apr 2022 08:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651247942; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LxsX4QTfntQs6C7Yv2fWXMkZHy++Bj4rZ1fvoMUwGU8=; b=GDZXAObdXzzohceVMgnAXlScmFX4wCwhieYUxYpRvNkpGhWnwRBbBYYCR1G79fKZbbfGl9 ScI3XpnTAoB4RVn2gsHkDPDuMve1ytoiDt857Si1mR9Ihl0DZICQKMUXEZi8vWS99HpLkC X/+vhk/xMkcGIP1FB0gQwikkTZWVqzw= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-552-GptI5G-AMRmVMSStt-rFKw-1; Fri, 29 Apr 2022 11:59:00 -0400 X-MC-Unique: GptI5G-AMRmVMSStt-rFKw-1 Received: by mail-ed1-f69.google.com with SMTP id b24-20020a50e798000000b0041631767675so4760095edn.23 for ; Fri, 29 Apr 2022 08:59:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=LxsX4QTfntQs6C7Yv2fWXMkZHy++Bj4rZ1fvoMUwGU8=; b=KWRSGkw78J1eXVhG9ARy8SLOnQXH1dVtnIRjVG7UeIWS+1vBiMQd9cLqXakqBT2fdJ /ncXWF1C6WIm6PnSQf5WLg1gVNFIh+p3oQ9+UgSsAazxt7fM0JQS+qTNNRua9kBl21H0 yBtqCUWofrgyN8mgYyVWmcokf5cbeOie6hYH6ftr1b1GfE8NsMTrDYNRVXUKCLTMy3Q+ Lgwk3Kpf1vDg4YvK8SWOhVS9MyaoET0z6Buh1ktsWFxHakPyKkCYzqHDDdArBJxogRYm NtPAFm+X3OKH2mSO8QVmevadt8xCtykDazDDx8bH/FyoSdUY7JcXWQGPZgAN96FFfyIZ mmPw== X-Gm-Message-State: AOAM531BKw3mBckXurI5iBwZ3PJYQJgivijrtDFqLjjYa9i6sqy0qSsf 6XVMF+t3fZkN+SeJ3SGnmEAIgRrevfxlQRWFTRXFadFeYq9Fc/72FsN292tTHIptgt5OBLBITTa BywCtBXENzqMwSswCVNwQSwpg X-Received: by 2002:a05:6402:5207:b0:426:1f0:b22 with SMTP id s7-20020a056402520700b0042601f00b22mr17790313edd.186.1651247939302; Fri, 29 Apr 2022 08:58:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9rfe2BvOZTLBxZyXAtLi09aJqjNbWyrLDxfj+FFkLsfpQGzZb0LJod/amJ9dE9xKbjLvuoQ== X-Received: by 2002:a05:6402:5207:b0:426:1f0:b22 with SMTP id s7-20020a056402520700b0042601f00b22mr17790296edd.186.1651247939050; Fri, 29 Apr 2022 08:58:59 -0700 (PDT) Received: from ?IPV6:2001:b07:6468:f312:1c09:f536:3de6:228c? ([2001:b07:6468:f312:1c09:f536:3de6:228c]) by smtp.googlemail.com with ESMTPSA id l21-20020a056402345500b0042617ba6393sm3053394edc.29.2022.04.29.08.58.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Apr 2022 08:58:58 -0700 (PDT) Message-ID: <4afce434-ab25-66d6-76f4-3a987f64e88e@redhat.com> Date: Fri, 29 Apr 2022 17:58:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v3] KVM: SEV: Mark nested locking of vcpu->lock Content-Language: en-US To: Peter Gonda Cc: John Sperbeck , kvm list , David Rientjes , Sean Christopherson , LKML References: <20220407195908.633003-1-pgonda@google.com> <62e9ece1-5d71-f803-3f65-2755160cf1d1@redhat.com> <4c0edc90-36a1-4f4c-1923-4b20e7bdbb4c@redhat.com> <0d282be4-d612-374d-84ba-067994321bab@redhat.com> <8a2c5f8c-503c-b4f0-75e7-039533c9852d@redhat.com> From: Paolo Bonzini In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/29/22 17:51, Peter Gonda wrote: >> No, you don't need any of this. You can rely on there being only one >> depmap, otherwise you wouldn't need the mock releases and acquires at >> all. Also the unlocking order does not matter for deadlocks, only the >> locking order does. You're overdoing it. :) > > Hmm I'm slightly confused here then. If I take your original suggestion of: > > bool acquired = false; > kvm_for_each_vcpu(...) { > if (acquired) > mutex_release(&vcpu->mutex.dep_map, > _THIS_IP_); <-- Warning here > if (mutex_lock_killable_nested(&vcpu->mutex, role) > goto out_unlock; > acquired = true; > > """ > [ 2810.088982] ===================================== > [ 2810.093687] WARNING: bad unlock balance detected! > [ 2810.098388] 5.17.0-dbg-DEV #5 Tainted: G O > [ 2810.103788] ------------------------------------- Ah even if the contents of the dep_map are the same for all locks, it also uses the *pointer* to the dep_map to track (class, subclass) -> pointer and checks for a match. So yeah, prev_cpu is needed. The unlock ordering OTOH is irrelevant so you don't need to visit the xarray backwards. Paolo