On 3/1/22 4:15 PM, David Laight wrote:
> From: Denys Vlasenko
>> Sent: 01 March 2022 21:57
>>
>> On Tue, Mar 1, 2022 at 5:39 PM Denys Vlasenko <[email protected]>
>> wrote:
>> > Meanwhile: what "timeout" is doing is it tries to get out
>> > of the way of the PROG to be launched so that timeout's parent
>> > sees PROG (not timeout) as a child. E.g. it can send signals
>> > to it, get waitpid notifications if PROG has been stopped
>> > with a signal, and such.
>> >
>> > And PROG also has no spurious "timeout" child.
>> > "timeout" exists as an orphaned granchild.
>> >
>> > Let's go with a solution with fd opened to /proc/PID?
>>
>> This little test:
>>
>> int fd = open("/proc/self", O_RDONLY);
>> int parent = getpid();
>> int pid = fork();
>> if (pid) { //parent
>> sleep(1);
>> exit(0);
>> }
>> sleep(2);
>> printf("openat:%d\n", openat(fd, ".", O_RDONLY));
>> while (openat(fd, ".", O_RDONLY) == -1)
>> continue;
>>
>> and a separate "spawn 40k 'sleep 0.03'" loop
>> seems to indicate that openat(fd, ".") on the exited
>> /proc/PID fails, and continues to fail
>> even if another process with this PID exists
>> again (pid was reused).
>
> Which kernel?
> That may not fail on pre-pidfd kernels.
Nah, nothing to do with that. If you have a file descriptor open to anything
under /proc/$PID then the reference count on the corresponding task struct can't
go to zero so the bit doesn't get cleared in the table. The dirfd still being
open pins it the same way a filehandle to a deleted file pins the inode...
Last I checked (many moons ago) there was a bitmask of active processes that
could be quickly checked for next empty bit and updated with lockless
compare-and-swap assembly magic (hence the O(1) part). That's why max_pid
defaults to 4096*8, it's one page. (I followed the O(1) rewrites when they went
in, and some of the early container work, but that was 10 years ago now...)
I still think it's silly to spend extra effort to make busybox timeout work
differently than anybody else's timeout, but it's Denys' codebase...
Rob
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
