From: miltonm@bga.com
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
Stefani Seibold <stefani@seibold.net>
Subject: Re: kfifo must_check warning (+ patch)
Date: Wed, 20 Oct 2010 12:51:27 -0500 [thread overview]
Message-ID: <kfifo-patch1-reply@mdm.bga.com> (raw)
In-Reply-To: <20101020094659.091113f5.randy.dunlap@oracle.com>
> --- linux-next-20101019.orig/drivers/char/n_gsm.c
> +++ linux-next-20101019/drivers/char/n_gsm.c
> @@ -1573,11 +1573,14 @@ static void gsm_dlci_command(struct gsm_
> static struct gsm_dlci *gsm_dlci_alloc(struct gsm_mux *gsm, int addr)
> {
> struct gsm_dlci *dlci = kzalloc(sizeof(struct gsm_dlci), GFP_ATOMIC);
> + int err;
> +
> if (dlci == NULL)
> return NULL;
> spin_lock_init(&dlci->lock);
> dlci->fifo = &dlci->_fifo;
> - if (kfifo_alloc(&dlci->_fifo, 4096, GFP_KERNEL) < 0) {
> + err = kfifo_alloc(&dlci->_fifo, 4096, GFP_KERNEL);
> + if (err < 0) {
> kfree(dlci);
> return NULL;
> }
>
>
I think this is not a gcc bug but Randy's gcc beeing smarter
and showing a signed bug with the old code.
The earlier discussion had:
> > > Should the driver code be doing something else?
> > > or should the kfifo_alloc() macro be checking the result of the helper?
> > >
> >
> > A gcc bug, I'd say. The code looks OK and my gcc doesn't warn.
>
> OK.
>
> > Perhaps see if you can find some code transformation in n_gsm.c which
> > makes it go away? Add a new local variable or something.
>
> Yes, that works for me. Patch is below.
>
> > I did see a probably unrelated bug in there though.
> > __kfifo_must_check_helper() coerces its arg into an `unsigned int' and
> > returns an unsigned int. Consequently if kfifo_alloc() tries to return
> > -EINVAL, the above-quoted code won't detect the error: it will see
> > -EINVAL as a large, positive unsigned value.
> >
and then gcc decides that the check of < 0 is meaningless, and then
says that the result is unused.
Note: I'm a kernel hacker , not a gcc one. This is pure speculation.
So to me the helper is the one causing the error! ... and the patch is
undoing the damage at the caller.
So the correct fix is to change the return type of the helper,
and if someone wants the int to be unsigned then it needs to be
unsigned long so we can use an is_error type test.
milton
next prev parent reply other threads:[~2010-10-20 18:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-19 22:10 kfifo must_check warning Randy Dunlap
2010-10-20 5:12 ` Andrew Morton
2010-10-20 16:46 ` kfifo must_check warning (+ patch) Randy Dunlap
2010-10-20 17:51 ` miltonm [this message]
2010-10-20 18:37 ` Alan Cox
2010-10-20 18:56 ` Andrew Morton
2010-10-20 20:09 ` Stefani Seibold
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=kfifo-patch1-reply@mdm.bga.com \
--to=miltonm@bga.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=stefani@seibold.net \
/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