All of lore.kernel.org
 help / color / mirror / Atom feed
From: Howell, Seth <seth.howell at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Updating discovery for ACL
Date: Mon, 25 Feb 2019 18:01:49 +0000	[thread overview]
Message-ID: <EA913ED399BBA34AA4EAC2EDC24CDD009C27254D@FMSMSX105.amr.corp.intel.com> (raw)
In-Reply-To: AM6PR04MB5127C9BBCD8E29C04C977A1D89790@AM6PR04MB5127.eurprd04.prod.outlook.com

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

Hi Shahar,

I think that placing the hostnqn in the controller is the right thing to do. It will still be accessible from the request object when we do the discovery a few commands later.
When it comes to the actual discovery mechanism, what is your plan? Currently, we only regenerate the discovery log when the generation counter has changed and the log is stored as a collection of strings. We will have to find a way to get back to the subsystems from the log page entries to check access controls.
One would be to regenerate the discovery log every time someone asks for it and check the hostnqn in nvmf_update_discovery_log.
Another way would be to add a new function such as get_nvmf_subsystem_by_nqn to the internal api. That would allow you to loop over the already generated log page buffer and copy over only the allowed entries. I think this way would be more efficient than the first.

Thanks,

Seth

-----Original Message-----
From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Shahar Salzman
Sent: Sunday, February 24, 2019 12:51 PM
To: Storage Performance Development Kit <spdk(a)lists.01.org>
Subject: [SPDK] Updating discovery for ACL

Hi,

I am following up on bug # 576 - nvme discover shows all target subsystems, even those that are not accessible by the host.

I looked at the discovery subsystem code, and it seems that a good option would be to copy only the relevant part of the discovery log page (i.e. only information about subsystems that the host has access to).
The problem is, that on the discover request there is no hostnqn information,

Looking at the connect, I see that the hostnqn is checked, but not saved anywhere, so it looks like a good option to save it on the controller, so that we can later reference this value.

Now upon discovery we can copy the relevant portions of the log page.

WDYT?

Shahar
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk

             reply	other threads:[~2019-02-25 18:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-25 18:01 Howell, Seth [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-02-27  8:31 [SPDK] Updating discovery for ACL Shahar Salzman
2019-02-24 19:51 Shahar Salzman

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=EA913ED399BBA34AA4EAC2EDC24CDD009C27254D@FMSMSX105.amr.corp.intel.com \
    --to=spdk@lists.01.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.