src/sys, branch stable/10

if_firewire: fixing panic upon packet reception for VNET build

2021-05-17T10:29:12+00:00

netisr_dispatch_src() needs valid VNET pointer or firewire_input() will panic
when receiving a packet.

Reviewed by:	glebius
MFC after:	2 weeks

(cherry picked from commit d9b61e7153c64b141436b4d9619b166c6d35a0a6)

MFC 4e38478c595a:

2021-04-01T09:34:24+00:00

ipoib: Fix incorrectly computed IPOIB_CM_RX_SG value.

The computed IPOIB_CM_RX_SG is too small. It doesn't account for fallback
to mbuf clusters when jumbo frames are not available and it also doesn't
account for the packet header and trailer mbuf.

This causes a memory overwrite situation when IPOIB_CM is configured.

While at it add a kernel assert to ensure the mapping array is not overwritten.

PR:		254474
Sponsored by:	Mellanox Technologies // NVIDIA Networking

(cherry picked from commit 4e38478c595a9e6225b525890d7ee269a203c200)

MFC 12148d4300db:

2021-03-03T13:33:16+00:00

Fix for locking order reversal in USB audio driver, when using mmap().

Locking the second lock which causes the LOR, can be skipped because
the code updating the shared variables is always executing from the
same USB thread.

lock order reversal:
  1st 0xfffff80005cc3840 pcm7:play:dsp7.p0 (pcm play channel, sleep mutex)
@ usb_transfer.c:2342
  2nd 0xfffff80005cc3860 pcm7:record:dsp7.r0 (pcm record channel, sleep mutex)
@ uaudio.c:2317

lock order pcm record channel -> pcm play channel established at:
witness_checkorder+0x461
__mtx_lock_flags+0x98
dsp_mmap_single+0x151
vm_mmap_cdev+0x65
devfs_mmap_f+0x143
kern_mmap_req+0x594
sys_mmap+0x46
amd64_syscall+0x12e
fast_syscall_common+0xf8

lock order pcm play channel -> pcm record channel attempted at:
witness_checkorder+0xd82
__mtx_lock_flags+0x98
uaudio_chan_play_callback+0xeb
usbd_callback_wrapper+0x7ec
usb_command_wrapper+0x7e
usb_callback_proc+0x8e
usb_process+0xf3
fork_exit+0x80
fork_trampoline+0xe

Found by:	Stefan Ehmann 
Sponsored by:	Mellanox Technologies // NVIDIA Networking

(cherry picked from commit 12148d4300dbbd93260bf2801cdb9eda8b3b05a4)

MFC 9febbc454190:

2021-03-03T09:57:29+00:00

Fix for natd(8) sending wrong sequence number after TCP retransmission,
terminating a TCP connection.

If a TCP packet must be retransmitted and the data length has changed in the
retransmitted packet, due to the internal workings of TCP, typically when ACK
packets are lost, then there is a 30% chance that the logic in GetDeltaSeqOut()
will find the correct length, which is the last length received.

This can be explained as follows:

If a "227 Entering Passive Mode" packet must be retransmittet and the length
changes from 51 to 50 bytes, for example, then we have three cases for the
list scan in GetDeltaSeqOut(), depending on how many prior packets were
received modulus N_LINK_TCP_DATA=3:

  case 1:  index 0:   original packet        51
           index 1:   retransmitted packet   50
           index 2:   not relevant

  case 2:  index 0:   not relevant
           index 1:   original packet        51
           index 2:   retransmitted packet   50

  case 3:  index 0:   retransmitted packet   50
           index 1:   not relevant
           index 2:   original packet        51

This patch simply changes the searching order for TCP packets, always starting
at the last received packet instead of any received packet, in
GetDeltaAckIn() and GetDeltaSeqOut().

Else no functional changes.

Discussed with:	rscheff@
Submitted by:	Andreas Longwitz 
PR:		230755
Sponsored by:	Mellanox Technologies // NVIDIA Networking

(cherry picked from commit 9febbc4541903bb8e6b0f1c84988c98b2f7c96ef)

MFC r362078:

2020-06-19T07:07:10+00:00

Decode the "LACP Fast Timeout" LAGG option flag

r286700 added the "lacp_fast_timeout" option to `ifconfig', but we forgot to
include the new option in the string used to decode the option bits. Add
"LACP_FAST_TIMO" to LAGG_OPT_BITS.

Also, s/LAGG_OPT_LACP_TIMEOUT/LAGG_OPT_LACP_FAST_TIMO/g , to be clearer that
the flag indicates "Fast Timeout" mode.

MFC r362045:

2020-06-18T10:41:51+00:00

Make sure packets generated by raw IP code is let through by mlx5en(4).

Allow the TCP header to reside in the mbuf following the IP header.
Else such packets will get dropped.

Backtrace:
mlx5e_sq_xmit()
mlx5e_xmit()
ether_output_frame()
ether_output()
ip_output_send()
ip_output()
rip_output()
sosend_generic()
sosend()
kern_sendit()
sendit()
sys_sendto()
amd64_syscall()
fast_syscall_common()

Sponsored by:	Mellanox Technologies

MFC r362044:

2020-06-18T10:31:21+00:00

Extend use of unlikely() in the fast path, in mlx5en(4).

Typically the TCP/IP headers fit within the first mbuf and should not
trigger any of the error cases. Use unlikely() for these cases.

No functional change.

Sponsored by:	Mellanox Technologies

MFC r362043:

2020-06-18T10:17:36+00:00

Use const keyword when parsing the TCP/IP header in the fast path in mlx5en(4).

When parsing the TCP/IP header in the fast path, make it clear by using
the const keyword, no fields are to be modified inside the transmitted
packet.

No functional change.

Sponsored by:	Mellanox Technologies

MFC r362056:

2020-06-14T05:33:25+00:00

Add missing range checks when receiving USB ethernet packets.

Found by:	Ilja Van Sprundel, IOActive
Sponsored by:	Mellanox Technologies

MFC r361827:

2020-06-08T09:34:16+00:00

USB HID descriptors may push/pop the current state to allow
description of items residing in a so-called union. FreeBSD currently
only supports 4 such push levels.

If the push level is not restored within the processing of the same
HID item, an invalid memory location may be used for subsequent HID
item processing.

Verify that the push level is always valid when processing HID items.

Reported by:	Andy Nguyen (Google)
Sponsored by:	Mellanox Technologies