https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
Mark Johnston changed:
What|Removed |Added
Status|Open|In Progress
Assignee|b..
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #77 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=7d1ab866911a2b29e041d64bc83a93638533f957
commit 7d1ab866911a2b29e041d64bc83a93638533f957
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #76 from Mark Johnston ---
(In reply to Mark Johnston from comment #75)
The problem has to do with the reimplementation of zone limits in 13.0. pf may
allocate items from the table entry zone before a limit is set, and these it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #75 from Mark Johnston ---
(In reply to Mark Johnston from comment #74)
Never mind, I'm able to reproduce this locally. On my test system we have:
vm.uma.pf_table_entries_3.limit.max_items: 200
vm.uma.pf_table_entries_3.li
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
Mark Johnston changed:
What|Removed |Added
Status|New |Open
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #73 from Kristof Provost ---
(In reply to Laurent Frigault from comment #72)
No, because it's not a fix but a debugging step.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #72 from Laurent Frigault ---
(In reply to Kristof Provost from comment #48)
Will your patch be included in the coming release 13.1 ?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #71 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #43)
The patch here also works on AMD64
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #70 from tech-li...@zyxst.net ---
I'm seeing the problem on stable/13-n249464-d0199f27c06 (AMD64) now
Shall I make another ticket for AMD64 specifically?
--
You are receiving this mail because:
You are the assignee for the bug
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #69 from Jean-Claude MICHOT ---
(In reply to tech-lists from comment #68)
13.0-RELEASE-p4 #0: Tue Aug 24 07:33:27 UTC 2021
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
running on Xeon
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #68 from tech-li...@zyxst.net ---
(In reply to Jean-Claude MICHOT from comment #67)
Is this on amd64 or arm64.aarch64 hardware?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
Jean-Claude MICHOT changed:
What|Removed |Added
CC||j...@michot.fr
--- Comment #6
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #66 from tech-li...@zyxst.net ---
writing to say the pf on the rpi4 is still working without error
% uptime
10:50p.m. up 12 days, 7:04, 7 users, load averages: 5.11, 4.85, 4.65
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
Kajetan Staszkiewicz changed:
What|Removed |Added
CC||veg...@tuxpowered.net
--- C
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #64 from Diego Linke ---
(In reply to tech-lists from comment #62)
kern.maxdsiz: 34359738368
net.pf.request_maxcount: 65535
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #63 from Kristof Provost ---
(In reply to tech-lists from comment #62)
net.pf.request_maxcount is not relevant for this issue. The allocation fails
after that check.
I'm less familiar with kern.maxdsiz, but it also appears to n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #62 from tech-li...@zyxst.net ---
(In reply to Diego Linke from comment #61)
Hi,
What do you have for the following sysctls:
kern.maxdsiz
net.pf.request_maxcount
?
--
You are receiving this mail because:
You are the assigne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #61 from Diego Linke ---
(In reply to Diego Linke from comment #54)
Just reporting that today I faced this issue again in another machine, after
the upgrade from 12 to 13.0.
Yes, this machine also doesn't have a lot of memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #60 from Diego Linke ---
(In reply to Diego Linke from comment #54)
Just reporting that today I faced this issue again in another machine, after
the upgrade from 12 to 13.0.
Yes, this machine also doesn't have a lot of memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #59 from jja...@gmail.com ---
(In reply to jjasen from comment #58)
This is on AMD64, FreeBSD 13.0-p4.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
jja...@gmail.com changed:
What|Removed |Added
CC||jja...@gmail.com
--- Comment #58
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #57 from tech-li...@zyxst.net ---
Hi,
Reporting that the rpi4 arm64.aarch64 is still running ok.
I did however encounter a similar error with an amd64-based bhyve vm. This vm
is unmodified
in comparison to the arm64.aarch64 dev
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #56 from tech-li...@zyxst.net ---
still ok
# doas -u _pfbadhost pf-badhost -O freebsd
Password:
pf-badhost 4113 - - Using experimental "aggy" aggregator...
24504 addresses added.
4155 addresses deleted.
pf-badhost 4181 - -
IP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #55 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #48)
Looks like your patch may have fixed the issue. I'll try making pfhost load
bigger tables to make sure.
So far, and it does this every 3 hrs appro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #54 from Diego Linke ---
(In reply to Kristof Provost from comment #53)
Yes, I does make sense.
I thought that I had free memory enough to load the tables without swap, the
tables are not so big.
Thank you very much I will c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #53 from Kristof Provost ---
(In reply to Diego Linke from comment #51)
> My last question is I had 79 Mb in free memory plus ~476 Mb in swap space. I
> wondering why PF as the last resource doesn't use swap memory to load the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #52 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #48)
ok the rpi4 is back up, with a new (current, GENERIC, so debug) kernel
[...]
pf-badhost 1405 - - Using experimental "aggy" aggregator...
1 table
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #51 from Diego Linke ---
(In reply to Kristof Provost from comment #50)
Yes it does make sense. I just reboot the machine and the PF is working fine
now. I was avoiding to make it to troubleshoot the issue better.
The machine
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #50 from Kristof Provost ---
(In reply to Diego Linke from comment #49)
So that looks a lot more like a machine that's at the limits of its free
memory, in which case what you're seeing isn't actually an error but things
working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #49 from Diego Linke ---
(In reply to Kristof Provost from comment #47)
Yes, this is small EC2 Virtual Machine. This used to work fine with FreeBSD 12
and pf.
# top -b | head -8
last pid: 22974; load averages: 0.81, 0.81,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #48 from Kristof Provost ---
(In reply to tech-lists from comment #46)
You'll also want to update pfctl.
cd /usr/src/sbin/pfctl && make && sudo make install should be sufficient for
that.
--
You are receiving this mail becaus
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #47 from Kristof Provost ---
(In reply to Diego Linke from comment #45)
Okay, that tells us at least that I used the entry probe in a few places where
I meant to use the return probe.
But also that it looks like in cache_alloc_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #46 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #43)
Thanks - tried first with manually applying, and got a build underway before i
saw yr update (will a kernel build/install be sufficient?)
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #45 from Diego Linke ---
(In reply to Diego Linke from comment #44)
Ops, I apologize, I pasted more than necesary in the comment above.
Please find the correct output. This is a FreeBSD 13 RELEASE amd64
# dtrace -s dtrace.sc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #44 from Diego Linke ---
(In reply to Kristof Provost from comment #40)
Hi, please find below the dtrace output, I hope it will be useful.
# dtrace -s dtrace_pf.sh -c "pfctl -f /etc/pf.conf"
dtrace: script 'dtrace_pf.sh' matc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #43 from Kristof Provost ---
Created attachment 230375
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230375&action=edit
no table limit patch
This is the same patch, but not mangled by being copy/pasted into and out
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #42 from tech-li...@zyxst.net ---
i'll try just manually editing it
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #41 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #40)
The patch doesn't apply:
# patch < pfpatch2.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #40 from Kristof Provost ---
(In reply to tech-lists from comment #39)
Yes please. Let's see if that makes a difference or not.
While we're at it, it'd be useful for someone who has an affected amd64 machine
to try this dtrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #39 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #35)
Would you like me to apply the patch and reboot?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #38 from Kristof Provost ---
(In reply to Andriy Gapon from comment #37)
Realistically no. It's pretty deep down the code path and would massively
complicate dealing with the ioctl.
It would also be a largely pointless exercise
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #37 from Andriy Gapon ---
(In reply to Kristof Provost from comment #36)
Could the allocation be done in advance, before the lock is taken?
If that's technically messy to do, then I recall that UMA has some sort of a
reservation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #36 from Kristof Provost ---
(In reply to Andriy Gapon from comment #34)
The allocation is done with the PF_RULES write lock held, and that's not a
sleepable lock. We need to hold the read lock for rules evaluation, so sleeping
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #35 from Kristof Provost ---
(In reply to Andriy Gapon from comment #31)
This should prevent the table limit from being set, so it's a little narrower
than just disabling the limit for everything:
diff --git a/sys/netpfil/pf/pf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #34 from Andriy Gapon ---
(In reply to Kristof Provost from comment #27)
Do memory allocations need to be done with M_NOWAIT if they are performed in a
context of a call (ioctl) from userland?
I think that it's not impossible th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #33 from Andriy Gapon ---
(In reply to tech-lists from comment #32)
Comment out all calls to uma_zone_set_max() under sys/netpfil/pf.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #32 from tech-li...@zyxst.net ---
(In reply to Andriy Gapon from comment #31)
How could that be done?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #31 from Andriy Gapon ---
I wonder whether it would help if --purely as a hack / experiment -- the limits
on uma zones that pf uses were removed.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #30 from Diego Linke ---
(In reply to Kristof Provost from comment #29)
Yes, I did. Please see below:
# vmstat -z | grep -E 'pf|ITEM'
ITEM SIZE LIMIT USED FREE REQ FAILSLEEP
XDOMAIN
pf mtags
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #29 from Kristof Provost ---
(In reply to Diego Linke from comment #28)
Have you checked the vmstat -z output as well?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #28 from Diego Linke ---
I don't think it's an exclusive issue of arm64 platform.
I am facing exactly this issue on a 13.0-RELEASE-p3 running at AWS EC2 instance
in an amd64 i386 platform.
--
You are receiving this mail becau
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #27 from Kristof Provost ---
Summarising some private debugging:
The "pfctl: Cannot allocate memory." originates in a failed uma_zalloc() in
pfr_create_kentry() on the V_pf_kentry_z ("pf table entries") zone. Confirmed
by dtrac
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #26 from Kristof Provost ---
I'll want more testing later, but I need to do some digging first and won't
have time to do that today. Go ahead and restart it. It seems to occur
sufficiently frequently that it shouldn't take very
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #25 from tech-li...@zyxst.net ---
can I restart it or would you like me to do some more testing?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #24 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #23)
it's gone up to 8 so far:
pf table entries: 160, 2540, 24700,5400, 58807, 8, 0, 0
i'll run the script again:
pf table en
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #23 from Kristof Provost ---
(In reply to tech-lists from comment #22)
Yeah, I'm aware of the consequences of this allocation failure. I'm just
struggling to work out why it's failing to allocate. There's no obvious reason
for i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #22 from tech-li...@zyxst.net ---
I cannot add any ip to any table while it's like this. This means programs like
sshguard (which monitors auth.log) cannot add ip addresses to its table
on-the-fly, which means they are no longer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #21 from tech-li...@zyxst.net ---
maybe worthwhile to mention I have in /boot/loader.conf:
kern.maxdsiz=4294967296
this was much smaller by default on this arch than expected when I set this
value.
--
You are receiving this ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #20 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #19)
> The only other reason I can see for it is that we're failing to find free
> memory to allocate from. So we're still at "Your system is out of me
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #19 from Kristof Provost ---
(In reply to tech-lists from comment #18)
> pf table entries: 160, 2540, 24700,5400, 58807, 4, 0, > 0
Okay, so that's the relevant line. Limit of 2540, 24700 used, 5400 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #18 from tech-li...@zyxst.net ---
# vmstat -m | grep -E 'pf|Size'
Type InUse MemUse Requests Size(s)
pfil11 1K 11 64,128
tcpfunc 1 1K1 64
pf_hash 5 11524K
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #17 from tech-li...@zyxst.net ---
might be of use:
# pfctl -si
Status: Enabled for 0 days 11:52:43 Debug: Urgent
State Table Total Rate
current entries 25
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #16 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #14)
ok it's failing now:
# vmstat -z | grep pf
pf mtags:48, 0, 0, 0, 0, 0, 0, 0
pf tags:1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #15 from tech-li...@zyxst.net ---
this might be a while as the time taken for it to fail has been variable
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #14 from Kristof Provost ---
(In reply to tech-lists from comment #12)
Okay, so we're failing allocation in pfr_create_kentry(), which means either
the V_pfr_kentry_z or V_pfr_kentry_counter_z zones.
After a failure take `vmsta
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #13 from tech-li...@zyxst.net ---
I'm not sure if the following information is of any use, but thought I'd
mention it in case it is:
1. with more or less the same config, but configured to block many more
addresses (so the table
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #12 from tech-li...@zyxst.net ---
after reboot, before loading pf:
# doas -u _pfbadhost pf-badhost -O freebsd
Password:
pf-badhost 1594 - - Using experimental "aggy" aggregator...
1 table created.
17842 addresses added.
pf-ba
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #11 from tech-li...@zyxst.net ---
this time, I couldn't reload pf even with the big table commented out again.
it won't load any tables at all. I'll have to restart the machine.
# pfctl -f /etc/pf.conf
/etc/pf.conf:23: cannot d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #10 from tech-li...@zyxst.net ---
OK - two tests, first one with the large table commented out (so pfctl -f
returns without error), second one with it uncommented
1.
# dtrace -n 'fbt:kernel:pfr_create_ktable:return { printf("%x
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #9 from Kristof Provost ---
> 2 36537pfr_ina_define:return c a000c1e48be0
> 2 36537pfr_ina_define:return 0 0
What? That's ... that can't be right. The first number should be the offset in
the fun
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #8 from tech-li...@zyxst.net ---
should be "block" rather than "clock"
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #7 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #6)
# dtrace -n 'fbt:kernel:pfr_ina_define:return { printf("%x %x", arg0, arg1); }'
dtrace: description 'fbt:kernel:pfr_ina_define:return ' matched 1 pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #6 from Kristof Provost ---
(In reply to tech-lists from comment #5)
No, run the dtrace command in one terminal and then (after dtrace has started)
the pfctl command in another.
If you have pf built into the kernel (why?) you'l
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #5 from tech-li...@zyxst.net ---
(In reply to Kristof Provost from comment #4)
version is FreeBSD 14.0-CURRENT #1 main-n251261-25d0ccbe101: Thu Dec 2
20:22:08 GMT 2021
kernel looks like this:
[...]
cpu ARM64
ident
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #4 from Kristof Provost ---
(In reply to tech-lists from comment #3)
That's strange. DIOCRINADEFINE does allocate memory, but the first (and
largest) allocation is done with M_WAITOK and cannot fail (or produce ENOMEM).
The alte
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
tech-li...@zyxst.net changed:
What|Removed |Added
CC||tech-li...@zyxst.net
--- Com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
--- Comment #1 from tech-li...@zyxst.net ---
also:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259798
some more stats
1. when it gets the error, before reboot
# vmstat -m | grep -E 'pf|Size'
Type InUse MemUse Requests Si
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260406
Bug ID: 260406
Summary: pfctl: Cannot allocate memory (after a time)
Product: Base System
Version: CURRENT
Hardware: arm64
URL: https://lists.freebsd.org/archives/freebsd-
79 matches
Mail list logo
