From: "Hook, Gary" <ghook@amd.com>
To: Joe Perches <joe@perches.com>,
Colin King <colin.king@canonical.com>,
Joerg Roedel <joro@8bytes.org>,
iommu@lists.linux-foundation.org
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/amd: fix missing tag from dev_err message
Date: Tue, 3 Jul 2018 11:21:24 -0500 [thread overview]
Message-ID: <f3e15437-68c1-58eb-bc34-93fa70e50dc9@amd.com> (raw)
In-Reply-To: <d93bfa0f52d8907019b16336645986cd339ebf75.camel@perches.com>
On 7/3/2018 10:55 AM, Joe Perches wrote:
> On Tue, 2018-07-03 at 07:56 -0500, Gary R Hook wrote:
>> On 07/03/2018 05:07 AM, Joe Perches wrote:
>>> On Tue, 2018-07-03 at 07:40 +0100, Colin King wrote:
>>>> Currently tag is being assigned but not used, it is missing from
>>>> the dev_err message, so add it in.
>>>>
>>>> Cleans up clang warning:
>>>> warning: variable 'tag' set but not used [-Wunused-but-set-variable]
>>>
>>> []
>>>> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
>>>
>>> []
>>>> @@ -616,9 +616,9 @@ static void iommu_print_event(struct amd_iommu *iommu, void *__evt)
>>>> pasid = ((event[0] >> 16) & 0xFFFF)
>>>> | ((event[1] << 6) & 0xF0000);
>>>> tag = event[1] & 0x03FF;
>>>> - dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x pasid=0x%05x address=0x%016llx flags=0x%04x]\n",
>>>> + dev_err(dev, "INVALID_PPR_REQUEST device=%02x:%02x.%x pasid=0x%05x address=0x%016llx flags=0x%04x tag=0x%03x]\n",
>>>> PCI_BUS_NUM(devid), PCI_SLOT(devid), PCI_FUNC(devid),
>>>> - pasid, address, flags);
>>>> + pasid, address, flags, tag);
>>>
>>> Seems to have a superfluous ] that should be removed.
>>
>> Yeah, I pretty much messed up all of the log messages in that function.
>> My apologies. I'll create a patch for that problem; it shouldn't be
>> fixed here.
Well, no, I misremembered. The extraneous square brace has been there
forever. Needs fixin', though.
> I also wonder why event is declared volatile and then
> dereferenced with [<constant>] multiple times.
>
> Maybe each array dereference should be stored as a
> local variable instead.
(I know you know this, but as I understand it) Event is pointing into
the (hardware's) event buffer, and the data structure has the potential
of changing out from under us if the device does something without our
knowledge. Since volatile hints to the compiler of this possibility, I
believe the compiler should manage this situation. But I could be wrong.
I don't know that we need to atomically copy all 16 bytes into a local
buffer, as I don't think it's possible for the device to step on itself.
It will just stop recording events if the buffer gets full. At this
moment I think volatile is overkill, at least for the EPYC/Ryzen IOMMU.
next prev parent reply other threads:[~2018-07-03 16:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-03 6:40 Colin King
2018-07-03 10:07 ` Joe Perches
2018-07-03 12:56 ` Gary R Hook
2018-07-03 15:55 ` Joe Perches
2018-07-03 16:21 ` Hook, Gary [this message]
2018-07-03 16:24 ` Colin Ian King
2018-07-03 16:27 ` Hook, Gary
2018-07-03 16:38 ` Joe Perches
2018-07-03 12:54 ` Gary R Hook
2018-07-03 16:57 Walter Harms
2018-07-03 17:34 ` Joe Perches
2018-07-06 13:00 ` 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=f3e15437-68c1-58eb-bc34-93fa70e50dc9@amd.com \
--to=ghook@amd.com \
--cc=colin.king@canonical.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joe@perches.com \
--cc=joro@8bytes.org \
--cc=kernel-janitors@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®