Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp430443ybl; Fri, 30 Aug 2019 01:53:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqwqJMffsyHyF7BlJBJVrW5vbNQRfxSjvdm3po8yguEXKiVbMhuaNyWAJ4+ZDp2K10zSXnnZ X-Received: by 2002:a17:902:8d8c:: with SMTP id v12mr14804181plo.198.1567155211960; Fri, 30 Aug 2019 01:53:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567155211; cv=none; d=google.com; s=arc-20160816; b=mpBGNph83OY74vA1sbGiR/1HNMIL71ZZxr4Tm0ybMkL9vDyGD5T9g9diyrbxmpwWCY jCcnuWC4/UEQkbXGkbJAJ+Lbu/zPQtSs8fE4BoAsW73qQ/28QXKPTKz4parDOhYYgvrp /oakWsc7zqt657c1ymV6afABvJeQy3NN41gTfRdXwPAdTWKwfUec2RLBlKdVQLWKkKvS oxnU5mzoKNLfUB8Ce/VpxlJ7DX8NdNRWqAA9f6inf6gCSEQlKmd+bQVQgtHTY01wbULG VH8zVQvjKE4M08WLmMRqIEGEefoNTa8+IsOrBxTIqHRc1SmMNKbokSns8QUcyC6b7ND2 KlkQ== 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=iiEV4DsPxdXi26A5/QAa7w+NjEkceew3DAyg3GdQ8Ko=; b=RhMiGTZdLLllmy6sFnEhQoQpULggxk3OzWCE2NZPwy6gLzrOPu+JOLYmhMVY0J+kgs j1XI+gwt4GKbeKlRcUnuvT01J5j67XwXf7lBJEyYmF3h15owLEkcetxjTEmmk3NLytdY g6zOy+CBqV6OIKep3oV0tudULNQZ7ikw5AvOvEkeseFiBvijU7aMPWI3pBqTa/hdryWp Q6IJthuA1HUI7ObibJ15MJig9nKO3YM0KUZYzwpQWSjjf83Fspc3zvqj+LABGfMTO3YQ nG3BTK8JC25oG/oU42u/jU7ZmewrHFlgKxHWrzTRFq2KoCfWZBPgbzTIfXI7CInrsale oAOQ== 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 x11si5142297pfn.171.2019.08.30.01.53.05; Fri, 30 Aug 2019 01:53:31 -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 S1726969AbfH3IxE (ORCPT + 99 others); Fri, 30 Aug 2019 04:53:04 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:33018 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726492AbfH3IxE (ORCPT ); Fri, 30 Aug 2019 04:53:04 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.1) (envelope-from ) id 1i3ceU-0001rQ-4I; Fri, 30 Aug 2019 10:53:02 +0200 Message-ID: <5dc694c33759a32eb3796668a8b396c0133e1ebe.camel@sipsolutions.net> Subject: Re: [PATCH] cfg80211: Purge frame registrations on iftype change From: Johannes Berg To: Denis Kenzior , linux-wireless@vger.kernel.org Cc: stable@vger.kernel.org Date: Fri, 30 Aug 2019 10:53:01 +0200 In-Reply-To: <20190828211110.15005-1-denkenz@gmail.com> (sfid-20190828_231636_661927_AAE3C4AB) References: <20190828211110.15005-1-denkenz@gmail.com> (sfid-20190828_231636_661927_AAE3C4AB) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) 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 Wed, 2019-08-28 at 16:11 -0500, Denis Kenzior wrote: > Currently frame registrations are not purged, even when changing the > interface type. This can lead to potentially weird / dangerous > situations where frames possibly not relevant to a given interface > type remain registered and mgmt_frame_register is not called for the > no-longer-relevant frame types. I'd argue really just "weird and non-working", hardly dangerous. Even in the mac80211 design where we want to not let you intercept e.g. AUTH frames in client mode - if you did, then you'd just end up with a non- working interface. Not sure I see any "dangerous situation". Not really an all that important distinction though. Depending on the design, it may also just be that those registrations are *ignored*, because e.g. firmware intercepts the AUTH frame already, which would just (maybe) confuse userspace - but that seems unlikely since it switched interface type and has no real need for those frames then. > The kernel currently relies on userspace apps to actually purge the > registrations themselves, e.g. by closing the nl80211 socket associated > with those frames. However, this requires multiple nl80211 sockets to > be open by the userspace app, and for userspace to be aware of all state > changes. This is not something that the kernel should rely on. I tend to agree with that the kernel shouldn't rely on it. > This commit adds a call to cfg80211_mlme_purge_registrations() to > forcefully remove any registrations left over prior to switching the > iftype. However, I do wonder if we should make this more transactional, and hang on to them if the type switching fails. We're not notifying userspace that the registrations have disappeared, so if type switching fails and it continues to work with the old type rather than throwing its hands up and quitting or something, it'd make a possibly bigger mess to just silently have removed them already. I *think* it should be safe to just move this after the switching succeeds, since the switching can pretty much only be done at a point where nothing is happening on the interface anyway, though that might confuse the driver when the remove happens. Also, perhaps it'd be better to actually hang on to those registrations that *are* still possible afterwards? But to not confuse the driver I guess that might require unregister/re-register to happen, all of which requires hanging on to the list and going through it after the type switch completed? What do you think? johannes