All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Qian Cai <cai@lca.pw>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] iommu/amd: fix a race in fetch_pte()
Date: Sat, 18 Apr 2020 14:10:22 +0200	[thread overview]
Message-ID: <20200418121022.GA6113@8bytes.org> (raw)
In-Reply-To: <4FAF3A63-8DC8-4489-B5FE-95B716EF25AE@lca.pw>

On Thu, Apr 16, 2020 at 09:42:41PM -0400, Qian Cai wrote:
> So, this is still not enough that would still trigger storage driver offline under
> memory pressure for a bit longer. It looks to me that in fetch_pte() there are
> could still racy?

Yes, your patch still looks racy. You need to atomically read
domain->pt_root to a stack variable and derive the pt_root pointer and
the mode from that variable instead of domain->pt_root directly. If you
read the domain->pt_root twice there could still be an update between
the two reads.
Probably the lock in increase_address_space() can also be avoided if
pt_root is updated using cmpxchg()?

Regards,

	Joerg

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Qian Cai <cai@lca.pw>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] iommu/amd: fix a race in fetch_pte()
Date: Sat, 18 Apr 2020 14:10:22 +0200	[thread overview]
Message-ID: <20200418121022.GA6113@8bytes.org> (raw)
In-Reply-To: <4FAF3A63-8DC8-4489-B5FE-95B716EF25AE@lca.pw>

On Thu, Apr 16, 2020 at 09:42:41PM -0400, Qian Cai wrote:
> So, this is still not enough that would still trigger storage driver offline under
> memory pressure for a bit longer. It looks to me that in fetch_pte() there are
> could still racy?

Yes, your patch still looks racy. You need to atomically read
domain->pt_root to a stack variable and derive the pt_root pointer and
the mode from that variable instead of domain->pt_root directly. If you
read the domain->pt_root twice there could still be an update between
the two reads.
Probably the lock in increase_address_space() can also be avoided if
pt_root is updated using cmpxchg()?

Regards,

	Joerg


  reply	other threads:[~2020-04-18 12:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07  2:12 [RFC PATCH] iommu/amd: fix a race in fetch_pte() Qian Cai
2020-04-07  2:12 ` Qian Cai
2020-04-07 15:36 ` Qian Cai
2020-04-07 15:36   ` Qian Cai
2020-04-08 14:19   ` Joerg Roedel
2020-04-08 14:19     ` Joerg Roedel
2020-04-14  1:36     ` Qian Cai
2020-04-14  1:36       ` Qian Cai
2020-04-17  1:42       ` Qian Cai
2020-04-17  1:42         ` Qian Cai
2020-04-18 12:10         ` Joerg Roedel [this message]
2020-04-18 12:10           ` Joerg Roedel
2020-04-18 13:01           ` Qian Cai
2020-04-18 13:01             ` Qian Cai
2020-04-18 18:34             ` Joerg Roedel
2020-04-18 18:34               ` Joerg Roedel
2020-04-20  2:07               ` Qian Cai
2020-04-20  2:07                 ` Qian Cai
2020-04-20 13:26               ` Qian Cai
2020-04-20 13:26                 ` Qian Cai
2020-04-29  8:47                 ` Joerg Roedel
2020-04-29  8:47                   ` Joerg Roedel
2020-04-29 11:20                 ` Joerg Roedel
2020-04-29 11:20                   ` Joerg Roedel
2020-04-30  1:04                   ` Qian Cai
2020-04-30  1:04                     ` Qian Cai
2020-05-03 13:04                   ` Qian Cai
2020-05-03 13:04                     ` Qian Cai
2020-05-03 18:39                     ` Joerg Roedel
2020-05-03 18:39                       ` Joerg Roedel
2020-05-03 19:12                       ` Qian Cai
2020-05-03 19:12                         ` Qian Cai

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=20200418121022.GA6113@8bytes.org \
    --to=joro@8bytes.org \
    --cc=cai@lca.pw \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.