On Sun, Jul 4, 2021 at 9:47 PM Zhang, Qiang <[email protected]> wrote: > > > > ________________________________________ > From: Bruce Ashfield <[email protected]> > Sent: Sunday, 4 July 2021 11:25 > To: Bruce Ashfield > Cc: Zhang, Qiang; [email protected] > Subject: Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: > Ratelimit event dump > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > On Fri, Jul 2, 2021 at 8:54 AM Bruce Ashfield via > lists.yoctoproject.org > <[email protected]> wrote: > > > > On Fri, Jul 2, 2021 at 1:47 AM Zhang, Qiang <[email protected]> > > wrote: > > > > > > > > > > > > ________________________________________ > > > From: Bruce Ashfield <[email protected]> > > > Sent: Monday, 7 June 2021 10:54 > > > To: Zhang, Qiang > > > Cc: [email protected] > > > Subject: Re: [linux-yocto] [linux-yocto v5.10] [PATCH] iommu/arm-smmu-v3: > > > Ratelimit event dump > > > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > > > On Fri, Jun 4, 2021 at 5:14 AM Zhang, Qiang <[email protected]> > > > wrote: > > > > > > > > > > > > > > > > ________________________________________ > > > > From: Bruce Ashfield <[email protected]> > > > > Sent: Thursday, 3 June 2021 05:05 > > > > To: Zhang, Qiang > > > > Cc: [email protected] > > > > Subject: Re: [linux-yocto] [linux-yocto v5.10] [PATCH] > > > > iommu/arm-smmu-v3: Ratelimit event dump > > > > > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > > > > > In message: [linux-yocto] [linux-yocto v5.10] [PATCH] > > > > iommu/arm-smmu-v3: Ratelimit event dump > > > > on 02/06/2021 [email protected] wrote: > > > > > > > > > From: Zqiang <[email protected]> > > > > > > > > > > When a device or driver misbehaves, it is possible to receive events > > > > > much faster than we can print them out. Ratelimit the printing of > > > > > events > > > > > > > > > > During the SVA tests when the device driver didn't properly stop DMA > > > > > before unbinding, the event queue thread would almost lock-up the > > > > > server > > > > > with a flood of event 0xa. This patch helped recover from the error. > > > > > > > > > > Tested-by: Aaro Koskinen <[email protected]> > > > > > Signed-off-by: Jean-Philippe Brucker <[email protected]> > > > > > Signed-off-by: Zqiang <[email protected]> > > > > > > > > > >Is there a link / reference to where this patch came from ? Judging > > > > >by the sign-offs, I assume it is from a mailing list ? > > > > > > > > > Hello Bruce > > > > > > > > https://lore.kernel.org/linux-iommu/[email protected]/#r > > > > > > >Are you tracking the subsystem tree ? > > > > > > > >I don't see any acked-by or reviewed-by on the list or in the lore link. > > > > > > Hello Bruce > > > > > > This change have been megre to linux-next > > > > > > > Excellent. I'll get it queued today. > > >I ran into some issues when queuing the change, largely around the > >fact that the linux-next / mainline version is different than the one > >you originally submitted. > > >The final version of this change depends on 395ad89d11fd93f > >[iommu/arm-smmu-v3: Add stall support for platform devices], which of > >course is a more invasive change. > > > >That being said, it did apply cleanly to 5.10, and then the ratelimit > >patch stacks cleanly as well. > > > >I'm not set up to test that the fix is correct. Can you do the same > >cherry pick and see if the result is what you are looking for ? > > Hello Bruce > > Yes, this patch can apply to v5.10, the v5.13 is not apply, in v5.13 this > patch depend on 395ad89d11fd93f [iommu/arm-smmu-v3: Add stall support for > platform devices]. > I just migrated this change 9cff922bba [iommu/arm-smmu-v3: Ratelimit event > dump ] to v5.10, and this be talk in > > https://patchwork.kernel.org/project/linux-arm-kernel/patch/[email protected]/ > > this patch [iommu/arm-smmu-v3: Ratelimit event dump ] can be sent > independently of other patches.
I wasn't clear. I would rather not merge this patch to v5.10, when the upstream version is different. Which is why I'm asking about doing the cherry-pick of both patches, and not using the one at all in this thread. At a minimum, the shortlog of this patch should be changed to be different from the one that merged and a description of why we can't backport the stall patch in the log. Otherwise, I'm creating a support problem. Bruce > > Thanks > Qiang > > > > > >Bruce > > > > > Bruce > > > > > commit 9cff922bba429b310507eac3b6cb5eb1b57e9ad1 > > > Author: Jean-Philippe Brucker <[email protected]> > > > Date: Mon May 31 11:56:50 2021 +0200 > > > > > > iommu/arm-smmu-v3: Ratelimit event dump > > > > > > When a device or driver misbehaves, it is possible to receive DMA > > > fault > > > events much faster than we can print them out, causing a lock up of > > > the > > > system and inability to cancel the source of the problem. Ratelimit > > > printing of events to help recovery. > > > > > > Tested-by: Aaro Koskinen <[email protected]> > > > Signed-off-by: Jean-Philippe Brucker <[email protected]> > > > Link: > > > https://lore.kernel.org/r/[email protected] > > > Signed-off-by: Will Deacon <[email protected]> > > > > > > Thanks > > > Qiang > > > > > > > > > >I'm trying to track down that this has been queued for linux-next and > > > >merging, that gives us confidence for v5.10/standard/base > > > > > > > >Without that, I'd prefer to merge this to branches just for the BSPs > > > >that are seeing issues with the event dump. Do we have a list of > > > >impacted boards or is it generally hitting various ARM BSPs ? > > > > > > > >Bruce > > > > > > > > > > > thanks > > > > Qiang > > > > >Also, were you targetting v5.10/standard/base ? If so, we want that > > > > >link even more. > > > > > > > > > >Bruce > > > > > > > > > --- > > > > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 12 ++++++++---- > > > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > > b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > > index 7067b7c11626..583db3dd1465 100644 > > > > > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > > > > > @@ -1357,16 +1357,20 @@ static irqreturn_t arm_smmu_evtq_thread(int > > > > > irq, void *dev) > > > > > struct arm_smmu_device *smmu = dev; > > > > > struct arm_smmu_queue *q = &smmu->evtq.q; > > > > > struct arm_smmu_ll_queue *llq = &q->llq; > > > > > + static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL, > > > > > + DEFAULT_RATELIMIT_BURST); > > > > > u64 evt[EVTQ_ENT_DWORDS]; > > > > > > > > > > do { > > > > > while (!queue_remove_raw(q, evt)) { > > > > > u8 id = FIELD_GET(EVTQ_0_ID, evt[0]); > > > > > > > > > > - dev_info(smmu->dev, "event 0x%02x received:\n", > > > > > id); > > > > > - for (i = 0; i < ARRAY_SIZE(evt); ++i) > > > > > - dev_info(smmu->dev, "\t0x%016llx\n", > > > > > - (unsigned long long)evt[i]); > > > > > + if (__ratelimit(&rs)) { > > > > > + dev_info(smmu->dev, "event 0x%02x > > > > > received:\n", id); > > > > > + for (i = 0; i < ARRAY_SIZE(evt); ++i) > > > > > + dev_info(smmu->dev, > > > > > "\t0x%016llx\n", > > > > > + (unsigned long > > > > > long)evt[i]); > > > > > + } > > > > > > > > > > } > > > > > > > > > > -- > > > > > 2.31.1 > > > > > > > > > > > > > > > > > -- > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > thee at its end > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10043): https://lists.yoctoproject.org/g/linux-yocto/message/10043 Mute This Topic: https://lists.yoctoproject.org/mt/83252521/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
