[RFC] mm: Generalize notify_page_fault()
Similar notify_page_fault() definitions are being used by architectures
duplicating much of the same code. This attempts to unify them into a
single implementation, generalize it and then move it to a common place.
kprobes_built_in() can detect CONFIG_KPROBES, hence notify_page_fault()
must not be wrapped again within CONFIG_KPROBES. Trap number argument can
now contain upto an 'unsigned int' accommodating all possible platforms.
Signed-off-by: Anshuman Khandual
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: Andrew Morton
Cc: Michal Hocko
Cc: Matthew Wilcox
Cc: Mark Rutland
Cc: Christophe Leroy
Cc: Stephen Rothwell
Cc: Andrey Konovalov
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: Yoshinori Sato
Cc: "David S. Miller"
---
Boot tested on arm64 and build tested on some others.
arch/arm/mm/fault.c | 22 --
arch/arm64/mm/fault.c| 22 --
arch/ia64/mm/fault.c | 22 --
arch/powerpc/mm/fault.c | 23 ++-
arch/s390/mm/fault.c | 16 +---
arch/sh/mm/fault.c | 14 --
arch/sparc/mm/fault_64.c | 16 +---
include/linux/mm.h | 1 +
mm/memory.c | 14 ++
9 files changed, 19 insertions(+), 131 deletions(-)
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 58f69fa..1bc3b18 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -30,28 +30,6 @@
#ifdef CONFIG_MMU
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
-{
- int ret = 0;
-
- if (!user_mode(regs)) {
- /* kprobe_running() needs smp_processor_id() */
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, fsr))
- ret = 1;
- preempt_enable();
- }
-
- return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
-{
- return 0;
-}
-#endif
-
/*
* This is useful to dump out the page tables associated with
* 'addr' in mm 'mm'.
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a30818e..152f1f1 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -70,28 +70,6 @@ static inline const struct fault_info
*esr_to_debug_fault_info(unsigned int esr)
return debug_fault_info + DBG_ESR_EVT(esr);
}
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
-{
- int ret = 0;
-
- /* kprobe_running() needs smp_processor_id() */
- if (!user_mode(regs)) {
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, esr))
- ret = 1;
- preempt_enable();
- }
-
- return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, unsigned int esr)
-{
- return 0;
-}
-#endif
-
static void data_abort_decode(unsigned int esr)
{
pr_alert("Data abort info:\n");
diff --git a/arch/ia64/mm/fault.c b/arch/ia64/mm/fault.c
index 5baeb02..64283d2 100644
--- a/arch/ia64/mm/fault.c
+++ b/arch/ia64/mm/fault.c
@@ -21,28 +21,6 @@
extern int die(char *, struct pt_regs *, long);
-#ifdef CONFIG_KPROBES
-static inline int notify_page_fault(struct pt_regs *regs, int trap)
-{
- int ret = 0;
-
- if (!user_mode(regs)) {
- /* kprobe_running() needs smp_processor_id() */
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, trap))
- ret = 1;
- preempt_enable();
- }
-
- return ret;
-}
-#else
-static inline int notify_page_fault(struct pt_regs *regs, int trap)
-{
- return 0;
-}
-#endif
-
/*
* Return TRUE if ADDRESS points at a page in the kernel's mapped segment
* (inside region 5, on ia64) and that page is present.
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index b5d3578..5a0d71f 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -46,26 +46,6 @@
#include
#include
-static inline bool notify_page_fault(struct pt_regs *regs)
-{
- bool ret = false;
-
-#ifdef CONFIG_KPROBES
- /* kprobe_running() needs smp_processor_id() */
- if (!user_mode(regs)) {
- preempt_disable();
- if (kprobe_running() && kprobe_fault_handler(regs, 11))
- ret = true;
- preempt_enable();
- }
-#endif /* CONFIG_KPROBES */
-
- if (unlikely(debugger_fault_handler(regs)))
- ret = true;
-
- return ret;
-}
-
/*
* Check whether the instruction inst is a store using
[PATCH v8 7/7] ia64: hide build option IOMMU_DEFAULT_PASSTHROUGH
The DMA mode PASSTHROUGH is not used on ia64. Signed-off-by: Zhen Lei --- drivers/iommu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index f6c030433d38048..f7400e35628dce4 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -89,7 +89,7 @@ choice config IOMMU_DEFAULT_PASSTHROUGH bool "passthrough" - depends on !S390_IOMMU + depends on (!S390_IOMMU && !IA64) help In this mode, the DMA access through IOMMU without any addresses translation. That means, the wrong or illegal DMA access can not -- 1.8.3
[PATCH v8 6/7] iommu/amd: add support for IOMMU default DMA mode build options
The default DMA mode of AMD IOMMU is LAZY, this patch make it can be set
to STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei
---
drivers/iommu/Kconfig | 2 +-
drivers/iommu/amd_iommu_init.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index af580274b7c5270..f6c030433d38048 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -79,7 +79,7 @@ choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
default IOMMU_DEFAULT_PASSTHROUGH if (PPC_POWERNV && PCI)
- default IOMMU_DEFAULT_LAZY if (INTEL_IOMMU || S390_IOMMU)
+ default IOMMU_DEFAULT_LAZY if (AMD_IOMMU || INTEL_IOMMU || S390_IOMMU)
default IOMMU_DEFAULT_STRICT
help
This option allows IOMMU DMA mode to be chose at build time, to
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index f977df90d2a4912..6b0bfa43f6faa32 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -166,7 +166,8 @@ struct ivmd_header {
to handle */
LIST_HEAD(amd_iommu_unity_map);/* a list of required unity
mappings
we find in ACPI */
-bool amd_iommu_unmap_flush;/* if true, flush on every unmap */
+bool amd_iommu_unmap_flush = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
+ /* if true, flush on every unmap */
LIST_HEAD(amd_iommu_list); /* list of all AMD IOMMUs in the
system */
--
1.8.3
[PATCH v8 5/7] iommu/vt-d: add support for IOMMU default DMA mode build options
The default DMA mode of INTEL IOMMU is LAZY, this patch make it can be set to STRICT at build time. It can be overridden by boot option. There is no functional change. Signed-off-by: Zhen Lei --- drivers/iommu/Kconfig | 2 +- drivers/iommu/intel-iommu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index b5af859956c4fda..af580274b7c5270 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -79,7 +79,7 @@ choice prompt "IOMMU default DMA mode" depends on IOMMU_API default IOMMU_DEFAULT_PASSTHROUGH if (PPC_POWERNV && PCI) - default IOMMU_DEFAULT_LAZY if S390_IOMMU + default IOMMU_DEFAULT_LAZY if (INTEL_IOMMU || S390_IOMMU) default IOMMU_DEFAULT_STRICT help This option allows IOMMU DMA mode to be chose at build time, to diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index a209199f3af6460..50d74ea0acdbdca 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -362,7 +362,7 @@ static int domain_detach_iommu(struct dmar_domain *domain, static int dmar_map_gfx = 1; static int dmar_forcedac; -static int intel_iommu_strict; +static int intel_iommu_strict = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT); static int intel_iommu_superpage = 1; static int intel_iommu_sm; static int iommu_identity_mapping; -- 1.8.3
[PATCH v8 4/7] powernv/iommu: add support for IOMMU default DMA mode build options
The default DMA mode is PASSTHROUGH on powernv, this patch make it can be set to STRICT at build time. It can be overridden by boot option. There is no functional change. Signed-off-by: Zhen Lei --- arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++- drivers/iommu/Kconfig | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 126602b4e39972d..40208b9019be890 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -85,7 +85,8 @@ void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level, va_end(args); } -static bool pnv_iommu_bypass_disabled __read_mostly; +static bool pnv_iommu_bypass_disabled __read_mostly = + !IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH); static bool pci_reset_phbs __read_mostly; static int __init iommu_setup(char *str) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 9b48c2fc20e14d3..b5af859956c4fda 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -78,6 +78,7 @@ config IOMMU_DEBUGFS choice prompt "IOMMU default DMA mode" depends on IOMMU_API + default IOMMU_DEFAULT_PASSTHROUGH if (PPC_POWERNV && PCI) default IOMMU_DEFAULT_LAZY if S390_IOMMU default IOMMU_DEFAULT_STRICT help @@ -98,6 +99,7 @@ config IOMMU_DEFAULT_PASSTHROUGH config IOMMU_DEFAULT_LAZY bool "lazy" + depends on !PPC_POWERNV help Support lazy mode, where for every IOMMU DMA unmap operation, the flush operation of IOTLB and the free operation of IOVA are deferred. -- 1.8.3
[PATCH v8 1/7] iommu: enhance IOMMU default DMA mode build options
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
Signed-off-by: Zhen Lei
---
drivers/iommu/Kconfig | 42 +++---
drivers/iommu/iommu.c | 3 ++-
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 83664db5221df02..d6a1a45f80ffbf5 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -75,17 +75,45 @@ config IOMMU_DEBUGFS
debug/iommu directory, and then populate a subdirectory with
entries as required.
-config IOMMU_DEFAULT_PASSTHROUGH
- bool "IOMMU passthrough by default"
+choice
+ prompt "IOMMU default DMA mode"
depends on IOMMU_API
-help
- Enable passthrough by default, removing the need to pass in
- iommu.passthrough=on or iommu=pt through command line. If this
- is enabled, you can still disable with iommu.passthrough=off
- or iommu=nopt depending on the architecture.
+ default IOMMU_DEFAULT_STRICT
+ help
+ This option allows IOMMU DMA mode to be chose at build time, to
+ override the default DMA mode of each ARCHs, removing the need to
+ pass in kernel parameters through command line. You can still use
+ ARCHs specific boot options to override this option again.
+
+config IOMMU_DEFAULT_PASSTHROUGH
+ bool "passthrough"
+ help
+ In this mode, the DMA access through IOMMU without any addresses
+ translation. That means, the wrong or illegal DMA access can not
+ be caught, no error information will be reported.
If unsure, say N here.
+config IOMMU_DEFAULT_LAZY
+ bool "lazy"
+ help
+ Support lazy mode, where for every IOMMU DMA unmap operation, the
+ flush operation of IOTLB and the free operation of IOVA are deferred.
+ They are only guaranteed to be done before the related IOVA will be
+ reused.
+
+config IOMMU_DEFAULT_STRICT
+ bool "strict"
+ help
+ For every IOMMU DMA unmap operation, the flush operation of IOTLB and
+ the free operation of IOVA are guaranteed to be done in the unmap
+ function.
+
+ This mode is safer than the two above, but it maybe slower in some
+ high performace scenarios.
+
+endchoice
+
config OF_IOMMU
def_bool y
depends on OF && IOMMU_API
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 67ee6623f9b2a4d..56bce221285b15f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -43,7 +43,8 @@
#else
static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
#endif
-static bool iommu_dma_strict __read_mostly = true;
+static bool iommu_dma_strict __read_mostly =
+ IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
struct iommu_group {
struct kobject kobj;
--
1.8.3
[PATCH v8 2/7] x86/dma: use IS_ENABLED() to simplify the code
This patch removes the ifdefs around CONFIG_IOMMU_DEFAULT_PASSTHROUGH to improve readablity. Signed-off-by: Zhen Lei --- arch/x86/kernel/pci-dma.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c index dcd272dbd0a9330..9f2b19c35a060df 100644 --- a/arch/x86/kernel/pci-dma.c +++ b/arch/x86/kernel/pci-dma.c @@ -43,11 +43,8 @@ * It is also possible to disable by default in kernel config, and enable with * iommu=nopt at boot time. */ -#ifdef CONFIG_IOMMU_DEFAULT_PASSTHROUGH -int iommu_pass_through __read_mostly = 1; -#else -int iommu_pass_through __read_mostly; -#endif +int iommu_pass_through __read_mostly = + IS_ENABLED(CONFIG_IOMMU_DEFAULT_PASSTHROUGH); extern struct iommu_table_entry __iommu_table[], __iommu_table_end[]; -- 1.8.3
[PATCH v8 3/7] s390/pci: add support for IOMMU default DMA mode build options
The default DMA mode is LAZY on s390, this patch make it can be set to
STRICT at build time. It can be overridden by boot option.
There is no functional change.
Signed-off-by: Zhen Lei
---
arch/s390/pci/pci_dma.c | 2 +-
drivers/iommu/Kconfig | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 9e52d1527f71495..784ad1e0acecfb1 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -17,7 +17,7 @@
static struct kmem_cache *dma_region_table_cache;
static struct kmem_cache *dma_page_table_cache;
-static int s390_iommu_strict;
+static int s390_iommu_strict = IS_ENABLED(CONFIG_IOMMU_DEFAULT_STRICT);
static int zpci_refresh_global(struct zpci_dev *zdev)
{
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index d6a1a45f80ffbf5..9b48c2fc20e14d3 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -78,6 +78,7 @@ config IOMMU_DEBUGFS
choice
prompt "IOMMU default DMA mode"
depends on IOMMU_API
+ default IOMMU_DEFAULT_LAZY if S390_IOMMU
default IOMMU_DEFAULT_STRICT
help
This option allows IOMMU DMA mode to be chose at build time, to
@@ -87,6 +88,7 @@ choice
config IOMMU_DEFAULT_PASSTHROUGH
bool "passthrough"
+ depends on !S390_IOMMU
help
In this mode, the DMA access through IOMMU without any addresses
translation. That means, the wrong or illegal DMA access can not
--
1.8.3
[PATCH v8 0/7] iommu: enhance IOMMU default DMA mode build options
v7--> v8 1. Split into multiple small patches base on ARCHs or IOMMU drivers. 2. Hide the unsupported build options on the related ARCH or IOMMU. v6 --> v7: 1. Fix some text editing errors v5 --> v6: 1. give up adding boot option iommu.dma_mode v4 --> v5: As Hanjun and Thomas Gleixner's suggestion: 1. Keep the old ARCH specific boot options no change. 2. Keep build option CONFIG_IOMMU_DEFAULT_PASSTHROUGH no change. v4: As Robin Murphy's suggestion: "It's also not necessarily obvious to the user how this interacts with IOMMU_DEFAULT_PASSTHROUGH, so if we really do go down this route, maybe it would be better to refactor the whole lot into a single selection of something like IOMMU_DEFAULT_MODE anyway." In this version, I tried to normalize the IOMMU dma mode boot options for all ARCHs. When IOMMU is enabled, there are 3 dma modes: paasthrough(bypass), lazy(mapping but defer the IOTLB invalidation), strict. But currently each ARCHs defined their private boot options, different with each other. For example, to enable/disable "passthrough", ARM64 use iommu.passthrough=1/0, X86 use iommu=pt/nopt, PPC/POWERNV use iommu=nobypass. Zhen Lei (7): iommu: enhance IOMMU default DMA mode build options x86/dma: use IS_ENABLED() to simplify the code s390/pci: add support for IOMMU default DMA mode build options powernv/iommu: add support for IOMMU default DMA mode build options iommu/vt-d: add support for IOMMU default DMA mode build options iommu/amd: add support for IOMMU default DMA mode build options ia64: hide build option IOMMU_DEFAULT_PASSTHROUGH arch/powerpc/platforms/powernv/pci-ioda.c | 3 +- arch/s390/pci/pci_dma.c | 2 +- arch/x86/kernel/pci-dma.c | 7 ++--- drivers/iommu/Kconfig | 46 ++- drivers/iommu/amd_iommu_init.c| 3 +- drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/iommu.c | 3 +- 7 files changed, 49 insertions(+), 17 deletions(-) -- 1.8.3
Re: [PATCH v3 1/3] PCI: Introduce pcibios_ignore_alignment_request
On 28/05/2019 17:39, Shawn Anastasio wrote:
>
>
> On 5/28/19 1:27 AM, Alexey Kardashevskiy wrote:
>>
>>
>> On 28/05/2019 15:36, Oliver wrote:
>>> On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio
>>> wrote:
Introduce a new pcibios function pcibios_ignore_alignment_request
which allows the PCI core to defer to platform-specific code to
determine whether or not to ignore alignment requests for PCI
resources.
The existing behavior is to simply ignore alignment requests when
PCI_PROBE_ONLY is set. This is behavior is maintained by the
default implementation of pcibios_ignore_alignment_request.
Signed-off-by: Shawn Anastasio
---
drivers/pci/pci.c | 9 +++--
include/linux/pci.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8abc843b1615..8207a09085d1 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5882,6 +5882,11 @@ resource_size_t __weak
pcibios_default_alignment(void)
return 0;
}
+int __weak pcibios_ignore_alignment_request(void)
+{
+ return pci_has_flag(PCI_PROBE_ONLY);
+}
+
#define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
static char
resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
static DEFINE_SPINLOCK(resource_alignment_lock);
@@ -5906,9 +5911,9 @@ static resource_size_t
pci_specified_resource_alignment(struct pci_dev *dev,
p = resource_alignment_param;
if (!*p && !align)
goto out;
- if (pci_has_flag(PCI_PROBE_ONLY)) {
+ if (pcibios_ignore_alignment_request()) {
align = 0;
- pr_info_once("PCI: Ignoring requested alignments
(PCI_PROBE_ONLY)\n");
+ pr_info_once("PCI: Ignoring requested alignments\n");
goto out;
}
>>>
>>> I think the logic here is questionable to begin with. If the user has
>>> explicitly requested re-aligning a resource via the command line then
>>> we should probably do it even if PCI_PROBE_ONLY is set. When it breaks
>>> they get to keep the pieces.
>>>
>>> That said, the real issue here is that PCI_PROBE_ONLY probably
>>> shouldn't be set under qemu/kvm. Under the other hypervisor (PowerVM)
>>> hotplugged devices are configured by firmware before it's passed to
>>> the guest and we need to keep the FW assignments otherwise things
>>> break. QEMU however doesn't do any BAR assignments and relies on that
>>> being handled by the guest. At boot time this is done by SLOF, but
>>> Linux only keeps SLOF around until it's extracted the device-tree.
>>> Once that's done SLOF gets blown away and the kernel needs to do it's
>>> own BAR assignments. I'm guessing there's a hack in there to make it
>>> work today, but it's a little surprising that it works at all...
>>
>>
>> The hack is to run a modified qemu-aware "/usr/sbin/rtas_errd" in the
>> guest which receives an event from qemu (RAS_EPOW from
>> /proc/interrupts), fetches device tree chunks (and as I understand it -
>> they come with BARs from phyp but without from qemu) and writes "1" to
>> "/sys/bus/pci/rescan" which calls pci_assign_resource() eventually:
>
> Interesting. Does this mean that the PHYP hotplug path doesn't
> call pci_assign_resource?
I'd expect dlpar_add_slot() to be called under phyp and eventually
pci_device_add() which (I think) may or may not trigger later reassignment.
> If so it means the patch may not
> break that platform after all, though it still may not be
> the correct way of doing things.
We should probably stop enforcing the PCI_PROBE_ONLY flag - it seems
that (unless resource_alignment= is used) the pseries guest should just
walk through all allocated resources and leave them unchanged.
>> [c6e6f960] [c05f62d4] pci_assign_resource+0x44/0x360
>>
>> [c6e6fa10] [c05f8b54]
>> assign_requested_resources_sorted+0x84/0x110
>> [c6e6fa60] [c05f9540]
>> __assign_resources_sorted+0xd0/0x750
>> [c6e6fb40] [c05fb2e0]
>> __pci_bus_assign_resources+0x80/0x280
>> [c6e6fc00] [c05fb95c]
>> pci_assign_unassigned_bus_resources+0xbc/0x100
>> [c6e6fc60] [c05e3d74] pci_rescan_bus+0x34/0x60
>>
>> [c6e6fc90] [c05f1ef4] rescan_store+0x84/0xc0
>>
>> [c6e6fcd0] [c068060c] bus_attr_store+0x3c/0x60
>>
>> [c6e6fcf0] [c037853c] sysfs_kf_write+0x5c/0x80
>>
>>
>>
>>
>>
>>>
>>> IIRC Sam Bobroff was looking at hotplug under pseries recently so he
>>> might have something to add. He's sick at the moment, but I'll ask him
>>> to take a look at this once he's back among the living
>>>
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4a5a84d7bdd4..47471dcdbaf9 100644
---
[PATCH 4.9 087/128] cpufreq: pmac32: fix possible object reference leak
[ Upstream commit 8d10dc28a9ea6e8c02e825dab28699f3c72b02d9 ]
The call to of_find_node_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 587, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linux...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
---
drivers/cpufreq/pmac32-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index ff44016ea0312..641f8021855a7 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -551,6 +551,7 @@ static int pmac_cpufreq_init_7447A(struct device_node
*cpunode)
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
if (!voltage_gpio){
pr_err("missing cpu-vcore-select gpio\n");
return 1;
@@ -587,6 +588,7 @@ static int pmac_cpufreq_init_750FX(struct device_node
*cpunode)
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
pvr = mfspr(SPRN_PVR);
has_cpu_l2lve = !((pvr & 0xf00) == 0x100);
--
2.20.1
[PATCH 4.9 086/128] cpufreq/pasemi: fix possible object reference leak
[ Upstream commit a9acc26b75f652f697e02a9febe2ab0da648a571 ] The call to of_get_cpu_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pasemi-cpufreq.c:212:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. ./drivers/cpufreq/pasemi-cpufreq.c:220:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin --- drivers/cpufreq/pasemi-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c index 35dd4d7ffee08..58c933f483004 100644 --- a/drivers/cpufreq/pasemi-cpufreq.c +++ b/drivers/cpufreq/pasemi-cpufreq.c @@ -146,6 +146,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy) cpu = of_get_cpu_node(policy->cpu, NULL); + of_node_put(cpu); if (!cpu) goto out; -- 2.20.1
[PATCH 4.9 107/128] ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put
[ Upstream commit c705247136a523488eac806bd357c3e5d79a7acd ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node
pointer with refcount incremented on line 38, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl_utils.c b/sound/soc/fsl/fsl_utils.c
index b9e42b503a377..4f8bdb7650e84 100644
--- a/sound/soc/fsl/fsl_utils.c
+++ b/sound/soc/fsl/fsl_utils.c
@@ -75,6 +75,7 @@ int fsl_asoc_get_dma_channel(struct device_node *ssi_np,
iprop = of_get_property(dma_np, "cell-index", NULL);
if (!iprop) {
of_node_put(dma_np);
+ of_node_put(dma_channel_np);
return -EINVAL;
}
*dma_id = be32_to_cpup(iprop);
--
2.20.1
[PATCH 4.14 159/193] ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put
[ Upstream commit c705247136a523488eac806bd357c3e5d79a7acd ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node
pointer with refcount incremented on line 38, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl_utils.c b/sound/soc/fsl/fsl_utils.c
index b9e42b503a377..4f8bdb7650e84 100644
--- a/sound/soc/fsl/fsl_utils.c
+++ b/sound/soc/fsl/fsl_utils.c
@@ -75,6 +75,7 @@ int fsl_asoc_get_dma_channel(struct device_node *ssi_np,
iprop = of_get_property(dma_np, "cell-index", NULL);
if (!iprop) {
of_node_put(dma_np);
+ of_node_put(dma_channel_np);
return -EINVAL;
}
*dma_id = be32_to_cpup(iprop);
--
2.20.1
[PATCH 4.14 132/193] cpufreq: pmac32: fix possible object reference leak
[ Upstream commit 8d10dc28a9ea6e8c02e825dab28699f3c72b02d9 ]
The call to of_find_node_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 587, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linux...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
---
drivers/cpufreq/pmac32-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index 61ae06ca008e7..e225edb5c3593 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -552,6 +552,7 @@ static int pmac_cpufreq_init_7447A(struct device_node
*cpunode)
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
if (!voltage_gpio){
pr_err("missing cpu-vcore-select gpio\n");
return 1;
@@ -588,6 +589,7 @@ static int pmac_cpufreq_init_750FX(struct device_node
*cpunode)
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
pvr = mfspr(SPRN_PVR);
has_cpu_l2lve = !((pvr & 0xf00) == 0x100);
--
2.20.1
[PATCH 4.14 131/193] cpufreq/pasemi: fix possible object reference leak
[ Upstream commit a9acc26b75f652f697e02a9febe2ab0da648a571 ] The call to of_get_cpu_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pasemi-cpufreq.c:212:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. ./drivers/cpufreq/pasemi-cpufreq.c:220:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin --- drivers/cpufreq/pasemi-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c index b257fc7d52041..8456492124f0c 100644 --- a/drivers/cpufreq/pasemi-cpufreq.c +++ b/drivers/cpufreq/pasemi-cpufreq.c @@ -146,6 +146,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy) cpu = of_get_cpu_node(policy->cpu, NULL); + of_node_put(cpu); if (!cpu) goto out; -- 2.20.1
[PATCH 4.19 181/276] cpufreq: pmac32: fix possible object reference leak
[ Upstream commit 8d10dc28a9ea6e8c02e825dab28699f3c72b02d9 ]
The call to of_find_node_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 587, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linux...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
---
drivers/cpufreq/pmac32-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index 61ae06ca008e7..e225edb5c3593 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -552,6 +552,7 @@ static int pmac_cpufreq_init_7447A(struct device_node
*cpunode)
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
if (!voltage_gpio){
pr_err("missing cpu-vcore-select gpio\n");
return 1;
@@ -588,6 +589,7 @@ static int pmac_cpufreq_init_750FX(struct device_node
*cpunode)
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
pvr = mfspr(SPRN_PVR);
has_cpu_l2lve = !((pvr & 0xf00) == 0x100);
--
2.20.1
[PATCH 4.19 180/276] cpufreq/pasemi: fix possible object reference leak
[ Upstream commit a9acc26b75f652f697e02a9febe2ab0da648a571 ] The call to of_get_cpu_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pasemi-cpufreq.c:212:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. ./drivers/cpufreq/pasemi-cpufreq.c:220:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin --- drivers/cpufreq/pasemi-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c index 75dfbd2a58ea6..c7710c149de85 100644 --- a/drivers/cpufreq/pasemi-cpufreq.c +++ b/drivers/cpufreq/pasemi-cpufreq.c @@ -146,6 +146,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy) cpu = of_get_cpu_node(policy->cpu, NULL); + of_node_put(cpu); if (!cpu) goto out; -- 2.20.1
[PATCH 4.19 215/276] ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put
[ Upstream commit c705247136a523488eac806bd357c3e5d79a7acd ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node
pointer with refcount incremented on line 38, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl_utils.c b/sound/soc/fsl/fsl_utils.c
index 7f0fa4b522231..cca33ab7020a4 100644
--- a/sound/soc/fsl/fsl_utils.c
+++ b/sound/soc/fsl/fsl_utils.c
@@ -71,6 +71,7 @@ int fsl_asoc_get_dma_channel(struct device_node *ssi_np,
iprop = of_get_property(dma_np, "cell-index", NULL);
if (!iprop) {
of_node_put(dma_np);
+ of_node_put(dma_channel_np);
return -EINVAL;
}
*dma_id = be32_to_cpup(iprop);
--
2.20.1
[PATCH 5.0 249/346] ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put
[ Upstream commit c705247136a523488eac806bd357c3e5d79a7acd ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node
pointer with refcount incremented on line 38, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl_utils.c b/sound/soc/fsl/fsl_utils.c
index 9981668ab5909..040d06b89f00a 100644
--- a/sound/soc/fsl/fsl_utils.c
+++ b/sound/soc/fsl/fsl_utils.c
@@ -71,6 +71,7 @@ int fsl_asoc_get_dma_channel(struct device_node *ssi_np,
iprop = of_get_property(dma_np, "cell-index", NULL);
if (!iprop) {
of_node_put(dma_np);
+ of_node_put(dma_channel_np);
return -EINVAL;
}
*dma_id = be32_to_cpup(iprop);
--
2.20.1
[PATCH 5.0 208/346] cpufreq: pmac32: fix possible object reference leak
[ Upstream commit 8d10dc28a9ea6e8c02e825dab28699f3c72b02d9 ]
The call to of_find_node_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 587, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linux...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
---
drivers/cpufreq/pmac32-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index 52f0d91d30c17..9b4ce2eb8222c 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -552,6 +552,7 @@ static int pmac_cpufreq_init_7447A(struct device_node
*cpunode)
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
if (!voltage_gpio){
pr_err("missing cpu-vcore-select gpio\n");
return 1;
@@ -588,6 +589,7 @@ static int pmac_cpufreq_init_750FX(struct device_node
*cpunode)
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
pvr = mfspr(SPRN_PVR);
has_cpu_l2lve = !((pvr & 0xf00) == 0x100);
--
2.20.1
[PATCH 5.0 207/346] cpufreq/pasemi: fix possible object reference leak
[ Upstream commit a9acc26b75f652f697e02a9febe2ab0da648a571 ] The call to of_get_cpu_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pasemi-cpufreq.c:212:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. ./drivers/cpufreq/pasemi-cpufreq.c:220:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin --- drivers/cpufreq/pasemi-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c index 75dfbd2a58ea6..c7710c149de85 100644 --- a/drivers/cpufreq/pasemi-cpufreq.c +++ b/drivers/cpufreq/pasemi-cpufreq.c @@ -146,6 +146,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy) cpu = of_get_cpu_node(policy->cpu, NULL); + of_node_put(cpu); if (!cpu) goto out; -- 2.20.1
[PATCH 5.1 275/405] ASoC: fsl_utils: fix a leaked reference by adding missing of_node_put
[ Upstream commit c705247136a523488eac806bd357c3e5d79a7acd ]
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/fsl_utils.c:74:2-8: ERROR: missing of_node_put; acquired a node
pointer with refcount incremented on line 38, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/fsl_utils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/fsl_utils.c b/sound/soc/fsl/fsl_utils.c
index 9981668ab5909..040d06b89f00a 100644
--- a/sound/soc/fsl/fsl_utils.c
+++ b/sound/soc/fsl/fsl_utils.c
@@ -71,6 +71,7 @@ int fsl_asoc_get_dma_channel(struct device_node *ssi_np,
iprop = of_get_property(dma_np, "cell-index", NULL);
if (!iprop) {
of_node_put(dma_np);
+ of_node_put(dma_channel_np);
return -EINVAL;
}
*dma_id = be32_to_cpup(iprop);
--
2.20.1
[PATCH 5.1 226/405] cpufreq/pasemi: fix possible object reference leak
[ Upstream commit a9acc26b75f652f697e02a9febe2ab0da648a571 ] The call to of_get_cpu_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/cpufreq/pasemi-cpufreq.c:212:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. ./drivers/cpufreq/pasemi-cpufreq.c:220:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 147, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: "Rafael J. Wysocki" Cc: Viresh Kumar Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin --- drivers/cpufreq/pasemi-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c index 75dfbd2a58ea6..c7710c149de85 100644 --- a/drivers/cpufreq/pasemi-cpufreq.c +++ b/drivers/cpufreq/pasemi-cpufreq.c @@ -146,6 +146,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy) cpu = of_get_cpu_node(policy->cpu, NULL); + of_node_put(cpu); if (!cpu) goto out; -- 2.20.1
[PATCH 5.1 227/405] cpufreq: pmac32: fix possible object reference leak
[ Upstream commit 8d10dc28a9ea6e8c02e825dab28699f3c72b02d9 ]
The call to of_find_node_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
./drivers/cpufreq/pmac32-cpufreq.c:557:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:569:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 552, but without a
corresponding object release within this function.
./drivers/cpufreq/pmac32-cpufreq.c:598:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 587, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linux...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
---
drivers/cpufreq/pmac32-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/pmac32-cpufreq.c b/drivers/cpufreq/pmac32-cpufreq.c
index 52f0d91d30c17..9b4ce2eb8222c 100644
--- a/drivers/cpufreq/pmac32-cpufreq.c
+++ b/drivers/cpufreq/pmac32-cpufreq.c
@@ -552,6 +552,7 @@ static int pmac_cpufreq_init_7447A(struct device_node
*cpunode)
volt_gpio_np = of_find_node_by_name(NULL, "cpu-vcore-select");
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
if (!voltage_gpio){
pr_err("missing cpu-vcore-select gpio\n");
return 1;
@@ -588,6 +589,7 @@ static int pmac_cpufreq_init_750FX(struct device_node
*cpunode)
if (volt_gpio_np)
voltage_gpio = read_gpio(volt_gpio_np);
+ of_node_put(volt_gpio_np);
pvr = mfspr(SPRN_PVR);
has_cpu_l2lve = !((pvr & 0xf00) == 0x100);
--
2.20.1
Re: [PATCH] powerpc/mm: Move some of the boot time info print to generic file
On 5/29/19 9:25 PM, Christophe Leroy wrote: "Aneesh Kumar K.V" a écrit : With radix translation enabled we find in dmesg hash-mmu: ppc64_pft_size = 0x0 hash-mmu: kernel vmalloc start = 0xc008 hash-mmu: kernel IO start = 0xc00a hash-mmu: kernel vmemmap start = 0xc00c This is because these pr_info calls are in hash_utils.c which has #define pr_fmt(fmt) "hash-mmu: " fmt The information printed in generic and hence move that to generic file Some similarities with Nick's patch https://patchwork.ozlabs.org/patch/1100245/ ? I missed that completely. -aneesh
Re: [PATCH] powerpc/powernv: Show checkstop reason for NPU2 HMIs
On 23/5/19 10:28 pm, Frederic Barrat wrote:
If the kernel is notified of an HMI caused by the NPU2, it's currently
not being recognized and it logs the default message:
Unknown Malfunction Alert of type 3
The NPU on Power 9 has 3 Fault Isolation Registers, so that's a lot of
possible causes, but we should at least log that it's an NPU problem
and report which FIR and which bit were raised if opal gave us the
information.
Signed-off-by: Frederic Barrat
---
Could be merged independently from (the opal-api.h change is already
in the skiboot tree), but works better with, the matching skiboot
change:
http://patchwork.ozlabs.org/patch/1104076/
Still always safest to hold off until merged into skiboot :)
Reviewed-by: Andrew Donnellan
arch/powerpc/include/asm/opal-api.h | 1 +
arch/powerpc/platforms/powernv/opal-hmi.c | 40 +++
2 files changed, 41 insertions(+)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index e1577cfa7186..2492fe248e1e 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -568,6 +568,7 @@ enum OpalHMI_XstopType {
CHECKSTOP_TYPE_UNKNOWN = 0,
CHECKSTOP_TYPE_CORE = 1,
CHECKSTOP_TYPE_NX = 2,
+ CHECKSTOP_TYPE_NPU = 3
};
enum OpalHMI_CoreXstopReason {
diff --git a/arch/powerpc/platforms/powernv/opal-hmi.c
b/arch/powerpc/platforms/powernv/opal-hmi.c
index 586ec71a4e17..de12a240b477 100644
--- a/arch/powerpc/platforms/powernv/opal-hmi.c
+++ b/arch/powerpc/platforms/powernv/opal-hmi.c
@@ -149,6 +149,43 @@ static void print_nx_checkstop_reason(const char *level,
xstop_reason[i].description);
}
+static void print_npu_checkstop_reason(const char *level,
+ struct OpalHMIEvent *hmi_evt)
+{
+ uint8_t reason, reason_count, i;
+
+ /*
+* We may not have a checkstop reason on some combination of
+* hardware and/or skiboot version
+*/
+ if (!hmi_evt->u.xstop_error.xstop_reason) {
+ printk("%s NPU checkstop on chip %x\n", level,
+ be32_to_cpu(hmi_evt->u.xstop_error.u.chip_id));
+ return;
+ }
+
+ /*
+* NPU2 has 3 FIRs. Reason encoded on a byte as:
+* 2 bits for the FIR number
+* 6 bits for the bit number
+* It may be possible to find several reasons.
+*
+* We don't display a specific message per FIR bit as there
+* are too many and most are meaningless without the workbook
+* and/or hw team help anyway.
+*/
+ reason_count = sizeof(hmi_evt->u.xstop_error.xstop_reason) /
+ sizeof(reason);
+ for (i = 0; i < reason_count; i++) {
+ reason = (hmi_evt->u.xstop_error.xstop_reason >> (8 * i)) &
0xFF;
very nitpicky: should we call be32_to_cpu() so that the bits appear in
order?
+ if (reason)
+ printk("%s NPU checkstop on chip %x: FIR%d bit %d is
set\n",
+ level,
+ be32_to_cpu(hmi_evt->u.xstop_error.u.chip_id),
+ reason >> 6, reason & 0x3F);
+ }
+}
+
static void print_checkstop_reason(const char *level,
struct OpalHMIEvent *hmi_evt)
{
@@ -160,6 +197,9 @@ static void print_checkstop_reason(const char *level,
case CHECKSTOP_TYPE_NX:
print_nx_checkstop_reason(level, hmi_evt);
break;
+ case CHECKSTOP_TYPE_NPU:
+ print_npu_checkstop_reason(level, hmi_evt);
+ break;
default:
printk("%s Unknown Malfunction Alert of type %d\n",
level, type);
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH v2 1/3] ibmvscsi: Wire up host_reset() in the drivers scsi_host_template
Tyrel, > Wire up the host_reset function in our driver_template to allow a user > requested adpater reset via the host_reset sysfs attribute. Series applied to 5.3/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH] dlpar: Fix a missing-check bug in dlpar_parse_cc_property()
In dlpar_parse_cc_property(), 'prop->name' is allocated by kstrdup().
kstrdup() may return NULL, so it should be checked and handle error.
And prop should be freed if 'prop->name' is NULL.
Signed-off-by: Gen Zhang
Acked-by: Nathan Lynch
---
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 1795804..c852024 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -61,6 +61,10 @@ static struct property *dlpar_parse_cc_property(struct
cc_workarea *ccwa)
name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
prop->name = kstrdup(name, GFP_KERNEL);
+ if (!prop->name) {
+ dlpar_free_cc_property(prop);
+ return NULL;
+ }
prop->length = be32_to_cpu(ccwa->prop_length);
value = (char *)ccwa + be32_to_cpu(ccwa->prop_offset);
---
[PATCH 22/22] docs: fix broken documentation links
Mostly due to x86 and acpi conversion, several documentation links are still pointing to the old file. Fix them. Signed-off-by: Mauro Carvalho Chehab --- Documentation/acpi/dsd/leds.txt | 2 +- Documentation/admin-guide/kernel-parameters.rst | 6 +++--- Documentation/admin-guide/kernel-parameters.txt | 16 Documentation/admin-guide/ras.rst| 2 +- .../devicetree/bindings/net/fsl-enetc.txt| 7 +++ .../bindings/pci/amlogic,meson-pcie.txt | 2 +- .../bindings/regulator/qcom,rpmh-regulator.txt | 2 +- Documentation/devicetree/booting-without-of.txt | 2 +- Documentation/driver-api/gpio/board.rst | 2 +- Documentation/driver-api/gpio/consumer.rst | 2 +- .../firmware-guide/acpi/enumeration.rst | 2 +- .../firmware-guide/acpi/method-tracing.rst | 2 +- Documentation/i2c/instantiating-devices | 2 +- Documentation/sysctl/kernel.txt | 4 ++-- .../translations/it_IT/process/howto.rst | 2 +- .../it_IT/process/stable-kernel-rules.rst| 4 ++-- .../translations/zh_CN/process/4.Coding.rst | 2 +- Documentation/x86/x86_64/5level-paging.rst | 2 +- Documentation/x86/x86_64/boot-options.rst| 4 ++-- .../x86/x86_64/fake-numa-for-cpusets.rst | 2 +- MAINTAINERS | 6 +++--- arch/arm/Kconfig | 2 +- arch/arm64/kernel/kexec_image.c | 2 +- arch/powerpc/Kconfig | 2 +- arch/x86/Kconfig | 16 arch/x86/Kconfig.debug | 2 +- arch/x86/boot/header.S | 2 +- arch/x86/entry/entry_64.S| 2 +- arch/x86/include/asm/bootparam_utils.h | 2 +- arch/x86/include/asm/page_64_types.h | 2 +- arch/x86/include/asm/pgtable_64_types.h | 2 +- arch/x86/kernel/cpu/microcode/amd.c | 2 +- arch/x86/kernel/kexec-bzimage64.c| 2 +- arch/x86/kernel/pci-dma.c| 2 +- arch/x86/mm/tlb.c| 2 +- arch/x86/platform/pvh/enlighten.c| 2 +- drivers/acpi/Kconfig | 10 +- drivers/net/ethernet/faraday/ftgmac100.c | 2 +- .../fieldbus/Documentation/fieldbus_dev.txt | 4 ++-- drivers/vhost/vhost.c| 2 +- include/acpi/acpi_drivers.h | 2 +- include/linux/fs_context.h | 2 +- include/linux/lsm_hooks.h| 2 +- mm/Kconfig | 2 +- security/Kconfig | 2 +- tools/include/linux/err.h| 2 +- tools/objtool/Documentation/stack-validation.txt | 4 ++-- tools/testing/selftests/x86/protection_keys.c| 2 +- 48 files changed, 77 insertions(+), 78 deletions(-) diff --git a/Documentation/acpi/dsd/leds.txt b/Documentation/acpi/dsd/leds.txt index 81a63af42ed2..cc58b1a574c5 100644 --- a/Documentation/acpi/dsd/leds.txt +++ b/Documentation/acpi/dsd/leds.txt @@ -96,4 +96,4 @@ where http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>, referenced 2019-02-21. -[7] Documentation/acpi/dsd/data-node-reference.txt +[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 0124980dca2d..8d3273e32eb1 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -167,7 +167,7 @@ parameter is applicable:: X86-32 X86-32, aka i386 architecture is enabled. X86-64 X86-64 architecture is enabled. More X86-64 boot options can be found in - Documentation/x86/x86_64/boot-options.txt . + Documentation/x86/x86_64/boot-options.rst. X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64) X86_UV SGI UV support is enabled. XEN Xen support is enabled @@ -181,10 +181,10 @@ In addition, the following text indicates that the option:: Parameters denoted with BOOT are actually interpreted by the boot loader, and have no meaning to the kernel directly. Do not modify the syntax of boot loader parameters without extreme -need or coordination with . +need or coordination with . There are also arch-specific kernel-parameters not documented here. -See for example . +See for example . Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index
Re: [PATCH v2] mm: hwpoison: disable memory error handling on 1GB hugepage
On 5/28/19 2:49 AM, Wanpeng Li wrote: > Cc Paolo, > Hi all, > On Wed, 14 Feb 2018 at 06:34, Mike Kravetz wrote: >> >> On 02/12/2018 06:48 PM, Michael Ellerman wrote: >>> Andrew Morton writes: >>> On Thu, 08 Feb 2018 12:30:45 + Punit Agrawal wrote: >> >> So I don't think that the above test result means that errors are >> properly >> handled, and the proposed patch should help for arm64. > > Although, the deviation of pud_huge() avoids a kernel crash the code > would be easier to maintain and reason about if arm64 helpers are > consistent with expectations by core code. > > I'll look to update the arm64 helpers once this patch gets merged. But > it would be helpful if there was a clear expression of semantics for > pud_huge() for various cases. Is there any version that can be used as > reference? Is that an ack or tested-by? Mike keeps plaintively asking the powerpc developers to take a look, but they remain steadfastly in hiding. >>> >>> Cc'ing linuxppc-dev is always a good idea :) >>> >> >> Thanks Michael, >> >> I was mostly concerned about use cases for soft/hard offline of huge pages >> larger than PMD_SIZE on powerpc. I know that powerpc supports PGD_SIZE >> huge pages, and soft/hard offline support was specifically added for this. >> See, 94310cbcaa3c "mm/madvise: enable (soft|hard) offline of HugeTLB pages >> at PGD level" >> >> This patch will disable that functionality. So, at a minimum this is a >> 'heads up'. If there are actual use cases that depend on this, then more >> work/discussions will need to happen. From the e-mail thread on PGD_SIZE >> support, I can not tell if there is a real use case or this is just a >> 'nice to have'. > > 1GB hugetlbfs pages are used by DPDK and VMs in cloud deployment, we > encounter gup_pud_range() panic several times in product environment. > Is there any plan to reenable and fix arch codes? I too am aware of slightly more interest in 1G huge pages. Suspect that as Intel MMU capacity increases to handle more TLB entries there will be more and more interest. Personally, I am not looking at this issue. Perhaps Naoya will comment as he know most about this code. > In addition, > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kvm/mmu.c#n3213 > The memory in guest can be 1GB/2MB/4K, though the host-backed memory > are 1GB hugetlbfs pages, after above PUD panic is fixed, > try_to_unmap() which is called in MCA recovery path will mark the PUD > hwpoison entry. The guest will vmexit and retry endlessly when > accessing any memory in the guest which is backed by this 1GB poisoned > hugetlbfs page. We have a plan to split this 1GB hugetblfs page by 2MB > hugetlbfs pages/4KB pages, maybe file remap to a virtual address range > which is 2MB/4KB page granularity, also split the KVM MMU 1GB SPTE > into 2MB/4KB and mark the offensive SPTE w/ a hwpoison flag, a sigbus > will be delivered to VM at page fault next time for the offensive > SPTE. Is this proposal acceptable? I am not sure of the error handling design, but this does sound reasonable. That block of code which potentially dissolves a huge page on memory error is hard to understand and I'm not sure if that is even the 'normal' functionality. Certainly, we would hate to waste/poison an entire 1G page for an error on a small subsection. -- Mike Kravetz
[PATCH 00/22] Some documentation fixes
Fix several warnings and broken links. This series was generated against linux-next, but was rebased to be applied at docs-next. It should apply cleanly on either tree. There's a git tree with all of them applied on the top of docs/docs-next at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=fix_doc_links_v2 Mauro Carvalho Chehab (21): ABI: sysfs-devices-system-cpu: point to the right docs isdn: mISDN: remove a bogus reference to a non-existing doc dt: fix broken references to nand.txt docs: zh_CN: get rid of basic_profiling.txt doc: it_IT: fix reference to magic-number.rst docs: mm: numaperf.rst: get rid of a build warning docs: bpf: get rid of two warnings docs: mark orphan documents as such docs: amd-memory-encryption.rst get rid of warnings gpu: amdgpu: fix broken amdgpu_dma_buf.c references gpu: i915.rst: Fix references to renamed files docs: zh_CN: avoid duplicate citation references docs: vm: hmm.rst: fix some warnings docs: it: license-rules.rst: get rid of warnings docs: gpio: driver.rst: fix a bad tag docs: soundwire: locking: fix tags for a code-block docs: security: trusted-encrypted.rst: fix code-block tag docs: security: core.rst: Fix several warnings docs: net: dpio-driver.rst: fix two codeblock warnings docs: net: sja1105.rst: fix table format docs: fix broken documentation links Otto Sabart (1): mfd: madera: Fix bad reference to pinctrl.txt file .../ABI/testing/sysfs-devices-system-cpu | 3 +- Documentation/accelerators/ocxl.rst | 2 + Documentation/acpi/dsd/leds.txt | 2 +- .../admin-guide/kernel-parameters.rst | 6 +- .../admin-guide/kernel-parameters.txt | 16 ++--- Documentation/admin-guide/mm/numaperf.rst | 5 +- Documentation/admin-guide/ras.rst | 2 +- Documentation/arm/stm32/overview.rst | 2 + .../arm/stm32/stm32f429-overview.rst | 2 + .../arm/stm32/stm32f746-overview.rst | 2 + .../arm/stm32/stm32f769-overview.rst | 2 + .../arm/stm32/stm32h743-overview.rst | 2 + .../arm/stm32/stm32mp157-overview.rst | 2 + Documentation/bpf/btf.rst | 2 + .../bindings/mtd/amlogic,meson-nand.txt | 2 +- .../devicetree/bindings/mtd/gpmc-nand.txt | 2 +- .../devicetree/bindings/mtd/marvell-nand.txt | 2 +- .../devicetree/bindings/mtd/tango-nand.txt| 2 +- .../devicetree/bindings/net/fsl-enetc.txt | 7 +- .../bindings/pci/amlogic,meson-pcie.txt | 2 +- .../regulator/qcom,rpmh-regulator.txt | 2 +- .../devicetree/booting-without-of.txt | 2 +- Documentation/driver-api/gpio/board.rst | 2 +- Documentation/driver-api/gpio/consumer.rst| 2 +- Documentation/driver-api/gpio/driver.rst | 2 +- .../driver-api/soundwire/locking.rst | 4 +- .../firmware-guide/acpi/enumeration.rst | 2 +- .../firmware-guide/acpi/method-tracing.rst| 2 +- Documentation/gpu/amdgpu.rst | 4 +- Documentation/gpu/i915.rst| 6 +- Documentation/gpu/msm-crash-dump.rst | 2 + Documentation/i2c/instantiating-devices | 2 +- Documentation/interconnect/interconnect.rst | 2 + Documentation/laptops/lg-laptop.rst | 2 + .../freescale/dpaa2/dpio-driver.rst | 4 +- Documentation/networking/dsa/sja1105.rst | 6 +- Documentation/powerpc/isa-versions.rst| 2 + Documentation/security/keys/core.rst | 16 +++-- .../security/keys/trusted-encrypted.rst | 4 +- Documentation/sysctl/kernel.txt | 4 +- .../translations/it_IT/process/howto.rst | 2 +- .../it_IT/process/license-rules.rst | 28 .../it_IT/process/magic-number.rst| 2 +- .../it_IT/process/stable-kernel-rules.rst | 4 +- .../translations/zh_CN/basic_profiling.txt| 71 --- .../translations/zh_CN/process/4.Coding.rst | 2 +- .../zh_CN/process/management-style.rst| 4 +- .../zh_CN/process/programming-language.rst| 28 .../virtual/kvm/amd-memory-encryption.rst | 5 ++ Documentation/virtual/kvm/vcpu-requests.rst | 2 + Documentation/vm/hmm.rst | 9 ++- Documentation/x86/x86_64/5level-paging.rst| 2 +- Documentation/x86/x86_64/boot-options.rst | 4 +- .../x86/x86_64/fake-numa-for-cpusets.rst | 2 +- MAINTAINERS | 6 +- arch/arm/Kconfig | 2 +- arch/arm64/kernel/kexec_image.c | 2 +- arch/powerpc/Kconfig | 2 +- arch/x86/Kconfig | 16 ++--- arch/x86/Kconfig.debug| 2 +- arch/x86/boot/header.S| 2 +- arch/x86/entry/entry_64.S | 2 +- arch/x86/include/asm/bootparam_utils.h| 2 +- arch/x86/include/asm/page_64_types.h | 2 +-
[PATCH 09/22] docs: mark orphan documents as such
Sphinx doesn't like orphan documents: Documentation/accelerators/ocxl.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32f746-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32f769-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32h743-overview.rst: WARNING: document isn't included in any toctree Documentation/arm/stm32/stm32mp157-overview.rst: WARNING: document isn't included in any toctree Documentation/gpu/msm-crash-dump.rst: WARNING: document isn't included in any toctree Documentation/interconnect/interconnect.rst: WARNING: document isn't included in any toctree Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in any toctree Documentation/powerpc/isa-versions.rst: WARNING: document isn't included in any toctree Documentation/virtual/kvm/amd-memory-encryption.rst: WARNING: document isn't included in any toctree Documentation/virtual/kvm/vcpu-requests.rst: WARNING: document isn't included in any toctree So, while they aren't on any toctree, add :orphan: to them, in order to silent this warning. Signed-off-by: Mauro Carvalho Chehab --- Documentation/accelerators/ocxl.rst | 2 ++ Documentation/arm/stm32/overview.rst| 2 ++ Documentation/arm/stm32/stm32f429-overview.rst | 2 ++ Documentation/arm/stm32/stm32f746-overview.rst | 2 ++ Documentation/arm/stm32/stm32f769-overview.rst | 2 ++ Documentation/arm/stm32/stm32h743-overview.rst | 2 ++ Documentation/arm/stm32/stm32mp157-overview.rst | 2 ++ Documentation/gpu/msm-crash-dump.rst| 2 ++ Documentation/interconnect/interconnect.rst | 2 ++ Documentation/laptops/lg-laptop.rst | 2 ++ Documentation/powerpc/isa-versions.rst | 2 ++ Documentation/virtual/kvm/amd-memory-encryption.rst | 2 ++ Documentation/virtual/kvm/vcpu-requests.rst | 2 ++ 13 files changed, 26 insertions(+) diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst index 14cefc020e2d..b1cea19a90f5 100644 --- a/Documentation/accelerators/ocxl.rst +++ b/Documentation/accelerators/ocxl.rst @@ -1,3 +1,5 @@ +:orphan: + OpenCAPI (Open Coherent Accelerator Processor Interface) diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arm/stm32/overview.rst index 85cfc8410798..f7e734153860 100644 --- a/Documentation/arm/stm32/overview.rst +++ b/Documentation/arm/stm32/overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32 ARM Linux Overview diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arm/stm32/stm32f429-overview.rst index 18feda97f483..65bbb1c3b423 100644 --- a/Documentation/arm/stm32/stm32f429-overview.rst +++ b/Documentation/arm/stm32/stm32f429-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32F429 Overview == diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arm/stm32/stm32f746-overview.rst index b5f4b6ce7656..42d593085015 100644 --- a/Documentation/arm/stm32/stm32f746-overview.rst +++ b/Documentation/arm/stm32/stm32f746-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32F746 Overview == diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arm/stm32/stm32f769-overview.rst index 228656ced2fe..f6adac862b17 100644 --- a/Documentation/arm/stm32/stm32f769-overview.rst +++ b/Documentation/arm/stm32/stm32f769-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32F769 Overview == diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arm/stm32/stm32h743-overview.rst index 3458dc00095d..c525835e7473 100644 --- a/Documentation/arm/stm32/stm32h743-overview.rst +++ b/Documentation/arm/stm32/stm32h743-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32H743 Overview == diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst index 62e176d47ca7..2c52cd020601 100644 --- a/Documentation/arm/stm32/stm32mp157-overview.rst +++ b/Documentation/arm/stm32/stm32mp157-overview.rst @@ -1,3 +1,5 @@ +:orphan: + STM32MP157 Overview === diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst index 757cd257e0d8..240ef200f76c 100644 --- a/Documentation/gpu/msm-crash-dump.rst +++ b/Documentation/gpu/msm-crash-dump.rst @@ -1,3 +1,5 @@ +:orphan: + = MSM Crash Dump Format = diff --git a/Documentation/interconnect/interconnect.rst
[PATCH v2] KVM: PPC: Report single stepping capability
When calling the KVM_SET_GUEST_DEBUG ioctl, userspace might request
the next instruction to be single stepped via the
KVM_GUESTDBG_SINGLESTEP control bit of the kvm_guest_debug structure.
We currently don't have support for guest single stepping implemented
in Book3S HV.
This patch adds the KVM_CAP_PPC_GUEST_DEBUG_SSTEP capability in order
to inform userspace about the state of single stepping support.
Signed-off-by: Fabiano Rosas
---
v1 -> v2:
- add capability description to Documentation/virtual/kvm/api.txt
Documentation/virtual/kvm/api.txt | 3 +++
arch/powerpc/kvm/powerpc.c| 5 +
include/uapi/linux/kvm.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index ba6c42c576dd..a77643bfa917 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2969,6 +2969,9 @@ can be determined by querying the
KVM_CAP_GUEST_DEBUG_HW_BPS and
KVM_CAP_GUEST_DEBUG_HW_WPS capabilities which return a positive number
indicating the number of supported registers.
+For ppc, the KVM_CAP_PPC_GUEST_DEBUG_SSTEP capability indicates whether
+the single-step debug event (KVM_GUESTDBG_SINGLESTEP) is supported.
+
When debug events exit the main run loop with the reason
KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
structure containing architecture specific debug information.
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 3393b166817a..fd7e7d55637e 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -538,6 +538,11 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_IMMEDIATE_EXIT:
r = 1;
break;
+ case KVM_CAP_PPC_GUEST_DEBUG_SSTEP:
+#ifdef CONFIG_BOOKE
+ r = 1;
+ break;
+#endif
case KVM_CAP_PPC_PAIRED_SINGLES:
case KVM_CAP_PPC_OSI:
case KVM_CAP_PPC_GET_PVINFO:
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 2fe12b40d503..cad9fcd90f39 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -993,6 +993,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_ARM_SVE 170
#define KVM_CAP_ARM_PTRAUTH_ADDRESS 171
#define KVM_CAP_ARM_PTRAUTH_GENERIC 172
+#define KVM_CAP_PPC_GUEST_DEBUG_SSTEP 173
#ifdef KVM_CAP_IRQ_ROUTING
--
2.20.1
Re: [PATCH][next] soc: fsl: fix spelling mistake "Firmaware" -> "Firmware"
On Tue, May 21, 2019 at 3:57 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message. Fix it.
>
> Signed-off-by: Colin Ian King
Applied. Thanks!
Regards,
Leo
> ---
> drivers/soc/fsl/dpaa2-console.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/fsl/dpaa2-console.c b/drivers/soc/fsl/dpaa2-console.c
> index 9168d8ddc932..27243f706f37 100644
> --- a/drivers/soc/fsl/dpaa2-console.c
> +++ b/drivers/soc/fsl/dpaa2-console.c
> @@ -73,7 +73,7 @@ static u64 get_mc_fw_base_address(void)
>
> mcfbaregs = ioremap(mc_base_addr.start, resource_size(_base_addr));
> if (!mcfbaregs) {
> - pr_err("could not map MC Firmaware Base registers\n");
> + pr_err("could not map MC Firmware Base registers\n");
> return 0;
> }
>
> --
> 2.20.1
>
[PATCH v3] mm: add account_locked_vm utility function
locked_vm accounting is done roughly the same way in five places, so
unify them in a helper.
Include the helper's caller in the debug print to distinguish between
callsites.
Error codes stay the same, so user-visible behavior does too. The one
exception is that the -EPERM case in tce_account_locked_vm is removed
because Alexey has never seen it triggered.
Signed-off-by: Daniel Jordan
Tested-by: Alexey Kardashevskiy
Cc: Alan Tull
Cc: Alex Williamson
Cc: Andrew Morton
Cc: Benjamin Herrenschmidt
Cc: Christoph Lameter
Cc: Christophe Leroy
Cc: Davidlohr Bueso
Cc: Ira Weiny
Cc: Jason Gunthorpe
Cc: Mark Rutland
Cc: Michael Ellerman
Cc: Moritz Fischer
Cc: Paul Mackerras
Cc: Steve Sistare
Cc: Wu Hao
Cc: linux...@kvack.org
Cc: k...@vger.kernel.org
Cc: kvm-...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-f...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
v3:
- uninline account_locked_vm (Andrew)
- fix doc comment (Ira)
- retain down_write_killable in vfio type1 (Alex)
- leave Alexey's T-b since the code is the same aside from uninlining
- sanity tested with vfio type1, sanity-built on ppc
arch/powerpc/kvm/book3s_64_vio.c | 44 ++--
arch/powerpc/mm/book3s64/iommu_api.c | 41 ++-
drivers/fpga/dfl-afu-dma-region.c| 53 ++--
drivers/vfio/vfio_iommu_spapr_tce.c | 54 ++--
drivers/vfio/vfio_iommu_type1.c | 17 +--
include/linux/mm.h | 4 ++
mm/util.c| 75
7 files changed, 98 insertions(+), 190 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 66270e07449a..768b645c7edf 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -56,43 +57,6 @@ static unsigned long kvmppc_stt_pages(unsigned long
tce_pages)
return tce_pages + ALIGN(stt_bytes, PAGE_SIZE) / PAGE_SIZE;
}
-static long kvmppc_account_memlimit(unsigned long stt_pages, bool inc)
-{
- long ret = 0;
-
- if (!current || !current->mm)
- return ret; /* process exited */
-
- down_write(>mm->mmap_sem);
-
- if (inc) {
- unsigned long locked, lock_limit;
-
- locked = current->mm->locked_vm + stt_pages;
- lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
- if (locked > lock_limit && !capable(CAP_IPC_LOCK))
- ret = -ENOMEM;
- else
- current->mm->locked_vm += stt_pages;
- } else {
- if (WARN_ON_ONCE(stt_pages > current->mm->locked_vm))
- stt_pages = current->mm->locked_vm;
-
- current->mm->locked_vm -= stt_pages;
- }
-
- pr_debug("[%d] RLIMIT_MEMLOCK KVM %c%ld %ld/%ld%s\n", current->pid,
- inc ? '+' : '-',
- stt_pages << PAGE_SHIFT,
- current->mm->locked_vm << PAGE_SHIFT,
- rlimit(RLIMIT_MEMLOCK),
- ret ? " - exceeded" : "");
-
- up_write(>mm->mmap_sem);
-
- return ret;
-}
-
static void kvm_spapr_tce_iommu_table_free(struct rcu_head *head)
{
struct kvmppc_spapr_tce_iommu_table *stit = container_of(head,
@@ -302,7 +266,7 @@ static int kvm_spapr_tce_release(struct inode *inode,
struct file *filp)
kvm_put_kvm(stt->kvm);
- kvmppc_account_memlimit(
+ account_locked_vm(current->mm,
kvmppc_stt_pages(kvmppc_tce_pages(stt->size)), false);
call_rcu(>rcu, release_spapr_tce_table);
@@ -327,7 +291,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
return -EINVAL;
npages = kvmppc_tce_pages(size);
- ret = kvmppc_account_memlimit(kvmppc_stt_pages(npages), true);
+ ret = account_locked_vm(current->mm, kvmppc_stt_pages(npages), true);
if (ret)
return ret;
@@ -373,7 +337,7 @@ long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
kfree(stt);
fail_acct:
- kvmppc_account_memlimit(kvmppc_stt_pages(npages), false);
+ account_locked_vm(current->mm, kvmppc_stt_pages(npages), false);
return ret;
}
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
b/arch/powerpc/mm/book3s64/iommu_api.c
index 5c521f3924a5..18d22eec0ebd 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -51,40 +52,6 @@ struct mm_iommu_table_group_mem_t {
u64 dev_hpa;/* Device memory base address */
};
-static long mm_iommu_adjust_locked_vm(struct mm_struct *mm,
- unsigned long npages, bool incr)
-{
- long ret = 0, locked, lock_limit;
-
- if (!npages)
- return 0;
-
-
Re: [PATCH v2] mm: add account_locked_vm utility function
On Tue, 28 May 2019 11:04:24 -0400
Daniel Jordan wrote:
> On Sat, May 25, 2019 at 02:51:18PM -0700, Andrew Morton wrote:
> > On Fri, 24 May 2019 13:50:45 -0400 Daniel Jordan
> > wrote:
> >
> > > locked_vm accounting is done roughly the same way in five places, so
> > > unify them in a helper. Standardize the debug prints, which vary
> > > slightly, but include the helper's caller to disambiguate between
> > > callsites.
> > >
> > > Error codes stay the same, so user-visible behavior does too. The one
> > > exception is that the -EPERM case in tce_account_locked_vm is removed
> > > because Alexey has never seen it triggered.
> > >
> > > ...
> > >
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -1564,6 +1564,25 @@ long get_user_pages_unlocked(unsigned long start,
> > > unsigned long nr_pages,
> > > int get_user_pages_fast(unsigned long start, int nr_pages,
> > > unsigned int gup_flags, struct page **pages);
> > >
> > > +int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool
> > > inc,
> > > + struct task_struct *task, bool bypass_rlim);
> > > +
> > > +static inline int account_locked_vm(struct mm_struct *mm, unsigned long
> > > pages,
> > > + bool inc)
> > > +{
> > > + int ret;
> > > +
> > > + if (pages == 0 || !mm)
> > > + return 0;
> > > +
> > > + down_write(>mmap_sem);
> > > + ret = __account_locked_vm(mm, pages, inc, current,
> > > + capable(CAP_IPC_LOCK));
> > > + up_write(>mmap_sem);
> > > +
> > > + return ret;
> > > +}
> >
> > That's quite a mouthful for an inlined function. How about uninlining
> > the whole thing and fiddling drivers/vfio/vfio_iommu_type1.c to suit.
> > I wonder why it does down_write_killable and whether it really needs
> > to...
>
> Sure, I can uninline it. vfio changelogs don't show a particular reason for
> _killable[1]. Maybe Alex has something to add. Otherwise I'll respin without
> it since the simplification seems worth removing _killable.
>
> [1] 0cfef2b7410b ("vfio/type1: Remove locked page accounting workqueue")
A userspace vfio driver maps DMA via an ioctl through this path, so I
believe I used killable here just to be friendly that it could be
interrupted and we could fall out with an errno if it were stuck here.
No harm, no foul, the user's mapping is aborted and unwound. If we're
deadlocked or seriously contended on mmap_sem, maybe we're already in
trouble, but it seemed like a valid and low hanging use case for
killable. Thanks,
Alex
Re: [PATCH v2] mm: add account_locked_vm utility function
On Wed, May 29, 2019 at 11:05:48AM -0700, Ira Weiny wrote:
> On Fri, May 24, 2019 at 01:50:45PM -0400, Daniel Jordan wrote:
> > +static inline int account_locked_vm(struct mm_struct *mm, unsigned long
> > pages,
> > + bool inc)
> > +{
> > + int ret;
> > +
> > + if (pages == 0 || !mm)
> > + return 0;
> > +
> > + down_write(>mmap_sem);
> > + ret = __account_locked_vm(mm, pages, inc, current,
> > + capable(CAP_IPC_LOCK));
> > + up_write(>mmap_sem);
> > +
> > + return ret;
> > +}
> > +
...snip...
> > +/**
> > + * __account_locked_vm - account locked pages to an mm's locked_vm
> > + * @mm: mm to account against, may be NULL
>
> This kernel doc is wrong. You dereference mm straight away...
...snip...
> > +
> > + locked_vm = mm->locked_vm;
>
> here...
>
> Perhaps the comment was meant to document account_locked_vm()?
Yes, the comment got out of sync when I moved the !mm check outside
__account_locked_vm. Thanks for catching, will fix.
Re: [PATCH v2] mm: add account_locked_vm utility function
On Fri, May 24, 2019 at 01:50:45PM -0400, Daniel Jordan wrote:
[snip]
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0e8834ac32b7..72c1034d2ec7 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1564,6 +1564,25 @@ long get_user_pages_unlocked(unsigned long start,
> unsigned long nr_pages,
> int get_user_pages_fast(unsigned long start, int nr_pages,
> unsigned int gup_flags, struct page **pages);
>
> +int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
> + struct task_struct *task, bool bypass_rlim);
> +
> +static inline int account_locked_vm(struct mm_struct *mm, unsigned long
> pages,
> + bool inc)
> +{
> + int ret;
> +
> + if (pages == 0 || !mm)
> + return 0;
> +
> + down_write(>mmap_sem);
> + ret = __account_locked_vm(mm, pages, inc, current,
> + capable(CAP_IPC_LOCK));
> + up_write(>mmap_sem);
> +
> + return ret;
> +}
> +
> /* Container for pinned pfns / pages */
> struct frame_vector {
> unsigned int nr_allocated; /* Number of frames we have space for */
> diff --git a/mm/util.c b/mm/util.c
> index e2e4f8c3fa12..bd3bdf16a084 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -346,6 +347,51 @@ int __weak get_user_pages_fast(unsigned long start,
> }
> EXPORT_SYMBOL_GPL(get_user_pages_fast);
>
> +/**
> + * __account_locked_vm - account locked pages to an mm's locked_vm
> + * @mm: mm to account against, may be NULL
This kernel doc is wrong. You dereference mm straight away...
> + * @pages: number of pages to account
> + * @inc: %true if @pages should be considered positive, %false if not
> + * @task:task used to check RLIMIT_MEMLOCK
> + * @bypass_rlim: %true if checking RLIMIT_MEMLOCK should be skipped
> + *
> + * Assumes @task and @mm are valid (i.e. at least one reference on each), and
> + * that mmap_sem is held as writer.
> + *
> + * Return:
> + * * 0 on success
> + * * 0 if @mm is NULL (can happen for example if the task is exiting)
> + * * -ENOMEM if RLIMIT_MEMLOCK would be exceeded.
> + */
> +int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
> + struct task_struct *task, bool bypass_rlim)
> +{
> + unsigned long locked_vm, limit;
> + int ret = 0;
> +
> + locked_vm = mm->locked_vm;
here...
Perhaps the comment was meant to document account_locked_vm()? Or should the
parameter checks be moved here?
Ira
> + if (inc) {
> + if (!bypass_rlim) {
> + limit = task_rlimit(task, RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> + if (locked_vm + pages > limit)
> + ret = -ENOMEM;
> + }
> + if (!ret)
> + mm->locked_vm = locked_vm + pages;
> + } else {
> + WARN_ON_ONCE(pages > locked_vm);
> + mm->locked_vm = locked_vm - pages;
> + }
> +
> + pr_debug("%s: [%d] caller %ps %c%lu %lu/%lu%s\n", __func__, task->pid,
> + (void *)_RET_IP_, (inc) ? '+' : '-', pages << PAGE_SHIFT,
> + locked_vm << PAGE_SHIFT, task_rlimit(task, RLIMIT_MEMLOCK),
> + ret ? " - exceeded" : "");
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(__account_locked_vm);
>
> +
> unsigned long vm_mmap_pgoff(struct file *file, unsigned long addr,
> unsigned long len, unsigned long prot,
> unsigned long flag, unsigned long pgoff)
>
> base-commit: a188339ca5a396acc588e5851ed7e19f66b0ebd9
> --
> 2.21.0
>
Re: kmemleak: 1157 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
On Tue, May 28, 2019 at 09:14:12PM +0200, Mathieu Malaterre wrote:
> On Tue, May 28, 2019 at 7:21 AM Michael Ellerman wrote:
> > Mathieu Malaterre writes:
> > > Is there a way to dump more context (somewhere in of tree
> > > flattening?). I cannot make sense of the following:
> >
> > Hmm. Not that I know of.
> >
> > Those don't look related to OF flattening/unflattening. That's just
> > sysfs setup based on the unflattened device tree.
> >
> > The allocations are happening in safe_name() AFAICS.
> >
> > int __of_add_property_sysfs(struct device_node *np, struct property *pp)
> > {
> > ...
> > pp->attr.attr.name = safe_name(>kobj, pp->name);
> >
> > And the free is in __of_sysfs_remove_bin_file():
> >
> > void __of_sysfs_remove_bin_file(struct device_node *np, struct property
> > *prop)
> > {
> > if (!IS_ENABLED(CONFIG_SYSFS))
> > return;
> >
> > sysfs_remove_bin_file(>kobj, >attr);
> > kfree(prop->attr.attr.name);
> >
>
> Right. That helped a lot !
>
> > There is this check which could be failing leading to us not calling the
> > free at all:
> >
> > void __of_remove_property_sysfs(struct device_node *np, struct property
> > *prop)
> > {
> > /* at early boot, bail here and defer setup to of_init() */
> > if (of_kset && of_node_is_attached(np))
> > __of_sysfs_remove_bin_file(np, prop);
> > }
> >
> >
> > So maybe stick a printk() in there to see if you're hitting that
> > condition, eg something like:
> >
> > if (of_kset && of_node_is_attached(np))
> > __of_sysfs_remove_bin_file(np, prop);
> > else
> > printk("%s: leaking prop %s on node %pOF\n", __func__,
> > prop->attr.attr.name, np);
> >
>
> If I understand correctly those are false positive. I was first
> starting to consider using something like kmemleak_not_leak, but I
> remember that I have been using kmemleak for a couple of years now.
> Those reports starting to show up only recently.
>
> Catalin, do you have an idea why on a non-SMP machine kmemleak reports
> leaks from:
>
> [...]
> void __init of_core_init(void)
> {
> [...]
> for_each_of_allnodes(np)
> __of_attach_node_sysfs(np);
It's likely that they are false positives but usually, rather than just
adding a kmemleak_not_leak(), it's better to figure out why kmemleak
reports them. The strings allocated above through kstrdup() can't be
tracked starting with the root objects. I think for the of stuff, this
should be the of_root pointer.
Is it only with non-SMP that this happens? I can't reproduce it on arm64
to be able to dig further.
Even better if you could bisect to the commit that's causing this.
--
Catalin
Re: [PATCH] powerpc/mm: Move some of the boot time info print to generic file
"Aneesh Kumar K.V" a écrit :
With radix translation enabled we find in dmesg
hash-mmu: ppc64_pft_size= 0x0
hash-mmu: kernel vmalloc start = 0xc008
hash-mmu: kernel IO start= 0xc00a
hash-mmu: kernel vmemmap start = 0xc00c
This is because these pr_info calls are in hash_utils.c which has
#define pr_fmt(fmt) "hash-mmu: " fmt
The information printed in generic and hence move that to generic file
Some similarities with Nick's patch
https://patchwork.ozlabs.org/patch/1100245/ ?
Christophe
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/kernel/setup-common.c| 4
arch/powerpc/mm/book3s64/hash_utils.c | 5 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index aad9f5df6ab6..a73a91f2c21f 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -810,6 +810,10 @@ static __init void print_system_info(void)
pr_info("mmu_features = 0x%08x\n", cur_cpu_spec->mmu_features);
#ifdef CONFIG_PPC64
pr_info("firmware_features = 0x%016lx\n", powerpc_firmware_features);
+ pr_info("ppc64_pft_size= 0x%llx\n", ppc64_pft_size);
+ pr_info("kernel vmalloc start = 0x%lx\n", KERN_VIRT_START);
+ pr_info("kernel IO start= 0x%lx\n", KERN_IO_START);
+ pr_info("kernel vmemmap start = 0x%lx\n", (unsigned long)vmemmap);
#endif
print_system_hash_info();
diff --git a/arch/powerpc/mm/book3s64/hash_utils.c
b/arch/powerpc/mm/book3s64/hash_utils.c
index 919a861a8ec0..2f677914bfd2 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -1950,11 +1950,6 @@ machine_device_initcall(pseries, hash64_debugfs);
void __init print_system_hash_info(void)
{
- pr_info("ppc64_pft_size= 0x%llx\n", ppc64_pft_size);
-
if (htab_hash_mask)
pr_info("htab_hash_mask= 0x%lx\n", htab_hash_mask);
- pr_info("kernel vmalloc start = 0x%lx\n", KERN_VIRT_START);
- pr_info("kernel IO start= 0x%lx\n", KERN_IO_START);
- pr_info("kernel vmemmap start = 0x%lx\n", (unsigned long)vmemmap);
}
--
2.21.0
Re: [PATCH v3 3/3] powerpc/pseries: Allow user-specified PCI resource alignment after init
On Mon, May 27, 2019 at 11:03:13PM -0500, Shawn Anastasio wrote:
> On pseries, custom PCI resource alignment specified with the commandline
> argument pci=resource_alignment is disabled due to PCI resources being
> managed by the firmware. However, in the case of PCI hotplug the
> resources are managed by the kernel, so custom alignments should be
> honored in these cases. This is done by only honoring custom
> alignments after initial PCI initialization is done, to ensure that
> all devices managed by the firmware are excluded.
>
> Without this ability, sub-page BARs sometimes get mapped in between
> page boundaries for hotplugged devices and are therefore unusable
> with the VFIO framework. This change allows users to request
> page alignment for devices they wish to access via VFIO using
> the pci=resource_alignment commandline argument.
>
> In the future, this could be extended to provide page-aligned
> resources by default for hotplugged devices, similar to what is
> done on powernv by commit 382746376993 ("powerpc/powernv: Override
> pcibios_default_alignment() to force PCI devices to be page aligned")
>
> Signed-off-by: Shawn Anastasio
> ---
> arch/powerpc/include/asm/machdep.h | 3 +++
> arch/powerpc/kernel/pci-common.c | 9 +
> arch/powerpc/platforms/pseries/setup.c | 22 ++
> 3 files changed, 34 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/machdep.h
> b/arch/powerpc/include/asm/machdep.h
> index 2fbfaa9176ed..46eb62c0954e 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -179,6 +179,9 @@ struct machdep_calls {
>
> resource_size_t (*pcibios_default_alignment)(void);
>
> + /* Called when determining PCI resource alignment */
> + int (*pcibios_ignore_alignment_request)(void);
> +
> #ifdef CONFIG_PCI_IOV
> void (*pcibios_fixup_sriov)(struct pci_dev *pdev);
> resource_size_t (*pcibios_iov_resource_alignment)(struct pci_dev *, int
> resno);
> diff --git a/arch/powerpc/kernel/pci-common.c
> b/arch/powerpc/kernel/pci-common.c
> index ff4b7539cbdf..8e0d73b4c188 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -238,6 +238,15 @@ resource_size_t pcibios_default_alignment(void)
> return 0;
> }
>
> +int pcibios_ignore_alignment_request(void)
> +{
> + if (ppc_md.pcibios_ignore_alignment_request)
> + return ppc_md.pcibios_ignore_alignment_request();
> +
> + /* Fall back to default method of checking PCI_PROBE_ONLY */
> + return pci_has_flag(PCI_PROBE_ONLY);
> +}
> +
> #ifdef CONFIG_PCI_IOV
> resource_size_t pcibios_iov_resource_alignment(struct pci_dev *pdev, int
> resno)
> {
> diff --git a/arch/powerpc/platforms/pseries/setup.c
> b/arch/powerpc/platforms/pseries/setup.c
> index e4f0dfd4ae33..07f03be02afe 100644
> --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -82,6 +82,8 @@ EXPORT_SYMBOL(CMO_PageSize);
>
> int fwnmi_active; /* TRUE if an FWNMI handler is present */
>
> +static int initial_pci_init_done; /* TRUE if initial pcibios init has
> completed */
> +
> static void pSeries_show_cpuinfo(struct seq_file *m)
> {
> struct device_node *root;
> @@ -749,6 +751,23 @@ static resource_size_t
> pseries_pci_iov_resource_alignment(struct pci_dev *pdev,
> }
> #endif
>
> +static void pseries_after_init(void)
> +{
> + initial_pci_init_done = 1;
> +}
> +
> +static int pseries_ignore_alignment_request(void)
> +{
> + if (initial_pci_init_done)
> + /*
> + * Allow custom alignments after init for things
> + * like PCI hotplugging.
> + */
> + return 0;
Hmm, if there's any way to avoid this sort of early/late flag, that
would be nicer.
> +
> + return pci_has_flag(PCI_PROBE_ONLY);
> +}
> +
> static void __init pSeries_setup_arch(void)
> {
> set_arch_panic_timeout(10, ARCH_PANIC_TIMEOUT);
> @@ -797,6 +816,9 @@ static void __init pSeries_setup_arch(void)
> }
>
> ppc_md.pcibios_root_bridge_prepare = pseries_root_bridge_prepare;
> + ppc_md.pcibios_after_init = pseries_after_init;
> + ppc_md.pcibios_ignore_alignment_request =
> + pseries_ignore_alignment_request;
> }
>
> static void pseries_panic(char *str)
> --
> 2.20.1
>
Re: [PATCH v3 1/3] PCI: Introduce pcibios_ignore_alignment_request
On Tue, May 28, 2019 at 03:36:34PM +1000, Oliver wrote:
> On Tue, May 28, 2019 at 2:03 PM Shawn Anastasio wrote:
> >
> > Introduce a new pcibios function pcibios_ignore_alignment_request
> > which allows the PCI core to defer to platform-specific code to
> > determine whether or not to ignore alignment requests for PCI resources.
> >
> > The existing behavior is to simply ignore alignment requests when
> > PCI_PROBE_ONLY is set. This is behavior is maintained by the
> > default implementation of pcibios_ignore_alignment_request.
> >
> > Signed-off-by: Shawn Anastasio
> > ---
> > drivers/pci/pci.c | 9 +++--
> > include/linux/pci.h | 1 +
> > 2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 8abc843b1615..8207a09085d1 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -5882,6 +5882,11 @@ resource_size_t __weak
> > pcibios_default_alignment(void)
> > return 0;
> > }
> >
> > +int __weak pcibios_ignore_alignment_request(void)
> > +{
> > + return pci_has_flag(PCI_PROBE_ONLY);
> > +}
> > +
> > #define RESOURCE_ALIGNMENT_PARAM_SIZE COMMAND_LINE_SIZE
> > static char resource_alignment_param[RESOURCE_ALIGNMENT_PARAM_SIZE] = {0};
> > static DEFINE_SPINLOCK(resource_alignment_lock);
> > @@ -5906,9 +5911,9 @@ static resource_size_t
> > pci_specified_resource_alignment(struct pci_dev *dev,
> > p = resource_alignment_param;
> > if (!*p && !align)
> > goto out;
> > - if (pci_has_flag(PCI_PROBE_ONLY)) {
> > + if (pcibios_ignore_alignment_request()) {
> > align = 0;
> > - pr_info_once("PCI: Ignoring requested alignments
> > (PCI_PROBE_ONLY)\n");
> > + pr_info_once("PCI: Ignoring requested alignments\n");
> > goto out;
> > }
>
> I think the logic here is questionable to begin with. If the user has
> explicitly requested re-aligning a resource via the command line then
> we should probably do it even if PCI_PROBE_ONLY is set. When it breaks
> they get to keep the pieces.
I agree. I don't like PCI_PROBE_ONLY in the first place. It's a
sledgehammer approach that doesn't tell us which resource assignments
need to be preserved or why. I'd rather use IORESOURCE_PCI_FIXED and
set it for the BARs where there's actually some sort of
hypervisor/firmware/OS dependency.
If there's a way to avoid another pciobios_*() weak function, that
would also be better.
Bjorn
Re: [PATCH] powerpc/configs: Rename foo_basic_defconfig to foo_base.config
Masahiro Yamada writes: > On Tue, May 28, 2019 at 9:10 PM Christoph Hellwig wrote: >> >> On Tue, May 28, 2019 at 06:16:14PM +1000, Michael Ellerman wrote: >> > We have several "defconfigs" that are not actually full defconfigs >> > they are just a base set of options which are then merged with other >> > fragments to produce a working defconfig. > > The default values from Kconfig files are used > where CONFIG options are not specified by the defconfig. > > So, I think corenet_basic_defconfig is a full defconfig > even if it contains a single CONFIG option. That's technically true, but it's not a full defconfig in the sense that it doesn't define a meaningful set of options for building for a specific machine. In fact if you build it you get a .config that doesn't include the one option it defines, CONFIG_CORENET_GENERIC=y. > Since the difference between "*_defconfig" and "*.config" > is ambiguous in some cases, it depends on the intended usage. I'm pretty sure all the existing foo.config files are fragments that are intended to be merged with an existing .config or other fragments. ie: These are fragments: arch/arm/configs/dram_0x.config arch/arm/configs/dram_0xc000.config arch/arm/configs/dram_0xd000.config These are all fragments: arch/powerpc/configs/be.config arch/powerpc/configs/book3s_32.config arch/powerpc/configs/altivec.config arch/powerpc/configs/85xx-hw.config arch/powerpc/configs/guest.config arch/powerpc/configs/85xx-smp.config arch/powerpc/configs/85xx-64bit.config arch/powerpc/configs/dpaa.config arch/powerpc/configs/85xx-32bit.config arch/powerpc/configs/fsl-emb-nonhw.config arch/powerpc/configs/86xx-smp.config arch/powerpc/configs/le.config arch/powerpc/configs/86xx-hw.config Pretty sure these all are, they're used in gen_generic_defconfigs in arch/mips/Makefile: arch/mips/configs/generic/board-xilfpga.config arch/mips/configs/generic/board-ocelot.config arch/mips/configs/generic/board-ni169445.config arch/mips/configs/generic/32r6.config arch/mips/configs/generic/64r1.config arch/mips/configs/generic/32r1.config arch/mips/configs/generic/64r6.config arch/mips/configs/generic/eb.config arch/mips/configs/generic/micro32r2.config arch/mips/configs/generic/32r2.config arch/mips/configs/generic/board-boston.config arch/mips/configs/generic/el.config arch/mips/configs/generic/board-ranchu.config arch/mips/configs/generic/64r2.config arch/mips/configs/generic/board-sead-3.config These are also both fragments: arch/x86/configs/tiny.config arch/x86/configs/xen.config >> > The most obvious example is corenet_basic_defconfig which only >> > contains one symbol CONFIG_CORENET_GENERIC=y. But there is also >> > mpc85xx_base_defconfig which doesn't actually enable CONFIG_PPC_85xx. >> > >> > To avoid confusion, rename these config fragments to "foo_base.config" >> > to make it clearer that they are not full defconfigs. >> >> Adding linux-kbuild, maybe we can make the handling of these fragments >> generic and actually document it.. > > I do not know how it should be documented. Me either. cheers
[PATCH] powerpc/64s: Fix misleading SPR and timebase information
pr_info shows SPR and timebase as a decimal value with a '0x'
prefix, which is somewhat misleading.
Fix it to print hexadecimal, as was intended.
Fixes: 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
Cc: Michael Ellerman
Cc: Nicholas Piggin
Signed-off-by: Shaokun Zhang
---
arch/powerpc/platforms/powernv/idle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index c9133f7908ca..77f2e0a4ee37 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -1159,10 +1159,10 @@ static void __init pnv_power9_idle_init(void)
pnv_deepest_stop_psscr_mask);
}
- pr_info("cpuidle-powernv: First stop level that may lose SPRs =
0x%lld\n",
+ pr_info("cpuidle-powernv: First stop level that may lose SPRs =
0x%llx\n",
pnv_first_spr_loss_level);
- pr_info("cpuidle-powernv: First stop level that may lose timebase =
0x%lld\n",
+ pr_info("cpuidle-powernv: First stop level that may lose timebase =
0x%llx\n",
pnv_first_tb_loss_level);
}
--
2.7.4
Re: [PATCH v3 1/3] powerpc: Fix vDSO clock_getres()
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: a7f290dad32ee [PATCH] powerpc: Merge vdso's and add vdso support
to 32 bits kernel.
The bot has tested the following trees: v5.1.4, v5.0.18, v4.19.45, v4.14.121,
v4.9.178, v4.4.180, v3.18.140.
v5.1.4: Build OK!
v5.0.18: Build OK!
v4.19.45: Build OK!
v4.14.121: Failed to apply! Possible dependencies:
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
v4.9.178: Failed to apply! Possible dependencies:
4546561551106 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
5d451a87e5ebb ("powerpc/64: Retrieve number of L1 cache sets from
device-tree")
7c5b06cadf274 ("KVM: PPC: Book3S HV: Adapt TLB invalidations to work on
POWER9")
83677f551e0a6 ("KVM: PPC: Book3S HV: Adjust host/guest context switch for
POWER9")
902e06eb86cd6 ("powerpc/32: Change the stack protector canary value per
task")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
bd067f83b0840 ("powerpc/64: Fix naming of cache block vs. cache line")
e2827fe5c1566 ("powerpc/64: Clean up ppc64_caches using a struct per cache")
e9cf1e085647b ("KVM: PPC: Book3S HV: Add new POWER9 guest-accessible SPRs")
f4c51f841d2ac ("KVM: PPC: Book3S HV: Modify guest entry/exit paths to
handle radix guests")
v4.4.180: Failed to apply! Possible dependencies:
153086644fd1f ("powerpc/ftrace: Add support for -mprofile-kernel ftrace
ABI")
3eb5d5888dc68 ("powerpc: Add ppc_strict_facility_enable boot option")
4546561551106 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
579e633e764e6 ("powerpc: create flush_all_to_thread()")
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
70fe3d980f5f1 ("powerpc: Restore FPU/VEC/VSX if previously used")
85baa095497f3 ("powerpc/livepatch: Add live patching support on ppc64le")
902e06eb86cd6 ("powerpc/32: Change the stack protector canary value per
task")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
bf76f73c5f655 ("powerpc: enable UBSAN support")
c208505900b23 ("powerpc: create giveup_all()")
d1e1cf2e38def ("powerpc: clean up asm/switch_to.h")
dc4fbba11e466 ("powerpc: Create disable_kernel_{fp,altivec,vsx,spe}()")
f17c4e01e906c ("powerpc/module: Mark module stubs with a magic value")
v3.18.140: Failed to apply! Possible dependencies:
10239733ee861 ("powerpc: Remove bootmem allocator")
2449acc5348b9 ("powerpc/kernel: Enable seccomp filter")
4546561551106 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
49e4e15619cd7 ("tile: support CONTEXT_TRACKING and thus NOHZ_FULL")
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
73569d87e2cc5 ("MIPS: OCTEON: Enable little endian kernel.")
817820b0226a1 ("powerpc/iommu: Support "hybrid" iommu/direct DMA ops for
coherent_mask < dma_mask")
83fe27ea53116 ("rcu: Make SRCU optional by using CONFIG_SRCU")
85baa095497f3 ("powerpc/livepatch: Add live patching support on ppc64le")
b01aec9b2c7d3 ("EDAC: Cleanup atomic_scrub mess")
b30e759072c18 ("powerpc/mm: Switch to generic RCU get_user_pages_fast")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
bf76f73c5f655 ("powerpc: enable UBSAN support")
c54b2bf1b5e99 ("powerpc: Add ppc64 hard lockup detector support")
f30c59e921f12 ("mm: Update generic gup implementation to handle hugepage
directory")
f47436734dc89 ("tile: Use the more common pr_warn instead of pr_warning")
How should we proceed with this patch?
--
Thanks,
Sasha
Re: [PATCH v4 1/3] powerpc: Fix vDSO clock_getres()
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: a7f290dad32ee [PATCH] powerpc: Merge vdso's and add vdso support
to 32 bits kernel.
The bot has tested the following trees: v5.1.4, v5.0.18, v4.19.45, v4.14.121,
v4.9.178, v4.4.180, v3.18.140.
v5.1.4: Build OK!
v5.0.18: Build OK!
v4.19.45: Build OK!
v4.14.121: Failed to apply! Possible dependencies:
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
v4.9.178: Failed to apply! Possible dependencies:
4546561551106 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
5d451a87e5ebb ("powerpc/64: Retrieve number of L1 cache sets from
device-tree")
7c5b06cadf274 ("KVM: PPC: Book3S HV: Adapt TLB invalidations to work on
POWER9")
83677f551e0a6 ("KVM: PPC: Book3S HV: Adjust host/guest context switch for
POWER9")
902e06eb86cd6 ("powerpc/32: Change the stack protector canary value per
task")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
bd067f83b0840 ("powerpc/64: Fix naming of cache block vs. cache line")
e2827fe5c1566 ("powerpc/64: Clean up ppc64_caches using a struct per cache")
e9cf1e085647b ("KVM: PPC: Book3S HV: Add new POWER9 guest-accessible SPRs")
f4c51f841d2ac ("KVM: PPC: Book3S HV: Modify guest entry/exit paths to
handle radix guests")
v4.4.180: Failed to apply! Possible dependencies:
153086644fd1f ("powerpc/ftrace: Add support for -mprofile-kernel ftrace
ABI")
3eb5d5888dc68 ("powerpc: Add ppc_strict_facility_enable boot option")
4546561551106 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
579e633e764e6 ("powerpc: create flush_all_to_thread()")
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
70fe3d980f5f1 ("powerpc: Restore FPU/VEC/VSX if previously used")
85baa095497f3 ("powerpc/livepatch: Add live patching support on ppc64le")
902e06eb86cd6 ("powerpc/32: Change the stack protector canary value per
task")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
bf76f73c5f655 ("powerpc: enable UBSAN support")
c208505900b23 ("powerpc: create giveup_all()")
d1e1cf2e38def ("powerpc: clean up asm/switch_to.h")
dc4fbba11e466 ("powerpc: Create disable_kernel_{fp,altivec,vsx,spe}()")
f17c4e01e906c ("powerpc/module: Mark module stubs with a magic value")
v3.18.140: Failed to apply! Possible dependencies:
10239733ee861 ("powerpc: Remove bootmem allocator")
2449acc5348b9 ("powerpc/kernel: Enable seccomp filter")
4546561551106 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
49e4e15619cd7 ("tile: support CONTEXT_TRACKING and thus NOHZ_FULL")
5c929885f1bb4 ("powerpc/vdso64: Add support for
CLOCK_{REALTIME/MONOTONIC}_COARSE")
73569d87e2cc5 ("MIPS: OCTEON: Enable little endian kernel.")
817820b0226a1 ("powerpc/iommu: Support "hybrid" iommu/direct DMA ops for
coherent_mask < dma_mask")
83fe27ea53116 ("rcu: Make SRCU optional by using CONFIG_SRCU")
85baa095497f3 ("powerpc/livepatch: Add live patching support on ppc64le")
b01aec9b2c7d3 ("EDAC: Cleanup atomic_scrub mess")
b30e759072c18 ("powerpc/mm: Switch to generic RCU get_user_pages_fast")
b5b4453e7912f ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across
Y2038")
bf76f73c5f655 ("powerpc: enable UBSAN support")
c54b2bf1b5e99 ("powerpc: Add ppc64 hard lockup detector support")
f30c59e921f12 ("mm: Update generic gup implementation to handle hugepage
directory")
f47436734dc89 ("tile: Use the more common pr_warn instead of pr_warning")
How should we proceed with this patch?
--
Thanks,
Sasha
Re: [PATCH v4 2/2] powerpc: Fix compile issue with force DAWR
> +config PPC_DAWR
> + bool
> + default n
"default n" is the default default. No need to write this line.
> +++ b/arch/powerpc/kernel/dawr.c
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// DAWR infrastructure
> +//
> +// Copyright 2019, Michael Neuling, IBM Corporation.
Normal top of file header should be /* */, //-style comments are only
for the actual SPDX heder line.
> + /* Send error to user if they hypervisor won't allow us to write DAWR */
> + if ((!dawr_force_enable) &&
> + (firmware_has_feature(FW_FEATURE_LPAR)) &&
> + (set_dawr(_brk) != H_SUCCESS))
None of the three inner brace sets here are required, and the code
becomes much easier to read without them.
> + return -1;
What about returning a proper error code?
> +static int __init dawr_force_setup(void)
> +{
> + dawr_force_enable = false;
This variable already is initialized to alse by default, so this line
is not required.
> + if (PVR_VER(mfspr(SPRN_PVR)) == PVR_POWER9) {
> + /* Turn DAWR off by default, but allow admin to turn it on */
> + dawr_force_enable = false;
.. and neither is this one.
