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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
> 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
On Wed, Mar 07, 2018 at 12:25:14AM +0100, Arnd Bergmann wrote:
> On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <[email protected]> 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 <[email protected]>
> >> 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
On Wed, Feb 28, 2018 at 10:15 PM, Jason Gunthorpe <[email protected]> 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 <[email protected]>
>> 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
On Wed, Mar 7, 2018 at 12:45 AM, Jason Gunthorpe <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> >> 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
On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <[email protected]> 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
On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <[email protected]> wrote:
> On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <[email protected]> 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
On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote:
> On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <[email protected]> wrote:
> > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <[email protected]> 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 <[email protected]>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Wed, Mar 14, 2018 at 9:03 PM, Doug Ledford <[email protected]> wrote:
> On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote:
>> On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <[email protected]> wrote:
>> > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <[email protected]> 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
On Wed, 2018-03-14 at 21:16 +0100, Arnd Bergmann wrote:
> On Wed, Mar 14, 2018 at 9:03 PM, Doug Ledford <[email protected]> wrote:
> > On Tue, 2018-03-13 at 09:50 +0100, Arnd Bergmann wrote:
> > > On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann <[email protected]> wrote:
> > > > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann <[email protected]> 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 <[email protected]>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
On Wed, Mar 14, 2018 at 1:28 PM, Doug Ledford <[email protected]> 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
On Wed, 2018-03-14 at 13:31 -0700, Linus Torvalds wrote:
> On Wed, Mar 14, 2018 at 1:28 PM, Doug Ledford <[email protected]> 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 <[email protected]>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD