From: Greg KH <gregkh@linuxfoundation.org> To: Yicong Yang <yangyicong@huawei.com> Cc: yangyicong@hisilicon.com, alexander.shishkin@linux.intel.com, leo.yan@linaro.org, james.clark@arm.com, will@kernel.org, robin.murphy@arm.com, acme@kernel.org, peterz@infradead.org, corbet@lwn.net, mathieu.poirier@linaro.org, mark.rutland@arm.com, jonathan.cameron@huawei.com, john.garry@huawei.com, helgaas@kernel.org, lorenzo.pieralisi@arm.com, suzuki.poulose@arm.com, joro@8bytes.org, shameerali.kolothum.thodi@huawei.com, mingo@redhat.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, linux-perf-users@vger.kernel.org, iommu@lists.linux-foundation.org, iommu@lists.linux.dev, linux-doc@vger.kernel.org, prime.zeng@huawei.com, liuqi115@huawei.com, zhangshaokun@hisilicon.com, linuxarm@huawei.com, bagasdotme@gmail.com Subject: Re: [PATCH v11 2/8] hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device Date: Fri, 29 Jul 2022 11:05:34 +0200 [thread overview] Message-ID: <YuOi3i0XHV++z1YI@kroah.com> (raw) In-Reply-To: <33f372f6-36bf-f84e-bca0-86347fa4d579@huawei.com> On Fri, Jul 29, 2022 at 03:29:14PM +0800, Yicong Yang wrote: > >> + /* > >> + * Handle the interrupt on the same cpu which starts the trace to avoid > >> + * context mismatch. Otherwise we'll trigger the WARN from the perf > >> + * core in event_function_local(). > >> + */ > >> + WARN_ON(irq_set_affinity(pci_irq_vector(hisi_ptt->pdev, HISI_PTT_TRACE_DMA_IRQ), > >> + cpumask_of(cpu))); > > > > If this hits, you just crashed the machine :( > > > > We'll likely to have a calltrace here without crash the machine and reboot in > most time, unless user has set panic_on_warn. Again, please do not use WARN_ON for this, please read: https://elixir.bootlin.com/linux/v5.19-rc8/source/include/asm-generic/bug.h#L74 If you want a traceback (what would you do with that?), then call the function to give you that. Don't crash people's boxes. > > Please properly recover from errors if you hit them, like this. Don't > > just give up and throw a message to userspace and watch the machine > > reboot with all data lost. > > > > Same for the other WARN_ON() instances here. Handle the error and > > report it properly up the call chain. > > > > The driver use WARN_ON() in two places, once in pmu::start() and another in cpu teardown's > callback, both when the irq_set_affinity() failed. This is common to behave so when driver > fails to set irq affinity in pmu::start() and cpu_teardown(): Don't repeat broken patterns please. > yangyicong@ubuntu:~/mainline_linux/linux/drivers$ grep -rn WARN_ON ./ | grep irq_set_affinity > ./perf/arm_smmuv3_pmu.c:649: WARN_ON(irq_set_affinity(smmu_pmu->irq, cpumask_of(target))); > ./perf/arm_smmuv3_pmu.c:895: WARN_ON(irq_set_affinity(smmu_pmu->irq, cpumask_of(smmu_pmu->on_cpu))); > ./perf/arm-ccn.c:1214: WARN_ON(irq_set_affinity(ccn->irq, cpumask_of(dt->cpu))); > ./perf/qcom_l2_pmu.c:796: WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(cpu))); > ./perf/qcom_l2_pmu.c:834: WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(target))); > ./perf/arm_dmc620_pmu.c:624: WARN_ON(irq_set_affinity(irq->irq_num, cpumask_of(target))); > ./perf/fsl_imx8_ddr_perf.c:674: WARN_ON(irq_set_affinity(pmu->irq, cpumask_of(pmu->cpu))); > ./perf/xgene_pmu.c:1793: WARN_ON(irq_set_affinity(xgene_pmu->irq, &xgene_pmu->cpu)); > ./perf/xgene_pmu.c:1826: WARN_ON(irq_set_affinity(xgene_pmu->irq, &xgene_pmu->cpu)); > ./perf/hisilicon/hisi_pcie_pmu.c:658: WARN_ON(irq_set_affinity(pcie_pmu->irq, cpumask_of(cpu))); > ./perf/hisilicon/hisi_pcie_pmu.c:684: WARN_ON(irq_set_affinity(pcie_pmu->irq, cpumask_of(target))); > ./perf/hisilicon/hisi_uncore_pmu.c:495: WARN_ON(irq_set_affinity(hisi_pmu->irq, cpumask_of(cpu))); > ./perf/hisilicon/hisi_uncore_pmu.c:528: WARN_ON(irq_set_affinity(hisi_pmu->irq, cpumask_of(target))); Great, you can fix all of these up as well any time :) thanks, greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org> To: Yicong Yang <yangyicong@huawei.com> Cc: yangyicong@hisilicon.com, alexander.shishkin@linux.intel.com, leo.yan@linaro.org, james.clark@arm.com, will@kernel.org, robin.murphy@arm.com, acme@kernel.org, peterz@infradead.org, corbet@lwn.net, mathieu.poirier@linaro.org, mark.rutland@arm.com, jonathan.cameron@huawei.com, john.garry@huawei.com, helgaas@kernel.org, lorenzo.pieralisi@arm.com, suzuki.poulose@arm.com, joro@8bytes.org, shameerali.kolothum.thodi@huawei.com, mingo@redhat.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, linux-perf-users@vger.kernel.org, iommu@lists.linux-foundation.org, iommu@lists.linux.dev, linux-doc@vger.kernel.org, prime.zeng@huawei.com, liuqi115@huawei.com, zhangshaokun@hisilicon.com, linuxarm@huawei.com, bagasdotme@gmail.com Subject: Re: [PATCH v11 2/8] hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device Date: Fri, 29 Jul 2022 11:05:34 +0200 [thread overview] Message-ID: <YuOi3i0XHV++z1YI@kroah.com> (raw) In-Reply-To: <33f372f6-36bf-f84e-bca0-86347fa4d579@huawei.com> On Fri, Jul 29, 2022 at 03:29:14PM +0800, Yicong Yang wrote: > >> + /* > >> + * Handle the interrupt on the same cpu which starts the trace to avoid > >> + * context mismatch. Otherwise we'll trigger the WARN from the perf > >> + * core in event_function_local(). > >> + */ > >> + WARN_ON(irq_set_affinity(pci_irq_vector(hisi_ptt->pdev, HISI_PTT_TRACE_DMA_IRQ), > >> + cpumask_of(cpu))); > > > > If this hits, you just crashed the machine :( > > > > We'll likely to have a calltrace here without crash the machine and reboot in > most time, unless user has set panic_on_warn. Again, please do not use WARN_ON for this, please read: https://elixir.bootlin.com/linux/v5.19-rc8/source/include/asm-generic/bug.h#L74 If you want a traceback (what would you do with that?), then call the function to give you that. Don't crash people's boxes. > > Please properly recover from errors if you hit them, like this. Don't > > just give up and throw a message to userspace and watch the machine > > reboot with all data lost. > > > > Same for the other WARN_ON() instances here. Handle the error and > > report it properly up the call chain. > > > > The driver use WARN_ON() in two places, once in pmu::start() and another in cpu teardown's > callback, both when the irq_set_affinity() failed. This is common to behave so when driver > fails to set irq affinity in pmu::start() and cpu_teardown(): Don't repeat broken patterns please. > yangyicong@ubuntu:~/mainline_linux/linux/drivers$ grep -rn WARN_ON ./ | grep irq_set_affinity > ./perf/arm_smmuv3_pmu.c:649: WARN_ON(irq_set_affinity(smmu_pmu->irq, cpumask_of(target))); > ./perf/arm_smmuv3_pmu.c:895: WARN_ON(irq_set_affinity(smmu_pmu->irq, cpumask_of(smmu_pmu->on_cpu))); > ./perf/arm-ccn.c:1214: WARN_ON(irq_set_affinity(ccn->irq, cpumask_of(dt->cpu))); > ./perf/qcom_l2_pmu.c:796: WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(cpu))); > ./perf/qcom_l2_pmu.c:834: WARN_ON(irq_set_affinity(cluster->irq, cpumask_of(target))); > ./perf/arm_dmc620_pmu.c:624: WARN_ON(irq_set_affinity(irq->irq_num, cpumask_of(target))); > ./perf/fsl_imx8_ddr_perf.c:674: WARN_ON(irq_set_affinity(pmu->irq, cpumask_of(pmu->cpu))); > ./perf/xgene_pmu.c:1793: WARN_ON(irq_set_affinity(xgene_pmu->irq, &xgene_pmu->cpu)); > ./perf/xgene_pmu.c:1826: WARN_ON(irq_set_affinity(xgene_pmu->irq, &xgene_pmu->cpu)); > ./perf/hisilicon/hisi_pcie_pmu.c:658: WARN_ON(irq_set_affinity(pcie_pmu->irq, cpumask_of(cpu))); > ./perf/hisilicon/hisi_pcie_pmu.c:684: WARN_ON(irq_set_affinity(pcie_pmu->irq, cpumask_of(target))); > ./perf/hisilicon/hisi_uncore_pmu.c:495: WARN_ON(irq_set_affinity(hisi_pmu->irq, cpumask_of(cpu))); > ./perf/hisilicon/hisi_uncore_pmu.c:528: WARN_ON(irq_set_affinity(hisi_pmu->irq, cpumask_of(target))); Great, you can fix all of these up as well any time :) thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-07-29 9:05 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-21 13:01 [PATCH v11 0/8] Add support for HiSilicon PCIe Tune and Trace device yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 13:01 ` [PATCH v11 1/8] iommu/arm-smmu-v3: Make default domain type of HiSilicon PTT device to identity yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 13:01 ` [PATCH v11 2/8] hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-28 14:11 ` Greg KH 2022-07-28 14:11 ` Greg KH 2022-07-29 7:29 ` Yicong Yang 2022-07-29 7:29 ` Yicong Yang 2022-07-29 9:05 ` Greg KH [this message] 2022-07-29 9:05 ` Greg KH 2022-07-29 9:58 ` Yicong Yang 2022-07-29 9:58 ` Yicong Yang 2022-07-21 13:01 ` [PATCH v11 3/8] hwtracing: hisi_ptt: Add tune " yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 13:01 ` [PATCH v11 4/8] perf tool: arm: Refactor event list iteration in auxtrace_record__init() yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 13:01 ` [PATCH v11 5/8] perf tool: Add support for HiSilicon PCIe Tune and Trace device driver yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 13:01 ` [PATCH v11 6/8] perf tool: Add support for parsing HiSilicon PCIe Trace packet yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 13:01 ` [PATCH v11 7/8] docs: trace: Add HiSilicon PTT device driver documentation yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 13:01 ` [PATCH v11 8/8] MAINTAINERS: Add maintainer for HiSilicon PTT driver yangyicong 2022-07-21 13:01 ` yangyicong 2022-07-21 15:43 ` [PATCH v11 0/8] Add support for HiSilicon PCIe Tune and Trace device Mathieu Poirier 2022-07-21 15:43 ` Mathieu Poirier 2022-07-22 14:52 ` Yicong Yang 2022-07-22 14:52 ` Yicong Yang 2022-07-25 14:32 ` Mathieu Poirier 2022-07-25 14:32 ` Mathieu Poirier 2022-07-26 11:36 ` Yicong Yang 2022-07-26 11:36 ` Yicong Yang
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=YuOi3i0XHV++z1YI@kroah.com \ --to=gregkh@linuxfoundation.org \ --cc=acme@kernel.org \ --cc=alexander.shishkin@linux.intel.com \ --cc=bagasdotme@gmail.com \ --cc=corbet@lwn.net \ --cc=helgaas@kernel.org \ --cc=iommu@lists.linux-foundation.org \ --cc=iommu@lists.linux.dev \ --cc=james.clark@arm.com \ --cc=john.garry@huawei.com \ --cc=jonathan.cameron@huawei.com \ --cc=joro@8bytes.org \ --cc=leo.yan@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=linux-perf-users@vger.kernel.org \ --cc=linuxarm@huawei.com \ --cc=liuqi115@huawei.com \ --cc=lorenzo.pieralisi@arm.com \ --cc=mark.rutland@arm.com \ --cc=mathieu.poirier@linaro.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=prime.zeng@huawei.com \ --cc=robin.murphy@arm.com \ --cc=shameerali.kolothum.thodi@huawei.com \ --cc=suzuki.poulose@arm.com \ --cc=will@kernel.org \ --cc=yangyicong@hisilicon.com \ --cc=yangyicong@huawei.com \ --cc=zhangshaokun@hisilicon.com \ /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: linkBe 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.