On Fri, 2013-12-13 at 15:58 -0800, Andy Grover wrote:
> Use the kernel's std kref for refcounting.
>
> Signed-off-by: Andy Grover <agrover@xxxxxxxxxx>
> ---
> drivers/target/target_core_device.c | 12 ++----------
> drivers/target/target_core_internal.h | 10 ++++++++++
> drivers/target/target_core_pr.c | 12 ++++--------
> include/target/target_core_base.h | 2 +-
> 4 files changed, 17 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c
> index 3350467..1954b0f 100644
> --- a/drivers/target/target_core_device.c
> +++ b/drivers/target/target_core_device.c
> @@ -472,6 +472,7 @@ static struct se_port *core_alloc_port(struct se_device *dev)
> atomic_set(&port->sep_tg_pt_secondary_offline, 0);
> spin_lock_init(&port->sep_alua_lock);
> mutex_init(&port->sep_tg_pt_md_mutex);
> + kref_init(&port->refcount);
>
> spin_lock(&dev->se_port_lock);
> if (dev->dev_port_count == 0x0000ffff) {
> @@ -555,20 +556,11 @@ static void core_export_port(
> static void core_release_port(struct se_device *dev, struct se_port *port)
> __releases(&dev->se_port_lock) __acquires(&dev->se_port_lock)
> {
> - /*
> - * Wait for any port reference for PR ALL_TG_PT=1 operation
> - * to complete in __core_scsi3_alloc_registration()
> - */
> - spin_unlock(&dev->se_port_lock);
> - if (atomic_read(&port->sep_tg_pt_ref_cnt))
> - cpu_relax();
> - spin_lock(&dev->se_port_lock);
> -
> core_alua_free_tg_pt_gp_mem(port);
>
> list_del(&port->sep_node);
> dev->dev_port_count--;
> - kfree(port);
> + put_port(port);
> }
>
Same problem yet again. It's not safe to release the se_port from it's
tg_pt_gp_mem association, while there are active references from other
process contexts.
Also the same issue with the configfs child / parent reference here,
where returning (instead of waiting for references to drop) introduces a
whole new host of reference counting issues.
NAK.
--nab
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
