In D56022#1287961, @aokblast wrote:

In D56022#1282431, @kib wrote:

In D56022#1282270, @aokblast wrote:

In D56022#1281980, @kib wrote:

No. Perhaps it is simpler to show code than to try to explain it, See D56053.

The example you provided would not work with my patch, it requires increasing the CXA_DTORS_ITERATIONS. Not sure if we want this.

If it breaks the valid C++ code, we should rethink about it. The T value can be somehow greater than CXA_DTORS_ITERATIONS if the user wants.

I do not disagree but there are also some robustness requirements as part of the implementation quality. So I am unsire, this is why I initially said that 'I am on edge' proposing this. Hanging in the system state (thread exiting) due to user bug is not robust.

That said, your patch should remove walk_cb_nocall(). And perhaps cxa_thread_walk() could drop the argument, simply inlining walk_cb_call.

I see, I think we can leave this patch in here before we get better conclusion. I run the test code on a Linux machine and it died immediately if we have infinity loop in thread local destructor. It seems that glibc also don't handle that case.

Pass tinderbox.

The version that builds with TARGET=arm64

Provide actual implementation for fegetenv, feenableexcept, fedisableexcept on aarch64.

Remove conditional include of the arch symbol map. All arches provide it, after the patch.

This is probably fine, but then resetting m_needs_zeroing seems to be somewhat unneeded. I started thinking that m_needs_zeroing should be removed, and when we find an invalid page on the shadowing object queue, we need to zero it immediately.

In D55912#1287198, @gallatin wrote:

You mean as a later, separate project, correct?

Sorry for the late reply.

The mere fact that we slept on the page somewhere in the shadow hierarchy does not mean that first_m should be zeroed.
But, if we go this route, then IMO m_needs_zero should be reset to true right at the RetryFault, and be done with it.

In D56223#1286935, @kevans wrote:

Hmm, The second kqueue might not be as useful as I've thought. It doesn't mean much because the filter needs to resolve the fd first, which will EBADF early.

Sentence per line

Sentence per line

Fix manpage.
Switch test to use non-_np names.

I think that kqueue_fork_copy() should be committed separately (no need for the new review, I am only asking for splitting the commit).

Today snapshot.

As was discussed elsewhere, fuse server which times out the responses could cause lock cascades in VFS. This would have global consequences for the whole system.

Move checks into try_fds_open().
Use strchr.
Drop O_EMPTY_PATH.
Do name++ early.
Grammar fix in the man page.

Man page editing.

In D56152#1284587, @markj wrote:

Why introduce this special syntax instead of adding a new function fdlopenat(<fd>, <rel path>, <flags>)?

To complement the output from dlinfo(), as I noted in the summary. We record the name of the object opened through LD_LIBRARY_PATH_FDS in this format. I wanted to make it possible to use the info output directly without user code needing to understand the special case.

Take Dimitry suggestion.

In D56139#1284163, @markmi_dsl-only.net wrote:

The status of fegetexcept, feenableexcept, and fedisableexcept and their relationship to __BSD_VISIBLE seems to be rather variable. Some of that variability may be incorrect and other parts expected. I just note the variability itself. A quick look seemed to show:

aarch64/fenv.c does not provide any external/exportable definitions for those.
aarch64/fenv.h has just __BSD_VISIBLE conditional __fenv_static based definitions, nothing for external/exportable support.

arm/fenv.c has definitions not conditional on __BSD_VISIBLE. fegetexcept is exported, unlike for the others. There is no use of weak references.
arm/fenv.h has __BSD_VISIBLE conditional external/exportable-supported based code, including for fegetexcept.
arm/fenv.h has fegetexcept for __ARM_PCS_VFP both inside and outside __BSD_VISIBLE.

powerpc/fenv.h has feenableexcept and fedisableexcept set up for exportable and conditional on __BSD_VISIBLE but fegetexcept is just for the __fenv_static definition.
powerpc/fenv.c has unconditional feenableexcept and fedisableexcept and no fegetexcept. Thre is no use of weak references.

riscv is like powerpc.

x86/fenv.h has the __BSD_VISIBLE conditionality but does not have static implementations of feenableexcept and fedisableexcept.
i387/fenv.c has unconditional feenableexcept and fedisableexcept with weak reference indicated and does not have fegetexcept.
amd64/fenv.c does that as well.

This should be not a note, but a proper explanation. Besides talking about that, it might be useful to explain how to get the stable results.

Add documentation and test.

Also it probably worth explaining what 'active' means.

The result of the call is invalid the moment the function returns. If this one-line manual page ever makes sense, it must describe how to use the result safely.

Initialize cnt

In D21206#1284013, @kevans wrote:

In D21206#1283986, @kib wrote:

Was it tested with compat32?

Looking at it anew, I do not like that the kernel private implementation type NDSLOTTYPE leaks to userspace, even if internally to libc.

Fair enough, how about I add a fixed width type bitmap and kind of abstract it away a level to knock out both points?

Was it tested with compat32?