Re: [GIT PULL] io_uring fixes for 6.0-rc1

[Jens Axboe <axboe@kernel.dk>]

On 8/12/22 3:43 PM, Linus Torvalds wrote:
> [ Crossed emails ]
> 
> On Fri, Aug 12, 2022 at 2:34 PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> 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?
> 
> I think was seeing others (I got hundreds of lines or errors), but now
> that I've blown things away I can't recreate it. My allmodconfig build
> just completed with no sign of the errors I saw earlier.
> 
> I think Keith is right. An allmodconfig build for me has
> 
>   CONFIG_RANDSTRUCT=y
>   CONFIG_GCC_PLUGIN_RANDSTRUCT=y
> 
> and the io_uring "type safety" isn't actually typesafe: it just checks
> the size of types.

I think Keith is right too...

> The other alternative is that we have some build dependency issue, and
> blowing away my old tree fixed things. But that sounds unlikely, we
> haven't had those kinds of issues in a long time.

I would've said we just revert it, but this looks broken now with the
io_cmd_data layout. Before this release, it just would've grown io_kiocb
a bit and spilled into the next cacheline for per-command data. And
while that isn't ideal for performance reasons, it's not like it
wouldn't work. But now we have it specifically set aside 64 bytes for
command data, where it really should be the max any command type would
use rather than a hard-coded 64 bytes. I suspect io_rw is the only one
that'd hit this, exactly because of the randomization in struct kiocb.
If anything else went beyond, we'd find it during development, not while
it was in-tree.

I'll ponder a solution to this...

-- 
Jens Axboe