On Mon, 2025-06-09 at 19:15 +0200, Johannes Berg wrote:
> On Sun, 2025-06-08 at 20:38 +0200, Benjamin Berg wrote:
> > >
> > > But my host kernel is 5.4 and fails to compile these pieces of
> > > codes because
> > > there is no this syscall in my older kernel.
> > >
> > > I was wondering if you ar
On Sun, 2025-06-08 at 20:38 +0200, Benjamin Berg wrote:
> >
> > But my host kernel is 5.4 and fails to compile these pieces of codes because
> > there is no this syscall in my older kernel.
> >
> > I was wondering if you are working on this issue. If not, I will try to
> > make a draft solution
Hi,
On Mon, Jun 9, 2025 at 2:38 AM Benjamin Berg wrote:
>
> Hi,
>
> On Sat, 2025-06-07 at 12:22 +0800, Yonting Lin wrote:
> > [SNIP]
> >
> > Sorry for my due enquiry, I don't want take a new thread with a patch.
> > It is just a short question.
> >
> > Currently(119b1e61a769aa98e68599f44721661a4d
Hi,
On Sat, 2025-06-07 at 12:22 +0800, Yonting Lin wrote:
> [SNIP]
>
> Sorry for my due enquiry, I don't want take a new thread with a patch.
> It is just a short question.
>
> Currently(119b1e61a769aa98e68599f44721661a4d8c55f3), there are three pieces
> of code calling to syscall __NR_close_ran
Hi Glenn,
Sun, 12 Jan 2025 14:07:36 -0600
Glenn Washburn wrote:
>On Fri, 10 Jan 2025 17:13:05 +0100
>Benjamin Berg wrote:
>
>> From: Benjamin Berg
>>
>> The stub execution uses the somewhat new close_range and execveat
>> syscalls. Of these two, the execveat call is essential, but the
>> close
Hi,
On Sun, 2025-01-12 at 14:07 -0600, Glenn Washburn wrote:
> On Fri, 10 Jan 2025 17:13:05 +0100
> Benjamin Berg wrote:
>
> > From: Benjamin Berg
> >
> > The stub execution uses the somewhat new close_range and execveat
> > syscalls. Of these two, the execveat call is essential, but the
> > c
On Fri, 10 Jan 2025 17:13:05 +0100
Benjamin Berg wrote:
> From: Benjamin Berg
>
> The stub execution uses the somewhat new close_range and execveat
> syscalls. Of these two, the execveat call is essential, but the
> close_range call is more about stub process hygiene rather than safety
> (and i
