From: Jon Hunter <jonathanh@nvidia.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>, <grundler@google.com>,
<olofj@chromium.org>, Seshagiri Holi <sholi@nvidia.com>,
<linux-mmc@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mmc: block: Add new ioctl to send multi commands
Date: Wed, 9 Sep 2015 17:44:54 +0100 [thread overview]
Message-ID: <55F06206.9040001@nvidia.com> (raw)
In-Reply-To: <1481090.IIYrKtDeR0@wuerfel>
On 09/09/15 16:56, Arnd Bergmann wrote:
> On Wednesday 09 September 2015 16:06:01 Jon Hunter wrote:
>> +
>> + idata = kcalloc(mcci.num_of_cmds, sizeof(*idata), GFP_KERNEL);
>> + if (!idata) {
>> + err = -ENOMEM;
>> + goto cmd_err;
>> + }
>> +
>> + cmds = (struct mmc_ioc_cmd __user *)(unsigned long)mcci.cmds_ptr;
>> + for (n_cmds = 0; n_cmds < mcci.num_of_cmds; n_cmds++) {
>> + idata[n_cmds] = mmc_blk_ioctl_copy_from_user(&cmds[n_cmds]);
>> + if (IS_ERR(idata[n_cmds])) {
>> + err = PTR_ERR(idata[n_cmds]);
>> + goto cmd_err;
>> + }
>> + }
>> +
>
> You have no upper bound on the number of commands, which means you end
> up catching overly large arguments only through -ENOMEM. Can you come
> up with an upper bound that is guaranteed to succeed with the allocation?
The uint8 type would limit you to 256 commands (if you have the memory),
although admittedly that is probably overkill.
> Or would it be possible to process the user data one at a time while
> going through the commands?
Yes, I think that could be a good option, I will take a look.
>> +struct mmc_ioc_multi_cmd {
>> + __u64 cmds_ptr;
>> + uint8_t num_of_cmds;
>> +};
>
> complex commands are always nasty in one way or another. Can you describe
> in the patch description why you picked an indirect pointer over something
> like
>
> struct mmc_ioc_multi_cmd {
> __u64 num_of_cmds;
> struct mmc_ioc_cmd cmds[0];
> };
>
> as I said, both are ugly. My first choice would have been the other one,
> but I'm sure you have some reasons yourself.
It was a suggestion from Olof to ensure the structure size is constant for
both 32-bit and 64-bit userspaces. I am not sure if it is worth adding a
macro similar to the below for this?
#define mmc_ioc_cmd_set_data(ic, ptr) ic.data_ptr = (__u64)(unsigned long) ptr
However, yes can update the changelog.
Cheers
Jon
next prev parent reply other threads:[~2015-09-09 16:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 15:06 [PATCH] mmc: block: Add new ioctl to send multi commands Jon Hunter
2015-09-09 15:56 ` Arnd Bergmann
2015-09-09 16:44 ` Jon Hunter [this message]
2015-09-09 20:22 ` Arnd Bergmann
2015-09-10 8:24 ` Jon Hunter
2015-09-10 8:38 ` Arnd Bergmann
2015-09-10 17:10 ` Grant Grundler
2015-09-10 18:20 ` Jon Hunter
2015-09-10 20:26 ` Grant Grundler
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=55F06206.9040001@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=arnd@arndb.de \
--cc=grundler@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=olofj@chromium.org \
--cc=sholi@nvidia.com \
--cc=ulf.hansson@linaro.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).