aboutsummaryrefslogtreecommitdiffstats
path: root/rust/helpers.c
diff options
context:
space:
mode:
authorChristoph Hellwig <[email protected]>2024-07-02 15:10:21 +0000
committerJens Axboe <[email protected]>2024-07-03 16:21:16 +0000
commitbf4c89fc8797f5c0964a0c3d561fbe7e8483b62f (patch)
tree2b729defed51056385346fe4f3889288a7c4e3e0 /rust/helpers.c
parentblock: also return bio_integrity_payload * from stubs (diff)
downloadkernel-bf4c89fc8797f5c0964a0c3d561fbe7e8483b62f.tar.gz
kernel-bf4c89fc8797f5c0964a0c3d561fbe7e8483b62f.zip
block: don't call bio_uninit from bio_endio
Commit b222dd2fdd53 ("block: call bio_uninit in bio_endio") added a call to bio_uninit in bio_endio to work around callers that use bio_init but fail to call bio_uninit after they are done to release the resources. While this is an abuse of the bio_init API we still have quite a few of those left. But this early uninit causes a problem for integrity data, as at least some users need the bio_integrity_payload. Right now the only one is the NVMe passthrough which archives this by adding a special case to skip the freeing if the BIP_INTEGRITY_USER flag is set. Sort this out by only putting bi_blkg in bio_endio as that is the cause of the actual leaks - the few users of the crypto context and integrity data all properly call bio_uninit, usually through bio_put for dynamically allocated bios. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
Diffstat (limited to 'rust/helpers.c')
0 files changed, 0 insertions, 0 deletions