- User Since
- Jun 4 2014, 10:38 AM (334 w, 2 d)
- also patch malloc_domainset
They had kmem_malloc and that got patched to malloc(...., M_EXEC) so I did not deviate from the general direction. That said, I'm indifferent to this one as long as the flag is gone from malloc itself.
Thu, Oct 29
Tue, Oct 27
Mon, Oct 26
A proper fix would avoid entering a jail to begin with, but that may be too much work right now.
This is a bug in jail significant enough to add a syscall doing the trick.
This is a non-starter imo. For example tmpfs does not do anything with dev and you are expected to pass "tmpfs" as the argument. However, at some point the argument may become meaningful. But then it will be susceptible to getting clobbered if the passed value happens to match a file in cwd.
Sat, Oct 24
Fri, Oct 23
Thu, Oct 22
Wed, Oct 21
Tue, Oct 20
Mon, Oct 19
Sat, Oct 17
Fri, Oct 16
Thu, Oct 15
If you can confirm that glib's fdwalk also passes your tests I'll take a fresh look at this patch and commit.
Wed, Oct 14
Tue, Oct 13
Mon, Oct 12
Do we even need this in default installs? As in, what happens if this does not get compiled at all?
Sun, Oct 11
If someone is to do anything serious with gcc I suggest the following:
- scratch version 9, use 10. the port may need updating.
- review all passed flags. I know some warns got silenced over the years just to get the compile rolling, despite pointing at legitimate problems.
- find a switch to make gcc leave enums alone and rely on clang for correctness
Is this a gcc build?
Sat, Oct 10
Fri, Oct 9
Wed, Oct 7
Well I'm note sure about NET_EPOCH_CALL semantics.
This looks fine to my cursory reading. Again, someone with stake in the area will have to ACK it.
Why not a step further and a global list of protocols? Regardless, this will need a buy in from someone from the network stack. I don't have stake here.
You can keep the flag and add the 2 lists anyway. The unload handling can be added later.
Future work can fix that up to make sure we don't find partially constructed domains, but care must be taken to make sure that at least, e.g., the usages of pffindproto in ip_input.c can still find them.
Tue, Oct 6
Mon, Oct 5
Fri, Oct 2
Oct 1 2020
Sep 30 2020
this adds a branch which likely pessimizes the code
Sep 29 2020
Sep 28 2020
can you elaborate on the nfs server problem? for example, if the concern is that it will tie down a thread for an extended amount of time, the 1 second timeout is already orders of magnitude too big. I know nfs likes to postpone signals in some cases, but all the copying here should be above any of that code.
It should not return after any specific period, instead it should check for yield and pending signals every n iterations.
Sep 24 2020
Sep 23 2020
Sep 20 2020
Now that's embarassing. Nice find.
Sep 16 2020
Given this already has support for reusing items from a global list, why uma allocation in the first place? Most notably why per-CPU caches. The current code does not scale regardless and is expensive to use, but with expected low msg rates it should be fine for the time being.