* linux-next: build warnings after merge of the block tree
@ 2013-11-26 2:29 Stephen Rothwell
2013-11-26 3:35 ` Stephen Rothwell
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2013-11-26 2:29 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Kent Overstreet
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
Hi Jens,
After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:
block/blk-merge.c: In function 'blk_rq_map_sg':
block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:171:23: note: 'bvprv.bv_len' was declared here
block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:171:23: note: 'bvprv.bv_page' was declared here
block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:171:23: note: 'bvprv.bv_offset' was declared here
block/blk-merge.c: In function 'blk_bio_map_sg':
block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:233:23: note: 'bvprv.bv_len' was declared here
block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:233:23: note: 'bvprv.bv_offset' was declared here
block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:233:23: note: 'bvprv.bv_page' was declared here
block/blk-merge.c: In function 'attempt_merge':
block/blk-merge.c:108:7: warning: 'end_bv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:89:17: note: 'end_bv.bv_offset' was declared here
block/blk-merge.c:108:7: warning: 'end_bv.bv_page' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:89:17: note: 'end_bv.bv_page' was declared here
block/blk-merge.c:108:7: warning: 'end_bv.bv_len' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:89:17: note: 'end_bv.bv_len' was declared here
arm has its own definition of BIOVEC_PHYS_MERGEABLE() if that is relevant.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2013-11-26 2:29 linux-next: build warnings after merge of the block tree Stephen Rothwell
@ 2013-11-26 3:35 ` Stephen Rothwell
2013-11-26 19:01 ` Olof Johansson
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2013-11-26 3:35 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Kent Overstreet
[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]
Hi all,
On Tue, 26 Nov 2013 13:29:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> block/blk-merge.c: In function 'blk_rq_map_sg':
> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:171:23: note: 'bvprv.bv_len' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:171:23: note: 'bvprv.bv_page' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:171:23: note: 'bvprv.bv_offset' was declared here
> block/blk-merge.c: In function 'blk_bio_map_sg':
> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:233:23: note: 'bvprv.bv_len' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:233:23: note: 'bvprv.bv_offset' was declared here
> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:233:23: note: 'bvprv.bv_page' was declared here
> block/blk-merge.c: In function 'attempt_merge':
> block/blk-merge.c:108:7: warning: 'end_bv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:89:17: note: 'end_bv.bv_offset' was declared here
> block/blk-merge.c:108:7: warning: 'end_bv.bv_page' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:89:17: note: 'end_bv.bv_page' was declared here
> block/blk-merge.c:108:7: warning: 'end_bv.bv_len' may be used uninitialized in this function [-Wuninitialized]
> block/blk-merge.c:89:17: note: 'end_bv.bv_len' was declared here
>
> arm has its own definition of BIOVEC_PHYS_MERGEABLE() if that is relevant.
For an easier test case, the i386 defcongig does this as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2013-11-26 3:35 ` Stephen Rothwell
@ 2013-11-26 19:01 ` Olof Johansson
2013-11-26 19:02 ` Jens Axboe
0 siblings, 1 reply; 42+ messages in thread
From: Olof Johansson @ 2013-11-26 19:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Jens Axboe, linux-next, linux-kernel, Kent Overstreet
On Mon, Nov 25, 2013 at 7:35 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Tue, 26 Nov 2013 13:29:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the block tree, today's linux-next build (arm
>> multi_v7_defconfig) produced these warnings:
>>
>> block/blk-merge.c: In function 'blk_rq_map_sg':
>> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:171:23: note: 'bvprv.bv_len' was declared here
>> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:171:23: note: 'bvprv.bv_page' was declared here
>> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:171:23: note: 'bvprv.bv_offset' was declared here
>> block/blk-merge.c: In function 'blk_bio_map_sg':
>> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:233:23: note: 'bvprv.bv_len' was declared here
>> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:233:23: note: 'bvprv.bv_offset' was declared here
>> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:233:23: note: 'bvprv.bv_page' was declared here
>> block/blk-merge.c: In function 'attempt_merge':
>> block/blk-merge.c:108:7: warning: 'end_bv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:89:17: note: 'end_bv.bv_offset' was declared here
>> block/blk-merge.c:108:7: warning: 'end_bv.bv_page' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:89:17: note: 'end_bv.bv_page' was declared here
>> block/blk-merge.c:108:7: warning: 'end_bv.bv_len' may be used uninitialized in this function [-Wuninitialized]
>> block/blk-merge.c:89:17: note: 'end_bv.bv_len' was declared here
>>
>> arm has its own definition of BIOVEC_PHYS_MERGEABLE() if that is relevant.
>
> For an easier test case, the i386 defcongig does this as well.
I just noticed that i see this with gcc 4.7.0, but 4.8.1 does not warn.
-Olof
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2013-11-26 19:01 ` Olof Johansson
@ 2013-11-26 19:02 ` Jens Axboe
2013-11-27 0:39 ` [PATCH] block: Silence spurious compiler warnings Kent Overstreet
0 siblings, 1 reply; 42+ messages in thread
From: Jens Axboe @ 2013-11-26 19:02 UTC (permalink / raw)
To: Olof Johansson, Stephen Rothwell
Cc: linux-next, linux-kernel, Kent Overstreet
On 11/26/2013 12:01 PM, Olof Johansson wrote:
> On Mon, Nov 25, 2013 at 7:35 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> On Tue, 26 Nov 2013 13:29:46 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> After merging the block tree, today's linux-next build (arm
>>> multi_v7_defconfig) produced these warnings:
>>>
>>> block/blk-merge.c: In function 'blk_rq_map_sg':
>>> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:171:23: note: 'bvprv.bv_len' was declared here
>>> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:171:23: note: 'bvprv.bv_page' was declared here
>>> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:171:23: note: 'bvprv.bv_offset' was declared here
>>> block/blk-merge.c: In function 'blk_bio_map_sg':
>>> block/blk-merge.c:133:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:233:23: note: 'bvprv.bv_len' was declared here
>>> block/blk-merge.c:133:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:233:23: note: 'bvprv.bv_offset' was declared here
>>> block/blk-merge.c:133:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:233:23: note: 'bvprv.bv_page' was declared here
>>> block/blk-merge.c: In function 'attempt_merge':
>>> block/blk-merge.c:108:7: warning: 'end_bv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:89:17: note: 'end_bv.bv_offset' was declared here
>>> block/blk-merge.c:108:7: warning: 'end_bv.bv_page' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:89:17: note: 'end_bv.bv_page' was declared here
>>> block/blk-merge.c:108:7: warning: 'end_bv.bv_len' may be used uninitialized in this function [-Wuninitialized]
>>> block/blk-merge.c:89:17: note: 'end_bv.bv_len' was declared here
>>>
>>> arm has its own definition of BIOVEC_PHYS_MERGEABLE() if that is relevant.
>>
>> For an easier test case, the i386 defcongig does this as well.
>
> I just noticed that i see this with gcc 4.7.0, but 4.8.1 does not warn.
That's good, because it's not a bug. But arguably we should shut up 4.7
as well, however...
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH] block: Silence spurious compiler warnings
2013-11-26 19:02 ` Jens Axboe
@ 2013-11-27 0:39 ` Kent Overstreet
2013-11-28 0:50 ` Stephen Rothwell
0 siblings, 1 reply; 42+ messages in thread
From: Kent Overstreet @ 2013-11-27 0:39 UTC (permalink / raw)
To: Jens Axboe; +Cc: Olof Johansson, Stephen Rothwell, linux-next, linux-kernel
>From 46e7081430f5f483906f496733a23f8e9d898879 Mon Sep 17 00:00:00 2001
From: Kent Overstreet <kmo@daterainc.com>
Date: Tue, 26 Nov 2013 16:36:49 -0800
Subject: [PATCH] block: Silence spurious compiler warnings
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
---
On Tue, Nov 26, 2013 at 12:02:08PM -0700, Jens Axboe wrote:
> On 11/26/2013 12:01 PM, Olof Johansson wrote:
> > I just noticed that i see this with gcc 4.7.0, but 4.8.1 does not warn.
>
> That's good, because it's not a bug. But arguably we should shut up 4.7
> as well, however...
Here you go:
block/blk-merge.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 05c17be..0b097f6 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -89,6 +89,8 @@ static int blk_phys_contig_segment(struct request_queue *q, struct bio *bio,
struct bio_vec end_bv, nxt_bv;
struct bvec_iter iter;
+ uninitialized_var(end_bv);
+
if (!blk_queue_cluster(q))
return 0;
@@ -173,6 +175,8 @@ int blk_rq_map_sg(struct request_queue *q, struct request *rq,
struct scatterlist *sg;
int nsegs, cluster;
+ uninitialized_var(bvprv);
+
nsegs = 0;
cluster = blk_queue_cluster(q);
@@ -235,6 +239,8 @@ int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
int nsegs, cluster;
struct bvec_iter iter;
+ uninitialized_var(bvprv);
+
nsegs = 0;
cluster = blk_queue_cluster(q);
--
1.8.4.4
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH] block: Silence spurious compiler warnings
2013-11-27 0:39 ` [PATCH] block: Silence spurious compiler warnings Kent Overstreet
@ 2013-11-28 0:50 ` Stephen Rothwell
0 siblings, 0 replies; 42+ messages in thread
From: Stephen Rothwell @ 2013-11-28 0:50 UTC (permalink / raw)
To: Kent Overstreet; +Cc: Jens Axboe, Olof Johansson, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]
Hi Kent,
On Tue, 26 Nov 2013 16:39:49 -0800 Kent Overstreet <kmo@daterainc.com> wrote:
>
> From 46e7081430f5f483906f496733a23f8e9d898879 Mon Sep 17 00:00:00 2001
> From: Kent Overstreet <kmo@daterainc.com>
> Date: Tue, 26 Nov 2013 16:36:49 -0800
> Subject: [PATCH] block: Silence spurious compiler warnings
>
> Signed-off-by: Kent Overstreet <kmo@daterainc.com>
Unfortunately, that did not work :-(
I am till getting these warnings into today's linux-next after merging
the block tree (arm multi_v7_defconfig, gcc 4.6):
block/blk-merge.c: In function 'blk_rq_map_sg':
block/blk-merge.c:135:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:173:23: note: 'bvprv.bv_page' was declared here
block/blk-merge.c:135:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:173:23: note: 'bvprv.bv_len' was declared here
block/blk-merge.c:135:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:173:23: note: 'bvprv.bv_offset' was declared here
block/blk-merge.c: In function 'blk_bio_map_sg':
block/blk-merge.c:135:8: warning: 'bvprv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:237:23: note: 'bvprv.bv_offset' was declared here
block/blk-merge.c:135:8: warning: 'bvprv.bv_len' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:237:23: note: 'bvprv.bv_len' was declared here
block/blk-merge.c:135:8: warning: 'bvprv.bv_page' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:237:23: note: 'bvprv.bv_page' was declared here
block/blk-merge.c: In function 'attempt_merge':
block/blk-merge.c:110:7: warning: 'end_bv.bv_offset' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:89:17: note: 'end_bv.bv_offset' was declared here
block/blk-merge.c:110:7: warning: 'end_bv.bv_len' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:89:17: note: 'end_bv.bv_len' was declared here
block/blk-merge.c:110:7: warning: 'end_bv.bv_page' may be used uninitialized in this function [-Wuninitialized]
block/blk-merge.c:89:17: note: 'end_bv.bv_page' was declared here
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2024-02-06 13:42 ` Geert Uytterhoeven
@ 2024-02-06 14:53 ` Jens Axboe
0 siblings, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2024-02-06 14:53 UTC (permalink / raw)
To: Geert Uytterhoeven, Stephen Rothwell
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 2/6/24 6:42 AM, Geert Uytterhoeven wrote:
> On Tue, Feb 6, 2024 at 12:12 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Tue, Feb 6, 2024 at 3:11 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> After merging the block tree, today's linux-next build (arm
>>> multi_v7_defconfig) produced these warnings:
>>>
>>> In file included from /home/sfr/next/next/include/linux/bits.h:6,
>>> from /home/sfr/next/next/include/linux/bitops.h:6,
>>> from /home/sfr/next/next/include/linux/kernel.h:23,
>>> from /home/sfr/next/next/io_uring/nop.c:2:
>>> /home/sfr/next/next/include/vdso/bits.h:7:40: warning: left shift count >= width of type [-Wshift-count-overflow]
>>> 7 | #define BIT(nr) (UL(1) << (nr))
>>> | ^~
>>> /home/sfr/next/next/include/linux/io_uring_types.h:538:35: note: in expansion of macro 'BIT'
>>> 538 | REQ_F_CAN_POLL = BIT(REQ_F_CAN_POLL_BIT),
>>> | ^~~
>>>
>>> (and mny more similar)
>>>
>>> Introduced by commit
>>>
>>> d964e8440442 ("io_uring: add io_file_can_poll() helper")
>>>
>>> REQ_F_CAN_POLL_BIT is 32.
>>
>> All of these BIT() have to be changed to BIT_ULL().
>> And let's hope all variables used for storing these flags have been
>> changed from unsigned long to u64...
>
> I have sent a fix
> https://lore.kernel.org/1960190f37b94276df50d382b9f1488cd6b6e662.1707226862.git.geert+renesas@glider.be
It needs a bit more than that, just because there's one helper that
also returns flags to be set. I've sorted it out and amended the commit,
should be fine now. I'll check on 32-bit as well.
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2024-02-06 2:10 linux-next: build warnings after merge of the block tree Stephen Rothwell
2024-02-06 4:13 ` Stephen Rothwell
2024-02-06 11:12 ` Geert Uytterhoeven
@ 2024-02-06 14:49 ` Jens Axboe
2 siblings, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2024-02-06 14:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 2/5/24 7:10 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> In file included from /home/sfr/next/next/include/linux/bits.h:6,
> from /home/sfr/next/next/include/linux/bitops.h:6,
> from /home/sfr/next/next/include/linux/kernel.h:23,
> from /home/sfr/next/next/io_uring/nop.c:2:
> /home/sfr/next/next/include/vdso/bits.h:7:40: warning: left shift count >= width of type [-Wshift-count-overflow]
> 7 | #define BIT(nr) (UL(1) << (nr))
> | ^~
> /home/sfr/next/next/include/linux/io_uring_types.h:538:35: note: in expansion of macro 'BIT'
> 538 | REQ_F_CAN_POLL = BIT(REQ_F_CAN_POLL_BIT),
> | ^~~
>
> (and mny more similar)
>
> Introduced by commit
>
> d964e8440442 ("io_uring: add io_file_can_poll() helper")
>
> REQ_F_CAN_POLL_BIT is 32.
Oops yes, didn't get around to 32-bit compiles just yet. I'll fix it
up, thanks.
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2024-02-06 11:12 ` Geert Uytterhoeven
@ 2024-02-06 13:42 ` Geert Uytterhoeven
2024-02-06 14:53 ` Jens Axboe
0 siblings, 1 reply; 42+ messages in thread
From: Geert Uytterhoeven @ 2024-02-06 13:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jens Axboe, Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Feb 6, 2024 at 12:12 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Feb 6, 2024 at 3:11 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > After merging the block tree, today's linux-next build (arm
> > multi_v7_defconfig) produced these warnings:
> >
> > In file included from /home/sfr/next/next/include/linux/bits.h:6,
> > from /home/sfr/next/next/include/linux/bitops.h:6,
> > from /home/sfr/next/next/include/linux/kernel.h:23,
> > from /home/sfr/next/next/io_uring/nop.c:2:
> > /home/sfr/next/next/include/vdso/bits.h:7:40: warning: left shift count >= width of type [-Wshift-count-overflow]
> > 7 | #define BIT(nr) (UL(1) << (nr))
> > | ^~
> > /home/sfr/next/next/include/linux/io_uring_types.h:538:35: note: in expansion of macro 'BIT'
> > 538 | REQ_F_CAN_POLL = BIT(REQ_F_CAN_POLL_BIT),
> > | ^~~
> >
> > (and mny more similar)
> >
> > Introduced by commit
> >
> > d964e8440442 ("io_uring: add io_file_can_poll() helper")
> >
> > REQ_F_CAN_POLL_BIT is 32.
>
> All of these BIT() have to be changed to BIT_ULL().
> And let's hope all variables used for storing these flags have been
> changed from unsigned long to u64...
I have sent a fix
https://lore.kernel.org/1960190f37b94276df50d382b9f1488cd6b6e662.1707226862.git.geert+renesas@glider.be
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2024-02-06 2:10 linux-next: build warnings after merge of the block tree Stephen Rothwell
2024-02-06 4:13 ` Stephen Rothwell
@ 2024-02-06 11:12 ` Geert Uytterhoeven
2024-02-06 13:42 ` Geert Uytterhoeven
2024-02-06 14:49 ` Jens Axboe
2 siblings, 1 reply; 42+ messages in thread
From: Geert Uytterhoeven @ 2024-02-06 11:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jens Axboe, Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Feb 6, 2024 at 3:11 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> In file included from /home/sfr/next/next/include/linux/bits.h:6,
> from /home/sfr/next/next/include/linux/bitops.h:6,
> from /home/sfr/next/next/include/linux/kernel.h:23,
> from /home/sfr/next/next/io_uring/nop.c:2:
> /home/sfr/next/next/include/vdso/bits.h:7:40: warning: left shift count >= width of type [-Wshift-count-overflow]
> 7 | #define BIT(nr) (UL(1) << (nr))
> | ^~
> /home/sfr/next/next/include/linux/io_uring_types.h:538:35: note: in expansion of macro 'BIT'
> 538 | REQ_F_CAN_POLL = BIT(REQ_F_CAN_POLL_BIT),
> | ^~~
>
> (and mny more similar)
>
> Introduced by commit
>
> d964e8440442 ("io_uring: add io_file_can_poll() helper")
>
> REQ_F_CAN_POLL_BIT is 32.
All of these BIT() have to be changed to BIT_ULL().
And let's hope all variables used for storing these flags have been
changed from unsigned long to u64...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2024-02-06 2:10 linux-next: build warnings after merge of the block tree Stephen Rothwell
@ 2024-02-06 4:13 ` Stephen Rothwell
2024-02-06 11:12 ` Geert Uytterhoeven
2024-02-06 14:49 ` Jens Axboe
2 siblings, 0 replies; 42+ messages in thread
From: Stephen Rothwell @ 2024-02-06 4:13 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
Hi all,
On Tue, 6 Feb 2024 13:10:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> In file included from /home/sfr/next/next/include/linux/bits.h:6,
> from /home/sfr/next/next/include/linux/bitops.h:6,
> from /home/sfr/next/next/include/linux/kernel.h:23,
> from /home/sfr/next/next/io_uring/nop.c:2:
> /home/sfr/next/next/include/vdso/bits.h:7:40: warning: left shift count >= width of type [-Wshift-count-overflow]
> 7 | #define BIT(nr) (UL(1) << (nr))
> | ^~
> /home/sfr/next/next/include/linux/io_uring_types.h:538:35: note: in expansion of macro 'BIT'
> 538 | REQ_F_CAN_POLL = BIT(REQ_F_CAN_POLL_BIT),
> | ^~~
>
> (and mny more similar)
>
> Introduced by commit
>
> d964e8440442 ("io_uring: add io_file_can_poll() helper")
>
> REQ_F_CAN_POLL_BIT is 32.
This became a build failure in the i386 defconfig build, so I reverted commit
efaf6760976d ("Merge branch 'for-6.9/io_uring' into for-next")
i.e. the merge of the whole topic branch.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* linux-next: build warnings after merge of the block tree
@ 2024-02-06 2:10 Stephen Rothwell
2024-02-06 4:13 ` Stephen Rothwell
` (2 more replies)
0 siblings, 3 replies; 42+ messages in thread
From: Stephen Rothwell @ 2024-02-06 2:10 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
Hi all,
After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:
In file included from /home/sfr/next/next/include/linux/bits.h:6,
from /home/sfr/next/next/include/linux/bitops.h:6,
from /home/sfr/next/next/include/linux/kernel.h:23,
from /home/sfr/next/next/io_uring/nop.c:2:
/home/sfr/next/next/include/vdso/bits.h:7:40: warning: left shift count >= width of type [-Wshift-count-overflow]
7 | #define BIT(nr) (UL(1) << (nr))
| ^~
/home/sfr/next/next/include/linux/io_uring_types.h:538:35: note: in expansion of macro 'BIT'
538 | REQ_F_CAN_POLL = BIT(REQ_F_CAN_POLL_BIT),
| ^~~
(and mny more similar)
Introduced by commit
d964e8440442 ("io_uring: add io_file_can_poll() helper")
REQ_F_CAN_POLL_BIT is 32.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-07-27 6:10 Stephen Rothwell
@ 2023-07-27 12:41 ` Jens Axboe
0 siblings, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2023-07-27 12:41 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 7/27/23 12:10 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> kernel/futex/futex.h:183: warning: Function parameter or member 'wake' not described in 'futex_q'
> kernel/futex/futex.h:183: warning: Function parameter or member 'wake_data' not described in 'futex_q'
>
> Introduced by commits
>
> c8d49e4f6dec ("futex: factor out the futex wake handling")
> 16759c720d7b ("futex: add wake_data to struct futex_q")
Thanks, I'll fix those up!
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* linux-next: build warnings after merge of the block tree
@ 2023-07-27 6:10 Stephen Rothwell
2023-07-27 12:41 ` Jens Axboe
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2023-07-27 6:10 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
Hi all,
After merging the block tree, today's linux-next build (htmldocs)
produced these warnings:
kernel/futex/futex.h:183: warning: Function parameter or member 'wake' not described in 'futex_q'
kernel/futex/futex.h:183: warning: Function parameter or member 'wake_data' not described in 'futex_q'
Introduced by commits
c8d49e4f6dec ("futex: factor out the futex wake handling")
16759c720d7b ("futex: add wake_data to struct futex_q")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-07-03 14:18 ` Jens Axboe
@ 2023-07-03 15:14 ` Peter Zijlstra
0 siblings, 0 replies; 42+ messages in thread
From: Peter Zijlstra @ 2023-07-03 15:14 UTC (permalink / raw)
To: Jens Axboe
Cc: Josh Poimboeuf, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Jul 03, 2023 at 08:18:38AM -0600, Jens Axboe wrote:
> On 7/3/23 5:04?AM, Peter Zijlstra wrote:
> > On Fri, Jun 16, 2023 at 02:43:55PM +0200, Peter Zijlstra wrote:
> >
> >> I've been getting reports from some anonymous people still using ancient
> >> GCCs (10.4) that also need the following:
> >
> > Jens, will you pick this up or should I route it through the objtool
> > tree?
>
> Sorry, guess it was waiting on me. Would be great if you could route it
> through the objtool tree. Thanks!
Will do! Thanks!
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-07-03 11:04 ` Peter Zijlstra
@ 2023-07-03 14:18 ` Jens Axboe
2023-07-03 15:14 ` Peter Zijlstra
0 siblings, 1 reply; 42+ messages in thread
From: Jens Axboe @ 2023-07-03 14:18 UTC (permalink / raw)
To: Peter Zijlstra, Josh Poimboeuf
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On 7/3/23 5:04?AM, Peter Zijlstra wrote:
> On Fri, Jun 16, 2023 at 02:43:55PM +0200, Peter Zijlstra wrote:
>
>> I've been getting reports from some anonymous people still using ancient
>> GCCs (10.4) that also need the following:
>
> Jens, will you pick this up or should I route it through the objtool
> tree?
Sorry, guess it was waiting on me. Would be great if you could route it
through the objtool tree. Thanks!
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-06-16 12:43 ` Peter Zijlstra
2023-06-16 12:49 ` Borislav Petkov
@ 2023-07-03 11:04 ` Peter Zijlstra
2023-07-03 14:18 ` Jens Axboe
1 sibling, 1 reply; 42+ messages in thread
From: Peter Zijlstra @ 2023-07-03 11:04 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Jens Axboe, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Fri, Jun 16, 2023 at 02:43:55PM +0200, Peter Zijlstra wrote:
> I've been getting reports from some anonymous people still using ancient
> GCCs (10.4) that also need the following:
Jens, will you pick this up or should I route it through the objtool
tree?
> ---
> Subject: iov_iter: Mark copy_iovec_from_user() noclone
>
> Extend commit 50f9a76ef127 ("iov_iter: Mark
> copy_compat_iovec_from_user() noinline") to also cover
> copy_iovec_from_user(). Different compiler versions cause the same
> problem on different functions.
>
> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x1f: redundant UACCESS disable
> lib/iov_iter.o: warning: objtool: iovec_from_user+0x84: call to copy_iovec_from_user.part.0() with UACCESS enabled
> lib/iov_iter.o: warning: objtool: __import_iovec+0x143: call to copy_iovec_from_user.part.0() with UACCESS enabled
>
> Fixes: 50f9a76ef127 ("iov_iter: Mark copy_compat_iovec_from_user() noinline")
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 960223ed9199..061cc3ed58f5 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1795,7 +1795,7 @@ static __noclone int copy_compat_iovec_from_user(struct iovec *iov,
> return ret;
> }
>
> -static int copy_iovec_from_user(struct iovec *iov,
> +static __noclone int copy_iovec_from_user(struct iovec *iov,
> const struct iovec __user *uiov, unsigned long nr_segs)
> {
> int ret = -EFAULT;
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-06-16 12:43 ` Peter Zijlstra
@ 2023-06-16 12:49 ` Borislav Petkov
2023-07-03 11:04 ` Peter Zijlstra
1 sibling, 0 replies; 42+ messages in thread
From: Borislav Petkov @ 2023-06-16 12:49 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Josh Poimboeuf, Jens Axboe, Stephen Rothwell,
Linux Kernel Mailing List, Linux Next Mailing List
On Fri, Jun 16, 2023 at 02:43:54PM +0200, Peter Zijlstra wrote:
> I've been getting reports from some anonymous people still using ancient
> GCCs (10.4) that also need the following:
>
> ---
> Subject: iov_iter: Mark copy_iovec_from_user() noclone
>
> Extend commit 50f9a76ef127 ("iov_iter: Mark
> copy_compat_iovec_from_user() noinline") to also cover
> copy_iovec_from_user(). Different compiler versions cause the same
> problem on different functions.
>
> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x1f: redundant UACCESS disable
> lib/iov_iter.o: warning: objtool: iovec_from_user+0x84: call to copy_iovec_from_user.part.0() with UACCESS enabled
> lib/iov_iter.o: warning: objtool: __import_iovec+0x143: call to copy_iovec_from_user.part.0() with UACCESS enabled
>
> Fixes: 50f9a76ef127 ("iov_iter: Mark copy_compat_iovec_from_user() noinline")
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 960223ed9199..061cc3ed58f5 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1795,7 +1795,7 @@ static __noclone int copy_compat_iovec_from_user(struct iovec *iov,
> return ret;
> }
>
> -static int copy_iovec_from_user(struct iovec *iov,
> +static __noclone int copy_iovec_from_user(struct iovec *iov,
> const struct iovec __user *uiov, unsigned long nr_segs)
> {
> int ret = -EFAULT;
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 16:25 ` Josh Poimboeuf
2023-04-12 16:35 ` Jens Axboe
@ 2023-06-16 12:43 ` Peter Zijlstra
2023-06-16 12:49 ` Borislav Petkov
2023-07-03 11:04 ` Peter Zijlstra
1 sibling, 2 replies; 42+ messages in thread
From: Peter Zijlstra @ 2023-06-16 12:43 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Jens Axboe, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Apr 12, 2023 at 09:25:17AM -0700, Josh Poimboeuf wrote:
> From: Josh Poimboeuf <jpoimboe@kernel.org>
> Subject: [PATCH] iov_iter: Mark copy_compat_iovec_from_user() noinline
>
> After commit 6376ce56feb6 ("iov_iter: import single vector iovecs as
> ITER_UBUF"), GCC does an inter-procedural compiler optimization which
> moves the user_access_begin() out of copy_compat_iovec_from_user() and
> into its callers:
>
> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS disable
> lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
> lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
>
> Enforce the "no UACCESS enable across function boundaries" rule by
> disabling cloning for copy_compat_iovec_from_user().
>
> Fixes: 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> https://lkml.kernel.org/lkml/20230327120017.6bb826d7@canb.auug.org.au
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> ---
> lib/iov_iter.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 274014e4eafe..48aa9fd99267 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1698,7 +1698,7 @@ const void *dup_iter(struct iov_iter *new, struct iov_iter *old, gfp_t flags)
> }
> EXPORT_SYMBOL(dup_iter);
>
> -static int copy_compat_iovec_from_user(struct iovec *iov,
> +static __noclone int copy_compat_iovec_from_user(struct iovec *iov,
> const struct iovec __user *uvec, unsigned long nr_segs)
> {
> const struct compat_iovec __user *uiov =
I've been getting reports from some anonymous people still using ancient
GCCs (10.4) that also need the following:
---
Subject: iov_iter: Mark copy_iovec_from_user() noclone
Extend commit 50f9a76ef127 ("iov_iter: Mark
copy_compat_iovec_from_user() noinline") to also cover
copy_iovec_from_user(). Different compiler versions cause the same
problem on different functions.
lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x1f: redundant UACCESS disable
lib/iov_iter.o: warning: objtool: iovec_from_user+0x84: call to copy_iovec_from_user.part.0() with UACCESS enabled
lib/iov_iter.o: warning: objtool: __import_iovec+0x143: call to copy_iovec_from_user.part.0() with UACCESS enabled
Fixes: 50f9a76ef127 ("iov_iter: Mark copy_compat_iovec_from_user() noinline")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 960223ed9199..061cc3ed58f5 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1795,7 +1795,7 @@ static __noclone int copy_compat_iovec_from_user(struct iovec *iov,
return ret;
}
-static int copy_iovec_from_user(struct iovec *iov,
+static __noclone int copy_iovec_from_user(struct iovec *iov,
const struct iovec __user *uiov, unsigned long nr_segs)
{
int ret = -EFAULT;
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 16:56 ` Josh Poimboeuf
@ 2023-04-12 17:57 ` Jens Axboe
0 siblings, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2023-04-12 17:57 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Peter Zijlstra, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On 4/12/23 10:56?AM, Josh Poimboeuf wrote:
> On Wed, Apr 12, 2023 at 10:44:11AM -0600, Jens Axboe wrote:
>> On 4/12/23 10:35?AM, Jens Axboe wrote:
>>> On 4/12/23 10:25?AM, Josh Poimboeuf wrote:
>>>> On Wed, Apr 12, 2023 at 01:44:00PM +0200, Peter Zijlstra wrote:
>>>>> On Tue, Apr 11, 2023 at 05:14:00PM -0700, Josh Poimboeuf wrote:
>>>>>
>>>>>> Peter, what do you think, should we make track uaccess state across
>>>>>> function boundaries?
>>>>>
>>>>> So IIRC the goal was to explicitly dis-allow that. You want minimal code
>>>>> executed with STAC and hence disallow calling stuff.
>>>>
>>>> I guess I was wondering if we could make an exception for calls to
>>>> static IPA-optimized functions, so we wouldn't have to scramble to "fix"
>>>> compiler optimizations.
>>>>
>>>> But for now, yeah let's just keep it simple.
>>>>
>>>> Jens, can you confirm this works? I added __noclone instead of removing
>>>> static.
>>>
>>> Yep, works for me.
>>
>> Want me to slap that patch on top of the branch that has the commit
>> that causes it?
>
> Yes, please. Thanks!
Done!
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 16:44 ` Jens Axboe
@ 2023-04-12 16:56 ` Josh Poimboeuf
2023-04-12 17:57 ` Jens Axboe
0 siblings, 1 reply; 42+ messages in thread
From: Josh Poimboeuf @ 2023-04-12 16:56 UTC (permalink / raw)
To: Jens Axboe
Cc: Peter Zijlstra, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Apr 12, 2023 at 10:44:11AM -0600, Jens Axboe wrote:
> On 4/12/23 10:35 AM, Jens Axboe wrote:
> > On 4/12/23 10:25?AM, Josh Poimboeuf wrote:
> >> On Wed, Apr 12, 2023 at 01:44:00PM +0200, Peter Zijlstra wrote:
> >>> On Tue, Apr 11, 2023 at 05:14:00PM -0700, Josh Poimboeuf wrote:
> >>>
> >>>> Peter, what do you think, should we make track uaccess state across
> >>>> function boundaries?
> >>>
> >>> So IIRC the goal was to explicitly dis-allow that. You want minimal code
> >>> executed with STAC and hence disallow calling stuff.
> >>
> >> I guess I was wondering if we could make an exception for calls to
> >> static IPA-optimized functions, so we wouldn't have to scramble to "fix"
> >> compiler optimizations.
> >>
> >> But for now, yeah let's just keep it simple.
> >>
> >> Jens, can you confirm this works? I added __noclone instead of removing
> >> static.
> >
> > Yep, works for me.
>
> Want me to slap that patch on top of the branch that has the commit
> that causes it?
Yes, please. Thanks!
--
Josh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 16:35 ` Jens Axboe
@ 2023-04-12 16:44 ` Jens Axboe
2023-04-12 16:56 ` Josh Poimboeuf
0 siblings, 1 reply; 42+ messages in thread
From: Jens Axboe @ 2023-04-12 16:44 UTC (permalink / raw)
To: Josh Poimboeuf, Peter Zijlstra
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On 4/12/23 10:35 AM, Jens Axboe wrote:
> On 4/12/23 10:25?AM, Josh Poimboeuf wrote:
>> On Wed, Apr 12, 2023 at 01:44:00PM +0200, Peter Zijlstra wrote:
>>> On Tue, Apr 11, 2023 at 05:14:00PM -0700, Josh Poimboeuf wrote:
>>>
>>>> Peter, what do you think, should we make track uaccess state across
>>>> function boundaries?
>>>
>>> So IIRC the goal was to explicitly dis-allow that. You want minimal code
>>> executed with STAC and hence disallow calling stuff.
>>
>> I guess I was wondering if we could make an exception for calls to
>> static IPA-optimized functions, so we wouldn't have to scramble to "fix"
>> compiler optimizations.
>>
>> But for now, yeah let's just keep it simple.
>>
>> Jens, can you confirm this works? I added __noclone instead of removing
>> static.
>
> Yep, works for me.
Want me to slap that patch on top of the branch that has the commit
that causes it?
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 16:25 ` Josh Poimboeuf
@ 2023-04-12 16:35 ` Jens Axboe
2023-04-12 16:44 ` Jens Axboe
2023-06-16 12:43 ` Peter Zijlstra
1 sibling, 1 reply; 42+ messages in thread
From: Jens Axboe @ 2023-04-12 16:35 UTC (permalink / raw)
To: Josh Poimboeuf, Peter Zijlstra
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On 4/12/23 10:25?AM, Josh Poimboeuf wrote:
> On Wed, Apr 12, 2023 at 01:44:00PM +0200, Peter Zijlstra wrote:
>> On Tue, Apr 11, 2023 at 05:14:00PM -0700, Josh Poimboeuf wrote:
>>
>>> Peter, what do you think, should we make track uaccess state across
>>> function boundaries?
>>
>> So IIRC the goal was to explicitly dis-allow that. You want minimal code
>> executed with STAC and hence disallow calling stuff.
>
> I guess I was wondering if we could make an exception for calls to
> static IPA-optimized functions, so we wouldn't have to scramble to "fix"
> compiler optimizations.
>
> But for now, yeah let's just keep it simple.
>
> Jens, can you confirm this works? I added __noclone instead of removing
> static.
Yep, works for me.
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 11:44 ` Peter Zijlstra
@ 2023-04-12 16:25 ` Josh Poimboeuf
2023-04-12 16:35 ` Jens Axboe
2023-06-16 12:43 ` Peter Zijlstra
0 siblings, 2 replies; 42+ messages in thread
From: Josh Poimboeuf @ 2023-04-12 16:25 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jens Axboe, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Apr 12, 2023 at 01:44:00PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 11, 2023 at 05:14:00PM -0700, Josh Poimboeuf wrote:
>
> > Peter, what do you think, should we make track uaccess state across
> > function boundaries?
>
> So IIRC the goal was to explicitly dis-allow that. You want minimal code
> executed with STAC and hence disallow calling stuff.
I guess I was wondering if we could make an exception for calls to
static IPA-optimized functions, so we wouldn't have to scramble to "fix"
compiler optimizations.
But for now, yeah let's just keep it simple.
Jens, can you confirm this works? I added __noclone instead of removing
static.
---8<---
From: Josh Poimboeuf <jpoimboe@kernel.org>
Subject: [PATCH] iov_iter: Mark copy_compat_iovec_from_user() noinline
After commit 6376ce56feb6 ("iov_iter: import single vector iovecs as
ITER_UBUF"), GCC does an inter-procedural compiler optimization which
moves the user_access_begin() out of copy_compat_iovec_from_user() and
into its callers:
lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS disable
lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
Enforce the "no UACCESS enable across function boundaries" rule by
disabling cloning for copy_compat_iovec_from_user().
Fixes: 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
https://lkml.kernel.org/lkml/20230327120017.6bb826d7@canb.auug.org.au
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
lib/iov_iter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 274014e4eafe..48aa9fd99267 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1698,7 +1698,7 @@ const void *dup_iter(struct iov_iter *new, struct iov_iter *old, gfp_t flags)
}
EXPORT_SYMBOL(dup_iter);
-static int copy_compat_iovec_from_user(struct iovec *iov,
+static __noclone int copy_compat_iovec_from_user(struct iovec *iov,
const struct iovec __user *uvec, unsigned long nr_segs)
{
const struct compat_iovec __user *uiov =
--
2.39.2
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 0:14 ` Josh Poimboeuf
2023-04-12 1:48 ` Jens Axboe
@ 2023-04-12 11:44 ` Peter Zijlstra
2023-04-12 16:25 ` Josh Poimboeuf
1 sibling, 1 reply; 42+ messages in thread
From: Peter Zijlstra @ 2023-04-12 11:44 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Jens Axboe, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, Apr 11, 2023 at 05:14:00PM -0700, Josh Poimboeuf wrote:
> Peter, what do you think, should we make track uaccess state across
> function boundaries?
So IIRC the goal was to explicitly dis-allow that. You want minimal code
executed with STAC and hence disallow calling stuff.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-12 0:14 ` Josh Poimboeuf
@ 2023-04-12 1:48 ` Jens Axboe
2023-04-12 11:44 ` Peter Zijlstra
1 sibling, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2023-04-12 1:48 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Stephen Rothwell, Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List
On 4/11/23 6:14?PM, Josh Poimboeuf wrote:
> On Tue, Apr 11, 2023 at 04:39:39PM -0600, Jens Axboe wrote:
>>>>>>> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
>>>>>>> isable
>>>>>>> lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
>>>>>>> at_iovec_from_user.part.0() with UACCESS enabled
>>>>>>> lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
>>>>>>>
>>>>>>> Presumably introduced by commit
>>>>>>>
>>>>>>> 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
>>
>> lib/iov_iter.o attached, gzip'ed. NOTE: if you disable either of the
>> copy_compat_iovec_from_user() as per diff below (commented out), then
>> it doesn't complain. Is there some bug where it thinks we'll hit both?
>> That should not be possible.
>
> Yeah, the problem is an inter-procedural compiler optimization which
> moves the user_access_begin() out of copy_compat_iovec_from_user() and
> into its callers.
Ah, I see.
> Which is fine, but objtool doesn't like it as it expects the uaccess
> enable to not cross function boundaries.
>
> Do the warnings go away if you make copy_compat_iovec_from_user()
> non-static?
Yep, if I kill the static, it stops complaining.
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-11 22:39 ` Jens Axboe
@ 2023-04-12 0:14 ` Josh Poimboeuf
2023-04-12 1:48 ` Jens Axboe
2023-04-12 11:44 ` Peter Zijlstra
0 siblings, 2 replies; 42+ messages in thread
From: Josh Poimboeuf @ 2023-04-12 0:14 UTC (permalink / raw)
To: Jens Axboe
Cc: Stephen Rothwell, Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, Apr 11, 2023 at 04:39:39PM -0600, Jens Axboe wrote:
> >>>>> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
> >>>>> isable
> >>>>> lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
> >>>>> at_iovec_from_user.part.0() with UACCESS enabled
> >>>>> lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
> >>>>>
> >>>>> Presumably introduced by commit
> >>>>>
> >>>>> 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
>
> lib/iov_iter.o attached, gzip'ed. NOTE: if you disable either of the
> copy_compat_iovec_from_user() as per diff below (commented out), then
> it doesn't complain. Is there some bug where it thinks we'll hit both?
> That should not be possible.
Yeah, the problem is an inter-procedural compiler optimization which
moves the user_access_begin() out of copy_compat_iovec_from_user() and
into its callers.
Which is fine, but objtool doesn't like it as it expects the uaccess
enable to not cross function boundaries.
Do the warnings go away if you make copy_compat_iovec_from_user()
non-static?
Peter, what do you think, should we make track uaccess state across
function boundaries?
Disassembly below:
0000000000000730 <copy_compat_iovec_from_user.part.0>:
730: 48 85 d2 test %rdx,%rdx
733: 74 45 je 77a <copy_compat_iovec_from_user.part.0+0x4a>
735: 45 31 c9 xor %r9d,%r9d
738: 31 c0 xor %eax,%eax
73a: eb 1d jmp 759 <copy_compat_iovec_from_user.part.0+0x29>
73c: 48 c1 e0 04 shl $0x4,%rax
740: 41 83 c1 01 add $0x1,%r9d
744: 48 01 f8 add %rdi,%rax
747: 48 89 08 mov %rcx,(%rax)
74a: 44 89 c1 mov %r8d,%ecx
74d: 48 89 48 08 mov %rcx,0x8(%rax)
751: 49 63 c1 movslq %r9d,%rax
754: 48 39 d0 cmp %rdx,%rax
757: 73 21 jae 77a <copy_compat_iovec_from_user.part.0+0x4a>
759: 48 8d 0c c6 lea (%rsi,%rax,8),%rcx
75d: 44 8b 41 04 mov 0x4(%rcx),%r8d
761: 8b 09 mov (%rcx),%ecx
763: 89 c9 mov %ecx,%ecx
765: 45 85 c0 test %r8d,%r8d
768: 79 d2 jns 73c <copy_compat_iovec_from_user.part.0+0xc>
76a: b8 ea ff ff ff mov $0xffffffea,%eax
76f: 90 nop
770: 90 nop
771: 90 nop
772: c3 ret
773: b8 f2 ff ff ff mov $0xfffffff2,%eax
778: eb f5 jmp 76f <copy_compat_iovec_from_user.part.0+0x3f>
77a: 31 c0 xor %eax,%eax
77c: eb f1 jmp 76f <copy_compat_iovec_from_user.part.0+0x3f>
77e: 66 90 xchg %ax,%ax
0000000000002380 <iovec_from_user.part.0>:
2380: 41 56 push %r14
2382: 45 89 c6 mov %r8d,%r14d
2385: 41 55 push %r13
2387: 49 89 fd mov %rdi,%r13
238a: 41 54 push %r12
238c: 49 89 cc mov %rcx,%r12
238f: 55 push %rbp
2390: 48 89 cd mov %rcx,%rbp
2393: 53 push %rbx
2394: 48 89 f3 mov %rsi,%rbx
2397: 48 83 ec 08 sub $0x8,%rsp
239b: 48 39 f2 cmp %rsi,%rdx
239e: 0f 82 bc 00 00 00 jb 2460 <iovec_from_user.part.0+0xe0>
23a4: 45 84 f6 test %r14b,%r14b
23a7: 75 70 jne 2419 <iovec_from_user.part.0+0x99>
23a9: 48 89 da mov %rbx,%rdx
23ac: 48 c1 e2 04 shl $0x4,%rdx
23b0: 48 81 fa ff ff ff 7f cmp $0x7fffffff,%rdx
23b7: 0f 87 98 00 00 00 ja 2455 <iovec_from_user.part.0+0xd5>
23bd: 4c 89 ee mov %r13,%rsi
23c0: 48 89 ef mov %rbp,%rdi
23c3: e8 00 00 00 00 call 23c8 <iovec_from_user.part.0+0x48> 23c4: R_X86_64_PLT32 _copy_from_user-0x4
23c8: 48 85 c0 test %rax,%rax
23cb: 0f 85 86 00 00 00 jne 2457 <iovec_from_user.part.0+0xd7>
23d1: 48 85 db test %rbx,%rbx
23d4: 75 0b jne 23e1 <iovec_from_user.part.0+0x61>
23d6: eb 78 jmp 2450 <iovec_from_user.part.0+0xd0>
23d8: 48 83 c0 01 add $0x1,%rax
23dc: 48 39 c3 cmp %rax,%rbx
23df: 74 6f je 2450 <iovec_from_user.part.0+0xd0>
23e1: 48 89 c2 mov %rax,%rdx
23e4: 48 c1 e2 04 shl $0x4,%rdx
23e8: 48 83 7c 15 08 00 cmpq $0x0,0x8(%rbp,%rdx,1)
23ee: 79 e8 jns 23d8 <iovec_from_user.part.0+0x58>
23f0: b8 ea ff ff ff mov $0xffffffea,%eax
23f5: 48 98 cltq
23f7: 4c 39 e5 cmp %r12,%rbp
23fa: 74 10 je 240c <iovec_from_user.part.0+0x8c>
23fc: 48 89 ef mov %rbp,%rdi
23ff: 48 89 04 24 mov %rax,(%rsp)
2403: e8 00 00 00 00 call 2408 <iovec_from_user.part.0+0x88> 2404: R_X86_64_PLT32 kfree-0x4
2408: 48 8b 04 24 mov (%rsp),%rax
240c: 48 83 c4 08 add $0x8,%rsp
2410: 5b pop %rbx
2411: 5d pop %rbp
2412: 41 5c pop %r12
2414: 41 5d pop %r13
2416: 41 5e pop %r14
2418: c3 ret
2419: 48 8d 14 dd 00 00 00 00 lea 0x0(,%rbx,8),%rdx
2421: 48 b8 00 f0 ff ff ff 7f 00 00 movabs $0x7ffffffff000,%rax
242b: 48 39 d0 cmp %rdx,%rax
242e: 72 27 jb 2457 <iovec_from_user.part.0+0xd7>
2430: 48 29 d0 sub %rdx,%rax
2433: 4c 39 e8 cmp %r13,%rax
2436: 72 1f jb 2457 <iovec_from_user.part.0+0xd7>
2438: 90 nop
2439: 90 nop
243a: 90 nop
243b: 90 nop
243c: 90 nop
243d: 90 nop
243e: 48 89 da mov %rbx,%rdx
2441: 4c 89 ee mov %r13,%rsi
2444: 48 89 ef mov %rbp,%rdi
2447: e8 e4 e2 ff ff call 730 <copy_compat_iovec_from_user.part.0>
244c: 85 c0 test %eax,%eax
244e: 75 a5 jne 23f5 <iovec_from_user.part.0+0x75>
2450: 48 89 e8 mov %rbp,%rax
2453: eb b7 jmp 240c <iovec_from_user.part.0+0x8c>
2455: 0f 0b ud2
2457: 48 c7 c0 f2 ff ff ff mov $0xfffffffffffffff2,%rax
245e: eb 97 jmp 23f7 <iovec_from_user.part.0+0x77>
2460: 48 89 f7 mov %rsi,%rdi
2463: 48 89 f0 mov %rsi,%rax
2466: 48 c1 e7 04 shl $0x4,%rdi
246a: 48 c1 e8 3c shr $0x3c,%rax
246e: 75 16 jne 2486 <iovec_from_user.part.0+0x106>
2470: be c0 0c 00 00 mov $0xcc0,%esi
2475: e8 00 00 00 00 call 247a <iovec_from_user.part.0+0xfa> 2476: R_X86_64_PLT32 __kmalloc-0x4
247a: 48 89 c5 mov %rax,%rbp
247d: 48 85 c0 test %rax,%rax
2480: 0f 85 1e ff ff ff jne 23a4 <iovec_from_user.part.0+0x24>
2486: 48 c7 c0 f4 ff ff ff mov $0xfffffffffffffff4,%rax
248d: e9 7a ff ff ff jmp 240c <iovec_from_user.part.0+0x8c>
2492: 66 66 2e 0f 1f 84 00 00 00 00 00 data16 cs nopw 0x0(%rax,%rax,1)
249d: 0f 1f 00 nopl (%rax)
0000000000004910 <__import_iovec>:
4910: 41 56 push %r14
4912: 4d 89 ce mov %r9,%r14
4915: 41 55 push %r13
4917: 41 89 fd mov %edi,%r13d
491a: 48 89 f7 mov %rsi,%rdi
491d: 41 54 push %r12
491f: 55 push %rbp
4920: 4c 89 c5 mov %r8,%rbp
4923: 53 push %rbx
4924: 44 8b 44 24 30 mov 0x30(%rsp),%r8d
4929: 48 8b 5d 00 mov 0x0(%rbp),%rbx
492d: 83 fa 01 cmp $0x1,%edx
4930: 0f 84 18 01 00 00 je 4a4e <__import_iovec+0x13e>
4936: 41 89 d4 mov %edx,%r12d
4939: 4d 85 e4 test %r12,%r12
493c: 0f 84 f7 00 00 00 je 4a39 <__import_iovec+0x129>
4942: 49 81 fc 00 04 00 00 cmp $0x400,%r12
4949: 0f 87 ad 01 00 00 ja 4afc <__import_iovec+0x1ec>
494f: 89 ca mov %ecx,%edx
4951: 45 0f b6 c0 movzbl %r8b,%r8d
4955: 48 89 d9 mov %rbx,%rcx
4958: 4c 89 e6 mov %r12,%rsi
495b: e8 20 da ff ff call 2380 <iovec_from_user.part.0>
4960: 4d 89 e0 mov %r12,%r8
4963: 31 c9 xor %ecx,%ecx
4965: 41 ba 00 f0 ff 7f mov $0x7ffff000,%r10d
496b: 49 c1 e0 04 shl $0x4,%r8
496f: 48 89 c3 mov %rax,%rbx
4972: 48 bf 00 f0 ff ff ff 7f 00 00 movabs $0x7ffffffff000,%rdi
497c: 49 01 c0 add %rax,%r8
497f: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
4985: 0f 87 bb 00 00 00 ja 4a46 <__import_iovec+0x136>
498b: 48 8b 50 08 mov 0x8(%rax),%rdx
498f: 48 8b 30 mov (%rax),%rsi
4992: 48 39 d7 cmp %rdx,%rdi
4995: 72 0b jb 49a2 <__import_iovec+0x92>
4997: 49 89 f9 mov %rdi,%r9
499a: 49 29 d1 sub %rdx,%r9
499d: 49 39 f1 cmp %rsi,%r9
49a0: 73 29 jae 49cb <__import_iovec+0xbb>
49a2: 48 39 5d 00 cmp %rbx,0x0(%rbp)
49a6: 74 08 je 49b0 <__import_iovec+0xa0>
49a8: 48 89 df mov %rbx,%rdi
49ab: e8 00 00 00 00 call 49b0 <__import_iovec+0xa0> 49ac: R_X86_64_PLT32 kfree-0x4
49b0: 48 c7 45 00 00 00 00 00 movq $0x0,0x0(%rbp)
49b8: 48 c7 c1 f2 ff ff ff mov $0xfffffffffffffff2,%rcx
49bf: 5b pop %rbx
49c0: 48 89 c8 mov %rcx,%rax
49c3: 5d pop %rbp
49c4: 41 5c pop %r12
49c6: 41 5d pop %r13
49c8: 41 5e pop %r14
49ca: c3 ret
49cb: 4c 89 d6 mov %r10,%rsi
49ce: 48 29 ce sub %rcx,%rsi
49d1: 48 01 d1 add %rdx,%rcx
49d4: 48 39 d6 cmp %rdx,%rsi
49d7: 73 09 jae 49e2 <__import_iovec+0xd2>
49d9: 48 89 70 08 mov %rsi,0x8(%rax)
49dd: b9 00 f0 ff 7f mov $0x7ffff000,%ecx
49e2: 48 83 c0 10 add $0x10,%rax
49e6: 49 39 c0 cmp %rax,%r8
49e9: 75 a0 jne 498b <__import_iovec+0x7b>
49eb: 48 89 c8 mov %rcx,%rax
49ee: 41 83 fd 01 cmp $0x1,%r13d
49f2: 0f 87 5f 01 00 00 ja 4b57 <__import_iovec+0x247>
49f8: 31 d2 xor %edx,%edx
49fa: 45 85 ed test %r13d,%r13d
49fd: 49 89 5e 10 mov %rbx,0x10(%r14)
4a01: 49 89 46 18 mov %rax,0x18(%r14)
4a05: 41 0f 95 46 02 setne 0x2(%r14)
4a0a: 31 c0 xor %eax,%eax
4a0c: 66 41 89 16 mov %dx,(%r14)
4a10: 41 c6 46 03 01 movb $0x1,0x3(%r14)
4a15: 49 c7 46 08 00 00 00 00 movq $0x0,0x8(%r14)
4a1d: 4d 89 66 20 mov %r12,0x20(%r14)
4a21: 48 39 5d 00 cmp %rbx,0x0(%rbp)
4a25: 48 0f 44 d8 cmove %rax,%rbx
4a29: 48 89 c8 mov %rcx,%rax
4a2c: 48 89 5d 00 mov %rbx,0x0(%rbp)
4a30: 5b pop %rbx
4a31: 5d pop %rbp
4a32: 41 5c pop %r12
4a34: 41 5d pop %r13
4a36: 41 5e pop %r14
4a38: c3 ret
4a39: 31 c0 xor %eax,%eax
4a3b: 31 c9 xor %ecx,%ecx
4a3d: 48 81 fb 00 f0 ff ff cmp $0xfffffffffffff000,%rbx
4a44: 76 a8 jbe 49ee <__import_iovec+0xde>
4a46: 48 89 d9 mov %rbx,%rcx
4a49: e9 b5 00 00 00 jmp 4b03 <__import_iovec+0x1f3>
4a4e: 45 84 c0 test %r8b,%r8b
4a51: 0f 85 b9 00 00 00 jne 4b10 <__import_iovec+0x200>
4a57: ba 10 00 00 00 mov $0x10,%edx
4a5c: 48 89 df mov %rbx,%rdi
4a5f: e8 00 00 00 00 call 4a64 <__import_iovec+0x154> 4a60: R_X86_64_PLT32 _copy_from_user-0x4
4a64: 48 85 c0 test %rax,%rax
4a67: 0f 85 4b ff ff ff jne 49b8 <__import_iovec+0xa8>
4a6d: 48 8b 43 08 mov 0x8(%rbx),%rax
4a71: 48 85 c0 test %rax,%rax
4a74: 0f 88 d1 00 00 00 js 4b4b <__import_iovec+0x23b>
4a7a: 48 ba 00 f0 ff ff ff 7f 00 00 movabs $0x7ffffffff000,%rdx
4a84: 48 8b 0b mov (%rbx),%rcx
4a87: 48 29 c2 sub %rax,%rdx
4a8a: 48 3d 00 f0 ff 7f cmp $0x7ffff000,%rax
4a90: 76 0f jbe 4aa1 <__import_iovec+0x191>
4a92: 48 ba 00 00 00 80 ff 7f 00 00 movabs $0x7fff80000000,%rdx
4a9c: b8 00 f0 ff 7f mov $0x7ffff000,%eax
4aa1: 48 39 ca cmp %rcx,%rdx
4aa4: 0f 82 0e ff ff ff jb 49b8 <__import_iovec+0xa8>
4aaa: 41 83 fd 01 cmp $0x1,%r13d
4aae: 0f 87 aa 00 00 00 ja 4b5e <__import_iovec+0x24e>
4ab4: 45 85 ed test %r13d,%r13d
4ab7: 49 c7 06 00 00 00 00 movq $0x0,(%r14)
4abe: 49 89 46 18 mov %rax,0x18(%r14)
4ac2: 49 89 4e 10 mov %rcx,0x10(%r14)
4ac6: 49 c7 46 08 00 00 00 00 movq $0x0,0x8(%r14)
4ace: 41 c6 06 05 movb $0x5,(%r14)
4ad2: 41 c6 46 03 01 movb $0x1,0x3(%r14)
4ad7: 49 c7 46 20 01 00 00 00 movq $0x1,0x20(%r14)
4adf: 41 0f 95 46 02 setne 0x2(%r14)
4ae4: 48 c7 45 00 00 00 00 00 movq $0x0,0x0(%rbp)
4aec: 49 8b 4e 18 mov 0x18(%r14),%rcx
4af0: 5b pop %rbx
4af1: 5d pop %rbp
4af2: 48 89 c8 mov %rcx,%rax
4af5: 41 5c pop %r12
4af7: 41 5d pop %r13
4af9: 41 5e pop %r14
4afb: c3 ret
4afc: 48 c7 c1 ea ff ff ff mov $0xffffffffffffffea,%rcx
4b03: 48 c7 45 00 00 00 00 00 movq $0x0,0x0(%rbp)
4b0b: e9 af fe ff ff jmp 49bf <__import_iovec+0xaf>
4b10: 48 b8 f8 ef ff ff ff 7f 00 00 movabs $0x7fffffffeff8,%rax
4b1a: 48 39 f0 cmp %rsi,%rax
4b1d: 0f 82 95 fe ff ff jb 49b8 <__import_iovec+0xa8>
4b23: 90 nop
4b24: 90 nop
4b25: 90 nop
4b26: 90 nop
4b27: 90 nop
4b28: 90 nop
4b29: ba 01 00 00 00 mov $0x1,%edx
4b2e: 48 89 df mov %rbx,%rdi
4b31: e8 fa bb ff ff call 730 <copy_compat_iovec_from_user.part.0>
4b36: 48 63 c8 movslq %eax,%rcx
4b39: 48 85 c9 test %rcx,%rcx
4b3c: 0f 85 7d fe ff ff jne 49bf <__import_iovec+0xaf>
4b42: 48 8b 43 08 mov 0x8(%rbx),%rax
4b46: e9 2f ff ff ff jmp 4a7a <__import_iovec+0x16a>
4b4b: 48 c7 c1 ea ff ff ff mov $0xffffffffffffffea,%rcx
4b52: e9 68 fe ff ff jmp 49bf <__import_iovec+0xaf>
4b57: 0f 0b ud2
4b59: e9 9a fe ff ff jmp 49f8 <__import_iovec+0xe8>
4b5e: 0f 0b ud2
4b60: e9 4f ff ff ff jmp 4ab4 <__import_iovec+0x1a4>
4b65: 66 66 2e 0f 1f 84 00 00 00 00 00 data16 cs nopw 0x0(%rax,%rax,1)
--
Josh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-11 21:55 ` Josh Poimboeuf
@ 2023-04-11 22:39 ` Jens Axboe
2023-04-12 0:14 ` Josh Poimboeuf
0 siblings, 1 reply; 42+ messages in thread
From: Jens Axboe @ 2023-04-11 22:39 UTC (permalink / raw)
To: Josh Poimboeuf, Stephen Rothwell
Cc: Peter Zijlstra, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]
On 4/11/23 3:55?PM, Josh Poimboeuf wrote:
> On Wed, Apr 12, 2023 at 07:34:16AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Tue, 28 Mar 2023 10:47:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> On Mon, 27 Mar 2023 09:26:30 -0700 Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>>>
>>>> On Mon, Mar 27, 2023 at 12:00:17PM +1100, Stephen Rothwell wrote:
>>>>>
>>>>> After merging the block tree, today's linux-next build (x86_64
>>>>> allnoconfig) produced these warnings:
>>>>>
>>>>> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
>>>>> isable
>>>>> lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
>>>>> at_iovec_from_user.part.0() with UACCESS enabled
>>>>> lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
>>>>>
>>>>> Presumably introduced by commit
>>>>>
>>>>> 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
>>>>
>>>> I'm not able to recreate. What's your compiler version?
>>>
>>> $ x86_64-linux-gnu-gcc --version
>>> x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
>>
>> Any progress?
>
> I still wasn't able to recreate with gcc version 12.2.1 20221121 (Red
> Hat 12.2.1-4) (GCC) .
>
> Is it a cross-compile?
>
> Can you share the .o file?
Here's mine, native compile:
axboe@12900k ~/gi/linux-block (test)> gcc --version
gcc (Debian 12.2.0-14) 12.2.0
lib/iov_iter.o attached, gzip'ed. NOTE: if you disable either of the
copy_compat_iovec_from_user() as per diff below (commented out), then
it doesn't complain. Is there some bug where it thinks we'll hit both?
That should not be possible.
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 783ae46b13b9..1bff8f9282b2 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -1327,6 +1327,7 @@ struct iovec *iovec_from_user(const struct iovec __user *uvec,
return ERR_PTR(-ENOMEM);
}
+ /* if (0 && compat) */
if (compat)
ret = copy_compat_iovec_from_user(iov, uvec, nr_segs);
else
@@ -1350,6 +1351,7 @@ static ssize_t __import_iovec_ubuf(int type, const struct iovec __user *uvec,
struct iovec *iov = *iovp;
ssize_t ret;
+ /* if (0 && compat) */
if (compat)
ret = copy_compat_iovec_from_user(iov, uvec, 1);
else
--
Jens Axboe
[-- Attachment #2: iov_iter.o.gz --]
[-- Type: application/gzip, Size: 163349 bytes --]
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-11 21:34 ` Stephen Rothwell
2023-04-11 21:55 ` Josh Poimboeuf
@ 2023-04-11 22:30 ` Jens Axboe
1 sibling, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2023-04-11 22:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Josh Poimboeuf, Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List
On 4/11/23 3:34?PM, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 28 Mar 2023 10:47:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> On Mon, 27 Mar 2023 09:26:30 -0700 Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>>
>>> On Mon, Mar 27, 2023 at 12:00:17PM +1100, Stephen Rothwell wrote:
>>>>
>>>> After merging the block tree, today's linux-next build (x86_64
>>>> allnoconfig) produced these warnings:
>>>>
>>>> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
>>>> isable
>>>> lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
>>>> at_iovec_from_user.part.0() with UACCESS enabled
>>>> lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
>>>>
>>>> Presumably introduced by commit
>>>>
>>>> 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
>>>
>>> I'm not able to recreate. What's your compiler version?
>>
>> $ x86_64-linux-gnu-gcc --version
>> x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
>
> Any progress?
Honestly I have no idea what it's complaining about. It's obviously the
compat copy, but everything seems fine to me?
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-04-11 21:34 ` Stephen Rothwell
@ 2023-04-11 21:55 ` Josh Poimboeuf
2023-04-11 22:39 ` Jens Axboe
2023-04-11 22:30 ` Jens Axboe
1 sibling, 1 reply; 42+ messages in thread
From: Josh Poimboeuf @ 2023-04-11 21:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jens Axboe, Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Apr 12, 2023 at 07:34:16AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 28 Mar 2023 10:47:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Mon, 27 Mar 2023 09:26:30 -0700 Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > >
> > > On Mon, Mar 27, 2023 at 12:00:17PM +1100, Stephen Rothwell wrote:
> > > >
> > > > After merging the block tree, today's linux-next build (x86_64
> > > > allnoconfig) produced these warnings:
> > > >
> > > > lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
> > > > isable
> > > > lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
> > > > at_iovec_from_user.part.0() with UACCESS enabled
> > > > lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
> > > >
> > > > Presumably introduced by commit
> > > >
> > > > 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
> > >
> > > I'm not able to recreate. What's your compiler version?
> >
> > $ x86_64-linux-gnu-gcc --version
> > x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
>
> Any progress?
I still wasn't able to recreate with gcc version 12.2.1 20221121 (Red
Hat 12.2.1-4) (GCC) .
Is it a cross-compile?
Can you share the .o file?
--
Josh
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-03-27 23:47 ` Stephen Rothwell
@ 2023-04-11 21:34 ` Stephen Rothwell
2023-04-11 21:55 ` Josh Poimboeuf
2023-04-11 22:30 ` Jens Axboe
0 siblings, 2 replies; 42+ messages in thread
From: Stephen Rothwell @ 2023-04-11 21:34 UTC (permalink / raw)
To: Jens Axboe
Cc: Josh Poimboeuf, Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
Hi all,
On Tue, 28 Mar 2023 10:47:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 27 Mar 2023 09:26:30 -0700 Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Mon, Mar 27, 2023 at 12:00:17PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the block tree, today's linux-next build (x86_64
> > > allnoconfig) produced these warnings:
> > >
> > > lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
> > > isable
> > > lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
> > > at_iovec_from_user.part.0() with UACCESS enabled
> > > lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
> > >
> > > Presumably introduced by commit
> > >
> > > 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
> >
> > I'm not able to recreate. What's your compiler version?
>
> $ x86_64-linux-gnu-gcc --version
> x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
Any progress?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-03-27 16:26 ` Josh Poimboeuf
@ 2023-03-27 23:47 ` Stephen Rothwell
2023-04-11 21:34 ` Stephen Rothwell
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2023-03-27 23:47 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Jens Axboe, Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
Hi Josh,
On Mon, 27 Mar 2023 09:26:30 -0700 Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Mon, Mar 27, 2023 at 12:00:17PM +1100, Stephen Rothwell wrote:
> >
> > After merging the block tree, today's linux-next build (x86_64
> > allnoconfig) produced these warnings:
> >
> > lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
> > isable
> > lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
> > at_iovec_from_user.part.0() with UACCESS enabled
> > lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
> >
> > Presumably introduced by commit
> >
> > 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
>
> I'm not able to recreate. What's your compiler version?
$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2023-03-27 1:00 Stephen Rothwell
@ 2023-03-27 16:26 ` Josh Poimboeuf
2023-03-27 23:47 ` Stephen Rothwell
0 siblings, 1 reply; 42+ messages in thread
From: Josh Poimboeuf @ 2023-03-27 16:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Jens Axboe, Peter Zijlstra, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Mar 27, 2023 at 12:00:17PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allnoconfig) produced these warnings:
>
> lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
> isable
> lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
> at_iovec_from_user.part.0() with UACCESS enabled
> lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
>
> Presumably introduced by commit
>
> 6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
I'm not able to recreate. What's your compiler version?
It's complaining about a call to a "part.0" function, maybe the IPA
optimization is moving the STAC to before the call.
--
Josh
^ permalink raw reply [flat|nested] 42+ messages in thread
* linux-next: build warnings after merge of the block tree
@ 2023-03-27 1:00 Stephen Rothwell
2023-03-27 16:26 ` Josh Poimboeuf
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2023-03-27 1:00 UTC (permalink / raw)
To: Jens Axboe
Cc: Peter Zijlstra, Josh Poimboeuf, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Hi all,
After merging the block tree, today's linux-next build (x86_64
allnoconfig) produced these warnings:
lib/iov_iter.o: warning: objtool: .altinstr_replacement+0x0: redundant UACCESS d
isable
lib/iov_iter.o: warning: objtool: iovec_from_user.part.0+0xc7: call to copy_comp
at_iovec_from_user.part.0() with UACCESS enabled
lib/iov_iter.o: warning: objtool: __import_iovec+0x21d: call to copy_compat_iovec_from_user.part.0() with UACCESS enabled
Presumably introduced by commit
6376ce56feb6 ("iov_iter: import single vector iovecs as ITER_UBUF")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* linux-next: build warnings after merge of the block tree
@ 2022-07-15 11:51 Stephen Rothwell
0 siblings, 0 replies; 42+ messages in thread
From: Stephen Rothwell @ 2022-07-15 11:51 UTC (permalink / raw)
To: Jens Axboe
Cc: Bart Van Assche, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Hi all,
After merging the block tree, today's linux-next build (htmldocs)
produced these warnings:
fs/buffer.c:2756: warning: Function parameter or member 'opf' not described in 'll_rw_block'
fs/buffer.c:2756: warning: Excess function parameter 'op' description in 'll_rw_block'
fs/buffer.c:2756: warning: Excess function parameter 'op_flags' description in 'll_rw_block'
Introduced by commit
1420c4a549bf ("fs/buffer: Combine two submit_bh() and ll_rw_block() arguments")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2020-03-03 1:41 Stephen Rothwell
@ 2020-03-03 2:59 ` Jens Axboe
0 siblings, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2020-03-03 2:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Next Mailing List, Linux Kernel Mailing List
On 3/2/20 6:41 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) produced these warnings:
>
> fs/io_uring.c: In function 'io_put_kbuf':
> fs/io_uring.c:1651:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> 1651 | struct io_buffer *kbuf = (struct io_buffer *) req->rw.addr;
> | ^
> fs/io_uring.c: In function 'io_rw_buffer_select':
> fs/io_uring.c:2209:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> 2209 | struct io_buffer *kbuf = (struct io_buffer *) req->rw.addr;
> | ^
> fs/io_uring.c:2216:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> 2216 | req->rw.addr = (u64) kbuf;
> | ^
> fs/io_uring.c: In function 'io_cleanup_req':
> fs/io_uring.c:4897:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> 4897 | kfree((void *)req->rw.addr);
> | ^
>
> Introduced by commits
>
> 7efcbb97deab ("io_uring: support buffer selection for OP_READ and OP_RECV")
> 8cab19f460b6 ("io_uring: add IOSQE_BUFFER_SELECT support for IORING_OP_READV")
Thanks Stephen, I added a fixup patch. I wish we had u64_to_ptr() and
ptr_to_u64(), but that's only for the __user pointers...
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* linux-next: build warnings after merge of the block tree
@ 2020-03-03 1:41 Stephen Rothwell
2020-03-03 2:59 ` Jens Axboe
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2020-03-03 1:41 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
Hi all,
After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) produced these warnings:
fs/io_uring.c: In function 'io_put_kbuf':
fs/io_uring.c:1651:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1651 | struct io_buffer *kbuf = (struct io_buffer *) req->rw.addr;
| ^
fs/io_uring.c: In function 'io_rw_buffer_select':
fs/io_uring.c:2209:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
2209 | struct io_buffer *kbuf = (struct io_buffer *) req->rw.addr;
| ^
fs/io_uring.c:2216:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
2216 | req->rw.addr = (u64) kbuf;
| ^
fs/io_uring.c: In function 'io_cleanup_req':
fs/io_uring.c:4897:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
4897 | kfree((void *)req->rw.addr);
| ^
Introduced by commits
7efcbb97deab ("io_uring: support buffer selection for OP_READ and OP_RECV")
8cab19f460b6 ("io_uring: add IOSQE_BUFFER_SELECT support for IORING_OP_READV")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2018-03-01 4:02 ` Anshuman Khandual
@ 2018-03-01 15:37 ` Jens Axboe
0 siblings, 0 replies; 42+ messages in thread
From: Jens Axboe @ 2018-03-01 15:37 UTC (permalink / raw)
To: Anshuman Khandual, Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
On 2/28/18 9:02 PM, Anshuman Khandual wrote:
> On 03/01/2018 05:56 AM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) produced these warning:
>>
>> In file included from drivers/misc/cardreader/rts5209.c:24:0:
>> include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined
>> #define SG_END 0x02
>>
>> In file included from include/linux/dmapool.h:14:0,
>> from include/linux/pci.h:1311,
>> from include/linux/rtsx_pci.h:26,
>> from drivers/misc/cardreader/rts5209.c:24:
>> include/linux/scatterlist.h:69:0: note: this is the location of the previous definition
>> #define SG_END 0x02UL
>>
>> In file included from drivers/staging/rts5208/rtsx.h:180:0,
>> from drivers/staging/rts5208/rtsx.c:28:
>> drivers/staging/rts5208/rtsx_chip.h:343:0: warning: "SG_END" redefined
>> #define SG_END 0x02
>>
>> In file included from include/linux/blkdev.h:28:0,
>> from drivers/staging/rts5208/rtsx.c:23:
>> include/linux/scatterlist.h:69:0: note: this is the location of the previous definition
>> #define SG_END 0x02UL
>>
>>
>> and many more the same.
>>
>> Introduced by commit
>>
>> 723fbf563a6a ("lib/scatterlist: Add SG_CHAIN and SG_END macros for LSB encodings")
>
> IIRC this was already detected and hence sent a new version changing
> this to SG_LAST.
>
> https://patchwork.kernel.org/patch/10227897/
The right fix is for drivers to not use defines that end up conflicting
with the global namespace. Should have been fixed up earlier, but I
have applied the patches from Arnd to rectify that.
--
Jens Axboe
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2018-03-01 0:26 Stephen Rothwell
@ 2018-03-01 4:02 ` Anshuman Khandual
2018-03-01 15:37 ` Jens Axboe
0 siblings, 1 reply; 42+ messages in thread
From: Anshuman Khandual @ 2018-03-01 4:02 UTC (permalink / raw)
To: Stephen Rothwell, Jens Axboe
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
On 03/01/2018 05:56 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) produced these warning:
>
> In file included from drivers/misc/cardreader/rts5209.c:24:0:
> include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined
> #define SG_END 0x02
>
> In file included from include/linux/dmapool.h:14:0,
> from include/linux/pci.h:1311,
> from include/linux/rtsx_pci.h:26,
> from drivers/misc/cardreader/rts5209.c:24:
> include/linux/scatterlist.h:69:0: note: this is the location of the previous definition
> #define SG_END 0x02UL
>
> In file included from drivers/staging/rts5208/rtsx.h:180:0,
> from drivers/staging/rts5208/rtsx.c:28:
> drivers/staging/rts5208/rtsx_chip.h:343:0: warning: "SG_END" redefined
> #define SG_END 0x02
>
> In file included from include/linux/blkdev.h:28:0,
> from drivers/staging/rts5208/rtsx.c:23:
> include/linux/scatterlist.h:69:0: note: this is the location of the previous definition
> #define SG_END 0x02UL
>
>
> and many more the same.
>
> Introduced by commit
>
> 723fbf563a6a ("lib/scatterlist: Add SG_CHAIN and SG_END macros for LSB encodings")
IIRC this was already detected and hence sent a new version changing
this to SG_LAST.
https://patchwork.kernel.org/patch/10227897/
^ permalink raw reply [flat|nested] 42+ messages in thread
* linux-next: build warnings after merge of the block tree
@ 2018-03-01 0:26 Stephen Rothwell
2018-03-01 4:02 ` Anshuman Khandual
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2018-03-01 0:26 UTC (permalink / raw)
To: Jens Axboe
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Anshuman Khandual
[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]
Hi Jens,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced these warning:
In file included from drivers/misc/cardreader/rts5209.c:24:0:
include/linux/rtsx_pci.h:40:0: warning: "SG_END" redefined
#define SG_END 0x02
In file included from include/linux/dmapool.h:14:0,
from include/linux/pci.h:1311,
from include/linux/rtsx_pci.h:26,
from drivers/misc/cardreader/rts5209.c:24:
include/linux/scatterlist.h:69:0: note: this is the location of the previous definition
#define SG_END 0x02UL
In file included from drivers/staging/rts5208/rtsx.h:180:0,
from drivers/staging/rts5208/rtsx.c:28:
drivers/staging/rts5208/rtsx_chip.h:343:0: warning: "SG_END" redefined
#define SG_END 0x02
In file included from include/linux/blkdev.h:28:0,
from drivers/staging/rts5208/rtsx.c:23:
include/linux/scatterlist.h:69:0: note: this is the location of the previous definition
#define SG_END 0x02UL
and many more the same.
Introduced by commit
723fbf563a6a ("lib/scatterlist: Add SG_CHAIN and SG_END macros for LSB encodings")
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: linux-next: build warnings after merge of the block tree
2011-01-07 0:02 Stephen Rothwell
@ 2011-01-07 1:49 ` Mathieu Desnoyers
0 siblings, 0 replies; 42+ messages in thread
From: Mathieu Desnoyers @ 2011-01-07 1:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Jens Axboe, linux-next, linux-kernel, Jeff Moyer
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
* Stephen Rothwell (sfr@canb.auug.org.au) wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) produced these warnings:
Sorry about this, I will issue a patch that updates the blktrace code
according to the new callback prototype expected right away.
Thanks,
Mathieu
>
> kernel/trace/blktrace.c: In function 'blk_register_tracepoints':
> kernel/trace/blktrace.c:999: warning: passing argument 1 of 'register_trace_block_bio_complete' from incompatible pointer type
> include/trace/events/block.h:240: note: expected 'void (*)(void *, struct request_queue *, struct bio *, int)' but argument is of type 'void (*)(void *, struct request_queue *, struct bio *)'
> kernel/trace/blktrace.c: In function 'blk_unregister_tracepoints':
> kernel/trace/blktrace.c:1038: warning: passing argument 1 of 'unregister_trace_block_bio_complete' from incompatible pointer type
> include/trace/events/block.h:240: note: expected 'void (*)(void *, struct request_queue *, struct bio *, int)' but argument is of type 'void (*)(void *, struct request_queue *, struct bio *)'
>
> Probably caused by commit de983a7bfcb7c020901ca6e2314cf55a4207ab5a
> ("block: trace event block fix unassigned field").
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
* linux-next: build warnings after merge of the block tree
@ 2011-01-07 0:02 Stephen Rothwell
2011-01-07 1:49 ` Mathieu Desnoyers
0 siblings, 1 reply; 42+ messages in thread
From: Stephen Rothwell @ 2011-01-07 0:02 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Jeff Moyer, Mathieu Desnoyers
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
Hi Jens,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) produced these warnings:
kernel/trace/blktrace.c: In function 'blk_register_tracepoints':
kernel/trace/blktrace.c:999: warning: passing argument 1 of 'register_trace_block_bio_complete' from incompatible pointer type
include/trace/events/block.h:240: note: expected 'void (*)(void *, struct request_queue *, struct bio *, int)' but argument is of type 'void (*)(void *, struct request_queue *, struct bio *)'
kernel/trace/blktrace.c: In function 'blk_unregister_tracepoints':
kernel/trace/blktrace.c:1038: warning: passing argument 1 of 'unregister_trace_block_bio_complete' from incompatible pointer type
include/trace/events/block.h:240: note: expected 'void (*)(void *, struct request_queue *, struct bio *, int)' but argument is of type 'void (*)(void *, struct request_queue *, struct bio *)'
Probably caused by commit de983a7bfcb7c020901ca6e2314cf55a4207ab5a
("block: trace event block fix unassigned field").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2024-02-06 14:53 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-26 2:29 linux-next: build warnings after merge of the block tree Stephen Rothwell
2013-11-26 3:35 ` Stephen Rothwell
2013-11-26 19:01 ` Olof Johansson
2013-11-26 19:02 ` Jens Axboe
2013-11-27 0:39 ` [PATCH] block: Silence spurious compiler warnings Kent Overstreet
2013-11-28 0:50 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2024-02-06 2:10 linux-next: build warnings after merge of the block tree Stephen Rothwell
2024-02-06 4:13 ` Stephen Rothwell
2024-02-06 11:12 ` Geert Uytterhoeven
2024-02-06 13:42 ` Geert Uytterhoeven
2024-02-06 14:53 ` Jens Axboe
2024-02-06 14:49 ` Jens Axboe
2023-07-27 6:10 Stephen Rothwell
2023-07-27 12:41 ` Jens Axboe
2023-03-27 1:00 Stephen Rothwell
2023-03-27 16:26 ` Josh Poimboeuf
2023-03-27 23:47 ` Stephen Rothwell
2023-04-11 21:34 ` Stephen Rothwell
2023-04-11 21:55 ` Josh Poimboeuf
2023-04-11 22:39 ` Jens Axboe
2023-04-12 0:14 ` Josh Poimboeuf
2023-04-12 1:48 ` Jens Axboe
2023-04-12 11:44 ` Peter Zijlstra
2023-04-12 16:25 ` Josh Poimboeuf
2023-04-12 16:35 ` Jens Axboe
2023-04-12 16:44 ` Jens Axboe
2023-04-12 16:56 ` Josh Poimboeuf
2023-04-12 17:57 ` Jens Axboe
2023-06-16 12:43 ` Peter Zijlstra
2023-06-16 12:49 ` Borislav Petkov
2023-07-03 11:04 ` Peter Zijlstra
2023-07-03 14:18 ` Jens Axboe
2023-07-03 15:14 ` Peter Zijlstra
2023-04-11 22:30 ` Jens Axboe
2022-07-15 11:51 Stephen Rothwell
2020-03-03 1:41 Stephen Rothwell
2020-03-03 2:59 ` Jens Axboe
2018-03-01 0:26 Stephen Rothwell
2018-03-01 4:02 ` Anshuman Khandual
2018-03-01 15:37 ` Jens Axboe
2011-01-07 0:02 Stephen Rothwell
2011-01-07 1:49 ` Mathieu Desnoyers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).