From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
To: SF Markus Elfring <elfring@users.sourceforge.net>,
linux-mtd@lists.infradead.org,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>
Cc: LKML <linux-kernel@vger.kernel.org>, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 1/3] mtd/ftl: Use kmalloc_array() in build_maps()
Date: Thu, 12 Jan 2017 13:00:03 +0000 [thread overview]
Message-ID: <4be87294-5e91-5ced-770f-8630ccab689a@atmel.com> (raw)
In-Reply-To: <b379ba57-d926-2572-17ec-5bbe166b0e37@users.sourceforge.net>
Le 12/01/2017 à 11:35, SF Markus Elfring a écrit :
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Thu, 12 Jan 2017 10:42:25 +0100
>
> * Multiplications for the size determination of memory allocations
> indicated that array data structures should be processed.
> Thus use the corresponding function "kmalloc_array".
>
> This issue was detected by using the Coccinelle software.
>
> * Replace the specification of data types by pointer dereferences
> to make the corresponding size determination a bit safer according to
> the Linux coding style convention.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/mtd/ftl.c | 13 ++++++-------
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/ftl.c b/drivers/mtd/ftl.c
> index 9fb3b0dcdac2..ef2f38b6a837 100644
> --- a/drivers/mtd/ftl.c
> +++ b/drivers/mtd/ftl.c
> @@ -207,15 +207,14 @@ static int build_maps(partition_t *part)
> /* Set up erase unit maps */
> part->DataUnits = le16_to_cpu(part->header.NumEraseUnits) -
> part->header.NumTransferUnits;
> - part->EUNInfo = kmalloc(part->DataUnits * sizeof(struct eun_info_t),
> - GFP_KERNEL);
> + part->EUNInfo = kmalloc_array(part->DataUnits, sizeof(*part->EUNInfo),
> + GFP_KERNEL);
The indentation has been changed and the new one looks wrong...
I understand the original indentation, with spaces, doesn't follow the
Linux coding style but at least it's consistent and readable.
Your patch uses a different indentation with tabs, which now mixes two
different indentations: IMHO, this is worst than before.
If you want to fix the indentation to make it compliant with the Linux
coding style, do it on the whole file so every thing is uniform.
Reviewing such dummy/automatic patches is a pure waste of time, so
personally I think we should just ignore them.
> if (!part->EUNInfo)
> goto out;
> for (i = 0; i < part->DataUnits; i++)
> part->EUNInfo[i].Offset = 0xffffffff;
> - part->XferInfo > - kmalloc(part->header.NumTransferUnits * sizeof(struct xfer_info_t),
> - GFP_KERNEL);
> + part->XferInfo = kmalloc_array(part->header.NumTransferUnits,
> + sizeof(*part->XferInfo), GFP_KERNEL);
Another indentation issue is introduced here too...
> if (!part->XferInfo)
> goto out_EUNInfo;
>
> @@ -275,8 +274,8 @@ static int build_maps(partition_t *part)
> memset(part->VirtualBlockMap, 0xff, blocks * sizeof(uint32_t));
> part->BlocksPerUnit = (1 << header.EraseUnitSize) >> header.BlockSize;
>
> - part->bam_cache = kmalloc(part->BlocksPerUnit * sizeof(uint32_t),
> - GFP_KERNEL);
> + part->bam_cache = kmalloc_array(part->BlocksPerUnit,
> + sizeof(*part->bam_cache), GFP_KERNEL);
+1
> if (!part->bam_cache)
> goto out_VirtualBlockMap;
>
>
next prev parent reply other threads:[~2017-01-12 13:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 10:33 [PATCH 0/3] MTD-FTL: Fine-tuning for two function implementations SF Markus Elfring
2017-01-12 10:35 ` [PATCH 1/3] mtd/ftl: Use kmalloc_array() in build_maps() SF Markus Elfring
2017-01-12 13:00 ` Cyrille Pitchen [this message]
2017-01-12 16:50 ` SF Markus Elfring
2017-01-12 16:58 ` Marek Vasut
2017-01-13 9:32 ` [PATCH 1/3] " kbuild test robot
2017-01-12 10:36 ` [PATCH 2/3] mtd/ftl: Delete an error message for a failed memory allocation in ftl_add_mtd() SF Markus Elfring
2017-01-12 10:38 ` [PATCH 3/3] mtd/ftl: Improve another size determination " SF Markus Elfring
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=4be87294-5e91-5ced-770f-8630ccab689a@atmel.com \
--to=cyrille.pitchen@atmel.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=elfring@users.sourceforge.net \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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