Hi,
I've been building some randconfig kernels lately and I've noticed
this in a few builds :
drivers/block/cciss.c:2614: warning: right shift count >= width of type
drivers/block/cciss.c:2615: warning: right shift count >= width of type
drivers/block/cciss.c:2616: warning: right shift count >= width of type
The code in question is this :
static void do_cciss_request(struct request_queue *q)
{
...
sector_t start_blk;
...
c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
c->Request.CDB[3]= (start_blk >> 48) & 0xff;
c->Request.CDB[4]= (start_blk >> 40) & 0xff;
...
}
The problem stems from these lines in include/linux/types.h :
...
#ifdef CONFIG_LBD
typedef u64 sector_t;
#else
typedef unsigned long sector_t;
#endif
...
So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
Thus it seems gcc is absolutely right in complaining about those
56, 48 & 40 bit shifts, since they are indeed wider than the type
in the "!CONFIG_LBD on a 32bit arch" case.
I must admit that I have no idear what the proper way to deal with
that is, so I'll just report it so hopefully someone else can fix it.
By the way; I'm building current Linus git tree, head at commit
ac07860264bd2b18834d3fa3be47032115524cea
Kind regards,
Jesper Juhl
(whoops, forgot to add maintainer to Cc - now added)
On 12/08/07, Jesper Juhl <[email protected]> wrote:
> Hi,
>
> I've been building some randconfig kernels lately and I've noticed
> this in a few builds :
>
> drivers/block/cciss.c:2614: warning: right shift count >= width of type
> drivers/block/cciss.c:2615: warning: right shift count >= width of type
> drivers/block/cciss.c:2616: warning: right shift count >= width of type
>
> The code in question is this :
>
> static void do_cciss_request(struct request_queue *q)
> {
> ...
> sector_t start_blk;
> ...
> c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
> c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> ...
> }
>
>
> The problem stems from these lines in include/linux/types.h :
> ...
> #ifdef CONFIG_LBD
> typedef u64 sector_t;
> #else
> typedef unsigned long sector_t;
> #endif
> ...
>
> So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32 bits wide.
> Thus it seems gcc is absolutely right in complaining about those
> 56, 48 & 40 bit shifts, since they are indeed wider than the type
> in the "!CONFIG_LBD on a 32bit arch" case.
>
>
> I must admit that I have no idear what the proper way to deal with
> that is, so I'll just report it so hopefully someone else can fix it.
>
> By the way; I'm building current Linus git tree, head at commit
> ac07860264bd2b18834d3fa3be47032115524cea
>
>
> Kind regards,
> Jesper Juhl
>
>
>
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
- c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
- c->Request.CDB[3]= (start_blk >> 48) & 0xff;
- c->Request.CDB[4]= (start_blk >> 40) & 0xff;
- c->Request.CDB[5]= (start_blk >> 32) & 0xff;
- c->Request.CDB[6]= (start_blk >> 24) & 0xff;
- c->Request.CDB[7]= (start_blk >> 16) & 0xff;
- c->Request.CDB[8]= (start_blk >> 8) & 0xff;
+ c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff; //MSB
+ c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+ c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+ c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+ c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+ c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+ c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
c->Request.CDB[9]= start_blk & 0xff;
c->Request.CDB[10]= (creq->nr_sectors >> 24) & 0xff;
c->Request.CDB[11]= (creq->nr_sectors >> 16) & 0xff;
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..fa2eec8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
- c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
- c->Request.CDB[3]= (start_blk >> 48) & 0xff;
- c->Request.CDB[4]= (start_blk >> 40) & 0xff;
- c->Request.CDB[5]= (start_blk >> 32) & 0xff;
- c->Request.CDB[6]= (start_blk >> 24) & 0xff;
- c->Request.CDB[7]= (start_blk >> 16) & 0xff;
- c->Request.CDB[8]= (start_blk >> 8) & 0xff;
+ c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff; //MSB
+ c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
+ c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
+ c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
+ c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
+ c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
+ c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
c->Request.CDB[9]= start_blk & 0xff;
c->Request.CDB[10]= (creq->nr_sectors >> 24) & 0xff;
c->Request.CDB[11]= (creq->nr_sectors >> 16) & 0xff;
On 08/12/2007 03:25 AM, Rene Herman wrote:
> On 08/12/2007 02:56 AM, Jesper Juhl wrote:
>
>> (whoops, forgot to add maintainer to Cc - now added)
>
> Ehm... too late...
Useless followup though -- hp.com rejects me as it feels the SPF neutral
results gmail sends due to me not using the gmail SMTP server and/or web
interface is something it wants to listen to.
I see you are @gmail as well, which depending on how you use it might mean
your are also not able to reach @hp. If anyone can get HP to fix their mail
setup, that'd be useful.
Rene.
>
>> On 12/08/07, Jesper Juhl <[email protected]> wrote:
>>> Hi,
>>>
>>> I've been building some randconfig kernels lately and I've noticed
>>> this in a few builds :
>>>
>>> drivers/block/cciss.c:2614: warning: right shift count >= width of type
>>> drivers/block/cciss.c:2615: warning: right shift count >= width of type
>>> drivers/block/cciss.c:2616: warning: right shift count >= width of type
>>>
>>> The code in question is this :
>>>
>>> static void do_cciss_request(struct request_queue *q)
>>> {
>>> ...
>>> sector_t start_blk;
>>> ...
>>> c->Request.CDB[2]= (start_blk >> 56) &
>>> 0xff; //MSB
>>> c->Request.CDB[3]= (start_blk >> 48) & 0xff;
>>> c->Request.CDB[4]= (start_blk >> 40) & 0xff;
>>> ...
>>> }
>>>
>>>
>>> The problem stems from these lines in include/linux/types.h :
>>> ...
>>> #ifdef CONFIG_LBD
>>> typedef u64 sector_t;
>>> #else
>>> typedef unsigned long sector_t;
>>> #endif
>>> ...
>>>
>>> So on a 32bit arch without CONFIG_LBD, sector_t is going to be 32
>>> bits wide.
>>> Thus it seems gcc is absolutely right in complaining about those
>>> 56, 48 & 40 bit shifts, since they are indeed wider than the type
>>> in the "!CONFIG_LBD on a 32bit arch" case.
>>>
>>>
>>> I must admit that I have no idear what the proper way to deal with
>>> that is, so I'll just report it so hopefully someone else can fix it.
>>>
>>> By the way; I'm building current Linus git tree, head at commit
>>> ac07860264bd2b18834d3fa3be47032115524cea
>
> Well, given that it's explicitly treating start_blk as a 64-bit value,
> the proper fix is probably to cast start_blk to an actual (guaranteed)
> 64-bit value. Untested, uncompiled, and someone else may disagree:
>
> Rene.
>
On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
> @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
> } else {
> c->Request.CDBLen = 16;
> c->Request.CDB[1]= 0;
> - c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
> - c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> - c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> - c->Request.CDB[5]= (start_blk >> 32) & 0xff;
> - c->Request.CDB[6]= (start_blk >> 24) & 0xff;
> - c->Request.CDB[7]= (start_blk >> 16) & 0xff;
> - c->Request.CDB[8]= (start_blk >> 8) & 0xff;
> + c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff; //MSB
> + c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
> + c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
> + c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
> + c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
> + c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
> + c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
put_unaligned(cpu_to_be64(start_blk), &c->Request.CDB[2]);
which is what's happening here anyway.
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..9fb6b3c 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -40,6 +40,7 @@
#include <linux/blktrace_api.h>
#include <asm/uaccess.h>
#include <asm/io.h>
+#include <asm/unaligned.h>
#include <linux/dma-mapping.h>
#include <linux/blkdev.h>
@@ -1711,10 +1712,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int ctlr, void *buff, size_
c->Request.Type.Direction = XFER_READ;
c->Request.Timeout = 0;
c->Request.CDB[0] = cmd;
- c->Request.CDB[6] = (size >> 24) & 0xFF; //MSB
- c->Request.CDB[7] = (size >> 16) & 0xFF;
- c->Request.CDB[8] = (size >> 8) & 0xFF;
- c->Request.CDB[9] = size & 0xFF;
+ put_unaligned(cpu_to_be32(size), &c->Request.CDB[6]);
break;
case CCISS_READ_CAPACITY:
@@ -1735,12 +1733,7 @@ static int fill_cmd(CommandList_struct *c, __u8 cmd, int ctlr, void *buff, size_
c->Request.Timeout = 0;
c->Request.CDB[0] = cmd;
c->Request.CDB[1] = 0x10;
- c->Request.CDB[10] = (size >> 24) & 0xFF;
- c->Request.CDB[11] = (size >> 16) & 0xFF;
- c->Request.CDB[12] = (size >> 8) & 0xFF;
- c->Request.CDB[13] = size & 0xFF;
- c->Request.Timeout = 0;
- c->Request.CDB[0] = cmd;
+ put_unaligned(cpu_to_be32(size), &c->Request.CDB[10]);
break;
case CCISS_CACHE_FLUSH:
c->Request.CDBLen = 12;
@@ -2598,29 +2591,15 @@ static void do_cciss_request(request_queue_t *q)
if (likely(blk_fs_request(creq))) {
if(h->cciss_read == CCISS_READ_10) {
c->Request.CDB[1] = 0;
- c->Request.CDB[2] = (start_blk >> 24) & 0xff; //MSB
- c->Request.CDB[3] = (start_blk >> 16) & 0xff;
- c->Request.CDB[4] = (start_blk >> 8) & 0xff;
- c->Request.CDB[5] = start_blk & 0xff;
- c->Request.CDB[6] = 0; // (sect >> 24) & 0xff; MSB
- c->Request.CDB[7] = (creq->nr_sectors >> 8) & 0xff;
- c->Request.CDB[8] = creq->nr_sectors & 0xff;
+ put_unaligned(cpu_to_be32(start_blk), &c->Request.CDB[2]);
+ c->Request.CDB[6] = 0;
+ put_unaligned(cpu_to_be16(creq->nr_sectors), &c->Request.CDB[7]);
c->Request.CDB[9] = c->Request.CDB[11] = c->Request.CDB[12] = 0;
} else {
c->Request.CDBLen = 16;
c->Request.CDB[1]= 0;
- c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
- c->Request.CDB[3]= (start_blk >> 48) & 0xff;
- c->Request.CDB[4]= (start_blk >> 40) & 0xff;
- c->Request.CDB[5]= (start_blk >> 32) & 0xff;
- c->Request.CDB[6]= (start_blk >> 24) & 0xff;
- c->Request.CDB[7]= (start_blk >> 16) & 0xff;
- c->Request.CDB[8]= (start_blk >> 8) & 0xff;
- c->Request.CDB[9]= start_blk & 0xff;
- c->Request.CDB[10]= (creq->nr_sectors >> 24) & 0xff;
- c->Request.CDB[11]= (creq->nr_sectors >> 16) & 0xff;
- c->Request.CDB[12]= (creq->nr_sectors >> 8) & 0xff;
- c->Request.CDB[13]= creq->nr_sectors & 0xff;
+ put_unaligned(cpu_to_be64(start_blk), &c->Request.CDB[2]);
+ put_unaligned(cpu_to_be32(creq->nr_sectors), &c->Request.CDB[10]);
c->Request.CDB[14] = c->Request.CDB[15] = 0;
}
} else if (blk_pc_request(creq)) {
On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:
> On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
> > @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
> > } else {
> > c->Request.CDBLen = 16;
> > c->Request.CDB[1]= 0;
> > - c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
> > - c->Request.CDB[3]= (start_blk >> 48) & 0xff;
> > - c->Request.CDB[4]= (start_blk >> 40) & 0xff;
> > - c->Request.CDB[5]= (start_blk >> 32) & 0xff;
> > - c->Request.CDB[6]= (start_blk >> 24) & 0xff;
> > - c->Request.CDB[7]= (start_blk >> 16) & 0xff;
> > - c->Request.CDB[8]= (start_blk >> 8) & 0xff;
> > + c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff; //MSB
> > + c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
> > + c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
> > + c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
> > + c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
> > + c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
> > + c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
>
> put_unaligned(cpu_to_be64(start_blk), &c->Request.CDB[2]);
>
> which is what's happening here anyway.
Well ... this was debated a while ago ad nauseam:
http://marc.info/?t=117699555300010
The main objection to what you propose is that it forces the u64
coercion even in the 32 bit start_blk case. The preferred solution as a
result of that debate was simply to us a macro Andrew introduced:
upper_32_bits()
Which will silently replace zero in the non LBD case. I actually
thought this had already been done.
James
James
On 08/12/2007 10:32 PM, James Bottomley wrote:
> On Sun, 2007-08-12 at 07:58 +0100, Al Viro wrote:
>> On Sun, Aug 12, 2007 at 03:21:57AM +0200, Rene Herman wrote:
>>> @@ -2609,13 +2609,13 @@ static void do_cciss_request(request_queue_t *q)
>>> } else {
>>> c->Request.CDBLen = 16;
>>> c->Request.CDB[1]= 0;
>>> - c->Request.CDB[2]= (start_blk >> 56) & 0xff; //MSB
>>> - c->Request.CDB[3]= (start_blk >> 48) & 0xff;
>>> - c->Request.CDB[4]= (start_blk >> 40) & 0xff;
>>> - c->Request.CDB[5]= (start_blk >> 32) & 0xff;
>>> - c->Request.CDB[6]= (start_blk >> 24) & 0xff;
>>> - c->Request.CDB[7]= (start_blk >> 16) & 0xff;
>>> - c->Request.CDB[8]= (start_blk >> 8) & 0xff;
>>> + c->Request.CDB[2]= ((u64)start_blk >> 56) & 0xff; //MSB
>>> + c->Request.CDB[3]= ((u64)start_blk >> 48) & 0xff;
>>> + c->Request.CDB[4]= ((u64)start_blk >> 40) & 0xff;
>>> + c->Request.CDB[5]= ((u64)start_blk >> 32) & 0xff;
>>> + c->Request.CDB[6]= ((u64)start_blk >> 24) & 0xff;
>>> + c->Request.CDB[7]= ((u64)start_blk >> 16) & 0xff;
>>> + c->Request.CDB[8]= ((u64)start_blk >> 8) & 0xff;
>> put_unaligned(cpu_to_be64(start_blk), &c->Request.CDB[2]);
>>
>> which is what's happening here anyway.
>
> Well ... this was debated a while ago ad nauseam:
>
> http://marc.info/?t=117699555300010
>
> The main objection to what you propose is that it forces the u64
> coercion even in the 32 bit start_blk case. The preferred solution as a
> result of that debate was simply to us a macro Andrew introduced:
>
> upper_32_bits()
>
> Which will silently replace zero in the non LBD case. I actually
> thought this had already been done.
I see. Will assume it's somewhere in the pipeline.
Rene.