https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
Oleksandr Tymoshenko changed:
What|Removed |Added
Status|New |Closed
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #34 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kp
Date: Sun Mar 18 11:26:07 UTC 2018
New revision: 331117
URL: https://svnweb.freebsd.org/changeset/base/331117
Log:
MFC r329950:
pf: Cope with ov
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #33 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kp
Date: Sun Mar 18 11:25:40 UTC 2018
New revision: 331116
URL: https://svnweb.freebsd.org/changeset/base/331116
Log:
MFC r329950:
pf: Cope with ov
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #32 from fehmi noyan isi ---
Thank you!
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #31 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kp
Date: Sun Feb 25 08:56:44 UTC 2018
New revision: 329950
URL: https://svnweb.freebsd.org/changeset/base/329950
Log:
pf: Cope with overly large net.p
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #30 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #29)
Calling free(9) before reallocating the memory was a no brainer. Thanks!
Below is the diff
https://reviews.freebsd.org/D14367
--
You are receiving t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #29 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #28)
It's possible that one of the V_pf_keyhash or V_pf_idhash allocations
succeeded, but not the other. That means you may have to free one of them.
(Note
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
fehmi noyan isi changed:
What|Removed |Added
Attachment #190429|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #27 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #26)
Yes, your analysis looks to be correct. I'd go for the second option: try to
allocate both keyhash and idhash with the requested size. If either one fai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #26 from fehmi noyan isi ---
Created attachment 190476
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=190476&action=edit
Kernel Crash Dump
(In reply to Kristof Provost from comment #25)
The VM I am running the tests
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #25 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #24)
I'd change the error message ('invalid states hashtable size(%lu)', and
friends) to say there's not enough memory. It's not so much that the value is
in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
fehmi noyan isi changed:
What|Removed |Added
Attachment #176410|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #23 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #22)
Yeah, that's probably the best we can do for the allocation. It'd also be good
to log that we haven't allocated all of the requested memory.
That's par
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #22 from fehmi noyan isi ---
Hi there. I patched pf_initialize() in head (r328383, which has mallocarray(9))
by implementing a fallback mallocarray(9) call (as discussed in the comments)
if ((V_pf_idhash = mallocarray(pf_hash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #21 from david.ma...@davenulle.org ---
mallocarray() is now available for 11-Stable.
https://svnweb.freebsd.org/changeset/base/328210
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #20 from fehmi noyan isi ---
ok, if a patch with malloc(9) could find its way into stable/11, it would pay
to use malloc(9).
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #19 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #18)
Yes, mallocarray() would indeed be better. I'd suggest doing that in a separate
commit mostly because mallocarray() currently only exists in head, and t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #18 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #17)
Sounds a better approach than I suggested, thanks!
As the allocation size can be set by the user, don't you think mallocarray(9)
would be a better choi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #17 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #16)
Yes, absolutely. The potential for integer overflow is a separate issue.
I wouldn't try check_if_we_have_enough_memory() though. Memory allocation is
v
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #16 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #15)
>> It does now. It was added very recently (in head). man 9 mallocarray. It
>> might be worth doing that change in a separate commit.
This is news to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #15 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #14)
> So, does this come down to supplying a default value and re-attempting
> malloc() again?
I was thinking in that direction as well, yes. It's either
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #14 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #13)
>> I do see why, because it's non-trivial to cope with allocation failures in
>> that part of the code. It gets called from a VNET_SYSINIT(), so it do
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #13 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #12)
Yes, that's probably one of them.
There are a couple of allocations in pf_initialize() and they all use M_WAITOK.
I do see why, because it's non-trivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #12 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #11)
For the first issue you mentioned,
I think it is this line blocking the startup
V_pf_srchash = malloc(pf_srchashsize * sizeof(struct
pf_srchash),M_PFH
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #11 from Kristof Provost ---
(In reply to fehmi noyan isi from comment #10)
Yes, but I wouldn't check the free memory.
I've not yet looked at the code, but the original report suggests there are a
couple of related issues:
> k
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #10 from fehmi noyan isi ---
(In reply to Kristof Provost from comment #9)
Hi Kristof,
>>> There are no guarantees that the memory would not be allocated for
>>> something else.
If my interpretation of your comment is correct
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #8 from fehmi noyan isi ---
Hi there,
Just checking whether the last submitted patch is an appropriate solution to
the problem and satisfies the requirement set by Olivier in his comment on
2016-06-03.
Is there anything that i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
fehmi noyan isi changed:
What|Removed |Added
Attachment #170810|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #6 from fehmi noyan isi ---
Hi,
Somehow, I missed the notification for the latest comment! Sorry for the late
reply
It is possible to add a log warning message by using printf(9) or log(9), but I
have noticed that pf_initi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #5 from Olivier Cochard ---
Thanks: Your patch works great!
Could you add a log warning message when the not enough memory condition is
triggered ?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #4 from fehmi noyan isi ---
Hi,
In this forum post [1] from David, there is a bit of discussion about this PR
(apart from the original question).
Would checking the requested amount of memory by malloc(9) against the
available
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
--- Comment #3 from fehmi noyan isi ---
Created attachment 170810
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170810&action=edit
Patch for the proposed fix.
Patch file is created with
$ diff -u pf.c pf.c.fni > pf.c.diff
wher
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209475
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-pf@FreeBSD.org
--
You are
34 matches
Mail list logo
