- User Since
- Jun 4 2014, 10:38 AM (271 w, 5 d)
Sun, Aug 18
Sat, Aug 17
Thu, Aug 15
I used alloca. It may be wasteful on the stack for a very poorly behaving process but it should be fine. I don't think paying for mmap is justified.
I think I sufficiently hacked this for inclusion. First the kernel part, then fdwalk itself.
I had an extra look and there is an extremely worrisome comment: apparently the routine is expected to by async-signal safe. This means both malloc and realloc are off the table. This can be worked around with having a statically sized buffer and requesting the bitmap in chunks which fit the buffer, i.e. pass the buffer and an offset (size of the buffer * iteration counter). See https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gspawn.c#L1182
So I had a look at glib. What's the benefit of adding this function to libc? All consumers are going to link to glib anyway. Perhaps we should get the kernel part in and then submit a patch to glib to use it.
Tue, Aug 13
Sat, Aug 10
It's not hard to add such a sysctl. If you want I can hack it up for you. I think it should just export the fd bitmap, then iteration over it is trivial.
Sat, Jul 27
The entire thing can be probably hacked to be better, but I don't have good ideas as it is.
Sun, Jul 21
Jul 19 2019
Jul 18 2019
Jul 14 2019
Architectures problematic in this regard definitely don't have anywhere near enough resources for a 32-bit overflow to be realistic, so they can stick to that size.
Note I did not propose converting refcount to long (or 64-bit). I proposed adding a long (or 64-bit) variant.
Jul 13 2019
I don't think this is the right fix. There is other code bumping the count (with fhold()) and that is still unchecked.
Jun 29 2019
It's not about just copying. fget_unlocked is severely pessimized right now and so happens to amount of __predict_true/false convinces clang to not generated a jump fest for the common case.
Half-scratch my previous comment. Of course at the time the state is already possibly in flux so it has to be moved away if assertions are to be kept. See the other point though.
Jun 28 2019
I don't think it's useful to move it out, it's an avoidable branch. i.e. I think it would be better to:
Jun 27 2019
Jun 7 2019
May 25 2019
I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose. lindevfs module could be created to extend devfs mount points with whatever is necessary. Preferably this would be a completely separate fs, but that's probably too problematic. i.e. currently the module would make_dev("shm") on it's own. the func can create directories and if it insists on getting a device, a separate variant can be added.
May 12 2019
May 10 2019
No. Locking was significantly revamped and the problem at hand us unlikely to be encountered. Should it be encountered, the new (much finer-grained) locking can be modified to use exclusive-only locks. The speed up as reported here was disputed on the mailing lists and was likely not present.
May 8 2019
May 7 2019
- remove proc locking in the first place
May 4 2019
Apr 24 2019
This works fine
Extended the patch with:
+ if (!(((object->flags & OBJ_TMPFS) == 0 && + object->type == OBJT_VNODE) || + ((object->flags & OBJ_TMPFS) != 0 && + object->type == OBJT_SWAP))) + printf("obj %p flags %x type %d\n", object, object->flags, object->type);
Sorry, I meant early when running poudriere. vp is NULL in vm_map_entry_inc_vnode_text. Can be trivially reproduced by having the shell fork when backed by tmpfs, in particular unpacking world, 'chroot . sh' + 'ls' do the trick.
Apr 23 2019
This crashes for me early on:
Apr 18 2019
I gave it a spin with poudriere and it panics:
Apr 14 2019
Apr 12 2019
Apr 5 2019
Apr 3 2019
Mar 27 2019
Mar 25 2019
What's the motivation for this functionality?
Mar 13 2019
So I'm in the process of reviewing this. I don't have a complete review yet, but I do have some comments.
Mar 12 2019
Feb 27 2019
Feb 26 2019
Feb 5 2019
Lock acquisition can be moved few lines later, after branching on data. Similarly, unlock can be done earlier.
Feb 1 2019
That's an error-prone approach. You should always have separate references for both ucred and pucred.
Jan 30 2019
I don't have an opinion about the userspace API. It does seem a little bit fishy that there is no tight control from that end. I would expect a fully-privileged daemon to get create a credfd an allow certain uids/gids to be switched to. Then it can drop privs. But again, I did not think this through.
Jan 29 2019
Dec 28 2018
Oops, indeed. Thanks for the fix.
Dec 27 2018
Dec 20 2018
See this review https://reviews.freebsd.org/D27
I have a machine where I reliably fail to git clone postgres repository, it always gets stuck at about 20%. This patch fixes it.
Dec 19 2018
This already landed in r342237, I see I forgot to add the line.