- User Since
- May 16 2014, 7:35 PM (274 w, 3 d)
Note that for devfs vnodes the vnode lock is often not held when writes are started. This is esp. true when metadata io is initiated by UFS.
Please fix two style issues, no need to re-post the updated patch.
Sun, Aug 18
Sat, Aug 17
Fri, Aug 16
I suspect the diff generation missed vm_phys.c.
I noted on IRC that roundup2 on line 1058 might result in overflow as well, at least theoretically.
vM is coded using (somewhat) abstracted types. We do not assume that everything is ILP32 or LP64, at least not in places where it is easy to avoid and which would create one more portability bug for future system porting.
Is seg->end 0xffffffff or 0 for the problematic case ? Anyway, I prefer the explicit check for overflow, it makes the things absolutely clear for reader.
Thu, Aug 15
solo% ls -l /usr/local/bin/clang ~ lrwxr-xr-x 1 root wheel 7 Aug 5 22:10 /usr/local/bin/clang -> clang90 solo% pkg which /usr/local/bin/clang ~ /usr/local/bin/clang was installed by package llvm-90 solo% pkg which /usr/local/bin/clang90 ~ /usr/local/bin/clang90 was installed by package llvm90-9.0.0.r1_1
Peter, could you please, test the patch ? The only interesting scenarios are OOMs. It should allow the system to unwind from low memory situations much quicker, or sometimes it should make out of problems previously causing hang.
Add sysctls descriptions, slightly edited from the wording provided by Mark.
(assuming Mark and John notes are handled)
Wed, Aug 14
Tue, Aug 13
Update the patch to the latest merge, trying to revive the review process.
Mon, Aug 12
Sun, Aug 11
Sat, Aug 10
Remove confusing comments in linuxolator that mention COMPAT_43.
Ultimately we want some other sysctl to get the list of filedescs, because kern.proc.filedesc performs a huge amount of the work that is discarded.
Fri, Aug 9
Add comment hinting why we do not stop iteration on asprintf (malloc) failure.
- Can you rewrite the review summary according to the new code ? I want to see the commit message for the change.
- Looking at proc_to_reap() and you initial note about kern_wait6(), I wonder should we check for p_procdesc for all idtype cases in proc_to_reap() ? In other words, isn't there somewhat larger problem with kern_wait6() reaping procdesc zombies at all ?
Thu, Aug 8
Add checks for ENOMEM.
Wed, Aug 7
Do not leak pwbuf.
Fix bugs pointed out by ian. I did not found other instances of it.