Hi all, Here's a series of patches to fix some problems I noticed in 4.18. The first patch fixes a problem where we WARN_ON if someone tries to create an empty transaction while the fs is frozen. Since these transactions can't modify anything, it seems unnecessary to warn about them. The second patch fixes per-ag rmapbt reservation accounting problems. The on-disk fdblocks counter is not decremented for rmapbt blocks, so the incore reservation should always decrement the incore fdblocks by the entire reservation regardless of rmapbt use. This fixes the problem where b_avail as reported by statfs changes across an unmount/mount cycle if the rmapbt had grown prior to the unmount, even though the number of blocks in use has not changed at all. The third patch fixes the userspace-configurable default reserved blocks calculation when there are fewer fdblocks than what we set aside to avoid deadlocks. The fourth patch fixes a problem Zorro Lang found where on a 512b block filesystem we can cause an extent at s_maxbytes to be right shifted to the point that it block offset exceeds the field size of 54 bytes. generic/485 is the regression test. The fifth patch fixes a hard to trigger TOCTOU bug in generic/166 where we take ILOCK_SHARED in preparation for a directio write but by the time we get the lock a second thread has set the reflink flag on the file and shared the extent we're trying to write but we proceed into the COW allocation paths without the required ILOCK_EXCL. The sixth patch fixes an uninitialized field in the rtbitmap fsmap code. The seventh pach fixes an off-by-one error in the rtbitmap range query function (which fortunately only affects the rtbitmap fsmap results). The eighth patch fixes a bug reported by fsx in generic/127 wherein if we write a file to a non-page-aligned length, mmap read the EOF page, truncate the file to a smaller non-page-aligned length, run zero_range out to EOF, and then mmap read the EOF page a second time, we briefly see non-zero bytes after EOF. Comments and questions are, as always, welcome. --D -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
