diff options
author | Darrick J. Wong <darrick.wong@oracle.com> | 2017-01-26 09:50:30 -0800 |
---|---|---|
committer | Darrick J. Wong <darrick.wong@oracle.com> | 2017-01-26 09:50:30 -0800 |
commit | c364b6d0b6cda1cd5d9ab689489adda3e82529aa (patch) | |
tree | 8e9682fcde7119274d457f7dd2238dde049c2834 /include/scsi/osd_initiator.h | |
parent | 2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b (diff) |
xfs: fix bmv_count confusion w/ shared extents
In a bmapx call, bmv_count is the total size of the array, including the
zeroth element that userspace uses to supply the search key. The output
array starts at offset 1 so that we can set up the user for the next
invocation. Since we now can split an extent into multiple bmap records
due to shared/unshared status, we have to be careful that we don't
overflow the output array.
In the original patch f86f403794b ("xfs: teach get_bmapx about shared
extents and the CoW fork") I used cur_ext (the output index) to check
for overflows, albeit with an off-by-one error. Since nexleft no longer
describes the number of unfilled slots in the output, we can rip all
that out and use cur_ext for the overflow check directly.
Failure to do this causes heap corruption in bmapx callers such as
xfs_io and xfs_scrub. xfs/328 can reproduce this problem.
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Diffstat (limited to 'include/scsi/osd_initiator.h')
0 files changed, 0 insertions, 0 deletions