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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox