mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: open-iscsi@googlegroups.com, Lee Duncan <lduncan@suse.com>,
	linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id
Date: Fri, 12 Feb 2016 16:13:41 -0600	[thread overview]
Message-ID: <56BE5915.9070308@cs.wisc.edu> (raw)
In-Reply-To: <1455299691.2396.45.camel@HansenPartnership.com>

On 02/12/2016 11: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?

I think it is if we do it by the iscsi rfc. We have two issues.

1. For iSCSI's iSID we need a 24 bit id. The iSID + initiator name is
the SCSI initiator port ID, so targets want the iSID to be reused for
things like persistent reservation tracking.

There are a couple red hat bugzillas. I am not sure if they are open
though. Here is a KB

https://access.redhat.com/solutions/66861

for more info.

We have been lazy and did not implement this and were just reusing part
of the session->sid.

2. For the kobject/sysfs name we want a unique name/id. Linux boxes stay
up a long time and some users login and logout of sessions a lot. We
roll over and have collisions.

Lee's patch was only meant to fix this. The reuse part was not meant to
fix #1, and so it does not handle every case like you suspect.


To fix everything how about this:

- Use Lee's patch to fix #2. We do not need the iSID to match the sysfs
name. Userspace does not do any type of iSCSI iSID <-> kernel session id
matching.

- For #1, in the userespace node db code we can implement some iSID
allocation/management code that follows the spec. We can also add a
blacklist there in case we find broken targets.

  reply	other threads:[~2016-02-12 22:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 17:38 Lee Duncan
2016-02-12 17:54 ` James Bottomley
2016-02-12 22:13   ` Mike Christie [this message]
2016-02-15 18:26   ` Chris Leech
2016-02-16 18:40     ` Mike Christie
2016-02-17 22:37       ` Chris Leech
2016-03-08  1:02   ` Lee Duncan
2016-03-08  2:15     ` Martin K. Petersen
2016-03-08 17:21 ` Chris Leech
2016-03-09  8:43 ` Johannes Thumshirn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56BE5915.9070308@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=lduncan@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=open-iscsi@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®