panic: sackhint bytes rtx >= 0

' , server = 0}, { t_end_info_bytes = "\000\000\000\000\000\000\000", t_end_info = 0}} (kgdb) p *tp@entry->sackhint.nexthole $8 = {start = 3846396940, end = 3846398380, rxmit = 3846398380, scblink = {tqe_next = 0x0, tqe_prev = 0xf8013da5a330}} -- Andriy Gapon __

Re: AW: panic: sackhint bytes rtx >= 0

ng else from the crash dump, please let me know. > *Von:*tue...@freebsd.org > *Gesendet:* Dienstag, 23. Februar 2021 22:21 > *An:* Richard Scheffenegger > *Betreff:* Fwd: panic: sackhint bytes rtx >= 0 > >   > > *NetApp Security WARNING*: This is an external email. Do n

Re: panic: sackhint bytes rtx >= 0

On 25/02/2021 20:20, Michael Tuexen wrote: >> On 25. Feb 2021, at 19:08, Andriy Gapon wrote: >> >> On 24/02/2021 00:40, Scheffenegger, Richard wrote: >>> Hi Andriy, >>> >>> I guess I am currently the person who has the most recent knowledge about &g

page fault in pfioctl

syscallenter() at 0x80b30cc9 = syscallenter+0x159/frame 0xfe01cb072ca0 -- Andriy Gapon

Re: page fault in pfioctl

On 13/06/2021 10:26, Kristof Provost wrote: On 12 Jun 2021, at 19:59, Andriy Gapon wrote: Not sure if this has been reported, or maybe even fixed, yet. The crash happened with stable/13 as of 92f49c769b4 (June 3). Judging from the time I think that it happened when running a periodic report

network crash in nhop_free

ocked+0x178 gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x9c fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 -- Andriy Gapon

Re: network crash in nhop_free

It seems that the panic message was panic: Misaligned access from kernel space! On 22/06/2021 12:54, Andriy Gapon wrote: Not sure if I'll be able to get more out of this arm64 machine. I was playing with ppp and switching routes between LAN and ppp when the crash happened. The system

Re: network crash in nhop_free

= 0xa0ddf900, nh_next = 0xa00027813900, nh_vnet = 0xa084c580, nh_epoch_ctx = {data = {0x005a2f90 , 0x0}}} (kgdb) p *nhg_priv->nhg_nh_weights[1].nh->nh_priv $8 = {nh_family = 2 '\002', spare = 0 '\000', nh_type = 2, rt_flags = 2050, nh_idx =

Re: network crash in nhop_free

On 01/08/2021 16:36, Alexander V. Chernikov wrote: On 10 Jul 2021, at 10:07, Andriy Gapon wrote: On 09/07/2021 00:02, Alexander V. Chernikov wrote: Hi Andriy, Could you by any chance provide a bit more info on the system networking configuration and the steps leading to panic? No chance

Re: network crash in nhop_free

On 30/08/2021 10:28, Andriy Gapon wrote: On 01/08/2021 16:36, Alexander V. Chernikov wrote: On 10 Jul 2021, at 10:07, Andriy Gapon wrote: On 09/07/2021 00:02, Alexander V. Chernikov wrote: Hi Andriy, Could you by any chance provide a bit more info on the system networking configuration

Re: network crash in nhop_free

>nhg->nhops[1] is okay, but nhg_priv->nhg_nh_weights[1].nh points to freed memory: (kgdb) x/a nhg_priv->nhg_nh_weights[1].nh 0xa000369f1400: 0xdeadc0dedeadc0de On 30/08/2021 10:32, Andriy Gapon wrote: Some more details from the today's crash: panic: Misaligned acce

recvmsg() "short receive" after FIONREAD

. -- Andriy Gapon

Re: recvmsg() "short receive" after FIONREAD

On 10/09/2021 21:51, Andriy Gapon wrote: I observe a problem with the code that can be seen here: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sap.c#L142 The code uses ioctl(FIONREAD) to check the size of available data in a socket. Does / should this

Re: recvmsg() "short receive" after FIONREAD

On 10/09/2021 22:35, Mark Johnston wrote: On Fri, Sep 10, 2021 at 10:15:37PM +0300, Andriy Gapon wrote: On 10/09/2021 21:51, Andriy Gapon wrote: I observe a problem with the code that can be seen here: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/modules/rtp/sap.c

Re: recvmsg() "short receive" after FIONREAD

On 10/09/2021 22:38, Andriy Gapon wrote: On 10/09/2021 22:35, Mark Johnston wrote: Indeed, I suspect that this is the problem.  Note that for kevent(EVFILT_READ) we subtract the number of control message bytes from the returned value, see filt_soread().  I wonder if FIONREAD should do the same

Re: recvmsg() "short receive" after FIONREAD

On 10/09/2021 22:40, Andriy Gapon wrote: On 10/09/2021 22:38, Andriy Gapon wrote: On 10/09/2021 22:35, Mark Johnston wrote: Indeed, I suspect that this is the problem.  Note that for kevent(EVFILT_READ) we subtract the number of control message bytes from the returned value, see filt_soread

Re: recvmsg() "short receive" after FIONREAD

so_rcv) - so->so_rcv.sb_ctl; } break; Let me try adding the lock. Thank you again! -- Andriy Gapon

Re: recvmsg() "short receive" after FIONREAD

On 11/09/2021 17:16, Andriy Gapon wrote: On 11/09/2021 17:13, Mark Johnston wrote: I think the semantic change is ok.  Did you change FIONREAD to lock the sockbuf?  I think it would be necessary to avoid races with pulseaudio: sb_acc is modified before sb_ctl, so there could be windows where

Re: recvmsg() "short receive" after FIONREAD

On 11/09/2021 17:28, Andriy Gapon wrote: On 11/09/2021 17:16, Andriy Gapon wrote: On 11/09/2021 17:13, Mark Johnston wrote: I think the semantic change is ok.  Did you change FIONREAD to lock the sockbuf?  I think it would be necessary to avoid races with pulseaudio: sb_acc is modified before

Re: recvmsg() "short receive" after FIONREAD

On 11/09/2021 21:40, Mark Johnston wrote: On Sat, Sep 11, 2021 at 09:25:42PM +0300, Andriy Gapon wrote: So, this is what I've got: diff --git a/sys/kern/sys_socket.c b/sys/kern/sys_socket.c index e53b0367960b..11ee03703407 100644 --- a/sys/kern/sys_socket.c +++ b/sys/kern/sys_socket.c @@ -

Re: page fault in pfioctl

On 13/06/2021 11:19, Kristof Provost wrote: On 13 Jun 2021, at 09:41, Andriy Gapon wrote: Based on the panic message (page fault with non-sleepable locks held), it seems that the problem is with holding the lock across the copyout. Usually that won't panic, but if the destination happe

Re: page fault in pfioctl

On 25/09/2021 19:25, Andriy Gapon wrote: On 13/06/2021 11:19, Kristof Provost wrote: On 13 Jun 2021, at 09:41, Andriy Gapon wrote: Based on the panic message (page fault with non-sleepable locks held), it seems that the problem is with holding the lock across the copyout.  Usually that won&#

Re: page fault in pfioctl

On 25/09/2021 19:34, Kristof Provost wrote: On 25 Sep 2021, at 18:25, Andriy Gapon wrote: On 13/06/2021 11:19, Kristof Provost wrote: On 13 Jun 2021, at 09:41, Andriy Gapon wrote: Based on the panic message (page fault with non-sleepable locks held), it seems that the problem is with holding

Re: page fault in pfioctl

On 25/09/2021 19:38, Andriy Gapon wrote: On 25/09/2021 19:34, Kristof Provost wrote: On 25 Sep 2021, at 18:25, Andriy Gapon wrote: On 13/06/2021 11:19, Kristof Provost wrote: On 13 Jun 2021, at 09:41, Andriy Gapon wrote: Based on the panic message (page fault with non-sleepable locks held

NULL pointer crash in iflib_rxd_pkt_get with vmxnet3

ifsd_fl = 0xf80002d93400} m = 0xf80123211c00 (kgdb) p m->m_data $1 = (caddr_t) 0xf80123211c58 "" (kgdb) p sd.ifsd_cl $2 = (caddr_t *) 0xf80002d61a38 (kgdb) p *sd.ifsd_cl $3 = (caddr_t) 0x0 Is this a known issue? Is there a chance that this has already been fixed? Thank you. -- Andriy Gapon

iflib_stop: drain rx tasks to prevent any data races

I am going to commit https://reviews.freebsd.org/D32926 Please speak up if there are any objections / concerns. -- Andriy Gapon

vmxnet3: possible bug in vmxnet3_isc_rxd_pkt_get

en in ifr_frags[]. vxcr_zero_length and vxcr_pkt_errors are both not zero, so maybe something got the driver into a confused state or the emulated hardware became confused. -- Andriy Gapon

Re: vmxnet3: possible bug in vmxnet3_isc_rxd_pkt_get

On 19/11/2021 20:19, Andriy Gapon wrote: Here is some data to demonstrate the issue: $1 = (iflib_rxq_t) 0xfe00ea9f6200 (kgdb) p $1->ifr_frags[0] $2 = {irf_flid = 0 '\000', irf_idx = 1799, irf_len = 118} (kgdb) p $1->ifr_frags[1] $3 = {irf_flid = 1 '\001', irf_idx

Re: vmxnet3: possible bug in vmxnet3_isc_rxd_pkt_get

On 19/11/2021 20:46, Andriy Gapon wrote: I think that this was the case and that I was able to find the corresponding descriptors in the completion ring. Please see https://people.freebsd.org/~avg/vmxnet3-fragment-overrun.txt $54 is the SOP, it has qid of 6. It is followed by many fragments

pseudo-device ef

c029bb80 d sysctl___net_inet_ipsec_def_policy but no XXNfM interfaces come into existance after boot. On the other hand, if I load the corresponding module if_ef via loader.conf, everything works like charm. Am I missing something or is there a problem with the code ? -- Andriy Gapon * "The

ipsec & ipfw: 4.7-release vs -stable

in the case I have missed any latest developments in this area. -- Andriy Gapon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message

Re: ipsec & ipfw: 4.7-release vs -stable

rhaps change 1.214 can > be reworked or reverted? I'll file a PR. Mike, filing a PR is an excellent idea. I think that should have been from the start. Thank you. -- Andriy Gapon * "In my view XML is to data representation what Roman numerals are to math." (c) Bakul Sha

dummynet + ipsec

Does ipsec + dummynet combination work under 4.7-release / stable ? Any tricks ? Namely, I want to pass esp packets to a pipe in ipfw rules. Thank you in advance. -- Andriy Gapon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message

Re: An interesting anomaly in NFS client...

/> I'm seeing this on 15 currentish (last few months). Could it be just make checking for stale targets? I.e., stat-ing various files to check their timestamps. -- Andriy Gapon

iflib expert group

Is there an iflib expert group? Or any forum to talk about iflib design, implementation, correct usage, etc with people who created iflib, worked on iflib, interested in iflib, etc? E.g., like geom@ is for GEOM. -- Andriy Gapon

[Differential] [Changed Subscribers] D1438: FreeBSD callout rewrite and cleanup

avg added a subscriber: avg. REVISION DETAIL https://reviews.freebsd.org/D1438 To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn, rrs, kostikbel, delphij, neel, erj, mat, remkolodder, bcr, brueffer, brd, allanjude, wblock Cc: avg, jch, wblock, freebsd-net _

[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)

avg added a subscriber: avg. avg added a comment. This has already been committed, so I've missed the train, but I still would like to comment. And I hope that my comment won't be just a rant. So, I don't like this change for several reasons. For one, given that nv(9) is a new thing while libnvp

[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)

avg added a comment. Another thought. Or was the intention only to make nv(9) and hrm.. nvpair compatible only within the kernel? Section 9 seems like a big hint here, but I am not sure. If the intention was such, then my previous comment is to inform that that change affected the userland as w

[Differential] D10485: Replace dhcp option 150 by 66

avg added a comment. I only recently looked into our pxeboot and it seems to be grossly non compliant with the PXE specification. And it probably needs to be because it acts as a PXE client. For starters, it does not support "Proxy DHCP" (a PXE server running separately from a DHCP server

[Differential] D10603: distinguish NFS versus TFTP boot by rootpath

avg added a comment. My opinion is that pxeboot is in the same league as ipxe. Of course, pxeboot is more specialized, but it is still a chain-loaded PXE boot client. I see two possibilities of providing FreeBSD specific boot information. Either we provide it via FreeBSD vendor extensions

[Differential] D24989: netinet: Generate a random RSS key on boot.

avg added a comment. I have a vague memory, maybe wrong, that commonly used fixed RSS keys were selected because they had some property (-ies). So, maybe just being random is not good enough? I think that hypothetical `rss_isbadkey` was mentioned for a reason? REPOSITORY rS FreeBSD src

[Differential] D24989: netinet: Generate a random RSS key on boot.

avg added a comment. In D24989#552693 , @neel_neelc.org wrote: > I believe Linux just uses random keys: > > - https://github.com/torvalds/linux/blob/29d9f30d4ce6c7a38745a54a8cddface10013490/net/ethtool/ioctl.c#L924 You are right. So, my

<    1   2