will the following sequence cause read-after-write inconsistency?

[sundengyu]

Precondition

Object o1 has just been created, its maxblkid is 0, the max block size of o1 is 128k.
thread1 wants to write 32k data at offset 128k and read that data using dmu_read_by_dnode after write, thread2 wants to write 32k data at offset 192k. thread1 and thread2 want to dirty the same dbuf in the same time

Operation Steps

1. thread2 add a dirty record to that dbuf
2. thread1 sees that record so it will only call dbuf_redirty which won't update maxblkid of object o1
3. thread1 calls dmu_read_by_dnode but it finds that maxblkid of o1 is 0 so it can only get zeroed data
4. thread2 updates maxblkid to 1

[amotin]

Case of block size change should be covered by range lock. In particular, for the first thread writing beyond the first block zfs_rangelock_cb() should manage locking of the whole file until the block size is changed and then reduce lock scope to the second block. The second thread should wait for it. Do you have some reproduction for the issue, or this is only a theoretical question?

[sundengyu]

In my use case, zfs works as a object store. I also implement sync write based on dmu_write like zfs_write, but in the upper case dmu_read_by_dnode inside zfs_log_write gets zeroed data.
Although zfs_rangelock_cb will lock the whole file, thread2 will reduce range after it sets new blocksize. the race condition happens when thread1 and thread2 call dmu_write_uio_dbuf, if thread2 add a dirty record first, thread1's dmu_write_uio_dbuf may return with maxblkid == 0, so the following dmu_read_by_dnode can get zeroed data
If the file only has the first block, thread1's write and thread2's write won't block each other, this problem may still happens