All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.