From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
Jonathan Hunter <jonathanh@nvidia.com>,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH v5] iommu/tegra-smmu: Add locking around mapping operations
Date: Fri, 4 Sep 2020 14:19:49 +0200 [thread overview]
Message-ID: <20200904121949.GA570531@ulmo> (raw)
In-Reply-To: <20200901203730.27865-1-digetx@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1668 bytes --]
On Tue, Sep 01, 2020 at 11:37:30PM +0300, Dmitry Osipenko wrote:
> The mapping operations of the Tegra SMMU driver are subjected to a race
> condition issues because SMMU Address Space isn't allocated and freed
> atomically, while it should be. This patch makes the mapping operations
> atomic, it fixes an accidentally released Host1x Address Space problem
> which happens while running multiple graphics tests in parallel on
> Tegra30, i.e. by having multiple threads racing with each other in the
> Host1x's submission and completion code paths, performing IOVA mappings
> and unmappings in parallel.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>
> Changelog:
>
> v5: - Replaced GFP_NOWAIT check with __GFP_ATOMIC to fix "sleep in
> atomic context" warnings, NOWAIT != ATOMIC.
>
> v4: - Returned to use spinlock, but now using a smarter allocation
> logic that performs allocation in a sleeping context whenever
> possible.
>
> - Removed the stable tag because patch isn't portable as-is
> since the arguments of map/unmap() callbacks changed recently.
> Perhaps we could just ignore older kernels for now. It will be
> possible to fix older kernels with a custom patch if will be needed.
>
> v3: - No changes. Resending for visibility.
>
> drivers/iommu/tegra-smmu.c | 95 +++++++++++++++++++++++++++++++++-----
> 1 file changed, 84 insertions(+), 11 deletions(-)
Seems to work fine. Tested on Jetson TX1 with display and GPU, which are
the primary users of the SMMU.
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 156 bytes --]
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>,
Jonathan Hunter <jonathanh@nvidia.com>,
Krishna Reddy <vdumpa@nvidia.com>,
iommu@lists.linux-foundation.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5] iommu/tegra-smmu: Add locking around mapping operations
Date: Fri, 4 Sep 2020 14:19:49 +0200 [thread overview]
Message-ID: <20200904121949.GA570531@ulmo> (raw)
In-Reply-To: <20200901203730.27865-1-digetx@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]
On Tue, Sep 01, 2020 at 11:37:30PM +0300, Dmitry Osipenko wrote:
> The mapping operations of the Tegra SMMU driver are subjected to a race
> condition issues because SMMU Address Space isn't allocated and freed
> atomically, while it should be. This patch makes the mapping operations
> atomic, it fixes an accidentally released Host1x Address Space problem
> which happens while running multiple graphics tests in parallel on
> Tegra30, i.e. by having multiple threads racing with each other in the
> Host1x's submission and completion code paths, performing IOVA mappings
> and unmappings in parallel.
>
> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
> ---
>
> Changelog:
>
> v5: - Replaced GFP_NOWAIT check with __GFP_ATOMIC to fix "sleep in
> atomic context" warnings, NOWAIT != ATOMIC.
>
> v4: - Returned to use spinlock, but now using a smarter allocation
> logic that performs allocation in a sleeping context whenever
> possible.
>
> - Removed the stable tag because patch isn't portable as-is
> since the arguments of map/unmap() callbacks changed recently.
> Perhaps we could just ignore older kernels for now. It will be
> possible to fix older kernels with a custom patch if will be needed.
>
> v3: - No changes. Resending for visibility.
>
> drivers/iommu/tegra-smmu.c | 95 +++++++++++++++++++++++++++++++++-----
> 1 file changed, 84 insertions(+), 11 deletions(-)
Seems to work fine. Tested on Jetson TX1 with display and GPU, which are
the primary users of the SMMU.
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-09-04 12:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 20:37 [PATCH v5] iommu/tegra-smmu: Add locking around mapping operations Dmitry Osipenko
2020-09-01 20:37 ` Dmitry Osipenko
2020-09-04 12:19 ` Thierry Reding [this message]
2020-09-04 12:19 ` Thierry Reding
2020-09-04 12:27 ` Joerg Roedel
2020-09-04 12:27 ` Joerg Roedel
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=20200904121949.GA570531@ulmo \
--to=thierry.reding@gmail.com \
--cc=digetx@gmail.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@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.