From: Mark Ruijter <mruijter@primelogic.nl>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>
Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Exporting NVMe-oF devices read-only enforced on export from the NVMe-oF target.
Date: Tue, 29 Sep 2020 11:34:53 +0000 [thread overview]
Message-ID: <BBC87AAC-A523-41F0-8CDE-38757C407C7F@primelogic.nl> (raw)
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi all,
Unless I am mistaken the NVMe-oF target driver does currently not support to export a device read-only from the target system.
For exporting readonly snapshot devices I am currently using the attached patch.
Does this change, or a similar change, make sense for upstream?
--
With the patch and after setting the namespace to readonly:
namespaces/1 # echo 1 > readonly
namespaces/1 # echo 1 > enable
On the initiator system writes are now no longer permitted:
root@r11i3:~# echo hello >/dev/nvme5n1
-bash: echo: write error: Operation not permitted
--
Thanks,
Mark Ruijter
[-- Attachment #2: readonly.patch --]
[-- Type: application/octet-stream, Size: 1305 bytes --]
--- drivers/nvme/target/configfs.c-orig 2020-08-21 05:50:14.369462419 -0600
+++ drivers/nvme/target/configfs.c 2020-08-21 05:37:13.817449795 -0600
@@ -543,6 +543,34 @@
CONFIGFS_ATTR(nvmet_ns_, buffered_io);
+static ssize_t nvmet_ns_readonly_show(struct config_item *item, char *page)
+{
+ return sprintf(page, "%d\n", to_nvmet_ns(item)->readonly);
+}
+
+static ssize_t nvmet_ns_readonly_store(struct config_item *item,
+ const char *page, size_t count)
+{
+ struct nvmet_ns *ns = to_nvmet_ns(item);
+ bool val;
+
+ if (strtobool(page, &val))
+ return -EINVAL;
+
+ mutex_lock(&ns->subsys->lock);
+ if (ns->enabled) {
+ pr_err("disable ns before setting readonly value.\n");
+ mutex_unlock(&ns->subsys->lock);
+ return -EINVAL;
+ }
+
+ ns->readonly = val;
+ mutex_unlock(&ns->subsys->lock);
+ return count;
+}
+
+CONFIGFS_ATTR(nvmet_ns_, readonly);
+
static struct configfs_attribute *nvmet_ns_attrs[] = {
&nvmet_ns_attr_device_path,
&nvmet_ns_attr_device_nguid,
@@ -550,6 +578,7 @@
&nvmet_ns_attr_ana_grpid,
&nvmet_ns_attr_enable,
&nvmet_ns_attr_buffered_io,
+ &nvmet_ns_attr_readonly,
#ifdef CONFIG_PCI_P2PDMA
&nvmet_ns_attr_p2pmem,
#endif
[-- Attachment #3: Type: text/plain, Size: 158 bytes --]
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next reply other threads:[~2020-09-29 11:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-29 11:34 Mark Ruijter [this message]
2020-09-30 0:28 ` Exporting NVMe-oF devices read-only enforced on export from the NVMe-oF target Chaitanya Kulkarni
2020-09-30 7:38 ` Mark Ruijter
2020-10-01 1:41 ` Chaitanya Kulkarni
2020-10-09 0:24 ` Sagi Grimberg
[not found] ` <BYAPR04MB496559D7BD43F180E366D91A86080@BYAPR04MB4965.namprd04.prod.outlook.com>
2020-10-09 7:57 ` Sagi Grimberg
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=BBC87AAC-A523-41F0-8CDE-38757C407C7F@primelogic.nl \
--to=mruijter@primelogic.nl \
--cc=Chaitanya.Kulkarni@wdc.com \
--cc=linux-nvme@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).