[Bug 271366] Invoking IPv6 network device address event may sleep with the following non-sleepable locks held

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271366

Mina Galić  changed:

   What|Removed |Added

 CC||free...@igalic.co

--- Comment #1 from Mina Galić  ---
seen before, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269821 but i
foolishly closed it, because i didn't realise it could be spurious

-- 
You are receiving this mail because:
You are the assignee for the bug.


LoR tcphash -> in6_ifaddr_lock

2023-05-12 Thread Bjoern A. Zeeb

where does this one come from these days?

lock order reversal:
 1st 0xfe0002305a10 tcphash (tcphash, sleep mutex) @ 
/usr/src/sys/netinet/tcp_usrreq.c:1477
 2nd 0x81a5b9d0 in6_ifaddr_lock (in6_ifaddr_lock, rm) @ 
/usr/src/sys/netinet6/in6_src.c:305
lock order tcphash -> in6_ifaddr_lock attempted at:
#0 0x80bc92c3 at witness_checkorder+0xbb3
#1 0x80b503df at _rm_rlock_debug+0x12f
#2 0x80d84c2f at in6_selectsrc+0x44f
#3 0x80d84790 at in6_selectsrc_socket+0x40
#4 0x80d826f7 at in6_pcbconnect+0x247
#5 0x80d66813 at tcp6_connect+0xa3
#6 0x80d641f4 at tcp6_usr_connect+0x304
#7 0x80c057ff at soconnectat+0xaf
#8 0x80c0c8f1 at kern_connectat+0xe1
#9 0x80c0c7e5 at sys_connect+0x75
#10 0x81051760 at amd64_syscall+0x140
#11 0x81023e1b at fast_syscall_common+0xf8


--
Bjoern A. Zeeb r15:7



[Bug 254596] if_bridge wants LRO turned off, if_vlan insists it remain on

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254596

paul vixie  changed:

   What|Removed |Added

 Attachment #242067|0   |1
is obsolete||

--- Comment #8 from paul vixie  ---
Created attachment 242133
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=242133&action=edit
second patch, same content, but in "git format-patch" format

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


[Bug 254596] if_bridge wants LRO turned off, if_vlan insists it remain on

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254596

--- Comment #9 from paul vixie  ---
(In reply to Naman Sood from comment #7)
i've now tested this patch and it does what i need. the LRO option remains on
for the physical interface and for the vlan subinterfaces which are not added
to a bridge. i did not performance-test the physical interface or other
subinterfaces to see what impact LRO was having, but input coalescence is a
theoretical boon and i'm glad to not have to turn off LRO on the physical
interface in order to protect the bridge members from having LRO turned on
inappropriately.

the main motivation is to avoid input coalescence on the bridge member, since
the other bridge members are tap(4) interfaces each belonging to a bhyve guest
(where the interface shows up as a vtnet(4) interface.) input coalescence in
this case is not just a performance problem it damages the input flow and makes
the bhyve guest unusable. i was working around this by turning off LRO on the
physical interface but this is a price too high: bhyve guests whose bridge is
connected not by a physical interface but by a vlan subinterface must "just
work".

i am attaching a second patch, this time in "git format-patch" format, since
this was requested. it looks the same to me. can this patch be reviewed for
inclusion in 13.3 and also pulled into the 13.2 release in the next maintenance
patch?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


[Bug 254596] if_bridge wants LRO turned off, if_vlan insists it remain on

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254596

--- Comment #10 from Ed Maste  ---
> can this patch be reviewed for inclusion in 13.3 and also pulled into the 13.2
> release in the next maintenance patch?

In order to make it into a 13.2 errata update the first two steps will be
committing to main and MFCing to stable/13. I'll handle that (likely after a
couple of weeks).

In order to help facilitate an errata update, would you be able to provide
content for the errata notice? See
https://www.freebsd.org/security/errata-template.txt, and in particular
sections I through IV.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.


[Bug 254596] if_bridge wants LRO turned off, if_vlan insists it remain on

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254596

--- Comment #11 from paul vixie  ---
Created attachment 242136
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=242136&action=edit
partial FreeBSD-EN-ERRATA_TEMPLATE as requested

as requested

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


[Bug 254596] if_bridge wants LRO turned off, if_vlan insists it remain on

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254596

--- Comment #12 from paul vixie  ---
(In reply to Ed Maste from comment #10)
done, see ticket attachments.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


[Bug 252015] Enabling LRO on network interfaces by default considered harmful

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252015

paul vixie  changed:

   What|Removed |Added

 CC||p...@redbarn.org

--- Comment #2 from paul vixie  ---
agreed that LRO should never be on by default. furthermore it should never be
propagated from a trunk interface into vlan subinterfaces. see also #254596.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 271371] e1000 driver falsely reports that it supports LRO

2023-05-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271371

Mark Linimon  changed:

   What|Removed |Added

   Keywords||IntelNetworking
   Assignee|b...@freebsd.org|n...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.