On Sat, Oct 23, 2021 at 03:36:53AM +0000, Visa Hankala wrote:
(cut)
> > >Fix:
> > None provided. Unfortunately I don't have a DDB capable console.
>
> Thank you for the report. It looks that the bug is generic and not
> specific to the machine.
>
> On amd64, the test program triggers the following:
>
> panic: free: size too large 32768 > 512 (0xffff800005683000) type devbuf
> Stopped at db_enter+0x10: popq %rbp
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> 182043 96299 0 0x3 0 3K bpftest
> *203812 7765 0 0x14000 0x200 1 smr
> db_enter() at db_enter+0x10
> panic(ffffffff81e64303) at panic+0xbf
> free(ffff800005683000,2,8000) at free+0x409
> bpf_d_smr(ffff800005612e00) at bpf_d_smr+0x4f
> smr_thread(ffff8000225da548) at smr_thread+0x21e
> end trace frame: 0x0, count: 10
>
> The panic happens when freeing bd->bd_fbuf. Curiously, both bd->bd_sbuf
> and bd->bd_hbuf are NULL. Also, many calls of ioctl(BIOCSETIF) have
> failed with ENOMEM. If bpf_allocbufs() fails, bd->bd_fbuf might be
> a dangling pointer.
>
> The following fix seems to help:
>
> Index: net/bpf.c
> ===================================================================
> RCS file: src/sys/net/bpf.c,v
> retrieving revision 1.205
> diff -u -p -r1.205 bpf.c
> --- net/bpf.c 15 Jun 2021 05:24:47 -0000 1.205
> +++ net/bpf.c 23 Oct 2021 03:19:56 -0000
> @@ -1553,6 +1553,7 @@ bpf_allocbufs(struct bpf_d *d)
> d->bd_sbuf = malloc(d->bd_bufsize, M_DEVBUF, M_NOWAIT);
> if (d->bd_sbuf == NULL) {
> free(d->bd_fbuf, M_DEVBUF, d->bd_bufsize);
> + d->bd_fbuf = NULL;
> return (ENOMEM);
> }
>
This fixes it for me! My RPIv4 lives on! Thank you! What's funny is that
I tested the program on my amd64 macbook pro with 16 GB RAM, and it did not
panic there. Could the amount of memory have anything to do with this issue?
Best Regards,
-peter
