linux-kernel - Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56DE24A8.2060305@suse.com>
Date:	Mon, 7 Mar 2016 17:02:32 -0800
From:	Lee Duncan <lduncan@...e.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>,
	linux-scsi@...r.kernel.org
Cc:	linux-kernel@...r.kernel.org, open-iscsi@...glegroups.com
Subject: Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id

On 02/12/2016 09:54 AM, James Bottomley wrote:
> On Fri, 2016-02-12 at 09:38 -0800, Lee Duncan wrote:
>> The scsi_transport_iscsi module already uses the ida_simple
>> routines for managing the target ID, if requested to do
>> so. This change replaces an ever-increasing atomic integer
>> that tracks the session ID itself with the ida_simple
>> family of routines. This means that the session ID
>> will be reclaimed and can be reused when the session
>> is freed.
> 
> Is reusing session ID's really a good idea?  For sequential sessions it
> means that the ID of the next session will be re-used, i.e. the same as
> the previous sessions, which could lead to target confusion.  I think
> local uniqueness of session IDs is more important than wrap around
> because sessions are short lived entities and the chances of the same
> session being alive by the time we've wrapped is pretty tiny.
> 
> If you can demostrate a multi-target problem, perhaps we should rather
> fix this by making the next session id a target local quantity?
> 
> James
> 

It looks like Mike and Chris are good with it. And I'd really like to
get rid of yet another atomic int.

Are you satisfied with this one?
-- 
Lee