From: Mike Christie <michael.christie@oracle.com>
To: Maurizio Lombardi <mlombard@redhat.com>, martin.petersen@oracle.com
Cc: target-devel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] target: allow changing dbroot if there are no registered devices
Date: Tue, 22 Feb 2022 14:57:30 -0600 [thread overview]
Message-ID: <e77b17da-f3cd-3a89-c46b-67dadae359ed@oracle.com> (raw)
In-Reply-To: <20220107151054.29734-1-mlombard@redhat.com>
On 1/7/22 9:10 AM, Maurizio Lombardi wrote:
> The target driver prevents the users from changing
> the database root directory if a target module like ib_srpt has
> been registered, this makes it difficult for users to
> set their preferred database directory if the module
> gets loaded during the system boot.
>
> Let the users modify dbroot if there are no registered devices
>
> Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
> ---
> drivers/target/target_core_configfs.c | 20 ++++++++------------
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c
> index 023bd4516a68..cba10829e62f 100644
> --- a/drivers/target/target_core_configfs.c
> +++ b/drivers/target/target_core_configfs.c
> @@ -72,6 +72,8 @@ static struct config_group target_core_hbagroup;
> static struct config_group alua_group;
> static struct config_group alua_lu_gps_group;
>
> +static unsigned int target_devices;
> +
> static inline struct se_hba *
> item_to_hba(struct config_item *item)
> {
> @@ -106,38 +108,32 @@ static ssize_t target_core_item_dbroot_store(struct config_item *item,
> ssize_t read_bytes;
> struct file *fp;
>
> - mutex_lock(&g_tf_lock);
> - if (!list_empty(&g_tf_list)) {
> - mutex_unlock(&g_tf_lock);
> - pr_err("db_root: cannot be changed: target drivers registered");
> + if (target_devices) {
> + pr_err("db_root: cannot be changed because it's in use\n");
> return -EINVAL;
> }
>
How does the locking work for this patch?
The configfs subsys mutex handles the make and drop callouts below.
For this part though, it didn't look like we are holding the same mutex,
so can target_devices increase after we've passed that check? If so, was
the idea that it's one of those things where if it races then it doesn't
really matter because it's rare and nothing is really hurt?
> if (count > (DB_ROOT_LEN - 1)) {
> - mutex_unlock(&g_tf_lock);
> pr_err("db_root: count %d exceeds DB_ROOT_LEN-1: %u\n",
> (int)count, DB_ROOT_LEN - 1);
> return -EINVAL;
> }
>
> read_bytes = snprintf(db_root_stage, DB_ROOT_LEN, "%s", page);
> - if (!read_bytes) {
> - mutex_unlock(&g_tf_lock);
> + if (!read_bytes)
> return -EINVAL;
> - }
> +
> if (db_root_stage[read_bytes - 1] == '\n')
> db_root_stage[read_bytes - 1] = '\0';
>
> /* validate new db root before accepting it */
> fp = filp_open(db_root_stage, O_RDONLY, 0);
> if (IS_ERR(fp)) {
> - mutex_unlock(&g_tf_lock);
> pr_err("db_root: cannot open: %s\n", db_root_stage);
> return -EINVAL;
> }
> if (!S_ISDIR(file_inode(fp)->i_mode)) {
> filp_close(fp, NULL);
> - mutex_unlock(&g_tf_lock);
> pr_err("db_root: not a directory: %s\n", db_root_stage);
> return -EINVAL;
> }
> @@ -145,8 +141,6 @@ static ssize_t target_core_item_dbroot_store(struct config_item *item,
>
> strncpy(db_root, db_root_stage, read_bytes);
>
> - mutex_unlock(&g_tf_lock);
> -
> pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
>
> return read_bytes;
> @@ -3315,6 +3309,7 @@ static struct config_group *target_core_make_subdev(
> */
> target_stat_setup_dev_default_groups(dev);
>
> + target_devices++;
> mutex_unlock(&hba->hba_access_mutex);
> return &dev->dev_group;
>
> @@ -3353,6 +3348,7 @@ static void target_core_drop_subdev(
> * se_dev is released from target_core_dev_item_ops->release()
> */
> config_item_put(item);
> + target_devices--;
> mutex_unlock(&hba->hba_access_mutex);
> }
>
next prev parent reply other threads:[~2022-02-22 20:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 15:10 [PATCH] target: allow changing dbroot if there are no registered devices Maurizio Lombardi
2022-02-22 20:57 ` Mike Christie [this message]
2022-02-24 9:00 ` Maurizio Lombardi
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=e77b17da-f3cd-3a89-c46b-67dadae359ed@oracle.com \
--to=michael.christie@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mlombard@redhat.com \
--cc=target-devel@vger.kernel.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