| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fix device initialization completion handling for vNIC adapters.
Initialize the completion structure on probe and reinitialize when needed.
This also fixes a race condition during kdump where the driver can attempt
to access the completion struct before it is initialized:
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc0000000081acbe0
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: ibmvnic(+) ibmveth sunrpc overlay squashfs loop
CPU: 19 PID: 301 Comm: systemd-udevd Not tainted 4.18.0-64.el8.ppc64le #1
NIP: c0000000081acbe0 LR: c0000000081ad964 CTR: c0000000081ad900
REGS: c000000027f3f990 TRAP: 0300 Not tainted (4.18.0-64.el8.ppc64le)
MSR: 800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 28228288 XER: 00000006
CFAR: c000000008008934 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1
GPR00: c0000000081ad964 c000000027f3fc10 c0000000095b5800 c0000000221b4e58
GPR04: 0000000000000003 0000000000000001 000049a086918581 00000000000000d4
GPR08: 0000000000000007 0000000000000000 ffffffffffffffe8 d0000000014dde28
GPR12: c0000000081ad900 c000000009a00c00 0000000000000001 0000000000000100
GPR16: 0000000000000038 0000000000000007 c0000000095e2230 0000000000000006
GPR20: 0000000000400140 0000000000000001 c00000000910c880 0000000000000000
GPR24: 0000000000000000 0000000000000006 0000000000000000 0000000000000003
GPR28: 0000000000000001 0000000000000001 c0000000221b4e60 c0000000221b4e58
NIP [c0000000081acbe0] __wake_up_locked+0x50/0x100
LR [c0000000081ad964] complete+0x64/0xa0
Call Trace:
[c000000027f3fc10] [c000000027f3fc60] 0xc000000027f3fc60 (unreliable)
[c000000027f3fc60] [c0000000081ad964] complete+0x64/0xa0
[c000000027f3fca0] [d0000000014dad58] ibmvnic_handle_crq+0xce0/0x1160 [ibmvnic]
[c000000027f3fd50] [d0000000014db270] ibmvnic_tasklet+0x98/0x130 [ibmvnic]
[c000000027f3fda0] [c00000000813f334] tasklet_action_common.isra.3+0xc4/0x1a0
[c000000027f3fe00] [c000000008cd13f4] __do_softirq+0x164/0x400
[c000000027f3fef0] [c00000000813ed64] irq_exit+0x184/0x1c0
[c000000027f3ff20] [c0000000080188e8] __do_irq+0xb8/0x210
[c000000027f3ff90] [c00000000802d0a4] call_do_irq+0x14/0x24
[c000000026a5b010] [c000000008018adc] do_IRQ+0x9c/0x130
[c000000026a5b060] [c000000008008ce4] hardware_interrupt_common+0x114/0x120
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
ipip6 tunnels run iptunnel_pull_header on received skbs. This can
determine the following use-after-free accessing iph pointer since
the packet will be 'uncloned' running pskb_expand_head if it is a
cloned gso skb (e.g if the packet has been sent though a veth device)
[ 706.369655] BUG: KASAN: use-after-free in ipip6_rcv+0x1678/0x16e0 [sit]
[ 706.449056] Read of size 1 at addr ffffe01b6bd855f5 by task ksoftirqd/1/=
[ 706.669494] Hardware name: HPE ProLiant m400 Server/ProLiant m400 Server, BIOS U02 08/19/2016
[ 706.771839] Call trace:
[ 706.801159] dump_backtrace+0x0/0x2f8
[ 706.845079] show_stack+0x24/0x30
[ 706.884833] dump_stack+0xe0/0x11c
[ 706.925629] print_address_description+0x68/0x260
[ 706.982070] kasan_report+0x178/0x340
[ 707.025995] __asan_report_load1_noabort+0x30/0x40
[ 707.083481] ipip6_rcv+0x1678/0x16e0 [sit]
[ 707.132623] tunnel64_rcv+0xd4/0x200 [tunnel4]
[ 707.185940] ip_local_deliver_finish+0x3b8/0x988
[ 707.241338] ip_local_deliver+0x144/0x470
[ 707.289436] ip_rcv_finish+0x43c/0x14b0
[ 707.335447] ip_rcv+0x628/0x1138
[ 707.374151] __netif_receive_skb_core+0x1670/0x2600
[ 707.432680] __netif_receive_skb+0x28/0x190
[ 707.482859] process_backlog+0x1d0/0x610
[ 707.529913] net_rx_action+0x37c/0xf68
[ 707.574882] __do_softirq+0x288/0x1018
[ 707.619852] run_ksoftirqd+0x70/0xa8
[ 707.662734] smpboot_thread_fn+0x3a4/0x9e8
[ 707.711875] kthread+0x2c8/0x350
[ 707.750583] ret_from_fork+0x10/0x18
[ 707.811302] Allocated by task 16982:
[ 707.854182] kasan_kmalloc.part.1+0x40/0x108
[ 707.905405] kasan_kmalloc+0xb4/0xc8
[ 707.948291] kasan_slab_alloc+0x14/0x20
[ 707.994309] __kmalloc_node_track_caller+0x158/0x5e0
[ 708.053902] __kmalloc_reserve.isra.8+0x54/0xe0
[ 708.108280] __alloc_skb+0xd8/0x400
[ 708.150139] sk_stream_alloc_skb+0xa4/0x638
[ 708.200346] tcp_sendmsg_locked+0x818/0x2b90
[ 708.251581] tcp_sendmsg+0x40/0x60
[ 708.292376] inet_sendmsg+0xf0/0x520
[ 708.335259] sock_sendmsg+0xac/0xf8
[ 708.377096] sock_write_iter+0x1c0/0x2c0
[ 708.424154] new_sync_write+0x358/0x4a8
[ 708.470162] __vfs_write+0xc4/0xf8
[ 708.510950] vfs_write+0x12c/0x3d0
[ 708.551739] ksys_write+0xcc/0x178
[ 708.592533] __arm64_sys_write+0x70/0xa0
[ 708.639593] el0_svc_handler+0x13c/0x298
[ 708.686646] el0_svc+0x8/0xc
[ 708.739019] Freed by task 17:
[ 708.774597] __kasan_slab_free+0x114/0x228
[ 708.823736] kasan_slab_free+0x10/0x18
[ 708.868703] kfree+0x100/0x3d8
[ 708.905320] skb_free_head+0x7c/0x98
[ 708.948204] skb_release_data+0x320/0x490
[ 708.996301] pskb_expand_head+0x60c/0x970
[ 709.044399] __iptunnel_pull_header+0x3b8/0x5d0
[ 709.098770] ipip6_rcv+0x41c/0x16e0 [sit]
[ 709.146873] tunnel64_rcv+0xd4/0x200 [tunnel4]
[ 709.200195] ip_local_deliver_finish+0x3b8/0x988
[ 709.255596] ip_local_deliver+0x144/0x470
[ 709.303692] ip_rcv_finish+0x43c/0x14b0
[ 709.349705] ip_rcv+0x628/0x1138
[ 709.388413] __netif_receive_skb_core+0x1670/0x2600
[ 709.446943] __netif_receive_skb+0x28/0x190
[ 709.497120] process_backlog+0x1d0/0x610
[ 709.544169] net_rx_action+0x37c/0xf68
[ 709.589131] __do_softirq+0x288/0x1018
[ 709.651938] The buggy address belongs to the object at ffffe01b6bd85580
which belongs to the cache kmalloc-1024 of size 1024
[ 709.804356] The buggy address is located 117 bytes inside of
1024-byte region [ffffe01b6bd85580, ffffe01b6bd85980)
[ 709.946340] The buggy address belongs to the page:
[ 710.003824] page:ffff7ff806daf600 count:1 mapcount:0 mapping:ffffe01c4001f600 index:0x0
[ 710.099914] flags: 0xfffff8000000100(slab)
[ 710.149059] raw: 0fffff8000000100 dead000000000100 dead000000000200 ffffe01c4001f600
[ 710.242011] raw: 0000000000000000 0000000000380038 00000001ffffffff 0000000000000000
[ 710.334966] page dumped because: kasan: bad access detected
Fix it resetting iph pointer after iptunnel_pull_header
Fixes: a09a4c8dd1ec ("tunnels: Remove encapsulation offloads on decap")
Tested-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In commit 0ae955e2656d ("tipc: improve TIPC throughput by Gap ACK
blocks"), we enhance the link transmq by releasing as many packets as
possible with the multi-ACKs from peer node. This also means the queue
is now non-linear and the peer link deferdq becomes vital.
Whereas, in the case of link failover, all messages in the link transmq
need to be transmitted as tunnel messages in such a way that message
sequentiality and cardinality per sender is preserved. This requires us
to maintain the link deferdq somehow, so that when the tunnel messages
arrive, the inner user messages along with the ones in the deferdq will
be delivered to upper layer correctly.
The commit accomplishes this by defining a new queue in the TIPC link
structure to hold the old link deferdq when link failover happens and
process it upon receipt of tunnel messages.
Also, in the case of link syncing, the link deferdq will not be purged
to avoid unnecessary retransmissions that in the worst case will fail
because the packets might have been freed on the sending side.
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
For unicast transmission, the current NACK sending althorithm is over-
active that forces the sending side to retransmit a packet that is not
really lost but just arrived at the receiving side with some delay, or
even retransmit same packets that have already been retransmitted
before. As a result, many duplicates are observed also under normal
condition, ie. without packet loss.
One example case is: node1 transmits 1 2 3 4 10 5 6 7 8 9, when node2
receives packet #10, it puts into the deferdq. When the packet #5 comes
it sends NACK with gap [6 - 9]. However, shortly after that, when
packet #6 arrives, it pulls out packet #10 from the deferfq, but it is
still out of order, so it makes another NACK with gap [7 - 9] and so on
... Finally, node1 has to retransmit the packets 5 6 7 8 9 a number of
times, but in fact all the packets are not lost at all, so duplicates!
This commit reduces duplicates by changing the condition to send NACK,
also restricting the retransmissions on individual packets via a timer
of about 1ms. However, it also needs to say that too tricky condition
for NACKs or too long timeout value for retransmissions will result in
performance reducing! The criterias in this commit are found to be
effective for both the requirements to reduce duplicates but not affect
performance.
The tipc_link_rcv() is also improved to only dequeue skb from the link
deferdq if it is expected (ie. its seqno <= rcv_nxt).
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
During unicast link transmission, it's observed very often that because
of one or a few lost/dis-ordered packets, the sending side will fastly
reach the send window limit and must wait for the packets to be arrived
at the receiving side or in the worst case, a retransmission must be
done first. The sending side cannot release a lot of subsequent packets
in its transmq even though all of them might have already been received
by the receiving side.
That is, one or two packets dis-ordered/lost and dozens of packets have
to wait, this obviously reduces the overall throughput!
This commit introduces an algorithm to overcome this by using "Gap ACK
blocks". Basically, a Gap ACK block will consist of <ack, gap> numbers
that describes the link deferdq where packets have been got by the
receiving side but with gaps, for example:
link deferdq: [1 2 3 4 10 11 13 14 15 20]
--> Gap ACK blocks: <4, 5>, <11, 1>, <15, 4>, <20, 0>
The Gap ACK blocks will be sent to the sending side along with the
traditional ACK or NACK message. Immediately when receiving the message
the sending side will now not only release from its transmq the packets
ack-ed by the ACK but also by the Gap ACK blocks! So, more packets can
be enqueued and transmitted.
In addition, the sending side can now do "multi-retransmissions"
according to the Gaps reported in the Gap ACK blocks.
The new algorithm as verified helps greatly improve the TIPC throughput
especially under packet loss condition.
So far, a maximum of 32 blocks is quite enough without any "Too few Gap
ACK blocks" reports with a 5.0% packet loss rate, however this number
can be increased in the furture if needed.
Also, the patch is backward compatible.
Acked-by: Ying Xue <ying.xue@windriver.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Now that phylib uses genphy_read_abilities() as fallback, we don't have
to set callback get_features any longer.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Meanwhile we have generic functions for reading the abilities of
Clause 22 / 45 PHY's. This allows to use them as fallback in case
callback get_features isn't set. Benefit is the reduction of
boilerplate code in PHY drivers.
v2:
- adjust the comment in phy_driver_register to match the code
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Since the mcast conversion to rhashtable this function has been unused, so
remove it.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We need to be careful and always zero the whole br_ip struct when it is
used for matching since the rhashtable change. This patch fixes all the
places which didn't properly clear it which in turn might've caused
mismatches.
Thanks for the great bug report with reproducing steps and bisection.
Steps to reproduce (from the bug report):
ip link add br0 type bridge mcast_querier 1
ip link set br0 up
ip link add v2 type veth peer name v3
ip link set v2 master br0
ip link set v2 up
ip link set v3 up
ip addr add 3.0.0.2/24 dev v3
ip netns add test
ip link add v1 type veth peer name v1 netns test
ip link set v1 master br0
ip link set v1 up
ip -n test link set v1 up
ip -n test addr add 3.0.0.1/24 dev v1
# Multicast receiver
ip netns exec test socat
UDP4-RECVFROM:5588,ip-add-membership=224.224.224.224:3.0.0.1,fork -
# Multicast sender
echo hello | nc -u -s 3.0.0.2 224.224.224.224 5588
Reported-by: liam.mcbirnie@boeing.com
Fixes: 19e3a9c90c53 ("net: bridge: convert multicast to generic rhashtable")
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit 6578229d4efb7ea6287861bfc2bd306140458e07.
netif_receive_skb_list() doesn't support GRO, therefore we may have
scenarios with decreased performance. See discussion here [0].
[0] https://marc.info/?t=155403847400001&r=1&w=2
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Linux currently disable ECN for incoming connections when the SYN
requests ECN and the IP header has ECT(0)/ECT(1) set, as some
networks were reportedly mangling the ToS byte, hence could later
trigger false congestion notifications.
RFC8311 §4.3 relaxes RFC3168's requirements such that ECT can be set
one TCP control packets (including SYNs). The main benefit of this
is the decreased probability of losing a SYN in a congested
ECN-capable network (i.e., it avoids the initial 1s timeout).
Additionally, this allows the development of newer TCP extensions,
such as AccECN.
This patch relaxes the previous check, by enabling ECN on incoming
connections using SYN+ECT if at least one bit of the reserved flags
of the TCP header is set. Such bit would indicate that the sender of
the SYN is using a newer TCP feature than what the host implements,
such as AccECN, and is thus implementing RFC8311. This enables
end-hosts not supporting such extensions to still negociate ECN, and
to have some of the benefits of using ECN on control packets.
Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
Suggested-by: Bob Briscoe <research@bobbriscoe.net>
Cc: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently if the driver registers devlink port instance, he should set
the devlink port attributes as well. Then the devlink core is able to
obtain switch id itself, no need for driver to implement the ndo.
Once all drivers will implement devlink port registration, this ndo
should be removed. This warning guides new drivers to do things as
they should be done.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pass the switch ID down the to devlink through devlink_port_attrs_set()
so it can be used by devlink_compat_switch_id_get(). Leave
ndo_get_port_parent_id implementation only for legacy.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Obtain HW id and pass it down to mlxsw_core_port_init() as it would be
used as switch_id in devlink and exposed to user.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Remove implementation of get_port_parent_id ndo and rely on core calling
into devlink for the information directly.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pass the switch ID down the to devlink through devlink_port_attrs_set()
so it can be used by devlink_compat_switch_id_get().
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Remove implementation of get_port_parent_id ndo and rely on core calling
into devlink for the information directly.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pass the switch ID down the to devlink through devlink_port_attrs_set()
so it can be used by devlink_compat_switch_id_get().
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Currently the switch_id is being only initialized when switching eswitch
mode from "legacy" to "switchdev". However, nothing prevents the id to
be initialized from the very beginning. Physical ports can show it even
in "legacy" mode.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Remove implementation of get_port_parent_id ndo and rely on core calling
into devlink for the information directly.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pass the switch ID down the to devlink through devlink_port_attrs_set()
so it can be used by devlink_compat_switch_id_get().
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Introduce devlink_compat_switch_id_get() helper which fills up switch_id
according to passed netdev pointer. Call it directly from
dev_get_port_parent_id() as a fallback when ndo_get_port_parent_id
is not defined for given netdev.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Extend devlink_port_attrs_set() to pass switch ID for ports which are
part of switch and store it in port attrs. For other ports, this is
NULL.
Note that this allows the driver to group devlink ports into one or more
switches according to the actual topology.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In order to save space in the struct, convert bools to bits.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
BITS_TO_LONGS() uses DIV_ROUND_UP() because of
this ppmax value can be greater than available
per cpu page pods.
This patch removes BITS_TO_LONGS() to fix this
issue.
Signed-off-by: Varun Prakash <varun@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We can optimize the fdb convergence when a backup_port is present by not
immediately flushing the entries of the stopped port since traffic for
those entries will flow towards the backup_port.
There are 2 cases specifically that benefit most:
- when the stopped port comes up before the entries expire by themselves
- when there's an external entry refresh and they're kept while the
backup_port is operating (e.g. mlag)
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This header is not in use - remove it.
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/ibm/ibmvnic.c: In function '__ibmvnic_reset':
drivers/net/ethernet/ibm/ibmvnic.c:1971:21: warning: variable 'netdev' set but not used [-Wunused-but-set-variable]
It's never used since introduction in
commit ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/ibm/ehea/ehea_qmr.c: In function 'ehea_create_cq':
drivers/net/ethernet/ibm/ehea/ehea_qmr.c:127:7: warning: variable 'cq_handle_ref' set but not used [-Wunused-but-set-variable]
drivers/net/ethernet/ibm/ehea/ehea_qmr.c:126:15: warning: variable 'epa' set but not used [-Wunused-but-set-variable]
They are never used since commit
7a291083225a ("[PATCH] ehea: IBM eHEA Ethernet Device Driver")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/pasemi/pasemi_mac.c: In function 'pasemi_mac_queue_csdesc':
drivers/net/ethernet/pasemi/pasemi_mac.c:1358:29: warning: variable 'cpyhdr' set but not used [-Wunused-but-set-variable]
It's never used since commit 8d636d8bc5ff ("pasemi_mac: jumbo
frame support") and can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
pr->tx_bytes should be assigned to tx_bytes other than
rx_bytes.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: ce45b873028f ("ehea: Fixing statistics")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
syzbot reports:
BUG: using __this_cpu_read() in preemptible code:
caller is dev_recursion_level include/linux/netdevice.h:3052 [inline]
__this_cpu_preempt_check+0x246/0x270 lib/smp_processor_id.c:47
dev_recursion_level include/linux/netdevice.h:3052 [inline]
ip6_skb_dst_mtu include/net/ip6_route.h:245 [inline]
I erronously downgraded a this_cpu_read to __this_cpu_read when
moving dev_recursion_level() around.
Reported-by: syzbot+51471b4aae195285a4a3@syzkaller.appspotmail.com
Fixes: 97cdcf37b57e ("net: place xmit recursion in softnet data")
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
skb somehow dequeued out of inputq before processing, it causes to
NULL pointer and kernel crashed.
Add checking skb valid before using.
Fixes: c55c8edafa9 ("tipc: smooth change between replicast and broadcast")
Reported-by: Tuong Lien Tong <tuong.t.lien@dektech.com.au>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Recent changes to TC flower remove the requirement for rtnl lock when
accessing and modifying filters. Refcounts now ensure access and deletion
do not happen concurrently. However, the reoffload function which cycles
through all filters and replays them to registered hw drivers is not
protected.
Use the fl_get_next_filter() function to cycle the filters for reoffload
and ensure the ref taken by this function is put when done with each
filter.
Signed-off-by: John Hurley <john.hurley@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Vlad Buslov <vladbu@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Way back in 3c9c36bcedd426f2be2826da43e5163de61735f7 the
ndo_fcoe_get_wwn pointer was switched from depending on CONFIG_FCOE to
CONFIG_LIBFCOE in order to allow building FCoE support into the bnx2x
driver and used by bnx2fc without including the generic software fcoe
module.
But, FCoE is generally used over an 802.1q VLAN, and the implementation
of ndo_fcoe_get_wwn in the 8021q module was not similarly changed. The
result is that if CONFIG_FCOE is disabled, then bnz2fc cannot make a
call to ndo_fcoe_get_wwn through the 8021q interface to the underlying
bnx2x interface. The bnx2fc driver then falls back to a potentially
different mapping of Ethernet MAC to Fibre Channel WWN, creating an
incompatibility with the fabric and target configurations when compared
to the WWNs used by pre-boot firmware and differently-configured
kernels.
So make the conditional inclusion of FCoE code in 8021q match the
conditional inclusion in netdevice.h
Signed-off-by: Chris Leech <cleech@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There is not actually any guarantee that the IP headers are valid before we
access the DSCP bits of the packets. Fix this using the same approach taken
in sch_dsmark.
Reported-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We shouldn't be using skb->protocol directly as that will miss cases with
hardware-accelerated VLAN tags. Use the helper instead to get the right
protocol number.
Reported-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
RFC8257 §3.5 explicitly states that "A DCTCP sender MUST react to
loss episodes in the same way as conventional TCP".
Currently, Linux DCTCP performs no cwnd reduction when losses
are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets
alpha to its maximal value if a RTO happens. This behavior
is sub-optimal for at least two reasons: i) it ignores losses
triggering fast retransmissions; and ii) it causes unnecessary large
cwnd reduction in the future if the loss was isolated as it resets
the historical term of DCTCP's alpha EWMA to its maximal value (i.e.,
denoting a total congestion). The second reason has an especially
noticeable effect when using DCTCP in high BDP environments, where
alpha normally stays at low values.
This patch replace the clamping of alpha by setting ssthresh to
half of cwnd for both fast retransmissions and RTOs, at most once
per RTT. Consequently, the dctcp_clamp_alpha_on_loss module parameter
has been removed.
The table below shows experimental results where we measured the
drop probability of a PIE AQM (not applying ECN marks) at a
bottleneck in the presence of a single TCP flow with either the
alpha-clamping option enabled or the cwnd halving proposed by this
patch. Results using reno or cubic are given for comparison.
| Link | RTT | Drop
TCP CC | speed | base+AQM | probability
==================|=========|==========|============
CUBIC | 40Mbps | 7+20ms | 0.21%
RENO | | | 0.19%
DCTCP-CLAMP-ALPHA | | | 25.80%
DCTCP-HALVE-CWND | | | 0.22%
------------------|---------|----------|------------
CUBIC | 100Mbps | 7+20ms | 0.03%
RENO | | | 0.02%
DCTCP-CLAMP-ALPHA | | | 23.30%
DCTCP-HALVE-CWND | | | 0.04%
------------------|---------|----------|------------
CUBIC | 800Mbps | 1+1ms | 0.04%
RENO | | | 0.05%
DCTCP-CLAMP-ALPHA | | | 18.70%
DCTCP-HALVE-CWND | | | 0.06%
We see that, without halving its cwnd for all source of losses,
DCTCP drives the AQM to large drop probabilities in order to keep
the queue length under control (i.e., it repeatedly faces RTOs).
Instead, if DCTCP reacts to all source of losses, it can then be
controlled by the AQM using similar drop levels than cubic or reno.
Signed-off-by: Koen De Schepper <koen.de_schepper@nokia-bell-labs.com>
Signed-off-by: Olivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
Cc: Bob Briscoe <research@bobbriscoe.net>
Cc: Lawrence Brakmo <brakmo@fb.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: Daniel Borkmann <borkmann@iogearbox.net>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Glenn Judd <glenn.judd@morganstanley.com>
Acked-by: Florian Westphal <fw@strlen.de>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Simplify this code by updating bridge multicast stats from
maybe_deliver().
Note that commit 6db6f0eae605 ("bridge: multicast to unicast"), in case
the port flag BR_MULTICAST_TO_UNICAST is set, never updates the previous
port pointer, therefore it is always going to be different from the
existing port in this deduplicated list iteration.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Just like 46cfd725c377 ("net: use kfree_skb_list() helper in more places").
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
the control path of 'sample' action does not validate the value of 'rate'
provided by the user, but then it uses it as divisor in the traffic path.
Validate it in tcf_sample_init(), and return -EINVAL with a proper extack
message in case that value is zero, to fix a splat with the script below:
# tc f a dev test0 egress matchall action sample rate 0 group 1 index 2
# tc -s a s action sample
total acts 1
action order 0: sample rate 1/0 group 1 pipe
index 2 ref 1 bind 1 installed 19 sec used 19 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
# ping 192.0.2.1 -I test0 -c1 -q
divide error: 0000 [#1] SMP PTI
CPU: 1 PID: 6192 Comm: ping Not tainted 5.1.0-rc2.diag2+ #591
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:tcf_sample_act+0x9e/0x1e0 [act_sample]
Code: 6a f1 85 c0 74 0d 80 3d 83 1a 00 00 00 0f 84 9c 00 00 00 4d 85 e4 0f 84 85 00 00 00 e8 9b d7 9c f1 44 8b 8b e0 00 00 00 31 d2 <41> f7 f1 85 d2 75 70 f6 85 83 00 00 00 10 48 8b 45 10 8b 88 08 01
RSP: 0018:ffffae320190ba30 EFLAGS: 00010246
RAX: 00000000b0677d21 RBX: ffff8af1ed9ec000 RCX: 0000000059a9fe49
RDX: 0000000000000000 RSI: 000000000c7e33b7 RDI: ffff8af23daa0af0
RBP: ffff8af1ee11b200 R08: 0000000074fcaf7e R09: 0000000000000000
R10: 0000000000000050 R11: ffffffffb3088680 R12: ffff8af232307f80
R13: 0000000000000003 R14: ffff8af1ed9ec000 R15: 0000000000000000
FS: 00007fe9c6d2f740(0000) GS:ffff8af23da80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff6772f000 CR3: 00000000746a2004 CR4: 00000000001606e0
Call Trace:
tcf_action_exec+0x7c/0x1c0
tcf_classify+0x57/0x160
__dev_queue_xmit+0x3dc/0xd10
ip_finish_output2+0x257/0x6d0
ip_output+0x75/0x280
ip_send_skb+0x15/0x40
raw_sendmsg+0xae3/0x1410
sock_sendmsg+0x36/0x40
__sys_sendto+0x10e/0x140
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x60/0x210
entry_SYSCALL_64_after_hwframe+0x49/0xbe
[...]
Kernel panic - not syncing: Fatal exception in interrupt
Add a TDC selftest to document that 'rate' is now being validated.
Reported-by: Matteo Croce <mcroce@redhat.com>
Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action")
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Acked-by: Yotam Gigi <yotam.gi@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When a bpf program is uploaded, the driver computes the number of
xdp tx queues resulting in the allocation of additional qsets.
Starting from commit '2ecbe4f4a027 ("net: thunderx: replace global
nicvf_rx_mode_wq work queue for all VFs to private for each of them")'
the driver runs link state polling for each VF resulting in the
following NULL pointer dereference:
[ 56.169256] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
[ 56.178032] Mem abort info:
[ 56.180834] ESR = 0x96000005
[ 56.183877] Exception class = DABT (current EL), IL = 32 bits
[ 56.189792] SET = 0, FnV = 0
[ 56.192834] EA = 0, S1PTW = 0
[ 56.195963] Data abort info:
[ 56.198831] ISV = 0, ISS = 0x00000005
[ 56.202662] CM = 0, WnR = 0
[ 56.205619] user pgtable: 64k pages, 48-bit VAs, pgdp = 0000000021f0c7a0
[ 56.212315] [0000000000000020] pgd=0000000000000000, pud=0000000000000000
[ 56.219094] Internal error: Oops: 96000005 [#1] SMP
[ 56.260459] CPU: 39 PID: 2034 Comm: ip Not tainted 5.1.0-rc3+ #3
[ 56.266452] Hardware name: GIGABYTE R120-T33/MT30-GS1, BIOS T49 02/02/2018
[ 56.273315] pstate: 80000005 (Nzcv daif -PAN -UAO)
[ 56.278098] pc : __ll_sc___cmpxchg_case_acq_64+0x4/0x20
[ 56.283312] lr : mutex_lock+0x2c/0x50
[ 56.286962] sp : ffff0000219af1b0
[ 56.290264] x29: ffff0000219af1b0 x28: ffff800f64de49a0
[ 56.295565] x27: 0000000000000000 x26: 0000000000000015
[ 56.300865] x25: 0000000000000000 x24: 0000000000000000
[ 56.306165] x23: 0000000000000000 x22: ffff000011117000
[ 56.311465] x21: ffff800f64dfc080 x20: 0000000000000020
[ 56.316766] x19: 0000000000000020 x18: 0000000000000001
[ 56.322066] x17: 0000000000000000 x16: ffff800f2e077080
[ 56.327367] x15: 0000000000000004 x14: 0000000000000000
[ 56.332667] x13: ffff000010964438 x12: 0000000000000002
[ 56.337967] x11: 0000000000000000 x10: 0000000000000c70
[ 56.343268] x9 : ffff0000219af120 x8 : ffff800f2e077d50
[ 56.348568] x7 : 0000000000000027 x6 : 000000062a9d6a84
[ 56.353869] x5 : 0000000000000000 x4 : ffff800f2e077480
[ 56.359169] x3 : 0000000000000008 x2 : ffff800f2e077080
[ 56.364469] x1 : 0000000000000000 x0 : 0000000000000020
[ 56.369770] Process ip (pid: 2034, stack limit = 0x00000000c862da3a)
[ 56.376110] Call trace:
[ 56.378546] __ll_sc___cmpxchg_case_acq_64+0x4/0x20
[ 56.383414] drain_workqueue+0x34/0x198
[ 56.387247] nicvf_open+0x48/0x9e8 [nicvf]
[ 56.391334] nicvf_open+0x898/0x9e8 [nicvf]
[ 56.395507] nicvf_xdp+0x1bc/0x238 [nicvf]
[ 56.399595] dev_xdp_install+0x68/0x90
[ 56.403333] dev_change_xdp_fd+0xc8/0x240
[ 56.407333] do_setlink+0x8e0/0xbe8
[ 56.410810] __rtnl_newlink+0x5b8/0x6d8
[ 56.414634] rtnl_newlink+0x54/0x80
[ 56.418112] rtnetlink_rcv_msg+0x22c/0x2f8
[ 56.422199] netlink_rcv_skb+0x60/0x120
[ 56.426023] rtnetlink_rcv+0x28/0x38
[ 56.429587] netlink_unicast+0x1c8/0x258
[ 56.433498] netlink_sendmsg+0x1b4/0x350
[ 56.437410] sock_sendmsg+0x4c/0x68
[ 56.440887] ___sys_sendmsg+0x240/0x280
[ 56.444711] __sys_sendmsg+0x68/0xb0
[ 56.448275] __arm64_sys_sendmsg+0x2c/0x38
[ 56.452361] el0_svc_handler+0x9c/0x128
[ 56.456186] el0_svc+0x8/0xc
[ 56.459056] Code: 35ffff91 2a1003e0 d65f03c0 f9800011 (c85ffc10)
[ 56.465166] ---[ end trace 4a57fdc27b0a572c ]---
[ 56.469772] Kernel panic - not syncing: Fatal exception
Fix it by checking nicvf_rx_mode_wq pointer in nicvf_open and nicvf_stop
Fixes: 2ecbe4f4a027 ("net: thunderx: replace global nicvf_rx_mode_wq work queue for all VFs to private for each of them")
Fixes: 2c632ad8bc74 ("net: thunderx: move link state polling function to VF")
Reported-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Tested-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There are some sparse warnings in the HNS drivers:
warning: incorrect type in assignment (different address spaces)
expected void [noderef] <asn:2> *io_base
got void *vaddr
warning: cast removes address space '<asn:2>' of expression
[...]
Add __iomem and change all the u8 __iomem to void __iomem to
fix these kind of warnings.
warning: incorrect type in argument 1 (different address spaces)
expected void [noderef] <asn:2> *base
got unsigned char [usertype] *base_addr
warning: cast to restricted __le16
warning: incorrect type in assignment (different base types)
expected unsigned int [usertype] tbl_tcam_data_high
got restricted __le32 [usertype]
warning: cast to restricted __le32
[...]
These variables used u32/u16 as their type, and finally as a
parameter of writel(), writel() will do the cpu_to_le32 coversion
so remove the little endian covert code to fix these kind of warnings.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When enable SMMU, remove HNS driver will cause a WARNING:
[ 141.924177] WARNING: CPU: 36 PID: 2708 at drivers/iommu/dma-iommu.c:443 __iommu_dma_unmap+0xc0/0xc8
[ 141.954673] Modules linked in: hns_enet_drv(-)
[ 141.963615] CPU: 36 PID: 2708 Comm: rmmod Tainted: G W 5.0.0-rc1-28723-gb729c57de95c-dirty #32
[ 141.983593] Hardware name: Huawei D05/D05, BIOS Hisilicon D05 UEFI Nemo 1.8 RC0 08/31/2017
[ 142.000244] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 142.009886] pc : __iommu_dma_unmap+0xc0/0xc8
[ 142.018476] lr : __iommu_dma_unmap+0xc0/0xc8
[ 142.027066] sp : ffff000013533b90
[ 142.033728] x29: ffff000013533b90 x28: ffff8013e6983600
[ 142.044420] x27: 0000000000000000 x26: 0000000000000000
[ 142.055113] x25: 0000000056000000 x24: 0000000000000015
[ 142.065806] x23: 0000000000000028 x22: ffff8013e66eee68
[ 142.076499] x21: ffff8013db919800 x20: 0000ffffefbff000
[ 142.087192] x19: 0000000000001000 x18: 0000000000000007
[ 142.097885] x17: 000000000000000e x16: 0000000000000001
[ 142.108578] x15: 0000000000000019 x14: 363139343a70616d
[ 142.119270] x13: 6e75656761705f67 x12: 0000000000000000
[ 142.129963] x11: 00000000ffffffff x10: 0000000000000006
[ 142.140656] x9 : 1346c1aa88093500 x8 : ffff0000114de4e0
[ 142.151349] x7 : 6662666578303d72 x6 : ffff0000105ffec8
[ 142.162042] x5 : 0000000000000000 x4 : 0000000000000000
[ 142.172734] x3 : 00000000ffffffff x2 : ffff0000114de500
[ 142.183427] x1 : 0000000000000000 x0 : 0000000000000035
[ 142.194120] Call trace:
[ 142.199030] __iommu_dma_unmap+0xc0/0xc8
[ 142.206920] iommu_dma_unmap_page+0x20/0x28
[ 142.215335] __iommu_unmap_page+0x40/0x60
[ 142.223399] hnae_unmap_buffer+0x110/0x134
[ 142.231639] hnae_free_desc+0x6c/0x10c
[ 142.239177] hnae_fini_ring+0x14/0x34
[ 142.246540] hnae_fini_queue+0x2c/0x40
[ 142.254080] hnae_put_handle+0x38/0xcc
[ 142.261619] hns_nic_dev_remove+0x54/0xfc [hns_enet_drv]
[ 142.272312] platform_drv_remove+0x24/0x64
[ 142.280552] device_release_driver_internal+0x17c/0x20c
[ 142.291070] driver_detach+0x4c/0x90
[ 142.298259] bus_remove_driver+0x5c/0xd8
[ 142.306148] driver_unregister+0x2c/0x54
[ 142.314037] platform_driver_unregister+0x10/0x18
[ 142.323505] hns_nic_dev_driver_exit+0x14/0xf0c [hns_enet_drv]
[ 142.335248] __arm64_sys_delete_module+0x214/0x25c
[ 142.344891] el0_svc_common+0xb0/0x10c
[ 142.352430] el0_svc_handler+0x24/0x80
[ 142.359968] el0_svc+0x8/0x7c0
[ 142.366104] ---[ end trace 60ad1cd58e63c407 ]---
The tx ring buffer map when xmit and unmap when xmit done. So in
hnae_init_ring() did not map tx ring buffer, but in hnae_fini_ring()
have a unmap operation for tx ring buffer, which is already unmapped
when xmit done, than cause this WARNING.
The hnae_alloc_buffers() is called in hnae_init_ring(),
so the hnae_free_buffers() should be in hnae_fini_ring(), not in
hnae_free_desc().
In hnae_fini_ring(), adds a check is_rx_ring() as in hnae_init_ring().
When the ring buffer is tx ring, adds a piece of code to ensure that
the tx ring is unmap.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
ICMP6 neighbor solicitation messages will be discard by the Hip06
chips, because of not setting forwarding pool. Enable promisc mode
has the same problem.
This patch fix the wrong forwarding table configs for the multicast
vague matching when enable promisc mode, and add forwarding pool
for the forwarding table.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When reboot the system again and again, may cause a memory
overwrite.
[ 15.638922] systemd[1]: Reached target Swap.
[ 15.667561] tun: Universal TUN/TAP device driver, 1.6
[ 15.676756] Bridge firewalling registered
[ 17.344135] Unable to handle kernel paging request at virtual address 0000000200000040
[ 17.352179] Mem abort info:
[ 17.355007] ESR = 0x96000004
[ 17.358105] Exception class = DABT (current EL), IL = 32 bits
[ 17.364112] SET = 0, FnV = 0
[ 17.367209] EA = 0, S1PTW = 0
[ 17.370393] Data abort info:
[ 17.373315] ISV = 0, ISS = 0x00000004
[ 17.377206] CM = 0, WnR = 0
[ 17.380214] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
[ 17.386926] [0000000200000040] pgd=0000000000000000
[ 17.391878] Internal error: Oops: 96000004 [#1] SMP
[ 17.396824] CPU: 23 PID: 95 Comm: kworker/u130:0 Tainted: G E 4.19.25-1.2.78.aarch64 #1
[ 17.414175] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.54 08/16/2018
[ 17.425615] Workqueue: events_unbound async_run_entry_fn
[ 17.435151] pstate: 00000005 (nzcv daif -PAN -UAO)
[ 17.444139] pc : __mutex_lock.isra.1+0x74/0x540
[ 17.453002] lr : __mutex_lock.isra.1+0x3c/0x540
[ 17.461701] sp : ffff000100d9bb60
[ 17.469146] x29: ffff000100d9bb60 x28: 0000000000000000
[ 17.478547] x27: 0000000000000000 x26: ffff802fb8945000
[ 17.488063] x25: 0000000000000000 x24: ffff802fa32081a8
[ 17.497381] x23: 0000000000000002 x22: ffff801fa2b15220
[ 17.506701] x21: ffff000009809000 x20: ffff802fa23a0888
[ 17.515980] x19: ffff801fa2b15220 x18: 0000000000000000
[ 17.525272] x17: 0000000200000000 x16: 0000000200000000
[ 17.534511] x15: 0000000000000000 x14: 0000000000000000
[ 17.543652] x13: ffff000008d95db8 x12: 000000000000000d
[ 17.552780] x11: ffff000008d95d90 x10: 0000000000000b00
[ 17.561819] x9 : ffff000100d9bb90 x8 : ffff802fb89d6560
[ 17.570829] x7 : 0000000000000004 x6 : 00000004a1801d05
[ 17.579839] x5 : 0000000000000000 x4 : 0000000000000000
[ 17.588852] x3 : ffff802fb89d5a00 x2 : 0000000000000000
[ 17.597734] x1 : 0000000200000000 x0 : 0000000200000000
[ 17.606631] Process kworker/u130:0 (pid: 95, stack limit = 0x(____ptrval____))
[ 17.617438] Call trace:
[ 17.623349] __mutex_lock.isra.1+0x74/0x540
[ 17.630927] __mutex_lock_slowpath+0x24/0x30
[ 17.638602] mutex_lock+0x50/0x60
[ 17.645295] drain_workqueue+0x34/0x198
[ 17.652623] __sas_drain_work+0x7c/0x168
[ 17.659903] sas_drain_work+0x60/0x68
[ 17.666947] hisi_sas_scan_finished+0x30/0x40 [hisi_sas_main]
[ 17.676129] do_scsi_scan_host+0x70/0xb0
[ 17.683534] do_scan_async+0x20/0x228
[ 17.690586] async_run_entry_fn+0x4c/0x1d0
[ 17.697997] process_one_work+0x1b4/0x3f8
[ 17.705296] worker_thread+0x54/0x470
Every time the call trace is not the same, but the overwrite address
is always the same:
Unable to handle kernel paging request at virtual address 0000000200000040
The root cause is, when write the reg XGMAC_MAC_TX_LF_RF_CONTROL_REG,
didn't use the io_base offset.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When the HNS driver loaded, always have an error print:
"netif_napi_add() called with weight 256"
This is because the kernel checks the NAPI polling weights
requested by drivers and it prints an error message if a driver
requests a weight bigger than 64.
So use NAPI_POLL_WEIGHT to fix it.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch is trying to fix the issue due to:
[27237.844750] BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x708/0xa18[hns_enet_drv]
After hnae_queue_xmit() in hns_nic_net_xmit_hw(), can be
interrupted by interruptions, and than call hns_nic_tx_poll_one()
to handle the new packets, and free the skb. So, when turn back to
hns_nic_net_xmit_hw(), calling skb->len will cause use-after-free.
This patch update tx ring statistics in hns_nic_tx_poll_one() to
fix the bug.
Signed-off-by: Liubin Shu <shuliubin@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The function hnae3_match_n_instantiate() was called both by
initializing or uninitializing client. For uninitializing, the
return value was never used.
To make it more clear, this patch splits it to two functions,
hnae3_init_client_instance() and hnae3_uninit_client_instance().
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In the hns3_reset_notify_uninit_enet() HNS3_NIC_STATE_INITED flag
should be checked and cleared firstly.
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
Thomas Falcon
Lorenzo Bianconi
Tuong Lien
Heiner Kallweit
Nikolay Aleksandrov
Tilmans, Olivier (Nokia - BE/Antwerp)
Jiri Pirko
Varun Prakash
Yuval Shaia
YueHaibing
Florian Westphal
Hoang Le
John Hurley
Chris Leech
Toke Høiland-Jørgensen
Koen De Schepper
Pablo Neira Ayuso
Davide Caratti
Yonglong Liu
Liubin Shu
Jian Shen
Huazhong Tan