* 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
* 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 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
* 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 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 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
* 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-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-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* 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
* 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 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-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-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 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-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-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 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 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 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: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: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: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-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-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-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-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-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
* 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* 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 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
@ 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 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
* 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
* 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* 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
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).