Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2808002pxb; Fri, 12 Feb 2021 01:37:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJy6VFigrhhu4DNiAfiXkKxdY5Gcegb0cjrTO9y0Sqqdrke3bz0N00xATABeAWD7GZrgpPV9 X-Received: by 2002:a05:6402:151:: with SMTP id s17mr2341120edu.107.1613122667905; Fri, 12 Feb 2021 01:37:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613122667; cv=none; d=google.com; s=arc-20160816; b=KUCIQyGHwAZ5M5SYm98QdbzRNc0yht6bnVekqaWRuTFKvlALmuLoqk2opdHntSU/EV mTu/yIZ+suxvVfFP6bbKbjqF/zxsAVjdYDdMtZtAh0LcrkfUF8pkxE2aSoZDeh8no//b KyjJSnjt7kf5mFF8/Uh7b/hgScFanAZC05P/VWiKkj1Ojvh6wYjGEIEbRV0zXNdENayT /I1Kboa/qC05N/lfT3bmly+pCGZUy6vWA7hAVCWggydhtN2+2y/k5hjy7WBa1ixLOAkk IGSYhixUJ/dB5P7Yu7AdlrEJ9YmESEzLWJLjiQzKWvxkAwWx4Z68N5aQoHryqPUCdDvB /mCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=U90UZmefQT68twBzWadSZacoqffEz06aXmD4uwJZd+o=; b=zgUdOn3JFlr1mlEwDyT+NWJ/KKk2D+xdiUODlaKsGzi2xstCDttyVND8cw6noSJ9cc o5JyWYQTpTOSTkGo9j7kCBEwAH8geJk9I30fkls14oW/cQX79Kf0s6FhnZGOGDgFD9FX 6a7PYRdTCzlrkoMV+F5ErLZ5vBYCfKnUCRXrRLELcv2anJEaDFcF6mZSK5gSZA3ckUvn dsAXAp6wd0rDpi8ZgEkfAghJQf3+yeUTUnnx7G33igmtR5JUKXIg8hnE5tQxhhQOVWuv EjhuOKTLM0aRFL6qm1G1DlfupUUSraoLS3WmtqVzEFZJDxnT4xt0/YHkQTtEL5iU9mj0 Rwdg== 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 n9si5555336edv.123.2021.02.12.01.37.13; Fri, 12 Feb 2021 01:37:47 -0800 (PST) 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 S229653AbhBLJea (ORCPT + 99 others); Fri, 12 Feb 2021 04:34:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229521AbhBLJeN (ORCPT ); Fri, 12 Feb 2021 04:34:13 -0500 Received: from sipsolutions.net (s3.sipsolutions.net [IPv6:2a01:4f8:191:4433::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 946D9C061756 for ; Fri, 12 Feb 2021 01:33:32 -0800 (PST) Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94) (envelope-from ) id 1lAUpO-001n3C-Ag; Fri, 12 Feb 2021 10:33:30 +0100 Message-ID: <9d9cc5bc50629090375b185a3af2546e506c22d9.camel@sipsolutions.net> Subject: Re: [PATCH 1/2] nl80211: Commands for FILS discovery and unsolicited broadcast probe response From: Johannes Berg To: Aloka Dixit , Arend van Spriel Cc: linux-wireless@vger.kernel.org Date: Fri, 12 Feb 2021 10:33:29 +0100 In-Reply-To: <430f10a576b8490f73827f800c87f58c@codeaurora.org> (sfid-20210125_225531_667698_384A7632) References: <20210120005229.32582-1-alokad@codeaurora.org> <20210120005229.32582-2-alokad@codeaurora.org> <430f10a576b8490f73827f800c87f58c@codeaurora.org> (sfid-20210125_225531_667698_384A7632) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-malware-bazaar: not-scanned Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Mon, 2021-01-25 at 13:52 -0800, Aloka Dixit wrote: > > FILS discovery and especially unsolicited probe response templates are > big. Sometimes send_and_recv() returns error due to memory > unavailability during wpa_driver_nl80211_set_ap() depending on how many > interfaces, which elements are added. What? Where do you get errors from? Netlink even supports vmalloc now, I believe, so the kernel really shouldn't care? > Moving these to separate commands > resolves this issue along with more control over the time interval > during run-time. I tend to agree with Arend though, we have NL80211_CMD_SET_BEACON and since NL80211_CMD_NEW_BEACON was renamed to NL80211_CMD_START_AP to more accurately say what it does, I think generalizing "AP modifications" by renaming NL80211_CMD_SET_BEACON to NL80211_CMD_UPDATE_AP (or such) would make a lot of sense. Let's not conflate the two issues here. 1) memory issues - need to understand better 2) update is needed - I'd say SET_BEACON/UPDATE_AP would be a better way than pulling everything into separate commands. Updates can be partial too, after all, if you include only the changed attributes, and that might even address case 1? I.e. why wouldn't userspace be able to do UPDATE_AP multiple times, just like with your patch it would do NL80211_CMD_SET_FILS_DISCOVERY and NL80211_CMD_SET_UNSOL_BCAST_PROBE_RESP? Also, technically this constitutes an API break. One that perhaps nobody cares about yet, but surely somebody already has hostapd versions that use NL80211_ATTR_FILS_DISCOVERY or NL80211_ATTR_UNSOL_BCAST_PROBE_RESP? After all, you don't want to tell me you never tested this code ;-) johannes