Performance definitely is impacted by not having native asynchronous I/O enabled.

Which operating system kernel is your container host running on? This should be a problem with the container environment. MariaDB is basically just a messenger here.

I read somewhere that disabling name resolving could solve the issue. But that is already disabled.

> Which operating system kernel is your container host running on?

The server is Debian 12.
Linux version 6.1.0-25-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26)

I also noticed that ulimit -l (memlock) was rather low in the container. It gave 8192 (K).
I added several values to docker run including --ulimit memlock=268435456:268435456 but to no avail.

But note: The old 10.5.23 container has the same low memlock value.

10.5 didn't have io_uring which is why its unaffected.

On the late kernel version you have memlock limits don't apply to uring any more (and the error would be different if it did - it would tell the required size or ENOMEM I think from memory).

skip_name_resolve as a solution is very odd. They aren't connected to io_uring. Internet answers always have a few random answers.

This is probably seccomp filters blocking io_uring in the default profile - https://github.com/moby/moby/commit/891241e7e74d4aae6de5f6125574eb994f25e169

Apparently https://github.com/moby/moby/issues/41371#issuecomment-1984972151 still the case, --security-opt=seccomp:unconfined. or create a custom seccomp profile - https://podman.io/blogs/2019/10/15/generate-seccomp-profiles.

If you do create a profile, a contribution on https://github.com/MariaDB/mariadb-docker would be most welcome.

Some text for a https://mariadb.com/kb/en/docker-official-image-frequently-asked-questions/ is probably the next step.

Thanks, Daniel. I am wondering if it was a good decision to use liburing if it is considered exploitable and we have to change sec profiles to get it working..

Docker does recommend to not change the default profile. And running unconfined to unblock liburing is no good strategy imo. Too bad that we cant pass an exception for liburing only on the docker run (without composing new seccomp profiles).

That said, I would argue that this is not just a matter of documentation. Since MariaDB is dockerized 'everywhere', this affects many people. Those who dont see it, have a degraded performance and others should be lowering security barriers. No nice choice.

In the meantime I stick to the latest 10.5 but has no good future either

Appreciating all prompt comments btw !

Ack, its a tough assessment. I went as far as moby revert -> Blackhat link, page 6, https://syzkaller.appspot.com/upstream/fixed - check current io_uring in search results (which is scarier than I hoped).

As all security exploitable is a really tough assessment, to work out.

On the plus side, if you consider mariadb is doing the uring, anything user attempted as exploitable needs to get into MariaDB's layers too, so if there's an exploit, its a tough one for a SQL user to inject.

> Since MariaDB is dockerized 'everywhere', this affects many people. Those who dont see it, have a degraded performance and others should be lowering security barriers. No nice choice.

MDEV-36182 is having contemplation for dual libaio fallback from liburing.

> In the meantime I stick to the latest 10.5 but has no good future either

Unclear if the degraded performance is actually worse than 10.5. Either way this is IO speed only. Welcome feedback on anyone who does benchmarks.