@@ -5417,31 +5417,6 @@ int ath11k_wmi_pull_fw_stats(struct ath11k_base *ab, struct sk_buff *skb,return0;}-staticint-ath11k_pull_pdev_temp_ev(structath11k_base*ab,u8*evt_buf,-u32len,conststructwmi_pdev_temperature_event*ev)-{-constvoid**tb;-intret;--tb=ath11k_wmi_tlv_parse_alloc(ab,evt_buf,len,GFP_ATOMIC);-if(IS_ERR(tb)){-ret=PTR_ERR(tb);-ath11k_warn(ab,"failed to parse tlv: %d\n",ret);-returnret;-}--ev=tb[WMI_TAG_PDEV_TEMPERATURE_EVENT];-if(!ev){-ath11k_warn(ab,"failed to fetch pdev temp ev");-kfree(tb);-return-EPROTO;-}--kfree(tb);-return0;-}-size_tath11k_wmi_fw_stats_num_vdevs(structlist_head*head){structath11k_fw_stats_vdev*i;
@@ -6849,23 +6824,37 @@ ath11k_wmi_pdev_temperature_event(struct ath11k_base *ab,structsk_buff*skb){structath11k*ar;-structwmi_pdev_temperature_eventev={0};+constvoid**tb;+conststructwmi_pdev_temperature_event*ev;+intret;++tb=ath11k_wmi_tlv_parse_alloc(ab,skb->data,skb->len,GFP_ATOMIC);+if(IS_ERR(tb)){+ret=PTR_ERR(tb);+ath11k_warn(ab,"failed to parse tlv: %d\n",ret);+return;+}-if(ath11k_pull_pdev_temp_ev(ab,skb->data,skb->len,&ev)!=0){-ath11k_warn(ab,"failed to extract pdev temperature event");+ev=tb[WMI_TAG_PDEV_TEMPERATURE_EVENT];+if(!ev){+ath11k_warn(ab,"failed to fetch pdev temp ev");+kfree(tb);return;}ath11k_dbg(ab,ATH11K_DBG_WMI,-"pdev temperature ev temp %d pdev_id %d\n",ev.temp,ev.pdev_id);+"pdev temperature ev temp %d pdev_id %d\n",ev->temp,ev->pdev_id);-ar=ath11k_mac_get_ar_by_pdev_id(ab,ev.pdev_id);+ar=ath11k_mac_get_ar_by_pdev_id(ab,ev->pdev_id);if(!ar){-ath11k_warn(ab,"invalid pdev id in pdev temperature ev %d",ev.pdev_id);+ath11k_warn(ab,"invalid pdev id in pdev temperature ev %d",ev->pdev_id);+kfree(tb);return;}-ath11k_thermal_event_temperature(ar,ev.temp);+ath11k_thermal_event_temperature(ar,ev->temp);++kfree(tb);}staticvoidath11k_fils_discovery_event(structath11k_base*ab,
From: Hoang Le <redacted>
[ Upstream commit 1980d37565061ab44bdc2f9e4da477d3b9752e81 ]
(struct tipc_link_info)->dest is in network order (__be32), so we must
convert the value to network order before assigning. The problem detected
by sparse:
net/tipc/netlink_compat.c:699:24: warning: incorrect type in assignment (different base types)
net/tipc/netlink_compat.c:699:24: expected restricted __be32 [usertype] dest
net/tipc/netlink_compat.c:699:24: got int
Acked-by: Jon Maloy <jmaloy@redhat.com>
Signed-off-by: Hoang Le <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/tipc/netlink_compat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Maxim Mikityanskiy <redacted>
[ Upstream commit 991b2654605b455a94dac73e14b23480e7e20991 ]
Commit e20f0dbf204f ("net/mlx5e: RX, Add a prefetch command for small
L1_CACHE_BYTES") switched to using net_prefetchw at all places in mlx5e.
In the same time frame, commit 5af75c747e2a ("net/mlx5e: Enhanced TX
MPWQE for SKBs") added one more usage of prefetchw. When these two
changes were merged, this new occurrence of prefetchw wasn't replaced
with net_prefetchw.
This commit fixes this last occurrence of prefetchw in
mlx5e_tx_mpwqe_session_start, making the same change that was done in
mlx5e_xdp_mpwqe_session_start.
Signed-off-by: Maxim Mikityanskiy <redacted>
Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Jonathan McDowell <redacted>
[ Upstream commit e127906b68b49ddb3ecba39ffa36a329c48197d3 ]
Commit eaf4fac47807 ("net: stmmac: Do not accept invalid MTU values")
started using the TX FIFO size to verify what counts as a valid MTU
request for the stmmac driver. This is unset for the ipq806x variant.
Looking at older patches for this it seems the RX + TXs buffers can be
up to 8k, so set appropriately.
(I sent this as an RFC patch in June last year, but received no replies.
I've been running with this on my hardware (a MikroTik RB3011) since
then with larger MTUs to support both the internal qca8k switch and
VLANs with no problems. Without the patch it's impossible to set the
larger MTU required to support this.)
Signed-off-by: Jonathan McDowell <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.c | 2 ++
1 file changed, 2 insertions(+)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
[ Upstream commit 787a4109f46847975ffae7d528a55c6b768ef0aa ]
The "bridge fdb add" command provided in the switchdev documentation is
junk now, not only because it is syntactically incorrect and rejected by
the iproute2 bridge program, but also because it was not updated in
light of Arkadi Sharshevsky's radical switchdev refactoring in commit
29ab586c3d83 ("net: switchdev: Remove bridge bypass support from
switchdev"). Try to explain what the intended usage pattern is with the
new kernel implementation.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/networking/switchdev.rst | 47 +++++++++++++++++++-------
1 file changed, 35 insertions(+), 12 deletions(-)
@@ -181,18 +181,41 @@ To offloading L2 bridging, the switchdev driver/device should support: Static FDB Entries ^^^^^^^^^^^^^^^^^^-The switchdev driver should implement ndo_fdb_add, ndo_fdb_del and ndo_fdb_dump-to support static FDB entries installed to the device. Static bridge FDB-entries are installed, for example, using iproute2 bridge cmd::-- bridge fdb add ADDR dev DEV [vlan VID] [self]--The driver should use the helper switchdev_port_fdb_xxx ops for ndo_fdb_xxx-ops, and handle add/delete/dump of SWITCHDEV_OBJ_ID_PORT_FDB object using-switchdev_port_obj_xxx ops.--XXX: what should be done if offloading this rule to hardware fails (for-example, due to full capacity in hardware tables) ?+A driver which implements the ``ndo_fdb_add``, ``ndo_fdb_del`` and+``ndo_fdb_dump`` operations is able to support the command below, which adds a+static bridge FDB entry::++ bridge fdb add dev DEV ADDRESS [vlan VID] [self] static++(the "static" keyword is non-optional: if not specified, the entry defaults to+being "local", which means that it should not be forwarded)++The "self" keyword (optional because it is implicit) has the role of+instructing the kernel to fulfill the operation through the ``ndo_fdb_add``+implementation of the ``DEV`` device itself. If ``DEV`` is a bridge port, this+will bypass the bridge and therefore leave the software database out of sync+with the hardware one.++To avoid this, the "master" keyword can be used::++ bridge fdb add dev DEV ADDRESS [vlan VID] master static++The above command instructs the kernel to search for a master interface of+``DEV`` and fulfill the operation through the ``ndo_fdb_add`` method of that.+This time, the bridge generates a ``SWITCHDEV_FDB_ADD_TO_DEVICE`` notification+which the port driver can handle and use it to program its hardware table. This+way, the software and the hardware database will both contain this static FDB+entry.++Note: for new switchdev drivers that offload the Linux bridge, implementing the+``ndo_fdb_add`` and ``ndo_fdb_del`` bridge bypass methods is strongly+discouraged: all static FDB entries should be added on a bridge port using the+"master" flag. The ``ndo_fdb_dump`` is an exception and can be implemented to+visualize the hardware tables, if the device does not have an interrupt for+notifying the operating system of newly learned/forgotten dynamic FDB+addresses. In that case, the hardware FDB might end up having entries that the+software FDB does not, and implementing ``ndo_fdb_dump`` is the only way to see+them. Note: by default, the bridge does not filter on VLAN and only bridges untagged traffic. To enable VLAN support, turn on VLAN filtering::
From: Archie Pusaka <redacted>
[ Upstream commit 5c4c8c9544099bb9043a10a5318130a943e32fc3 ]
hci_chan can be created in 2 places: hci_loglink_complete_evt() if
it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory,
Only AMP hci_chan should be removed by a call to
hci_disconn_loglink_complete_evt(). However, the controller might mess
up, call that function, and destroy an hci_chan which is not initiated
by hci_loglink_complete_evt().
This patch adds a verification that the destroyed hci_chan must have
been init'd by hci_loglink_complete_evt().
Example crash call trace:
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe3/0x144 lib/dump_stack.c:118
print_address_description+0x67/0x22a mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report mm/kasan/report.c:412 [inline]
kasan_report+0x251/0x28f mm/kasan/report.c:396
hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072
l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877
l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661
l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline]
l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline]
l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline]
l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline]
l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023
l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596
hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline]
hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796
process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
kthread+0x2f0/0x304 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
Allocated by task 38:
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787
kmalloc include/linux/slab.h:515 [inline]
kzalloc include/linux/slab.h:709 [inline]
hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674
l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062
l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline]
l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381
hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404
hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline]
hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981
hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
kthread+0x2f0/0x304 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
Freed by task 1732:
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free mm/kasan/kasan.c:521 [inline]
__kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493
slab_free_hook mm/slub.c:1409 [inline]
slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436
slab_free mm/slub.c:3009 [inline]
kfree+0x182/0x21e mm/slub.c:3972
hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline]
hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050
hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791
process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175
worker_thread+0x4fc/0x670 kernel/workqueue.c:2321
kthread+0x2f0/0x304 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415
The buggy address belongs to the object at ffff8881d7af9180
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 24 bytes inside of
128-byte region [ffff8881d7af9180, ffff8881d7af9200)
The buggy address belongs to the page:
page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0
flags: 0x8000000000000200(slab)
raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Signed-off-by: Archie Pusaka <redacted>
Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com
Reviewed-by: Alain Michaud <redacted>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_event.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
From: Archie Pusaka <redacted>
[ Upstream commit 3a9d54b1947ecea8eea9a902c0b7eb58a98add8a ]
Currently l2cap_chan_set_defaults() reset chan->conf_state to zero.
However, there is a flag CONF_NOT_COMPLETE which is set when
creating the l2cap_chan. It is suggested that the flag should be
cleared when l2cap_chan is ready, but when l2cap_chan_set_defaults()
is called, l2cap_chan is not yet ready. Therefore, we must set this
flag as the default.
Example crash call trace:
__dump_stack lib/dump_stack.c:15 [inline]
dump_stack+0xc4/0x118 lib/dump_stack.c:56
panic+0x1c6/0x38b kernel/panic.c:117
__warn+0x170/0x1b9 kernel/panic.c:471
warn_slowpath_fmt+0xc7/0xf8 kernel/panic.c:494
debug_print_object+0x175/0x193 lib/debugobjects.c:260
debug_object_assert_init+0x171/0x1bf lib/debugobjects.c:614
debug_timer_assert_init kernel/time/timer.c:629 [inline]
debug_assert_init kernel/time/timer.c:677 [inline]
del_timer+0x7c/0x179 kernel/time/timer.c:1034
try_to_grab_pending+0x81/0x2e5 kernel/workqueue.c:1230
cancel_delayed_work+0x7c/0x1c4 kernel/workqueue.c:2929
l2cap_clear_timer+0x1e/0x41 include/net/bluetooth/l2cap.h:834
l2cap_chan_del+0x2d8/0x37e net/bluetooth/l2cap_core.c:640
l2cap_chan_close+0x532/0x5d8 net/bluetooth/l2cap_core.c:756
l2cap_sock_shutdown+0x806/0x969 net/bluetooth/l2cap_sock.c:1174
l2cap_sock_release+0x64/0x14d net/bluetooth/l2cap_sock.c:1217
__sock_release+0xda/0x217 net/socket.c:580
sock_close+0x1b/0x1f net/socket.c:1039
__fput+0x322/0x55c fs/file_table.c:208
____fput+0x17/0x19 fs/file_table.c:244
task_work_run+0x19b/0x1d3 kernel/task_work.c:115
exit_task_work include/linux/task_work.h:21 [inline]
do_exit+0xe4c/0x204a kernel/exit.c:766
do_group_exit+0x291/0x291 kernel/exit.c:891
get_signal+0x749/0x1093 kernel/signal.c:2396
do_signal+0xa5/0xcdb arch/x86/kernel/signal.c:737
exit_to_usermode_loop arch/x86/entry/common.c:243 [inline]
prepare_exit_to_usermode+0xed/0x235 arch/x86/entry/common.c:277
syscall_return_slowpath+0x3a7/0x3b3 arch/x86/entry/common.c:348
int_ret_from_sys_call+0x25/0xa3
Signed-off-by: Archie Pusaka <redacted>
Reported-by: syzbot+338f014a98367a08a114@syzkaller.appspotmail.com
Reviewed-by: Alain Michaud <redacted>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 2 ++
1 file changed, 2 insertions(+)
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
[ Upstream commit be8597239379f0f53c9710dd6ab551bbf535bec6 ]
syzbot is hitting "INFO: trying to register non-static key." message [1],
for "struct l2cap_chan"->tx_q.lock spinlock is not yet initialized when
l2cap_chan_del() is called due to e.g. timeout.
Since "struct l2cap_chan"->lock mutex is initialized at l2cap_chan_create()
immediately after "struct l2cap_chan" is allocated using kzalloc(), let's
as well initialize "struct l2cap_chan"->{tx_q,srej_q}.lock spinlocks there.
[1] https://syzkaller.appspot.com/bug?extid=fadfba6a911f6bf71842
Reported-and-tested-by: syzbot <redacted>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/l2cap_core.c | 2 ++
1 file changed, 2 insertions(+)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
[ Upstream commit 6215afcb9a7e35cef334dc0ae7f998cc72c8465f ]
A make W=1 build complains that:
net/sched/cls_flower.c:214:20: warning: cast from restricted __be16
net/sched/cls_flower.c:214:20: warning: incorrect type in argument 1 (different base types)
net/sched/cls_flower.c:214:20: expected unsigned short [usertype] val
net/sched/cls_flower.c:214:20: got restricted __be16 [usertype] dst
This is because we use htons on struct flow_dissector_key_ports members
src and dst, which are defined as __be16, so they are already in network
byte order, not host. The byte swap function for the other direction
should have been used.
Because htons and ntohs do the same thing (either both swap, or none
does), this change has no functional effect except to silence the
warnings.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sched/cls_flower.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
@@ -209,16 +209,16 @@ static bool fl_range_port_dst_cmp(struct cls_fl_filter *filter,structfl_flow_key*key,structfl_flow_key*mkey){-__be16min_mask,max_mask,min_val,max_val;+u16min_mask,max_mask,min_val,max_val;-min_mask=htons(filter->mask->key.tp_range.tp_min.dst);-max_mask=htons(filter->mask->key.tp_range.tp_max.dst);-min_val=htons(filter->key.tp_range.tp_min.dst);-max_val=htons(filter->key.tp_range.tp_max.dst);+min_mask=ntohs(filter->mask->key.tp_range.tp_min.dst);+max_mask=ntohs(filter->mask->key.tp_range.tp_max.dst);+min_val=ntohs(filter->key.tp_range.tp_min.dst);+max_val=ntohs(filter->key.tp_range.tp_max.dst);if(min_mask&&max_mask){-if(htons(key->tp_range.tp.dst)<min_val||-htons(key->tp_range.tp.dst)>max_val)+if(ntohs(key->tp_range.tp.dst)<min_val||+ntohs(key->tp_range.tp.dst)>max_val)returnfalse;/* skb does not have min and max values */
@@ -232,16 +232,16 @@ static bool fl_range_port_src_cmp(struct cls_fl_filter *filter,structfl_flow_key*key,structfl_flow_key*mkey){-__be16min_mask,max_mask,min_val,max_val;+u16min_mask,max_mask,min_val,max_val;-min_mask=htons(filter->mask->key.tp_range.tp_min.src);-max_mask=htons(filter->mask->key.tp_range.tp_max.src);-min_val=htons(filter->key.tp_range.tp_min.src);-max_val=htons(filter->key.tp_range.tp_max.src);+min_mask=ntohs(filter->mask->key.tp_range.tp_min.src);+max_mask=ntohs(filter->mask->key.tp_range.tp_max.src);+min_val=ntohs(filter->key.tp_range.tp_min.src);+max_val=ntohs(filter->key.tp_range.tp_max.src);if(min_mask&&max_mask){-if(htons(key->tp_range.tp.src)<min_val||-htons(key->tp_range.tp.src)>max_val)+if(ntohs(key->tp_range.tp.src)<min_val||+ntohs(key->tp_range.tp.src)>max_val)returnfalse;/* skb does not have min and max values */
@@ -783,16 +783,16 @@ static int fl_set_key_port_range(struct nlattr **tb, struct fl_flow_key *key,TCA_FLOWER_UNSPEC,sizeof(key->tp_range.tp_max.src));if(mask->tp_range.tp_min.dst&&mask->tp_range.tp_max.dst&&-htons(key->tp_range.tp_max.dst)<=-htons(key->tp_range.tp_min.dst)){+ntohs(key->tp_range.tp_max.dst)<=+ntohs(key->tp_range.tp_min.dst)){NL_SET_ERR_MSG_ATTR(extack,tb[TCA_FLOWER_KEY_PORT_DST_MIN],"Invalid destination port range (min must be strictly smaller than max)");return-EINVAL;}if(mask->tp_range.tp_min.src&&mask->tp_range.tp_max.src&&-htons(key->tp_range.tp_max.src)<=-htons(key->tp_range.tp_min.src)){+ntohs(key->tp_range.tp_max.src)<=+ntohs(key->tp_range.tp_min.src)){NL_SET_ERR_MSG_ATTR(extack,tb[TCA_FLOWER_KEY_PORT_SRC_MIN],"Invalid source port range (min must be strictly smaller than max)");
From: Nikolay Aleksandrov <redacted>
[ Upstream commit 0353b4a96b7a9f60fe20d1b3ebd4931a4085f91c ]
Recently we had an interop issue where RARP packets got suppressed with
bridge neigh suppression enabled, but the check in the code was meant to
suppress GARP. Exclude RARP packets from it which would allow some VMWare
setups to work, to quote the report:
"Those RARP packets usually get generated by vMware to notify physical
switches when vMotion occurs. vMware may use random sip/tip or just use
sip=tip=0. So the RARP packet sometimes get properly flooded by the vtep
and other times get dropped by the logic"
Reported-by: Amer Abdalamer <redacted>
Signed-off-by: Nikolay Aleksandrov <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bridge/br_arp_nd_proxy.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Guangbin Huang <redacted>
[ Upstream commit a2ee6fd28a190588e142ad8ea9d40069cd3c9f98 ]
The array size of bd_num_list is a fixed value, it may have potential
overflow risk when array size of hclge_dfx_bd_offset_list is greater
than that fixed value. So modify bd_num_list as a pointer and allocate
memory for it according to array size of hclge_dfx_bd_offset_list.
Signed-off-by: Guangbin Huang <redacted>
Signed-off-by: Huazhong Tan <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../hisilicon/hns3/hns3pf/hclge_main.c | 27 ++++++++++++++-----
1 file changed, 20 insertions(+), 7 deletions(-)
@@ -11473,15 +11472,19 @@ static int hclge_get_dfx_reg_len(struct hclge_dev *hdev, int *len){u32dfx_reg_type_num=ARRAY_SIZE(hclge_dfx_bd_offset_list);intdata_len_per_desc,bd_num,i;-intbd_num_list[BD_LIST_MAX_NUM];+int*bd_num_list;u32data_len;intret;+bd_num_list=kcalloc(dfx_reg_type_num,sizeof(int),GFP_KERNEL);+if(!bd_num_list)+return-ENOMEM;+ret=hclge_get_dfx_reg_bd_num(hdev,bd_num_list,dfx_reg_type_num);if(ret){dev_err(&hdev->pdev->dev,"Get dfx reg bd num fail, status is %d.\n",ret);-returnret;+gotoout;}data_len_per_desc=sizeof_field(structhclge_desc,data);
@@ -11492,6 +11495,8 @@ static int hclge_get_dfx_reg_len(struct hclge_dev *hdev, int *len)*len+=(data_len/REG_LEN_PER_LINE+1)*REG_LEN_PER_LINE;}+out:+kfree(bd_num_list);returnret;}
@@ -11499,16 +11504,20 @@ static int hclge_get_dfx_reg(struct hclge_dev *hdev, void *data){u32dfx_reg_type_num=ARRAY_SIZE(hclge_dfx_bd_offset_list);intbd_num,bd_num_max,buf_len,i;-intbd_num_list[BD_LIST_MAX_NUM];structhclge_desc*desc_src;+int*bd_num_list;u32*reg=data;intret;+bd_num_list=kcalloc(dfx_reg_type_num,sizeof(int),GFP_KERNEL);+if(!bd_num_list)+return-ENOMEM;+ret=hclge_get_dfx_reg_bd_num(hdev,bd_num_list,dfx_reg_type_num);if(ret){dev_err(&hdev->pdev->dev,"Get dfx reg bd num fail, status is %d.\n",ret);-returnret;+gotoout;}bd_num_max=bd_num_list[0];
From: Yunsheng Lin <redacted>
[ Upstream commit d5d5e0193ee8f88efbbc7f1471087255657bc19a ]
Currently hns3 driver only handle the xmit skb with one level of
fraglist skb, add handling for multi level by calling hns3_tx_bd_num()
recursively when calculating bd num and calling hns3_fill_skb_to_desc()
recursively when filling tx desc.
When the skb has a fraglist level of 24, the skb is simply dropped and
stats.max_recursion_level is added to record the error. Move the stat
handling from hns3_nic_net_xmit() to hns3_nic_maybe_stop_tx() in order
to handle different error stat and add the 'max_recursion_level' and
'hw_limitation' stat.
Note that the max recursive level as 24 is chose according to below:
commit 48a1df65334b ("skbuff: return -EMSGSIZE in skb_to_sgvec to
prevent overflow").
And that we are not able to find a testcase to verify the recursive
fraglist case, so Fixes tag is not provided.
Reported-by: Barry Song <redacted>
Signed-off-by: Yunsheng Lin <redacted>
Signed-off-by: Huazhong Tan <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/hisilicon/hns3/hns3_enet.c | 115 +++++++++++-------
.../net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +
.../ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +
3 files changed, 78 insertions(+), 41 deletions(-)
@@ -1277,23 +1277,21 @@ static unsigned int hns3_skb_bd_num(struct sk_buff *skb, unsigned int *bd_size,}staticunsignedinthns3_tx_bd_num(structsk_buff*skb,unsignedint*bd_size,-u8max_non_tso_bd_num)+u8max_non_tso_bd_num,unsignedintbd_num,+unsignedintrecursion_level){+#define HNS3_MAX_RECURSION_LEVEL 24+structsk_buff*frag_skb;-unsignedintbd_num=0;/* If the total len is within the max bd limit */-if(likely(skb->len<=HNS3_MAX_BD_SIZE&&!skb_has_frag_list(skb)&&+if(likely(skb->len<=HNS3_MAX_BD_SIZE&&!recursion_level&&+!skb_has_frag_list(skb)&&skb_shinfo(skb)->nr_frags<max_non_tso_bd_num))returnskb_shinfo(skb)->nr_frags+1U;-/* The below case will always be linearized, return-*HNS3_MAX_BD_NUM_TSO+1Utomakesureitislinearized.-*/-if(unlikely(skb->len>HNS3_MAX_TSO_SIZE||-(!skb_is_gso(skb)&&skb->len>-HNS3_MAX_NON_TSO_SIZE(max_non_tso_bd_num))))-returnHNS3_MAX_TSO_BD_NUM+1U;+if(unlikely(recursion_level>=HNS3_MAX_RECURSION_LEVEL))+returnUINT_MAX;bd_num=hns3_skb_bd_num(skb,bd_size,bd_num);
@@ -1301,7 +1299,8 @@ static unsigned int hns3_tx_bd_num(struct sk_buff *skb, unsigned int *bd_size,returnbd_num;skb_walk_frags(skb,frag_skb){-bd_num=hns3_skb_bd_num(frag_skb,bd_size,bd_num);+bd_num=hns3_tx_bd_num(frag_skb,bd_size,max_non_tso_bd_num,+bd_num,recursion_level+1);if(bd_num>HNS3_MAX_TSO_BD_NUM)returnbd_num;}
@@ -1361,6 +1360,43 @@ void hns3_shinfo_pack(struct skb_shared_info *shinfo, __u32 *size)size[i]=skb_frag_size(&shinfo->frags[i]);}+staticinthns3_skb_linearize(structhns3_enet_ring*ring,+structsk_buff*skb,+u8max_non_tso_bd_num,+unsignedintbd_num)+{+/* 'bd_num == UINT_MAX' means the skb' fraglist has a+*recursionlevelofoverHNS3_MAX_RECURSION_LEVEL.+*/+if(bd_num==UINT_MAX){+u64_stats_update_begin(&ring->syncp);+ring->stats.over_max_recursion++;+u64_stats_update_end(&ring->syncp);+return-ENOMEM;+}++/* The skb->len has exceeded the hw limitation, linearization+*willnothelp.+*/+if(skb->len>HNS3_MAX_TSO_SIZE||+(!skb_is_gso(skb)&&skb->len>+HNS3_MAX_NON_TSO_SIZE(max_non_tso_bd_num))){+u64_stats_update_begin(&ring->syncp);+ring->stats.hw_limitation++;+u64_stats_update_end(&ring->syncp);+return-ENOMEM;+}++if(__skb_linearize(skb)){+u64_stats_update_begin(&ring->syncp);+ring->stats.sw_err_cnt++;+u64_stats_update_end(&ring->syncp);+return-ENOMEM;+}++return0;+}+staticinthns3_nic_maybe_stop_tx(structhns3_enet_ring*ring,structnet_device*netdev,structsk_buff*skb)
@@ -1370,7 +1406,7 @@ static int hns3_nic_maybe_stop_tx(struct hns3_enet_ring *ring,unsignedintbd_size[HNS3_MAX_TSO_BD_NUM+1U];unsignedintbd_num;-bd_num=hns3_tx_bd_num(skb,bd_size,max_non_tso_bd_num);+bd_num=hns3_tx_bd_num(skb,bd_size,max_non_tso_bd_num,0,0);if(unlikely(bd_num>max_non_tso_bd_num)){if(bd_num<=HNS3_MAX_TSO_BD_NUM&&skb_is_gso(skb)&&!hns3_skb_need_linearized(skb,bd_size,bd_num,
@@ -1379,16 +1415,11 @@ static int hns3_nic_maybe_stop_tx(struct hns3_enet_ring *ring,gotoout;}-if(__skb_linearize(skb))+if(hns3_skb_linearize(ring,skb,max_non_tso_bd_num,+bd_num))return-ENOMEM;bd_num=hns3_tx_bd_count(skb->len);-if((skb_is_gso(skb)&&bd_num>HNS3_MAX_TSO_BD_NUM)||-(!skb_is_gso(skb)&&-bd_num>max_non_tso_bd_num)){-trace_hns3_over_max_bd(skb);-return-ENOMEM;-}u64_stats_update_begin(&ring->syncp);ring->stats.tx_copy++;
@@ -1412,6 +1443,10 @@ static int hns3_nic_maybe_stop_tx(struct hns3_enet_ring *ring,returnbd_num;}+u64_stats_update_begin(&ring->syncp);+ring->stats.tx_busy++;+u64_stats_update_end(&ring->syncp);+return-EBUSY;}
@@ -1459,6 +1494,7 @@ static int hns3_fill_skb_to_desc(struct hns3_enet_ring *ring,structsk_buff*skb,enumhns_desc_typetype){unsignedintsize=skb_headlen(skb);+structsk_buff*frag_skb;inti,ret,bd_num=0;if(size){
@@ -1483,6 +1519,15 @@ static int hns3_fill_skb_to_desc(struct hns3_enet_ring *ring,bd_num+=ret;}+skb_walk_frags(skb,frag_skb){+ret=hns3_fill_skb_to_desc(ring,frag_skb,+DESC_TYPE_FRAGLIST_SKB);+if(unlikely(ret<0))+returnret;++bd_num+=ret;+}+returnbd_num;}
From: Marc Kleine-Budde <mkl@pengutronix.de>
[ Upstream commit 4168d079aa41498639b2c64b4583375bcdf360d9 ]
A out of bounds access to "struct can_priv::echo_skb" leads to a
kernel crash. Better print a sensible warning message instead and try
to recover.
This patch is similar to:
| e7a6994d043a ("can: dev: __can_get_echo_skb(): Don't crash the kernel
| if can_priv::echo_skb is accessed out of bounds")
Link: https://lore.kernel.org/r/20210319142700.305648-2-mkl@pengutronix.de
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/can/dev/skb.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
From: Paul M Stillwell Jr <redacted>
[ Upstream commit 2ec5638559c13b923250eccf495d2a033fccb3e7 ]
There is an issue when the Tx or Rx ring size increases using
'ethtool -L ...' where the new rings don't get the correct ITR
values because when we rebuild the VSI we don't know that some
of the rings may be new.
Fix this by looking at the original number of rings and
determining if the rings in ice_vsi_rebuild_set_coalesce()
were not present in the original rings received in
ice_vsi_rebuild_get_coalesce().
Also change the code to return an error if we can't allocate
memory for the coalesce data in ice_vsi_rebuild().
Signed-off-by: Paul M Stillwell Jr <redacted>
Tested-by: Tony Brelinski <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/ice/ice_lib.c | 123 ++++++++++++++++------
drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +
2 files changed, 92 insertions(+), 33 deletions(-)
@@ -2818,38 +2818,46 @@ int ice_vsi_release(struct ice_vsi *vsi)}/**-*ice_vsi_rebuild_update_coalesce-setcoalesceforaq_vector+*ice_vsi_rebuild_update_coalesce_intrl-setinterruptratelimitforaq_vector*@q_vector:pointertoq_vectorwhichisbeingupdated-*@coalesce:pointertoarrayofstructwithstoredcoalesce+*@stored_intrl_setting:originalINTRLsetting**Setcoalesceparaminq_vectorandupdatetheseparametersinHW.*/staticvoid-ice_vsi_rebuild_update_coalesce(structice_q_vector*q_vector,-structice_coalesce_stored*coalesce)+ice_vsi_rebuild_update_coalesce_intrl(structice_q_vector*q_vector,+u16stored_intrl_setting){-structice_ring_container*rx_rc=&q_vector->rx;-structice_ring_container*tx_rc=&q_vector->tx;structice_hw*hw=&q_vector->vsi->back->hw;-tx_rc->itr_setting=coalesce->itr_tx;-rx_rc->itr_setting=coalesce->itr_rx;--/* dynamic ITR values will be updated during Tx/Rx */-if(!ITR_IS_DYNAMIC(tx_rc->itr_setting))-wr32(hw,GLINT_ITR(tx_rc->itr_idx,q_vector->reg_idx),-ITR_REG_ALIGN(tx_rc->itr_setting)>>-ICE_ITR_GRAN_S);-if(!ITR_IS_DYNAMIC(rx_rc->itr_setting))-wr32(hw,GLINT_ITR(rx_rc->itr_idx,q_vector->reg_idx),-ITR_REG_ALIGN(rx_rc->itr_setting)>>-ICE_ITR_GRAN_S);--q_vector->intrl=coalesce->intrl;+q_vector->intrl=stored_intrl_setting;wr32(hw,GLINT_RATE(q_vector->reg_idx),ice_intrl_usec_to_reg(q_vector->intrl,hw->intrl_gran));}+/**+*ice_vsi_rebuild_update_coalesce_itr-setcoalesceforaq_vector+*@q_vector:pointertoq_vectorwhichisbeingupdated+*@rc:pointertoringcontainer+*@stored_itr_setting:originalITRsetting+*+*Setcoalesceparaminq_vectorandupdatetheseparametersinHW.+*/+staticvoid+ice_vsi_rebuild_update_coalesce_itr(structice_q_vector*q_vector,+structice_ring_container*rc,+u16stored_itr_setting)+{+structice_hw*hw=&q_vector->vsi->back->hw;++rc->itr_setting=stored_itr_setting;++/* dynamic ITR values will be updated during Tx/Rx */+if(!ITR_IS_DYNAMIC(rc->itr_setting))+wr32(hw,GLINT_ITR(rc->itr_idx,q_vector->reg_idx),+ITR_REG_ALIGN(rc->itr_setting)>>ICE_ITR_GRAN_S);+}+/***ice_vsi_rebuild_get_coalesce-getcoalescefromallq_vectors*@vsi:VSIconnectedwithq_vectors
@@ -2893,17 +2906,59 @@ ice_vsi_rebuild_set_coalesce(struct ice_vsi *vsi,if((size&&!coalesce)||!vsi)return;-for(i=0;i<size&&i<vsi->num_q_vectors;i++)-ice_vsi_rebuild_update_coalesce(vsi->q_vectors[i],-&coalesce[i]);--/* number of q_vectors increased, so assume coalesce settings were-*changedglobally(i.e.ethtool-Ceth0insteadofper-queue)anduse-*theprevioussettingsfromq_vector0forallofthenewq_vectors+/* There are a couple of cases that have to be handled here:+*1.Thecasewherethenumberofqueuevectorsstaysthesame,but+*thenumberofTxorRxringschanges(thefirstforloop)+*2.Thecasewherethenumberofqueuevectorsincreased(the+*secondforloop)*/-for(;i<vsi->num_q_vectors;i++)-ice_vsi_rebuild_update_coalesce(vsi->q_vectors[i],-&coalesce[0]);+for(i=0;i<size&&i<vsi->num_q_vectors;i++){+/* There are 2 cases to handle here and they are the same for+*bothTxandRx:+*iftheentrywasvalidpreviously(coalesce[i].[tr]x_valid+*andtheloopvariableislessthanthenumberofrings+*allocated,thenwritethepreviousvalues+*+*iftheentrywasnotvalidpreviously,butthenumberof+*ringsislessthanareallocated(thismeansthenumberof+*ringsincreasedfrompreviously),thenwriteoutthe+*valuesinthefirstelement+*/+if(i<vsi->alloc_rxq&&coalesce[i].rx_valid)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->rx,+coalesce[i].itr_rx);+elseif(i<vsi->alloc_rxq)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->rx,+coalesce[0].itr_rx);++if(i<vsi->alloc_txq&&coalesce[i].tx_valid)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->tx,+coalesce[i].itr_tx);+elseif(i<vsi->alloc_txq)+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->tx,+coalesce[0].itr_tx);++ice_vsi_rebuild_update_coalesce_intrl(vsi->q_vectors[i],+coalesce[i].intrl);+}++/* the number of queue vectors increased so write whatever is in+*thefirstelement+*/+for(;i<vsi->num_q_vectors;i++){+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->tx,+coalesce[0].itr_tx);+ice_vsi_rebuild_update_coalesce_itr(vsi->q_vectors[i],+&vsi->q_vectors[i]->rx,+coalesce[0].itr_rx);+ice_vsi_rebuild_update_coalesce_intrl(vsi->q_vectors[i],+coalesce[0].intrl);+}}/**
@@ -2932,9 +2987,11 @@ int ice_vsi_rebuild(struct ice_vsi *vsi, bool init_vsi)coalesce=kcalloc(vsi->num_q_vectors,sizeof(structice_coalesce_stored),GFP_KERNEL);-if(coalesce)-prev_num_q_vectors=ice_vsi_rebuild_get_coalesce(vsi,-coalesce);+if(!coalesce)+return-ENOMEM;++prev_num_q_vectors=ice_vsi_rebuild_get_coalesce(vsi,coalesce);+ice_rm_vsi_lan_cfg(vsi->port_info,vsi->idx);ice_vsi_free_q_vectors(vsi);
@@ -351,6 +351,8 @@ struct ice_coalesce_stored {u16itr_tx;u16itr_rx;u8intrl;+u8tx_valid;+u8rx_valid;};/* iterator for handling rings in ring container */
From: Phillip Potter <phil@philpotter.co.uk>
[ Upstream commit bd78980be1a68d14524c51c4b4170782fada622b ]
Use memset to initialize local array in drivers/net/usb/ax88179_178a.c, and
also set a local u16 and u32 variable to 0. Fixes a KMSAN found uninit-value bug
reported by syzbot at:
https://syzkaller.appspot.com/bug?id=00371c73c72f72487c1d0bfe0cc9d00de339d5aa
Reported-by: syzbot+4993e4a0e237f1b53747@syzkaller.appspotmail.com
Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/usb/ax88179_178a.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
@@ -1296,6 +1296,8 @@ static void ax88179_get_mac_addr(struct usbnet *dev){u8mac[ETH_ALEN];+memset(mac,0,sizeof(mac));+/* Maybe the boot loader passed the MAC address via device tree */if(!eth_platform_get_mac_address(&dev->udev->dev,mac)){netif_dbg(dev,ifup,dev->net,
From: Matthieu Baerts <redacted>
[ Upstream commit 5888a61cb4e00695075bbacfd86f3fa73af00413 ]
'mptcp_connect' already has a timeout for poll() but in some cases, it
is not enough.
With "timeout" tool, we will force the command to fail if it doesn't
finish on time. Thanks to that, the script will continue and display
details about the current state before marking the test as failed.
Displaying this state is very important to be able to understand the
issue. Best to have our CI reporting the issue than just "the test
hanged".
Note that in mptcp_connect.sh, we were using a long timeout to validate
the fact we cannot create a socket if a sysctl is set. We don't need
this timeout.
In diag.sh, we want to send signals to mptcp_connect instances that have
been started in the netns. But we cannot send this signal to 'timeout'
otherwise that will stop the timeout and messages telling us SIGUSR1 has
been received will be printed. Instead of trying to find the right PID
and storing them in an array, we can simply use the output of
'ip netns pids' which is all the PIDs we want to send signal to.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/160
Signed-off-by: Matthieu Baerts <redacted>
Signed-off-by: Mat Martineau <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/net/mptcp/diag.sh | 55 ++++++++++++-------
.../selftests/net/mptcp/mptcp_connect.sh | 15 +++--
.../testing/selftests/net/mptcp/mptcp_join.sh | 22 ++++++--
.../selftests/net/mptcp/simult_flows.sh | 13 ++++-
4 files changed, 72 insertions(+), 33 deletions(-)
@@ -14,18 +15,14 @@ flush_pids()# give it some timesleep1.1-forpidin${pids[@]};do-[-d/proc/$pid]&&kill-SIGUSR1$pid>/dev/null2>&1-done-pids=()+ipnetnspids"${ns}"|xargs--no-run-if-emptykill-SIGUSR1&>/dev/null} cleanup(){+ipnetnspids"${ns}"|xargs--no-run-if-emptykill-SIGKILL&>/dev/null+ipnetnsdel$ns-forpidin${pids[@]};do-[-d/proc/$pid]&&kill-9$pid>/dev/null2>&1-done} ip-Version>/dev/null2>&1
From: Daniel Winkler <redacted>
[ Upstream commit b6f1b79deabd32f89adbf24ef7b30f82d029808a ]
We set hdev->cur_adv_instance in the adv param MGMT request to allow the
callback to the hci param request to set the tx power to the correct
instance. Now that the callbacks use the advertising handle from the hci
request (as they should), this workaround is no longer necessary.
Furthermore, this change resolves a race condition that is more
prevalent when using the extended advertising MGMT calls - if
hdev->cur_adv_instance is set in the params request, then when the data
request is called, we believe our new instance is already active. This
treats it as an update and immediately schedules the instance with the
controller, which has a potential race with the software rotation adv
update. By not setting hdev->cur_adv_instance too early, the new
instance is queued as it should be, to be used when the rotation comes
around again.
This change is tested on harrison peak to confirm that it resolves the
race condition on registration, and that there is no regression in
single- and multi-advertising automated tests.
Reviewed-by: Miao-chen Chou <redacted>
Signed-off-by: Daniel Winkler <redacted>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bluetooth/mgmt.c | 1 -
1 file changed, 1 deletion(-)
From: Johan Almbladh <johan.almbladh@anyfinetworks.com>
[ Upstream commit 96a7109a16665255b65d021e24141c2edae0e202 ]
Some drivers, for example mt76, use the skb priority field, and
expects that to be consistent with the skb queue mapping. On some
frame injection code paths that was not true, and it broke frame
injection. Now the skb queue mapping is set according to the skb
priority value when the frame is injected. The skb priority value
is also derived from the frame data for all frame types, as it
was done prior to commit dbd50a851c50 (only allocate one queue
when using iTXQs). Fixes frame injection with the mt76 driver on
MT7610E chipset.
Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com>
Link: https://lore.kernel.org/r/20210401164455.978245-1-johan.almbladh@anyfinetworks.com
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/tx.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
@@ -2267,17 +2267,6 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,payload[7]);}-/* Initialize skb->priority for QoS frames. If the DONT_REORDER flag-*isset,sticktothedefaultvalueforskb->prioritytoassure-*framesinjectedwiththisflagarenotreorderedrelativetoeach-*other.-*/-if(ieee80211_is_data_qos(hdr->frame_control)&&-!(info->control.flags&IEEE80211_TX_CTRL_DONT_REORDER)){-u8*p=ieee80211_get_qos_ctl(hdr);-skb->priority=*p&IEEE80211_QOS_CTL_TAG1D_MASK;-}-rcu_read_lock();/*
@@ -2341,6 +2330,15 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,info->band=chandef->chan->band;+/* Initialize skb->priority according to frame type and TID class,+*withrespecttothesubinterfacethattheframewillactually+*betransmittedon.IftheDONT_REORDERflagisset,theoriginal+*skb-priorityispreservedtoassureframesinjectedwiththis+*flagarenotreorderedrelativetoeachother.+*/+ieee80211_select_queue_80211(sdata,skb,hdr);+skb_set_queue_mapping(skb,ieee80211_ac_from_tid(skb->priority));+/* remove the injection radiotap header */skb_pull(skb,len_rthdr);
From: Emmanuel Grumbach <redacted>
[ Upstream commit d6843d1ee283137723b4a8c76244607ce6db1951 ]
After channel switch, we should consider any beacon with a
CSA IE as a new switch. If the CSA IE is a leftover from
before the switch that the AP forgot to remove, we'll get
a CSA-to-Self.
This caused issues in iwlwifi where the firmware saw a beacon
with a CSA-to-Self with mode = 1 on the new channel after a
switch. The firmware considered this a new switch and closed
its queues. Since the beacon didn't change between before and
after the switch, we wouldn't handle it (the CRC is the same)
and we wouldn't let the firmware open its queues again or
disconnect if the CSA IE stays for too long.
Clear the CRC valid state after we switch to make sure that
we handle the beacon and handle the CSA IE as required.
Signed-off-by: Emmanuel Grumbach <redacted>
Link: https://lore.kernel.org/r/20210408143124.b9e68aa98304.I465afb55ca2c7d59f7bf610c6046a1fd732b4c28@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 5 +++++
1 file changed, 5 insertions(+)
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit fba863b816049b03f3fbb07b10ebdcfe5c4141f7 ]
Resume callback of the PHY driver is called after the one for the MAC
driver. The PHY driver resume callback calls phy_init_hw(), and this is
potentially problematic if the MAC driver calls phy_start() in its resume
callback. One issue was reported with the fec driver and a KSZ8081 PHY
which seems to become unstable if a soft reset is triggered during aneg.
The new flag allows MAC drivers to indicate that they take care of
suspending/resuming the PHY. Then the MAC PM callbacks can handle
any dependency between MAC and PHY PM.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/phy/phy_device.c | 6 ++++++
include/linux/phy.h | 2 ++
2 files changed, 8 insertions(+)
@@ -273,6 +273,9 @@ static __maybe_unused int mdio_bus_phy_suspend(struct device *dev){structphy_device*phydev=to_phy_device(dev);+if(phydev->mac_managed_pm)+return0;+/* We must stop the state machine manually, otherwise it stops out of*control,possiblywiththephydev->lockheld.Uponresume,netdev*maycallphyroutinesthattrytograbthesamelock,andthatmay
@@ -294,6 +297,9 @@ static __maybe_unused int mdio_bus_phy_resume(struct device *dev)structphy_device*phydev=to_phy_device(dev);intret;+if(phydev->mac_managed_pm)+return0;+if(!phydev->suspended_by_mdio_bus)gotono_resume;
@@ -567,6 +568,7 @@ struct phy_device {unsignedloopback_enabled:1;unsigneddownshifted_rate:1;unsignedis_on_sfp_module:1;+unsignedmac_managed_pm:1;unsignedautoneg:1;/* The most recently read link state */
From: Heiner Kallweit <hkallweit1@gmail.com>
[ Upstream commit 557d5dc83f6831b4e54d141e9b121850406f9a60 ]
Use the new mac_managed_pm flag to work around an issue with KSZ8081 PHY
that becomes unstable when a soft reset is triggered during aneg.
Reported-by: Joakim Zhang <redacted>
Tested-by: Joakim Zhang <redacted>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/freescale/fec_main.c | 3 +++
1 file changed, 3 insertions(+)
From: Sander Vanheule <sander@svanheule.net>
[ Upstream commit 858ebf446bee7d5077bd99488aae617908c3f4fe ]
EEPROM blobs for MT7613BE radios start with (little endian) 0x7663,
which is also the PCI device ID for this device. The EEPROM is required
for the radio to work at useful power levels, otherwise only the lowest
power level is available.
Suggested-by: Georgi Vlaev <redacted>
Tested-by: Stijn Segers <redacted>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c | 1 +
1 file changed, 1 insertion(+)
From: Felix Fietkau <nbd@nbd.name>
[ Upstream commit 730d6d0da8d8f5905faafe645a5b3c08ac3f5a8f ]
There were multiple issues in the current key set/remove code:
- deleting a key with the previous key index deletes the current key
- BIP key would only be uploaded correctly initially and corrupted on rekey
Rework the code to better keep track of multiple keys and check for the
key index before deleting the current key
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
.../net/wireless/mediatek/mt76/mt7615/mac.c | 97 ++++++++++---------
.../net/wireless/mediatek/mt76/mt7615/main.c | 18 ++--
3 files changed, 65 insertions(+), 51 deletions(-)
@@ -337,7 +337,8 @@ static int mt7615_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,structmt7615_sta*msta=sta?(structmt7615_sta*)sta->drv_priv:&mvif->sta;structmt76_wcid*wcid=&msta->wcid;-intidx=key->keyidx,err;+intidx=key->keyidx,err=0;+u8*wcid_keyidx=&wcid->hw_key_idx;/* The hardware does not support per-STA RX GTK, fallback*tosoftwaremodeforthese.
@@ -352,6 +353,7 @@ static int mt7615_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,/* fall back to sw encryption for unsupported ciphers */switch(key->cipher){caseWLAN_CIPHER_SUITE_AES_CMAC:+wcid_keyidx=&wcid->hw_key_idx2;key->flags|=IEEE80211_KEY_FLAG_GENERATE_MMIE;break;caseWLAN_CIPHER_SUITE_TKIP:
From: David Bauer <redacted>
[ Upstream commit 4b36cc6b390f18dbc59a45fb4141f90d7dfe2b23 ]
When operating two VAP on a MT7610 with encryption (PSK2, SAE, OWE),
only the first one to be created will transmit properly encrypteded
frames.
All subsequently created VAPs will sent out frames with the payload left
unencrypted, breaking multicast traffic (ICMP6 NDP) and potentially
disclosing information to a third party.
Disable GTK offloading and encrypt these frames in software to
circumvent this issue. THis only seems to be necessary on MT7610 chips,
as MT7612 is not affected from our testing.
Signed-off-by: David Bauer <redacted>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76x02_util.c | 4 ++++
1 file changed, 4 insertions(+)
@@ -447,6 +447,10 @@ int mt76x02_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,!(key->flags&IEEE80211_KEY_FLAG_PAIRWISE))return-EOPNOTSUPP;+/* MT76x0 GTK offloading does not work with more than one VIF */+if(is_mt76x0(dev)&&!(key->flags&IEEE80211_KEY_FLAG_PAIRWISE))+return-EOPNOTSUPP;+msta=sta?(structmt76x02_sta*)sta->drv_priv:NULL;wcid=msta?&msta->wcid:&mvif->group_wcid;
From: Lorenzo Bianconi <lorenzo@kernel.org>
[ Upstream commit baa3afb39e94965f4ca5b5d3d274379504b8fa24 ]
Even if this is not a real bug since mt76_connac_mcu_alloc_wtbl_req routine
can fails just if nskb is NULL , always check return value from
mt76_connac_mcu_alloc_wtbl_req in order to avoid possible future
mistake.
Reported-by: Dan Carpenter <redacted>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 3 +++
drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 3 +++
2 files changed, 6 insertions(+)
From: Lorenzo Bianconi <lorenzo@kernel.org>
[ Upstream commit 45f93e368211fbbd247e1ece254ffb121e20fa10 ]
As done for mt76_connac_mcu_alloc_wtbl_req, even if this is not a real
bug since mt7915_mcu_alloc_wtbl_req routine can fails just if nskb is NULL,
always check return value from mt7915_mcu_alloc_wtbl_req in order to avoid
possible future mistake.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
From: Felix Fietkau <nbd@nbd.name>
[ Upstream commit 1da4fd48d28436f8b690cdc2879603dede6d8355 ]
Deleting a key with the previous key index deletes the current key
Rework the code to better keep track of multiple keys and check for the
key index before deleting the current key
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7915/main.c | 25 +++++++++++++------
1 file changed, 18 insertions(+), 7 deletions(-)
@@ -317,7 +317,9 @@ static int mt7915_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,structmt7915_sta*msta=sta?(structmt7915_sta*)sta->drv_priv:&mvif->sta;structmt76_wcid*wcid=&msta->wcid;+u8*wcid_keyidx=&wcid->hw_key_idx;intidx=key->keyidx;+interr=0;/* The hardware does not support per-STA RX GTK, fallback*tosoftwaremodeforthese.
@@ -332,6 +334,7 @@ static int mt7915_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,/* fall back to sw encryption for unsupported ciphers */switch(key->cipher){caseWLAN_CIPHER_SUITE_AES_CMAC:+wcid_keyidx=&wcid->hw_key_idx2;key->flags|=IEEE80211_KEY_FLAG_GENERATE_MMIE;break;caseWLAN_CIPHER_SUITE_TKIP:
From: Lorenzo Bianconi <lorenzo@kernel.org>
[ Upstream commit 60468f7fd7072c804b2613f1cadabace8d77d311 ]
Similar to the mt7915 driver, deleting a key with the previous key index
deletes the current key. Rework the code to better keep track of
multiple keys and check for the key index before deleting the current
key
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7921/main.c | 25 +++++++++++++------
1 file changed, 17 insertions(+), 8 deletions(-)
@@ -413,7 +413,8 @@ static int mt7921_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,structmt7921_sta*msta=sta?(structmt7921_sta*)sta->drv_priv:&mvif->sta;structmt76_wcid*wcid=&msta->wcid;-intidx=key->keyidx;+u8*wcid_keyidx=&wcid->hw_key_idx;+intidx=key->keyidx,err=0;/* The hardware does not support per-STA RX GTK, fallback*tosoftwaremodeforthese.
From: Ryder Lee <ryder.lee@mediatek.com>
[ Upstream commit e07419a7dca97dd9bddfe5d099380857c19535f3 ]
Reset wifi subsystem when MCU is already running.
Fixes firmware download failure after soft reboot on systems where the PCIe
reset could not be performed properly.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7915/init.c | 58 ++++++++++++++++++-
.../net/wireless/mediatek/mt76/mt7915/mcu.c | 15 +----
.../net/wireless/mediatek/mt76/mt7915/regs.h | 13 +++++
3 files changed, 70 insertions(+), 16 deletions(-)
@@ -283,9 +284,50 @@ static void mt7915_init_work(struct work_struct *work)mt7915_register_ext_phy(dev);}+staticvoidmt7915_wfsys_reset(structmt7915_dev*dev)+{+u32val=MT_TOP_PWR_KEY|MT_TOP_PWR_SW_PWR_ON|MT_TOP_PWR_PWR_ON;+u32reg=mt7915_reg_map_l1(dev,MT_TOP_MISC);++#define MT_MCU_DUMMY_RANDOM GENMASK(15, 0)+#define MT_MCU_DUMMY_DEFAULT GENMASK(31, 16)++mt76_wr(dev,MT_MCU_WFDMA0_DUMMY_CR,MT_MCU_DUMMY_RANDOM);++/* change to software control */+val|=MT_TOP_PWR_SW_RST;+mt76_wr(dev,MT_TOP_PWR_CTRL,val);++/* reset wfsys */+val&=~MT_TOP_PWR_SW_RST;+mt76_wr(dev,MT_TOP_PWR_CTRL,val);++/* release wfsys then mcu re-excutes romcode */+val|=MT_TOP_PWR_SW_RST;+mt76_wr(dev,MT_TOP_PWR_CTRL,val);++/* switch to hw control */+val&=~MT_TOP_PWR_SW_RST;+val|=MT_TOP_PWR_HW_CTRL;+mt76_wr(dev,MT_TOP_PWR_CTRL,val);++/* check whether mcu resets to default */+if(!mt76_poll_msec(dev,MT_MCU_WFDMA0_DUMMY_CR,MT_MCU_DUMMY_DEFAULT,+MT_MCU_DUMMY_DEFAULT,1000)){+dev_err(dev->mt76.dev,"wifi subsystem reset failure\n");+return;+}++/* wfsys reset won't clear host registers */+mt76_clear(dev,reg,MT_TOP_MISC_FW_STATE);++msleep(100);+}+staticintmt7915_init_hardware(structmt7915_dev*dev){intret,idx;+u32val;mt76_wr(dev,MT_INT_SOURCE_CSR,~0);
@@ -295,6 +337,12 @@ static int mt7915_init_hardware(struct mt7915_dev *dev)dev->dbdc_support=!!(mt7915_l1_rr(dev,MT_HW_BOUND)&BIT(5));+val=mt76_rr(dev,mt7915_reg_map_l1(dev,MT_TOP_MISC));++/* If MCU was already running, it is likely in a bad state */+if(FIELD_GET(MT_TOP_MISC_FW_STATE,val)>FW_STATE_FW_DOWNLOAD)+mt7915_wfsys_reset(dev);+ret=mt7915_dma_init(dev);if(ret)returnret;
@@ -308,8 +356,14 @@ static int mt7915_init_hardware(struct mt7915_dev *dev)mt76_wr(dev,MT_SWDEF_MODE,MT_SWDEF_NORMAL_MODE);ret=mt7915_mcu_init(dev);-if(ret)-returnret;+if(ret){+/* Reset and try again */+mt7915_wfsys_reset(dev);++ret=mt7915_mcu_init(dev);+if(ret)+returnret;+}ret=mt7915_eeprom_init(dev);if(ret<0)
@@ -2754,21 +2754,8 @@ static int mt7915_load_ram(struct mt7915_dev *dev)staticintmt7915_load_firmware(structmt7915_dev*dev){+u32reg=mt7915_reg_map_l1(dev,MT_TOP_MISC);intret;-u32val,reg=mt7915_reg_map_l1(dev,MT_TOP_MISC);--val=FIELD_PREP(MT_TOP_MISC_FW_STATE,FW_STATE_FW_DOWNLOAD);--if(!mt76_poll_msec(dev,reg,MT_TOP_MISC_FW_STATE,val,1000)){-/* restart firmware once */-__mt76_mcu_restart(&dev->mt76);-if(!mt76_poll_msec(dev,reg,MT_TOP_MISC_FW_STATE,-val,1000)){-dev_err(dev->mt76.dev,-"Firmware is not ready for download\n");-return-EIO;-}-}ret=mt7915_load_patch(dev);if(ret)
From: Johannes Berg <redacted>
[ Upstream commit 48a5494d6a4cb5812f0640d9515f1876ffc7a013 ]
If we (for example) have a trans_cfg entry in the PCI IDs table,
but then don't find a full cfg entry for it in the info table,
we fall through to the code that treats the PCI ID table entry
as a full cfg entry. This obviously causes crashes later, e.g.
when trying to build the firmware name string.
Avoid such crashes by using the low bit of the pointer as a tag
for trans_cfg entries (automatically using a macro that checks
the type when assigning) and then checking that before trying to
use the data as a full entry - if it's just a partial entry at
that point, fail.
Since we're adding some macro magic, also check that the type is
in fact either struct iwl_cfg_trans_params or struct iwl_cfg,
failing compilation ("initializer element is not constant") if
it isn't.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20210330162204.6f69fe6e4128.I921d4ae20ef5276716baeeeda0b001cf25b9b968@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 35 +++++++++++++++----
1 file changed, 28 insertions(+), 7 deletions(-)
@@ -17,10 +17,20 @@#include"iwl-prph.h"#include"internal.h"+#define TRANS_CFG_MARKER BIT(0)+#define _IS_A(cfg, _struct) __builtin_types_compatible_p(typeof(cfg), \+struct_struct)+externint_invalid_type;+#define _TRANS_CFG_MARKER(cfg) \+(__builtin_choose_expr(_IS_A(cfg,iwl_cfg_trans_params),\+TRANS_CFG_MARKER,\+__builtin_choose_expr(_IS_A(cfg,iwl_cfg),0,_invalid_type)))+#define _ASSIGN_CFG(cfg) (_TRANS_CFG_MARKER(cfg) + (kernel_ulong_t)&(cfg))+#define IWL_PCI_DEVICE(dev, subdev, cfg) \.vendor=PCI_VENDOR_ID_INTEL,.device=(dev),\.subvendor=PCI_ANY_ID,.subdevice=(subdev),\-.driver_data=(kernel_ulong_t)&(cfg)+.driver_data=_ASSIGN_CFG(cfg)/* Hardware specific file defines the PCI IDs table for that hardware module */staticconststructpci_device_idiwl_hw_card_ids[]={
@@ -1075,19 +1085,22 @@ static const struct iwl_dev_info iwl_dev_info_table[] = {staticintiwl_pci_probe(structpci_dev*pdev,conststructpci_device_id*ent){-conststructiwl_cfg_trans_params*trans=-(structiwl_cfg_trans_params*)(ent->driver_data);+conststructiwl_cfg_trans_params*trans;conststructiwl_cfg*cfg_7265d__maybe_unused=NULL;structiwl_trans*iwl_trans;structiwl_trans_pcie*trans_pcie;inti,ret;+conststructiwl_cfg*cfg;++trans=(void*)(ent->driver_data&~TRANS_CFG_MARKER);+/**Thisisneededforbackwardscompatibilitywiththeold*tables,sowedon'tneedtochangealltheconfigstructs*atthesametime.Thecfgisusedtocomparewiththeold*fullcfgstructs.*/-conststructiwl_cfg*cfg=(structiwl_cfg*)(ent->driver_data);+cfg=(void*)(ent->driver_data&~TRANS_CFG_MARKER);/* make sure trans is the first element in iwl_cfg */BUILD_BUG_ON(offsetof(structiwl_cfg,trans));
@@ -1202,11 +1215,19 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)#endif/*-*Ifwedidn'tsetthecfgyet,assumethetransisactually-*afullcfgfromtheoldtables.+*Ifwedidn'tsetthecfgyet,thePCIIDtableentryshouldhave+*beenafullconfig-ifyes,useit,otherwisefail.*/-if(!iwl_trans->cfg)+if(!iwl_trans->cfg){+if(ent->driver_data&TRANS_CFG_MARKER){+pr_err("No config found for PCI dev %04x/%04x, rev=0x%x, rfid=0x%x\n",+pdev->device,pdev->subsystem_device,+iwl_trans->hw_rev,iwl_trans->hw_rf_id);+ret=-EINVAL;+gotoout_free_trans;+}iwl_trans->cfg=cfg;+}/* if we don't have a name yet, copy name from the old cfg */if(!iwl_trans->name)
From: Mordechay Goodstein <redacted>
[ Upstream commit 4cf2f5904d971a461f67825434ae3c31900ff84b ]
In case the device is stopped any usage of hw queues needs to be
reallocated in fw due to fw reset after device stop, so all driver
internal queue should also be freed, and if we don't free the next usage
would leak the old memory and get in recover flows
"iwlwifi 0000:00:03.0: dma_pool_destroy iwlwifi:bc" warning.
Also warn about trying to reuse an internal allocated queue.
Signed-off-by: Mordechay Goodstein <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20210411124417.c72d2f0355c4.Ia3baff633b9b9109f88ab379ef0303aa152c16bf@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../wireless/intel/iwlwifi/pcie/trans-gen2.c | 4 +--
drivers/net/wireless/intel/iwlwifi/queue/tx.c | 30 ++++---------------
drivers/net/wireless/intel/iwlwifi/queue/tx.h | 3 +-
3 files changed, 9 insertions(+), 28 deletions(-)
@@ -1,7 +1,7 @@// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause/**Copyright(C)2017IntelDeutschlandGmbH-*Copyright(C)2018-2020IntelCorporation+*Copyright(C)2018-2021IntelCorporation*/#include"iwl-trans.h"#include"iwl-prph.h"
@@ -143,7 +143,7 @@ void _iwl_trans_pcie_gen2_stop_device(struct iwl_trans *trans)if(test_and_clear_bit(STATUS_DEVICE_ENABLED,&trans->status)){IWL_DEBUG_INFO(trans,"DEVICE_ENABLED bit was set and is now cleared\n");-iwl_txq_gen2_tx_stop(trans);+iwl_txq_gen2_tx_free(trans);iwl_pcie_rx_stop(trans);}
@@ -13,30 +13,6 @@#include"iwl-scd.h"#include<linux/dmapool.h>-/*-*iwl_txq_gen2_tx_stop-StopallTxDMAchannels-*/-voidiwl_txq_gen2_tx_stop(structiwl_trans*trans)-{-inttxq_id;--/*-*Thisfunctioncanbecalledbeforetheop_modedisabledthe-*queues.Thishappenswhenwehaveanrfkillinterrupt.-*SincewestopTxaltogether-markthequeuesasstopped.-*/-memset(trans->txqs.queue_stopped,0,-sizeof(trans->txqs.queue_stopped));-memset(trans->txqs.queue_used,0,sizeof(trans->txqs.queue_used));--/* Unmap DMA from host system and free skb's */-for(txq_id=0;txq_id<ARRAY_SIZE(trans->txqs.txq);txq_id++){-if(!trans->txqs.txq[txq_id])-continue;-iwl_txq_gen2_unmap(trans,txq_id);-}-}-/**iwl_txq_update_byte_tbl-SetupentryinTxbyte-countarray*/
From: Johannes Berg <redacted>
[ Upstream commit d12455fdbfe9430affd88bfbfee51777356667a0 ]
In a few PCIe devices we may have to swap out the configuration
after we allocate/initialise some parts of the device because
we only know the correct one after reading some registers. This
causes some things such as the byte-count table allocations to
be incorrect, since the configuration is swapped for one with a
bigger queue size.
Fix this by initialising most of the transport much later, only
after the configuration has finally been determined.
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20210411132130.8f5db97db1e4.Ic622da559b586a04ca536a0ec49ed5ecf03a9354@changeid
Signed-off-by: Luca Coelho <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/intel/iwlwifi/iwl-trans.c | 91 +++++++++++--------
.../net/wireless/intel/iwlwifi/iwl-trans.h | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 4 +
3 files changed, 57 insertions(+), 39 deletions(-)
@@ -21,7 +21,6 @@ struct iwl_trans *iwl_trans_alloc(unsigned int priv_size,conststructiwl_cfg_trans_params*cfg_trans){structiwl_trans*trans;-inttxcmd_size,txcmd_align;#ifdef CONFIG_LOCKDEPstaticstructlock_class_key__key;#endif
@@ -31,10 +30,40 @@ struct iwl_trans *iwl_trans_alloc(unsigned int priv_size,returnNULL;trans->trans_cfg=cfg_trans;-if(!cfg_trans->gen2){++#ifdef CONFIG_LOCKDEP+lockdep_init_map(&trans->sync_cmd_lockdep_map,"sync_cmd_lockdep_map",+&__key,0);+#endif++trans->dev=dev;+trans->ops=ops;+trans->num_rx_queues=1;++WARN_ON(!ops->wait_txq_empty&&!ops->wait_tx_queues_empty);++if(trans->trans_cfg->use_tfh){+trans->txqs.tfd.addr_size=64;+trans->txqs.tfd.max_tbs=IWL_TFH_NUM_TBS;+trans->txqs.tfd.size=sizeof(structiwl_tfh_tfd);+}else{+trans->txqs.tfd.addr_size=36;+trans->txqs.tfd.max_tbs=IWL_NUM_OF_TBS;+trans->txqs.tfd.size=sizeof(structiwl_tfd);+}+trans->max_skb_frags=IWL_TRANS_MAX_FRAGS(trans);++returntrans;+}++intiwl_trans_init(structiwl_trans*trans)+{+inttxcmd_size,txcmd_align;++if(!trans->trans_cfg->gen2){txcmd_size=sizeof(structiwl_tx_cmd);txcmd_align=sizeof(void*);-}elseif(cfg_trans->device_family<IWL_DEVICE_FAMILY_AX210){+}elseif(trans->trans_cfg->device_family<IWL_DEVICE_FAMILY_AX210){txcmd_size=sizeof(structiwl_tx_cmd_gen2);txcmd_align=64;}else{
@@ -46,17 +75,8 @@ struct iwl_trans *iwl_trans_alloc(unsigned int priv_size,txcmd_size+=36;/* biggest possible 802.11 header *//* Ensure device TX cmd cannot reach/cross a page boundary in gen2 */-if(WARN_ON(cfg_trans->gen2&&txcmd_size>=txcmd_align))-returnERR_PTR(-EINVAL);--#ifdef CONFIG_LOCKDEP-lockdep_init_map(&trans->sync_cmd_lockdep_map,"sync_cmd_lockdep_map",-&__key,0);-#endif--trans->dev=dev;-trans->ops=ops;-trans->num_rx_queues=1;+if(WARN_ON(trans->trans_cfg->gen2&&txcmd_size>=txcmd_align))+return-EINVAL;if(trans->trans_cfg->device_family>=IWL_DEVICE_FAMILY_AX210)trans->txqs.bc_tbl_size=sizeof(structiwl_gen3_bc_tbl);
@@ -68,23 +88,16 @@ struct iwl_trans *iwl_trans_alloc(unsigned int priv_size,*allocatehere.*/if(trans->trans_cfg->gen2){-trans->txqs.bc_pool=dmam_pool_create("iwlwifi:bc",dev,+trans->txqs.bc_pool=dmam_pool_create("iwlwifi:bc",trans->dev,trans->txqs.bc_tbl_size,256,0);if(!trans->txqs.bc_pool)-returnNULL;+return-ENOMEM;}-if(trans->trans_cfg->use_tfh){-trans->txqs.tfd.addr_size=64;-trans->txqs.tfd.max_tbs=IWL_TFH_NUM_TBS;-trans->txqs.tfd.size=sizeof(structiwl_tfh_tfd);-}else{-trans->txqs.tfd.addr_size=36;-trans->txqs.tfd.max_tbs=IWL_NUM_OF_TBS;-trans->txqs.tfd.size=sizeof(structiwl_tfd);-}-trans->max_skb_frags=IWL_TRANS_MAX_FRAGS(trans);+/* Some things must not change even if the config does */+WARN_ON(trans->txqs.tfd.addr_size!=+(trans->trans_cfg->use_tfh?64:36));snprintf(trans->dev_cmd_pool_name,sizeof(trans->dev_cmd_pool_name),"iwl_cmd_pool:%s",dev_name(trans->dev));
@@ -93,35 +106,35 @@ struct iwl_trans *iwl_trans_alloc(unsigned int priv_size,txcmd_size,txcmd_align,SLAB_HWCACHE_ALIGN,NULL);if(!trans->dev_cmd_pool)-returnNULL;--WARN_ON(!ops->wait_txq_empty&&!ops->wait_tx_queues_empty);+return-ENOMEM;trans->txqs.tso_hdr_page=alloc_percpu(structiwl_tso_hdr_page);if(!trans->txqs.tso_hdr_page){kmem_cache_destroy(trans->dev_cmd_pool);-returnNULL;+return-ENOMEM;}/* Initialize the wait queue for commands */init_waitqueue_head(&trans->wait_command_queue);-returntrans;+return0;}voidiwl_trans_free(structiwl_trans*trans){inti;-for_each_possible_cpu(i){-structiwl_tso_hdr_page*p=-per_cpu_ptr(trans->txqs.tso_hdr_page,i);+if(trans->txqs.tso_hdr_page){+for_each_possible_cpu(i){+structiwl_tso_hdr_page*p=+per_cpu_ptr(trans->txqs.tso_hdr_page,i);-if(p->page)-__free_page(p->page);-}+if(p&&p->page)+__free_page(p->page);+}-free_percpu(trans->txqs.tso_hdr_page);+free_percpu(trans->txqs.tso_hdr_page);+}kmem_cache_destroy(trans->dev_cmd_pool);}
From: Florian Fainelli <f.fainelli@gmail.com>
[ Upstream commit ae1ea84b33dab45c7b6c1754231ebda5959b504c ]
Some Ethernet switches might only be able to support disabling multicast
snooping globally, which is an issue for example when several bridges
span the same physical device and request contradictory settings.
Propagate the return value of br_mc_disabled_update() such that this
limitation is transmitted correctly to user-space.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/bridge/br_multicast.c | 28 +++++++++++++++++++++-------
net/bridge/br_netlink.c | 4 +++-
net/bridge/br_private.h | 3 ++-
net/bridge/br_sysfs_br.c | 8 +-------
4 files changed, 27 insertions(+), 16 deletions(-)
From: Yonghong Song <redacted>
[ Upstream commit 26e6dd1072763cd5696b75994c03982dde952ad9 ]
selftests/bpf/Makefile includes lib.mk. With the following command
make -j60 LLVM=1 LLVM_IAS=1 <=== compile kernel
make -j60 -C tools/testing/selftests/bpf LLVM=1 LLVM_IAS=1 V=1
some files are still compiled with gcc. This patch
fixed lib.mk issue which sets CC to gcc in all cases.
Signed-off-by: Yonghong Song <redacted>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210413153413.3027426-1-yhs@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/lib.mk | 4 ++++
1 file changed, 4 insertions(+)
@@ -1,6 +1,10 @@# This mimics the top-level Makefile. We do it explicitly here so that this# Makefile can operate with or without the kbuild infrastructure.+ifneq ($(LLVM),)+CC:=clang+elseCC:=$(CROSS_COMPILE)gcc+endififeq (0,$(MAKELEVEL)) ifeq ($(OUTPUT),)
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit e5272ad4aab347dde5610c0aedb786219e3ff793 ]
Fix the following out-of-bounds warning:
net/sctp/sm_make_chunk.c:3150:4: warning: 'memcpy' offset [17, 28] from the object at 'addr' is out of the bounds of referenced subobject 'v4' with type 'struct sockaddr_in' at offset 0 [-Warray-bounds]
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <redacted>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sctp/sm_make_chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Emmanuel Grumbach <redacted>
[ Upstream commit 253907ab8bc0818639af382f6398810fa1f022b3 ]
In case the frequency is invalid, ieee80211_parse_ch_switch_ie
will fail and we may not even reach the check in
ieee80211_sta_process_chanswitch. Drop the connection
in case ieee80211_parse_ch_switch_ie failed, but still
take into account the CSA mode to remember not to send
a deauth frame in case if it is forbidden to.
Signed-off-by: Emmanuel Grumbach <redacted>
Signed-off-by: Luca Coelho <redacted>
Link: https://lore.kernel.org/r/iwlwifi.20210409123755.34712ef96a0a.I75d7ad7f1d654e8b0aa01cd7189ff00a510512b3@changeid
Signed-off-by: Johannes Berg <redacted>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/mac80211/mlme.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
From: Du Cheng <redacted>
[ Upstream commit ed8157f1ebf1ae81a8fa2653e3f20d2076fad1c9 ]
There is a reproducible sequence from the userland that will trigger a WARN_ON()
condition in taprio_get_start_time, which causes kernel to panic if configured
as "panic_on_warn". Catch this condition in parse_taprio_schedule to
prevent this condition.
Reported as bug on syzkaller:
https://syzkaller.appspot.com/bug?extid=d50710fd0873a9c6b40c
Reported-by: syzbot+d50710fd0873a9c6b40c@syzkaller.appspotmail.com
Signed-off-by: Du Cheng <redacted>
Acked-by: Cong Wang <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/sched/sch_taprio.c | 6 ++++++
1 file changed, 6 insertions(+)
@@ -901,6 +901,12 @@ static int parse_taprio_schedule(struct taprio_sched *q, struct nlattr **tb,list_for_each_entry(entry,&new->entries,list)cycle=ktime_add_ns(cycle,entry->interval);++if(!cycle){+NL_SET_ERR_MSG(extack,"'cycle_time' can never be 0");+return-EINVAL;+}+new->cycle_time=cycle;}
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit 1e3d976dbb23b3fce544752b434bdc32ce64aabc ]
Fix the following out-of-bounds warning:
net/core/flow_dissector.c:835:3: warning: 'memcpy' offset [33, 48] from the object at 'flow_keys' is out of the bounds of referenced subobject 'ipv6_src' with type '__u32[4]' {aka 'unsigned int[4]'} at offset 16 [-Warray-bounds]
The problem is that the original code is trying to copy data into a
couple of struct members adjacent to each other in a single call to
memcpy(). So, the compiler legitimately complains about it. As these
are just a couple of members, fix this by copying each one of them in
separate calls to memcpy().
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/flow_dissector.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit c1d9e34e11281a8ba1a1c54e4db554232a461488 ]
Fix the following out-of-bounds warning:
net/ethtool/ioctl.c:492:2: warning: 'memcpy' offset [49, 84] from the object at 'link_usettings' is out of the bounds of referenced subobject 'base' with type 'struct ethtool_link_settings' at offset 0 [-Warray-bounds]
The problem is that the original code is trying to copy data into a
some struct members adjacent to each other in a single call to
memcpy(). This causes a legitimate compiler warning because memcpy()
overruns the length of &link_usettings.base. Fix this by directly
using &link_usettings and _from_ as destination and source addresses,
instead.
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ethtool/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From commit c0bbbdc32feb ("__netif_receive_skb_core: pass skb by
reference"), the first argument passed into __netif_receive_skb_core
has changed to reference of a skb pointer.
This commit fixes by using bpf_probe_read_kernel.
Signed-off-by: Yaqi Chen <redacted>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Yonghong Song <redacted>
Link: https://lore.kernel.org/bpf/20210416154803.37157-1-chendotjs@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
samples/bpf/tracex1_kern.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -26,7 +26,7 @@SEC("kprobe/__netif_receive_skb_core")intbpf_prog1(structpt_regs*ctx){-/* attaches to kprobe netif_receive_skb,+/* attaches to kprobe __netif_receive_skb_core,*looksforpacketsonloobpackdeviceandprintsthem*/chardevname[IFNAMSIZ];
@@ -35,7 +35,7 @@ int bpf_prog1(struct pt_regs *ctx)intlen;/* non-portable! works for the given kernel only */-skb=(structsk_buff*)PT_REGS_PARM1(ctx);+bpf_probe_read_kernel(&skb,sizeof(skb),(void*)PT_REGS_PARM1(ctx));dev=_(skb->dev);len=_(skb->len);
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit bb43e5718d8f1b46e7a77e7b39be3c691f293050 ]
Fix the following out-of-bounds warnings by adding a new structure
wl3501_req instead of duplicating the same members in structure
wl3501_join_req and wl3501_scan_confirm:
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [39, 108] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 36 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [25, 95] from the object at 'sig' is out of the bounds of referenced subobject 'beacon_period' with type 'short unsigned int' at offset 22 [-Warray-bounds]
Refactor the code, accordingly:
$ pahole -C wl3501_req drivers/net/wireless/wl3501_cs.o
struct wl3501_req {
u16 beacon_period; /* 0 2 */
u16 dtim_period; /* 2 2 */
u16 cap_info; /* 4 2 */
u8 bss_type; /* 6 1 */
u8 bssid[6]; /* 7 6 */
struct iw_mgmt_essid_pset ssid; /* 13 34 */
struct iw_mgmt_ds_pset ds_pset; /* 47 3 */
struct iw_mgmt_cf_pset cf_pset; /* 50 8 */
struct iw_mgmt_ibss_pset ibss_pset; /* 58 4 */
struct iw_mgmt_data_rset bss_basic_rset; /* 62 10 */
/* size: 72, cachelines: 2, members: 10 */
/* last cacheline: 8 bytes */
};
$ pahole -C wl3501_join_req drivers/net/wireless/wl3501_cs.o
struct wl3501_join_req {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 reserved; /* 3 1 */
struct iw_mgmt_data_rset operational_rset; /* 4 10 */
u16 reserved2; /* 14 2 */
u16 timeout; /* 16 2 */
u16 probe_delay; /* 18 2 */
u8 timestamp[8]; /* 20 8 */
u8 local_time[8]; /* 28 8 */
struct wl3501_req req; /* 36 72 */
/* size: 108, cachelines: 2, members: 10 */
/* last cacheline: 44 bytes */
};
$ pahole -C wl3501_scan_confirm drivers/net/wireless/wl3501_cs.o
struct wl3501_scan_confirm {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 reserved; /* 3 1 */
u16 status; /* 4 2 */
char timestamp[8]; /* 6 8 */
char localtime[8]; /* 14 8 */
struct wl3501_req req; /* 22 72 */
/* --- cacheline 1 boundary (64 bytes) was 30 bytes ago --- */
u8 rssi; /* 94 1 */
/* size: 96, cachelines: 2, members: 8 */
/* padding: 1 */
/* last cacheline: 32 bytes */
};
The problem is that the original code is trying to copy data into a
bunch of struct members adjacent to each other in a single call to
memcpy(). Now that a new struct wl3501_req enclosing all those adjacent
members is introduced, memcpy() doesn't overrun the length of
&sig.beacon_period and &this->bss_set[i].beacon_period, because the
address of the new struct object _req_ is used as the destination,
instead.
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Kees Cook <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/1fbaf516da763b50edac47d792a9145aa4482e29.1618442265.git.gustavoars@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/wl3501.h | 35 +++++++++++--------------
drivers/net/wireless/wl3501_cs.c | 44 +++++++++++++++++---------------
2 files changed, 38 insertions(+), 41 deletions(-)
From: Lee Gibson <redacted>
[ Upstream commit 130f634da1af649205f4a3dd86cbe5c126b57914 ]
Function qtnf_event_handle_external_auth calls memcpy without
checking the length.
A user could control that length and trigger a buffer overflow.
Fix by checking the length is within the maximum allowed size.
Signed-off-by: Lee Gibson <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210419145842.345787-1-leegib@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/quantenna/qtnfmac/event.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: Felix Fietkau <nbd@nbd.name>
[ Upstream commit 3f57d8c40fea9b20543cab4da12f4680d2ef182c ]
The VLAN ID in the rx descriptor is only valid if the RX_DMA_VTAG bit is
set. Fixes frames wrongly marked with VLAN tags.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[Ilya: fix commit message]
Signed-off-by: Ilya Lipnitskiy <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
From: Stefan Assmann <redacted>
[ Upstream commit 1a0e880b028f97478dc689e2900b312741d0d772 ]
Both iavf_free_all_tx_resources() and iavf_free_all_rx_resources() have
already been called in the very same function.
Remove the duplicate calls.
Signed-off-by: Stefan Assmann <redacted>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 2 --
1 file changed, 2 deletions(-)
From: David Mosberger-Tang <redacted>
[ Upstream commit a381b78a1598dde34a6e40dae2842024308a6ef2 ]
Linux network drivers normally disallow changing the MAC address when
the interface is up. This driver has been different in that it allows
to change the MAC address *only* when it's up. This patch brings
wilc1000 behavior more in line with other network drivers. We could
have replaced wilc_set_mac_addr() with eth_mac_addr() but that would
break existing documentation on how to change the MAC address.
Likewise, return -EADDRNOTAVAIL (not -EINVAL) when the specified MAC
address is invalid or unavailable.
Signed-off-by: David Mosberger-Tang <redacted>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/20210303194846.1823596-1-davidm@egauge.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/wireless/microchip/wilc1000/netdev.c | 25 ++++++++++++-------
1 file changed, 16 insertions(+), 9 deletions(-)
@@ -575,7 +575,6 @@ static int wilc_mac_open(struct net_device *ndev){structwilc_vif*vif=netdev_priv(ndev);structwilc*wl=vif->wilc;-unsignedcharmac_add[ETH_ALEN]={0};intret=0;structmgmt_frame_regsmgmt_regs={};
@@ -598,9 +597,12 @@ static int wilc_mac_open(struct net_device *ndev)wilc_set_operation_mode(vif,wilc_get_vif_idx(vif),vif->iftype,vif->idx);-wilc_get_mac_address(vif,mac_add);-netdev_dbg(ndev,"Mac address: %pM\n",mac_add);-ether_addr_copy(ndev->dev_addr,mac_add);++if(is_valid_ether_addr(ndev->dev_addr))+wilc_set_mac_address(vif,ndev->dev_addr);+else+wilc_get_mac_address(vif,ndev->dev_addr);+netdev_dbg(ndev,"Mac address: %pM\n",ndev->dev_addr);if(!is_valid_ether_addr(ndev->dev_addr)){netdev_err(ndev,"Wrong MAC address\n");
@@ -639,7 +641,14 @@ static int wilc_set_mac_addr(struct net_device *dev, void *p)intsrcu_idx;if(!is_valid_ether_addr(addr->sa_data))-return-EINVAL;+return-EADDRNOTAVAIL;++if(!vif->mac_opened){+eth_commit_mac_addr_change(dev,p);+return0;+}++/* Verify MAC Address is not already in use: */srcu_idx=srcu_read_lock(&wilc->srcu);list_for_each_entry_rcu(tmp_vif,&wilc->vif_list,list){
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
[ Upstream commit 820aa37638a252b57967bdf4038a514b1ab85d45 ]
Fix the following out-of-bounds warnings by enclosing structure members
daddr and saddr into new struct addr, in structures wl3501_md_req and
wl3501_md_ind:
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds]
arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds]
Refactor the code, accordingly:
$ pahole -C wl3501_md_req drivers/net/wireless/wl3501_cs.o
struct wl3501_md_req {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 routing; /* 3 1 */
u16 data; /* 4 2 */
u16 size; /* 6 2 */
u8 pri; /* 8 1 */
u8 service_class; /* 9 1 */
struct {
u8 daddr[6]; /* 10 6 */
u8 saddr[6]; /* 16 6 */
} addr; /* 10 12 */
/* size: 22, cachelines: 1, members: 8 */
/* last cacheline: 22 bytes */
};
$ pahole -C wl3501_md_ind drivers/net/wireless/wl3501_cs.o
struct wl3501_md_ind {
u16 next_blk; /* 0 2 */
u8 sig_id; /* 2 1 */
u8 routing; /* 3 1 */
u16 data; /* 4 2 */
u16 size; /* 6 2 */
u8 reception; /* 8 1 */
u8 pri; /* 9 1 */
u8 service_class; /* 10 1 */
struct {
u8 daddr[6]; /* 11 6 */
u8 saddr[6]; /* 17 6 */
} addr; /* 11 12 */
/* size: 24, cachelines: 1, members: 9 */
/* padding: 1 */
/* last cacheline: 24 bytes */
};
The problem is that the original code is trying to copy data into a
couple of arrays adjacent to each other in a single call to memcpy().
Now that a new struct _addr_ enclosing those two adjacent arrays
is introduced, memcpy() doesn't overrun the length of &sig.daddr[0]
and &sig.daddr, because the address of the new struct object _addr_
is used, instead.
This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().
Link: https://github.com/KSPP/linux/issues/109
Reported-by: kernel test robot <redacted>
Reviewed-by: Kees Cook <redacted>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <redacted>
Link: https://lore.kernel.org/r/d260fe56aed7112bff2be5b4d152d03ad7b78e78.1618442265.git.gustavoars@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/wl3501.h | 12 ++++++++----
drivers/net/wireless/wl3501_cs.c | 10 ++++++----
2 files changed, 14 insertions(+), 8 deletions(-)
From: Petr Machata <petrm@nvidia.com>
[ Upstream commit dda7f4fa55839baeb72ae040aeaf9ccf89d3e416 ]
The intention behind this test is to make sure that qdisc limit is
correctly projected to the HW. However, first, due to rounding in the
qdisc, and then in the driver, the number cannot actually be accurate. And
second, the approach to testing this is to oversubscribe the port with
traffic generated on the same switch. The actual backlog size therefore
fluctuates.
In practice, this test proved to be noisier than the rest, and spuriously
fails every now and then. Increase the tolerance to 10 % to avoid these
issues.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Acked-by: Jiri Pirko <redacted>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/drivers/net/mlxsw/sch_red_core.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Petr Machata <petrm@nvidia.com>
[ Upstream commit 1233898ab758cbcf5f6fea10b8dd16a0b2c24fab ]
The mirror_gre_scale test creates as many ERSPAN sessions as the underlying
chip supports, and tests that they all work. In order to determine that it
issues a stream of ICMP packets and checks if they are mirrored as
expected.
However, the mausezahn invocation missed the -6 flag to identify the use of
IPv6 protocol, and was sending ICMP messages over IPv6, as opposed to
ICMP6. It also didn't pass an explicit source IP address, which apparently
worked at some point in the past, but does not anymore.
To fix these issues, extend the function mirror_test() in mirror_lib by
detecting the IPv6 protocol addresses, and using a different ICMP scheme.
Fix __mirror_gre_test() in the selftest itself to pass a source IP address.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../drivers/net/mlxsw/mirror_gre_scale.sh | 3 ++-
.../selftests/net/forwarding/mirror_lib.sh | 19 +++++++++++++++++--
2 files changed, 19 insertions(+), 3 deletions(-)