Re: [PATCH] scsi: iscsi: Fix IDR memory leak in transport exit

[Rodolfo Giometti <giometti@enneenne.com>]

On 04/07/25 14:49, Anders Roxell wrote:
> Add missing idr_destroy() call in iscsi_transport_exit() to properly free
> the iscsi_ep_idr radix tree nodes. Without this, module load/unload cycles
> leak 576-byte radix tree node allocations, detectable by kmemleak as:
> 
> unreferenced object (size 576):
>    backtrace:
>      [<ffffffff81234567>] radix_tree_node_alloc+0xa0/0xf0
>      [<ffffffff81234568>] idr_get_free+0x128/0x280
> 
> The iscsi_ep_idr is initialized via DEFINE_IDR() at line 89 and used
> throughout the iSCSI transport layer for endpoint ID management with
> proper mutex protection via iscsi_ep_idr_mutex. The fix follows the
> documented pattern in lib/idr.c and matches the cleanup approach used
> by other drivers.
> 
> This leak was discovered through comprehensive module testing with cumulative
> kmemleak detection across 10 load/unload iterations per module.

This test has been done on PPS sources too?

> Fixes: 3c6ae371b8a1 ("scsi: iscsi: Release endpoint ID when its freed")

I think that the patch description should be linked to the code it applies to.

Maybe the patch is needed, but if you only modify the PPS code you should also 
provide a description of the problem within the PPS subsystem.

Ciao,

Rodolfo

> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
> ---
>   drivers/pps/pps.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c
> index 6a02245ea35f..25ed0d44b121 100644
> --- a/drivers/pps/pps.c
> +++ b/drivers/pps/pps.c
> @@ -456,6 +456,7 @@ static void __exit pps_exit(void)
>   {
>   	class_destroy(pps_class);
>   	__unregister_chrdev(pps_major, 0, PPS_MAX_SOURCES, "pps");
> +	idr_destroy(&pps_idr);
>   }
>   
>   static int __init pps_init(void)

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming