summaryrefslogtreecommitdiff
path: root/include/scsi/osd_initiator.h
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2017-01-26 09:50:30 -0800
committerDarrick J. Wong <darrick.wong@oracle.com>2017-01-26 09:50:30 -0800
commitc364b6d0b6cda1cd5d9ab689489adda3e82529aa (patch)
tree8e9682fcde7119274d457f7dd2238dde049c2834 /include/scsi/osd_initiator.h
parent2aa6ba7b5ad3189cc27f14540aa2f57f0ed8df4b (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