| 1350922d | 28-Jul-2020 |
Tomasz Zawadzki <tomasz.zawadzki@intel.com> |
bdev/ocf: take additional reference for ocf_cache
Fixes #1498
When shutting down the application, it was possible to reference stale ocf_cache pointer. This was the case when two or more vbdev_ocf
bdev/ocf: take additional reference for ocf_cache
Fixes #1498
When shutting down the application, it was possible to reference stale ocf_cache pointer. This was the case when two or more vbdev_ocf devices were based on top of single cache bdev.
This issue did not occur outside of the shutdown case, since RPC only allows deletion of the vbdev_ocf. This erases on disk metadata and next run of the application, would not detect such vbdev_ocf.
Shutdown meanwhile works different, by first stopping the instance of running "ocf_mngt_cache" and later detaching "core" devices (the ones being cached). This prevented erasing the on disk metadata and allowed for restarted application to detect vbdev_ocf. See patch (1292ef2) for details.
Since references to ocf_cache are copied between vbdev_ocf [see start_cache()], the reference count inside ocf_cache was limited to original ocf_mngt_cache_start() and management queue creation. First call into ocf_mngt_cache_stop() released all references to ocf_cache. Leaving other vbdev_ocfs pointing to released memory.
This patch works around this issue by increasing ref cnt on ocf_cache for each vbdev based on top of it. It allows to call into ocf_mngt_cache_stop(), but not release the memory for ocf_cache until last vbdev.
Note: A proper redesign here is in order: - either rearranging structures to be based around single ocf_cache, rather than multiple vbdev_ocf instances - better use of OCF API to reduce book keeping logic in vbdev
There are plans to implement detach/attach in RPC, so it should be a focus during that effort.
Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Change-Id: I560a7fbb1c052bf53970e655bdb60803c561a252 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/3574 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Vitaliy Mysak <vitaliy.mysak@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
show more ...
|