[Bug 283426] panic in sbappendaddr_locked() - if_ovpn related?

[email protected]
Newsgroups gmane.os.freebsd.devel.net
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283426

Bjoern A. Zeeb <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|[email protected]        |[email protected]
            Summary|panic in                    |panic in
                   |sbappendaddr_locked()       |sbappendaddr_locked() -
                   |                            |if_ovpn related?
                 CC|                            |[email protected]

--- Comment #12 from Bjoern A. Zeeb <[email protected]> ---
(In reply to Robin Haberkorn from comment #11)

Yes I understand why the question was for the original one;  I just wanted to
understand as the "copy" should have it too then and when manually going up the
stack I couldn't spot where it might be cleared.

I wonder what Dan Epure's report looked like, Glebius?  Do you have a backtrace
from that?  Same code paths?  Also UDP? Also ovpn loaded?

I don't know how the openvpn kernel module is hooking into the input path;  if
it's using u_tun_func then that at least would explain why we do not see it in
the backtrace.  And then Takahiro Kurosawa's analysis from #c7 sounds fairly
valid if m_unshare can lose the PKTHDR on the copy.  OpenVPN doesn't have to be
active;  it seems if there's an interface the filtering function will be hooked
up.  And then it's not a regression in iwm or the network stack; then it's
imply the feature.

Adding Kristof and bouncing this back to net@.

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.