Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Andrii Nakryiko
On Thu, Aug 15, 2024 at 11:58 AM Jann Horn wrote: > > +brauner for "struct file" lifetime > > On Thu, Aug 15, 2024 at 7:45 PM Suren Baghdasaryan wrote: > > On Thu, Aug 15, 2024 at 9:47 AM Andrii Nakryiko > > wrote: > > > > > > On Thu, Aug 15, 2024 at 6:44 AM Mateusz Guzik wrote: > > > > > > > >

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Suren Baghdasaryan
On Thu, Aug 15, 2024 at 11:58 AM Jann Horn wrote: > > +brauner for "struct file" lifetime > > On Thu, Aug 15, 2024 at 7:45 PM Suren Baghdasaryan wrote: > > On Thu, Aug 15, 2024 at 9:47 AM Andrii Nakryiko > > wrote: > > > > > > On Thu, Aug 15, 2024 at 6:44 AM Mateusz Guzik wrote: > > > > > > > >

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Mateusz Guzik
On Thu, Aug 15, 2024 at 8:58 PM Jann Horn wrote: > Stupid question: Is this uprobe stuff actually such a hot codepath > that it makes sense to optimize it to be faster than the page fault > path? > That's what I implicitly asked, hoping a down_read on vma would do it, but Andrii claims multiple p

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Jann Horn
+brauner for "struct file" lifetime On Thu, Aug 15, 2024 at 7:45 PM Suren Baghdasaryan wrote: > On Thu, Aug 15, 2024 at 9:47 AM Andrii Nakryiko > wrote: > > > > On Thu, Aug 15, 2024 at 6:44 AM Mateusz Guzik wrote: > > > > > > On Tue, Aug 13, 2024 at 08:36:03AM -0700, Suren Baghdasaryan wrote: >

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Mateusz Guzik
On Thu, Aug 15, 2024 at 10:45:45AM -0700, Suren Baghdasaryan wrote: > >From all the above, my understanding of your objection is that > checking mmap_lock during our speculation is too coarse-grained and > you would prefer to use the VMA seq counter to check that the VMA we > are working on is unch

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Suren Baghdasaryan
On Thu, Aug 15, 2024 at 9:47 AM Andrii Nakryiko wrote: > > On Thu, Aug 15, 2024 at 6:44 AM Mateusz Guzik wrote: > > > > On Tue, Aug 13, 2024 at 08:36:03AM -0700, Suren Baghdasaryan wrote: > > > On Mon, Aug 12, 2024 at 11:18 PM Mateusz Guzik wrote: > > > > > > > > On Mon, Aug 12, 2024 at 09:29:17

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Andrii Nakryiko
On Thu, Aug 15, 2024 at 6:44 AM Mateusz Guzik wrote: > > On Tue, Aug 13, 2024 at 08:36:03AM -0700, Suren Baghdasaryan wrote: > > On Mon, Aug 12, 2024 at 11:18 PM Mateusz Guzik wrote: > > > > > > On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote: > > > > Now that files_cachep is SLAB

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-15 Thread Mateusz Guzik
On Tue, Aug 13, 2024 at 08:36:03AM -0700, Suren Baghdasaryan wrote: > On Mon, Aug 12, 2024 at 11:18 PM Mateusz Guzik wrote: > > > > On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote: > > > Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely access > > > vma->vm_file->f_inode

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-13 Thread Suren Baghdasaryan
On Mon, Aug 12, 2024 at 11:18 PM Mateusz Guzik wrote: > > On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote: > > Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely access > > vma->vm_file->f_inode lockless only under rcu_read_lock() protection, > > attempting uprobe look up

Re: [PATCH RFC v3 13/13] uprobes: add speculative lockless VMA to inode resolution

2024-08-12 Thread Mateusz Guzik
On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote: > Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely access > vma->vm_file->f_inode lockless only under rcu_read_lock() protection, > attempting uprobe look up speculatively. > > We rely on newly added mmap_lock_speculation