User Details
- User Since
- May 28 2014, 2:27 PM (608 w, 2 d)
Yesterday
Wed, Jan 21
Tue, Jan 20
Mon, Jan 19
Looks great, thanks!
Sun, Jan 18
Sat, Jan 17
Fri, Jan 16
I have very little idea about that. I'm just working on making interfaces detach more safe and I want in6_ifextra to be a single piece of memory which would have delayed reclamation.
Thu, Jan 15
Wed, Jan 14
Have you tried to submit this the tcpdump project itself? https://github.com/the-tcpdump-group/tcpdump
Mon, Jan 12
Sat, Jan 10
Thu, Jan 8
I would suggest to go deeper and call memset() directly. These empty proxy functions do not improve readability.
Wed, Jan 7
The description mentions ip_output(), but in reality the patch is against rip_send(), which is send(2) method for a PF_INET/SOCK_RAW. Looks like with a specially crafted send(2) we can achieve such a bogus mbuf. Instead of putting the bandaid let's find out how this mbuf was produced and fix the bug. Note that mbufs are formed outside of protocol implementation, so potentially the problem discovered may apply to other protocols beyond PF_INET/SOCK_RAW.
The only sleepable context where the lock was acquired was dyn_tick(). The comment said it is done to prevent parallel execution of dyn_expire_states(). However, there is proper internal locking in there and function should be safe to execute in parallel. The real problem is dyn_expire_states() called via userland to race with dyn_grow_hashtable() called via dyn_tick(). Protect against this condition with the main chain lock.
Tue, Jan 6
- Fix lock leak in ipfw_commit_rules().
Mon, Jan 5
But where is the ICMP_REDIRECT_DEFAULT_TIMEOUT defined? The patch as is can't be compilable.
Thanks!
Thu, Jan 1
Sat, Dec 27
Well I think you're right. if_getifaddr() ( wrapper around ifp->if_addr ) is the right accessor to get link level address. Using that directly is much simpler than a iterator.
Dec 23 2025
Have you tried chaining mbufs instead of having an array? Does that have negative cache effect?
Dec 22 2025
Dec 19 2025
I'd also suggest to change it to SYSCTL_BOOL.
Dec 18 2025
Dec 17 2025
As we discussed in private email exchange, this is speculatively supposed to be safe. I tested only on CPU Family=0x19 Model=0xa0 Stepping=0x02, that doesn't have updated BIOS. The microcode in the CPU matches the first version in the blob and safely failed to upgrade to the newer version. The expected failure message was printed.
Dec 16 2025
- Rebase. USB already has been taken care of.
- Rebase better.
- Add missing line.
- Rebased. No functional changes.
- Split into two events
