On pre-emption enabled kernels the following oops was being seen due to
missing local_bh_disable/local_bh_enable calls. mac80211 assumes that
pre-emption is disabled in the data path.
[ 5365.229756] Call Trace:
[ 5365.229762] dump_stack+0x5c/0x80
[ 5365.229766] check_preemption_disabled.cold.0+0x46/0x51
[ 5365.229779] __ieee80211_subif_start_xmit+0x144/0x210 [mac80211]
[ 5365.229790] ieee80211_tx_control_port+0x116/0x140 [mac80211]
[ 5365.229806] nl80211_tx_control_port+0x13c/0x270 [cfg80211]
[ 5365.229810] genl_family_rcv_msg+0x1c4/0x3a0
[ 5365.229814] ? nlmon_xmit+0x3c/0x50 [nlmon]
[ 5365.229816] ? dev_hard_start_xmit+0xa5/0x240
[ 5365.229817] genl_rcv_msg+0x47/0x90
[ 5365.229818] ? genl_family_rcv_msg+0x3a0/0x3a0
[ 5365.229820] netlink_rcv_skb+0x4c/0x120
[ 5365.229821] genl_rcv+0x24/0x40
[ 5365.229822] netlink_unicast+0x196/0x240
[ 5365.229824] netlink_sendmsg+0x1fd/0x3c0
[ 5365.229826] sock_sendmsg+0x33/0x40
[ 5365.229827] __sys_sendto+0xee/0x160
[ 5365.229830] ? __se_sys_epoll_ctl+0x34d/0xe80
[ 5365.229831] ? do_epoll_wait+0xb0/0xd0
[ 5365.229832] __x64_sys_sendto+0x24/0x30
[ 5365.229835] do_syscall_64+0x5b/0x170
[ 5365.229836] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Denis Kenzior <[email protected]>
---
net/mac80211/tx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5b93bde248fd..6a79d564de35 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -4850,7 +4850,9 @@ int ieee80211_tx_control_port(struct wiphy *wiphy, struct net_device *dev,
skb_reset_network_header(skb);
skb_reset_mac_header(skb);
+ local_bh_disable();
__ieee80211_subif_start_xmit(skb, skb->dev, flags);
+ local_bh_enable();
return 0;
}
--
2.13.5
On Wed, 2018-06-20 at 09:51 +0200, Arend van Spriel wrote:
> On 6/19/2018 5:39 PM, Denis Kenzior wrote:
> > On pre-emption enabled kernels the following oops was being seen due
> > to missing local_bh_disable/local_bh_enable calls. mac80211 assumes
> > that pre-emption is disabled in the data path.
>
> No sure if "assumes" is the right term here. It seems like it is
> required and there is probably a good reason for that. Would be nice to
> know what that reason is.
It's using per-CPU data.
johannes
On Tue, 2018-06-19 at 10:39 -0500, Denis Kenzior wrote:
> On pre-emption enabled kernels the following oops was being seen due to
> missing local_bh_disable/local_bh_enable calls. mac80211 assumes that
> pre-emption is disabled in the data path.
Applied, but I've done some major edits to the commit message and added
a Fixes tag :)
johannes
On 6/19/2018 5:39 PM, Denis Kenzior wrote:
> On pre-emption enabled kernels the following oops was being seen due
> to missing local_bh_disable/local_bh_enable calls. mac80211 assumes
> that pre-emption is disabled in the data path.
No sure if "assumes" is the right term here. It seems like it is
required and there is probably a good reason for that. Would be nice to
know what that reason is.
Regards,
Arend
On 6/20/2018 9:53 AM, Johannes Berg wrote:
> On Wed, 2018-06-20 at 09:51 +0200, Arend van Spriel wrote:
>> On 6/19/2018 5:39 PM, Denis Kenzior wrote:
>>> On pre-emption enabled kernels the following oops was being seen due
>>> to missing local_bh_disable/local_bh_enable calls. mac80211 assumes
>>> that pre-emption is disabled in the data path.
>>
>> No sure if "assumes" is the right term here. It seems like it is
>> required and there is probably a good reason for that. Would be nice to
>> know what that reason is.
>
> It's using per-CPU data.
Hence the smp_processor_id() call which Denis mentioned in the bug report?
Regards,
Arend
On Wed, 2018-06-20 at 09:54 +0200, Arend van Spriel wrote:
> On 6/20/2018 9:53 AM, Johannes Berg wrote:
> > On Wed, 2018-06-20 at 09:51 +0200, Arend van Spriel wrote:
> > > On 6/19/2018 5:39 PM, Denis Kenzior wrote:
> > > > On pre-emption enabled kernels the following oops was being seen due
> > > > to missing local_bh_disable/local_bh_enable calls. mac80211 assumes
> > > > that pre-emption is disabled in the data path.
> > >
> > > No sure if "assumes" is the right term here. It seems like it is
> > > required and there is probably a good reason for that. Would be nice to
> > > know what that reason is.
> >
> > It's using per-CPU data.
>
> Hence the smp_processor_id() call which Denis mentioned in the bug report?
Yeah, I think that's an implementation detail thereof.
johannes