[1/2] infiniband: qplib_fp: fix pointer cast

Message ID 20180220205638.1959033-1-arnd@arndb.de
State Accepted
Commit 5388a508479d8b7e6d24fe5ca2645806d8e3d0f1
Headers show
Series
  • [1/2] infiniband: qplib_fp: fix pointer cast
Related show

Commit Message

Arnd Bergmann Feb. 20, 2018, 8:56 p.m.
Building for a 32-bit target results in a couple of warnings from casting between
a 32-bit pointer and a 64-bit integer:

drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq':
drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
    bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle,
                       ^
drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
            (struct bnxt_qplib_srq *)q_handle,
            ^
In file included from include/linux/byteorder/little_endian.h:5,
                 from arch/arm/include/uapi/asm/byteorder.h:22,
                 from include/asm-generic/bitops/le.h:6,
                 from arch/arm/include/asm/bitops.h:342,
                 from include/linux/bitops.h:38,
                 from include/linux/kernel.h:11,
                 from include/linux/interrupt.h:6,
                 from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39:
drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq':
include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
 #define __cpu_to_le64(x) ((__force __le64)(__u64)(x))
                                           ^
include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'
 #define cpu_to_le64 __cpu_to_le64
                     ^~~~~~~~~~~~~
drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64'
  req.srq_handle = cpu_to_le64(srq);

Using a uintptr_t as an intermediate works on all architectures.

Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

---
 drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.9.0

Comments

Jason Gunthorpe Feb. 28, 2018, 9:15 p.m. | #1
On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote:
> Building for a 32-bit target results in a couple of warnings from casting between

> a 32-bit pointer and a 64-bit integer:

> 

> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq':

> drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

>     bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle,

>                        ^

> drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

>             (struct bnxt_qplib_srq *)q_handle,

>             ^

> In file included from include/linux/byteorder/little_endian.h:5,

>                  from arch/arm/include/uapi/asm/byteorder.h:22,

>                  from include/asm-generic/bitops/le.h:6,

>                  from arch/arm/include/asm/bitops.h:342,

>                  from include/linux/bitops.h:38,

>                  from include/linux/kernel.h:11,

>                  from include/linux/interrupt.h:6,

>                  from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39:

> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq':

> include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

>  #define __cpu_to_le64(x) ((__force __le64)(__u64)(x))

>                                            ^

> include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'

>  #define cpu_to_le64 __cpu_to_le64

>                      ^~~~~~~~~~~~~

> drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64'

>   req.srq_handle = cpu_to_le64(srq);

> 

> Using a uintptr_t as an intermediate works on all architectures.

> 

> Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>  drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++--

>  1 file changed, 2 insertions(+), 2 deletions(-)


I applied the series to for-next, thanks

Jason
Arnd Bergmann March 6, 2018, 11:25 p.m. | #2
On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote:

>> Building for a 32-bit target results in a couple of warnings from casting between

>> a 32-bit pointer and a 64-bit integer:

>>

>> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq':

>> drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

>>     bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle,

>>                        ^

>> drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

>>             (struct bnxt_qplib_srq *)q_handle,

>>             ^

>> In file included from include/linux/byteorder/little_endian.h:5,

>>                  from arch/arm/include/uapi/asm/byteorder.h:22,

>>                  from include/asm-generic/bitops/le.h:6,

>>                  from arch/arm/include/asm/bitops.h:342,

>>                  from include/linux/bitops.h:38,

>>                  from include/linux/kernel.h:11,

>>                  from include/linux/interrupt.h:6,

>>                  from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39:

>> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq':

>> include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

>>  #define __cpu_to_le64(x) ((__force __le64)(__u64)(x))

>>                                            ^

>> include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'

>>  #define cpu_to_le64 __cpu_to_le64

>>                      ^~~~~~~~~~~~~

>> drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64'

>>   req.srq_handle = cpu_to_le64(srq);

>>

>> Using a uintptr_t as an intermediate works on all architectures.

>>

>> Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")

>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>>  drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++--

>>  1 file changed, 2 insertions(+), 2 deletions(-)

>

> I applied the series to for-next, thanks


Hi Jason,

kernelci still reports the warning for v4.16-rc, any chance you can also send it
as a bugfix for the current release?

      Arnd
Jason Gunthorpe March 6, 2018, 11:45 p.m. | #3
On Wed, Mar 07, 2018 at 12:25:14AM +0100, Arnd Bergmann wrote:
> On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote:

> > On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote:

> >> Building for a 32-bit target results in a couple of warnings from casting between

> >> a 32-bit pointer and a 64-bit integer:

> >>

> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq':

> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

> >>     bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle,

> >>                        ^

> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

> >>             (struct bnxt_qplib_srq *)q_handle,

> >>             ^

> >> In file included from include/linux/byteorder/little_endian.h:5,

> >>                  from arch/arm/include/uapi/asm/byteorder.h:22,

> >>                  from include/asm-generic/bitops/le.h:6,

> >>                  from arch/arm/include/asm/bitops.h:342,

> >>                  from include/linux/bitops.h:38,

> >>                  from include/linux/kernel.h:11,

> >>                  from include/linux/interrupt.h:6,

> >>                  from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39:

> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq':

> >> include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

> >>  #define __cpu_to_le64(x) ((__force __le64)(__u64)(x))

> >>                                            ^

> >> include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'

> >>  #define cpu_to_le64 __cpu_to_le64

> >>                      ^~~~~~~~~~~~~

> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64'

> >>   req.srq_handle = cpu_to_le64(srq);

> >>

> >> Using a uintptr_t as an intermediate works on all architectures.

> >>

> >> Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")

> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

> >>  drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++--

> >>  1 file changed, 2 insertions(+), 2 deletions(-)

> >

> > I applied the series to for-next, thanks

> 

> Hi Jason,

> 

> kernelci still reports the warning for v4.16-rc, any chance you can also send it

> as a bugfix for the current release?


As a general rule we haven't been sending sparse cleanups like this to
-rc which is why it went to -next..

Can you talk about why this is important to kernelci? I'm not familiar
at all with it.

I'm a little leary to duplicate a commit in both our branches without
a good reason??

Jason
Arnd Bergmann March 7, 2018, 9:05 a.m. | #4
On Wed, Mar 7, 2018 at 12:45 AM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Wed, Mar 07, 2018 at 12:25:14AM +0100, Arnd Bergmann wrote:

>> On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote:

>> > On Tue, Feb 20, 2018 at 09:56:26PM +0100, Arnd Bergmann wrote:

>> >> Building for a 32-bit target results in a couple of warnings from casting between

>> >> a 32-bit pointer and a 64-bit integer:

>> >>

>> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_service_nq':

>> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:333:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

>> >>     bnxt_qplib_arm_srq((struct bnxt_qplib_srq *)q_handle,

>> >>                        ^

>> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:336:12: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

>> >>             (struct bnxt_qplib_srq *)q_handle,

>> >>             ^

>> >> In file included from include/linux/byteorder/little_endian.h:5,

>> >>                  from arch/arm/include/uapi/asm/byteorder.h:22,

>> >>                  from include/asm-generic/bitops/le.h:6,

>> >>                  from arch/arm/include/asm/bitops.h:342,

>> >>                  from include/linux/bitops.h:38,

>> >>                  from include/linux/kernel.h:11,

>> >>                  from include/linux/interrupt.h:6,

>> >>                  from drivers/infiniband/hw/bnxt_re/qplib_fp.c:39:

>> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function 'bnxt_qplib_create_srq':

>> >> include/uapi/linux/byteorder/little_endian.h:31:43: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

>> >>  #define __cpu_to_le64(x) ((__force __le64)(__u64)(x))

>> >>                                            ^

>> >> include/linux/byteorder/generic.h:86:21: note: in expansion of macro '__cpu_to_le64'

>> >>  #define cpu_to_le64 __cpu_to_le64

>> >>                      ^~~~~~~~~~~~~

>> >> drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion of macro 'cpu_to_le64'

>> >>   req.srq_handle = cpu_to_le64(srq);

>> >>

>> >> Using a uintptr_t as an intermediate works on all architectures.

>> >>

>> >> Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters")

>> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

>> >>  drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++--

>> >>  1 file changed, 2 insertions(+), 2 deletions(-)

>> >

>> > I applied the series to for-next, thanks

>>

>> Hi Jason,

>>

>> kernelci still reports the warning for v4.16-rc, any chance you can also send it

>> as a bugfix for the current release?

>

> As a general rule we haven't been sending sparse cleanups like this to

> -rc which is why it went to -next..

>

> Can you talk about why this is important to kernelci? I'm not familiar

> at all with it.

>

> I'm a little leary to duplicate a commit in both our branches without

> a good reason??


I agree that we shouldn't do this for sparse warnings, but the one I'm
interested in is a compiler warning in the allmodconfig build, as
found by kernelci.org. This is one of only three remaining warnings
that it reports for any of the default builds, see [1] for the overall
build reports on mainline kernels, and [2] for the detailed log of
the arm64 allmodconfig build that shows it.

A small complication is that I wrote the changelog for the build warning
on 32-bit architectures, which is more elaborate. kernelci.org for
some reasons currently skips the allmodconfig build on all 32-bit
architectures (I should ask the kernelci maintainers to change that),
but the same patch I sent also addresses a warning on bit-endian
64-bit architectures:

../drivers/infiniband/hw/bnxt_re/qplib_fp.c: In function
'bnxt_qplib_create_srq':
../include/uapi/linux/byteorder/big_endian.h:31:52: warning: passing
argument 1 of '__fswab64' makes integer from pointer without a cast
[-Wint-conversion]
 #define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
                                                    ^
../include/uapi/linux/swab.h:132:12: note: in definition of macro '__swab64'
  __fswab64(x))
            ^
../include/linux/byteorder/generic.h:86:21: note: in expansion of
macro '__cpu_to_le64'
 #define cpu_to_le64 __cpu_to_le64
                     ^
../drivers/infiniband/hw/bnxt_re/qplib_fp.c:569:19: note: in expansion
of macro 'cpu_to_le64'
  req.srq_handle = cpu_to_le64(srq);
                   ^
../include/uapi/linux/swab.h:65:41: note: expected '__u64 {aka long
long unsigned int}' but argument is of type 'struct bnxt_qplib_srq *'
 static inline __attribute_const__ __u64 __fswab64(__u64 val)

On x86 and on the arm64 defconfig build, the __cpu_to_le64() is defined in
include/uapi/linux/byteorder/little_endian.h and degrades into a __force
cast that happens to avoid this warning, but on arm64 allmodconfig,
we use include/uapi/linux/byteorder/big_endian.h, which passes
the pointer into __swab64() first, and that warns about the type
mismatch.

       Arnd

[1] https://kernelci.org/build/mainline/branch/master/kernel/v4.16-rc4-123-g86f84779d8e9/
[2] https://storage.kernelci.org/mainline/master/v4.16-rc4-123-g86f84779d8e9/arm64/allmodconfig/build.log
Arnd Bergmann March 7, 2018, 10:12 a.m. | #5
On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> A small complication is that I wrote the changelog for the build warning

> on 32-bit architectures, which is more elaborate. kernelci.org for

> some reasons currently skips the allmodconfig build on all 32-bit

> architectures (I should ask the kernelci maintainers to change that),


I see that Olof's build bot does have build results for arm32
allmodconfig, which is also big-endian, and reports the same
errors that I described in the patch changelog.

See

http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/
http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed

for today's results.

This bot reports one other warning for arm32, but it's
specific to the toolchain version used on that bot.
I have a fix for that one as well, but there was some
discussion on what the best approach would be.

      Arnd
Arnd Bergmann March 13, 2018, 8:50 a.m. | #6
On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>

>> A small complication is that I wrote the changelog for the build warning

>> on 32-bit architectures, which is more elaborate. kernelci.org for

>> some reasons currently skips the allmodconfig build on all 32-bit

>> architectures (I should ask the kernelci maintainers to change that),

>

> I see that Olof's build bot does have build results for arm32

> allmodconfig, which is also big-endian, and reports the same

> errors that I described in the patch changelog.

>

> See

>

> http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/

> http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed

>

> for today's results.

>

> This bot reports one other warning for arm32, but it's

> specific to the toolchain version used on that bot.

> I have a fix for that one as well, but there was some

> discussion on what the best approach would be.


Any update on this? This is now the only remaining gcc warning we get on
allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc.


     Arnd
Doug Ledford March 14, 2018, 8:03 p.m. | #7
On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote:
> On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> > 

> > > A small complication is that I wrote the changelog for the build warning

> > > on 32-bit architectures, which is more elaborate. kernelci.org for

> > > some reasons currently skips the allmodconfig build on all 32-bit

> > > architectures (I should ask the kernelci maintainers to change that),

> > 

> > I see that Olof's build bot does have build results for arm32

> > allmodconfig, which is also big-endian, and reports the same

> > errors that I described in the patch changelog.

> > 

> > See

> > 

> > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/

> > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed

> > 

> > for today's results.

> > 

> > This bot reports one other warning for arm32, but it's

> > specific to the toolchain version used on that bot.

> > I have a fix for that one as well, but there was some

> > discussion on what the best approach would be.

> 

> Any update on this? This is now the only remaining gcc warning we get on

> allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc.

> 

> 

>      Arnd


Do you need the full series to fix this (it looked that way to me)?

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
Arnd Bergmann March 14, 2018, 8:16 p.m. | #8
On Wed, Mar 14, 2018 at 9:03 PM, Doug Ledford <dledford@redhat.com> wrote:
> On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote:

>> On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote:

>> >

>> > > A small complication is that I wrote the changelog for the build warning

>> > > on 32-bit architectures, which is more elaborate. kernelci.org for

>> > > some reasons currently skips the allmodconfig build on all 32-bit

>> > > architectures (I should ask the kernelci maintainers to change that),

>> >

>> > I see that Olof's build bot does have build results for arm32

>> > allmodconfig, which is also big-endian, and reports the same

>> > errors that I described in the patch changelog.

>> >

>> > See

>> >

>> > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/

>> > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed

>> >

>> > for today's results.

>> >

>> > This bot reports one other warning for arm32, but it's

>> > specific to the toolchain version used on that bot.

>> > I have a fix for that one as well, but there was some

>> > discussion on what the best approach would be.

>>

>> Any update on this? This is now the only remaining gcc warning we get on

>> allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc.

>>

>

> Do you need the full series to fix this (it looked that way to me)?


I just double-checked, as I thought only the first one was needed, but
indeed we do need both.

       Arnd
Doug Ledford March 14, 2018, 8:28 p.m. | #9
On Wed, 2018-03-14 at 21:16 +0100, Arnd Bergmann wrote:
> On Wed, Mar 14, 2018 at 9:03 PM, Doug Ledford <dledford@redhat.com> wrote:

> > On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote:

> > > On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> > > > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> > > > 

> > > > > A small complication is that I wrote the changelog for the build warning

> > > > > on 32-bit architectures, which is more elaborate. kernelci.org for

> > > > > some reasons currently skips the allmodconfig build on all 32-bit

> > > > > architectures (I should ask the kernelci maintainers to change that),

> > > > 

> > > > I see that Olof's build bot does have build results for arm32

> > > > allmodconfig, which is also big-endian, and reports the same

> > > > errors that I described in the patch changelog.

> > > > 

> > > > See

> > > > 

> > > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/

> > > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed

> > > > 

> > > > for today's results.

> > > > 

> > > > This bot reports one other warning for arm32, but it's

> > > > specific to the toolchain version used on that bot.

> > > > I have a fix for that one as well, but there was some

> > > > discussion on what the best approach would be.

> > > 

> > > Any update on this? This is now the only remaining gcc warning we get on

> > > allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc.

> > > 

> > 

> > Do you need the full series to fix this (it looked that way to me)?

> 

> I just double-checked, as I thought only the first one was needed, but

> indeed we do need both.


Hi Linus,

Arnd sent in a two patch series and it got put into our for-next branch.
 But, the two patches are the *only* two remaining issues for the arm
builds on the kernelci system.  They would like to get this into for-rc
so that the build failures stop.  Are you OK with me just cherry-picking 
them from for-next to for-rc so I can send them to you?  They'll show as
duplicates in the next merge window, but should drop silently.

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
Linus Torvalds March 14, 2018, 8:31 p.m. | #10
On Wed, Mar 14, 2018 at 1:28 PM, Doug Ledford <dledford@redhat.com> wrote:
>

> Arnd sent in a two patch series and it got put into our for-next branch.

>  But, the two patches are the *only* two remaining issues for the arm

> builds on the kernelci system.  They would like to get this into for-rc

> so that the build failures stop.  Are you OK with me just cherry-picking

> them from for-next to for-rc so I can send them to you?  They'll show as

> duplicates in the next merge window, but should drop silently.


Go ahead, assuming there are no other planned changes around them that
would cause potential pointless merge problems..

           Linus
Doug Ledford March 14, 2018, 9:01 p.m. | #11
On Wed, 2018-03-14 at 13:31 -0700, Linus Torvalds wrote:
> On Wed, Mar 14, 2018 at 1:28 PM, Doug Ledford <dledford@redhat.com> wrote:

> > 

> > Arnd sent in a two patch series and it got put into our for-next branch.

> >  But, the two patches are the *only* two remaining issues for the arm

> > builds on the kernelci system.  They would like to get this into for-rc

> > so that the build failures stop.  Are you OK with me just cherry-picking

> > them from for-next to for-rc so I can send them to you?  They'll show as

> > duplicates in the next merge window, but should drop silently.

> 

> Go ahead, assuming there are no other planned changes around them that

> would cause potential pointless merge problems..


These two patches will be fine in that regard.  They aren't in the area
where all the syzkaller bugs have been getting fixed.  But I need to
merge for-rc into for-next because of all of the syzkaller bugs being
fixed.  We are running into a situation where code updates that were
planned are in areas where syzkaller bugs have been fixed and there
would be significant merge conflicts if I didn't.  So, the plan as it
stands is: get the needed patches in for-rc, merge for-rc to for-next,
then cherry pick from for-next to for-rc just the two patches here
(since I have no idea how cherry picking to for-rc and then merging for-
rc to for-next would play out, I'm just not gonna try it).

It's a bit convoluted, but as long as I don't use my standard git
request pull macro when generating the pull request (it will pick the
wrong merge base every time whenever you've merged for-rc into for-next, 
you have to manually find the alternate merge base and use the right one
for git request pull) it comes out nicely in the end.

-- 
Doug Ledford <dledford@redhat.com>
    GPG KeyID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

Patch

diff --git a/drivers/infiniband/hw/bnxt_re/qplib_fp.c b/drivers/infiniband/hw/bnxt_re/qplib_fp.c
index 1b0e94697fe3..9885d7d428e3 100644
--- a/drivers/infiniband/hw/bnxt_re/qplib_fp.c
+++ b/drivers/infiniband/hw/bnxt_re/qplib_fp.c
@@ -283,7 +283,7 @@  static void bnxt_qplib_service_nq(unsigned long data)
 	u32 sw_cons, raw_cons;
 	u16 type;
 	int budget = nq->budget;
-	u64 q_handle;
+	uintptr_t q_handle;
 
 	/* Service the NQ until empty */
 	raw_cons = hwq->cons;
@@ -566,7 +566,7 @@  int bnxt_qplib_create_srq(struct bnxt_qplib_res *res,
 
 	/* Configure the request */
 	req.dpi = cpu_to_le32(srq->dpi->dpi);
-	req.srq_handle = cpu_to_le64(srq);
+	req.srq_handle = cpu_to_le64((uintptr_t)srq);
 
 	req.srq_size = cpu_to_le16((u16)srq->hwq.max_elements);
 	pbl = &srq->hwq.pbl[PBL_LVL_0];