From: Andrew Morton <akpm@linux-foundation.org>
To: Richard Yang <weiyang@linux.vnet.ibm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
richard -rw- weinberger <richard.weinberger@gmail.com>,
Stefani Seibold <stefani@seibold.net>,
Jiri Kosina <jkosina@suse.cz>
Subject: Re: linux-next: build warnings after merge of the akpm tree
Date: Thu, 25 Oct 2012 15:23:37 -0700 [thread overview]
Message-ID: <20121025152337.7f14919d.akpm@linux-foundation.org> (raw)
In-Reply-To: <508948de.01dc440a.58ed.ffffff17SMTPIN_ADDED@mx.google.com>
On Thu, 25 Oct 2012 22:12:32 +0800
Richard Yang <weiyang@linux.vnet.ibm.com> wrote:
> >drivers/scsi/libiscsi.c: In function 'iscsi_free_task':
> >drivers/scsi/libiscsi.c:507:2: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi.c: In function 'iscsi_pool_init':
> >drivers/scsi/libiscsi.c:2510:3: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi.c: In function 'iscsi_conn_setup':
> >drivers/scsi/libiscsi.c:2881:2: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi.c: In function 'iscsi_conn_teardown':
> >drivers/scsi/libiscsi.c:2944:2: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi_tcp.c: In function 'iscsi_tcp_cleanup_task':
> >drivers/scsi/libiscsi_tcp.c:462:3: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi_tcp.c:469:3: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi_tcp.c: In function 'iscsi_tcp_r2t_rsp':
> >drivers/scsi/libiscsi_tcp.c:570:3: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi_tcp.c:586:3: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi_tcp.c:596:2: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >drivers/scsi/libiscsi_tcp.c: In function 'iscsi_tcp_get_curr_r2t':
> >drivers/scsi/libiscsi_tcp.c:998:5: warning: comparison of distinct pointer types lacks a cast [enabled by default]
> >
>
> ...
>
> I did a quick check.
>
> The root reason is,
> 1. kfifo_in() second parameter should be type "const void *"
> 2. kfifo_out_locked() second parameter should be type "void *"
> 3. kfifo_in_locked() second parameter should be type "const void *"
>
> And I am curious about why the original code couldn't detect this type
> mismatch.
Well, just looking at __cxio_init_resource_fifo():
u32 entry = 0;
...
kfifo_in(fifo, (unsigned char *) &entry, sizeof(u32));
This is silly - we shouldn't warn about this code. There is no reason
for the kfifo library code to require that the *caller*'s storage be
const!
kfifo_in() is (or should be) simulating a C function with the interface:
unsigned int kfifo_in(struct kfifo *fifo, const void *buf, size_t n);
This states "this function does not modify the memory at *buf" and it's
perfectly OK for a caller to pass a non-const pointer into kfifo_in().
We shouldn't warn about this.
In fact, the __cxio_init_resource_fifo() shouldn't need to cast `buf'
to uchar* either. The need to add that cast is a shortcoming in the
existing kfifo code.
We should be able to pass *any* pointer, of any type, const or
non-const into code which expects a const void *, without any warning.
And holy cow that code is hard to read :( Why was kfifo_in()
implemented as a macro, anyway? AFAICT all its args have a known type,
so we could have used a proper C interface, which would have fixed all
this nicely.
Anyway,
include-linux-kfifoh-replace-open-coded-type-check-code-with-typecheck.patch
takes the kfifo typechecking from "too strict" to "far too strict", so
I'll drop that patch.
next prev parent reply other threads:[~2012-10-25 22:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-25 3:28 linux-next: build warnings after merge of the akpm tree Stephen Rothwell
2012-10-25 3:30 ` Stephen Rothwell
[not found] ` <20121025141232.GB4730@richard.(null)>
2012-10-25 14:16 ` Stephen Rothwell
[not found] ` <508948de.01dc440a.58ed.ffffff17SMTPIN_ADDED@mx.google.com>
2012-10-25 22:23 ` Andrew Morton [this message]
2012-10-25 23:50 ` Stephen Rothwell
[not found] ` <20121025223656.GA3805@richard.(null)>
2012-10-26 5:44 ` Stefani Seibold
[not found] ` <20121025130952.GA4730@richard.(null)>
2012-10-25 14:20 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2012-11-29 6:19 Stephen Rothwell
2012-11-29 7:24 ` Lars Ellenberg
2016-11-24 5:20 Stephen Rothwell
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=20121025152337.7f14919d.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=richard.weinberger@gmail.com \
--cc=sfr@canb.auug.org.au \
--cc=stefani@seibold.net \
--cc=weiyang@linux.vnet.ibm.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.