LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH AUTOSEL 4.9 08/22] cpufreq/pasemi: fix use-after-free in pas_cpufreq_cpu_init()
From: Sasha Levin @ 2019-08-02 13:25 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, linux-pm, Viresh Kumar, Rafael J . Wysocki,
	linuxppc-dev, Wen Yang
In-Reply-To: <20190802132547.14517-1-sashal@kernel.org>

From: Wen Yang <wen.yang99@zte.com.cn>

[ Upstream commit e0a12445d1cb186d875410d093a00d215bec6a89 ]

The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.

Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/cpufreq/pasemi-cpufreq.c | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 58c933f483004..991b6a3062c4f 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -145,10 +145,18 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	int err = -ENODEV;
 
 	cpu = of_get_cpu_node(policy->cpu, NULL);
+	if (!cpu)
+		goto out;
 
+	max_freqp = of_get_property(cpu, "clock-frequency", NULL);
 	of_node_put(cpu);
-	if (!cpu)
+	if (!max_freqp) {
+		err = -EINVAL;
 		goto out;
+	}
+
+	/* we need the freq in kHz */
+	max_freq = *max_freqp / 1000;
 
 	dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
 	if (!dn)
@@ -185,16 +193,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	}
 
 	pr_debug("init cpufreq on CPU %d\n", policy->cpu);
-
-	max_freqp = of_get_property(cpu, "clock-frequency", NULL);
-	if (!max_freqp) {
-		err = -EINVAL;
-		goto out_unmap_sdcpwr;
-	}
-
-	/* we need the freq in kHz */
-	max_freq = *max_freqp / 1000;
-
 	pr_debug("max clock-frequency is at %u kHz\n", max_freq);
 	pr_debug("initializing frequency table\n");
 
@@ -212,9 +210,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
 	return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
 
-out_unmap_sdcpwr:
-	iounmap(sdcpwr_mapbase);
-
 out_unmap_sdcasr:
 	iounmap(sdcasr_mapbase);
 out:
-- 
2.20.1


^ permalink raw reply related
* [PATCH AUTOSEL 4.9 19/22] scsi: ibmvfc: fix WARN_ON during event pool release
From: Sasha Levin @ 2019-08-02 13:25 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, linux-scsi, Martin K . Petersen, Abdul Haleem,
	Tyrel Datwyler, linuxppc-dev
In-Reply-To: <20190802132547.14517-1-sashal@kernel.org>

From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>

[ Upstream commit 5578257ca0e21056821e6481bd534ba267b84e58 ]

While removing an ibmvfc client adapter a WARN_ON like the following
WARN_ON is seen in the kernel log:

WARNING: CPU: 6 PID: 5421 at ./include/linux/dma-mapping.h:541
ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc]
CPU: 6 PID: 5421 Comm: rmmod Tainted: G            E     4.17.0-rc1-next-20180419-autotest #1
NIP:  d00000000290328c LR: d00000000290325c CTR: c00000000036ee20
REGS: c000000288d1b7e0 TRAP: 0700   Tainted: G            E      (4.17.0-rc1-next-20180419-autotest)
MSR:  800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 44008828  XER: 20000000
CFAR: c00000000036e408 SOFTE: 1
GPR00: d00000000290325c c000000288d1ba60 d000000002917900 c000000289d75448
GPR04: 0000000000000071 c0000000ff870000 0000000018040000 0000000000000001
GPR08: 0000000000000000 c00000000156e838 0000000000000001 d00000000290c640
GPR12: c00000000036ee20 c00000001ec4dc00 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 00000100276901e0 0000000010020598
GPR20: 0000000010020550 0000000010020538 0000000010020578 00000000100205b0
GPR24: 0000000000000000 0000000000000000 0000000010020590 5deadbeef0000100
GPR28: 5deadbeef0000200 d000000002910b00 0000000000000071 c0000002822f87d8
NIP [d00000000290328c] ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc]
LR [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc]
Call Trace:
[c000000288d1ba60] [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc] (unreliable)
[c000000288d1baf0] [d000000002909390] ibmvfc_abort_task_set+0x7b0/0x8b0 [ibmvfc]
[c000000288d1bb70] [c0000000000d8c68] vio_bus_remove+0x68/0x100
[c000000288d1bbb0] [c0000000007da7c4] device_release_driver_internal+0x1f4/0x2d0
[c000000288d1bc00] [c0000000007da95c] driver_detach+0x7c/0x100
[c000000288d1bc40] [c0000000007d8af4] bus_remove_driver+0x84/0x140
[c000000288d1bcb0] [c0000000007db6ac] driver_unregister+0x4c/0xa0
[c000000288d1bd20] [c0000000000d6e7c] vio_unregister_driver+0x2c/0x50
[c000000288d1bd50] [d00000000290ba0c] cleanup_module+0x24/0x15e0 [ibmvfc]
[c000000288d1bd70] [c0000000001dadb0] sys_delete_module+0x220/0x2d0
[c000000288d1be30] [c00000000000b284] system_call+0x58/0x6c
Instruction dump:
e8410018 e87f0068 809f0078 e8bf0080 e8df0088 2fa30000 419e008c e9230200
2fa90000 419e0080 894d098a 794a07e0 <0b0a0000> e9290008 2fa90000 419e0028

This is tripped as a result of irqs being disabled during the call to
dma_free_coherent() by ibmvfc_free_event_pool(). At this point in the code path
we have quiesced the adapter and its overly paranoid anyways to be holding the
host lock.

Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 7e487c78279cb..54dea767dfde9 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -4883,8 +4883,8 @@ static int ibmvfc_remove(struct vio_dev *vdev)
 
 	spin_lock_irqsave(vhost->host->host_lock, flags);
 	ibmvfc_purge_requests(vhost, DID_ERROR);
-	ibmvfc_free_event_pool(vhost);
 	spin_unlock_irqrestore(vhost->host->host_lock, flags);
+	ibmvfc_free_event_pool(vhost);
 
 	ibmvfc_free_mem(vhost);
 	spin_lock(&ibmvfc_driver_lock);
-- 
2.20.1


^ permalink raw reply related
* [PATCH AUTOSEL 4.4 07/17] cpufreq/pasemi: fix use-after-free in pas_cpufreq_cpu_init()
From: Sasha Levin @ 2019-08-02 13:26 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, linux-pm, Viresh Kumar, Rafael J . Wysocki,
	linuxppc-dev, Wen Yang
In-Reply-To: <20190802132635.14885-1-sashal@kernel.org>

From: Wen Yang <wen.yang99@zte.com.cn>

[ Upstream commit e0a12445d1cb186d875410d093a00d215bec6a89 ]

The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.

Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/cpufreq/pasemi-cpufreq.c | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 58c933f483004..991b6a3062c4f 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -145,10 +145,18 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	int err = -ENODEV;
 
 	cpu = of_get_cpu_node(policy->cpu, NULL);
+	if (!cpu)
+		goto out;
 
+	max_freqp = of_get_property(cpu, "clock-frequency", NULL);
 	of_node_put(cpu);
-	if (!cpu)
+	if (!max_freqp) {
+		err = -EINVAL;
 		goto out;
+	}
+
+	/* we need the freq in kHz */
+	max_freq = *max_freqp / 1000;
 
 	dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
 	if (!dn)
@@ -185,16 +193,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	}
 
 	pr_debug("init cpufreq on CPU %d\n", policy->cpu);
-
-	max_freqp = of_get_property(cpu, "clock-frequency", NULL);
-	if (!max_freqp) {
-		err = -EINVAL;
-		goto out_unmap_sdcpwr;
-	}
-
-	/* we need the freq in kHz */
-	max_freq = *max_freqp / 1000;
-
 	pr_debug("max clock-frequency is at %u kHz\n", max_freq);
 	pr_debug("initializing frequency table\n");
 
@@ -212,9 +210,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
 
 	return cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
 
-out_unmap_sdcpwr:
-	iounmap(sdcpwr_mapbase);
-
 out_unmap_sdcasr:
 	iounmap(sdcasr_mapbase);
 out:
-- 
2.20.1


^ permalink raw reply related
* [PATCH AUTOSEL 4.4 15/17] scsi: ibmvfc: fix WARN_ON during event pool release
From: Sasha Levin @ 2019-08-02 13:26 UTC (permalink / raw)
  To: linux-kernel, stable
  Cc: Sasha Levin, linux-scsi, Martin K . Petersen, Abdul Haleem,
	Tyrel Datwyler, linuxppc-dev
In-Reply-To: <20190802132635.14885-1-sashal@kernel.org>

From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>

[ Upstream commit 5578257ca0e21056821e6481bd534ba267b84e58 ]

While removing an ibmvfc client adapter a WARN_ON like the following
WARN_ON is seen in the kernel log:

WARNING: CPU: 6 PID: 5421 at ./include/linux/dma-mapping.h:541
ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc]
CPU: 6 PID: 5421 Comm: rmmod Tainted: G            E     4.17.0-rc1-next-20180419-autotest #1
NIP:  d00000000290328c LR: d00000000290325c CTR: c00000000036ee20
REGS: c000000288d1b7e0 TRAP: 0700   Tainted: G            E      (4.17.0-rc1-next-20180419-autotest)
MSR:  800000010282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>  CR: 44008828  XER: 20000000
CFAR: c00000000036e408 SOFTE: 1
GPR00: d00000000290325c c000000288d1ba60 d000000002917900 c000000289d75448
GPR04: 0000000000000071 c0000000ff870000 0000000018040000 0000000000000001
GPR08: 0000000000000000 c00000000156e838 0000000000000001 d00000000290c640
GPR12: c00000000036ee20 c00000001ec4dc00 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 00000100276901e0 0000000010020598
GPR20: 0000000010020550 0000000010020538 0000000010020578 00000000100205b0
GPR24: 0000000000000000 0000000000000000 0000000010020590 5deadbeef0000100
GPR28: 5deadbeef0000200 d000000002910b00 0000000000000071 c0000002822f87d8
NIP [d00000000290328c] ibmvfc_free_event_pool+0x12c/0x1f0 [ibmvfc]
LR [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc]
Call Trace:
[c000000288d1ba60] [d00000000290325c] ibmvfc_free_event_pool+0xfc/0x1f0 [ibmvfc] (unreliable)
[c000000288d1baf0] [d000000002909390] ibmvfc_abort_task_set+0x7b0/0x8b0 [ibmvfc]
[c000000288d1bb70] [c0000000000d8c68] vio_bus_remove+0x68/0x100
[c000000288d1bbb0] [c0000000007da7c4] device_release_driver_internal+0x1f4/0x2d0
[c000000288d1bc00] [c0000000007da95c] driver_detach+0x7c/0x100
[c000000288d1bc40] [c0000000007d8af4] bus_remove_driver+0x84/0x140
[c000000288d1bcb0] [c0000000007db6ac] driver_unregister+0x4c/0xa0
[c000000288d1bd20] [c0000000000d6e7c] vio_unregister_driver+0x2c/0x50
[c000000288d1bd50] [d00000000290ba0c] cleanup_module+0x24/0x15e0 [ibmvfc]
[c000000288d1bd70] [c0000000001dadb0] sys_delete_module+0x220/0x2d0
[c000000288d1be30] [c00000000000b284] system_call+0x58/0x6c
Instruction dump:
e8410018 e87f0068 809f0078 e8bf0080 e8df0088 2fa30000 419e008c e9230200
2fa90000 419e0080 894d098a 794a07e0 <0b0a0000> e9290008 2fa90000 419e0028

This is tripped as a result of irqs being disabled during the call to
dma_free_coherent() by ibmvfc_free_event_pool(). At this point in the code path
we have quiesced the adapter and its overly paranoid anyways to be holding the
host lock.

Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 1f9f9e5af2072..0526a47e30a3f 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -4869,8 +4869,8 @@ static int ibmvfc_remove(struct vio_dev *vdev)
 
 	spin_lock_irqsave(vhost->host->host_lock, flags);
 	ibmvfc_purge_requests(vhost, DID_ERROR);
-	ibmvfc_free_event_pool(vhost);
 	spin_unlock_irqrestore(vhost->host->host_lock, flags);
+	ibmvfc_free_event_pool(vhost);
 
 	ibmvfc_free_mem(vhost);
 	spin_lock(&ibmvfc_driver_lock);
-- 
2.20.1


^ permalink raw reply related
* [PATCH v2 1/1] powerpc/pseries/hotplug-memory.c: Change rc variable to bool
From: Leonardo Bras @ 2019-08-02 13:39 UTC (permalink / raw)
  To: linuxppc-dev, linux-kernel
  Cc: Rob Herring, Pavel Tatashin, David Hildenbrand,
	Greg Kroah-Hartman, YueHaibing, Mahesh Salgaonkar, Paul Mackerras,
	Leonardo Bras, Nathan Fontenot, Oscar Salvador

Changes the return variable to bool (as the return value) and
avoids doing a ternary operation before returning.

Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com>
---
Changes in v2:
  - Restore previous and-ing logic on rc.

 arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 8e700390f3d6..c126b94d1943 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -338,7 +338,7 @@ static int pseries_remove_mem_node(struct device_node *np)
 static bool lmb_is_removable(struct drmem_lmb *lmb)
 {
 	int i, scns_per_block;
-	int rc = 1;
+	bool rc = true;
 	unsigned long pfn, block_sz;
 	u64 phys_addr;
 
@@ -363,11 +363,11 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
 		if (!pfn_present(pfn))
 			continue;
 
-		rc &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
+		rc = rc && is_mem_section_removable(pfn, PAGES_PER_SECTION);
 		phys_addr += MIN_MEMORY_BLOCK_SIZE;
 	}
 
-	return rc ? true : false;
+	return rc;
 }
 
 static int dlpar_add_lmb(struct drmem_lmb *);
-- 
2.20.1


^ permalink raw reply related
* Re: [PATCH v2 1/1] powerpc/pseries/hotplug-memory.c: Change rc variable to bool
From: David Hildenbrand @ 2019-08-02 13:45 UTC (permalink / raw)
  To: Leonardo Bras, linuxppc-dev, linux-kernel
  Cc: Pavel Tatashin, Rob Herring, YueHaibing, Mahesh Salgaonkar,
	Paul Mackerras, Greg Kroah-Hartman, Nathan Fontenot,
	Oscar Salvador
In-Reply-To: <20190802133914.30413-1-leonardo@linux.ibm.com>

On 02.08.19 15:39, Leonardo Bras wrote:
> Changes the return variable to bool (as the return value) and
> avoids doing a ternary operation before returning.
> 
> Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com>
> ---
> Changes in v2:
>   - Restore previous and-ing logic on rc.
> 
>  arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 8e700390f3d6..c126b94d1943 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -338,7 +338,7 @@ static int pseries_remove_mem_node(struct device_node *np)
>  static bool lmb_is_removable(struct drmem_lmb *lmb)
>  {
>  	int i, scns_per_block;
> -	int rc = 1;
> +	bool rc = true;
>  	unsigned long pfn, block_sz;
>  	u64 phys_addr;
>  
> @@ -363,11 +363,11 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
>  		if (!pfn_present(pfn))
>  			continue;
>  
> -		rc &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
> +		rc = rc && is_mem_section_removable(pfn, PAGES_PER_SECTION);
>  		phys_addr += MIN_MEMORY_BLOCK_SIZE;
>  	}
>  
> -	return rc ? true : false;
> +	return rc;
>  }
>  
>  static int dlpar_add_lmb(struct drmem_lmb *);
> 

Yeah, why not

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

^ permalink raw reply
* Re: [PATCH 1/1] pseries/hotplug-memory.c: Change rc variable to bool
From: Leonardo Bras @ 2019-08-02 13:48 UTC (permalink / raw)
  To: David Hildenbrand, linuxppc-dev, linux-kernel
  Cc: Rob Herring, Greg Kroah-Hartman, Rafael J. Wysocki, YueHaibing,
	Paul Mackerras, Mahesh Salgaonkar, Nathan Fontenot,
	Thomas Gleixner
In-Reply-To: <78612e21-de54-4bd2-c22f-1c67aed29b2e@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

On Fri, 2019-08-02 at 09:23 +0200, David Hildenbrand wrote:
>  subtle changes in a "Change rc variable to bool"
> patch should be avoided.

You are right.
If it was a valid change, I should give it a patch for itself.
I will keep that in mind next time.

Thanks for helping!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply
* Re: [PATCH v2 3/3] powerpc/spinlocks: Fix oops in shared-processor spinlocks
From: Christopher M Riedl @ 2019-08-02 15:12 UTC (permalink / raw)
  To: Michael Ellerman, linuxppc-dev; +Cc: ajd, bauerman
In-Reply-To: <877e7vlruk.fsf@concordia.ellerman.id.au>


> On August 2, 2019 at 6:38 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
> 
> 
> "Christopher M. Riedl" <cmr@informatik.wtf> writes:
> > diff --git a/arch/powerpc/include/asm/spinlock.h b/arch/powerpc/include/asm/spinlock.h
> > index 0a8270183770..6aed8a83b180 100644
> > --- a/arch/powerpc/include/asm/spinlock.h
> > +++ b/arch/powerpc/include/asm/spinlock.h
> > @@ -124,6 +122,22 @@ static inline bool is_shared_processor(void)
> >  #endif
> >  }
> >  
> > +static inline void spin_yield(arch_spinlock_t *lock)
> > +{
> > +	if (is_shared_processor())
> > +		splpar_spin_yield(lock);
> > +	else
> > +		barrier();
> > +}
> ...
> >  static inline void arch_spin_lock(arch_spinlock_t *lock)
> >  {
> >  	while (1) {
> > @@ -132,7 +146,7 @@ static inline void arch_spin_lock(arch_spinlock_t *lock)
> >  		do {
> >  			HMT_low();
> >  			if (is_shared_processor())
> > -				__spin_yield(lock);
> > +				spin_yield(lock);
> 
> This leaves us with a double test of is_shared_processor() doesn't it?

Yep, and that's no good. Hmm, executing the barrier() in the non-shared-processor
case probably hurts performance here?

^ permalink raw reply
* [PATCH v2 3/3] powerpc/pseries/mobility: use cond_resched when updating device tree
From: Nathan Lynch @ 2019-08-02 19:29 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20190802192926.19277-1-nathanl@linux.ibm.com>

After a partition migration, pseries_devicetree_update() processes
changes to the device tree communicated from the platform to
Linux. This is a relatively heavyweight operation, with multiple
device tree searches, memory allocations, and conversations with
partition firmware.

There's a few levels of nested loops which are bounded only by
decisions made by the platform, outside of Linux's control, and indeed
we have seen RCU stalls on large systems while executing this call
graph. Use cond_resched() in these loops so that the cpu is yielded
when needed.

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
 arch/powerpc/platforms/pseries/mobility.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index fe812bebdf5e..b571285f6c14 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -9,6 +9,7 @@
 #include <linux/cpu.h>
 #include <linux/kernel.h>
 #include <linux/kobject.h>
+#include <linux/sched.h>
 #include <linux/smp.h>
 #include <linux/stat.h>
 #include <linux/completion.h>
@@ -207,7 +208,11 @@ static int update_dt_node(__be32 phandle, s32 scope)
 
 				prop_data += vd;
 			}
+
+			cond_resched();
 		}
+
+		cond_resched();
 	} while (rtas_rc == 1);
 
 	of_node_put(dn);
@@ -310,8 +315,12 @@ int pseries_devicetree_update(s32 scope)
 					add_dt_node(phandle, drc_index);
 					break;
 				}
+
+				cond_resched();
 			}
 		}
+
+		cond_resched();
 	} while (rc == 1);
 
 	kfree(rtas_buf);
-- 
2.20.1


^ permalink raw reply related
* [PATCH v2 0/3] more migration vs CPU hotplug fixes etc
From: Nathan Lynch @ 2019-08-02 19:29 UTC (permalink / raw)
  To: linuxppc-dev

Despite recent fixes, userspace-initiated CPU hotplug still can
destructively race with the migration code's CPU state
manipulations. And parts of the LPM implementation have potentially
long-running code, especially on larger systems, that ties up the CPU
causing RCU stalls etc.

Changes since v1:
- Correct description of cpu hotplug vs LPM race.
- Add fix for long-running code in pseries_devicetree_update and friends

Nathan Lynch (3):
  powerpc/rtas: use device model APIs and serialization during LPM
  powerpc/rtas: allow rescheduling while changing cpu states
  powerpc/pseries/mobility: use cond_resched when updating device tree

 arch/powerpc/kernel/rtas.c                | 13 ++++++++++---
 arch/powerpc/platforms/pseries/mobility.c |  9 +++++++++
 2 files changed, 19 insertions(+), 3 deletions(-)

-- 
2.20.1


^ permalink raw reply
* [PATCH v2 2/3] powerpc/rtas: allow rescheduling while changing cpu states
From: Nathan Lynch @ 2019-08-02 19:29 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20190802192926.19277-1-nathanl@linux.ibm.com>

rtas_cpu_state_change_mask() potentially operates on scores of cpus,
so explicitly allow rescheduling in the loop body.

Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
 arch/powerpc/kernel/rtas.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 05824eb4323b..b7ca2fde68a9 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -16,6 +16,7 @@
 #include <linux/capability.h>
 #include <linux/delay.h>
 #include <linux/cpu.h>
+#include <linux/sched.h>
 #include <linux/smp.h>
 #include <linux/completion.h>
 #include <linux/cpumask.h>
@@ -898,6 +899,7 @@ static int rtas_cpu_state_change_mask(enum rtas_cpu_state state,
 				cpumask_clear_cpu(cpu, cpus);
 			}
 		}
+		cond_resched();
 	}
 
 	return ret;
-- 
2.20.1


^ permalink raw reply related
* [PATCH v2 1/3] powerpc/rtas: use device model APIs and serialization during LPM
From: Nathan Lynch @ 2019-08-02 19:29 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20190802192926.19277-1-nathanl@linux.ibm.com>

The LPAR migration implementation and userspace-initiated cpu hotplug
can interleave their executions like so:

1. Set cpu 7 offline via sysfs.

2. Begin a partition migration, whose implementation requires the OS
   to ensure all present cpus are online; cpu 7 is onlined:

     rtas_ibm_suspend_me -> rtas_online_cpus_mask -> cpu_up

   This sets cpu 7 online in all respects except for the cpu's
   corresponding struct device; dev->offline remains true.

3. Set cpu 7 online via sysfs. _cpu_up() determines that cpu 7 is
   already online and returns success. The driver core (device_online)
   sets dev->offline = false.

4. The migration completes and restores cpu 7 to offline state:

     rtas_ibm_suspend_me -> rtas_offline_cpus_mask -> cpu_down

This leaves cpu7 in a state where the driver core considers the cpu
device online, but in all other respects it is offline and
unused. Attempts to online the cpu via sysfs appear to succeed but the
driver core actually does not pass the request to the lower-level
cpuhp support code. This makes the cpu unusable until the cpu device
is manually set offline and then online again via sysfs.

Instead of directly calling cpu_up/cpu_down, the migration code should
use the higher-level device core APIs to maintain consistent state and
serialize operations.

Fixes: 120496ac2d2d ("powerpc: Bring all threads online prior to migration/hibernation")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
 arch/powerpc/kernel/rtas.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 5faf0a64c92b..05824eb4323b 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -871,15 +871,17 @@ static int rtas_cpu_state_change_mask(enum rtas_cpu_state state,
 		return 0;
 
 	for_each_cpu(cpu, cpus) {
+		struct device *dev = get_cpu_device(cpu);
+
 		switch (state) {
 		case DOWN:
-			cpuret = cpu_down(cpu);
+			cpuret = device_offline(dev);
 			break;
 		case UP:
-			cpuret = cpu_up(cpu);
+			cpuret = device_online(dev);
 			break;
 		}
-		if (cpuret) {
+		if (cpuret < 0) {
 			pr_debug("%s: cpu_%s for cpu#%d returned %d.\n",
 					__func__,
 					((state == UP) ? "up" : "down"),
@@ -968,6 +970,8 @@ int rtas_ibm_suspend_me(u64 handle)
 	data.token = rtas_token("ibm,suspend-me");
 	data.complete = &done;
 
+	lock_device_hotplug();
+
 	/* All present CPUs must be online */
 	cpumask_andnot(offline_mask, cpu_present_mask, cpu_online_mask);
 	cpuret = rtas_online_cpus_mask(offline_mask);
@@ -1006,6 +1010,7 @@ int rtas_ibm_suspend_me(u64 handle)
 				__func__);
 
 out:
+	unlock_device_hotplug();
 	free_cpumask_var(offline_mask);
 	return atomic_read(&data.error);
 }
-- 
2.20.1


^ permalink raw reply related
* Re: [PATCH] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-03  6:48 UTC (permalink / raw)
  To: Will Deacon
  Cc: Shawn Anastasio, linuxppc-dev, Russell King, linux-kernel, iommu,
	Catalin Marinas, Robin Murphy, Christoph Hellwig,
	linux-arm-kernel
In-Reply-To: <20190802103803.3qrbhqwxlasojsco@willie-the-truck>

On Fri, Aug 02, 2019 at 11:38:03AM +0100, Will Deacon wrote:
> 
> So this boils down to a terminology mismatch. The Arm architecture doesn't have
> anything called "write combine", so in Linux we instead provide what the Arm
> architecture calls "Normal non-cacheable" memory for pgprot_writecombine().
> Amongst other things, this memory type permits speculation, unaligned accesses
> and merging of writes. I found something in the architecture spec about
> non-cachable memory, but it's written in Armglish[1].
> 
> pgprot_noncached(), on the other hand, provides what the architecture calls
> Strongly Ordered or Device-nGnRnE memory. This is intended for mapping MMIO
> (i.e. PCI config space) and therefore forbids speculation, preserves access
> size, requires strict alignment and also forces write responses to come from
> the endpoint.
> 
> I think the naming mismatch is historical, but on arm64 we wanted to use the
> same names as arm32 so that any drivers using these things directly would get
> the same behaviour.

That all makes sense, but it totally needs a comment.  I'll try to draft
one based on this.  I've also looked at the arm32 code a bit more, and
it seems arm always (?) supported Normal non-cacheable attribute, but
Linux only optionally uses it for arm v6+ because of fears of drivers
missing barriers.  The other really weird things is that in arm32
pgprot_dmacoherent incudes the L_PTE_XN bit, which from my understanding
is the no-execture bit, but pgprot_writecombine does not.  This seems to
not very unintentional.  So minus that the whole DMA_ATTR_WRITE_COMBІNE
seems to be about flagging old arm specific drivers as having the proper
barriers in places and otherwise is a no-op.

Here is my tentative plan:

 - respin this patch with a small fix to handle the
   DMA_ATTR_NON_CONSISTENT (as in ignore it unless actually supported),
   but keep the name as-is to avoid churn.  This should allow 5.3
   inclusion and backports
 - remove DMA_ATTR_WRITE_COMBINE support from mips, probably also 5.3
   material.
 - move all architectures but arm over to just define
   pgprot_dmacoherent, including a comment with the above explanation
   for arm64.
 - make DMA_ATTR_WRITE_COMBINE a no-op and schedule it for removal,
   thus removing the last instances of arch_dma_mmap_pgprot

^ permalink raw reply
* Thank you for contacting us
From: stay @ 2019-08-03  9:11 UTC (permalink / raw)
  To: linuxppc-dev

Thank you for contacting us. Somebody will get back to you as soon as possible, usually within 48 hours. If you have any more questions please contact us direct.

Sarah and Richard Burdon
Lake Hawea Holiday Park
phone:03 443 1767
stay@haweaholidaypark.co.nz



^ permalink raw reply
* Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
From: Christoph Hellwig @ 2019-08-03 10:30 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, linux-m68k,
	Robin Murphy, x86, linux-kernel, iommu, linuxppc-dev,
	Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <s5hh870rn4t.wl-tiwai@suse.de>

On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> I wasn't careful enough to look at that change, sorry.
> 
> The code there tries to check whether dma_mmap_coherent() would always
> fail on some platforms.  Then the driver clears the mmap capability
> flag at the device open time and notifies user-space to fall back to
> the dumb read/write mode.
> 
> So I'm afraid that simply dropping the check would cause the behavior
> regression, e.g. on PARISC.
> 
> Is there any simple way to test whether dma_mmap_coherent() would work
> or not in general on the target platform?  It's not necessarily in an
> ifdef at all.

This isn't really a platform, but a per-device question.  I can add a
"bool dma_can_mmap(struct device *dev)" helper to check that.  But how
do I get at a suitable struct device in hw_support_mmap()?

^ permalink raw reply
* Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
From: Takashi Iwai @ 2019-08-03 11:22 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, linux-m68k,
	Robin Murphy, x86, linux-kernel, iommu, linuxppc-dev,
	linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190803103024.GA32624@lst.de>

On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
> 
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> > 
> > The code there tries to check whether dma_mmap_coherent() would always
> > fail on some platforms.  Then the driver clears the mmap capability
> > flag at the device open time and notifies user-space to fall back to
> > the dumb read/write mode.
> > 
> > So I'm afraid that simply dropping the check would cause the behavior
> > regression, e.g. on PARISC.
> > 
> > Is there any simple way to test whether dma_mmap_coherent() would work
> > or not in general on the target platform?  It's not necessarily in an
> > ifdef at all.
> 
> This isn't really a platform, but a per-device question.  I can add a
> "bool dma_can_mmap(struct device *dev)" helper to check that.

Yes, this would fit perfect.

> But how
> do I get at a suitable struct device in hw_support_mmap()?

substream->dma_buffer.dev.dev can be that, which is used in the mmap
helper side, snd_pcm_lib_default_mmap().


Thanks!

Takashi

^ permalink raw reply
* [RFC PATCH v3] powerpc/xmon: Restrict when kernel is locked down
From: Christopher M. Riedl @ 2019-08-03 19:00 UTC (permalink / raw)
  To: linuxppc-dev, kernel-hardening; +Cc: Andrew Donnellan, mjg59, dja

Xmon should be either fully or partially disabled depending on the
kernel lockdown state.

Put xmon into read-only mode for lockdown=integrity and completely
disable xmon when lockdown=confidentiality. Xmon checks the lockdown
state and takes appropriate action:

 (1) during xmon_setup to prevent early xmon'ing

 (2) when triggered via sysrq

 (3) when toggled via debugfs

 (4) when triggered via a previously enabled breakpoint

The following lockdown state transitions are handled:

 (1) lockdown=none -> lockdown=integrity
     set xmon read-only mode

 (2) lockdown=none -> lockdown=confidentiality
     clear all breakpoints, set xmon read-only mode,
     prevent re-entry into xmon

 (3) lockdown=integrity -> lockdown=confidentiality
     clear all breakpoints, set xmon read-only mode,
     prevent re-entry into xmon

Suggested-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Christopher M. Riedl <cmr@informatik.wtf>
---
Changes since v1:
 - Rebased onto v36 of https://patchwork.kernel.org/cover/11049461/
   (based on: f632a8170a6b667ee4e3f552087588f0fe13c4bb)
 - Do not clear existing breakpoints when transitioning from
   lockdown=none to lockdown=integrity
 - Remove line continuation and dangling quote (confuses checkpatch.pl)
   from the xmon command help/usage string

 arch/powerpc/xmon/xmon.c     | 59 ++++++++++++++++++++++++++++++++++--
 include/linux/security.h     |  2 ++
 security/lockdown/lockdown.c |  2 ++
 3 files changed, 60 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index d0620d762a5a..1a5e43d664ca 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -25,6 +25,7 @@
 #include <linux/nmi.h>
 #include <linux/ctype.h>
 #include <linux/highmem.h>
+#include <linux/security.h>
 
 #include <asm/debugfs.h>
 #include <asm/ptrace.h>
@@ -187,6 +188,9 @@ static void dump_tlb_44x(void);
 static void dump_tlb_book3e(void);
 #endif
 
+static void clear_all_bpt(void);
+static void xmon_init(int);
+
 #ifdef CONFIG_PPC64
 #define REG		"%.16lx"
 #else
@@ -283,10 +287,41 @@ Commands:\n\
 "  U	show uptime information\n"
 "  ?	help\n"
 "  # n	limit output to n lines per page (for dp, dpa, dl)\n"
-"  zr	reboot\n\
-  zh	halt\n"
+"  zr	reboot\n"
+"  zh	halt\n"
 ;
 
+#ifdef CONFIG_SECURITY
+static bool xmon_is_locked_down(void)
+{
+	static bool lockdown;
+
+	if (!lockdown) {
+		lockdown = !!security_locked_down(LOCKDOWN_XMON_RW);
+		if (lockdown) {
+			printf("xmon: Disabled due to kernel lockdown\n");
+			xmon_is_ro = true;
+			xmon_on = 0;
+			xmon_init(0);
+			clear_all_bpt();
+		}
+	}
+
+	if (!xmon_is_ro) {
+		xmon_is_ro = !!security_locked_down(LOCKDOWN_XMON_WR);
+		if (xmon_is_ro)
+			printf("xmon: Read-only due to kernel lockdown\n");
+	}
+
+	return lockdown;
+}
+#else /* CONFIG_SECURITY */
+static inline bool xmon_is_locked_down(void)
+{
+	return false;
+}
+#endif
+
 static struct pt_regs *xmon_regs;
 
 static inline void sync(void)
@@ -704,6 +739,9 @@ static int xmon_bpt(struct pt_regs *regs)
 	struct bpt *bp;
 	unsigned long offset;
 
+	if (xmon_is_locked_down())
+		return 0;
+
 	if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
 		return 0;
 
@@ -735,6 +773,9 @@ static int xmon_sstep(struct pt_regs *regs)
 
 static int xmon_break_match(struct pt_regs *regs)
 {
+	if (xmon_is_locked_down())
+		return 0;
+
 	if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
 		return 0;
 	if (dabr.enabled == 0)
@@ -745,6 +786,9 @@ static int xmon_break_match(struct pt_regs *regs)
 
 static int xmon_iabr_match(struct pt_regs *regs)
 {
+	if (xmon_is_locked_down())
+		return 0;
+
 	if ((regs->msr & (MSR_IR|MSR_PR|MSR_64BIT)) != (MSR_IR|MSR_64BIT))
 		return 0;
 	if (iabr == NULL)
@@ -3741,6 +3785,9 @@ static void xmon_init(int enable)
 #ifdef CONFIG_MAGIC_SYSRQ
 static void sysrq_handle_xmon(int key)
 {
+	if (xmon_is_locked_down())
+		return;
+
 	/* ensure xmon is enabled */
 	xmon_init(1);
 	debugger(get_irq_regs());
@@ -3762,7 +3809,6 @@ static int __init setup_xmon_sysrq(void)
 device_initcall(setup_xmon_sysrq);
 #endif /* CONFIG_MAGIC_SYSRQ */
 
-#ifdef CONFIG_DEBUG_FS
 static void clear_all_bpt(void)
 {
 	int i;
@@ -3784,8 +3830,12 @@ static void clear_all_bpt(void)
 	printf("xmon: All breakpoints cleared\n");
 }
 
+#ifdef CONFIG_DEBUG_FS
 static int xmon_dbgfs_set(void *data, u64 val)
 {
+	if (xmon_is_locked_down())
+		return 0;
+
 	xmon_on = !!val;
 	xmon_init(xmon_on);
 
@@ -3844,6 +3894,9 @@ early_param("xmon", early_parse_xmon);
 
 void __init xmon_setup(void)
 {
+	if (xmon_is_locked_down())
+		return;
+
 	if (xmon_on)
 		xmon_init(1);
 	if (xmon_early)
diff --git a/include/linux/security.h b/include/linux/security.h
index 807dc0d24982..379b74b5d545 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -116,12 +116,14 @@ enum lockdown_reason {
 	LOCKDOWN_MODULE_PARAMETERS,
 	LOCKDOWN_MMIOTRACE,
 	LOCKDOWN_DEBUGFS,
+	LOCKDOWN_XMON_WR,
 	LOCKDOWN_INTEGRITY_MAX,
 	LOCKDOWN_KCORE,
 	LOCKDOWN_KPROBES,
 	LOCKDOWN_BPF_READ,
 	LOCKDOWN_PERF,
 	LOCKDOWN_TRACEFS,
+	LOCKDOWN_XMON_RW,
 	LOCKDOWN_CONFIDENTIALITY_MAX,
 };
 
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index f6c74cf6a798..79d1799a62ca 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -31,12 +31,14 @@ static char *lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
 	[LOCKDOWN_MODULE_PARAMETERS] = "unsafe module parameters",
 	[LOCKDOWN_MMIOTRACE] = "unsafe mmio",
 	[LOCKDOWN_DEBUGFS] = "debugfs access",
+	[LOCKDOWN_XMON_WR] = "xmon write access",
 	[LOCKDOWN_INTEGRITY_MAX] = "integrity",
 	[LOCKDOWN_KCORE] = "/proc/kcore access",
 	[LOCKDOWN_KPROBES] = "use of kprobes",
 	[LOCKDOWN_BPF_READ] = "use of bpf to read kernel RAM",
 	[LOCKDOWN_PERF] = "unsafe use of perf",
 	[LOCKDOWN_TRACEFS] = "use of tracefs",
+	[LOCKDOWN_XMON_RW] = "xmon read and write access",
 	[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
 };
 
-- 
2.22.0


^ permalink raw reply related
* Re: [RFC PATCH v2] powerpc/xmon: restrict when kernel is locked down
From: Christopher M Riedl @ 2019-08-03 19:04 UTC (permalink / raw)
  To: Daniel Axtens, Andrew Donnellan, linuxppc-dev, kernel-hardening; +Cc: mjg59
In-Reply-To: <87ef29gwa1.fsf@dja-thinkpad.axtens.net>

> On July 29, 2019 at 2:00 AM Daniel Axtens <dja@axtens.net> wrote:
> 
> Would you be able to send a v2 with these changes? (that is, not purging
> breakpoints when entering integrity mode)
> 

Just sent out a v3 with that change among a few others and a rebase.

Thanks,
Chris R.

^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-3 tag
From: Michael Ellerman @ 2019-08-04 11:49 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: sfr, santosh, aneesh.kumar, linux-kernel, linuxppc-dev, christian

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Linus,

Please pull some more powerpc fixes for 5.3:

The following changes since commit 609488bc979f99f805f34e9a32c1e3b71179d10b:

  Linux 5.3-rc2 (2019-07-28 12:47:02 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.3-3

for you to fetch changes up to d7e23b887f67178c4f840781be7a6aa6aeb52ab1:

  powerpc/kasan: fix early boot failure on PPC32 (2019-07-31 22:02:52 +1000)

- ------------------------------------------------------------------
powerpc fixes for 5.3 #3

Wire up the new clone3 syscall.

A fix for the PAPR SCM nvdimm driver, to fix a crash when firmware gives us a
device that's attached to a non-online NUMA node.

A fix for a boot failure on 32-bit with KASAN enabled.

Three fixes for implicit fall through warnings, some of which are errors for us
due to -Werror.

Thanks to:
  Aneesh Kumar K.V, Christophe Leroy, Kees Cook, Santosh Sivaraj, Stephen
  Rothwell.

- ------------------------------------------------------------------
Aneesh Kumar K.V (1):
      powerpc/nvdimm: Pick nearby online node if the device node is not online

Christophe Leroy (1):
      powerpc/kasan: fix early boot failure on PPC32

Michael Ellerman (2):
      powerpc: Wire up clone3 syscall
      powerpc/spe: Mark expected switch fall-throughs

Santosh Sivaraj (1):
      powerpc/kvm: Fall through switch case explicitly

Stephen Rothwell (1):
      drivers/macintosh/smu.c: Mark expected switch fall-through


 arch/powerpc/include/asm/unistd.h         |  1 +
 arch/powerpc/kernel/align.c               |  4 ++++
 arch/powerpc/kernel/entry_32.S            |  8 ++++++++
 arch/powerpc/kernel/entry_64.S            |  5 +++++
 arch/powerpc/kernel/syscalls/syscall.tbl  |  2 +-
 arch/powerpc/kvm/book3s_32_mmu.c          |  1 +
 arch/powerpc/mm/kasan/kasan_init_32.c     |  7 +++++--
 arch/powerpc/platforms/pseries/papr_scm.c | 29 +++++++++++++++++++++++++++--
 drivers/macintosh/smu.c                   |  1 +
 9 files changed, 53 insertions(+), 5 deletions(-)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl1GxcEACgkQUevqPMjh
pYDXVQ//Wg2vXgrCxc9Gk65Sspu1oLwgBOl8zsM7u/McOXBUeBC3o8pUMwh1N5MB
IbSffD6UlK3GNEcIfVGWb7OeaqEZjRL3uUtJMUJQIEkK8MnflE60H9n5jrKMApV7
zRTQfU2mL/wObXeASgdUIhCgiTlkaZJcse9ATIKOtDpYy2Xm7ahAyImfqet39Ea0
9OetR48YuZzEPzzuESFAFslawFLRLIYSpviBYeFO85+uuoULu2ylpts1c5XyOH38
bUfRyvEJvvPEmYgmmqnw3R6NqPQwCc6+VkEbIZ6kv67vfXQbrTG7uN/HOjm9ksFf
/2Q/hXl2ZfwM+SO2lhhDPWFkJuWyBrutoxumkVE1dlD8B5D71qWpCxlPOVbwF8tB
S5b+8pq1mrrwQmsPoYa46WtvuEbuKI0vZqqx27ZSzGE40FwQcEbJhDRTEmsXuh+D
n3395ddQclj5zfsxU/gk+bmdT03F8crT+OPZxYKYZlUDgk/+6rYvghm7EC0dK3h7
/5sIpl5oWVMEUqpjdfeWPbdnF8b5M2xHFJXBUTJcHNA2gZzarUp0KuSPxBt2suu6
NhXZ19Ja2vaHwI2NZvKCdd543PzP6NG8GHRrMyiMnGWC88Fm4r5/FBd2g80ShQ2p
WuXj98tye3dbPTPzbkQM24g4WNsrQcc7uhKveRwnimWEgcPATPI=
=nPN5
-----END PGP SIGNATURE-----

^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-3 tag
From: Linus Torvalds @ 2019-08-04 17:34 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Stephen Rothwell, santosh, Aneesh Kumar K.V, lkml, linuxppc-dev,
	Christian Brauner
In-Reply-To: <87a7cpw3on.fsf@concordia.ellerman.id.au>

On Sun, Aug 4, 2019 at 4:49 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Please pull some more powerpc fixes for 5.3:

Hmm. This was caught by the gmail spam-filter for some reason. I don't
see anything particularly different from your normal pull requests, so
don't ask me why.

The fact that you have no email authentication (dkim/spf/whatever) for
your email address tends to make gmail more suspicious of emails, so
it's probably then some random other pattern that just happened to
trigger it.

I do check my spam fairly religiously, so it's not like it's usually a
problem - and I obviously marked it as ham to hopefully teach gmail
the error of its ways. So this is just a heads up.

But if you do have the possibility of enabling DKIM or similar on
ellerman.id.au, then that is always a good thing, of course. I hate
spam, even even if DKIM and friends certainly aren't perfect, they are
better than nothing.

                Linus

^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.3-3 tag
From: pr-tracker-bot @ 2019-08-04 17:35 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: sfr, santosh, aneesh.kumar, linux-kernel, Linus Torvalds,
	linuxppc-dev, christian
In-Reply-To: <87a7cpw3on.fsf@concordia.ellerman.id.au>

The pull request you sent on Sun, 04 Aug 2019 21:49:44 +1000:

> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.3-3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4b6f23161b4e888e72671e377c32eabe9a8e62fc

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply
* Re: [PATCH] powerpc: Remove inaccessible CMDLINE default
From: Chris Packham @ 2019-08-04 20:32 UTC (permalink / raw)
  To: christophe.leroy@c-s.fr, paulus@samba.org, mpe@ellerman.id.au,
	benh@kernel.crashing.org
  Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <43422528-c2fc-a2c8-49e6-0f6b2c791648@c-s.fr>

On Fri, 2019-08-02 at 07:18 +0200, Christophe Leroy wrote:
> 
> Le 02/08/2019 à 07:02, Chris Packham a écrit :
> > 
> > Since commit cbe46bd4f510 ("powerpc: remove CONFIG_CMDLINE #ifdef
> > mess")
> > CONFIG_CMDLINE has always had a value regardless of
> > CONNIG_CMDLINE_BOOL.
> s/CONNIG/CONFIG/
> 
> > 
> > 
> > For example:
> > 
> >   $ make ARCH=powerpc defconfig
> >   $ cat .config
> >   # CONFIG_CMDLINE_BOOL is not set
> >   CONFIG_CMDLINE=""
> > 
> > When enabling CONNIG_CMDLINE_BOOL this value is kept making the
> > 'default
> > "..." if CONNIG_CMDLINE_BOOL' ineffective.
> s/CONNIG/CONFIG/
> 

Will fix in v2.

> > 
> > 
> >   $ ./scripts/config --enable CONFIG_CMDLINE_BOOL
> >   $ cat .config
> >   CONFIG_CMDLINE_BOOL=y
> >   CONFIG_CMDLINE=""
> > 
> > Additionally all the in-tree powerpc defconfigs that set
> > CONFIG_CMDLINE_BOOL=y also set CONFIG_CMDLINE to something else.
> > For
> > these reasons remove the inaccessible default.
> > 
> > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> 
> > 
> > ---
> > This should be independent of http://patchwork.ozlabs.org/patch/114
> > 0811/ but
> > I've generated this patch on a stream that has it applied locally.
> > 
> >   arch/powerpc/Kconfig | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index d413fe1b4058..6fca6eba6aee 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -844,7 +844,6 @@ config CMDLINE_BOOL
> >   
> >   config CMDLINE
> >   	string "Initial kernel command string" if CMDLINE_BOOL
> > -	default "console=ttyS0,9600 console=tty0 root=/dev/sda2"
> > if CMDLINE_BOOL
> >   	default ""
> >   	help
> >   	  On some platforms, there is currently no way for the
> > boot loader to
> > 
> I think we could also get rid of CMDLINE_BOOL totally and use CMDLINE
> != 
> "" instead.

The only reason I can see to keep CMDLINE_BOOL is that it hides the
text input for CMDLINE which seems to be a pattern in Kconfig. Happy to
remove it if that's the consensus. 

I'll wait for the dust to settle on my other patch before sending a v2
of this one.

> 
> Christophe

^ permalink raw reply
* [Bug 204479] KASAN hit at modprobe zram
From: bugzilla-daemon @ 2019-08-05  0:34 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <bug-204479-206035@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=204479

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linuxppc-dev@lists.ozlabs.o
                   |                            |rg

-- 
You are receiving this mail because:
You are on the CC list for the bug.

^ permalink raw reply
* [Bug 204375] kernel 5.2.4 w. KASAN enabled fails to boot on a PowerMac G4 3,6 at very early stage
From: bugzilla-daemon @ 2019-08-05  0:42 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <bug-204375-206035@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=204375

--- Comment #14 from Erhard F. (erhard_f@mailbox.org) ---
With radeon.ko module removed the G4 DP continues and finishes booting with
KASAN. So this one seems fixed. Thanks!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply
* SMP lockup at boot on Freescale/NXP T2080 (powerpc 64)
From: Chris Packham @ 2019-08-05  2:06 UTC (permalink / raw)
  To: linuxppc-dev@lists.ozlabs.org; +Cc: linux-kernel@vger.kernel.org, Grant McEwan

Hi All,

I have a custom board that uses the Freescale/NXP T2080 SoC.

The board boots fine using v4.19.60 but when I use v5.1.21 it locks up
waiting for the other CPUs to come online (earlyprintk output below).
If I set maxcpus=0 then the system boots all the way through to
userland. The same thing happens with 5.3-rc2.

The defconfig I'm using is https://gist.github.com/cpackham/f24d0b426f3
de0eaaba17b82c3528a9d it was updated from the working v4.19.60
defconfig using make olddefconfig.

Does this ring any bells for anyone?

I haven't dug into the differences between the working an non-working
versions yet. I'll start looking now.

Booting...
MMU: Supported page sizes
         4 KB as direct
      2048 KB as direct & indirect
      4096 KB as direct
     16384 KB as direct
     65536 KB as direct
    262144 KB as direct
   1048576 KB as direct
MMU: Book3E HW tablewalk enabled
Linux version 5.1.21-at1+ (@chrisp-dl) (gcc version 4.9.3 (crosstool-NG 
crosstool-ng-1.22.0)) #24 SMP PREEMPT Mon Aug 5 01:42:00 UTC 2019
Found initrd at 0xc00000002f045000:0xc000000030000000
Using CoreNet Generic machine description
Found legacy serial port 0 for /soc@ffe000000/serial@11c500
  mem=ffe11c500, taddr=ffe11c500, irq=0, clk=300000000, speed=0
Found legacy serial port 1 for /soc@ffe000000/serial@11c600
  mem=ffe11c600, taddr=ffe11c600, irq=0, clk=300000000, speed=0
Found legacy serial port 2 for /soc@ffe000000/serial@11d500
  mem=ffe11d500, taddr=ffe11d500, irq=0, clk=300000000, speed=0
Found legacy serial port 3 for /soc@ffe000000/serial@11d600
  mem=ffe11d600, taddr=ffe11d600, irq=0, clk=300000000, speed=0
printk: bootconsole [udbg0] enabled
CPU maps initialized for 2 threads per core
 (thread shift is 1)
Allocated 1856 bytes for 8 pacas
-----------------------------------------------------
phys_mem_size     = 0x100000000
dcache_bsize      = 0x40
icache_bsize      = 0x40
cpu_features      = 0x00000003009003b6
  possible        = 0x00000003009003b6
  always          = 0x00000003008003b4
cpu_user_features = 0xdc008000 0x08000000
mmu_features      = 0x000a0010
firmware_features = 0x0000000000000000
-----------------------------------------------------
CoreNet Generic board
barrier-nospec: using isync; sync as speculation barrier
barrier-nospec: patched 412 locations
Top of RAM: 0x100000000, Total RAM: 0x100000000
Memory hole size: 0MB
Zone ranges:
  DMA      [mem 0x0000000000000000-0x000000007fffefff]
  Normal   [mem 0x000000007ffff000-0x00000000ffffffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000000000000-0x00000000ffffffff]
Initmem setup node 0 [mem 0x0000000000000000-0x00000000ffffffff]
On node 0 totalpages: 1048576
  DMA zone: 7168 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 524287 pages, LIFO batch:63
  Normal zone: 7169 pages used for memmap
  Normal zone: 524289 pages, LIFO batch:63
MMU: Allocated 2112 bytes of context maps for 255 contexts
percpu: Embedded 22 pages/cpu s49304 r0 d40808 u131072
pcpu-alloc: s49304 r0 d40808 u131072 alloc=1*1048576
pcpu-alloc: [0] 0 1 2 3 4 5 6 7 
Built 1 zonelists, mobility grouping on.  Total pages: 1034239
Kernel command line: console=ttyS0,115200 root=/dev/ram0
releasefile=linuxbox_ppc64_e6500mc-tb233.rel bootversion=6.2.7
loglevel=8 mtdoops.mtddev=errlog
mtdparts=fff800000.flash:4088M(user),8M(errlog)
earlyprintk=ttyS0,115200 real_init=
/bin/sh securitylevel=1 reladdr=0x1000000,1522523
printk: log_buf_len individual max cpu contribution: 4096 bytes
printk: log_buf_len total cpu_extra contributions: 28672 bytes
printk: log_buf_len min size: 16384 bytes
printk: log_buf_len: 65536 bytes
printk: early log buf free: 12412(75%)
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 3979284K/4194304K available (8704K kernel code, 1584K rwdata,
2496K rodata, 472K init, 299K bss, 215020K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
rcu: Preemptible hierarchical RCU implementation.
rcu:    RCU event tracing is enabled.
        Tasks RCU enabled.
rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
mpic: Setting up MPIC " OpenPIC  " version 1.2 at ffe040000, max 8 CPUs
mpic: ISU size: 512, shift: 9, mask: 1ff
mpic: Initializing for 512 sources
time_init: decrementer frequency = 37.500000 MHz
time_init: processor frequency   = 1500.000000 MHz
clocksource: timebase: mask: 0xffffffffffffffff max_cycles:
0x8a60dd6a9, max_idle_ns: 440795204056 ns
clocksource: timebase mult[1aaaaaab] shift[24] registered
clockevent: decrementer mult[999999a] shift[32] cpu[0]
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes)
e6500 family performance monitor hardware support registered
rcu: Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox