Re: [PATCH 02/12] uprobes: grab write mmap lock in unapply_uprobe()
On 06/25, Andrii Nakryiko wrote: > > On Tue, Jun 25, 2024 at 7:51 AM Oleg Nesterov wrote: > > > > Why? > > > > So far I don't understand this change. Quite possibly I missed something, > > but in this case the changelog should explain the problem more clearly. > > > > I just went off of "Called with mm->mmap_lock held for write." comment > in uprobe_write_opcode(), tbh. Ah, indeed... and git blame makes me sad ;) I _think_ that 29dedee0e693a updated this comment without any thinking, but today I can't recall. In any case, today this nothing to do with mem_cgroup_charge(). Not sure __replace_page() is correct (in this respect) when it returns -EAGAIN but this is another story. > If we don't actually need writer > mmap_lock, we should probably update at least that comment. Agreed. > There is a > lot going on in uprobe_write_opcode(), and I don't understand all the > requirements there. Heh. Neither me today ;) Oleg.
Re: [PATCH 02/12] uprobes: grab write mmap lock in unapply_uprobe()
On 06/25, Masami Hiramatsu wrote: > > On Mon, 24 Jun 2024 17:21:34 -0700 > Andrii Nakryiko wrote: > > > Given unapply_uprobe() can call remove_breakpoint() which eventually > > calls uprobe_write_opcode(), which can modify a set of memory pages and > > expects mm->mmap_lock held for write, it needs to have writer lock. > > Oops, it is an actual bug, right? Why? So far I don't understand this change. Quite possibly I missed something, but in this case the changelog should explain the problem more clearly. Oleg.
Re: [PATCH 04/12] uprobes: revamp uprobe refcounting and lifetime management
Again, I'll try to read (at least this) patch later this week, just one cosmetic nit for now... On 06/24, Andrii Nakryiko wrote: > > + * UPROBE_REFCNT_GET constant is chosen such that it will *increment both* > + * epoch and refcnt parts atomically with one atomic_add(). > + * UPROBE_REFCNT_PUT is chosen such that it will *decrement* refcnt part and > + * *increment* epoch part. > + */ > +#define UPROBE_REFCNT_GET ((1LL << 32) | 1LL) > +#define UPROBE_REFCNT_PUT (0xLL) How about #define UPROBE_REFCNT_GET ((1ULL << 32) + 1ULL) #define UPROBE_REFCNT_PUT ((1ULL << 32) - 1ULL) ? this makes them symmetrical and makes it clear why atomic64_add(UPROBE_REFCNT_PUT) works as described in the comment. Feel free to ignore if you don't like it. Oleg.
Re: [PATCH 02/12] uprobes: grab write mmap lock in unapply_uprobe()
I don't think I can review, I forgot everything, but I'll try to read this series when I have time to (try to) understand what it does... On 06/24, Andrii Nakryiko wrote: > > Given unapply_uprobe() can call remove_breakpoint() which eventually > calls uprobe_write_opcode(), which can modify a set of memory pages and > expects mm->mmap_lock held for write, it needs to have writer lock. > > Fix this by switching to mmap_write_lock()/mmap_write_unlock(). > > Fixes: da1816b1caec ("uprobes: Teach handler_chain() to filter out the probed > task") > Signed-off-by: Andrii Nakryiko > --- > kernel/events/uprobes.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > index 197fbe4663b5..e896eeecb091 100644 > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -1235,7 +1235,7 @@ static int unapply_uprobe(struct uprobe *uprobe, struct > mm_struct *mm) > struct vm_area_struct *vma; > int err = 0; > > - mmap_read_lock(mm); > + mmap_write_lock(mm); Can you explain what exactly is wrong? FOLL_FORCE/etc is fine under mmap_read_lock(), __replace_page() seems too... I recall that initially uprobes.c always took mmap_sem for reading, then register_for_each_vma() was changed by 77fc4af1b59d12 but there was other reasons for this change... Again, I don't understand this code today, quite possibly I missed something, I am just trying to understand. Well, it seems there is another reason for this change... Currently 2 unapply_uprobe()'s can race with each other if they try to update the same page. But in this case we can rely on -EAGAIN from __replace_page() ? Oleg.
Re: [PATCH] uprobes: prevent mutex_lock() under rcu_read_lock()
On 05/20, Andrii Nakryiko wrote: > > Fixes: 1b8f85defbc8 ("uprobes: prepare uprobe args buffer lazily") > Reported-by: Breno Leitao > Signed-off-by: Andrii Nakryiko > --- > kernel/trace/trace_uprobe.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) Reviewed-by: Oleg Nesterov