lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49F74672.2090407@garzik.org>
Date:	Tue, 28 Apr 2009 14:09:54 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
CC:	Mark Lord <liml@....ca>, Tejun Heo <tj@...nel.org>,
	axboe@...nel.dk, linux-kernel@...r.kernel.org, donari75@...il.com,
	linux-ide@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH 2/3] mg_disk: fix CONFIG_LBD=y warning

Bartlomiej Zolnierkiewicz wrote:
> On Tuesday 28 April 2009 17:19:34 Mark Lord wrote:
>> Tejun Heo wrote:
>>> From: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
>>>
>>> drivers/block/mg_disk.c: In function ‘mg_dump_status’:
>>> drivers/block/mg_disk.c:265: warning: format ‘%ld’ expects type ‘long int’, but
>>> argument 2 has type ‘sector_t’
>>>
>>> [ Impact: kill build warning ]
>>>
>>> Cc: unsik Kim <donari75@...il.com>
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
>>> Signed-off-by: Tejun Heo <tj@...nel.org>
>>> ---
>>>  drivers/block/mg_disk.c |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/block/mg_disk.c b/drivers/block/mg_disk.c
>>> index d3e72ad..f389835 100644
>>> --- a/drivers/block/mg_disk.c
>>> +++ b/drivers/block/mg_disk.c
>>> @@ -79,7 +79,7 @@ static void mg_dump_status(const char *msg, unsigned int stat,
>>>  			if (host->breq) {
>>>  				req = elv_next_request(host->breq);
>>>  				if (req)
>>> -					printk(", sector=%ld", req->sector);
>>> +					printk(", sector=%u", (u32)req->sector);
>> ..
>>
>> Eh?  Shouldn't that be fixed the other way around, like this:
>>
>>   +					printk(", sector=%llu", (u64)req->sector);
>>
>> This way, it will still give correct data when sector_t is a u64.
> 
> shouldn't matter, req->sector is never > u32 for mg_disk

It never matters... until the code gets copied elsewhere.  IMO wrong 
code should never be kept -- "impossible to hit" just means it is low 
priority :)

	Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ