lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 25 Mar 2022 15:18:10 -0700 From: Jeff Johnson <quic_jjohnson@...cinc.com> To: Johannes Berg <johannes@...solutions.net>, William McVicker <willmcvicker@...gle.com> CC: Jakub Kicinski <kuba@...nel.org>, <linux-wireless@...r.kernel.org>, "Marek Szyprowski" <m.szyprowski@...sung.com>, Kalle Valo <kvalo@...eaurora.org>, "David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>, "Amitkumar Karwar" <amitkarwar@...il.com>, Ganapathi Bhat <ganapathi.bhat@....com>, Xinming Hu <huxinming820@...il.com>, <kernel-team@...roid.com>, Paolo Abeni <pabeni@...hat.com> Subject: Re: [BUG] deadlock in nl80211_vendor_cmd On 3/25/2022 2:16 PM, Johannes Berg wrote: > On Fri, 2022-03-25 at 20:36 +0000, William McVicker wrote: >> >> I found that my wlan driver is using the vendor commands to create/delete NAN >> interfaces for this Android feature called Wi-Fi aware [1]. Basically, this >> features allows users to discover other nearby devices and allows them to >> connect directly with one another over a local network. >> > > Wait, why is it doing that? We actually support a NAN interface type > upstream :) It's not really quite fully fleshed out, but it could be? > Probably should be? And this is the issue with Android drivers. Android team proposes changes to the Wifi HAL and driver vendors have to implement those quickly to meet product deadlines. Some infrastructure changes we're able to get into the core kernel without having an in-tree driver that uses them (such as introducing NL80211_IFTYPE_NAN), but there have been instances of core kernel changes being rejected because there was not an in-tree user. Yes, in your ideal world all of the Android wifi drivers would be in-tree. And in that ideal world every release cycle the Android team would advocate for core kernel changes needed to support the new features of the HAL. But past history has shown attempts to upstream new features has been delayed, perhaps in part due to the absence of an in-tree driver that utilizes those features, and the only way to meet product deadlines is to take the vendor command route. And yes my out-of-tree driver is facing the exact same issue with NAN interface creation and deletion via vendor commands. Previously you had suggested: > Your easiest option might be to just patch NL80211_FLAG_NEED_RTNL into > your kernel for vendor commands and call it a day? Would you consider taking that upstream given that there are very few in-tree users of vendor commands, and I fear Will and I aren't the only ones who'll face this issue? Will, suggest you at least advocate for getting this into the 5.15 ACK. /jeff
Powered by blists - more mailing lists