Teach procstat(1), fstat(1), and fuser(1) about altroot.

Drop altroot for setid native binaries.
Man page fixes and clarifications.

In D60035#1379038, @markj wrote:

Neat feature, what is the motivation?

Just a question, did you tested d_purge with the WITNESS kernel?

Move the man page to libsys/x86

Apply jhb editings

Thank you very much for reading it so far.
Obviously I cannot get (the) articles right, I gave up on this many tens of years ago.

So I got the answer people that actually implement PCIe config space (for some unnamed high-profile PCIe device). The implementation of it is in fw for all practical purposes. The pending TLP bit is always zero.

Stop busying already busy page, returned by the grab, avoiding deadlock.

Bug fixes for disabling altroot mode:

• make chroot -A not bail with an error
• avoid NULL deref in MAC hook

Teach chroot(8) about altroot.

In D60022#1377546, @christos wrote:

In D60022#1377269, @kib wrote:

We have d_purge cdevsw method. It is invoked by destroy_dev(9) when it observes threads inside cdevsw methods, to release the sleep. Would it be useful for your purpose there?

I see only one use of d_purge in the tree. What I want is to wake up the server cv that's sleeping in CUSE_IOCTL_GET_COMMAND and set is_closing. I guess d_purge should be good, or is there something that might bite us?

Add fchaltroot(2)
Add mac callback
Documentation

Drop fhstat(2) chunk.

Plug newpwd leak.

In D60035#1377863, @dteske wrote:

In D60035#1377674, @kib wrote:

Extract chroot_unpriv() from kern_chroot.
Use the same privilege checks for chaltroot(2) as for chroot(2).

Privilege check matches. Thanks for adding that.

Issue: pwd_altroot no-op leaks newpwd. Alloc is unconditional; when altroot_vp == oldpwd->pwd_adir the else nullifies oldpwd and the unused newpwd is never dropped.

Fixed, thanks.

Fix typos and systematically markup instructions with .Dv.

Suggested editing.

Extract chroot_unpriv() from kern_chroot.
Use the same privilege checks for chaltroot(2) as for chroot(2).

In D60035#1377627, @dteske wrote:

Yes, expose it. D59990 can configure the overlay from a native process, dropping the linux_base skip.

In D58851#1377389, @rmacklem wrote:

In D58851#1377388, @kib wrote:

"pgrbwt" means that the function waits for the page busy state to pass. Often the reason for this state waiting forever is that the thread that waits already owns the busy state on the page.

Does the hang occur in the buffer strategy method?

Yes. Btw, I think the main use for this helper is in the server
where the vnode won't be an NFS one, so if this isn't easily
avoided, I wouldn't worry about it. (In other words, use the
helper in the NFS server, but not the NFS client.)

"pgrbwt" means that the function waits for the page busy state to pass. Often the reason for this state waiting forever is that the thread that waits already owns the busy state on the page.

This is a proposal for now, I want to discuss do we want this feature exposed to the native processes at all.
I thought about putting it under e.g. procctl(2), but it seems to not be a natural place.

There is no bug that you claim. Behavior for normal lookup and and for operations directly on the inode number (AKA fh) have to differ because of their nature, where one operates over the global file namespace, and another acts on the inode identifiers within single filesystem.

Always allocate new environment instead of checking it for NULL.

We have d_purge cdevsw method. It is invoked by destroy_dev(9) when it observes threads inside cdevsw methods, to release the sleep. Would it be useful for your purpose there?

I suggest to do always define wrmsr_imm in the cpufunc.h header, but reduce it to wrmsr() if the compiler is too old. Then the calling sites do not need to care about compiler. It would generate pointless ifunc resolvers, but I do not think we should care.

I did not read the details of the tests, but I do not see a reason not to commit them now.

In D59910#1376521, @olce wrote:

In D59910#1376490, @kib wrote:

What do you mean by inconsistency? Do you want _MNTPOINT when fhstat("/")?

EDIT: No, that would be one more special case, and at the moment I don't see why we would want to treat / differently than any other path. Worse, doing so would introduce a discrepancy with stat("/") in jails with respect to the host for jails rooted in a filesystem's root that is not the host's /.

The inconsistency is this:

1. Mount something on, let's say, /mnt (and possibly mount more filesystems on top of it, that doesn't change what's next).
2. Do stat("/mnt"), this returns SFBSD_MNTPOINT.
3. Do fhget("/mnt") and then fhstat() on the result, and SFBSD_MNTPOINT is not returned.

This is a problem because we naturally expect that 2 and 3 would give the same result,

Report SFBSD_MNTPOINT for root on fhstat()

What do you mean by inconsistency? Do you want _MNTPOINT when stat("/")?

I would not encode the bit position in the name, for instance how it was done for OBJ_PAGEPRIV1/2.

s/MNTROOT/MNTPOINT/g

In D59932#1376355, @markj wrote:

Does bufbdflush() need to be updated? I am not sure if it is ever called with a devvp.

Reword

In D59910#1376115, @olce wrote:

In D59910#1376112, @kib wrote:

In D59910#1376084, @olce wrote

The check on VIRF_MOUNTPOINT is indeed necessary if the handle points to an underlying vnode, but the check on VV_ROOT should be performed also, if for anything for consistency with fstatat().

No, VV_ROOT vnode is not a mountpoint when it is instantiated by ino number, instead of lookup. It is below mountpoint.

That's certainly true strictly speaking, but was not my point.

I think this can cause confusion to users obtaining first a handle and then calling fhstat() versus calling stat() because they would be inconsistent if both are performed after the mount operation has taken place.

It may well be better to change the semantics to: Reports a mount point or a filesystem root, which would avoid the inconsistency (and corresponds to checking VV_ROOT also).

Clarification for fhstat(2).

In D59910#1376084, @olce wrote

The check on VIRF_MOUNTPOINT is indeed necessary if the handle points to an underlying vnode, but the check on VV_ROOT should be performed also, if for anything for consistency with fstatat().

Handle fhstat(2)

In D59910#1375689, @markj wrote:

Should kern_fhstat() be updated too?

Drop nullfs specialization.

In D59910#1375640, @markj wrote:

In D59910#1375621, @kib wrote:

If you really want to, use stat("/").

This might not work in a chroot or jail.

In D59910#1375613, @sobomax wrote:

P.S. Perhaps bump __FreeBSD_version? Since there is no other way to probe if the kernel supports this feature or not.

In D59356#1375502, @sobomax wrote:

@pho I tried to coerce ChatGPT Codex to write a reproducer, but it keep refusing claiming that's a security concern. I will try maybe to rephrase it as writing a "unit test to validate the fix."