[lkml]   [2019]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v4] scsi/ata: Use unsigned int for cmd's type in ioctls in scsi_host_template
On 26/01/2019 08:52, Nathan Chancellor wrote:

> Clang warns several times in the scsi subsystem (trimmed for brevity):
> drivers/scsi/hpsa.c:6209:7: warning: overflow converting case value to
> switch condition type (2147762695 to 18446744071562347015) [-Wswitch]
> ^
> drivers/scsi/hpsa.c:6208:7: warning: overflow converting case value to
> switch condition type (2147762694 to 18446744071562347014) [-Wswitch]
> ^
> The root cause is that the _IOC macro can generate really large numbers,
> which don't find into type 'int', which is used for the cmd paremeter in
^^^^ ^^^^^^^^^

"which don't fit"
"the cmd parameter"


> the ioctls in scsi_host_template. My research into how GCC and Clang are
> handling this at a low level didn't prove fruitful. However, looking at
> the rest of the kernel tree, all ioctls use an 'unsigned int' for the
> cmd parameter, which will fit all of the _IOC values in the scsi/ata
> subsystems.
> Make that change because none of the ioctls expect to take a negative
> value, it brings the ioctls inline with the reset of the kernel, and it
> removes ambiguity, which is never good when dealing with compilers.
> Link:
> Link:
> Link:
> Signed-off-by: Nathan Chancellor <>
> Reviewed-by: Bart Van Assche <>
> ---
> v3 -> v4:
> * Repost with Bart's suggested change and his reviewed by (mainly as an
> excuse to repost with the below comment).
> v2 -> v3:
> * Fix another -Wswitch warning from drivers/scsi/cxlflash/main.c, coming
> from decode_hioctl (uncovered via a powernv_defconfig build).
> v1 -> v2:
> * Fix build breakage in cxlflash driver from forgetting to update
> prototype (thanks to 0day for catching it).
> I apologize for resending this so soon after v3 but it has been three
> months since I sent this patch and I have yet to receive a single
> comment from ANY of the maintainers that './scripts/'
> spits out for this patch so it feels like I am sending it into the void.
> I understand you all are busy people and such and maybe I am being
> impatient but these warnings are rather spammy and we're trying to get
> that category cleaned up as quick as possible so that new warnings are
> easier to spot. I'd appreciate any and all reviews/acks/testing that I
> can get on this patch (especially since it is so simple) so it can be
> accepted and merged into mainline.

 \ /
  Last update: 2019-02-07 11:53    [W:0.136 / U:1.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site