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:
> > > >
> > > >
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:
> > > >
> > > >
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
+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:
>
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
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
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
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
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
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
10 matches
Mail list logo