This is small enough that shouldn't affect upstream merging (also the code is very FreeBSD-specific).
It also respects the general objective of the code.

In D13964#293442, @fsu wrote:

In D13964#293380, @pfg wrote:

In D13964#293266, @fsu wrote:

In D13964#293256, @pfg wrote:

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.

There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.

I haven't looked at ext4 for a while but most of those features seem to require some obscure collaboration from the kernel, that is out of the scope of the driver. There's also the issue that most of the interesting enhancements in linux assume there is journalling.

I am not sure, that journal feature is required for non-native file system, also it will be difficult to test it.

In D13964#293266, @fsu wrote:

In D13964#293256, @pfg wrote:

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.

There are another features like RO_COMPAT_QUOTA, INCOMPAT_INLINE_DATA, etc, but from my current point of view, it is not so, important, if it will be required to implement it. I think it a not a problem.
The only feature, which will be difficult to implement is RO_COMPAT_BIGALLOC, but I hope it will be not widely used by linux.

A sidenote: I just noticed META_BG is supported on ext3 too.

Hmm.. it seems like we are getting to a rather complete ext4 implementation, which is positive. On the downside the code is diverging from UFS. We just can't have both I guess.
In any case , let me mention that EXT4F_RO_INCOMPAT_SUPP was created as a dirty hack: to workaround for features that we were not planning to support at all but that we needed to fake in order to read the partition.
We should remove EXT4F_RO_INCOMPAT_SUPP as it has fulfilled its purpose.

For the record: the changes were committed by parts in a series of commits from r328016 to r328026.

I committed sys/dev in rr327949 so drop those from the Revision.

This should be a minimal and more straightforward replacement.

Drop the arc4random change for now as to unblock this change.

In D13837#290289, @cem wrote:

In D13837#290288, @pfg wrote:

It is now the case that it panics right

Right.

(OpenBSD panics also, I think)?

No idea.

Can we have it return NULL for M_NOWAIT and panic for M_WAITOK?

No, I don't think that makes any sense.

When I started this changes, mallocarray(9) would return NULL on overflow, and for the M_WAITOK case the code was not prepared to handle that, so I avoided M_WAITOK changes for this revision (I was not going to do it at all).

In D13837#290278, @cem wrote:

Was this mechanical (with e.g. coccinelle)?

Nope ... I checked it on opengrok and then by hand.

In D13835#290226, @dumbbell wrote:

Hi!

What is the benefit of using mallocarray() here?

In D13810#289917, @fsu wrote:

In D13810#289909, @pfg wrote:

In D13810#289828, @fsu wrote:

In D13810#289543, @pfg wrote:

A thought : would it be possible to checksum only what we are going to write to disk?
Data will not, generally, corrupt in memory and the kernel has no use for the checksums at runtime so we only need to write stuff when it's going to be converted to the on-disk format in ext2_inode_cnv.c.

All fields, which are mentioned in SUMMERY, should be written to disk. If it will not be updated, we will have errors reported by e2fsck, or bunch of error messages from driver on linux side.

I am not complaining at all about what is being checksummed: I understand you want to checksum everything that is needed. The main doubt is when to checksum.

There are two possibilities: you either checksum everything as soon as you get it or you checksum at the last moment before writing to disk. Both options have their advantages It seems like the checksumming is happening all over the filesystem so you are doing the former, I was only wondering if we could do all the checksums in a single place, right when we are converting to the ext2fs format for writing.

I am not sure if such thing is poosible though, and your change is not incorrect so I'll let you think about it but I'll approve the patch.

I use second approach, checksum every field before bwrite() call.

OK, I see ...

In D13810#289828, @fsu wrote:

In D13810#289543, @pfg wrote:

A thought : would it be possible to checksum only what we are going to write to disk?
Data will not, generally, corrupt in memory and the kernel has no use for the checksums at runtime so we only need to write stuff when it's going to be converted to the on-disk format in ext2_inode_cnv.c.

All fields, which are mentioned in SUMMERY, should be written to disk. If it will not be updated, we will have errors reported by e2fsck, or bunch of error messages from driver on linux side.

A thought : would it be possible to checksum only what we are going to write to disk?
Data will not, generally, corrupt in memory and the kernel has no use for the checksums at runtime so we only need to write stuff when it's going to be converted to the on-disk format in ext2_inode_cnv.c.

OK, thanks.

For the record: I never liked adding reallocarray to stdlib.h because it is a nonstandard funtion. In the case of the kernel, of course, I think it is not an issue.