Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1488092imu; Tue, 20 Nov 2018 19:23:05 -0800 (PST) X-Google-Smtp-Source: AFSGD/Wbl6qYL/ZsI7OkRHXTCnnaM8ilmMnkekZuT3EN1PACwJxG7fNCZFht/omeFrUGGkHOeEQk X-Received: by 2002:a63:6ac5:: with SMTP id f188mr4436723pgc.165.1542770585281; Tue, 20 Nov 2018 19:23:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542770585; cv=none; d=google.com; s=arc-20160816; b=McT40mnCvOLIUpikanr3ZaS2VubSpD/u5dqkGGZOlE4OgrFLc1YekyXJvAFD269T0r Xx9x4DUGO2oaakqyePTNc5jD4Xfkg7N9cFLdEOy9cYrHf2T+6AL/eJ+4ZCCRsbl6uPUO 24Jh23BFiPG8uTO/f6ME+574cl4cyMMYi4bc9LYJg5Jwaaf1X25tOujMoFqJLAfWQFei 5H0nMDp3/P5IAeLVwKgbtg8JShBPFzHo7DxifSs2/kL0EiQDGLNUE5eJX6ZnyQAYg5jp ffju0saKD0vfi38WLzalX+xc9+jzShD/RVoZWAsapw03Qm8/xhcldDD7X+mgbu1wUrER nQ0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fvdD350S5xrXdLzzmPXVMAW0MEo3EiFNQTEvkxDsZmw=; b=uAM7yiICNq9JkmUu6kI/0JieUk3EKvveOQFlGR+NwIRPJhGKH7iZOCMXeAgai1zzTo 4T71QbROvm6YT7S99hQJoovASu5rFifL2TXkSBhiz/R/HSKdrKmS69TbIw70thjYi7Im YhzxXoL3GvCBmcrJKvfy8N1JKe4PeHfyylrMXBWkMjkguAgYNdtOnl7SFmVf7wO1hXXI Wh/8kBtggbLM5BL7ldMrFpCRs62C7ZyNwRYbGv94ZB1lI/8DOv9BerHnGl3VZiHxQge3 Rbo1FbM6KYjOmnXtNolpuYfV0GuBHlZE0akcuuYSjTHkz1RWePkjuvqoB5tuO98quX9X dxHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CFm1LMx2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a6si25519269plz.316.2018.11.20.19.22.50; Tue, 20 Nov 2018 19:23:05 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=CFm1LMx2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727348AbeKUNxk (ORCPT + 99 others); Wed, 21 Nov 2018 08:53:40 -0500 Received: from mail-io1-f67.google.com ([209.85.166.67]:47033 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726343AbeKUNxk (ORCPT ); Wed, 21 Nov 2018 08:53:40 -0500 Received: by mail-io1-f67.google.com with SMTP id m1-v6so2993528ioc.13 for ; Tue, 20 Nov 2018 19:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fvdD350S5xrXdLzzmPXVMAW0MEo3EiFNQTEvkxDsZmw=; b=CFm1LMx2bOw7myYyHpo5gKNmUTrU/8vMjw9ZpmgQtfaMuTaHxu1zRnsOk/BKt40+fU Opb22xmaR65gY35atLUSll3nlypgZOLODJbB470c95eksorntfdAVWFzY3vnHD45gq8V ffNY7qpvwUgcWEp92AVfeUx4vRYpeOf5zILcyxDTvIsJthIEYHRjZZwJDP2QTyal84u7 OiIH2xgjTPCo4NW7UHDzdIOxcYlYaEXcJYfalPw0+14fms/sqqNniQLUgtvSxYdGfClb zWsf3bFoOvI/B5GtqyF6//qqBC08rQfVeeJyfMTle+SLdT7wJtVvgWy0dtmIoDnIbbje 6iiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fvdD350S5xrXdLzzmPXVMAW0MEo3EiFNQTEvkxDsZmw=; b=eg3YlypaGIprgvqTPTFkpBZDXLL5YHFRnBplQ8DaysGuOIPchSmXzmu8sTfIn4Nj0r RtjskPU+UCGqq5H5ZK8ULJKkIJkX77Kv1PT82xMeiwtnx1oIfwuGHeiJjlndfcdKuuOb dvA+aAL9NBn7ucwnuyZGzt8gaVGj25EoRAumHpKY84LIAOAgoV4IPanMJyyUVMioDZyS Y8FXnr0ahVh/m45iahKYo+GONGu+FqPYeeFuIxjgJilpvLe/fKnQkcKI77qywbRqt2w+ C7pgNeYIcNXysC7oDcPIaUV/ZQszm6np9U/nEOdu3HUdInmSj6ooX7+ChEou50LCEMzc sMvw== X-Gm-Message-State: AA+aEWb/RC+toWgmrxTpVGBlejw1AhuwjTwVT/IUnXM+CuKA71HCsarg 9hFcdZ+g9bH5UApAAG+uERH0MsOEBqbXPuOJ7kXBWA== X-Received: by 2002:a6b:398b:: with SMTP id g133mr3564576ioa.67.1542770469043; Tue, 20 Nov 2018 19:21:09 -0800 (PST) MIME-Version: 1.0 References: <20181004195906.201895-1-schuffelen@google.com> <1539073540.3687.99.camel@sipsolutions.net> In-Reply-To: <1539073540.3687.99.camel@sipsolutions.net> From: Cody Schuffelen Date: Tue, 20 Nov 2018 19:20:57 -0800 Message-ID: Subject: Re: [PATCH net-next v3] wireless-drivers: rtnetlink wifi simulation device To: Johannes Berg Cc: Kalle Valo , "David S. Miller" , linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, netdev@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 9, 2018 at 1:25 AM Johannes Berg wrote: > > On Thu, 2018-10-04 at 12:59 -0700, Cody Schuffelen wrote: > > > > I wasn't completely clear on whether I should change the title (net-next > > to mac80211-next) so I left it as is for v3 to try to keep the patchwork > > series together. > > You can/should change it - patchwork doesn't really track this at all > anyway. Got it, thanks. > > > The driver is also now a bool instead of a tristate to use __ro_after_init. > > Hmm? Why would that be required? __ro_after_init works fine in modules? My mistake, you're right. Tested and this does work with a module. > > +static struct ieee80211_rate bitrates_2ghz[] = { > > + { .bitrate = 10 }, > > + { .bitrate = 20 }, > > + { .bitrate = 55 }, > > + { .bitrate = 60 }, > > + { .bitrate = 110 }, > > + { .bitrate = 120 }, > > + { .bitrate = 240 }, > > +}; > > Come to think of it, the typical order here would be 1,2,5.5,11,6,12,24 > (6<->11), due to the ordering in the probe request frame I guess. > > I'm not sure it matters though. Thanks, changed. > > > +static struct ieee80211_supported_band band_2ghz = { > > These can be const, I think? Unfortunately, the arrays they're assigned to in the wiphy is non-const: https://github.com/torvalds/linux/blob/master/include/net/cfg80211.h#L4055 https://github.com/torvalds/linux/blob/master/include/net/cfg80211.h#L346 struct ieee80211_supported_band *bands[IEEE80211_NUM_BANDS]; > > +/** Assigned at module init. Guaranteed locally-administered and unicast. */ > > I think you should avoid ** - it's the kernel-doc marker. Good catch. Sorry about that, you pointed it out on an earlier version as well on a different line. > > > +static u8 fake_router_bssid[ETH_ALEN] __ro_after_init = {}; > > If this is the reason for not allowing it to be a module then you don't > need to disallow the module case. Good point, fixed. > > + > > +static void virt_wifi_scan_result(struct work_struct *work) > > +{ > > + const union { > > + struct { > > + u8 tag; > > + u8 len; > > + u8 ssid[8]; > > + } __packed parts; > > + u8 data[10]; > > + } ssid = { .parts = { > > + .tag = WLAN_EID_SSID, .len = 8, .ssid = "VirtWifi" } > > + }; > > Not sure I see much value in the union, but I don't think it matters > much. > (You could just cast below - (void *)&ssid, sizeof(ssid)) Good point, done. > > > + rtnl_lock(); > > + if (priv->scan_request) { > > + cfg80211_scan_done(priv->scan_request, &scan_info); > > + priv->scan_request = NULL; > > + } > > + rtnl_unlock(); > > Do you need the rtnl for the priv->scan_request locking? I've redone the structure a bit to clean this up, and don't use the lock here anymore. > > +static int virt_wifi_get_station(struct wiphy *wiphy, > > + struct net_device *dev, > > + const u8 *mac, > > + struct station_info *sinfo) > > +{ > > [...] > > + sinfo->tx_packets = 1; > > + sinfo->tx_failed = 0; > > + sinfo->signal = -60; > > I think Sergey pointed out the -60 elsewhere - need to check here too, > and maybe set in some place that you actually report dBm/mBm. Added a comment here, it looks like even with CFG80211_SIGNAL_TYPE_MBM this should be in dBm. https://github.com/torvalds/linux/blob/master/include/net/cfg80211.h#L1264 > Also, I think you should only report something here if actually > connected - Sergey pointed this out on the dump station but it applies > here too. Thanks, get_station and dump_station now both check if the device is connected. > > +static void free_netdev_and_wiphy(struct net_device *dev) > > +{ > > + struct virt_wifi_netdev_priv *priv = netdev_priv(dev); > > + struct virt_wifi_priv *w_priv; > > + > > + flush_work(&priv->register_wiphy_work); > > + if (dev->ieee80211_ptr && !IS_ERR(dev->ieee80211_ptr)) { > > + w_priv = wiphy_priv(dev->ieee80211_ptr->wiphy); > > + w_priv->being_deleted = true; > > + flush_delayed_work(&w_priv->scan_result); > > + flush_delayed_work(&w_priv->connect); > > + flush_delayed_work(&w_priv->disconnect); > > this is called from > > > +static void virt_wifi_setup(struct net_device *dev) > > +{ > > + ether_setup(dev); > > + dev->netdev_ops = &virt_wifi_ops; > > + dev->priv_destructor = free_netdev_and_wiphy; > > +} > > the destructor, but I believe the destructor is invoked with the RTNL > held. As such, this will deadlock (and lockdep should complain - at > least in current kernel versions) when it's actually running when you > flush it, since you flush something that's (potentially) waiting to > acquire the RTNL, but you are holding the RTNL here and so neither side > can make progress. Good catch, this was not a good strategy. I think it was stable for me only because RTNL is technically not held when the destructor is invoked by netdev_run_todo, though I see now that's only because netdev_run_todo is a special case with respect to the RTNL mutex so interacting with it there seems like a bad idea. https://github.com/torvalds/linux/blob/master/net/core/dev.c#L8735 I've changed the asynchronous strategy: at a high level, it now sets the device in a "down"/"being deleted" state to block any further asynchronous requests, cancels pending delayed work operations, and cleans up dangling callbacks the delayed work operations had committed to doing. More functions are also now annotated with which locks should already be held and which will be acquired and released. This relies heavily on cancel_delayed_work_sync. My assumption here is that cancel_delayed_work_sync puts the delayed work operations in a definite "not running" state, and uses the return value to determine if it needs to clean up any callbacks. > > + /* The newlink callback is invoked while holding the rtnl lock, but > > + * register_wiphy wants to claim the rtnl lock itself. > > + */ > > + schedule_work(&priv->register_wiphy_work); > > Maybe we should fix/change that? Worked around it for this implementation by sharing one wiphy across all net_device instances. The module init and destroy now acquire the rtnl mutex to init/destroy the wiphy as well as registering the rtnl device type. The netdev setup is now more sane as the wiphy setup is done ahead of time. The only downside is that multiple wifi devices cannot scan simultaneously, so no great loss. I've uploaded the new version here: https://lkml.org/lkml/2018/11/21/251