All of lore.kernel.org
 help / color / mirror / Atom feed
From: "yukuai (C)" <yukuai3@huawei.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Harald Welte <laforge@gnumonks.org>,
	gregkh <gregkh@linuxfoundation.org>, <akpm@osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"zhangyi (F)" <yi.zhang@huawei.com>
Subject: Re: [PATCH] char: pcmcia: remove set but not used variable 'tmp'
Date: Sat, 15 May 2021 15:15:56 +0800	[thread overview]
Message-ID: <7dc2aaca-20d1-46fc-e5a0-312f3fbc7ea4@huawei.com> (raw)
In-Reply-To: <CAK8P3a01oF7QZzjbd703QwiK+6ZPx1w-fSBcLjeMm4KQ0X0amw@mail.gmail.com>

On 2021/05/14 14:28, Arnd Bergmann wrote:
> On Fri, May 14, 2021 at 8:21 AM Yu Kuai <yukuai3@huawei.com> wrote:
>>
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> drivers/char/pcmcia/cm4000_cs.c:1053:16: warning: variable ‘tmp’
>> set but not used [-Wunused-but-set-variable]
>>
>> It is never used and so can be removed.
>>
>> Fixes: c1986ee9bea3 ("[PATCH] New Omnikey Cardman 4000 driver")
>> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> 
> Looks good to me. This was likely written that way at a time when some
> architecture implemented inb() as a macro, and ignoring its value
> would cause a different warning.
> 
> Since you are already touching this file, can you have a look at this
> warning as well:
> 
>     drivers/char/pcmcia/cm4000_cs.c: In function 'set_protocol':
>>> drivers/char/pcmcia/cm4000_cs.c:569:16: warning: iteration 4 invokes undefined behavior [-Waggressive-loop-optimizations]
>       569 |   pts_reply[i] = inb(REG_BUF_DATA(iobase));
>           |   ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
>     drivers/char/pcmcia/cm4000_cs.c:567:2: note: within this loop
>       567 |  for (i = 0; i < num_bytes_read; i++) {
> 
> This looks like a preexisting problem that was uncovered by a patch
> that is now in linux-next to change the inb() definition once more,
> I got a report from the kernel build bot about it after I merged the
> patch into the asm-generic tree. It needs a range check on
> num_bytes_read, or a Kconfig check to ensure it is not built on
> architectures without working inb()/outb() operations.
> 
>          Arnd
> .
> 
Hi,

I'm not familar with the logical here, however, if io_read_num_rec_bytes
may get 'num_bytes_read' greater than 4, this loop will cause index out
of boundary. It make sense to me to add a range check. Futhermore, since
'num_bytes_read' is ensure to >= 4,I think we can change the loop to:

for (i = 0; i < 4; ++i) {
	xoutb(i, REG_BUF_ADDR(iobase));
	pts_reply[i] = inb(REG_BUF_DATA(iobase));
}

Thanks
Yu Kuai


  reply	other threads:[~2021-05-15  7:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14  6:21 [PATCH] char: pcmcia: remove set but not used variable 'tmp' Yu Kuai
2021-05-14  6:28 ` Arnd Bergmann
2021-05-15  7:15   ` yukuai (C) [this message]
2021-05-15  9:05     ` Arnd Bergmann

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=7dc2aaca-20d1-46fc-e5a0-312f3fbc7ea4@huawei.com \
    --to=yukuai3@huawei.com \
    --cc=akpm@osdl.org \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=laforge@gnumonks.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yi.zhang@huawei.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.