LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] powerpc/tm: Avoid machine crash on rt_sigreturn
From: Michael Neuling @ 2019-05-01  7:17 UTC (permalink / raw)
  To: Breno Leitao, linuxppc-dev; +Cc: gromero
In-Reply-To: <1547657264-28761-1-git-send-email-leitao@debian.org>

On Wed, 2019-01-16 at 14:47 -0200, Breno Leitao wrote:
> There is a kernel crash that happens if rt_sigreturn is called inside a
> transactional block.
> 
> This crash happens if the kernel hits an in-kernel page fault when
> accessing userspace memory, usually through copy_ckvsx_to_user(). A major
> page fault calls might_sleep() function, which can cause a task reschedule.
> A task reschedule (switch_to()) reclaim and recheckpoint the TM states,
> but, in the signal return path, the checkpointed memory was already
> reclaimed, thus the exception stack has MSR that points to MSR[TS]=0.
> 
> When the code returns from might_sleep() and a task reschedule happened,
> then this task is returned with the memory recheckpointed, and
> CPU MSR[TS] = suspended.
> 
> This means that there is a side effect at might_sleep() if it is called
> with CPU MSR[TS] = 0 and the task has regs->msr[TS] != 0.
> 
> This side effect can cause a TM bad thing, since at the exception entrance,
> the stack saves MSR[TS]=0, and this is what will be used at RFID, but,
> the processor has MSR[TS] = Suspended, and this transition will be invalid
> and a TM Bad thing will be raised, causing the following crash:
> 
> 	Unexpected TM Bad Thing exception at c00000000000e9ec (msr
> 0x8000000302a03031) tm_scratch=800000010280b033
> 	cpu 0xc: Vector: 700 (Program Check) at [c00000003ff1fd70]
> 	    pc: c00000000000e9ec: fast_exception_return+0x100/0x1bc
> 	    lr: c000000000032948: handle_rt_signal64+0xb8/0xaf0
> 	    sp: c0000004263ebc40
> 	   msr: 8000000302a03031
> 	  current = 0xc000000415050300
> 	  paca    = 0xc00000003ffc4080	 irqmask: 0x03	 irq_happened: 0x01
> 	    pid   = 25006, comm = sigfuz
> 	Linux version 5.0.0-rc1-00001-g3bd6e94bec12 (breno@debian) (gcc version
> 8.2.0 (Debian 8.2.0-3)) #899 SMP Mon Jan 7 11:30:07 EST 2019
> 	WARNING: exception is not recoverable, can't continue
> 	enter ? for help
> 	[c0000004263ebc40] c000000000032948 handle_rt_signal64+0xb8/0xaf0
> (unreliable)
> 	[c0000004263ebd30] c000000000022780 do_notify_resume+0x2f0/0x430
> 	[c0000004263ebe20] c00000000000e844 ret_from_except_lite+0x70/0x74
> 	--- Exception: c00 (System Call) at 00007fffbaac400c
> 	SP (7fffeca90f40) is in userspace
> 
> The solution for this problem is running the sigreturn code with
> regs->msr[TS] disabled, thus, avoiding hitting the side effect above. This
> does not seem to be a problem since regs->msr will be replaced by the
> ucontext value, so, it is being flushed already. In this case, it is
> flushed earlier.
> 
> Signed-off-by: Breno Leitao <leitao@debian.org>

Acked-by: Michael Neuling <mikey@neuling.org>

This still applies on powerpc/next so just acking rather than reposting

> ---
>  arch/powerpc/kernel/signal_64.c | 27 ++++++++++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
> index 6794466f6420..06c299ef6132 100644
> --- a/arch/powerpc/kernel/signal_64.c
> +++ b/arch/powerpc/kernel/signal_64.c
> @@ -565,7 +565,7 @@ static long restore_tm_sigcontexts(struct task_struct
> *tsk,
>  	preempt_disable();
>  
>  	/* pull in MSR TS bits from user context */
> -	regs->msr = (regs->msr & ~MSR_TS_MASK) | (msr & MSR_TS_MASK);
> +	regs->msr |= msr & MSR_TS_MASK;
>  
>  	/*
>  	 * Ensure that TM is enabled in regs->msr before we leave the signal
> @@ -745,6 +745,31 @@ SYSCALL_DEFINE0(rt_sigreturn)
>  	if (MSR_TM_SUSPENDED(mfmsr()))
>  		tm_reclaim_current(0);
>  
> +	/*
> +	 * Disable MSR[TS] bit also, so, if there is an exception in the
> +	 * code below (as a page fault in copy_ckvsx_to_user()), it does
> +	 * not recheckpoint this task if there was a context switch inside
> +	 * the exception.
> +	 *
> +	 * A major page fault can indirectly call schedule(). A reschedule
> +	 * process in the middle of an exception can have a side effect
> +	 * (Changing the CPU MSR[TS] state), since schedule() is called
> +	 * with the CPU MSR[TS] disable and returns with MSR[TS]=Suspended
> +	 * (switch_to() calls tm_recheckpoint() for the 'new' process). In
> +	 * this case, the process continues to be the same in the CPU, but
> +	 * the CPU state just changed.
> +	 *
> +	 * This can cause a TM Bad Thing, since the MSR in the stack will
> +	 * have the MSR[TS]=0, and this is what will be used to RFID.
> +	 *
> +	 * Clearing MSR[TS] state here will avoid a recheckpoint if there
> +	 * is any process reschedule in kernel space. The MSR[TS] state
> +	 * does not need to be saved also, since it will be replaced with
> +	 * the MSR[TS] that came from user context later, at
> +	 * restore_tm_sigcontexts.
> +	 */
> +	regs->msr &= ~MSR_TS_MASK;
> +
>  	if (__get_user(msr, &uc->uc_mcontext.gp_regs[PT_MSR]))
>  		goto badframe;
>  	if (MSR_TM_ACTIVE(msr)) {


^ permalink raw reply

* Re: [PATCH kernel v2 0/2] powerpc/ioda2: Another attempt to allow DMA masks between 32 and 59
From: Alexey Kardashevskiy @ 2019-05-01  7:28 UTC (permalink / raw)
  To: Alistair Popple; +Cc: Oliver O'Halloran, linuxppc-dev, David Gibson
In-Reply-To: <2637621.o3tU8Khc0e@townsend>



On 01/05/2019 16:09, Alistair Popple wrote:
> Hi Alexey,
> 
> Do we need a seperate patch to allow this to be used? Last time I tried 
> calling dma_set_mask(52) on powernv it returned an error and there doesn't 
> seem to be anything obvious to me in this series to change that behaviour, but 
> perhaps I missed something.


Right now (this could have changed with the Hellwig's patches) when
called with MASK(52), dma_iommu_dma_supported() will select the default
ops and allow any mask. The kernel won't be able to use the entire mask
(since the default window won't be that big) and eventually
dma_map_ops::alloc() will fail when the entire DMA window is used but
this may happen anyway. This patchset does not change this behaviour,
just moves the upper limit for DMA window further up.



https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/dma-iommu.c?h=v5.1-rc7#n117

int dma_iommu_dma_supported(struct device *dev, u64 mask)
{
	struct iommu_table *tbl = get_iommu_table_base(dev);

	if (!tbl) {
		dev_info(dev, "Warning: IOMMU dma not supported: mask 0x%08llx"
			", table unavailable\n", mask);
		return 0;
	}

	if (dev_is_pci(dev) && dma_iommu_bypass_supported(dev, mask)) {
		dev->archdata.iommu_bypass = true;
		dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
		return 1;
	}

	if (tbl->it_offset > (mask >> tbl->it_page_shift)) {
		dev_info(dev, "Warning: IOMMU offset too big for device mask\n");
		dev_info(dev, "mask: 0x%08llx, table offset: 0x%08lx\n",
				mask, tbl->it_offset << tbl->it_page_shift);
		return 0;
	}

	dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
	dev->archdata.iommu_bypass = false;
	return 1;
}


> 
> - Alistair
> 
> On Wednesday, 1 May 2019 3:28:20 PM AEST Alexey Kardashevskiy wrote:
>> This is an attempt to allow DMA masks between 32..59 which are not large
>> enough to use either a PHB3 bypass mode or a sketchy bypass. Depending
>> on the max order, up to 40 is usually available.
>>
>>
>> This is based on sha1
>> 37624b58542f Linus Torvalds "Linux 5.1-rc7".
>>
>> Please comment. Thanks.
>>
>>
>>
>> Alexey Kardashevskiy (2):
>>   powerpc/powernv/ioda2: Allocate TCE table levels on demand for default
>>     DMA window
>>   powerpc/powernv/ioda2: Create bigger default window with 64k IOMMU
>>     pages
>>
>>  arch/powerpc/include/asm/iommu.h              |  8 ++-
>>  arch/powerpc/platforms/powernv/pci.h          |  2 +-
>>  arch/powerpc/kernel/iommu.c                   | 58 +++++++++++++------
>>  arch/powerpc/platforms/powernv/pci-ioda-tce.c | 20 +++----
>>  arch/powerpc/platforms/powernv/pci-ioda.c     | 40 +++++++++++--
>>  5 files changed, 90 insertions(+), 38 deletions(-)
> 
> 

-- 
Alexey

^ permalink raw reply

* [PATCH v2 0/6] soc/fsl/qe: cleanups and new DT binding
From: Rasmus Villemoes @ 2019-05-01  9:29 UTC (permalink / raw)
  To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
  Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
	Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190430133615.25721-1-rasmus.villemoes@prevas.dk>

This small series consists of some small cleanups and simplifications
of the QUICC engine driver, and introduces a new DT binding that makes
it much easier to support other variants of the QUICC engine IP block
that appears in the wild: There's no reason to expect in general that
the number of valid SNUMs uniquely determines the set of such, so it's
better to simply let the device tree specify the values (and,
implicitly via the array length, also the count).

v2:
- Address comments from Christophe Leroy
- Add his Reviewed-by to 1/6 and 3/6
- Split DT binding update to separate patch as per
  Documentation/devicetree/bindings/submitting-patches.txt


Rasmus Villemoes (6):
  soc/fsl/qe: qe.c: drop useless static qualifier
  soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
  soc/fsl/qe: qe.c: introduce qe_get_device_node helper
  dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
  soc/fsl/qe: qe.c: support fsl,qe-snums property
  soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init

 .../devicetree/bindings/soc/fsl/cpm_qe/qe.txt |   8 +-
 drivers/soc/fsl/qe/qe.c                       | 164 +++++++-----------
 2 files changed, 72 insertions(+), 100 deletions(-)

-- 
2.20.1


^ permalink raw reply

* [PATCH v2 2/6] soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
From: Rasmus Villemoes @ 2019-05-01  9:29 UTC (permalink / raw)
  To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
  Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
	Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-1-rasmus.villemoes@prevas.dk>

The current array of struct qe_snum use 256*4 bytes for just keeping
track of the free/used state of each index, and the struct layout
means there's another 768 bytes of padding. If we just unzip that
structure, the array of snum values just use 256 bytes, while the
free/inuse state can be tracked in a 32 byte bitmap.

So this reduces the .data footprint by 1760 bytes. It also serves as
preparation for introducing another DT binding for specifying the snum
values.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 drivers/soc/fsl/qe/qe.c | 43 ++++++++++++-----------------------------
 1 file changed, 12 insertions(+), 31 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 855373deb746..303aa29cb27d 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -14,6 +14,7 @@
  * Free Software Foundation;  either version 2 of the  License, or (at your
  * option) any later version.
  */
+#include <linux/bitmap.h>
 #include <linux/errno.h>
 #include <linux/sched.h>
 #include <linux/kernel.h>
@@ -43,25 +44,14 @@ static DEFINE_SPINLOCK(qe_lock);
 DEFINE_SPINLOCK(cmxgcr_lock);
 EXPORT_SYMBOL(cmxgcr_lock);
 
-/* QE snum state */
-enum qe_snum_state {
-	QE_SNUM_STATE_USED,
-	QE_SNUM_STATE_FREE
-};
-
-/* QE snum */
-struct qe_snum {
-	u8 num;
-	enum qe_snum_state state;
-};
-
 /* We allocate this here because it is used almost exclusively for
  * the communication processor devices.
  */
 struct qe_immap __iomem *qe_immr;
 EXPORT_SYMBOL(qe_immr);
 
-static struct qe_snum snums[QE_NUM_OF_SNUM];	/* Dynamically allocated SNUMs */
+static u8 snums[QE_NUM_OF_SNUM];	/* Dynamically allocated SNUMs */
+static DECLARE_BITMAP(snum_state, QE_NUM_OF_SNUM);
 static unsigned int qe_num_of_snum;
 
 static phys_addr_t qebase = -1;
@@ -315,10 +305,8 @@ static void qe_snums_init(void)
 	else
 		snum_init = snum_init_46;
 
-	for (i = 0; i < qe_num_of_snum; i++) {
-		snums[i].num = snum_init[i];
-		snums[i].state = QE_SNUM_STATE_FREE;
-	}
+	bitmap_zero(snum_state, QE_NUM_OF_SNUM);
+	memcpy(snums, snum_init, qe_num_of_snum);
 }
 
 int qe_get_snum(void)
@@ -328,12 +316,10 @@ int qe_get_snum(void)
 	int i;
 
 	spin_lock_irqsave(&qe_lock, flags);
-	for (i = 0; i < qe_num_of_snum; i++) {
-		if (snums[i].state == QE_SNUM_STATE_FREE) {
-			snums[i].state = QE_SNUM_STATE_USED;
-			snum = snums[i].num;
-			break;
-		}
+	i = find_first_zero_bit(snum_state, qe_num_of_snum);
+	if (i < qe_num_of_snum) {
+		set_bit(i, snum_state);
+		snum = snums[i];
 	}
 	spin_unlock_irqrestore(&qe_lock, flags);
 
@@ -343,14 +329,9 @@ EXPORT_SYMBOL(qe_get_snum);
 
 void qe_put_snum(u8 snum)
 {
-	int i;
-
-	for (i = 0; i < qe_num_of_snum; i++) {
-		if (snums[i].num == snum) {
-			snums[i].state = QE_SNUM_STATE_FREE;
-			break;
-		}
-	}
+	const u8 *p = memchr(snums, snum, qe_num_of_snum);
+	if (p)
+		clear_bit(p - snums, snum_state);
 }
 EXPORT_SYMBOL(qe_put_snum);
 
-- 
2.20.1


^ permalink raw reply related

* [PATCH v2 3/6] soc/fsl/qe: qe.c: introduce qe_get_device_node helper
From: Rasmus Villemoes @ 2019-05-01  9:29 UTC (permalink / raw)
  To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
  Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
	Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-1-rasmus.villemoes@prevas.dk>

The 'try of_find_compatible_node(NULL, NULL, "fsl,qe"), fall back to
of_find_node_by_type(NULL, "qe")' pattern is repeated five
times. Factor it into a common helper.

Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 drivers/soc/fsl/qe/qe.c | 71 +++++++++++++++++------------------------
 1 file changed, 29 insertions(+), 42 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 303aa29cb27d..0fb8b59f61ad 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -56,6 +56,20 @@ static unsigned int qe_num_of_snum;
 
 static phys_addr_t qebase = -1;
 
+static struct device_node *qe_get_device_node(void)
+{
+	struct device_node *qe;
+
+	/*
+	 * Newer device trees have an "fsl,qe" compatible property for the QE
+	 * node, but we still need to support older device trees.
+	 */
+	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
+	if (qe)
+		return qe;
+	return of_find_node_by_type(NULL, "qe");
+}
+
 static phys_addr_t get_qe_base(void)
 {
 	struct device_node *qe;
@@ -65,12 +79,9 @@ static phys_addr_t get_qe_base(void)
 	if (qebase != -1)
 		return qebase;
 
-	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
-	if (!qe) {
-		qe = of_find_node_by_type(NULL, "qe");
-		if (!qe)
-			return qebase;
-	}
+	qe = qe_get_device_node();
+	if (!qe)
+		return qebase;
 
 	ret = of_address_to_resource(qe, 0, &res);
 	if (!ret)
@@ -164,12 +175,9 @@ unsigned int qe_get_brg_clk(void)
 	if (brg_clk)
 		return brg_clk;
 
-	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
-	if (!qe) {
-		qe = of_find_node_by_type(NULL, "qe");
-		if (!qe)
-			return brg_clk;
-	}
+	qe = qe_get_device_node();
+	if (!qe)
+		return brg_clk;
 
 	prop = of_get_property(qe, "brg-frequency", &size);
 	if (prop && size == sizeof(*prop))
@@ -557,16 +565,9 @@ struct qe_firmware_info *qe_get_firmware_info(void)
 
 	initialized = 1;
 
-	/*
-	 * Newer device trees have an "fsl,qe" compatible property for the QE
-	 * node, but we still need to support older device trees.
-	*/
-	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
-	if (!qe) {
-		qe = of_find_node_by_type(NULL, "qe");
-		if (!qe)
-			return NULL;
-	}
+	qe = qe_get_device_node();
+	if (!qe)
+		return NULL;
 
 	/* Find the 'firmware' child node */
 	fw = of_get_child_by_name(qe, "firmware");
@@ -612,16 +613,9 @@ unsigned int qe_get_num_of_risc(void)
 	unsigned int num_of_risc = 0;
 	const u32 *prop;
 
-	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
-	if (!qe) {
-		/* Older devices trees did not have an "fsl,qe"
-		 * compatible property, so we need to look for
-		 * the QE node by name.
-		 */
-		qe = of_find_node_by_type(NULL, "qe");
-		if (!qe)
-			return num_of_risc;
-	}
+	qe = qe_get_device_node();
+	if (!qe)
+		return num_of_risc;
 
 	prop = of_get_property(qe, "fsl,qe-num-riscs", &size);
 	if (prop && size == sizeof(*prop))
@@ -641,16 +635,9 @@ unsigned int qe_get_num_of_snums(void)
 	const u32 *prop;
 
 	num_of_snums = 28; /* The default number of snum for threads is 28 */
-	qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
-	if (!qe) {
-		/* Older devices trees did not have an "fsl,qe"
-		 * compatible property, so we need to look for
-		 * the QE node by name.
-		 */
-		qe = of_find_node_by_type(NULL, "qe");
-		if (!qe)
-			return num_of_snums;
-	}
+	qe = qe_get_device_node();
+	if (!qe)
+		return num_of_snums;
 
 	prop = of_get_property(qe, "fsl,qe-num-snums", &size);
 	if (prop && size == sizeof(*prop)) {
-- 
2.20.1


^ permalink raw reply related

* [PATCH v2 4/6] dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
From: Rasmus Villemoes @ 2019-05-01  9:29 UTC (permalink / raw)
  To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
  Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
	Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-1-rasmus.villemoes@prevas.dk>

Reading table 4-30, and its footnotes, of the QUICC Engine Block
Reference Manual shows that the set of snum _values_ is not
necessarily just a function of the _number_ of snums, as given in the
fsl,qe-num-snums property.

As an alternative, to make it easier to add support for other variants
of the QUICC engine IP, this introduces a new binding fsl,qe-snums,
which automatically encodes both the number of snums and the actual
values to use.

For example, for the MPC8309, one would specify the property as

               fsl,qe-snums = /bits/ 8 <
                       0x88 0x89 0x98 0x99 0xa8 0xa9 0xb8 0xb9
                       0xc8 0xc9 0xd8 0xd9 0xe8 0xe9>;

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
index d7afaff5faff..05f5f485562a 100644
--- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
+++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
@@ -18,7 +18,8 @@ Required properties:
 - reg : offset and length of the device registers.
 - bus-frequency : the clock frequency for QUICC Engine.
 - fsl,qe-num-riscs: define how many RISC engines the QE has.
-- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
+- fsl,qe-snums: This property has to be specified as '/bits/ 8' value,
+  defining the array of serial number (SNUM) values for the virtual
   threads.
 
 Optional properties:
@@ -34,6 +35,11 @@ Recommended properties
 - brg-frequency : the internal clock source frequency for baud-rate
   generators in Hz.
 
+Deprecated properties
+- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use
+  for the threads. Use fsl,qe-snums instead to not only specify the
+  number of snums, but also their values.
+
 Example:
      qe@e0100000 {
 	#address-cells = <1>;
-- 
2.20.1


^ permalink raw reply related

* [PATCH v2 5/6] soc/fsl/qe: qe.c: support fsl,qe-snums property
From: Rasmus Villemoes @ 2019-05-01  9:29 UTC (permalink / raw)
  To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
  Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
	Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-1-rasmus.villemoes@prevas.dk>

Add driver support for the newly introduced fsl,qe-snums property.

Conveniently, of_property_read_variable_u8_array does exactly what we
need: If the property fsl,qe-snums is found (and has an allowed size),
the array of values get copied to snums, and the return value is the
number of snums - we cannot assign directly to num_of_snums, since we
need to check whether the return value is negative.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 drivers/soc/fsl/qe/qe.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 0fb8b59f61ad..325d689cbf5c 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -283,7 +283,6 @@ EXPORT_SYMBOL(qe_clock_source);
  */
 static void qe_snums_init(void)
 {
-	int i;
 	static const u8 snum_init_76[] = {
 		0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
 		0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89,
@@ -304,7 +303,21 @@ static void qe_snums_init(void)
 		0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
 		0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
 	};
+	struct device_node *qe;
 	const u8 *snum_init;
+	int i;
+
+	bitmap_zero(snum_state, QE_NUM_OF_SNUM);
+	qe = qe_get_device_node();
+	if (qe) {
+		i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
+						       snums, 1, QE_NUM_OF_SNUM);
+		of_node_put(qe);
+		if (i > 0) {
+			qe_num_of_snum = i;
+			return;
+		}
+	}
 
 	qe_num_of_snum = qe_get_num_of_snums();
 
@@ -313,7 +326,6 @@ static void qe_snums_init(void)
 	else
 		snum_init = snum_init_46;
 
-	bitmap_zero(snum_state, QE_NUM_OF_SNUM);
 	memcpy(snums, snum_init, qe_num_of_snum);
 }
 
-- 
2.20.1


^ permalink raw reply related

* [PATCH v2 1/6] soc/fsl/qe: qe.c: drop useless static qualifier
From: Rasmus Villemoes @ 2019-05-01  9:29 UTC (permalink / raw)
  To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
  Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
	Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-1-rasmus.villemoes@prevas.dk>

The local variable snum_init has no reason to have static storage duration.

Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 drivers/soc/fsl/qe/qe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 612d9c551be5..855373deb746 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -306,7 +306,7 @@ static void qe_snums_init(void)
 		0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
 		0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
 	};
-	static const u8 *snum_init;
+	const u8 *snum_init;
 
 	qe_num_of_snum = qe_get_num_of_snums();
 
-- 
2.20.1


^ permalink raw reply related

* [PATCH v2 6/6] soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init
From: Rasmus Villemoes @ 2019-05-01  9:29 UTC (permalink / raw)
  To: devicetree@vger.kernel.org, Qiang Zhao, Li Yang
  Cc: Mark Rutland, linux-kernel@vger.kernel.org, Scott Wood,
	Rasmus Villemoes, Rob Herring, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-1-rasmus.villemoes@prevas.dk>

The comment "No QE ever has fewer than 28 SNUMs" is false; e.g. the
MPC8309 has 14. The code path returning -EINVAL is also a recipe for
instant disaster, since the caller (qe_snums_init) uncritically
assigns the return value to the unsigned qe_num_of_snum, and would
thus proceed to attempt to copy 4GB from snum_init_46[] to the snum[]
array.

So fold the handling of the legacy fsl,qe-num-snums into
qe_snums_init, and make sure we do not end up using the snum_init_46
array in cases other than the two where we know it makes sense.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
---
 drivers/soc/fsl/qe/qe.c | 46 ++++++++++++++---------------------------
 1 file changed, 16 insertions(+), 30 deletions(-)

diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 325d689cbf5c..276d7d78ebfc 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -308,24 +308,33 @@ static void qe_snums_init(void)
 	int i;
 
 	bitmap_zero(snum_state, QE_NUM_OF_SNUM);
+	qe_num_of_snum = 28; /* The default number of snum for threads is 28 */
 	qe = qe_get_device_node();
 	if (qe) {
 		i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
 						       snums, 1, QE_NUM_OF_SNUM);
-		of_node_put(qe);
 		if (i > 0) {
+			of_node_put(qe);
 			qe_num_of_snum = i;
 			return;
 		}
+		/*
+		 * Fall back to legacy binding of using the value of
+		 * fsl,qe-num-snums to choose one of the static arrays
+		 * above.
+		 */
+		of_property_read_u32(qe, "fsl,qe-num-snums", &qe_num_of_snum);
+		of_node_put(qe);
 	}
 
-	qe_num_of_snum = qe_get_num_of_snums();
-
-	if (qe_num_of_snum == 76)
+	if (qe_num_of_snum == 76) {
 		snum_init = snum_init_76;
-	else
+	} else if (qe_num_of_snum == 28 || qe_num_of_snum == 46) {
 		snum_init = snum_init_46;
-
+	} else {
+		pr_err("QE: unsupported value of fsl,qe-num-snums: %u\n", qe_num_of_snum);
+		return;
+	}
 	memcpy(snums, snum_init, qe_num_of_snum);
 }
 
@@ -641,30 +650,7 @@ EXPORT_SYMBOL(qe_get_num_of_risc);
 
 unsigned int qe_get_num_of_snums(void)
 {
-	struct device_node *qe;
-	int size;
-	unsigned int num_of_snums;
-	const u32 *prop;
-
-	num_of_snums = 28; /* The default number of snum for threads is 28 */
-	qe = qe_get_device_node();
-	if (!qe)
-		return num_of_snums;
-
-	prop = of_get_property(qe, "fsl,qe-num-snums", &size);
-	if (prop && size == sizeof(*prop)) {
-		num_of_snums = *prop;
-		if ((num_of_snums < 28) || (num_of_snums > QE_NUM_OF_SNUM)) {
-			/* No QE ever has fewer than 28 SNUMs */
-			pr_err("QE: number of snum is invalid\n");
-			of_node_put(qe);
-			return -EINVAL;
-		}
-	}
-
-	of_node_put(qe);
-
-	return num_of_snums;
+	return qe_num_of_snum;
 }
 EXPORT_SYMBOL(qe_get_num_of_snums);
 
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH v5 00/23] Include linux ACPI docs into Sphinx TOC tree
From: Rafael J. Wysocki @ 2019-05-01 10:15 UTC (permalink / raw)
  To: Changbin Du
  Cc: Fenghua Yu, Mauro Carvalho Chehab, Jonathan Corbet, linux-gpio,
	open list:DOCUMENTATION, Linux Kernel Mailing List,
	ACPI Devel Maling List, Bjorn Helgaas, linuxppc-dev,
	Rafael J. Wysocki
In-Reply-To: <20190425152034.u4q6wjhm3yfhbnzp@mail.google.com>

On Thursday, April 25, 2019 5:20:35 PM CEST Changbin Du wrote:
> On Thu, Apr 25, 2019 at 10:44:14AM +0200, Rafael J. Wysocki wrote:
> > .On Wed, Apr 24, 2019 at 7:54 PM Changbin Du <changbin.du@gmail.com> wrote:
> > >
> > > Hi All,
> > > The kernel now uses Sphinx to generate intelligent and beautiful documentation
> > > from reStructuredText files. I converted all of the Linux ACPI/PCI/X86 docs to
> > > reST format in this serias.
> > >
> > > The hieararchy of ACPI docs are based on Corbet's suggestion:
> > > https://lkml.org/lkml/2019/4/3/1047
> > > I did some adjustment according to the content and finally they are placed as:
> > > Documentation/firmware-guide/acpi/
> > 
> > I'd like to queue up this series, but it is missing a patch to create
> > Documentation/firmware-guide/acpi/index.rst.
> > 
> > Care to provide one?
> oops, the first patch is missed. Let me add it next.

I've picked up the first patch from the v6 and applied this series on top of it.

 Thanks!




^ permalink raw reply

* Re: [PATCH] powerpc/mm/radix: Fix kernel crash when running subpage protect test
From: Aneesh Kumar K.V @ 2019-05-01 10:32 UTC (permalink / raw)
  To: Michael Ellerman, npiggin, paulus; +Cc: Sachin Sant, linuxppc-dev
In-Reply-To: <875zqvaqxz.fsf@concordia.ellerman.id.au>

On 5/1/19 7:14 AM, Michael Ellerman wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> 
>> This patch fixes the below crash by making sure we touch the subpage protection
>> related structures only if we know they are allocated on the platform. With
>> radix translation we don't allocate hash context at all and trying to access
>> subpage_prot_table results in
>>
>>   Faulting instruction address: 0xc00000000008bdb4
>>   Oops: Kernel access of bad area, sig: 11 [#1]
>>   LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
>>   ....
>>   NIP [c00000000008bdb4] sys_subpage_prot+0x74/0x590
>>   LR [c00000000000b688] system_call+0x5c/0x70
>>   Call Trace:
>>   [c00020002c6b7d30] [c00020002c6b7d90] 0xc00020002c6b7d90 (unreliable)
>>   [c00020002c6b7e20] [c00000000000b688] system_call+0x5c/0x70
>>   Instruction dump:
>>   fb61ffd8 fb81ffe0 fba1ffe8 fbc1fff0 fbe1fff8 f821ff11 e92d1178 f9210068
>>   39200000 e92d0968 ebe90630 e93f03e8 <eb891038> 60000000 3860fffe e9410068
>>
>> We also move the subpage_prot_table with mmp_sem held to avoid racec
>> between two parallel subpage_prot syscall.
>>
>> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> 
> Presumably it was:
> 
> 701101865f5d ("powerpc/mm: Reduce memory usage for mm_context_t for radix")
> 
> That caused the breakage?
> 

that is correct. Sorry i missed the Fixes: line.

-aneesh


^ permalink raw reply

* Re: [PATCH] x86/mpx: fix recursive munmap() corruption
From: Michael Ellerman @ 2019-05-01 10:32 UTC (permalink / raw)
  To: Laurent Dufour, Dave Hansen, Thomas Gleixner, Dave Hansen
  Cc: mhocko, rguenther, x86, LKML, stable, luto, linux-mm,
	Andrew Morton, linuxppc-dev, vbabka
In-Reply-To: <4e1bbb14-e14f-8643-2072-17b4cdef5326@linux.vnet.ibm.com>

Laurent Dufour <ldufour@linux.vnet.ibm.com> writes:
> Le 23/04/2019 à 18:04, Dave Hansen a écrit :
>> On 4/23/19 4:16 AM, Laurent Dufour wrote:
...
>>> There are 2 assumptions here:
>>>   1. 'start' and 'end' are page aligned (this is guaranteed by __do_munmap().
>>>   2. the VDSO is 1 page (this is guaranteed by the union vdso_data_store on powerpc)
>> 
>> Are you sure about #2?  The 'vdso64_pages' variable seems rather
>> unnecessary if the VDSO is only 1 page. ;)
>
> Hum, not so sure now ;)
> I got confused, only the header is one page.
> The test is working as a best effort, and don't cover the case where 
> only few pages inside the VDSO are unmmapped (start > 
> mm->context.vdso_base). This is not what CRIU is doing and so this was 
> enough for CRIU support.
>
> Michael, do you think there is a need to manage all the possibility 
> here, since the only user is CRIU and unmapping the VDSO is not a so 
> good idea for other processes ?

Couldn't we implement the semantic that if any part of the VDSO is
unmapped then vdso_base is set to zero? That should be fairly easy, eg:

	if (start < vdso_end && end >= mm->context.vdso_base)
		mm->context.vdso_base = 0;


We might need to add vdso_end to the mm->context, but that should be OK.

That seems like it would work for CRIU and make sense in general?

cheers

^ permalink raw reply

* Re: [PATCH v4] powerpc/pseries: Remove limit in wait for dying CPU
From: Nathan Lynch @ 2019-05-01 14:57 UTC (permalink / raw)
  To: Thiago Jung Bauermann
  Cc: Gautham R Shenoy, linux-kernel, Nicholas Piggin,
	Michael Bringmann, Tyrel Datwyler, Vaidyanathan Srinivasan,
	linuxppc-dev
In-Reply-To: <87v9yve02x.fsf@morokweng.localdomain>

Hi Thiago,

Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
> Nathan Lynch <nathanl@linux.ibm.com> writes:
>> Thiago Jung Bauermann <bauerman@linux.ibm.com> writes:
>>> +		while (true) {
>>>  			cpu_status = smp_query_cpu_stopped(pcpu);
>>>  			if (cpu_status == QCSS_STOPPED ||
>>>  			    cpu_status == QCSS_HARDWARE_ERROR)
>>>  				break;
>>> -			cpu_relax();
>>> +			udelay(100);
>>>  		}
>>>  	}
>>
>> I agree with looping indefinitely but doesn't it need a cond_resched()
>> or similar check?
>
> If there's no kernel or hypervisor bug, it shouldn't take more than a
> few tens of ms for this loop to complete (Gautham measured a maximum of
> 10 ms on a POWER9 with an earlier version of this patch).

10ms is twice the default scheduler quantum...


> In case of bugs related to CPU hotplug (either in the kernel or the
> hypervisor), I was hoping that the resulting lockup warnings would be a
> good indicator that something is wrong. :-)

Not convinced we should assume something is wrong if it takes a few
dozen ms to complete the operation. AFAIK we don't have any guarantees
about the maximum latency of stop-self, and it can be affected by other
activity in the system, whether we're in shared processor mode, etc. Not
to mention smp_query_cpu_stopped has to acquire the global RTAS lock and
be serialized with other tasks calling into RTAS. So I am concerned
about generating spurious warnings here.

If for whatever reason the operation is taking too long, drmgr or
whichever application is initiating the change will appear to stop
making progress. It's not too hard to find out what's going on with
facilities like perf or /proc/pid/stack.


> Though perhaps adding a cond_resched() every 10 ms or so, with a
> WARN_ON() if it loops for more than 50 ms would be better.

A warning doesn't seem appropriate to me, and cond_resched should be
invoked in each iteration. Or just msleep(1) in each iteration would be
fine, I think.

But I'd like to bring in some more context -- here is the body of
pseries_cpu_die:

static void pseries_cpu_die(unsigned int cpu)
{
	int tries;
	int cpu_status = 1;
	unsigned int pcpu = get_hard_smp_processor_id(cpu);

	if (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
		cpu_status = 1;
		for (tries = 0; tries < 5000; tries++) {
			if (get_cpu_current_state(cpu) == CPU_STATE_INACTIVE) {
				cpu_status = 0;
				break;
			}
			msleep(1);
		}
	} else if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {

		for (tries = 0; tries < 25; tries++) {
			cpu_status = smp_query_cpu_stopped(pcpu);
			if (cpu_status == QCSS_STOPPED ||
			    cpu_status == QCSS_HARDWARE_ERROR)
				break;
			cpu_relax();
		}
}

This patch alters the behavior of the second loop (the CPU_STATE_OFFLINE
branch). The CPU_STATE_INACTIVE branch is used when the offline behavior
is to use H_CEDE instead of stop-self, correct?

And isn't entering H_CEDE expected to be quite a bit faster than
stop-self? If so, why does that path get five whole seconds[*] while
we're bikeshedding about tens of milliseconds for stop-self? :-)

[*] And should it be made to retry indefinitely as well?


^ permalink raw reply

* Re: [PATCH v2 4/6] dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
From: Joakim Tjernlund @ 2019-05-01 15:12 UTC (permalink / raw)
  To: rasmus.villemoes@prevas.dk, leoyang.li@nxp.com,
	qiang.zhao@nxp.com, devicetree@vger.kernel.org
  Cc: mark.rutland@arm.com, Rasmus.Villemoes@prevas.se,
	linux-kernel@vger.kernel.org, oss@buserror.net,
	robh+dt@kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190501092841.9026-5-rasmus.villemoes@prevas.dk>

On Wed, 2019-05-01 at 09:29 +0000, Rasmus Villemoes wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Reading table 4-30, and its footnotes, of the QUICC Engine Block
> Reference Manual shows that the set of snum _values_ is not
> necessarily just a function of the _number_ of snums, as given in the
> fsl,qe-num-snums property.
> 
> As an alternative, to make it easier to add support for other variants
> of the QUICC engine IP, this introduces a new binding fsl,qe-snums,
> which automatically encodes both the number of snums and the actual
> values to use.
> 
> For example, for the MPC8309, one would specify the property as
> 
>                fsl,qe-snums = /bits/ 8 <
>                        0x88 0x89 0x98 0x99 0xa8 0xa9 0xb8 0xb9
>                        0xc8 0xc9 0xd8 0xd9 0xe8 0xe9>;

I think you need add this example to the qe.txt doc itselft. BTW, what is /bits/ ?
> 
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
>  Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
> index d7afaff5faff..05f5f485562a 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
> @@ -18,7 +18,8 @@ Required properties:
>  - reg : offset and length of the device registers.
>  - bus-frequency : the clock frequency for QUICC Engine.
>  - fsl,qe-num-riscs: define how many RISC engines the QE has.
> -- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
> +- fsl,qe-snums: This property has to be specified as '/bits/ 8' value,
> +  defining the array of serial number (SNUM) values for the virtual
>    threads.
> 
>  Optional properties:
> @@ -34,6 +35,11 @@ Recommended properties
>  - brg-frequency : the internal clock source frequency for baud-rate
>    generators in Hz.
> 
> +Deprecated properties
> +- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use
> +  for the threads. Use fsl,qe-snums instead to not only specify the
> +  number of snums, but also their values.
> +
>  Example:
>       qe@e0100000 {
>         #address-cells = <1>;
> --
> 2.20.1
> 


^ permalink raw reply

* Re: [PATCH v2 3/6] x86: clean up _TIF_SYSCALL_EMU handling using ptrace_syscall_enter hook
From: Oleg Nesterov @ 2019-05-01 15:57 UTC (permalink / raw)
  To: Sudeep Holla
  Cc: Haibo Xu, Steve Capper, Catalin Marinas, jdike, x86, Will Deacon,
	linux-kernel, Bin Lu, Richard Weinberger, Ingo Molnar,
	Paul Mackerras, Andy Lutomirski, Borislav Petkov, Thomas Gleixner,
	linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190430164413.GA18913@e107155-lin>

On 04/30, Sudeep Holla wrote:
>
> On Mon, Mar 18, 2019 at 04:33:22PM +0100, Oleg Nesterov wrote:
> >
> > And it seems that _TIF_WORK_SYSCALL_ENTRY needs some cleanups too... We don't need
> > "& _TIF_WORK_SYSCALL_ENTRY" in syscall_trace_enter, and _TIF_WORK_SYSCALL_ENTRY
> > should not include _TIF_NOHZ?
> >
>
> I was about to post the updated version and checked this to make sure I have
> covered everything or not. I had missed the above comment. All architectures
> have _TIF_NOHZ in their mask that they check to do work. And from x86, I read
> "...syscall_trace_enter(). Also includes TIF_NOHZ for enter_from_user_mode()"
> So I don't understand why _TIF_NOHZ needs to be dropped.

I have already forgot this discussion... But after I glanced at this code again
I still think the same, and I don't understand why do you disagree.

> Also if we need to drop, we can address that separately examining all archs.

Sure, and I was only talking about x86. We can keep TIF_NOHZ and even
set_tsk_thread_flag(TIF_NOHZ) in context_tracking_cpu_set() if some arch needs
this but remove TIF_NOHZ from TIF_WORK_SYSCALL_ENTRY in arch/x86/include/asm/thread_info.h,
afaics this shouldn't make any difference.

And I see no reason why x86 needs to use TIF_WORK_SYSCALL_ENTRY in
syscall_trace_enter().

Oleg.


^ permalink raw reply

* RE: [PATCH] crypto: caam/jr - Remove extra memory barrier during job ring dequeue
From: Vakul Garg @ 2019-05-01 14:27 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Aymen Sghaier, herbert@gondor.apana.org.au, Horia Geanta,
	linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	davem@davemloft.net
In-Reply-To: <87pnp2aflz.fsf@concordia.ellerman.id.au>



> -----Original Message-----
> From: Michael Ellerman <mpe@ellerman.id.au>
> Sent: Wednesday, May 1, 2019 11:20 AM
> To: Vakul Garg <vakul.garg@nxp.com>
> Cc: linux-crypto@vger.kernel.org; Aymen Sghaier
> <aymen.sghaier@nxp.com>; davem@davemloft.net;
> herbert@gondor.apana.org.au; Horia Geanta <horia.geanta@nxp.com>;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] crypto: caam/jr - Remove extra memory barrier during
> job ring dequeue
> 
> Vakul Garg wrote:
> > In function caam_jr_dequeue(), a full memory barrier is used before
> > writing response job ring's register to signal removal of the
> > completed job. Therefore for writing the register, we do not need
> > another write memory barrier. Hence it is removed by replacing the
> > call to wr_reg32() with a newly defined function wr_reg32_relaxed().
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> > ---
> >  drivers/crypto/caam/jr.c   | 2 +-
> >  drivers/crypto/caam/regs.h | 8 ++++++++
> >  2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c index
> > 4e9b3fca5627..2ce6d7d2ad72 100644
> > --- a/drivers/crypto/caam/jr.c
> > +++ b/drivers/crypto/caam/jr.c
> > @@ -266,7 +266,7 @@ static void caam_jr_dequeue(unsigned long
> devarg)
> >  		mb();
> >
> >  		/* set done */
> > -		wr_reg32(&jrp->rregs->outring_rmvd, 1);
> > +		wr_reg32_relaxed(&jrp->rregs->outring_rmvd, 1);
> >
> >  		jrp->out_ring_read_index = (jrp->out_ring_read_index + 1) &
> >  					   (JOBR_DEPTH - 1);
> > diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
> > index 3cd0822ea819..9e912c722e33 100644
> > --- a/drivers/crypto/caam/regs.h
> > +++ b/drivers/crypto/caam/regs.h
> > @@ -96,6 +96,14 @@ cpu_to_caam(16)
> >  cpu_to_caam(32)
> >  cpu_to_caam(64)
> >
> > +static inline void wr_reg32_relaxed(void __iomem *reg, u32 data) {
> > +	if (caam_little_end)
> > +		writel_relaxed(data, reg);
> > +	else
> > +		writel_relaxed(cpu_to_be32(data), reg); }
> > +
> >  static inline void wr_reg32(void __iomem *reg, u32 data)  {
> >  	if (caam_little_end)
> 
> This crashes on my p5020ds. Did you test on powerpc?
> 
I did not test on powerpc.

> # first bad commit: [bbfcac5ff5f26aafa51935a62eb86b6eacfe8a49] crypto:
> caam/jr - Remove extra memory barrier during job ring dequeue
> 
> Log:
> 
>   ------------[ cut here ]------------
>   kernel BUG at drivers/crypto/caam/jr.c:191!
>   Oops: Exception in kernel mode, sig: 5 [#1]
>   BE PAGE_SIZE=4K SMP NR_CPUS=24 CoreNet Generic
>   Modules linked in:
>   CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.1.0-rc1-gcc-8.2.0-00060-
> gbbfcac5ff5f2 #31
>   NIP:  c00000000079d704 LR: c00000000079d498 CTR: c000000000086914
>   REGS: c0000000fffc7970 TRAP: 0700   Not tainted  (5.1.0-rc1-gcc-8.2.0-
> 00060-gbbfcac5ff5f2)
>   MSR:  0000000080029000 <CE,EE,ME>  CR: 28008484  XER: 00000000
>   IRQMASK: 0
>   GPR00: c00000000079d6b0 c0000000fffc7c00 c000000000fbc800
> 0000000000000001
>   GPR04: 000000007e080080 000000000000ffc0 0000000000000001
> 00000000000067d7
>   GPR08: 00000000880401a9 0000000000000000 0000000000000001
> 00000000fa83b2da
>   GPR12: 0000000028008224 c00000003ffff800 c000000000fc20b0
> 0000000000000100
>   GPR16: 8920f09520bea117 c000000000def480 0000000000000000
> 0000000000000001
>   GPR20: c000000000fc3940 c0000000f3537e18 0000000000000001
> c000000001026cc5
>   GPR24: 0000000000000001 c0000000f3328000 0000000000000001
> c0000000f3451010
>   GPR28: 0000000000000000 0000000000000001 0000000000000000
> 0000000000000000
>   NIP [c00000000079d704] .caam_jr_dequeue+0x2f0/0x410
>   LR [c00000000079d498] .caam_jr_dequeue+0x84/0x410
>   Call Trace:
>   [c0000000fffc7c00] [c00000000079d6b0] .caam_jr_dequeue+0x29c/0x410
> (unreliable)
>   [c0000000fffc7cd0] [c00000000004fef0]
> .tasklet_action_common.isra.3+0xac/0x180
>   [c0000000fffc7d80] [c000000000a2f99c] .__do_softirq+0x174/0x3f8
>   [c0000000fffc7e90] [c00000000004fb94] .irq_exit+0xc4/0xdc
>   [c0000000fffc7f00] [c000000000007348] .__do_irq+0x8c/0x1b0
>   [c0000000fffc7f90] [c0000000000150c4] .call_do_irq+0x14/0x24
>   [c0000000f3137930] [c0000000000074e4] .do_IRQ+0x78/0xd4
>   [c0000000f31379c0] [c000000000019998]
> exc_0x500_common+0xfc/0x100
>   --- interrupt: 501 at .book3e_idle+0x24/0x5c
>       LR = .book3e_idle+0x24/0x5c
>   [c0000000f3137cc0] [c00000000000a6a4] .arch_cpu_idle+0x34/0xa0
> (unreliable)
>   [c0000000f3137d30] [c000000000a2f2e8] .default_idle_call+0x5c/0x70
>   [c0000000f3137da0] [c000000000084210] .do_idle+0x1b0/0x1f4
>   [c0000000f3137e40] [c000000000084434] .cpu_startup_entry+0x28/0x30
>   [c0000000f3137eb0] [c000000000021538] .start_secondary+0x59c/0x5b0
>   [c0000000f3137f90] [c00000000000045c]
> start_secondary_prolog+0x10/0x14
>   Instruction dump:
>   7d284a14 e9290018 2fa90000 40de001c 3bbd0001 57bd05fe 7d3db050
> 712901ff
>   7fbd07b4 40e2ffcc 93b500dc 4bffff94 <0fe00000> 78890022 79270020
> 41d600ec
>   ---[ end trace 7bedbdf37a95ab35 ]---
> 
> That's hitting:
> 
> 		/* we should never fail to find a matching descriptor */
> 		BUG_ON(CIRC_CNT(head, tail + i, JOBR_DEPTH) <= 0);
> 

Is it hitting under high traffic to caam?
How to reproduce it?
 

> cheers

^ permalink raw reply

* Re: [PATCH v2 3/6] x86: clean up _TIF_SYSCALL_EMU handling using ptrace_syscall_enter hook
From: Sudeep Holla @ 2019-05-01 16:51 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Haibo Xu, Steve Capper, Catalin Marinas, jdike, x86, Will Deacon,
	linux-kernel, Bin Lu, Richard Weinberger, Ingo Molnar,
	Paul Mackerras, Andy Lutomirski, Borislav Petkov, Thomas Gleixner,
	linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190501155711.GB30235@redhat.com>

On Wed, May 01, 2019 at 05:57:11PM +0200, Oleg Nesterov wrote:
> On 04/30, Sudeep Holla wrote:
> >
> > On Mon, Mar 18, 2019 at 04:33:22PM +0100, Oleg Nesterov wrote:
> > >
> > > And it seems that _TIF_WORK_SYSCALL_ENTRY needs some cleanups too... We don't need
> > > "& _TIF_WORK_SYSCALL_ENTRY" in syscall_trace_enter, and _TIF_WORK_SYSCALL_ENTRY
> > > should not include _TIF_NOHZ?
> > >
> >
> > I was about to post the updated version and checked this to make sure I have
> > covered everything or not. I had missed the above comment. All architectures
> > have _TIF_NOHZ in their mask that they check to do work. And from x86, I read
> > "...syscall_trace_enter(). Also includes TIF_NOHZ for enter_from_user_mode()"
> > So I don't understand why _TIF_NOHZ needs to be dropped.
>
> I have already forgot this discussion... But after I glanced at this code again
> I still think the same, and I don't understand why do you disagree.
>

Sorry, but I didn't have any disagreement, I just said I don't understand
the usage on all architectures at that moment.

> > Also if we need to drop, we can address that separately examining all archs.
>
> Sure, and I was only talking about x86. We can keep TIF_NOHZ and even
> set_tsk_thread_flag(TIF_NOHZ) in context_tracking_cpu_set() if some arch needs
> this but remove TIF_NOHZ from TIF_WORK_SYSCALL_ENTRY in arch/x86/include/asm/thread_info.h,
> afaics this shouldn't make any difference.
>

OK, it's just x86, then I understand your point. I was looking at all
the architectures, sorry for the confusion.

> And I see no reason why x86 needs to use TIF_WORK_SYSCALL_ENTRY in
> syscall_trace_enter().
>

Agreed

--
Regards,
Sudeep

^ permalink raw reply

* Re: [PATCH v2] powerpc/32s: fix BATs setting with CONFIG_STRICT_KERNEL_RWX
From: christophe leroy @ 2019-05-01 17:22 UTC (permalink / raw)
  To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Serge Belyshev, Segher Boessenkool
  Cc: linuxppc-dev, linux-kernel
In-Reply-To: <878svrat7x.fsf@concordia.ellerman.id.au>



Le 01/05/2019 à 02:55, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Serge reported some crashes with CONFIG_STRICT_KERNEL_RWX enabled
>> on a book3s32 machine.
>>
>> Analysis shows two issues:
>> - BATs addresses and sizes are not properly aligned.
>> - There is a gap between the last address covered by BATs and the
>> first address covered by pages.
>>
>> Memory mapped with DBATs:
>> 0: 0xc0000000-0xc07fffff 0x00000000 Kernel RO coherent
>> 1: 0xc0800000-0xc0bfffff 0x00800000 Kernel RO coherent
>> 2: 0xc0c00000-0xc13fffff 0x00c00000 Kernel RW coherent
>> 3: 0xc1400000-0xc23fffff 0x01400000 Kernel RW coherent
>> 4: 0xc2400000-0xc43fffff 0x02400000 Kernel RW coherent
>> 5: 0xc4400000-0xc83fffff 0x04400000 Kernel RW coherent
>> 6: 0xc8400000-0xd03fffff 0x08400000 Kernel RW coherent
>> 7: 0xd0400000-0xe03fffff 0x10400000 Kernel RW coherent
>>
>> Memory mapped with pages:
>> 0xe1000000-0xefffffff  0x21000000       240M        rw       present           dirty  accessed
>>
>> This patch fixes both issues. With the patch, we get the following
>> which is as expected:
>>
>> Memory mapped with DBATs:
>> 0: 0xc0000000-0xc07fffff 0x00000000 Kernel RO coherent
>> 1: 0xc0800000-0xc0bfffff 0x00800000 Kernel RO coherent
>> 2: 0xc0c00000-0xc0ffffff 0x00c00000 Kernel RW coherent
>> 3: 0xc1000000-0xc1ffffff 0x01000000 Kernel RW coherent
>> 4: 0xc2000000-0xc3ffffff 0x02000000 Kernel RW coherent
>> 5: 0xc4000000-0xc7ffffff 0x04000000 Kernel RW coherent
>> 6: 0xc8000000-0xcfffffff 0x08000000 Kernel RW coherent
>> 7: 0xd0000000-0xdfffffff 0x10000000 Kernel RW coherent
>>
>> Memory mapped with pages:
>> 0xe0000000-0xefffffff  0x20000000       256M        rw       present           dirty  accessed
>>
>> Reported-by: Serge Belyshev <belyshev@depni.sinp.msu.ru>
>> Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
>> Cc: stable@vger.kernel.org
> 
> I could probably still get this into v5.1 if you're confident it's a
> good fix.

If possible it would be great.

Yes I'm confident it is a good fix:
- The fix has no impact on the configurations I tested originally (they 
were lacking a trailing area not mapped with BATs and the boundarie 
between RW and RO was a power of 2 so ffs() returned the same as lfs())
- The fix was tested by myself on QEMU.
- The fix was tested by Serge.
- The fix was acked by Segher.
- The fix make sense (ie ffs() is the good one, fls() was definitly wrong)

Christophe

> 
> cheers
> 

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus


^ permalink raw reply

* remove asm-generic/ptrace.h
From: Christoph Hellwig @ 2019-05-01 17:39 UTC (permalink / raw)
  To: Oleg Nesterov, Arnd Bergmann
  Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
	linux-arm-kernel

Hi all,

asm-generic/ptrace.h is a little weird in that it doesn't actually
implement any functionality, but it provided multiple layers of macros
that just implement trivial inline functions.  We implement those
directly in the few architectures and be off with a much simpler
design.

^ permalink raw reply

* [PATCH 1/5] arm64: don't use asm-generic/ptrace.h
From: Christoph Hellwig @ 2019-05-01 17:39 UTC (permalink / raw)
  To: Oleg Nesterov, Arnd Bergmann
  Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
	linux-arm-kernel
In-Reply-To: <20190501173943.5688-1-hch@lst.de>

Doing the indirection through macros for the regs accessors just
makes them harder to read, so implement the helpers directly.

Note that only the helpers actually used are implemented now.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/arm64/include/asm/ptrace.h | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index ec60174c8c18..55c1fb25cf32 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -228,11 +228,12 @@ static inline void forget_syscall(struct pt_regs *regs)
 #define fast_interrupts_enabled(regs) \
 	(!((regs)->pstate & PSR_F_BIT))
 
-#define GET_USP(regs) \
-	(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
-
-#define SET_USP(ptregs, value) \
-	(!compat_user_mode(regs) ? ((regs)->sp = value) : ((regs)->compat_sp = value))
+static inline unsigned long user_stack_pointer(struct pt_regs *regs)
+{
+	if (compat_user_mode(regs))
+		return regs->compat_sp;
+	return regs->sp;
+}
 
 extern int regs_query_register_offset(const char *name);
 extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
@@ -309,13 +310,20 @@ static inline unsigned long regs_return_value(struct pt_regs *regs)
 struct task_struct;
 int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task);
 
-#define GET_IP(regs)		((unsigned long)(regs)->pc)
-#define SET_IP(regs, value)	((regs)->pc = ((u64) (value)))
-
-#define GET_FP(ptregs)		((unsigned long)(ptregs)->regs[29])
-#define SET_FP(ptregs, value)	((ptregs)->regs[29] = ((u64) (value)))
+static inline unsigned long instruction_pointer(struct pt_regs *regs)
+{
+	return regs->pc;
+}
+static inline void instruction_pointer_set(struct pt_regs *regs,
+		unsigned long val)
+{
+	regs->pc = val;
+}
 
-#include <asm-generic/ptrace.h>
+static inline unsigned long frame_pointer(struct pt_regs *regs)
+{
+	return regs->regs[29];
+}
 
 #define procedure_link_pointer(regs)	((regs)->regs[30])
 
@@ -325,7 +333,6 @@ static inline void procedure_link_pointer_set(struct pt_regs *regs,
 	procedure_link_pointer(regs) = val;
 }
 
-#undef profile_pc
 extern unsigned long profile_pc(struct pt_regs *regs);
 
 #endif /* __ASSEMBLY__ */
-- 
2.20.1


^ permalink raw reply related

* [PATCH 2/5] powerpc: don't use asm-generic/ptrace.h
From: Christoph Hellwig @ 2019-05-01 17:39 UTC (permalink / raw)
  To: Oleg Nesterov, Arnd Bergmann
  Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
	linux-arm-kernel
In-Reply-To: <20190501173943.5688-1-hch@lst.de>

Doing the indirection through macros for the regs accessors just
makes them harder to read, so implement the helpers directly.

Note that only the helpers actually used are implemented now.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/powerpc/include/asm/ptrace.h | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 64271e562fed..5d30944f1f6b 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -108,18 +108,33 @@ struct pt_regs
 
 #ifndef __ASSEMBLY__
 
-#define GET_IP(regs)		((regs)->nip)
-#define GET_USP(regs)		((regs)->gpr[1])
-#define GET_FP(regs)		(0)
-#define SET_FP(regs, val)
+static inline unsigned long instruction_pointer(struct pt_regs *regs)
+{
+	return regs->nip;
+}
+
+static inline void instruction_pointer_set(struct pt_regs *regs,
+		unsigned long val)
+{
+	regs->nip = val;
+}
+
+static inline unsigned long user_stack_pointer(struct pt_regs *regs)
+{
+	return regs->gpr[1];
+}
+
+static inline unsigned long frame_pointer(struct pt_regs *regs)
+{
+	return 0;
+}
 
 #ifdef CONFIG_SMP
 extern unsigned long profile_pc(struct pt_regs *regs);
-#define profile_pc profile_pc
+#else
+#define profile_pc(regs) instruction_pointer(regs)
 #endif
 
-#include <asm-generic/ptrace.h>
-
 #define kernel_stack_pointer(regs) ((regs)->gpr[1])
 static inline int is_syscall_success(struct pt_regs *regs)
 {
-- 
2.20.1


^ permalink raw reply related

* [PATCH 3/5] sh: don't use asm-generic/ptrace.h
From: Christoph Hellwig @ 2019-05-01 17:39 UTC (permalink / raw)
  To: Oleg Nesterov, Arnd Bergmann
  Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
	linux-arm-kernel
In-Reply-To: <20190501173943.5688-1-hch@lst.de>

Doing the indirection through macros for the regs accessors just
makes them harder to read, so implement the helpers directly.

Note that only the helpers actually used are implemented now.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/sh/include/asm/ptrace.h | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/arch/sh/include/asm/ptrace.h b/arch/sh/include/asm/ptrace.h
index 9143c7babcbe..6c89e3e04cee 100644
--- a/arch/sh/include/asm/ptrace.h
+++ b/arch/sh/include/asm/ptrace.h
@@ -16,8 +16,31 @@
 #define user_mode(regs)			(((regs)->sr & 0x40000000)==0)
 #define kernel_stack_pointer(_regs)	((unsigned long)(_regs)->regs[15])
 
-#define GET_FP(regs)	((regs)->regs[14])
-#define GET_USP(regs)	((regs)->regs[15])
+static inline unsigned long instruction_pointer(struct pt_regs *regs)
+{
+	return regs->pc;
+}
+static inline void instruction_pointer_set(struct pt_regs *regs,
+		unsigned long val)
+{
+	regs->pc = val;
+}
+
+static inline unsigned long frame_pointer(struct pt_regs *regs)
+{
+	return regs->regs[14];
+}
+
+static inline unsigned long user_stack_pointer(struct pt_regs *regs)
+{
+	return regs->regs[15];
+}
+
+static inline void user_stack_pointer_set(struct pt_regs *regs,
+		unsigned long val)
+{
+	regs->regs[15] = val;
+}
 
 #define arch_has_single_step()	(1)
 
@@ -112,7 +135,5 @@ static inline unsigned long profile_pc(struct pt_regs *regs)
 
 	return pc;
 }
-#define profile_pc profile_pc
 
-#include <asm-generic/ptrace.h>
 #endif /* __ASM_SH_PTRACE_H */
-- 
2.20.1


^ permalink raw reply related

* [PATCH 4/5] x86: don't use asm-generic/ptrace.h
From: Christoph Hellwig @ 2019-05-01 17:39 UTC (permalink / raw)
  To: Oleg Nesterov, Arnd Bergmann
  Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
	linux-arm-kernel
In-Reply-To: <20190501173943.5688-1-hch@lst.de>

Doing the indirection through macros for the regs accessors just
makes them harder to read, so implement the helpers directly.

Note that only the helpers actually used are implemented now.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 arch/x86/include/asm/ptrace.h | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
index 8a7fc0cca2d1..9b81ef539eb3 100644
--- a/arch/x86/include/asm/ptrace.h
+++ b/arch/x86/include/asm/ptrace.h
@@ -98,7 +98,6 @@ struct cpuinfo_x86;
 struct task_struct;
 
 extern unsigned long profile_pc(struct pt_regs *regs);
-#define profile_pc profile_pc
 
 extern unsigned long
 convert_ip_to_linear(struct task_struct *child, struct pt_regs *regs);
@@ -175,11 +174,31 @@ static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
 }
 #endif
 
-#define GET_IP(regs) ((regs)->ip)
-#define GET_FP(regs) ((regs)->bp)
-#define GET_USP(regs) ((regs)->sp)
+static inline unsigned long instruction_pointer(struct pt_regs *regs)
+{
+	return regs->ip;
+}
+static inline void instruction_pointer_set(struct pt_regs *regs,
+		unsigned long val)
+{
+	regs->ip = val;
+}
+
+static inline unsigned long frame_pointer(struct pt_regs *regs)
+{
+	return regs->bp;
+}
 
-#include <asm-generic/ptrace.h>
+static inline unsigned long user_stack_pointer(struct pt_regs *regs)
+{
+	return regs->sp;
+}
+
+static inline void user_stack_pointer_set(struct pt_regs *regs,
+		unsigned long val)
+{
+	regs->sp = val;
+}
 
 /* Query offset/name of register from its name/offset */
 extern int regs_query_register_offset(const char *name);
-- 
2.20.1


^ permalink raw reply related

* [PATCH 5/5] asm-generic: remove ptrace.h
From: Christoph Hellwig @ 2019-05-01 17:39 UTC (permalink / raw)
  To: Oleg Nesterov, Arnd Bergmann
  Cc: linux-arch, linux-sh, x86, linux-mips, linux-kernel, linuxppc-dev,
	linux-arm-kernel
In-Reply-To: <20190501173943.5688-1-hch@lst.de>

No one is using this helper anymore.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 MAINTAINERS                    |  1 -
 arch/mips/include/asm/ptrace.h |  5 ---
 include/asm-generic/ptrace.h   | 74 ----------------------------------
 3 files changed, 80 deletions(-)
 delete mode 100644 include/asm-generic/ptrace.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 5c38f21aee78..0d44b2369f42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12586,7 +12586,6 @@ F:	include/linux/regset.h
 F:	include/linux/tracehook.h
 F:	include/uapi/linux/ptrace.h
 F:	include/uapi/linux/ptrace.h
-F:	include/asm-generic/ptrace.h
 F:	kernel/ptrace.c
 F:	arch/*/ptrace*.c
 F:	arch/*/*/ptrace*.c
diff --git a/arch/mips/include/asm/ptrace.h b/arch/mips/include/asm/ptrace.h
index b6578611dddb..1e76774b36dd 100644
--- a/arch/mips/include/asm/ptrace.h
+++ b/arch/mips/include/asm/ptrace.h
@@ -56,11 +56,6 @@ static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
 	return regs->regs[31];
 }
 
-/*
- * Don't use asm-generic/ptrace.h it defines FP accessors that don't make
- * sense on MIPS.  We rather want an error if they get invoked.
- */
-
 static inline void instruction_pointer_set(struct pt_regs *regs,
                                            unsigned long val)
 {
diff --git a/include/asm-generic/ptrace.h b/include/asm-generic/ptrace.h
deleted file mode 100644
index 82e674f6b337..000000000000
--- a/include/asm-generic/ptrace.h
+++ /dev/null
@@ -1,74 +0,0 @@
-/*
- * Common low level (register) ptrace helpers
- *
- * Copyright 2004-2011 Analog Devices Inc.
- *
- * Licensed under the GPL-2 or later.
- */
-
-#ifndef __ASM_GENERIC_PTRACE_H__
-#define __ASM_GENERIC_PTRACE_H__
-
-#ifndef __ASSEMBLY__
-
-/* Helpers for working with the instruction pointer */
-#ifndef GET_IP
-#define GET_IP(regs) ((regs)->pc)
-#endif
-#ifndef SET_IP
-#define SET_IP(regs, val) (GET_IP(regs) = (val))
-#endif
-
-static inline unsigned long instruction_pointer(struct pt_regs *regs)
-{
-	return GET_IP(regs);
-}
-static inline void instruction_pointer_set(struct pt_regs *regs,
-                                           unsigned long val)
-{
-	SET_IP(regs, val);
-}
-
-#ifndef profile_pc
-#define profile_pc(regs) instruction_pointer(regs)
-#endif
-
-/* Helpers for working with the user stack pointer */
-#ifndef GET_USP
-#define GET_USP(regs) ((regs)->usp)
-#endif
-#ifndef SET_USP
-#define SET_USP(regs, val) (GET_USP(regs) = (val))
-#endif
-
-static inline unsigned long user_stack_pointer(struct pt_regs *regs)
-{
-	return GET_USP(regs);
-}
-static inline void user_stack_pointer_set(struct pt_regs *regs,
-                                          unsigned long val)
-{
-	SET_USP(regs, val);
-}
-
-/* Helpers for working with the frame pointer */
-#ifndef GET_FP
-#define GET_FP(regs) ((regs)->fp)
-#endif
-#ifndef SET_FP
-#define SET_FP(regs, val) (GET_FP(regs) = (val))
-#endif
-
-static inline unsigned long frame_pointer(struct pt_regs *regs)
-{
-	return GET_FP(regs);
-}
-static inline void frame_pointer_set(struct pt_regs *regs,
-                                     unsigned long val)
-{
-	SET_FP(regs, val);
-}
-
-#endif /* __ASSEMBLY__ */
-
-#endif
-- 
2.20.1


^ permalink raw reply related

* Re: [PATCH v2 4/6] dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
From: Rasmus Villemoes @ 2019-05-01 18:47 UTC (permalink / raw)
  To: Joakim Tjernlund, leoyang.li@nxp.com, qiang.zhao@nxp.com,
	devicetree@vger.kernel.org
  Cc: mark.rutland@arm.com, Rasmus Villemoes,
	linux-kernel@vger.kernel.org, oss@buserror.net,
	robh+dt@kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <4c3aef881393398ca18efac99b1f76e7dbd19acf.camel@infinera.com>

On 01/05/2019 17.12, Joakim Tjernlund wrote:
> On Wed, 2019-05-01 at 09:29 +0000, Rasmus Villemoes wrote:
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>
>>
>> Reading table 4-30, and its footnotes, of the QUICC Engine Block
>> Reference Manual shows that the set of snum _values_ is not
>> necessarily just a function of the _number_ of snums, as given in the
>> fsl,qe-num-snums property.
>>
>> As an alternative, to make it easier to add support for other variants
>> of the QUICC engine IP, this introduces a new binding fsl,qe-snums,
>> which automatically encodes both the number of snums and the actual
>> values to use.
>>
>> For example, for the MPC8309, one would specify the property as
>>
>>                fsl,qe-snums = /bits/ 8 <
>>                        0x88 0x89 0x98 0x99 0xa8 0xa9 0xb8 0xb9
>>                        0xc8 0xc9 0xd8 0xd9 0xe8 0xe9>;
> 
> I think you need add this example to the qe.txt doc itselft.

Sure, can do.

> BTW, what is /bits/ ?

That indicates that the numbers should be stored as an array of u8, and
not as by default an array of (big-endian) 32-bit numbers. See

https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dts-format.txt#n46

This is already used in some bindings and existing .dts (e.g.
hwmon/aspeed-pwm-tacho.txt, but git grep shows many more).

Rasmus

^ 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