Unfortunately, no readable diff between specifications as far as I know. (I don't know of any great VFAT specification off-hand.) exFAT is relatively well defined at https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification .

Lgtm.

Code change seems good. The doc change is possibly incomplete (still potentially confusing) but I don't consider that blocking.

Sure. Warner or Xin Li (CC'd, involved in earlier part of this design IIRC) might prefer something else, so you could also wait to see if they have an opinion.

I'm not super keen on this design. It makes the file type of /etc/motd more confusing, turns _PATH_MOTDFILE into a symlink for the default case, and I'm unclear why you're modifying the motd rc script at all if your proposal involves update_motd="NO".

The idea seems good to me. It seems like the implementation may also be tripped by concurrent panic, not just recursive panic. I've usually (only?) seen concurrent panics in the context of unhandled MCA/MCE exceptions, and maybe that was an oddity of that particular FreeBSD derivative. I don't think that's a significant (or new) problem with this change.

Should have been automatically closed by rS367777, but wasn't for some reason.

(Just FYI, Bryan. If there's interested in upstreaming this stuff to the FreeBSD nvdimm layer and eventually rebasing Isilon's nvdimm journal on nvdimm(4), this might be a place to start.)

In D27236#608678, @imp wrote:

In D27236#608561, @hselasky wrote:

If you ktrace a regular application starting up you already see a lot of system calls, so I think adding one more is fine.

Except there's many efforts to reduce this. At present, this function is called by a tiny number of binaries, so I'd rather have any overhead be limited to those programs that use it.

Some notes I sent Adam earlier, might be useful for someone in the future:

The user.localbase sysctl seems like a poor design, and doesn't exist at the moment. That needs to be resolved before this change is committed.

In D26792#607459, @kib wrote:

Does anybody looked at the resulting asm to confirm that memory access is indeed generated ?

Lsof appears to use libkvm on modern FreeBSD, but not libproc. So it needs the equivalent change to procstat_getfiles_kvm() and I think that's it.

Hm, that kind of check is usually EINVAL.

I agree that something else may make more sense. I'd suggest EPERM (as opposed to EACCES, which explicitly mentions file access permissions) or EINVAL (generic bogus argument) as possibilities. I don't oppose EACCES either. I think EDOOFUS is pretty much always wrong.

• Version sockcred2 structure

• uma -> malloc
• drop shared lock macros

This tinderboxes and both modules load without issue on amd64. I was able to run a 64-bit binary fine.

Move MI dummy stubs and SDT definition into linux_common.

Thanks!

In D27099#604907, @trasz wrote:

I like it. Some of the per-architecture DUMMY() should probably get moved to the MI file too - statx for example - but that's better done later on.

In D27084#604733, @kib wrote:

In D27084#604727, @cem wrote:

In D27084#604715, @kib wrote:>

If you add new fields after sc_groups[], there is no need in SCM_CREDS2.

I don't think that's true. How does a consumer reliably distinguish between cmsgcred, original sockcred, and new sockcred with extra fields?

Consumer does not need to. If LOCAL_CREDS_PERSISTENT was set, it is always new sockcred. The option is per-socket so it should be fine for older library to get older sockcred on other sockets.

In D27084#604715, @kib wrote:

In D27084#604710, @cem wrote:

In D27084#604700, @kib wrote:

Hm, if we do this for existing SCM_CREDS, one difficulty is that statically sized buffers (e.g., SOCKCREDSIZE(CMGROUP_MAX)) in existing binaries would potentially no longer be big enough. Correct code would not overrun a buffer, but could fail to receive SCM_CREDS messages that used to work.

CMGROUP_MAX is silly, and probably makes sc_groups not too useful. That said, it is probably fine to fail to add the message if there is no space. App setting the 'new creds' flag should be aware.

In D27084#604700, @kib wrote:

You can add fields after sc_groups[], without introducing sockcred2. The receiver would need to check something to understand that kernel supplies that addon, e.g. p_osrel is the obvious candidate.

In D27084#604683, @markj wrote:

I think changing the value of SCM_CREDS is probably good enough though. This might be a question for the mailing lists; the proposed patch makes an already-confusing API even more complicated.

In D27084#604675, @markj wrote:

Fix misnamed LOCAL_CREDS in socket.h comment

• Fix sbuf drain length math when a partial seek occurred
• Early terminate pseudofs auto-drain fill routines when caller's uio is fully consumed

• Convert pwddesc lock to mutex (required shuffling chroot_refuse_vdir_fds() lock order)

• Mechanically rename pathsdesc to pwddesc. No functional change.

• Fix PCB lock leak
• Fix 'error' assignment operator

• Unify return style of GET/SET cases in switch

Rebase on parent revision changes.

• Rename WANTCRED => WANTCRED_ONESHOT
• Rename LOCAL_PASSCRED to LOCAL_CREDS_PERSISTENT
• Make LOCAL_CREDS{,_PERSISTENT} mutually exlusive (EINVAL from setsockopt) and document in manual page.

• Fix buflen+1 logic. As a side effect, the maximal limit for pfs fill routines is one byte smaller (of 1MB).
• Drop compound literal for struct initialization.

• Fix PID passed to kern_procctl. Previously, the syscall would manipulate the tracability of the kernel 0 process, which is probably meaningless and certainly not intended.