From: Jens Axboe <axboe@kernel.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: io-uring <io-uring@vger.kernel.org>, Keith Busch <kbusch@kernel.org>
Subject: Re: [GIT PULL] io_uring fixes for 6.0-rc1
Date: Fri, 12 Aug 2022 15:34:05 -0600 [thread overview]
Message-ID: <433f4500-427d-8581-b852-fbe257aa6120@kernel.dk> (raw)
In-Reply-To: <ca630c3c-80ad-ceff-61a9-63b253ba5dbd@kernel.dk>
On 8/12/22 3:08 PM, Jens Axboe wrote:
> On 8/12/22 3:01 PM, Jens Axboe wrote:
>> On 8/12/22 2:44 PM, Jens Axboe wrote:
>>> On Aug 12, 2022, at 2:28 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>>>
>>>> ?On Fri, Aug 12, 2022 at 5:46 AM Jens Axboe <axboe@kernel.dk> wrote:
>>>>>
>>>>> - Small series improving type safety of the sqe fields (Stefan)
>>>>
>>>> This doesn't work AT ALL.
>>>>
>>>> A basic allmodconfig build fails with tons of errors. It starts with
>>>>
>>>> In function ?io_kiocb_cmd_sz_check?,
>>>> inlined from ?io_prep_rw? at io_uring/rw.c:38:21:
>>>> ././include/linux/compiler_types.h:354:45: error: call to
>>>> ?__compiletime_assert_802? declared with attribute error: BUILD_BUG_ON
>>>> failed: cmd_sz > sizeof(struct io_cmd_data)
>>>> 354 | _compiletime_assert(condition, msg,
>>>> __compiletime_assert_, __COUNTER__)
>>>> | ^
>>>> ././include/linux/compiler_types.h:335:25: note: in definition of
>>>> macro ?__compiletime_assert?
>>>> 335 | prefix ## suffix();
>>>> \
>>>> | ^~~~~~
>>>> ././include/linux/compiler_types.h:354:9: note: in expansion of
>>>> macro ?_compiletime_assert?
>>>> 354 | _compiletime_assert(condition, msg,
>>>> __compiletime_assert_, __COUNTER__)
>>>> | ^~~~~~~~~~~~~~~~~~~
>>>> ./include/linux/build_bug.h:39:37: note: in expansion of macro
>>>> ?compiletime_assert?
>>>> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>>>> | ^~~~~~~~~~~~~~~~~~
>>>> ./include/linux/build_bug.h:50:9: note: in expansion of macro
>>>> ?BUILD_BUG_ON_MSG?
>>>> 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: "
>>>> #condition)
>>>> | ^~~~~~~~~~~~~~~~
>>>> ./include/linux/io_uring_types.h:496:9: note: in expansion of macro
>>>> ?BUILD_BUG_ON?
>>>> 496 | BUILD_BUG_ON(cmd_sz > sizeof(struct io_cmd_data));
>>>> | ^~~~~~~~~~~~
>>>>
>>>> and goes downhill from there.
>>>>
>>>> I don't think this can have seen any testing at all.
>>>
>>> Wtf? I always run allmodconfig before sending and it also ran testing.
>>> I?ll check shortly. Sorry about that, whatever went wrong here.
>>
>> My test box is still on the same sha from this morning, which is:
>>
>> commit 2ae08b36c06ea8df73a79f6b80ff7964e006e9e3 (origin/master, origin/HEAD)
>> Merge: 21f9c8a13bb2 8bb5e7f4dcd9
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date: Thu Aug 11 09:23:08 2022 -0700
>>
>> Merge tag 'input-for-v5.20-rc0' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
>>
>> with io_uring-6.0 (ff34d8d06a1f16b6a58fb41bfbaa475cc6c02497) and
>> block-6.0 (aa0c680c3aa96a5f9f160d90dd95402ad578e2b0) pulled in, and it
>> builds just fine for me:
>>
>> axboe@r7525 ~/gi/build (test)> make clean 9.827s
>> HOSTCC scripts/basic/fixdep
>> HOSTCC scripts/kconfig/conf.o
>> HOSTCC scripts/kconfig/confdata.o
>> HOSTCC scripts/kconfig/expr.o
>> LEX scripts/kconfig/lexer.lex.c
>> YACC scripts/kconfig/parser.tab.[ch]
>> HOSTCC scripts/kconfig/lexer.lex.o
>> HOSTCC scripts/kconfig/menu.o
>> HOSTCC scripts/kconfig/parser.tab.o
>> HOSTCC scripts/kconfig/preprocess.o
>> HOSTCC scripts/kconfig/symbol.o
>> HOSTCC scripts/kconfig/util.o
>> HOSTLD scripts/kconfig/conf
>> #
>> # No change to .config
>> #
>> axboe@r7525 ~/gi/build (test)> time make -j256 -s
>>
>> ________________________________________________________
>> Executed in 172.67 secs fish external
>> usr time 516.61 mins 396.00 micros 516.61 mins
>> sys time 44.40 mins 0.00 micros 44.40 mins
>>
>> using:
>>
>> axboe@r7525 ~/gi/build (test)> gcc --version
>> gcc (Debian 12.1.0-7) 12.1.0
>>
>> Puzzled, I'll keep poking...
>
> I re-did an allmodconfig, and also built on arm64, and I have to say I'm
> puzzled with what you are seeing. Updated to latest master as well,
> nothing. Furthermore, I have the build bot send me successful build
> notifications as well, not just the errors, and here's what it reported
> 12h ago:
>
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git io_uring-6.0
> branch HEAD: ff34d8d06a1f16b6a58fb41bfbaa475cc6c02497 io_uring: add missing BUILD_BUG_ON() checks for new io_uring_sqe fields
>
> elapsed time: 882m
>
> configs tested: 53
> configs skipped: 2
>
> The following configs have been built successfully.
> More configs may be tested in the coming days.
>
> gcc tested configs:
> um x86_64_defconfig
> um i386_defconfig
> i386 defconfig
> i386 randconfig-a014
> i386 randconfig-a012
> i386 randconfig-a016
> x86_64 randconfig-a013
> x86_64 randconfig-a011
> arc randconfig-r043-20220811
> arm defconfig
> x86_64 randconfig-a015
> m68k allmodconfig
> arc allyesconfig
> i386 allyesconfig
> i386 randconfig-a001
> x86_64 rhel-8.3-func
> i386 randconfig-a003
> x86_64 defconfig
> alpha allyesconfig
> mips allyesconfig
> arm allyesconfig
> x86_64 rhel-8.3-kunit
> m68k allyesconfig
> powerpc allnoconfig
> arm64 allyesconfig
> i386 randconfig-a005
> x86_64 rhel-8.3
> sh allmodconfig
> x86_64 rhel-8.3-kvm
> x86_64 allyesconfig
> x86_64 rhel-8.3-kselftests
> x86_64 rhel-8.3-syz
> x86_64 randconfig-a002
> x86_64 randconfig-a004
> x86_64 randconfig-a006
> ia64 allmodconfig
> powerpc allmodconfig
>
> clang tested configs:
> i386 randconfig-a011
> i386 randconfig-a013
> hexagon randconfig-r045-20220811
> hexagon randconfig-r041-20220811
> x86_64 randconfig-a012
> s390 randconfig-r044-20220811
> i386 randconfig-a015
> riscv randconfig-r042-20220811
> x86_64 randconfig-a014
> x86_64 randconfig-a016
> i386 randconfig-a002
> i386 randconfig-a006
> i386 randconfig-a004
> x86_64 randconfig-a001
> x86_64 randconfig-a003
> x86_64 randconfig-a005
>
> building that very same sha I sent you. WTF? I assure you this thing has
> been both built, and not just by me, and runtime tested as per usual.
> Why it fails on your end, I really have no good clue right now.
Keith brought up a good point, is this some weird randomization of
io_kiocb that makes it bigger? struct io_rw is already at 64-bytes as it
is, if it gets re-arranged for more padding maybe that's what you're
hitting? Is it just io_rw or are you seeing others?
--
Jens Axboe
next prev parent reply other threads:[~2022-08-12 21:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-12 12:46 [GIT PULL] io_uring fixes for 6.0-rc1 Jens Axboe
2022-08-12 20:28 ` Linus Torvalds
2022-08-12 20:44 ` Jens Axboe
2022-08-12 21:01 ` Jens Axboe
2022-08-12 21:08 ` Jens Axboe
2022-08-12 21:34 ` Jens Axboe [this message]
2022-08-12 21:43 ` Linus Torvalds
2022-08-12 21:53 ` Jens Axboe
2022-08-12 21:54 ` Linus Torvalds
2022-08-12 22:01 ` Linus Torvalds
2022-08-12 22:16 ` Jens Axboe
2022-08-12 22:11 ` Jens Axboe
2022-08-12 22:19 ` Jens Axboe
2022-08-12 22:23 ` Keith Busch
2022-08-12 22:25 ` Jens Axboe
2022-08-12 22:27 ` Jens Axboe
2022-08-12 22:35 ` Linus Torvalds
2022-08-12 22:38 ` Jens Axboe
2022-08-12 22:52 ` Linus Torvalds
2022-08-12 22:55 ` Jens Axboe
2022-08-12 21:37 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2022-08-11 1:01 Jens Axboe
2022-08-11 14:35 ` Jens Axboe
2022-08-13 21:48 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=433f4500-427d-8581-b852-fbe257aa6120@kernel.dk \
--to=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=kbusch@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.