From: Guenter Roeck <linux@roeck-us.net>
To: Arvind Yadav <arvind.yadav.cs@gmail.com>
Cc: scottwood@freescale.com, qiang.zhao@freescale.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: Remove lots of IS_ERR_VALUE abuses and compilation warning.
Date: Thu, 7 Jul 2016 08:51:02 -0700 [thread overview]
Message-ID: <20160707155102.GA5107@roeck-us.net> (raw)
In-Reply-To: <1467905249-3990-1-git-send-email-arvind.yadav.cs@gmail.com>
On Thu, Jul 07, 2016 at 08:57:29PM +0530, Arvind Yadav wrote:
> Passing value in IS_ERR_VALUE() is wrong, as they
> pass an 'int' into a function that takes an 'unsigned long'
> argument. This happens to work because the type is sign-extended
> on 64-bit architectures before it gets converted into an
> unsigned type.
>
> Passing an 'unsigned short' or 'unsigned int'
> argument into IS_ERR_VALUE() is guaranteed to be broken, as are
> 8-bit integers and types that are wider than 'unsigned long'.
>
> Any user will get compilation warning for that do not pass an
> 'unsigned long' argument.
>
> Commit '287980e49f; - This change is alreday fixes lots of other
> worst abusers.
>
Couple of generic comments:
- Your patch subject lines don't include the affected drivers/modules.
As such, most of them will be ignored because maintainers won't realize
that you are talking with them. Some may ask you to resubmit with proper
subject lines.
Commit 287980e49f is different; it addresses the problem in several
drivers in a single commit.
- If you patch a single file, I think it would be better to adjust the
description accordingly. In this patch, the offending variable type is
u32. The patch description is therefore misleading; the code here simply does
not work.
- When you resubmit a patch, you don't include a version, not a change log.
This means additional work for maintainers, who have to figure out which
patch to apply.
Specific comment:
The allocator in question returns -ENOMEM in an unsigned long. This is assigned
to u32. A proper fix would be to assign the return value to an unsigned
long and to use IS_ER_VALUE() to check if it reports an error, and to only
assign it to ucc_fast_rx_virtual_fifo_base_offset if there was no error.
Also, unless I am missing something - since ucc_fast_rx_virtual_fifo_base_offset
is defined as u32, it is somewhat unlikely that it is ever < 0.
Guenter
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
> ---
> drivers/soc/fsl/qe/ucc_fast.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/ucc_fast.c b/drivers/soc/fsl/qe/ucc_fast.c
> index a768931..7cc783c 100644
> --- a/drivers/soc/fsl/qe/ucc_fast.c
> +++ b/drivers/soc/fsl/qe/ucc_fast.c
> @@ -268,7 +268,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
> /* Allocate memory for Tx Virtual Fifo */
> uccf->ucc_fast_tx_virtual_fifo_base_offset =
> qe_muram_alloc(uf_info->utfs, UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
> - if (IS_ERR_VALUE(uccf->ucc_fast_tx_virtual_fifo_base_offset)) {
> + if (uccf->ucc_fast_tx_virtual_fifo_base_offset < 0) {
> printk(KERN_ERR "%s: cannot allocate MURAM for TX FIFO\n",
> __func__);
> uccf->ucc_fast_tx_virtual_fifo_base_offset = 0;
> @@ -281,7 +281,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct ucc_fast_private ** ucc
> qe_muram_alloc(uf_info->urfs +
> UCC_FAST_RECEIVE_VIRTUAL_FIFO_SIZE_FUDGE_FACTOR,
> UCC_FAST_VIRT_FIFO_REGS_ALIGNMENT);
> - if (IS_ERR_VALUE(uccf->ucc_fast_rx_virtual_fifo_base_offset)) {
> + if (uccf->ucc_fast_rx_virtual_fifo_base_offset < 0) {
> printk(KERN_ERR "%s: cannot allocate MURAM for RX FIFO\n",
> __func__);
> uccf->ucc_fast_rx_virtual_fifo_base_offset = 0;
next prev parent reply other threads:[~2016-07-07 16:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-07 15:27 [PATCH] Remove lots of IS_ERR_VALUE abuses and compilation warning Arvind Yadav
2016-07-07 15:51 ` Guenter Roeck [this message]
2016-07-07 17:06 ` arvind Yadav
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=20160707155102.GA5107@roeck-us.net \
--to=linux@roeck-us.net \
--cc=arvind.yadav.cs@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=qiang.zhao@freescale.com \
--cc=scottwood@freescale.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.