| Message ID | 20200327225102.25061-8-walken@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add a new mmap locking API wrapping mmap_sem calls | expand |
On Fri, Mar 27, 2020 at 03:50:59PM -0700, Michel Lespinasse wrote: > Add a couple APIs to allow splitting mmap_read_unlock() into two calls: > - mmap_read_release(), called by the task that had taken the mmap lock; > - mmap_read_unlock_non_owner(), called from a work queue. > > These apis are used by kernel/bpf/stackmap.c only. That code is an absolute abomination and should never have gotten merged. That said; I would prefer a mmap_read_trylock_nonowner() over mmap_read_release() existing. > Signed-off-by: Michel Lespinasse <walken@google.com> > --- > include/linux/mmap_lock.h | 10 ++++++++++ > kernel/bpf/stackmap.c | 9 ++++----- > 2 files changed, 14 insertions(+), 5 deletions(-) > > diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h > index 36fb758401d6..a80cf9695514 100644 > --- a/include/linux/mmap_lock.h > +++ b/include/linux/mmap_lock.h > @@ -62,4 +62,14 @@ static inline void mmap_read_unlock(struct mm_struct *mm) > up_read(&mm->mmap_sem); > } > > +static inline void mmap_read_release(struct mm_struct *mm, unsigned long ip) > +{ > + rwsem_release(&mm->mmap_sem.dep_map, ip); > +} > + > +static inline void mmap_read_unlock_non_owner(struct mm_struct *mm) > +{ > + up_read_non_owner(&mm->mmap_sem); > +} > + > #endif /* _LINUX_MMAP_LOCK_H */
On Wed, Apr 1, 2020 at 6:46 AM Peter Zijlstra <peterz@infradead.org> wrote: > On Fri, Mar 27, 2020 at 03:50:59PM -0700, Michel Lespinasse wrote: > > Add a couple APIs to allow splitting mmap_read_unlock() into two calls: > > - mmap_read_release(), called by the task that had taken the mmap lock; > > - mmap_read_unlock_non_owner(), called from a work queue. > > > > These apis are used by kernel/bpf/stackmap.c only. > > That code is an absolute abomination and should never have gotten > merged. I have to say, it's causing me some grief too :/ > That said; I would prefer a mmap_read_trylock_nonowner() over > mmap_read_release() existing. It only addresses part of the issue, but I suppose I could do that. Is this something I could append to the end of this series, or do I need to prepare a v4 for such changes ?
diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h index 36fb758401d6..a80cf9695514 100644 --- a/include/linux/mmap_lock.h +++ b/include/linux/mmap_lock.h @@ -62,4 +62,14 @@ static inline void mmap_read_unlock(struct mm_struct *mm) up_read(&mm->mmap_sem); } +static inline void mmap_read_release(struct mm_struct *mm, unsigned long ip) +{ + rwsem_release(&mm->mmap_sem.dep_map, ip); +} + +static inline void mmap_read_unlock_non_owner(struct mm_struct *mm) +{ + up_read_non_owner(&mm->mmap_sem); +} + #endif /* _LINUX_MMAP_LOCK_H */ diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c index f2115f691577..413b512a99eb 100644 --- a/kernel/bpf/stackmap.c +++ b/kernel/bpf/stackmap.c @@ -33,7 +33,7 @@ struct bpf_stack_map { /* irq_work to run up_read() for build_id lookup in nmi context */ struct stack_map_irq_work { struct irq_work irq_work; - struct rw_semaphore *sem; + struct mm_struct *mm; }; static void do_up_read(struct irq_work *entry) @@ -41,8 +41,7 @@ static void do_up_read(struct irq_work *entry) struct stack_map_irq_work *work; work = container_of(entry, struct stack_map_irq_work, irq_work); - up_read_non_owner(work->sem); - work->sem = NULL; + mmap_read_unlock_non_owner(work->mm); } static DEFINE_PER_CPU(struct stack_map_irq_work, up_read_work); @@ -332,14 +331,14 @@ static void stack_map_get_build_id_offset(struct bpf_stack_build_id *id_offs, if (!work) { mmap_read_unlock(current->mm); } else { - work->sem = ¤t->mm->mmap_sem; + work->mm = current->mm; irq_work_queue(&work->irq_work); /* * The irq_work will release the mmap_sem with * up_read_non_owner(). The rwsem_release() is called * here to release the lock from lockdep's perspective. */ - rwsem_release(¤t->mm->mmap_sem.dep_map, _RET_IP_); + mmap_read_release(current->mm, _RET_IP_); } }
Add a couple APIs to allow splitting mmap_read_unlock() into two calls: - mmap_read_release(), called by the task that had taken the mmap lock; - mmap_read_unlock_non_owner(), called from a work queue. These apis are used by kernel/bpf/stackmap.c only. Signed-off-by: Michel Lespinasse <walken@google.com> --- include/linux/mmap_lock.h | 10 ++++++++++ kernel/bpf/stackmap.c | 9 ++++----- 2 files changed, 14 insertions(+), 5 deletions(-)