On Tue, Feb 23, 2021 at 11:50 AM Geert Uytterhoeven
wrote:
> If CONFIG_DEBUG_SG=y, and CONFIG_MMU=y:
>
> include/linux/scatterlist.h: In function ‘sg_set_buf’:
> arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of
> pointer with null pointer [-Wextra]
> 174 |
On 23/2/21 8:49 pm, Geert Uytterhoeven wrote:
If CONFIG_DEBUG_SG=y, and CONFIG_MMU=y:
include/linux/scatterlist.h: In function ‘sg_set_buf’:
arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
174 | #define
If CONFIG_DEBUG_SG=y, and CONFIG_MMU=y:
include/linux/scatterlist.h: In function ‘sg_set_buf’:
arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
174 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void
*)PAGE_OFFSET &&
The function prototype for the functions defined in ima.c for powerpc
are given in the header file ima.h. But this header file is not
included in ima.c resulting in compilation errors such as given below.
arch/powerpc/kexec/ima.c:56:5: error: no previous prototype for
'ima_get_kexec_buffer'
Lakshmi Ramasubramanian writes:
> The function prototype for the functions defined in ima.c for powerpc
> are given in the header file ima.h. But this header file is not
> included in ima.c resulting in compilation errors such as given below.
>
> arch/powerpc/kexec/ima.c:56:5: error: no
The function prototype for the functions defined in ima.c for powerpc
are given in the header file ima.h. But this header file is not
included in ima.c resulting in compilation errors such as given below.
arch/powerpc/kexec/ima.c:56:5: error: no previous prototype for
'ima_get_kexec_buffer'
Hi Lakshmi,
On Fri, 2020-11-13 at 11:22 -0800, Lakshmi Ramasubramanian wrote:
> The function prototype for the functions defined in ima.c for powerpc
> are given in the header file ima.h. But this header file is not
> included in ima.c resulting in compilation errors such as given below.
>
>
The function prototype for the functions defined in ima.c for powerpc
are given in the header file ima.h. But this header file is not
included in ima.c resulting in compilation errors such as given below.
arch/powerpc/kexec/ima.c:56:5: error: no previous prototype for
'ima_get_kexec_buffer'
On Tue, Jun 23, 2020 at 11:27 AM Valdis Klētnieks
wrote:
>
> On Mon, 22 Jun 2020 14:10:13 +0900, Masahiro Yamada said:
>
> > > This patch introduces a new build flag 'K=1' which controls whether
> > > kerneldoc
> > > warnings should be issued, separa
On Mon, 22 Jun 2020 14:10:13 +0900, Masahiro Yamada said:
> > This patch introduces a new build flag 'K=1' which controls whether
> > kerneldoc
> > warnings should be issued, separating them from the compiler warnings that
> > W=
> > controls.
> I do not und
On Sun, Jun 21, 2020 at 3:52 AM Valdis Klētnieks
wrote:
>
> This patch introduces a new build flag 'K=1' which controls whether kerneldoc
> warnings should be issued, separating them from the compiler warnings that W=
> controls.
I do not understand why this change is needed.
II
On Sat, 2020-06-20 at 14:52 -0400, Valdis Klētnieks wrote:
> This patch introduces a new build flag 'K=1' which controls whether kerneldoc
> warnings should be issued, separating them from the compiler warnings that W=
> controls.
[]
> diff --git a/Makefile b/Makefile
[]
> @@
This patch introduces a new build flag 'K=1' which controls whether kerneldoc
warnings should be issued, separating them from the compiler warnings that W=
controls.
Signed-off-by: Valdis Kletnieks
diff --git a/Makefile b/Makefile
index 29abe44ada91..b1c0f9484a66 100644
--- a/Makefile
+++ b
On Wed, 2020-05-13 at 15:53 +, David Laight wrote:
> > If we don't have pselect() we use the close() in the signal
> > handler. In that case we're just waiting in the read(), we're not
> > using select() or poll() or whatever. It's definitely the case
> > that if we're waiting in read() and
From: Paul Smith
> Sent: 13 May 2020 16:33
> On Wed, 2020-05-13 at 08:21 +, David Laight wrote:
...
> If we don't have pselect() we use the close() in the signal handler.
> In that case we're just waiting in the read(), we're not using select()
> or poll() or whatever. It's definitely the
On Wed, 2020-05-13 at 08:21 +, David Laight wrote:
> > GNU make uses pselect(), on systems that support it. On systems
> > that don't support pselect() it uses a trick I described in another
> > email: we dup() the FD, read() on the dup, then in the SIGCHLD
> > handler we close() the dup.
>
From: Paul Smith
> Sent: 12 May 2020 17:55
> On Tue, 2020-05-12 at 15:04 +, David Laight wrote:
> > I think there were some sub-makes that were started with make
> > instead of $(MAKE) so ended up creating a new job pipe.
>
> Oh, yes, that will do it.
>
> > Doesn't it do blocking reads with
On Tue, 2020-05-12 at 15:04 +, David Laight wrote:
> I think there were some sub-makes that were started with make
> instead of $(MAKE) so ended up creating a new job pipe.
Oh, yes, that will do it.
> Doesn't it do blocking reads with SIGCHLD enabled?
No, because it's racy (by itself).
>
From: Paul Smith
> Sent: 12 May 2020 15:36
> On Tue, 2020-05-12 at 07:55 +, David Laight wrote:
> > > One problem is ensuring that all the recursive makes actually
> > > use the same token queue.
> > > The Linux kernel build acts as though the sub-makes have their
> > > own queue - I certainly
On Tue, 2020-05-12 at 07:55 +, David Laight wrote:
> > One problem is ensuring that all the recursive makes actually
> > use the same token queue.
> > The Linux kernel build acts as though the sub-makes have their
> > own queue - I certainly had to fix that as well.
I don't understand this...
From: David Laight
> Sent: 11 May 2020 22:09
> From: Paul Smith
> > Sent: 11 May 2020 18:59
> > On Mon, 2020-05-11 at 10:41 -0700, Linus Torvalds wrote:
> > > On Mon, May 11, 2020 at 12:43 AM David Laight <
> > > david.lai...@aculab.com> wrote:
> > > >
> > > > I've not looked inside gmake, but I
From: Paul Smith
> Sent: 11 May 2020 18:59
> On Mon, 2020-05-11 at 10:41 -0700, Linus Torvalds wrote:
> > On Mon, May 11, 2020 at 12:43 AM David Laight <
> > david.lai...@aculab.com> wrote:
> > >
> > > I've not looked inside gmake, but I fixed nmake so that it
> > > properly used a single job
On Mon, 2020-05-11 at 12:33 -0700, Linus Torvalds wrote:
> I wonder if you could just have three different file descriptors:
>
> - the "current token file descriptor"
> - a /dev/null file descriptor
> - the jobserver pipe file descriptor. This is left blocking.
If I'm understanding your
On Mon, May 11, 2020 at 10:59 AM Paul Smith wrote:
>
> As with all single-threaded applications, though, the problem is the
> difficulty (in a portable way) of handling both signals and wait*(2)
> reliably...
I do wonder if GNU make isn't making it worse for itself by blocking SIGCHLD.
I wonder
On Mon, 2020-05-11 at 10:41 -0700, Linus Torvalds wrote:
> On Mon, May 11, 2020 at 12:43 AM David Laight <
> david.lai...@aculab.com> wrote:
> >
> > I've not looked inside gmake, but I fixed nmake so that it
> > properly used a single job token pipe for the entire (NetBSD)
> > build and then
On Mon, May 11, 2020 at 12:43 AM David Laight wrote:
>
> I've not looked inside gmake, but I fixed nmake so that it
> properly used a single job token pipe for the entire (NetBSD)
> build and then flushed and refilled it with 'abort' tokens
> when any command failed.
> That made the build stop
On Mon, May 11, 2020 at 11:03 AM Arnd Bergmann wrote:
>
> - There is a good chance that some trivial difference between
> mainline and linux-next, or between linux-next and my test
> branch (with a couple hundred fixup patches) is causing you
> to see many warnings that I don't get. I'll
On Sun, May 10, 2020 at 9:33 PM Linus Torvalds
wrote:
>
> So I don't think those parts are at all controversial. We'll get the
> zero-sized arrays converted, and then we'll have another slew of
> one-sized array declarations that will also have to be taken care of,
> but I hope we can re-enable
From: Linus Torvalds
> Sent: 10 May 2020 20:33
...
> And as part of that, there were a lot of new warnings in the kernel build.
>
> I let them go for a while, in the belief that I could deal with it,
> but then yesterday I did a pull and didn't initially even notice that
> the end result didn't
Arnd, Masahiro, (anybody else?),
I don't know how much you care - I thought at least Arnd might - but
I've upgraded my main desktop to gcc-10. I did that partly because a
bug report that initially seemed to blame the compiler, but eventually
turned out to be unrelated.
And as part of that,
From: Christian Borntraeger
[ Upstream commit 062795fcdcb2d22822fb42644b1d76a8ad8439b3 ]
Depending on inlining decisions by the compiler, __get/put_user_fn
might become out of line. Then the compiler is no longer able to tell
that size can only be 1,2,4 or 8 due to the check in __get/put_user
From: Christian Borntraeger
[ Upstream commit 062795fcdcb2d22822fb42644b1d76a8ad8439b3 ]
Depending on inlining decisions by the compiler, __get/put_user_fn
might become out of line. Then the compiler is no longer able to tell
that size can only be 1,2,4 or 8 due to the check in __get/put_user
From: Christian Borntraeger
[ Upstream commit 062795fcdcb2d22822fb42644b1d76a8ad8439b3 ]
Depending on inlining decisions by the compiler, __get/put_user_fn
might become out of line. Then the compiler is no longer able to tell
that size can only be 1,2,4 or 8 due to the check in __get/put_user
From: Christian Borntraeger
[ Upstream commit 062795fcdcb2d22822fb42644b1d76a8ad8439b3 ]
Depending on inlining decisions by the compiler, __get/put_user_fn
might become out of line. Then the compiler is no longer able to tell
that size can only be 1,2,4 or 8 due to the check in __get/put_user
From: Jason Gerecke
[ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ]
Addresses a few issues that were noticed when compiling with non-default
warnings enabled. The trimmed-down warnings in the order they are fixed
below are:
* declaration of 'size' shadows a parameter
* '%s'
From: Jason Gerecke
[ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ]
Addresses a few issues that were noticed when compiling with non-default
warnings enabled. The trimmed-down warnings in the order they are fixed
below are:
* declaration of 'size' shadows a parameter
* '%s'
From: Jason Gerecke
[ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ]
Addresses a few issues that were noticed when compiling with non-default
warnings enabled. The trimmed-down warnings in the order they are fixed
below are:
* declaration of 'size' shadows a parameter
* '%s'
From: Finn Thain
[ Upstream commit 94c04390225bcd8283103fd0c04be20cc30cc979 ]
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/m
From: Finn Thain
[ Upstream commit 94c04390225bcd8283103fd0c04be20cc30cc979 ]
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/m
From: Finn Thain
[ Upstream commit 94c04390225bcd8283103fd0c04be20cc30cc979 ]
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/m
From: Jason Gerecke
[ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ]
Addresses a few issues that were noticed when compiling with non-default
warnings enabled. The trimmed-down warnings in the order they are fixed
below are:
* declaration of 'size' shadows a parameter
* '%s'
From: Jason Gerecke
[ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ]
Addresses a few issues that were noticed when compiling with non-default
warnings enabled. The trimmed-down warnings in the order they are fixed
below are:
* declaration of 'size' shadows a parameter
* '%s'
From: Jason Gerecke
[ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ]
Addresses a few issues that were noticed when compiling with non-default
warnings enabled. The trimmed-down warnings in the order they are fixed
below are:
* declaration of 'size' shadows a parameter
* '%s'
From: Finn Thain
[ Upstream commit 94c04390225bcd8283103fd0c04be20cc30cc979 ]
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/m
From: Finn Thain
[ Upstream commit 94c04390225bcd8283103fd0c04be20cc30cc979 ]
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/m
From: Finn Thain
[ Upstream commit 94c04390225bcd8283103fd0c04be20cc30cc979 ]
Since commit d3b41b6bb49e ("m68k: Dispatch nvram_ops calls to Atari or
Mac functions"), Coldfire builds generate compiler warnings due to the
unconditional inclusion of asm/atarihw.h and asm/m
3.16.74-rc1 review patch. If anyone has any objections, please let me know.
--
From: Kees Cook
commit a147faa96f832f76e772b1e448e94ea84c774081 upstream.
This fixes the various compiler warnings when building the msgque
selftest. The primary change is using sys/msg.h instead
On Tue, 17 Sep 2019, David Rientjes wrote:
> Acked-by: David Rientjes
Ditto
On Tue, 17 Sep 2019, David Rientjes wrote:
> On Tue, 17 Sep 2019, Qian Cai wrote:
>
> > tid_to_cpu() and tid_to_event() are only used in note_cmpxchg_failure()
> > when SLUB_DEBUG_CMPXCHG=y, so when SLUB_DEBUG_CMPXCHG=n by default,
> > Clang will complain that those unused functions.
> >
> >
On Tue, 17 Sep 2019, Qian Cai wrote:
> tid_to_cpu() and tid_to_event() are only used in note_cmpxchg_failure()
> when SLUB_DEBUG_CMPXCHG=y, so when SLUB_DEBUG_CMPXCHG=n by default,
> Clang will complain that those unused functions.
>
> Signed-off-by: Qian Cai
Acked-by: David Rientjes
tid_to_cpu() and tid_to_event() are only used in note_cmpxchg_failure()
when SLUB_DEBUG_CMPXCHG=y, so when SLUB_DEBUG_CMPXCHG=n by default,
Clang will complain that those unused functions.
Signed-off-by: Qian Cai
---
mm/slub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/slub.c
From: Joe Perches
> Sent: 27 August 2019 19:33
> On Tue, 2019-08-27 at 19:59 +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 27, 2019 at 7:46 PM Al Viro wrote:
> > > On Tue, Aug 27, 2019 at 07:29:52PM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Aug 27, 2019 at 4:17 PM David Laight
> > > >
On Tue, 2019-08-27 at 19:59 +0200, Geert Uytterhoeven wrote:
> On Tue, Aug 27, 2019 at 7:46 PM Al Viro wrote:
> > On Tue, Aug 27, 2019 at 07:29:52PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Aug 27, 2019 at 4:17 PM David Laight
> > > wrote:
> > > > From: Geert Uytterhoeven
> > > > > Sent:
Hi Al,
On Tue, Aug 27, 2019 at 7:46 PM Al Viro wrote:
> On Tue, Aug 27, 2019 at 07:29:52PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 27, 2019 at 4:17 PM David Laight
> > wrote:
> > > From: Geert Uytterhoeven
> > > > Sent: 19 August 2019 18:15
> > > ...
> > > > > I think a cast to
On Tue, Aug 27, 2019 at 07:29:52PM +0200, Geert Uytterhoeven wrote:
> Hi David,
>
> On Tue, Aug 27, 2019 at 4:17 PM David Laight wrote:
> > From: Geert Uytterhoeven
> > > Sent: 19 August 2019 18:15
> > ...
> > > > I think a cast to unsigned long is rather more common.
> > > >
> > > > uintptr_t
Hi David,
On Tue, Aug 27, 2019 at 4:17 PM David Laight wrote:
> From: Geert Uytterhoeven
> > Sent: 19 August 2019 18:15
> ...
> > > I think a cast to unsigned long is rather more common.
> > >
> > > uintptr_t is used ~1300 times in the kernel.
> > > I believe a cast to unsigned long is much more
From: Geert Uytterhoeven
> Sent: 19 August 2019 18:15
...
> > I think a cast to unsigned long is rather more common.
> >
> > uintptr_t is used ~1300 times in the kernel.
> > I believe a cast to unsigned long is much more common.
>
> That is true, as uintptr_t was introduced in C99.
> Similarly,
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
compilers insist
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
compilers insist
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
compilers insist
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
compilers insist
From: Qian Cai
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
On Mon, Aug 19, 2019 at 09:40:10PM +, Bernard Metzler wrote:
> >It is either an iova & lkey pair, or SGE information is inlined into
> >the WR ring.
> >
> In siw, the reference to any type of memory is kept uninterpreted
> in the send/receive queue until it gets accessed by a data
> transfer.
gt;> >Date: 08/19/2019 06:35PM
>> >Cc: "Geert Uytterhoeven" , "Doug Ledford"
>> >, linux-r...@vger.kernel.org,
>> >linux-kernel@vger.kernel.org
>> >Subject: [EXTERNAL] Re: Re: Re: Re: Re: [PATCH] RDMA/siw: Fix
>> >compiler warnings on 32-
rg,
> >linux-kernel@vger.kernel.org
> >Subject: [EXTERNAL] Re: Re: Re: Re: Re: [PATCH] RDMA/siw: Fix
> >compiler warnings on 32-bit due to u64/pointer abuse
> >
> >On Mon, Aug 19, 2019 at 04:29:11PM +, Bernard Metzler wrote:
> >>
> >> >To: &qu
gt;> >Date: 08/19/2019 06:05PM
>> >Cc: "Geert Uytterhoeven" , "Doug Ledford"
>> >, linux-r...@vger.kernel.org,
>> >linux-kernel@vger.kernel.org
>> >Subject: [EXTERNAL] Re: Re: Re: Re: [PATCH] RDMA/siw: Fix compiler
>> >warnings on 32-bit
erhoeven"
>Date: 08/19/2019 07:15PM
>Cc: "Bernard Metzler" , "Doug Ledford"
>, "Jason Gunthorpe" , "linux-rdma"
>, "Linux Kernel Mailing List"
>
>Subject: [EXTERNAL] Re: [PATCH] RDMA/siw: Fix compiler warnings on
>32-bit du
Hi Joe,
On Mon, Aug 19, 2019 at 6:56 PM Joe Perches wrote:
> On Mon, 2019-08-19 at 12:05 +0200, Geert Uytterhoeven wrote:
> > When compiling on 32-bit:
> >
> > drivers/infiniband/sw/siw/siw_cq.c:76:20: warning: cast to pointer from
> > integer of different size [-Wint-to-pointer-cast]
> >
On Mon, 2019-08-19 at 12:05 +0200, Geert Uytterhoeven wrote:
> When compiling on 32-bit:
>
> drivers/infiniband/sw/siw/siw_cq.c:76:20: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> drivers/infiniband/sw/siw/siw_qp.c:952:28: warning: cast from pointer
rg,
> >linux-kernel@vger.kernel.org
> >Subject: [EXTERNAL] Re: Re: Re: Re: [PATCH] RDMA/siw: Fix compiler
> >warnings on 32-bit due to u64/pointer abuse
> >
> >On Mon, Aug 19, 2019 at 03:54:56PM +, Bernard Metzler wrote:
> >
> >> Absolutely. But th
-"Jason Gunthorpe" wrote: -
>To: "Bernard Metzler"
>From: "Jason Gunthorpe"
>Date: 08/19/2019 06:05PM
>Cc: "Geert Uytterhoeven" , "Doug Ledford"
>, linux-r...@vger.kernel.org,
>linux-kernel@vger.kernel.org
>Subje
On Mon, Aug 19, 2019 at 03:54:56PM +, Bernard Metzler wrote:
> Absolutely. But these addresses are conveyed through the
> API as unsigned 64 during post_send(), and land in the siw
> send queue as is. During send queue processing, these addresses
> must be interpreted according to its context
-"Jason Gunthorpe" wrote: -
>To: "Bernard Metzler"
>From: "Jason Gunthorpe"
>Date: 08/19/2019 05:07PM
>Cc: "Geert Uytterhoeven" , "Doug Ledford"
>, linux-r...@vger.kernel.org,
>linux-kernel@vger.kernel.org
>Subject
el.org,
> >linux-kernel@vger.kernel.org
> >Subject: [EXTERNAL] Re: Re: Re: [PATCH] RDMA/siw: Fix compiler
> >warnings on 32-bit due to u64/pointer abuse
> >
> >On Mon, Aug 19, 2019 at 02:15:36PM +, Bernard Metzler wrote:
> >>
> >> >To: &qu
-"Jason Gunthorpe" wrote: -
>To: "Bernard Metzler"
>From: "Jason Gunthorpe"
>Date: 08/19/2019 04:19PM
>Cc: "Geert Uytterhoeven" , "Doug Ledford"
>, linux-r...@vger.kernel.org,
>linux-kernel@vger.kernel.org
>Subject
rg,
> >linux-kernel@vger.kernel.org
> >Subject: [EXTERNAL] Re: Re: [PATCH] RDMA/siw: Fix compiler warnings
> >on 32-bit due to u64/pointer abuse
> >
> >On Mon, Aug 19, 2019 at 01:36:11PM +, Bernard Metzler wrote:
> >> >If the value is really a kernel po
-"Jason Gunthorpe" wrote: -
>To: "Bernard Metzler"
>From: "Jason Gunthorpe"
>Date: 08/19/2019 03:52PM
>Cc: "Geert Uytterhoeven" , "Doug Ledford"
>, linux-r...@vger.kernel.org,
>linux-kernel@vger.kernel.org
>Subject
On Mon, Aug 19, 2019 at 01:36:11PM +, Bernard Metzler wrote:
> >If the value is really a kernel pointer, then it ought to be printed
> >with %p. We have been getting demanding on this point lately in RDMA
> >to enforce the ability to keep kernel pointers secret.
> >
> >> -
-"Jason Gunthorpe" wrote: -
>To: "Geert Uytterhoeven"
>From: "Jason Gunthorpe"
>Date: 08/19/2019 02:25PM
>Cc: "Bernard Metzler" , "Doug Ledford"
>, linux-r...@vger.kernel.org,
>linux-kernel@vger.kernel.org
>Subject
On Mon, Aug 19, 2019 at 12:05:26PM +0200, Geert Uytterhoeven wrote:
> When compiling on 32-bit:
>
> drivers/infiniband/sw/siw/siw_cq.c:76:20: warning: cast to pointer from
> integer of different size [-Wint-to-pointer-cast]
> drivers/infiniband/sw/siw/siw_qp.c:952:28: warning: cast from
lls to Atari or
> >>> Mac functions"), Coldfire builds generate compiler warnings due to the
> >>> unconditional inclusion of asm/atarihw.h and asm/macintosh.h.
> >>>
> >>> The inclusion of asm/atarihw.h causes warnings like this:
> >>>
&g
When compiling on 32-bit:
drivers/infiniband/sw/siw/siw_cq.c:76:20: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
drivers/infiniband/sw/siw/siw_qp.c:952:28: warning: cast from pointer to
integer of different size [-Wpointer-to-int-cast]
On Mon, Aug 12, 2019 at 09:47:40PM +, Luck, Tony wrote:
> > this little series fixes various warnings I see in ia64 builds.
>
> Applied. Thanks.
>
> [I assume you are using some up-to-date version of gcc that generates these
> warnings ... I'm not seeing them, but I'm still using a compiler
> this little series fixes various warnings I see in ia64 builds.
Applied. Thanks.
[I assume you are using some up-to-date version of gcc that generates these
warnings ... I'm not seeing them, but I'm still using a compiler from the stone
age]
-Tony
Hi Tony,
this little series fixes various warnings I see in ia64 builds.
On Wed, Aug 07, 2019 at 07:50:43AM -0400, Qian Cai wrote:
>
>
> > On Aug 7, 2019, at 6:56 AM, Will Deacon wrote:
> >
> > On Tue, Aug 06, 2019 at 03:34:34PM -0400, Qian Cai wrote:
> >> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> >> index 876055e37352..a0c495a3f4fd
> On Aug 7, 2019, at 6:56 AM, Will Deacon wrote:
>
> On Tue, Aug 06, 2019 at 03:34:34PM -0400, Qian Cai wrote:
>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>> index 876055e37352..a0c495a3f4fd 100644
>> --- a/arch/arm64/kernel/cpuinfo.c
>> +++
On Tue, Aug 06, 2019 at 03:34:34PM -0400, Qian Cai wrote:
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 876055e37352..a0c495a3f4fd 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -34,10 +34,7 @@ DEFINE_PER_CPU(struct
On Tue, Aug 06, 2019 at 03:34:34PM -0400, Qian Cai wrote:
> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> VIVT I-caches") introduced some compiation warnings from GCC (and
> Clang),
>
> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
> overwritten
From: Qian Cai
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
From: Qian Cai
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
From: Qian Cai
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
From: Qian Cai
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
From: Qian Cai
[ Upstream commit cbedfe11347fe418621bd188d58a206beb676218 ]
Commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
VIVT I-caches") introduced some compiation warnings from GCC (and
Clang),
arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
overwritten [-Woverride-init]
[ICACHE_POLICY_VIPT] = "VIPT",
On Mon, Aug 05, 2019 at 11:50:03PM -0400, Qian Cai wrote:
>
>
> > On Aug 5, 2019, at 10:01 AM, Will Deacon wrote:
> >
> > On Mon, Aug 05, 2019 at 07:47:37AM -0400, Qian Cai wrote:
> >>
> >>
> >>> On Aug 5, 2019, at 5:52 AM, Will Deacon wrote:
> >>>
> >>> On Fri, Aug 02, 2019 at 11:32:24AM
> On Aug 5, 2019, at 10:01 AM, Will Deacon wrote:
>
> On Mon, Aug 05, 2019 at 07:47:37AM -0400, Qian Cai wrote:
>>
>>
>>> On Aug 5, 2019, at 5:52 AM, Will Deacon wrote:
>>>
>>> On Fri, Aug 02, 2019 at 11:32:24AM -0400, Qian Cai wrote:
The commit 155433cb365e ("arm64: cache: Remove
On Mon, Aug 05, 2019 at 07:47:37AM -0400, Qian Cai wrote:
>
>
> > On Aug 5, 2019, at 5:52 AM, Will Deacon wrote:
> >
> > On Fri, Aug 02, 2019 at 11:32:24AM -0400, Qian Cai wrote:
> >> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
> >> VIVT I-caches") introduced some
[ Upstream commit ec6335586953b0df32f83ef696002063090c7aef ]
There are many compiler warnings like this,
In file included from ./arch/x86/include/asm/smp.h:13,
from ./arch/x86/include/asm/mmzone_64.h:11,
from ./arch/x86/include/asm/mmzone.h:5
[ Upstream commit ec6335586953b0df32f83ef696002063090c7aef ]
There are many compiler warnings like this,
In file included from ./arch/x86/include/asm/smp.h:13,
from ./arch/x86/include/asm/mmzone_64.h:11,
from ./arch/x86/include/asm/mmzone.h:5
1 - 100 of 638 matches
Mail list logo
