Looking at the ntfs code, BMAP is failing because fusefs is calling the fuse BMAP operation with blocksize == maxiosize, and that'll generally be much larger than the NTFS cluster size. I'm not sure why fusefs passes that instead of the block size (or why the BMAP operation would take the blocksize as a parameter to begin with, is the block size not fixed by the client filesystem?), but it makes sense that the filesystem driver would return an error in that case.

This looks ok to me, but it depends on the other revision, which is as-yet unfinished.

Closing this since a similar change landed in commit e63bf6aa523eb9a865b7ce34d01e75a13818b367

I'll close this revision now that the underlying problem has apparently been fixed.

This isn't the right place to submit changes to llvm. This copy of llvm is imported from https://github.com/llvm/llvm-project and changes should be proposed there.

It's fine. The string here doesn't matter, I usually just use "none".

Nice cleanup.

In D53135#1213843, @emaste wrote:

This is fine too. We do have some existing cases using sizeof, e.g.

sys/dev/drm2/drm_atomic.h:#define       NB_BITS_PER_LONG                (sizeof(long) * NBBY)
sys/dev/axgbe/xgbe_osdep.h:#define      BITS_PER_LONG                   (sizeof(long) * CHAR_BIT)

Typo.

Handle review feedback.

It'd make more sense to change the man pages instead. The string in question doesn't matter for synthetic filesystems like these, so we might as well be consistent and use the "fs" suffix everywhere.

In D52968#1213618, @corvink wrote:

In D52968#1213405, @markj wrote:

In D52968#1212719, @corvink wrote:

It doesn't look like it fully freezes. However, it gets extremely slow. The circle of the Windows boot loader spins very slowly. Don't know if it will ever reach the desktop.

What output do you see if you run procstat -kk <bhyve PID> while this is happening?

Almost always one vCPU hangs in vm_handle_rendezvous. The output is from a single VM run. I've called procstat a few times within a few seconds:

Fix a silly mistake

Try to validate strtol()'s return value.

Use SIZEOF_LONG instead. Fix up BITS_PER_LONG_LONG too.

In D27220#1213582, @kib wrote:

In D27220#1213316, @markj wrote:

In D27220#1213306, @kib wrote:

In D27220#1213262, @markj wrote:

Looks ok to me. Perhaps this should be a private library instead?

IMO it is generally useful API. Also, I do provide symbol versioning, which does not make sense for a private library: the intent is to keep stable interfaces.

Well, now the kernel's internal interface must be kept stable as well. I don't object, but I'm worried it'll be easy for someone modifying vmem to forget about this.

Yes, I noted the same when parts of msdosfs were used in makefs (AFAIR). But there it is much simpler interface, and if the interface for kernel or userspace starts drifting, the code can be easily forked to the residual part.

Note, there are quite a few other definitions of BITS_PER_LONG that have similar problems, but they're mostly in obsolete or unmaintained drivers. I'm not sure whether to sweep through and fix them too.

In D37981#1210335, @avg wrote:

Totally belated, but would it make (have made) sense to split default behavior of reboot and reset commands?
I think that it would be more natural if reboot tried to do a reboot and reset just went for a reset (where implemented)?

Fix a lock order reversal.

In D52968#1212719, @corvink wrote:

It doesn't look like it fully freezes. However, it gets extremely slow. The circle of the Windows boot loader spins very slowly. Don't know if it will ever reach the desktop.

In D27220#1213306, @kib wrote:

In D27220#1213262, @markj wrote:

Looks ok to me. Perhaps this should be a private library instead?

IMO it is generally useful API. Also, I do provide symbol versioning, which does not make sense for a private library: the intent is to keep stable interfaces.

The code changes seem ok to me. This should really have some regression tests. Even some simple ones which exercise the f_copy routine for various filters, and verify that knotes for O_CLOFORK fds are handled properly, would be much better than nothing.

Looks ok to me. Perhaps this should be a private library instead?

In D53066#1213092, @vmaffione wrote:

Disclaimer: I am not familiar with the memory management subsystem.
From my understanding, vm_object_reference(obj) is called to account for the reference that we add by calling vm_map_find on the kernel map, since the comment on the latter function explicitly requires the caller to increment the object reference counter.
But I could not find evidence that vm_map_remove will actually remove the reference above.. is that the case? I tried to look in the code, but I could not find the spot nor comments or documentation about that. Also, I would think that vm_map_remove (which undoes what vmap_map_find does, I guess) does not drop the object reference since its counterpart also does not do it.

• Fix an unrelated typo
• Perform a single check

Do we not block at all when sending on a dgram socket and the receiver has insufficient space?

In D53068#1212662, @ae wrote:

Yes, I think they were replaced with handlers from ipfw_sopt_handler.

In D53062#1212373, @emaste wrote:

Do they get placed in rodata with the change?

Also I think the commit message ought to reference any changes in ELF sections containing these.