Since the "serial" taken from the configuration is directly copied to become the virtio-blk device's ident, should we call this "ident" simply? Looks good to me otherwise.

Thanks mav@ for pointing this mistake out.

• MD_AUTOUNMAP -> MD_MUSTDEALLOC
• Clarifications on behavior regarding with/without the flag
• Sort the options over the code and manpage

markj@'s suggestion

In D31829#718297, @rmacklem wrote:

Well, if you think there might be future uses of different
timeouts, the high order 8bits could be defined as the
timeout value (when non-zero) in 1/10seconds.
--> That would use up 8 of the 32bits, but since Linux

has not defined any flags yet, I think that's ok.

Even 1/10sec resolution isn't always going to be achieved.
I mentioned the case where the vn_rdwr() calls takes more than
one second.

• Comments
• ternary instead.

vn_deallocate_impl takes three kinds of cred so it's the caller to decide which cred to pass to the VOP call. Suggested by kib@.

In D31712#716746, @kib wrote:

Don't do this either.

Right now I see the only place which uses vn_deallocate(), it is md(4). Do you envision any more places which would do that?

My change to ctl(4) which translate UNMAP to VOP_DEALLOCATE for file-backed LUNS also calls vn_deallocate().

The upper 16bit of ioflag is used to pass internal flag to vn_deallocate_impl.

Thanks for your contribution!

• Use vn_deallocate_args to pass around most of the args to vn_deallocate_impl.
• Comment vn_deallocate(9)'s active_cred/file_cred preference.

Oops.

Make such change specific to vn_deallocate instead.

Just checked the behavior of .fo_read/.fo_write.

Do not call maybe_yield if there is any error

• Styles
• KASSERT message changes
• KASSERT node type be VREG in tmpfs_reg_punch_hole
• Remove the MPASS(VOP_ISLOCKED(vp)) from tmpfs_deallocate. This is guarded by ASSERT_VOP_LOCKED already.

Cleanups suggested by kib@

One thing to note, it might be good to periodically do maybe_yield when looping the call so that it won't early return when should_yield() in the default implementation is hit.

The VOP_DEALLOCATE bits look good to me.

This should play better with the nfs_deallocate implementation in NFS4.2 client module.

In D31640#714099, @rmacklem wrote:

I could make r_offset >= maxfilesize a no-op.
The problem is that the client will only have a (possibly stale)
va.va_size for the file to use to set the reply r_offset.
--> To be honest, it is always a bit bogus, since another

client can change the file size at any time.

If just guessing at what va_size is to set r_offset to is fine with
you guys, I can do that.