All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.