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

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

[Arnd Bergmann]

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(-)

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];
-- 
2.9.0

[PATCH 2/2] infiniband: bnxt_re: use BIT_ULL() for 64-bit bit masks

[Arnd Bergmann]

On 32-bit targets, we otherwise get a warning about an impossible constant
integer expression:

In file included from include/linux/kernel.h:11,
                 from include/linux/interrupt.h:6,
                 from drivers/infiniband/hw/bnxt_re/ib_verbs.c:39:
drivers/infiniband/hw/bnxt_re/ib_verbs.c: In function 'bnxt_re_query_device':
include/linux/bitops.h:7:24: error: left shift count >= width of type [-Werror=shift-count-overflow]
 #define BIT(nr)   (1UL << (nr))
                        ^~
drivers/infiniband/hw/bnxt_re/bnxt_re.h:61:34: note: in expansion of macro 'BIT'
 #define BNXT_RE_MAX_MR_SIZE_HIGH BIT(39)
                                  ^~~
drivers/infiniband/hw/bnxt_re/bnxt_re.h:62:30: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE_HIGH'
 #define BNXT_RE_MAX_MR_SIZE  BNXT_RE_MAX_MR_SIZE_HIGH
                              ^~~~~~~~~~~~~~~~~~~~~~~~
drivers/infiniband/hw/bnxt_re/ib_verbs.c:149:25: note: in expansion of macro 'BNXT_RE_MAX_MR_SIZE'
  ib_attr->max_mr_size = BNXT_RE_MAX_MR_SIZE;
                         ^~~~~~~~~~~~~~~~~~~

Fixes: 872f3578241d ("RDMA/bnxt_re: Add support for MRs with Huge pages")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/infiniband/hw/bnxt_re/bnxt_re.h  | 4 ++--
 drivers/infiniband/hw/bnxt_re/ib_verbs.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/bnxt_re/bnxt_re.h b/drivers/infiniband/hw/bnxt_re/bnxt_re.h
index ca32057e886f..32dbde48f3e6 100644
--- a/drivers/infiniband/hw/bnxt_re/bnxt_re.h
+++ b/drivers/infiniband/hw/bnxt_re/bnxt_re.h
@@ -57,8 +57,8 @@
 #define BNXT_RE_PAGE_SIZE_8M		BIT(BNXT_RE_PAGE_SHIFT_8M)
 #define BNXT_RE_PAGE_SIZE_1G		BIT(BNXT_RE_PAGE_SHIFT_1G)
 
-#define BNXT_RE_MAX_MR_SIZE_LOW		BIT(BNXT_RE_PAGE_SHIFT_1G)
-#define BNXT_RE_MAX_MR_SIZE_HIGH	BIT(39)
+#define BNXT_RE_MAX_MR_SIZE_LOW		BIT_ULL(BNXT_RE_PAGE_SHIFT_1G)
+#define BNXT_RE_MAX_MR_SIZE_HIGH	BIT_ULL(39)
 #define BNXT_RE_MAX_MR_SIZE		BNXT_RE_MAX_MR_SIZE_HIGH
 
 #define BNXT_RE_MAX_QPC_COUNT		(64 * 1024)
diff --git a/drivers/infiniband/hw/bnxt_re/ib_verbs.c b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
index ae9e9ff54826..56878387c8f9 100644
--- a/drivers/infiniband/hw/bnxt_re/ib_verbs.c
+++ b/drivers/infiniband/hw/bnxt_re/ib_verbs.c
@@ -3548,7 +3548,7 @@ struct ib_mr *bnxt_re_reg_user_mr(struct ib_pd *ib_pd, u64 start, u64 length,
 	int umem_pgs, page_shift, rc;
 
 	if (length > BNXT_RE_MAX_MR_SIZE) {
-		dev_err(rdev_to_dev(rdev), "MR Size: %lld > Max supported:%ld\n",
+		dev_err(rdev_to_dev(rdev), "MR Size: %lld > Max supported:%lld\n",
 			length, BNXT_RE_MAX_MR_SIZE);
 		return ERR_PTR(-ENOMEM);
 	}
-- 
2.9.0

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

[Jason Gunthorpe]

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

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

[Arnd Bergmann]

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

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

[Jason Gunthorpe]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Arnd Bergmann]

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

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

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Linus Torvalds]

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

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

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]