From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"evgreen@chromium.org" <evgreen@chromium.org>,
"vinholikatti@gmail.com" <vinholikatti@gmail.com>,
Stanislav Nijnikov <Stanislav.Nijnikov@wdc.com>
Cc: "gwendal@chromium.org" <gwendal@chromium.org>
Subject: Re: [PATCH 5/7] scsi: ufs: Refactor descriptor read for write
Date: Mon, 4 Jun 2018 08:40:44 +0000 [thread overview]
Message-ID: <21ce321eb2d81d59d6e4578669b8287b9ac4d29f.camel@wdc.com> (raw)
In-Reply-To: <20180529181740.195362-6-evgreen@chromium.org>
On Tue, 2018-05-29 at 11:17 -0700, Evan Green wrote:
> /* Check whether we need temp memory */
> if (param_offset != 0 || param_size < buff_len) {
> - desc_buf = kmalloc(buff_len, GFP_KERNEL);
> + desc_buf = kzalloc(buff_len, GFP_KERNEL);
> if (!desc_buf)
> return -ENOMEM;
> +
> + /* If it's a write, first read the complete descriptor, then
> + * copy in the parts being changed.
> + */
Have you verified this patch with checkpatch? The above comment does not follow
the Linux kernel coding style.
> + if (opcode == UPIU_QUERY_OPCODE_WRITE_DESC) {
> + if ((int)param_offset + (int)param_size > buff_len) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + ret = ufshcd_query_descriptor_retry(hba,
> + UPIU_QUERY_OPCODE_READ_DESC,
> + desc_id, desc_index, 0,
> + desc_buf, &buff_len);
> +
> + if (ret) {
> + dev_err(hba->dev,
> + "%s: Failed reading descriptor. desc_id %d, desc_index %d, param_offset %d, ret %d",
> + __func__, desc_id, desc_index,
> + param_offset, ret);
> +
> + goto out;
> + }
> +
> + memcpy(desc_buf + param_offset, param_buf, param_size);
> + }
The above code is indented deeply. I think that means that this code would become
easier to read if a helper function would be introduced.
Additionally, I think locking is missing from the above code. How else can race
conditions between concurrent writers be prevented?
Bart.
next prev parent reply other threads:[~2018-06-04 8:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 18:17 [PATCH 0/7] Enable UFS provisioning via Linux Evan Green
2018-05-29 18:17 ` [PATCH 1/7] scsi: ufs: Add Configuration Descriptor to sysfs Evan Green
2018-06-04 8:31 ` Bart Van Assche
2018-06-04 15:39 ` Evan Green
2018-05-29 18:17 ` [PATCH 2/7] scsi: ufs: Add config descriptor documentation Evan Green
2018-06-04 8:34 ` Bart Van Assche
2018-06-04 15:39 ` Evan Green
2018-05-29 18:17 ` [PATCH 3/7] scsi: ufs: Make sysfs attributes writable Evan Green
2018-06-04 8:33 ` Bart Van Assche
2018-06-04 15:39 ` Evan Green
2018-05-29 18:17 ` [PATCH 4/7] scsi: ufs: sysfs: Document attribute writability Evan Green
2018-06-04 8:35 ` Bart Van Assche
2018-06-04 15:39 ` Evan Green
2018-05-29 18:17 ` [PATCH 5/7] scsi: ufs: Refactor descriptor read for write Evan Green
2018-05-30 17:21 ` Evan Green
2018-06-04 8:40 ` Bart Van Assche [this message]
2018-06-04 15:40 ` Evan Green
2018-05-29 18:17 ` [PATCH 6/7] scsi: ufs: Enable writing config descriptor Evan Green
2018-06-04 8:46 ` Bart Van Assche
2018-05-29 18:17 ` [PATCH 7/7] scsi: ufs: Update config descriptor documentation Evan Green
2018-05-31 10:04 ` [PATCH 0/7] Enable UFS provisioning via Linux Stanislav Nijnikov
2018-06-01 14:44 ` Evan Green
2018-06-03 10:21 ` Stanislav Nijnikov
2018-06-04 14:59 ` Evan Green
2018-06-08 12:30 ` Adrian Hunter
2018-06-10 9:31 ` Stanislav Nijnikov
2018-06-12 19:42 ` Evan Green
2018-06-12 20:11 ` Bart Van Assche
2018-06-13 10:12 ` Stanislav Nijnikov
2018-06-15 21:19 ` Evan Green
2018-06-04 11:11 ` Kyuho Choi
2018-06-04 15:03 ` Evan Green
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=21ce321eb2d81d59d6e4578669b8287b9ac4d29f.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=Stanislav.Nijnikov@wdc.com \
--cc=evgreen@chromium.org \
--cc=gwendal@chromium.org \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=vinholikatti@gmail.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