From: Dmitry Safonov via iommu <iommu@lists.linux-foundation.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Joerg Roedel <jroedel@suse.de>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 4.19 17/32] iommu/vt-d: Dont queue_iova() if there is no flush queue
Date: Wed, 7 Aug 2019 00:16:21 +0100 [thread overview]
Message-ID: <858b5409-d8ed-5ff1-2daf-3f6287fb5c8e@arista.com> (raw)
In-Reply-To: <dc639510-5d88-5b05-a973-5f4b7c720f76@arista.com>
On 8/6/19 11:47 PM, Dmitry Safonov wrote:
> Hi Pavel,
>
> On 8/3/19 10:34 PM, Pavel Machek wrote:
>> Hi!
>>
>>> --- a/drivers/iommu/intel-iommu.c
>>> +++ b/drivers/iommu/intel-iommu.c
>>> @@ -3721,7 +3721,7 @@ static void intel_unmap(struct device *d
>>>
>>> freelist = domain_unmap(domain, start_pfn, last_pfn);
>>>
>>> - if (intel_iommu_strict) {
>>> + if (intel_iommu_strict || !has_iova_flush_queue(&domain->iovad)) {
>>> iommu_flush_iotlb_psi(iommu, domain, start_pfn,
>>> nrpages, !freelist, 0);
>>> /* free iova */
>>> --- a/drivers/iommu/iova.c
>>> +++ b/drivers/iommu/iova.c
>>> @@ -65,9 +65,14 @@ init_iova_domain(struct iova_domain *iov
>>> }
>>> EXPORT_SYMBOL_GPL(init_iova_domain);
>>>
>>> +bool has_iova_flush_queue(struct iova_domain *iovad)
>>> +{
>>> + return !!iovad->fq;
>>
>> Should this be READ_ONCE()?
>
> Why? Compiler can't anyhow assume that it's always true/false and there
> is a clear data dependency between this and:
> : queue_iova(&domain->iovad, iova_pfn, nrpages,
> : (unsigned long)freelist);
>
>>
>>> @@ -100,13 +106,17 @@ int init_iova_flush_queue(struct iova_do
>>> for_each_possible_cpu(cpu) {
>>> struct iova_fq *fq;
>>>
>>> - fq = per_cpu_ptr(iovad->fq, cpu);
>>> + fq = per_cpu_ptr(queue, cpu);
>>> fq->head = 0;
>>> fq->tail = 0;
>>>
>>> spin_lock_init(&fq->lock);
>>> }
>>>
>>> + smp_wmb();
>>> +
>>> + iovad->fq = queue;
>>> +
>>
>> Could we have a comment why the barrier is needed,
>
> I'm up for the comment if you feel like it - in my POV it's quite
> obvious that we want finish initializing the queue's internals before
> assigning the queue. I didn't put the comment exactly because I felt
> like it would state something evident [in my POV].
>
>> and perhaps there
>> should be oposing smp_rmb() somewhere? Does this need to be
>> WRITE_ONCE() as it is racing against reader?
>
> I feel confused. I might have forgotten everything about barriers, but
> again if I'm not mistaken, one doesn't need a barrier in:
> : if (A->a != NULL)
> : use(A); /* dereferences A->a */
> : else
> : /* don't use `a' */
And in this simplified example I mean that use() will either see A->a
initialized (IOW, CPU can't load A->a->field1 before checking the
condition) or use() will not be called.
Thanks,
Dmitry
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
prev parent reply other threads:[~2019-08-06 23:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190802092101.913646560@linuxfoundation.org>
2019-08-02 9:39 ` [PATCH 4.19 17/32] iommu/vt-d: Dont queue_iova() if there is no flush queue Greg Kroah-Hartman
2019-08-03 21:34 ` Pavel Machek
2019-08-06 22:47 ` Dmitry Safonov via iommu
2019-08-06 23:16 ` Dmitry Safonov via iommu [this message]
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=858b5409-d8ed-5ff1-2daf-3f6287fb5c8e@arista.com \
--to=iommu@lists.linux-foundation.org \
--cc=dima@arista.com \
--cc=dwmw2@infradead.org \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/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