On Tue, Dec 10, 2024 at 06:23:19PM +0100, Oleg Nesterov wrote:
> On 12/10, Oleg Nesterov wrote:
> >
> > I must have missed something, but...
> >
> > On 12/10, Lorenzo Stoakes wrote:
> > >
> > > @@ -1746,9 +1741,11 @@ static struct mm_struct *dup_mm(struct task_struct
> > > *tsk,
> > > if (!mm_in
On 12/10, Oleg Nesterov wrote:
>
> I must have missed something, but...
>
> On 12/10, Lorenzo Stoakes wrote:
> >
> > @@ -1746,9 +1741,11 @@ static struct mm_struct *dup_mm(struct task_struct
> > *tsk,
> > if (!mm_init(mm, tsk, mm->user_ns))
> > goto fail_nomem;
> >
> > + uprobe_s
I must have missed something, but...
On 12/10, Lorenzo Stoakes wrote:
>
> @@ -1746,9 +1741,11 @@ static struct mm_struct *dup_mm(struct task_struct
> *tsk,
> if (!mm_init(mm, tsk, mm->user_ns))
> goto fail_nomem;
>
> + uprobe_start_dup_mmap();
> err = dup_mmap(mm, o
On Tue, Dec 10, 2024 at 05:53:34PM +0100, Oleg Nesterov wrote:
> I must have missed something, but...
>
> On 12/10, Lorenzo Stoakes wrote:
> >
> > @@ -1746,9 +1741,11 @@ static struct mm_struct *dup_mm(struct task_struct
> > *tsk,
> > if (!mm_init(mm, tsk, mm->user_ns))
> > goto fa
If dup_mmap() encounters an issue, currently uprobe is able to access the
relevant mm via the reverse mapping (in build_map_info()), and if we are
very unlucky with a race window, observe invalid XA_ZERO_ENTRY state which
we establish as part of the fork error path.
This occurs because uprobe_writ
