Re: Crash when attaching uretprobes to processes running in Docker

[Eyal Birger <eyal.birger@gmail.com>]

Hi,

> On Jan 14, 2025, at 15:52, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> 
> On Tue, Jan 14, 2025 at 2:11 PM Oleg Nesterov <oleg@redhat.com> wrote:
>> 
>>> On 01/14, Andrii Nakryiko wrote:
>>> 
>>> On Tue, Jan 14, 2025 at 12:40 PM Oleg Nesterov <oleg@redhat.com> wrote:
>>>> 
>>>> 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
> 
>> Oleg.
>>