New code for 5.15:
 - Fix a potential log livelock on busy filesystems when there's so much
   work going on that we can't finish a quotaoff before filling up the log
   by removing the ability to disable quota accounting.
 - Introduce the ability to use per-CPU data structures in XFS so that
   we can do a better job of maintaining CPU locality for certain
   operations.
 - Defer inode inactivation work to per-CPU lists, which will help us
   batch that processing.  Deletions of large sparse files will *appear*
   to run faster, but all that means is that we've moved the work to the
   backend.
 - Drop the EXPERIMENTAL warnings from the y2038+ support and the inode
   btree counters, since it's been nearly a year and no complaints have
   come in.
 - Remove more of our bespoke kmem* variants in favor of using the
   standard Linux calls.
 - Prepare for the addition of log incompat features in upcoming cycles
   by actually adding code to support this.
 - Small cleanups of the xattr code in preparation for landing support
   for full logging of extended attribute updates in a future cycle.
 - Replace the various log shutdown state and flag code all over xfs
   with a single atomic bit flag.
 - Fix a serious log recovery bug where log item replay can be skipped
   based on the start lsn of a transaction even though the transaction
   commit lsn is the key data point for that by enforcing start lsns to
   appear in the log in the same order as commit lsns.
 - Enable pipelining in the code that pushes log items to disk.
 - Drop ->writepage.
 - Fix some bugs in GETFSMAP where the last fsmap record reported for a
   device could extend beyond the end of the device, and a separate bug
   where query keys for one device could be applied to another.
 - Don't let GETFSMAP query functions edit their input parameters.
xfs: make fsmap backend function key parameters const

There are several GETFSMAP backend functions for XFS to cover the three
devices and various feature support.  Each of these functions are passed
pointers to the low and high keys for the dataset that userspace
requested, and a pointer to scratchpad variables that are used to
control the iteration and fill out records.  The scratchpad data can be
changed arbitrarily, but the keys are supposed to remain unchanged (and
under the control of the outermost loop in xfs_getfsmap).

Unfortunately, the data and rt backends modify the keys that are passed
in from the main control loop, which causes subsequent calls to return
incorrect query results.  Specifically, each of those two functions set
the block number in the high key to the size of their respective device.
Since fsmap results are sorted in device number order, if the lower
numbered device is smaller than the higher numbered device, the first
function will set the high key to the small size, and the key remains
unchanged as it is passed into the function for the higher numbered
device.  The second function will then fail to return all of the results
for the dataset that userspace is asking for because the keyspace is
incorrectly constrained.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
1 file changed