linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Dean Luick <dean.luick@cornelisnetworks.com>
Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>,
	leonro@nvidia.com, linux-rdma@vger.kernel.org
Subject: Re: [PATCH for-rc 6/6] IB/hfi1: Remove user expected buffer invalidate race
Date: Thu, 19 Jan 2023 14:05:53 -0400	[thread overview]
Message-ID: <Y8mGgZqh90M6OfE8@nvidia.com> (raw)
In-Reply-To: <90652c2d-a874-fb24-3356-55c9b7003feb@cornelisnetworks.com>

On Thu, Jan 19, 2023 at 10:00:39AM -0600, Dean Luick wrote:
> On 1/18/2023 6:42 AM, Jason Gunthorpe wrote:
> > On Tue, Jan 17, 2023 at 01:19:14PM -0600, Dean Luick wrote:
> >> On 1/16/2023 9:41 AM, Jason Gunthorpe wrote:
> >>> On Mon, Jan 09, 2023 at 12:31:31PM -0500, Dennis Dalessandro wrote:
> >>>
> >>>> +    if (fd->use_mn) {
> >>>> +            ret = mmu_interval_notifier_insert(
> >>>> +                    &tidbuf->notifier, current->mm,
> >>>> +                    tidbuf->vaddr, tidbuf->npages * PAGE_SIZE,
> >>>> +                    &tid_cover_ops);
> >>>
> >>> This is still not the right way to use these notifiers, you should be
> >>> removing the calls to mmu_notifier_register()
> >>
> >> I am confused by your comment.  This is the user expected receive
> >> code.  There are no calls to mmu_notifier_register() here.  You
> >> removed those calls when you added the FIXME.  The Send DMA side
> >> still has calls to mmu_notifier_register().  This series is all
> >> about user expected receive.
> >
> > Then something else seems wrong because you shouldn't be removing the
> > notifiers in the same function you add them
> 
> The add-then-remove is intentional.  The purpose is to make sure
> there are no invalidates while we pin pages and set up the
> "permanent" notifiers that cover exact ranges based on sequential
> pages and how the DMA hardware is programmed.  Once the programmed
> hardware range notifiers are in place, the covering range serves no
> purpose and can be removed.

Uh, that doesn't sound very good, it is very expensive to create these
notifiers, they were not intended to be overly narrowed like this -
you are better to have a wider range and deal with the rare false hit
than to take the cost of register/unregister on every activity??

Also I'm not entirely sure this can be race free, having two notifiers
responsible for the same memory at the same time sounds like Danger
Danger sort of situation..

Jason

  reply	other threads:[~2023-01-19 18:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09 17:31 [PATCH for-rc 0/6] HFI fixups around expected recv Dennis Dalessandro
2023-01-09 17:31 ` [PATCH for-rc 1/6] IB/hfi1: Restore allocated resources on failed copyout Dennis Dalessandro
2023-01-10 10:12   ` Leon Romanovsky
2023-01-09 17:31 ` [PATCH for-rc 2/6] IB/hfi1: Reject a zero-length user expected buffer Dennis Dalessandro
2023-01-09 17:31 ` [PATCH for-rc 3/6] IB/hfi1: Reserve user expected TIDs Dennis Dalessandro
2023-01-09 17:31 ` [PATCH for-rc 4/6] IB/hfi1: Fix expected receive setup error exit issues Dennis Dalessandro
2023-01-09 17:31 ` [PATCH for-rc 5/6] IB/hfi1: Immediately remove invalid memory from hardware Dennis Dalessandro
2023-01-09 17:31 ` [PATCH for-rc 6/6] IB/hfi1: Remove user expected buffer invalidate race Dennis Dalessandro
2023-01-16 15:41   ` Jason Gunthorpe
2023-01-17 19:19     ` Dean Luick
2023-01-18 12:42       ` Jason Gunthorpe
2023-01-19 16:00         ` Dean Luick
2023-01-19 18:05           ` Jason Gunthorpe [this message]
2023-01-20 16:09             ` Dean Luick
2023-01-10 10:17 ` [PATCH for-rc 0/6] HFI fixups around expected recv Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y8mGgZqh90M6OfE8@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=dean.luick@cornelisnetworks.com \
    --cc=dennis.dalessandro@cornelisnetworks.com \
    --cc=leonro@nvidia.com \
    --cc=linux-rdma@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).