- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 2 2019
Jul 1 2019
Jun 30 2019
Man page update and minor code rearrangement.
In D20786#450131, @mckusick wrote:Some of the checks that I am contemplating are expensive in that they may require extra I/O operations. Another possible thing is that I may spawn a process to run a full filesystem check before proceeding with the mount. These are not things that should or need to be done in the case of a trusted filesystem. I believe that the name "untrusted" well and succinctly describes this option.
In D20772#450488, @danfe wrote:Observations like "this condition is always true" and "it is guaranteed that old == owner here" should ideally be verified by static code analysis. I'd try to apply the patch and run PVS-Studio over it.
Jun 29 2019
Anyway, do as you want. Printing any estimation of the size in case of failure is an improvement on its own, even if not perfect.
In D20716#450173, @brooks wrote:I've addressed the main technical concerns (other then which syscall implementation to call). If we agree to move forward with this patch I can address style(9), but don't want to spend the time unless it's going to land in FreeBSD.
vm_map_protect() is not the only user of the vm_map_clip_start(). More, I suspect that wire/unwire and vm_map_delete() might be more prominent users, because apps do not change protection often, while they definitely unmap enough. Did you evaluate these cases ?
Jun 28 2019
Fix i386 casueword.
Handle Mark' notes.
Committed style change.
In D20663#450067, @arichardson wrote:I've managed to boot amd64 with these changes. The libc and libthr tests also complete successfully.
The only thing I noticed was the following during boot:lock order reversal: 1st 0xfffffe0000847200 bufwait (bufwait) @ /exports/users/alr48/sources/freebsd-universe/sys/kern/vfs_bio.c:3904 2nd 0xfffff800033e0200 dirhash (dirhash) @ /exports/users/alr48/sources/freebsd-universe/sys/ufs/ufs/ufs_dirhash.c:289 stack backtrace: #0 0xffffffff80c30bf3 at witness_debugger+0x73 #1 0xffffffff80c3093d at witness_checkorder+0xa7d #2 0xffffffff80bd0548 at _sx_xlock+0x68 #3 0xffffffff80ed741d at ufsdirhash_add+0x3d #4 0xffffffff80eda206 at ufs_direnter+0x446 #5 0xffffffff80ee14a2 at ufs_rename+0xe82 #6 0xffffffff81217fe0 at VOP_RENAME_APV+0x70 #7 0xffffffff80ca812b at kern_renameat+0x36b #8 0xffffffff81092af6 at amd64_syscall+0x276 #9 0xffffffff8106ad6d at fast_syscall_common+0x101However, it seems unlikely that this is caused by my rtld changes and more likely that I booted with a broken kernel version.
I am not sure how useful this option is.
Jun 27 2019
Hopefully fix two bugs.
Jun 26 2019
Remove extra empty line.
In D20663#449383, @arichardson wrote:In D20663#449349, @kib wrote:In D20663#449347, @arichardson wrote:In D20663#449299, @kib wrote:What testing was done ? Did you boot amd64 multiuser with the patched rtld ?
libthr consumes some bits from rtld, mostly rtld_malloc.c.
libthr still builds fine (I did a full universe build).
Did you do any runtime testing of threaded apps ?
I did not try any threaded applications yet. Do you have any suggestions what would be a good test case?
Perhaps run libc and libthr tests from /usr/tests ...
Update ppc inline asm comment.
sparc64 bugs pointed out by Mark.
In D20663#449347, @arichardson wrote:In D20663#449299, @kib wrote:What testing was done ? Did you boot amd64 multiuser with the patched rtld ?
libthr consumes some bits from rtld, mostly rtld_malloc.c.
libthr still builds fine (I did a full universe build).
Did you do any runtime testing of threaded apps ?
What testing was done ? Did you boot amd64 multiuser with the patched rtld ?
Overall, I like where you get at. The realpath.c and rtld-elf/debug.h changes can be already committed separately.
I believe that the code is fine from the algorithmic PoV, but I suggest some minor renaming and rearrangement.
Jun 25 2019
IMO removing the sentence at all is overreaction, you can say 'will be copied' or use any other syntax construct that indicates that copying could occur in future.
With Mark' note, accepted.
Jun 24 2019
I suggest you to go ahead with smbfs part.
Jun 23 2019
Two more language fixes.
Language corrections.
In D20663#448176, @arichardson wrote:Okay, I'll try extracting the required files from libc_nossp_pic.a using ar and link against those files. Is that what you were suggesting? I would prefer building all the .o files, but I think there might be some per-architecture assembly files that need to be included and adding that logic to the makefile is slightly annoying.
Ok for me, but I wonder how would it work. Basically, to avoid the interposing code, you need to use _xxx or __sys_xxx symbols directly, right ? Then if you do, wouldn't simply linking with libc_nossp_pic.a enough ?
In D20663#448150, @arichardson wrote:In D20663#448138, @kib wrote:I always wanted to remove -lc (or any currently used variant of libc) from the rtld linking. Ideally, we would just compile required libc sources second time for rtld, inside libexec/rtld-elf. I am sure that this would be a lot of work, but I am not sure that it would be much more work than continuing the approach of patching libc.a to cut off unneeded pieces.
There are not actually that many files from libc that are used in rtld. Here is the -Wl,--trace output:
...
I think if we linked against a libsyscalls (D14609) we only really need to build the string-related files (plus a few more which seem to mostly come from getenv()) again.
I always wanted to remove -lc (or any currently used variant of libc) from the rtld linking. Ideally, we would just compile required libc sources second time for rtld, inside libexec/rtld-elf. I am sure that this would be a lot of work, but I am not sure that it would be much more work than continuing the approach of patching libc.a to cut off unneeded pieces.
Add comments explaining the callout use and recheck.
Jun 22 2019
In D20720#448095, @trasz wrote:Without this commit, Linux ldd is broken - it errors out due to not being able to exec rtld. No idea why rtld is like this, but, well, it is - both in Centos and Ubuntu.
It probably also fixed Android binaries; I hadn’t tested it this time.
There is a lot of style(9) violations, and I stopped listing at some point. Each thing I noted is recurrent.
In which way does it fix ldd, and why ? [As usual, you do not bother to explain]
You can't use block special nodes for anything on FreeBSD. In particular, they cannot be used for swap.
Jun 17 2019
In D20636#446616, @alc wrote:I would suggest that you add a comment to the code explaining why the callout is necessary.
Jun 16 2019
Feel free to do the rename in the preliminary commit.