Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp285294ybz; Fri, 17 Apr 2020 00:52:46 -0700 (PDT) X-Google-Smtp-Source: APiQypIMJTvaO5reE6HS3aTBUFJ2O5lLPLyNN1jhy/cn6IdalOfJr9xVM1EGpdJ6tVH8SNzM4Jb6 X-Received: by 2002:a17:906:edb5:: with SMTP id sa21mr1858265ejb.270.1587109966821; Fri, 17 Apr 2020 00:52:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587109966; cv=none; d=google.com; s=arc-20160816; b=yjvJbPoZ+R+ozrYYEgiuFonXxfGnShrTv3ynowBaNkbHQieR5+z9PEKJGC45ltdwRJ m3w4QoSoy4DASwlNfTHO7VNrX5mJ2105NwgnUbXYRUKO9ydnGSwPARoGfkmfqah2h3QG d0pk3i6vBaJujiQuFRrQrKX6e+6Zwk7A13Tf6Mxa16512dX+rIa3dWq/EfnH6iHuvoXZ d9dWUFfXlGVKrEoWD5M5FP0xb/TYVRGZP1tVXb0qrnaHgaQ8oZrXVrwDvVpNd23b4HT+ xPfXh3MUTcvDuRZgOKsxj9RVMf0/VNsAtjV6prwmbPkvpm6Ofm49/qpaCtq0LQcc8Nhe TIsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=Xuov4DmA/bQPe+sm1Ii3zM4aYwT/OonPix9nmXZeOZg=; b=I6MJvzIUJLdB1PKNBJY0FWiwcgWWLPGWHO8u4XlTZiqsyR9Oc+Ze5N1eFEKHrfHszA h9Mv1izhLQlP3rDnvhdT7suW3BW9cwSuTzTwVSbOZMCNxzTZeXn4GQQYGISsjAhhWgWf 4bCX72YDaavGaj6PybrNtvwNIkl4ke1i5Jp/Tp2e/Qv52MFHGsHAe+PEMymzX3QD7WSk 8Lf9EVttmiX8xXJHK4wcVe/CPsLd9Ty1n/YEqq6yt2hfo5cyQ33/G7/igDci9N3Fvf/Z gH91SAg8/Qzvne+mw+IBfmFaP5aqHUGs2+2oT+794Wi1tsQxALu4Nscy6hJNHlkHlAGQ R+fQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cy6si1906693edb.530.2020.04.17.00.52.20; Fri, 17 Apr 2020 00:52:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729492AbgDQHwM (ORCPT + 99 others); Fri, 17 Apr 2020 03:52:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729042AbgDQHwM (ORCPT ); Fri, 17 Apr 2020 03:52:12 -0400 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C935CC061A0C for ; Fri, 17 Apr 2020 00:52:11 -0700 (PDT) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.93) (envelope-from ) id 1jPLnB-006kEb-EQ; Fri, 17 Apr 2020 09:52:05 +0200 Message-ID: Subject: Re: [PATCH v5.7 8/8] iwlwifi: mvm: don't call iwl_mvm_free_inactive_queue() under RCU From: Johannes Berg To: Mark Asselstine , Luca Coelho Cc: kvalo@codeaurora.org, linux-wireless Date: Fri, 17 Apr 2020 09:52:04 +0200 In-Reply-To: (sfid-20200403_162852_111476_08446F51) References: <20200403082955.1126339-1-luca@coelho.fi> (sfid-20200403_162852_111476_08446F51) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org Sorry, missed your comment. On Fri, 2020-04-03 at 10:28 -0400, Mark Asselstine wrote: > I was looking into this as part of > https://bugzilla.kernel.org/show_bug.cgi?id=206971 and had a similar > fix in flight. My concern was that queue_owner being used outside of > the RCU might be an issue Yes, that does *look* questionable, and I missed it completely. However, that's only because the code makes weak assumptions when it's under much stronger guarantees. There's no reason for it to use RCU here for the station lookup, since it's holding the write-side lock (which is the mvm->mutex). IOW, we could just change sta = rcu_dereference(mvm->fw_id_to_mac_id[sta_id]); to sta = rcu_dereference_protected(mvm->fw_id_to_mac_id[sta_id], ...); and then it's clear that there's no issue. > as now you have no guaranty that the > eventual use of sta->txq[tid] in iwl_mvm_free_inactive_queue() is > going to be valid. The only way to work around this is instead of > storing queue_owner, store mvmtxq = iwl_mvm_txq_from_tid(sta, i), then > adjust iwl_mvm_free_inactive_queue(), iwl_mvm_disable_txq() and > whatnot to take struct iwl_mvm_txq * instead of struct ieee80211_sta > *. If you open the bug you will see the latest version of my work as > the attached patch. I am not an RCU expert so I am curious to hear > your thoughts. You could do that too, but it seems overly complex to me. johannes