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  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]
Date:   Fri, 8 Feb 2019 00:05:01 -0800
From:   Christoph Hellwig <>
To:     Nathan Chancellor <>
Cc:     Jens Axboe <>,
        "James E.J. Bottomley" <>,
        "Martin K. Petersen" <>,
        "Manoj N. Kumar" <>,
        "Matthew R. Ochs" <>,
        Uma Krishnan <>,
        Brian King <>,
        Adaptec OEM Raid Solutions <>,
        Marc Gonzalez <>,,,,,
        Bradley Grove <>,
        Don Brace <>,
        Bart Van Assche <>,
        Nick Desaulniers <>
Subject: Re: [PATCH v5] scsi/ata: Use unsigned int for cmd's type in ioctls
 in scsi_host_template

On Thu, Feb 07, 2019 at 09:07:20AM -0700, 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]
>         case CCISS_GETBUSTYPES:
>              ^
> drivers/scsi/hpsa.c:6208:7: warning: overflow converting case value to
> switch condition type (2147762694 to 18446744071562347014) [-Wswitch]
>         case CCISS_GETHEARTBEAT:
>              ^
> The root cause is that the _IOC macro can generate really large numbers,
> which don't fit into type 'int', which is used for the cmd parameter in
> 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 a negative value for
> any command, 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 <>
> Acked-by: Bradley Grove <>
> Acked-by: Don Brace <>
> Reviewed-by: Bart Van Assche <>
> Tested-by: Nick Desaulniers <>

Looks good:

Reviewed-by: Christoph Hellwig <>

Powered by blists - more mailing lists