Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6112738yba; Tue, 14 May 2019 01:46:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqwnx1zUyS9xBT/hqjgPC95xzWX9CGTK2baz5WMoUYUjpMz+lv+2VcMVbwdzHrhIMqZpnSjT X-Received: by 2002:a63:1726:: with SMTP id x38mr11680323pgl.365.1557823577452; Tue, 14 May 2019 01:46:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557823577; cv=none; d=google.com; s=arc-20160816; b=n6f18maQFzVlwruNrR9eHTn5l12ZGs+v37XP6HTGkVGAD3Rz1bz6CEnhQisCoQnvrF jfkgoxCgjXAVKQxoqEzrV/haRs4xd69b+phBIIB7mbMHgrhF5ULDyQnHB7Byq80D6cdP 4FJ1lm8xgHP8BJiaujG+CCp6eIfjxpZOOElDve5TCl2UEtiz0e3fHxptkJv+wyhs7+MI pcUwAmdECJgFK2gzyYs4RC03XImE77ZegmhyeFqOdVzNKRoGNxJdj4SJ643nxXtsDar0 LMAOWac0nvUy7DBcjWAOTrnEOz2XP42TAtknQe+xFHN8ifNyqWovYx6xp6FJPZL4qDKf poJA== 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 :references:in-reply-to:date:cc:to:from:subject:message-id; bh=qiitgPCrEG6MCM7YcNNuxcEEz6vWhF2nrofYr3p6GGg=; b=p5DflLPdxBE6e2eAW55hLWkkSOGvqO1+CNgSTidOYpmJYkgluv2Fqe3eMPB9QLvKGV KfZndawOJWG//Rh6iFhiFDyfSHci57vBvAJ1+PTXv4j7wu9MeRbCcNj8WPKds88rdiGk o5olTbyofGLTiZXYLBE/AaT0QozNvguYj+iMEkh2gJCZzoDXWpqYnUUSexotWRyqUC+O BN2VepX0IIjnMjdARubgK553QFtNi90RZuGZphkkbhbDfQ+5X9K6U3AcpjScVdb8s5cD yXudk4acMwaBJ4V4yKtmqIW84f7is59IndvpGEwpxCNEbf+1RCPnWA5j7Mh/p9qj5sMz oW4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z33si4018562pgk.516.2019.05.14.01.46.02; Tue, 14 May 2019 01:46:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726210AbfENIot (ORCPT + 99 others); Tue, 14 May 2019 04:44:49 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:39974 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725985AbfENIos (ORCPT ); Tue, 14 May 2019 04:44:48 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1hQT3H-0006k7-A7; Tue, 14 May 2019 10:44:47 +0200 Message-ID: Subject: Re: [PATCH] mac80211: remove warning message From: Johannes Berg To: Yibo Zhao , linux-wireless@vger.kernel.org Cc: ath10k@lists.infradead.org, Zhi Chen Date: Tue, 14 May 2019 10:44:45 +0200 In-Reply-To: <1557471662-1355-1-git-send-email-yiboz@codeaurora.org> (sfid-20190510_090204_942831_B8A9C5A2) References: <1557471662-1355-1-git-send-email-yiboz@codeaurora.org> (sfid-20190510_090204_942831_B8A9C5A2) Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.fc28) 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 On Fri, 2019-05-10 at 15:01 +0800, Yibo Zhao wrote: > In multiple SSID cases, it takes time to prepare every AP interface > to be ready in initializing phase. If a sta already knows everything it > needs to join one of the APs and sends authentication to the AP which > is not fully prepared at this point of time, AP's channel context > could be NULL. As a result, warning message occurs. Please share the dump, I don't think this should be happening. I think this warning did what it was supposed to, uncover a bug; rather than remove the warning we should fix the bug. > Even worse, if the AP is under attack via tools such as MDK3 and massive > authentication requests are received in a very short time, console will > be hung due to kernel warning messages. I don't buy this, it's just a WARN_ON_ONCE(). > If this case can be hit during normal functionality, there should be no > WARN_ON(). Those should be reserved to cases that are not supposed to be > hit at all or some other more specific cases like indicating obsolete > interface. I agree, but right now I'm inclined to think it's a bug elsewhere rather than normal operation. johannes