Hi,

On Jan 14, 2025, at 15:52, Andrii Nakryiko [off-list ref] wrote:

On Tue, Jan 14, 2025 at 2:11 PM Oleg Nesterov [off-list ref] wrote:

quoted

quoted

On 01/14, Andrii Nakryiko wrote:

On Tue, Jan 14, 2025 at 12:40 PM Oleg Nesterov [off-list ref] wrote:

quoted

But, unlike sys_uretprobe(), sys_rt_sigreturn() is old, so the existing
setups must know that sigreturn() should be respected...

someday sys_uretprobe will be old as well ;) FWIW, systemd allowlisted
sys_uretprobe, see [0]

And I agree! ;)

I mean, I'd personally prefer to do nothing and wait until userspace figures
out that we have another "special" syscall.

But can we do it? I simply do not know. Can we ignore this (valid) bug report?

Seems wrong for kernel to try to guess whether some syscall is
filtered by some policy or not (though maybe I'm misunderstanding the
details and it's kernel-originated problem?). Seems like a recipe for
more problems.

Nothing is really fundamentally broken. Some piece of software needs
an upgraded library to not disable the kernel's special syscall (just
like sys_rt_sigreturn, nothing "new" here, really). Users can't do
uprobing in such broken setups (but not in general), seems like a good
incentive for everyone to push for the right thing here: fixed up to
date software.

It’s not “users” doing the uprobing in this case.
Its software, that’s working fine in previous kernel versions and upon upgrade starts creating crashes in other processes.

IMHO demanding that other software (e.g docker) be upgraded in order to run on a newer kernel is not what Linux formerly guaranteed.

Eyal

quoted

Oleg.