* Re: [PATCH v5] pseries: prevent free CPU ids to be reused on another node
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: paulus, benh, mpe, Laurent Dufour; +Cc: nathanl, linuxppc-dev, linux-kernel
In-Reply-To: <20210429174908.16613-1-ldufour@linux.ibm.com>
On Thu, 29 Apr 2021 19:49:08 +0200, Laurent Dufour wrote:
> When a CPU is hot added, the CPU ids are taken from the available mask from
> the lower possible set. If that set of values was previously used for CPU
> attached to a different node, this seems to application like if these CPUs
> have migrated from a node to another one which is not expected in real
> life.
>
> To prevent this, it is needed to record the CPU ids used for each node and
> to not reuse them on another node. However, to prevent CPU hot plug to
> fail, in the case the CPU ids is starved on a node, the capability to reuse
> other nodes’ free CPU ids is kept. A warning is displayed in such a case
> to warn the user.
>
> [...]
Applied to powerpc/next.
[1/1] pseries: prevent free CPU ids to be reused on another node
https://git.kernel.org/powerpc/c/bd1dd4c5f5286df0148b5b316f37c583b8f55fa1
cheers
^ permalink raw reply
* Re: [PATCH v5] pseries/drmem: update LMBs after LPM
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: paulus, benh, mpe, Laurent Dufour
Cc: Nathan Lynch, Tyrel Datwyler, linuxppc-dev, linux-kernel,
Aneesh Kumar K . V
In-Reply-To: <20210517090606.56930-1-ldufour@linux.ibm.com>
On Mon, 17 May 2021 11:06:06 +0200, Laurent Dufour wrote:
> After a LPM, the device tree node ibm,dynamic-reconfiguration-memory may be
> updated by the hypervisor in the case the NUMA topology of the LPAR's
> memory is updated.
>
> This is handled by the kernel, but the memory's node is not updated because
> there is no way to move a memory block between nodes from the Linux kernel
> point of view.
>
> [...]
Applied to powerpc/next.
[1/1] pseries/drmem: update LMBs after LPM
https://git.kernel.org/powerpc/c/d144f4d5a8a804133d20ff311d7be70bcdbfaac2
cheers
^ permalink raw reply
* Re: [PATCH v2] ppc64/numa: consider the max numa node for migratable LPAR
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: paulus, benh, mpe, Laurent Dufour
Cc: nathanl, linuxppc-dev, linux-kernel, Srikar Dronamraju
In-Reply-To: <20210511073136.17795-1-ldufour@linux.ibm.com>
On Tue, 11 May 2021 09:31:36 +0200, Laurent Dufour wrote:
> When a LPAR is migratable, we should consider the maximum possible NUMA
> node instead the number of NUMA node from the actual system.
>
> The DT property 'ibm,current-associativity-domains' is defining the maximum
> number of nodes the LPAR can see when running on that box. But if the LPAR
> is being migrated on another box, it may seen up to the nodes defined by
> 'ibm,max-associativity-domains'. So if a LPAR is migratable, that value
> should be used.
>
> [...]
Applied to powerpc/next.
[1/1] ppc64/numa: consider the max numa node for migratable LPAR
https://git.kernel.org/powerpc/c/9c7248bb8de31f51c693bfa6a6ea53b1c07e0fa8
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/kexec: fix for_each_child.cocci warning
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Julia Lawall, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: Sumera Priyadarsini, linuxppc-dev, kbuild-all, linux-kernel
In-Reply-To: <alpine.DEB.2.22.394.2108031654080.17639@hadrien>
On Tue, 3 Aug 2021 16:59:55 +0200 (CEST), Julia Lawall wrote:
> for_each_node_by_type should have of_node_put() before return.
>
> Generated by: scripts/coccinelle/iterators/for_each_child.cocci
Applied to powerpc/next.
[1/1] powerpc/kexec: fix for_each_child.cocci warning
https://git.kernel.org/powerpc/c/c00103abf76fd3916596afd07dd3fdeee0dca15d
cheers
^ permalink raw reply
* Re: [PATCH v2 00/32] powerpc: Add MSI IRQ domains to PCI drivers
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, Cédric Le Goater
In-Reply-To: <20210701132750.1475580-1-clg@kaod.org>
On Thu, 1 Jul 2021 15:27:18 +0200, Cédric Le Goater wrote:
> This series adds support for MSI IRQ domains on top of the XICS (P8)
> and XIVE (P9/P10) IRQ domains for the PowerNV (baremetal) and pSeries
> (VM) platforms. It should simplify and improve IRQ affinity of PCI
> MSIs under these PowerPC platforms, specially for drivers distributing
> multiple RX/TX queues on the different CPUs of the system.
>
> Data locality can still be improved with an interrupt controller node
> per chip but this requires FW changes. It could be done under OPAL.
>
> [...]
Patches 1-31 applied to powerpc/next.
[01/32] powerpc/pseries/pci: Introduce __find_pe_total_msi()
https://git.kernel.org/powerpc/c/786e5b102a0007d81579822eac23cb5bfaa0b65f
[02/32] powerpc/pseries/pci: Introduce rtas_prepare_msi_irqs()
https://git.kernel.org/powerpc/c/e81202007363bd694b711f307f02320b5f98edaa
[03/32] powerpc/xive: Add support for IRQ domain hierarchy
https://git.kernel.org/powerpc/c/14be098c5387eb93b794f299f3c3e2ddf6038ec7
[04/32] powerpc/xive: Ease debugging of xive_irq_set_affinity()
https://git.kernel.org/powerpc/c/6c2ab2a5d634d4e30445ee5d52d5d1469bf74aa2
[05/32] powerpc/pseries/pci: Add MSI domains
https://git.kernel.org/powerpc/c/a5f3d2c17b07e69166b93209f34a5fb8271a6810
[06/32] powerpc/xive: Drop unmask of MSIs at startup
https://git.kernel.org/powerpc/c/5690bcae186084a8544b1819f0d89399268bd0cf
[07/32] powerpc/xive: Remove irqd_is_started() check when setting the affinity
https://git.kernel.org/powerpc/c/292145a6e598c1e6633b8f5f607706b46f552ab9
[08/32] powerpc/pseries/pci: Add a domain_free_irqs() handler
https://git.kernel.org/powerpc/c/07817a578a7a79638537480b8847dc7a12f293c5
[09/32] powerpc/pseries/pci: Add a msi_free() handler to clear XIVE data
https://git.kernel.org/powerpc/c/9a014f456881e947bf8cdd8c984a207097e6c096
[10/32] powerpc/pseries/pci: Add support of MSI domains to PHB hotplug
https://git.kernel.org/powerpc/c/174db9e7f775ce06fc6949c9abbe758b3eb8171c
[11/32] powerpc/powernv/pci: Introduce __pnv_pci_ioda_msi_setup()
https://git.kernel.org/powerpc/c/2c50d7e99e39eba92b93210e740f3f9e5a06ba54
[12/32] powerpc/powernv/pci: Add MSI domains
https://git.kernel.org/powerpc/c/0fcfe2247e75070361af2b6845030cada92cdbf8
[13/32] KVM: PPC: Book3S HV: Use the new IRQ chip to detect passthrough interrupts
https://git.kernel.org/powerpc/c/ba418a0278265ad65f2f9544e743b7dbff3b994b
[14/32] KVM: PPC: Book3S HV: XIVE: Change interface of passthrough interrupt routines
https://git.kernel.org/powerpc/c/e5e78b15113a73d0294141d9796969fa7b10fa3c
[15/32] KVM: PPC: Book3S HV: XIVE: Fix mapping of passthrough interrupts
https://git.kernel.org/powerpc/c/51be9e51a8000ffc6a33083ceca9da9303ed4dc5
[16/32] powerpc/xics: Remove ICS list
https://git.kernel.org/powerpc/c/298f6f952885eeb1f25461f085c6c238bcd9fc5e
[17/32] powerpc/xics: Rename the map handler in a check handler
https://git.kernel.org/powerpc/c/248af248a8f45461662fb633eca4adf24ae704ad
[18/32] powerpc/xics: Give a name to the default XICS IRQ domain
https://git.kernel.org/powerpc/c/7d14f6c60b76fa7f3f89d81a95385576ca33b483
[19/32] powerpc/xics: Add debug logging to the set_irq_affinity handlers
https://git.kernel.org/powerpc/c/53b34e8db73af98fa652641bf490384dc665d0f2
[20/32] powerpc/xics: Add support for IRQ domain hierarchy
https://git.kernel.org/powerpc/c/e4f0aa3b4731430ad73fb4485e97f751c7500668
[21/32] powerpc/powernv/pci: Customize the MSI EOI handler to support PHB3
https://git.kernel.org/powerpc/c/bbb25af8fbdba4acaf955e412a84eb2eea48697c
[22/32] powerpc/pci: Drop XIVE restriction on MSI domains
https://git.kernel.org/powerpc/c/679e30b9536eeb93bc8c9a39c0ddc77dec536f6b
[23/32] powerpc/xics: Drop unmask of MSIs at startup
https://git.kernel.org/powerpc/c/1e661f81a522eadfe4bc5bb1ec9fbae27c13f163
[24/32] powerpc/pseries/pci: Drop unused MSI code
https://git.kernel.org/powerpc/c/3005123eea0daa18d98602ab64b2ce3ad087d849
[25/32] powerpc/powernv/pci: Drop unused MSI code
https://git.kernel.org/powerpc/c/6d9ba6121b1cf453985d08c141970a1b44cd9cf1
[26/32] powerpc/powernv/pci: Adapt is_pnv_opal_msi() to detect passthrough interrupt
https://git.kernel.org/powerpc/c/f1a377f86f51b381cfc30bf2270f8a5f81e35ee9
[27/32] powerpc/xics: Fix IRQ migration
https://git.kernel.org/powerpc/c/c80198a21792ac59412871e4e6fad5041c9be8e4
[28/32] powerpc/powernv/pci: Set the IRQ chip data for P8/CXL devices
https://git.kernel.org/powerpc/c/5cd69651ceeed15e021cf7d19f1b1be0a80c0c7a
[29/32] powerpc/powernv/pci: Rework pnv_opal_pci_msi_eoi()
https://git.kernel.org/powerpc/c/c325712b5f85e561ea89bae2ba5d0104e797e42c
[30/32] KVM: PPC: Book3S HV: XICS: Fix mapping of passthrough interrupts
https://git.kernel.org/powerpc/c/1753081f2d445f9157550692fcc4221cd3ff0958
[31/32] powerpc/xive: Use XIVE domain under xmon and debugfs
https://git.kernel.org/powerpc/c/59b2bc18b1492b46d45b6b6828ba098f09b9ba67
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Always inline radix_enabled() to fix build failure
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, Jordan Niethe; +Cc: erhard_f
In-Reply-To: <20210804013724.514468-1-jniethe5@gmail.com>
On Wed, 4 Aug 2021 11:37:24 +1000, Jordan Niethe wrote:
> This is the same as commit acdad8fb4a15 ("powerpc: Force inlining of
> mmu_has_feature to fix build failure") but for radix_enabled(). The
> config in the linked bugzilla causes the following build failure:
>
> LD .tmp_vmlinux.kallsyms1
> powerpc64-linux-ld: arch/powerpc/mm/pgtable.o: in function `.__ptep_set_access_flags':
> pgtable.c:(.text+0x17c): undefined reference to `.radix__ptep_set_access_flags'
...
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Always inline radix_enabled() to fix build failure
https://git.kernel.org/powerpc/c/27fd1111051dc218e5b6cb2da5dbb3f342879ff1
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/non-smp: Inconditionaly call smp_mb() on switch_mm
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e9d501da0c59f60ca767b1b3ea4603fce6d02b9e.1625486440.git.christophe.leroy@csgroup.eu>
On Mon, 5 Jul 2021 12:00:50 +0000 (UTC), Christophe Leroy wrote:
> Commit 3ccfebedd8cf ("powerpc, membarrier: Skip memory barrier in
> switch_mm()") added some logic to skip the smp_mb() in
> switch_mm_irqs_off() before the call to switch_mmu_context().
>
> However, on non SMP smp_mb() is just a compiler barrier and doing
> it inconditionaly is simpler than the logic used to check
> whether the barrier is needed or not.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/non-smp: Inconditionaly call smp_mb() on switch_mm
https://git.kernel.org/powerpc/c/c8a6d91005343dea0d53be0ff0620c66934dcd44
cheers
^ permalink raw reply
* Re: [PATCH kernel v2] KVM: PPC: Use arch_get_random_seed_long instead of powernv variant
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: kvm-ppc, kvm
In-Reply-To: <20210805075649.2086567-1-aik@ozlabs.ru>
On Thu, 5 Aug 2021 17:56:49 +1000, Alexey Kardashevskiy wrote:
> The powernv_get_random_long() does not work in nested KVM (which is
> pseries) and produces a crash when accessing in_be64(rng->regs) in
> powernv_get_random_long().
>
> This replaces powernv_get_random_long with the ppc_md machine hook
> wrapper.
Applied to powerpc/next.
[1/1] KVM: PPC: Use arch_get_random_seed_long instead of powernv variant
https://git.kernel.org/powerpc/c/2ac78e0c00184a9ba53d507be7549c69a3f566b6
cheers
^ permalink raw reply
* Re: [PATCH v8 0/5] Add support for FORM2 associativity
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, mpe, Aneesh Kumar K.V
Cc: Nathan Lynch, Daniel Henrique Barboza, David Gibson
In-Reply-To: <20210812132223.225214-1-aneesh.kumar@linux.ibm.com>
On Thu, 12 Aug 2021 18:52:18 +0530, Aneesh Kumar K.V wrote:
> Form2 associativity adds a much more flexible NUMA topology layout
> than what is provided by Form1. More details can be found in patch 7.
>
> $ numactl -H
> ...
> node distances:
> node 0 1 2 3
> 0: 10 11 222 33
> 1: 44 10 55 66
> 2: 77 88 10 99
> 3: 101 121 132 10
> $
>
> [...]
Applied to powerpc/next.
[1/5] powerpc/pseries: rename min_common_depth to primary_domain_index
https://git.kernel.org/powerpc/c/7e35ef662ca05c42dbc2f401bb76d9219dd7fd02
[2/5] powerpc/pseries: Rename TYPE1_AFFINITY to FORM1_AFFINITY
https://git.kernel.org/powerpc/c/0eacd06bb8adea8dd9edb0a30144166d9f227e64
[3/5] powerpc/pseries: Consolidate different NUMA distance update code paths
https://git.kernel.org/powerpc/c/8ddc6448ec5a5ef50eaa581a7dec0e12a02850ff
[4/5] powerpc/pseries: Add a helper for form1 cpu distance
https://git.kernel.org/powerpc/c/ef31cb83d19c4c589d650747cd5a7e502be9f665
[5/5] powerpc/pseries: Add support for FORM2 associativity
https://git.kernel.org/powerpc/c/1c6b5a7e74052768977855f95d6b8812f6e7772c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/configs: Disable legacy ptys on microwatt defconfig
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Anton Blanchard, Michael Ellerman, Paul Mackerras, Joel Stanley
Cc: linuxppc-dev
In-Reply-To: <20210805112005.3cb1f412@kryten.localdomain>
On Thu, 5 Aug 2021 11:20:05 +1000, Anton Blanchard wrote:
> We shouldn't need legacy ptys, and disabling the option improves boot
> time by about 0.5 seconds.
Applied to powerpc/next.
[1/1] powerpc/configs: Disable legacy ptys on microwatt defconfig
https://git.kernel.org/powerpc/c/9b49f979b3d560cb75ea9f1a596baf432d566798
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Remove in_kernel_text()
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2a3a5b6f8cc0ef4e854d7b764f66aa8d2ee270d2.1624813698.git.christophe.leroy@csgroup.eu>
On Sun, 27 Jun 2021 17:09:18 +0000 (UTC), Christophe Leroy wrote:
> Last user of in_kernel_text() stopped using in with
> commit 549e8152de80 ("powerpc: Make the 64-bit kernel as a
> position-independent executable").
>
> Generic function is_kernel_text() does the same.
>
> So remote it.
Applied to powerpc/next.
[1/1] powerpc: Remove in_kernel_text()
https://git.kernel.org/powerpc/c/09ca497528dac12cbbceab8197011c875a96d053
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: use IRQF_NO_DEBUG for IPIs
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, Cédric Le Goater; +Cc: Thomas Gleixner
In-Reply-To: <20210719130614.195886-1-clg@kaod.org>
On Mon, 19 Jul 2021 15:06:14 +0200, Cédric Le Goater wrote:
> There is no need to use the lockup detector ("noirqdebug") for IPIs.
> The ipistorm benchmark measures a ~10% improvement on high systems
> when this flag is set.
Applied to powerpc/next.
[1/1] powerpc: use IRQF_NO_DEBUG for IPIs
https://git.kernel.org/powerpc/c/17df41fec5b80b16ea4774495f1eb730e2225619
cheers
^ permalink raw reply
* Re: [PATCH 0/2] KVM: PPC: Book3S HV: XIVE: Improve guest entries and exits
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, Cédric Le Goater; +Cc: Paul Mackerras, kvm-ppc
In-Reply-To: <20210720134209.256133-1-clg@kaod.org>
On Tue, 20 Jul 2021 15:42:07 +0200, Cédric Le Goater wrote:
> The XIVE interrupt controller on P10 can automatically save and
> restore the state of the interrupt registers under the internal NVP
> structure representing the VCPU. This saves a costly store/load in
> guest entries and exits.
>
> Thanks,
>
> [...]
Applied to powerpc/next.
[1/2] KVM: PPC: Book3S HV: XIVE: Add a 'flags' field
https://git.kernel.org/powerpc/c/b68c6646cce5ee8caefa6333ee743f960222dcea
[2/2] KVM: PPC: Book3S HV: XIVE: Add support for automatic save-restore
https://git.kernel.org/powerpc/c/f5af0a978776b710f16dc99a85496b1e760bf9e0
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Michael Ellerman,
Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <b286e07fb771a664b631cd07a40b09c06f26e64b.1618331881.git.christophe.leroy@csgroup.eu>
On Tue, 13 Apr 2021 16:38:09 +0000 (UTC), Christophe Leroy wrote:
> powerpc BUG_ON() and WARN_ON() are based on using twnei instruction.
>
> For catching simple conditions like a variable having value 0, this
> is efficient because it does the test and the trap at the same time.
> But most conditions used with BUG_ON or WARN_ON are more complex and
> forces GCC to format the condition into a 0 or 1 value in a register.
> This will usually require 2 to 3 instructions.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/bug: Remove specific powerpc BUG_ON() and WARN_ON() on PPC32
https://git.kernel.org/powerpc/c/db87a7199229b75c9996bf78117eceb81854fce2
[2/2] powerpc/bug: Provide better flexibility to WARN_ON/__WARN_FLAGS() with asm goto
https://git.kernel.org/powerpc/c/1e688dd2a3d6759d416616ff07afc4bb836c4213
cheers
^ permalink raw reply
* Re: (subset) [PATCH 00/38] Replace deprecated CPU-hotplug
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linux-kernel, Sebastian Andrzej Siewior; +Cc: linuxppc-dev
In-Reply-To: <20210803141621.780504-1-bigeasy@linutronix.de>
On Tue, 3 Aug 2021 16:15:43 +0200, Sebastian Andrzej Siewior wrote:
> This is a tree wide replacement of the deprecated CPU hotplug functions
> which are only wrappers around the actual functions.
>
> Each patch is independent and can be picked up by the relevant maintainer.
>
> [...]
Applied to powerpc/next.
[03/38] powerpc: Replace deprecated CPU-hotplug functions.
https://git.kernel.org/powerpc/c/5ae36401ca4ea2737d779ce7c267444b16530001
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/book3s64/radix: make tlb_single_page_flush_ceiling a debugfs entry
From: Michael Ellerman @ 2021-08-18 13:38 UTC (permalink / raw)
To: linuxppc-dev, mpe, Aneesh Kumar K.V
In-Reply-To: <20210812132831.233794-1-aneesh.kumar@linux.ibm.com>
On Thu, 12 Aug 2021 18:58:30 +0530, Aneesh Kumar K.V wrote:
> Similar to x86/s390 add a debugfs file to tune tlb_single_page_flush_ceiling.
> Also add a debugfs entry for tlb_local_single_page_flush_ceiling.
Applied to powerpc/next.
[1/2] powerpc/book3s64/radix: make tlb_single_page_flush_ceiling a debugfs entry
https://git.kernel.org/powerpc/c/3e188b1ae8807f26cc5a530a9d55f3f643fe050a
[2/2] powerpc: rename powerpc_debugfs_root to arch_debugfs_dir
https://git.kernel.org/powerpc/c/dbf77fed8b302e87561c7c2fc06050c88f4d3120
cheers
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/perf: Fix the check for SIAR value
From: Christophe Leroy @ 2021-08-18 13:28 UTC (permalink / raw)
To: Kajol Jain, mpe, linuxppc-dev; +Cc: atrajeev, maddy, rnsastry
In-Reply-To: <20210818131949.32008-3-kjain@linux.ibm.com>
Le 18/08/2021 à 15:19, Kajol Jain a écrit :
> Incase of random sampling, there can be scenarios where
> Sample Instruction Address Register(SIAR) may not latch
> to the sampled instruction and could result in
> the value of 0. In these scenarios it is preferred to
> return regs->nip. These corner cases are seen in the
> previous generation (p9) also.
>
> Patch adds the check for SIAR value along with use_siar and
> siar_valid checks so that the function will return regs->nip
> incase SIAR is zero.
>
> Patch drops the code under PPMU_P10_DD1 flag check
> which handles SIAR 0 case only for Power10 DD1.
>
> Fixes: 2ca13a4cc56c9 ("powerpc/perf: Use regs->nip when SIAR is zero")
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
>
> Changelog:
> - Drop adding new ternary condition to check siar value.
> - Remove siar check specific for PPMU_P10_DD1 and add
> it along with common checks as suggested by Christophe Leroy
> and Michael Ellermen
>
> arch/powerpc/perf/core-book3s.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 23ec89a59893..55efbba7572b 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -2254,12 +2254,7 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
> bool use_siar = regs_use_siar(regs);
> unsigned long siar = mfspr(SPRN_SIAR);
>
> - if (ppmu && (ppmu->flags & PPMU_P10_DD1)) {
> - if (siar)
> - return siar;
> - else
> - return regs->nip;
> - } else if (use_siar && siar_valid(regs))
> + if (use_siar && siar_valid(regs) && siar)
You can probably now do
+ if (regs_use_siar(regs) && siar_valid(regs) && siar)
and remove use_siar
> return siar + perf_ip_adjust(regs);
> else
> return regs->nip;
>
^ permalink raw reply
* [PATCH v3 3/3] powerpc/perf: Fix the check for SIAR value
From: Kajol Jain @ 2021-08-18 13:19 UTC (permalink / raw)
To: mpe, linuxppc-dev, christophe.leroy; +Cc: kjain, atrajeev, maddy, rnsastry
In-Reply-To: <20210818131949.32008-1-kjain@linux.ibm.com>
Incase of random sampling, there can be scenarios where
Sample Instruction Address Register(SIAR) may not latch
to the sampled instruction and could result in
the value of 0. In these scenarios it is preferred to
return regs->nip. These corner cases are seen in the
previous generation (p9) also.
Patch adds the check for SIAR value along with use_siar and
siar_valid checks so that the function will return regs->nip
incase SIAR is zero.
Patch drops the code under PPMU_P10_DD1 flag check
which handles SIAR 0 case only for Power10 DD1.
Fixes: 2ca13a4cc56c9 ("powerpc/perf: Use regs->nip when SIAR is zero")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
Changelog:
- Drop adding new ternary condition to check siar value.
- Remove siar check specific for PPMU_P10_DD1 and add
it along with common checks as suggested by Christophe Leroy
and Michael Ellermen
arch/powerpc/perf/core-book3s.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 23ec89a59893..55efbba7572b 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2254,12 +2254,7 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
bool use_siar = regs_use_siar(regs);
unsigned long siar = mfspr(SPRN_SIAR);
- if (ppmu && (ppmu->flags & PPMU_P10_DD1)) {
- if (siar)
- return siar;
- else
- return regs->nip;
- } else if (use_siar && siar_valid(regs))
+ if (use_siar && siar_valid(regs) && siar)
return siar + perf_ip_adjust(regs);
else
return regs->nip;
--
2.26.2
^ permalink raw reply related
* [PATCH v3 2/3] powerpc/perf: Drop the case of returning 0 as instruction pointer
From: Kajol Jain @ 2021-08-18 13:19 UTC (permalink / raw)
To: mpe, linuxppc-dev, christophe.leroy; +Cc: kjain, atrajeev, maddy, rnsastry
In-Reply-To: <20210818131949.32008-1-kjain@linux.ibm.com>
Drop the case of returning 0 as instruction pointer since kernel
never executes at 0 and userspace almost never does either.
Fixes: e6878835ac47 ("powerpc/perf: Sample only if SIAR-Valid
bit is set in P7+")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/core-book3s.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 1b464aad29c4..23ec89a59893 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2261,8 +2261,6 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
return regs->nip;
} else if (use_siar && siar_valid(regs))
return siar + perf_ip_adjust(regs);
- else if (use_siar)
- return 0; // no valid instruction pointer
else
return regs->nip;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v3 1/3] powerpc/perf: Use stack siar instead of mfspr
From: Kajol Jain @ 2021-08-18 13:19 UTC (permalink / raw)
To: mpe, linuxppc-dev, christophe.leroy; +Cc: kjain, atrajeev, maddy, rnsastry
Minor optimization in the 'perf_instruction_pointer' function code by
making use of stack siar instead of mfspr.
Fixes: 75382aa72f06 ("powerpc/perf: Move code to select SIAR or pt_regs
into perf_read_regs")
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
---
arch/powerpc/perf/core-book3s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index bb0ee716de91..1b464aad29c4 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2260,7 +2260,7 @@ unsigned long perf_instruction_pointer(struct pt_regs *regs)
else
return regs->nip;
} else if (use_siar && siar_valid(regs))
- return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
+ return siar + perf_ip_adjust(regs);
else if (use_siar)
return 0; // no valid instruction pointer
else
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v1 2/4] powerpc/64s/perf: add power_pmu_running to query whether perf is being used
From: Athira Rajeev @ 2021-08-18 12:14 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <1629286381.q658eskbmg.astroid@bobo.none>
> On 18-Aug-2021, at 5:11 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> Excerpts from Madhavan Srinivasan's message of August 17, 2021 11:06 pm:
>>
>> On 8/16/21 12:59 PM, Nicholas Piggin wrote:
>>> Interrupt handling code would like to know whether perf is enabled, to
>>> know whether it should enable MSR[EE] to improve PMI coverage.
>>>
>>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>>> Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> ---
>>> arch/powerpc/include/asm/hw_irq.h | 2 ++
>>> arch/powerpc/perf/core-book3s.c | 13 +++++++++++++
>>> 2 files changed, 15 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
>>> index 21cc571ea9c2..2d5c0d3ccbb6 100644
>>> --- a/arch/powerpc/include/asm/hw_irq.h
>>> +++ b/arch/powerpc/include/asm/hw_irq.h
>>> @@ -306,6 +306,8 @@ static inline bool lazy_irq_pending_nocheck(void)
>>> return __lazy_irq_pending(local_paca->irq_happened);
>>> }
>>>
>>> +bool power_pmu_running(void);
>>> +
>>> /*
>>> * This is called by asynchronous interrupts to conditionally
>>> * re-enable hard interrupts after having cleared the source
>>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>>> index bb0ee716de91..76114a9afb2b 100644
>>> --- a/arch/powerpc/perf/core-book3s.c
>>> +++ b/arch/powerpc/perf/core-book3s.c
>>> @@ -2380,6 +2380,19 @@ static void perf_event_interrupt(struct pt_regs *regs)
>>> perf_sample_event_took(sched_clock() - start_clock);
>>> }
>>>
>>> +bool power_pmu_running(void)
>>> +{
>>> + struct cpu_hw_events *cpuhw;
>>> +
>>> + /* Could this simply test local_paca->pmcregs_in_use? */
>>> +
>>> + if (!ppmu)
>>> + return false;
>>
>>
>> This covers only when perf platform driver is not registered,
>> but we should also check for MMCR0[32], since pmu sprs can be
>> accessed via sysfs.
>
> In that case do they actually do anything with the PMI? I don't think it
> should matter hopefully.
>
> But I do think a lot of this stuff could be cleaned up. We have
> pmcs_enabled and ppc_enable_pmcs() in sysfs.c, ppc_set_pmu_inuse(),
> ppc_md.enable_pmcs(), reserve_pmc_hardware(), etc and different users
> call different things. We don't consistently disable either, e.g., we
> never disable the H_PERFMON facility after we stop using perf even
> though it says that slows down partition switch.
Hi Nick,
I have started looking at understanding the code path and working on it to get the code cleaned up.
I will work on posting the patch set for clean up.
Thanks
Athira Rajeev
>
> I started to have a look at sorting it out but it looks like a big
> job so would take a bit of time if we want to do it.
>
> Thanks,
> Nick
^ permalink raw reply
* Re: [PATCH v2] powerpc/mm: Fix set_memory_*() against concurrent accesses
From: Christophe Leroy @ 2021-08-18 12:09 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
Cc: lvivier, jniethe5, aneesh.kumar, npiggin, farosas
In-Reply-To: <20210818120518.3603172-1-mpe@ellerman.id.au>
Le 18/08/2021 à 14:05, Michael Ellerman a écrit :
> Laurent reported that STRICT_MODULE_RWX was causing intermittent crashes
> on one of his systems:
>
> kernel tried to execute exec-protected page (c008000004073278) - exploit attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch
> Faulting instruction address: 0xc008000004073278
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: drm virtio_console fuse drm_panel_orientation_quirks ...
> CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 5.14.0-rc4+ #12
> Workqueue: events control_work_handler [virtio_console]
> NIP: c008000004073278 LR: c008000004073278 CTR: c0000000001e9de0
> REGS: c00000002e4ef7e0 TRAP: 0400 Not tainted (5.14.0-rc4+)
> MSR: 800000004280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 200400cf
> ...
> NIP fill_queue+0xf0/0x210 [virtio_console]
> LR fill_queue+0xf0/0x210 [virtio_console]
> Call Trace:
> fill_queue+0xb4/0x210 [virtio_console] (unreliable)
> add_port+0x1a8/0x470 [virtio_console]
> control_work_handler+0xbc/0x1e8 [virtio_console]
> process_one_work+0x290/0x590
> worker_thread+0x88/0x620
> kthread+0x194/0x1a0
> ret_from_kernel_thread+0x5c/0x64
>
> Jordan, Fabiano & Murilo were able to reproduce and identify that the
> problem is caused by the call to module_enable_ro() in do_init_module(),
> which happens after the module's init function has already been called.
>
> Our current implementation of change_page_attr() is not safe against
> concurrent accesses, because it invalidates the PTE before flushing the
> TLB and then installing the new PTE. That leaves a window in time where
> there is no valid PTE for the page, if another CPU tries to access the
> page at that time we see something like the fault above.
>
> We can't simply switch to set_pte_at()/flush TLB, because our hash MMU
> code doesn't handle a set_pte_at() of a valid PTE. See [1].
>
> But we do have pte_update(), which replaces the old PTE with the new,
> meaning there's no window where the PTE is invalid. And the hash MMU
> version hash__pte_update() deals with synchronising the hash page table
> correctly.
>
> [1]: https://lore.kernel.org/linuxppc-dev/87y318wp9r.fsf@linux.ibm.com/
>
> Fixes: 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
> Reported-by: Laurent Vivier <lvivier@redhat.com>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/mm/pageattr.c | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> v2: Use pte_update(..., ~0, pte_val(pte), ...) as suggested by Fabiano,
> and ptep_get() as suggested by Christophe.
>
> diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
> index 0876216ceee6..edea388e9d3f 100644
> --- a/arch/powerpc/mm/pageattr.c
> +++ b/arch/powerpc/mm/pageattr.c
> @@ -18,16 +18,12 @@
> /*
> * Updates the attributes of a page in three steps:
> *
> - * 1. invalidate the page table entry
> - * 2. flush the TLB
> - * 3. install the new entry with the updated attributes
> - *
> - * Invalidating the pte means there are situations where this will not work
> - * when in theory it should.
> - * For example:
> - * - removing write from page whilst it is being executed
> - * - setting a page read-only whilst it is being read by another CPU
> + * 1. take the page_table_lock
> + * 2. install the new entry with the updated attributes
> + * 3. flush the TLB
> *
> + * This sequence is safe against concurrent updates, and also allows updating the
> + * attributes of a page currently being executed or accessed.
> */
> static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
> {
> @@ -36,9 +32,7 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
>
> spin_lock(&init_mm.page_table_lock);
>
> - /* invalidate the PTE so it's safe to modify */
> - pte = ptep_get_and_clear(&init_mm, addr, ptep);
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> + pte = ptep_get(ptep);
>
> /* modify the PTE bits as desired, then apply */
> switch (action) {
> @@ -59,11 +53,14 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
> break;
> }
>
> - set_pte_at(&init_mm, addr, ptep, pte);
> + pte_update(&init_mm, addr, ptep, ~0UL, pte_val(pte), 0);
>
> /* See ptesync comment in radix__set_pte_at() */
> if (radix_enabled())
> asm volatile("ptesync": : :"memory");
> +
> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> +
> spin_unlock(&init_mm.page_table_lock);
>
> return 0;
>
> base-commit: cbc06f051c524dcfe52ef0d1f30647828e226d30
>
^ permalink raw reply
* [PATCH v2] powerpc/mm: Fix set_memory_*() against concurrent accesses
From: Michael Ellerman @ 2021-08-18 12:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: lvivier, farosas, jniethe5, npiggin, aneesh.kumar
Laurent reported that STRICT_MODULE_RWX was causing intermittent crashes
on one of his systems:
kernel tried to execute exec-protected page (c008000004073278) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0xc008000004073278
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: drm virtio_console fuse drm_panel_orientation_quirks ...
CPU: 3 PID: 44 Comm: kworker/3:1 Not tainted 5.14.0-rc4+ #12
Workqueue: events control_work_handler [virtio_console]
NIP: c008000004073278 LR: c008000004073278 CTR: c0000000001e9de0
REGS: c00000002e4ef7e0 TRAP: 0400 Not tainted (5.14.0-rc4+)
MSR: 800000004280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 200400cf
...
NIP fill_queue+0xf0/0x210 [virtio_console]
LR fill_queue+0xf0/0x210 [virtio_console]
Call Trace:
fill_queue+0xb4/0x210 [virtio_console] (unreliable)
add_port+0x1a8/0x470 [virtio_console]
control_work_handler+0xbc/0x1e8 [virtio_console]
process_one_work+0x290/0x590
worker_thread+0x88/0x620
kthread+0x194/0x1a0
ret_from_kernel_thread+0x5c/0x64
Jordan, Fabiano & Murilo were able to reproduce and identify that the
problem is caused by the call to module_enable_ro() in do_init_module(),
which happens after the module's init function has already been called.
Our current implementation of change_page_attr() is not safe against
concurrent accesses, because it invalidates the PTE before flushing the
TLB and then installing the new PTE. That leaves a window in time where
there is no valid PTE for the page, if another CPU tries to access the
page at that time we see something like the fault above.
We can't simply switch to set_pte_at()/flush TLB, because our hash MMU
code doesn't handle a set_pte_at() of a valid PTE. See [1].
But we do have pte_update(), which replaces the old PTE with the new,
meaning there's no window where the PTE is invalid. And the hash MMU
version hash__pte_update() deals with synchronising the hash page table
correctly.
[1]: https://lore.kernel.org/linuxppc-dev/87y318wp9r.fsf@linux.ibm.com/
Fixes: 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines")
Reported-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/mm/pageattr.c | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
v2: Use pte_update(..., ~0, pte_val(pte), ...) as suggested by Fabiano,
and ptep_get() as suggested by Christophe.
diff --git a/arch/powerpc/mm/pageattr.c b/arch/powerpc/mm/pageattr.c
index 0876216ceee6..edea388e9d3f 100644
--- a/arch/powerpc/mm/pageattr.c
+++ b/arch/powerpc/mm/pageattr.c
@@ -18,16 +18,12 @@
/*
* Updates the attributes of a page in three steps:
*
- * 1. invalidate the page table entry
- * 2. flush the TLB
- * 3. install the new entry with the updated attributes
- *
- * Invalidating the pte means there are situations where this will not work
- * when in theory it should.
- * For example:
- * - removing write from page whilst it is being executed
- * - setting a page read-only whilst it is being read by another CPU
+ * 1. take the page_table_lock
+ * 2. install the new entry with the updated attributes
+ * 3. flush the TLB
*
+ * This sequence is safe against concurrent updates, and also allows updating the
+ * attributes of a page currently being executed or accessed.
*/
static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
{
@@ -36,9 +32,7 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
spin_lock(&init_mm.page_table_lock);
- /* invalidate the PTE so it's safe to modify */
- pte = ptep_get_and_clear(&init_mm, addr, ptep);
- flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+ pte = ptep_get(ptep);
/* modify the PTE bits as desired, then apply */
switch (action) {
@@ -59,11 +53,14 @@ static int change_page_attr(pte_t *ptep, unsigned long addr, void *data)
break;
}
- set_pte_at(&init_mm, addr, ptep, pte);
+ pte_update(&init_mm, addr, ptep, ~0UL, pte_val(pte), 0);
/* See ptesync comment in radix__set_pte_at() */
if (radix_enabled())
asm volatile("ptesync": : :"memory");
+
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+
spin_unlock(&init_mm.page_table_lock);
return 0;
base-commit: cbc06f051c524dcfe52ef0d1f30647828e226d30
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v1 2/4] powerpc/64s/perf: add power_pmu_running to query whether perf is being used
From: Nicholas Piggin @ 2021-08-18 11:41 UTC (permalink / raw)
To: linuxppc-dev, Madhavan Srinivasan; +Cc: Athira Rajeev
In-Reply-To: <2e3108d7-8d11-d204-c605-fe51cd361586@linux.ibm.com>
Excerpts from Madhavan Srinivasan's message of August 17, 2021 11:06 pm:
>
> On 8/16/21 12:59 PM, Nicholas Piggin wrote:
>> Interrupt handling code would like to know whether perf is enabled, to
>> know whether it should enable MSR[EE] to improve PMI coverage.
>>
>> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
>> Cc: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/include/asm/hw_irq.h | 2 ++
>> arch/powerpc/perf/core-book3s.c | 13 +++++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
>> index 21cc571ea9c2..2d5c0d3ccbb6 100644
>> --- a/arch/powerpc/include/asm/hw_irq.h
>> +++ b/arch/powerpc/include/asm/hw_irq.h
>> @@ -306,6 +306,8 @@ static inline bool lazy_irq_pending_nocheck(void)
>> return __lazy_irq_pending(local_paca->irq_happened);
>> }
>>
>> +bool power_pmu_running(void);
>> +
>> /*
>> * This is called by asynchronous interrupts to conditionally
>> * re-enable hard interrupts after having cleared the source
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index bb0ee716de91..76114a9afb2b 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -2380,6 +2380,19 @@ static void perf_event_interrupt(struct pt_regs *regs)
>> perf_sample_event_took(sched_clock() - start_clock);
>> }
>>
>> +bool power_pmu_running(void)
>> +{
>> + struct cpu_hw_events *cpuhw;
>> +
>> + /* Could this simply test local_paca->pmcregs_in_use? */
>> +
>> + if (!ppmu)
>> + return false;
>
>
> This covers only when perf platform driver is not registered,
> but we should also check for MMCR0[32], since pmu sprs can be
> accessed via sysfs.
In that case do they actually do anything with the PMI? I don't think it
should matter hopefully.
But I do think a lot of this stuff could be cleaned up. We have
pmcs_enabled and ppc_enable_pmcs() in sysfs.c, ppc_set_pmu_inuse(),
ppc_md.enable_pmcs(), reserve_pmc_hardware(), etc and different users
call different things. We don't consistently disable either, e.g., we
never disable the H_PERFMON facility after we stop using perf even
though it says that slows down partition switch.
I started to have a look at sorting it out but it looks like a big
job so would take a bit of time if we want to do it.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] scsi: ibmvfc: Stop using scsi_cmnd.tag
From: John Garry @ 2021-08-18 11:29 UTC (permalink / raw)
To: Martin K. Petersen
Cc: tyreld, bvanassche, linux-scsi, sfr, jejb, linux-kernel,
linux-next, paulus, hare, linuxppc-dev, hch
In-Reply-To: <yq14kbnmqoh.fsf@ca-mkp.ca.oracle.com>
Hi Martin,
>
>> Use scsi_cmd_to_rq(scsi_cmnd)->tag in preference to scsi_cmnd.tag.
>
> Applied to 5.15/scsi-staging and rebased for bisectability.
>
Thanks, and sorry for the hassle. But I would still like the maintainers
to have a look, as I was curious about current usage of scsi_cmnd.tag in
that driver.
> Just to be picky it looks like there's another scsi_cmmd tag lurking in
> qla1280.c but it's sitting behind an #ifdef DEBUG_QLA1280.
>
That driver does not even compile with DEBUG_QLA1280 set beforehand.
I'll fix that up and send as separate patches in case you want to
shuffle the tag patch in earlier, which is prob not worth the effort.
I've done a good few more x86 randconfigs and tried to audit the code
for more references, so hopefully that's the last.
Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox