* [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Desnes A. Nunes do Rosario @ 2018-03-14 16:34 UTC (permalink / raw)
To: linux-kernel, linux-pci, linuxppc-dev
Cc: bhelgaas, benh, paulus, mpe, ruscur, aik, david, fbarrat, brking
In-Reply-To: <20180314163455.15854-1-desnesn@linux.vnet.ibm.com>
Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
silent PCI realignment messages if the flag is turned on by a driver.
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
---
drivers/pci/pci.c | 3 ++-
drivers/pci/setup-res.c | 3 ++-
include/linux/pci.h | 2 ++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c71d1a66cdd..be197c944e5f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)
return;
}
- pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
+ pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
pci_read_config_word(dev, PCI_COMMAND, &command);
command &= ~PCI_COMMAND_MEMORY;
pci_write_config_word(dev, PCI_COMMAND, command);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 369d48d6c6f1..00a538def763 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
void pci_disable_bridge_window(struct pci_dev *dev)
{
- pci_info(dev, "disabling bridge mem windows\n");
+ if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
+ pci_info(dev, "disabling bridge mem windows\n");
/* MMIO Base/Limit */
pci_write_config_dword(dev, PCI_MEMORY_BASE, 0x0000fff0);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e057e8cc63e7..993f9c7dcc00 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -205,6 +205,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
/* Don't use Relaxed Ordering for TLPs directed at this device */
PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
+ /* Silent PCI resource realignment messages */
+ PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
};
enum pci_irq_reroute_variant {
--
2.14.3
^ permalink raw reply related
* [PATCH 2/2, powerpc/powernv] powerpc/powernv: Tweak PCI_DEV_FLAGS_QUIET_PCI_REALIGN on/off during boot
From: Desnes A. Nunes do Rosario @ 2018-03-14 16:34 UTC (permalink / raw)
To: linux-kernel, linux-pci, linuxppc-dev
Cc: bhelgaas, benh, paulus, mpe, ruscur, aik, david, fbarrat, brking
In-Reply-To: <20180314163455.15854-1-desnesn@linux.vnet.ibm.com>
Turn on PCI_DEV_FLAGS_QUIET_PCI_REALIGN flag on powernv's pci driver
to silent PCI realignment messages through a early stage hook, and turn
it off right before the pci device is enabled with a final stage hook.
Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to force PCI devices to be page aligned")
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index 69d102cbf48f..d28ce0899487 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -1108,6 +1108,20 @@ static void pnv_p7ioc_rc_quirk(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_IBM, 0x3b9, pnv_p7ioc_rc_quirk);
+/* Fixup that disables PCI realignment menssages for all PCI devices */
+static void disable_realign_menssages(struct pci_dev *dev)
+{
+ dev->dev_flags |= PCI_DEV_FLAGS_QUIET_PCI_REALIGN;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_ANY_ID, PCI_ANY_ID, disable_realign_menssages);
+
+/* Fixup that enables PCI realignment messages for all PCI devices */
+static void enable_realign_menssages(struct pci_dev *dev)
+{
+ dev->dev_flags ^= PCI_DEV_FLAGS_QUIET_PCI_REALIGN;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, enable_realign_menssages);
+
void __init pnv_pci_init(void)
{
struct device_node *np;
--
2.14.3
^ permalink raw reply related
* Re: [RESEND PATCH] Input: joystick/analog - Use get_cycles() on PPC
From: Dmitry Torokhov @ 2018-03-14 16:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-input, linux-kernel, linuxppc-dev
In-Reply-To: <20180314111752.1748-1-mpe@ellerman.id.au>
On Wed, Mar 14, 2018 at 10:17:52PM +1100, Michael Ellerman wrote:
> The analog joystick driver spits a warning at us:
>
> drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer
> not defined for this architecture.
>
> PPC has get_cycles() so use that.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied, thank you.
> ---
> drivers/input/joystick/analog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> This is the third resend, I'll take it via the powerpc tree if no one else
> does.
>
> cheers
>
> diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
> index c868a878c84f..a942c4ccd2af 100644
> --- a/drivers/input/joystick/analog.c
> +++ b/drivers/input/joystick/analog.c
> @@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
> #define GET_TIME(x) do { x = (unsigned int)rdtsc(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "TSC"
> -#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_RISCV) || defined(CONFIG_TILE)
> +#elif defined(__alpha__) || defined(CONFIG_MN10300) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_PPC) || defined(CONFIG_RISCV) || defined(CONFIG_TILE)
> #define GET_TIME(x) do { x = get_cycles(); } while (0)
> #define DELTA(x,y) ((y)-(x))
> #define TIME_NAME "get_cycles"
> --
> 2.14.1
>
--
Dmitry
^ permalink raw reply
* [RFC] powerpc/xive: Remove irq from queue when it is shutdown
From: Frederic Barrat @ 2018-03-14 16:58 UTC (permalink / raw)
To: linuxppc-dev, benh, clg; +Cc: andrew.donnellan, vaibhav
If a driver has called free_irq() but an irq is waiting in a queue, an
error is logged when a cpu processes it:
irq 232, desc: 0000000044e5941a, depth: 1, count: 9823, unhandled: 0
->handle_irq(): 0000000023f2e352,
handle_bad_irq+0x0/0x2e0
->irq_data.chip(): 000000007fd7bf50,
no_irq_chip+0x0/0x110
->action(): (null)
IRQ_NOREQUEST set
unexpected IRQ trap at vector e8
In most cases, it's due to a driver bug or a misbehaving device, but
it can be observed with opencapi with no involvment of a device. AFU
interrupts are triggered by writing a special page of a process, but
it's possible for a thread of that process to write to that page as
well. If that process exits abruptly, the driver will free the AFU
interrupts resources, but there's no possible quiescing of the
process, so we may have interrupts in the queue.
This patch adds a scan of the queue when an interrupt is shutdown to
replace any pending irq with XIVE_BAD_IRQ, since those are ignored.
Also move when XIVE_BAD_IRQs are ignored closer to reading the queue,
so that we can reset the CPPR if it's the last interrupt in the queue.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
---
arch/powerpc/sysdev/xive/common.c | 69 ++++++++++++++++++++++++++++++++++++---
1 file changed, 65 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
index 3459015092fa..91047bc7c731 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -148,8 +148,16 @@ static u32 xive_scan_interrupts(struct xive_cpu *xc, bool just_peek)
prio = ffs(xc->pending_prio) - 1;
DBG_VERBOSE("scan_irq: trying prio %d\n", prio);
- /* Try to fetch */
- irq = xive_read_eq(&xc->queue[prio], just_peek);
+ /*
+ * Try to fetch.
+ * When not peeking, drop any BAD_IRQ on the floor
+ * now. If we let it reach get_irq() and it's the last
+ * one, then we'd need to rescan again to reset the
+ * CPPR
+ */
+ do {
+ irq = xive_read_eq(&xc->queue[prio], just_peek);
+ } while (irq == XIVE_BAD_IRQ && !just_peek);
/* Found something ? That's it */
if (irq)
@@ -282,8 +290,6 @@ static unsigned int xive_get_irq(void)
irq, xc->pending_prio);
/* Return pending interrupt if any */
- if (irq == XIVE_BAD_IRQ)
- return 0;
return irq;
}
@@ -592,6 +598,58 @@ static unsigned int xive_irq_startup(struct irq_data *d)
return 0;
}
+static void xive_remove_from_queue(unsigned int hw_irq, int cpu)
+{
+ struct xive_cpu *xc;
+ struct xive_q *q;
+ u32 irq = 0, cur, idx, toggle, prev;
+ u8 prio;
+ int count;
+
+ xc = per_cpu(xive_cpu, cpu);
+
+ /*
+ * Only one queue is really in use, but let's try stay generic, and
+ * check all of them
+ */
+ for (prio = 0; prio < XIVE_MAX_QUEUES; prio++) {
+ q = &xc->queue[prio];
+ if (!q->qpage)
+ continue;
+
+ /*
+ * We can't read a reliable index and toggle without
+ * locking, as another cpu can process an interrupt
+ * and read the queue at any given time. So use the
+ * toggle from the previous index, which should be ok
+ * as long as the queue doesn't overflow.
+ */
+ idx = q->idx;
+ prev = (idx - 1) & q->msk;
+ cur = be32_to_cpup(q->qpage + prev);
+ toggle = (cur >> 31) ^ 1;
+ count = 0;
+ do {
+ count++;
+ cur = be32_to_cpup(q->qpage + idx);
+ if ((cur >> 31) == toggle)
+ irq = 0;
+ else
+ irq = cur & 0x7fffffff;
+
+ if (irq == hw_irq) {
+ cur &= 1 << 31;
+ cur |= XIVE_BAD_IRQ;
+ *(q->qpage + idx) = cpu_to_be32(cur);
+ }
+
+ idx = (idx + 1) & q->msk;
+ if (idx == 0)
+ toggle ^= 1;
+ } while (irq && (count < q->msk));
+ }
+}
+
static void xive_irq_shutdown(struct irq_data *d)
{
struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
@@ -624,6 +682,9 @@ static void xive_irq_shutdown(struct irq_data *d)
get_hard_smp_processor_id(xd->target),
0xff, XIVE_BAD_IRQ);
+ /* configure_irq() syncs the queue */
+ xive_remove_from_queue(hw_irq, xd->target);
+
xive_dec_target_count(xd->target);
xd->target = XIVE_INVALID_TARGET;
}
--
2.14.1
^ permalink raw reply related
* [PATCH] powerpc/xive: Fix wrong xmon output caused by typo
From: Frederic Barrat @ 2018-03-14 17:01 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
---
arch/powerpc/sysdev/xive/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
index 40c06110821c..3459015092fa 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -246,7 +246,7 @@ notrace void xmon_xive_do_dump(int cpu)
u64 val = xive_esb_read(&xc->ipi_data, XIVE_ESB_GET);
xmon_printf(" IPI state: %x:%c%c\n", xc->hw_ipi,
val & XIVE_ESB_VAL_P ? 'P' : 'p',
- val & XIVE_ESB_VAL_P ? 'Q' : 'q');
+ val & XIVE_ESB_VAL_Q ? 'Q' : 'q');
}
#endif
}
--
2.14.1
^ permalink raw reply related
* Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
From: Ram Pai @ 2018-03-14 17:14 UTC (permalink / raw)
To: Dave Hansen
Cc: mingo, mpe, linuxppc-dev, linux-mm, x86, linux-arch, linux-kernel,
akpm, benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu,
mhocko, bauerman, ebiederm, corbet, arnd, fweimer, msuchanek
In-Reply-To: <18b155e3-07e9-5a4b-1f95-e1667078438c@intel.com>
On Wed, Mar 14, 2018 at 07:19:23AM -0700, Dave Hansen wrote:
> On 03/14/2018 12:46 AM, Ram Pai wrote:
> > Once an address range is associated with an allocated pkey, it cannot be
> > reverted back to key-0. There is no valid reason for the above behavior. On
> > the contrary applications need the ability to do so.
>
> I'm trying to remember why we cared in the first place. :)
>
> Could you add that to the changelog, please?
>
> > @@ -92,7 +92,8 @@ int mm_pkey_alloc(struct mm_struct *mm)
> > static inline
> > int mm_pkey_free(struct mm_struct *mm, int pkey)
> > {
> > - if (!mm_pkey_is_allocated(mm, pkey))
> > + /* pkey 0 is special and can never be freed */
> > + if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> > return -EINVAL;
>
> If an app was being really careful, couldn't it free up all of the
> implicitly-pkey-0-assigned memory so that it is not in use at all? In
> that case, we might want to allow this.
>
> On the other hand, nobody is likely to _ever_ actually do this so this
> is good shoot-yourself-in-the-foot protection.
I look at key-0 as 'the key'. It has special status.
(a) It always exist.
(b) it cannot be freed.
(c) it is assigned by default.
(d) its permissions cannot be modified.
(e) it bypasses key-permission checks when assigned.
An arch need not necessarily map 'the key-0' to its key-0. It could
internally map it to any of its internal key of its choice, transparent
to the application.
Do you see a problem to this view point?
RP
^ permalink raw reply
* Re: [PATCH 0/5] DPAA Ethernet fixes
From: David Miller @ 2018-03-14 17:17 UTC (permalink / raw)
To: madalin.bucur
Cc: netdev, linux-kernel, camelia.groza, leoyang.li, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20180314133732.24068-1-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Wed, 14 Mar 2018 08:37:27 -0500
> This patch set is addressing several issues in the DPAA Ethernet
> driver suite:
>
> - module unload crash caused by wrong reference to device being left
> in the cleanup code after the DSA related changes
> - scheduling wile atomic bug in QMan code revealed during dpaa_eth
> module unload
> - a couple of error counter fixes, a duplicated init in dpaa_eth.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Andy Shevchenko @ 2018-03-14 17:41 UTC (permalink / raw)
To: Desnes A. Nunes do Rosario
Cc: Linux Kernel Mailing List, linux-pci,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, Bjorn Helgaas,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, ruscur,
aik, david, fbarrat, brking
In-Reply-To: <20180314163455.15854-2-desnesn@linux.vnet.ibm.com>
On Wed, Mar 14, 2018 at 6:34 PM, Desnes A. Nunes do Rosario
<desnesn@linux.vnet.ibm.com> wrote:
> Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
> silent PCI realignment messages if the flag is turned on by a driver.
It doesn't explain "Why?"
Why the driver needs that?
Another approach is to increase level of the message. Would it be
accepted by you (in case Bjorn agrees)?
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -205,6 +205,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
> /* Don't use Relaxed Ordering for TLPs directed at this device */
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
> + /* Silent PCI resource realignment messages */
> + PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
I would rather name it _NO_PCI_REALIGN_MSG
> };
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Andy Shevchenko @ 2018-03-14 17:42 UTC (permalink / raw)
To: Desnes A. Nunes do Rosario
Cc: Linux Kernel Mailing List, linux-pci,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, Bjorn Helgaas,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, ruscur,
aik, david, fbarrat, brking
In-Reply-To: <CAHp75VdOaE-efzbQV=Mtf+a1-6L5JxF10Uc+uZ+LYz3S757biw@mail.gmail.com>
On Wed, Mar 14, 2018 at 7:41 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> I would rather name it _NO_PCI_REALIGN_MSG
I meant _NO_REALIGN_MSG of course (PCI is already at the beginning).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
From: Dave Hansen @ 2018-03-14 17:51 UTC (permalink / raw)
To: Ram Pai
Cc: mingo, mpe, linuxppc-dev, linux-mm, x86, linux-arch, linux-kernel,
akpm, benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu,
mhocko, bauerman, ebiederm, corbet, arnd, fweimer, msuchanek
In-Reply-To: <20180314171448.GA1060@ram.oc3035372033.ibm.com>
On 03/14/2018 10:14 AM, Ram Pai wrote:
> I look at key-0 as 'the key'. It has special status.
> (a) It always exist.
Do you mean "is always allocated"?
> (b) it cannot be freed.
This is the one I'm questioning.
> (c) it is assigned by default.
I agree on this totally. :)
> (d) its permissions cannot be modified.
Why not? You could pretty easily get a thread going that had its stack
covered with another pkey and that was being very careful what it
accesses. It could pretty easily set pkey-0's access or write-disable bits.
> (e) it bypasses key-permission checks when assigned.
I don't think this is necessary. I think the only rule we *need* is:
pkey-0 is allocated implicitly at execve() time. You do not
need to call pkey_alloc() to allocate it.
> An arch need not necessarily map 'the key-0' to its key-0. It could
> internally map it to any of its internal key of its choice, transparent
> to the application.
I don't understand what you are saying here.
^ permalink raw reply
* Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Bjorn Helgaas @ 2018-03-14 18:06 UTC (permalink / raw)
To: Desnes A. Nunes do Rosario
Cc: linux-kernel, linux-pci, linuxppc-dev, bhelgaas, benh, paulus,
mpe, ruscur, aik, david, fbarrat, brking
In-Reply-To: <20180314163455.15854-2-desnesn@linux.vnet.ibm.com>
On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote:
> Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
> silent PCI realignment messages if the flag is turned on by a driver.
>
> Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
> ---
> drivers/pci/pci.c | 3 ++-
> drivers/pci/setup-res.c | 3 ++-
> include/linux/pci.h | 2 ++
> 3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 8c71d1a66cdd..be197c944e5f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)
> return;
> }
>
> - pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> + pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
> pci_read_config_word(dev, PCI_COMMAND, &command);
> command &= ~PCI_COMMAND_MEMORY;
> pci_write_config_word(dev, PCI_COMMAND, command);
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 369d48d6c6f1..00a538def763 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
>
> void pci_disable_bridge_window(struct pci_dev *dev)
> {
> - pci_info(dev, "disabling bridge mem windows\n");
> + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> + pci_info(dev, "disabling bridge mem windows\n");
As far as I'm concerned, we can just remove these messages completely.
I don't think there's any real value there.
> /* MMIO Base/Limit */
> pci_write_config_dword(dev, PCI_MEMORY_BASE, 0x0000fff0);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e057e8cc63e7..993f9c7dcc00 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -205,6 +205,8 @@ enum pci_dev_flags {
> PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
> /* Don't use Relaxed Ordering for TLPs directed at this device */
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
> + /* Silent PCI resource realignment messages */
> + PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
> };
>
> enum pci_irq_reroute_variant {
> --
> 2.14.3
>
^ permalink raw reply
* Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Desnes Augusto Nunes do Rosário @ 2018-03-14 18:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linux Kernel Mailing List, linux-pci,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, Bjorn Helgaas,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman, ruscur,
aik, david, fbarrat, brking
In-Reply-To: <CAHp75VdOaE-efzbQV=Mtf+a1-6L5JxF10Uc+uZ+LYz3S757biw@mail.gmail.com>
Hello Andy,
On 03/14/2018 02:41 PM, Andy Shevchenko wrote:
> On Wed, Mar 14, 2018 at 6:34 PM, Desnes A. Nunes do Rosario
> <desnesn@linux.vnet.ibm.com> wrote:
>> Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
>> silent PCI realignment messages if the flag is turned on by a driver.
>
> It doesn't explain "Why?"
> Why the driver needs that?
I have written down the reason on the cover letter, but I concur on
creating a second version of the patch's comment. Basically, all PCI
resources on powerpc are printing out expected realignment messages
which are flooding the systems logs.
Perhaps this would be better?
---
"Some architectures such as powerpc has aligned all of its PCI resources
to its PAGE_SIZE during boot, thus the system logs will be flooded by
expected realignment messages, which can be interpreted as a false
positive for total PCI failure on the system.
[root@system user]# dmesg | grep -i disabling
[ 0.692270] pci 0000:00:00.0: Disabling memory decoding and releasing
memory resources
[ 0.692324] pci 0000:00:00.0: disabling bridge mem windows
[ 0.729134] pci 0001:00:00.0: Disabling memory decoding and releasing
memory resources
[ 0.737352] pci 0001:00:00.0: disabling bridge mem windows
[ 0.776295] pci 0002:00:00.0: Disabling memory decoding and releasing
memory resources
[ 0.784509] pci 0002:00:00.0: disabling bridge mem windows
... and goes on for all PCI devices ...
Thus, this patch adds PCI_DEV_FLAGS_NO_REALIGN_MSG to pci_dev_flags and
uses it to silent PCI realignment messages if the flag is turned on by a
driver.
"
---
>
> Another approach is to increase level of the message. Would it be
> accepted by you (in case Bjorn agrees)?
>
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -205,6 +205,8 @@ enum pci_dev_flags {
>> PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
>> /* Don't use Relaxed Ordering for TLPs directed at this device */
>> PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
>> + /* Silent PCI resource realignment messages */
>> + PCI_DEV_FLAGS_QUIET_PCI_REALIGN = (__force pci_dev_flags_t) (1 << 12),
>
> I would rather name it _NO_PCI_REALIGN_MSG
I concur on changing it to PCI_DEV_FLAGS_NO_REALIGN_MSG in a second
version of the patchset.
>
>> };
>
Thank you very much for your review,
--
Desnes A. Nunes do Rosário
^ permalink raw reply
* Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Desnes Augusto Nunes do Rosário @ 2018-03-14 18:22 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-kernel, linux-pci, linuxppc-dev, bhelgaas, benh, paulus,
mpe, ruscur, aik, david, fbarrat, brking
In-Reply-To: <20180314180642.GC179719@bhelgaas-glaptop.roam.corp.google.com>
Hello Bjorn,
On 03/14/2018 03:06 PM, Bjorn Helgaas wrote:
> On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote:
>> Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
>> silent PCI realignment messages if the flag is turned on by a driver.
>>
>> Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
>> ---
>> drivers/pci/pci.c | 3 ++-
>> drivers/pci/setup-res.c | 3 ++-
>> include/linux/pci.h | 2 ++
>> 3 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 8c71d1a66cdd..be197c944e5f 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)
>> return;
>> }
>>
>> - pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
>> + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
>> + pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
>> pci_read_config_word(dev, PCI_COMMAND, &command);
>> command &= ~PCI_COMMAND_MEMORY;
>> pci_write_config_word(dev, PCI_COMMAND, command);
>> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
>> index 369d48d6c6f1..00a538def763 100644
>> --- a/drivers/pci/setup-res.c
>> +++ b/drivers/pci/setup-res.c
>> @@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
>>
>> void pci_disable_bridge_window(struct pci_dev *dev)
>> {
>> - pci_info(dev, "disabling bridge mem windows\n");
>> + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
>> + pci_info(dev, "disabling bridge mem windows\n");
>
> As far as I'm concerned, we can just remove these messages completely.
> I don't think there's any real value there.
After I found out that this was happening to all PCI devices on powerpc
due to the __weak
pcibios_default_alignment() interface (necessary for VFIO passthrough
and performance), I confess that this was my first approach to this
matter; however I couldn't vouch the need of these messages on other
architectures.
If there are no further concerns, I definitely prefer sending a second
version of this patch only eliminating these messages and attesting the
reason why.
Thank you very much for your review Bjorn,
--
Desnes A. Nunes do Rosário
^ permalink raw reply
* Re: [PATCH 0/5] DPAA Ethernet fixes
From: Joakim Tjernlund @ 2018-03-14 18:43 UTC (permalink / raw)
To: davem@davemloft.net, madalin.bucur@nxp.com
Cc: linuxppc-dev@lists.ozlabs.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, leoyang.li@nxp.com,
camelia.groza@nxp.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20180314133732.24068-1-madalin.bucur@nxp.com>
T24gV2VkLCAyMDE4LTAzLTE0IGF0IDA4OjM3IC0wNTAwLCBNYWRhbGluIEJ1Y3VyIHdyb3RlOg0K
PiBIaSwNCj4gDQo+IFRoaXMgcGF0Y2ggc2V0IGlzIGFkZHJlc3Npbmcgc2V2ZXJhbCBpc3N1ZXMg
aW4gdGhlIERQQUEgRXRoZXJuZXQNCj4gZHJpdmVyIHN1aXRlOg0KPiANCj4gIC0gbW9kdWxlIHVu
bG9hZCBjcmFzaCBjYXVzZWQgYnkgd3JvbmcgcmVmZXJlbmNlIHRvIGRldmljZSBiZWluZyBsZWZ0
DQo+ICAgIGluIHRoZSBjbGVhbnVwIGNvZGUgYWZ0ZXIgdGhlIERTQSByZWxhdGVkIGNoYW5nZXMN
Cj4gIC0gc2NoZWR1bGluZyB3aWxlIGF0b21pYyBidWcgaW4gUU1hbiBjb2RlIHJldmVhbGVkIGR1
cmluZyBkcGFhX2V0aA0KPiAgICBtb2R1bGUgdW5sb2FkDQo+ICAtIGEgY291cGxlIG9mIGVycm9y
IGNvdW50ZXIgZml4ZXMsIGEgZHVwbGljYXRlZCBpbml0IGluIGRwYWFfZXRoLg0KDQpobW0sIHNv
bWUgb2YgdGhlc2UoYWxsPykgYnVncyBhcmUgaW4gc3RhYmxlIHRvbywgQ0M6IHN0YWJsZSBwZXJo
YXBzPyANCg0KPiANCj4gTWFkYWxpbg0KPiANCj4gQ2FtZWxpYSBHcm96YSAoMyk6DQo+ICAgZHBh
YV9ldGg6IHJlbW92ZSBkdXBsaWNhdGUgaW5pdGlhbGl6YXRpb24NCj4gICBkcGFhX2V0aDogaW5j
cmVtZW50IHRoZSBSWCBkcm9wcGVkIGNvdW50ZXIgd2hlbiBuZWVkZWQNCj4gICBkcGFhX2V0aDog
cmVtb3ZlIGR1cGxpY2F0ZSBpbmNyZW1lbnQgb2YgdGhlIHR4X2Vycm9ycyBjb3VudGVyDQo+IA0K
PiBNYWRhbGluIEJ1Y3VyICgyKToNCj4gICBzb2MvZnNsL3FibWFuOiBmaXggaXNzdWUgaW4gcW1h
bl9kZWxldGVfY2dyX3NhZmUoKQ0KPiAgIGRwYWFfZXRoOiBmaXggZXJyb3IgaW4gZHBhYV9yZW1v
dmUoKQ0KPiANCj4gIGRyaXZlcnMvbmV0L2V0aGVybmV0L2ZyZWVzY2FsZS9kcGFhL2RwYWFfZXRo
LmMgfCAgOCArKysrLS0tLQ0KPiAgZHJpdmVycy9zb2MvZnNsL3FibWFuL3FtYW4uYyAgICAgICAg
ICAgICAgICAgICB8IDI4ICsrKysrLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAyIGZpbGVzIGNo
YW5nZWQsIDkgaW5zZXJ0aW9ucygrKSwgMjcgZGVsZXRpb25zKC0pDQo+IA0KPiAtLQ0KPiAyLjEu
MA0KPiANCg==
^ permalink raw reply
* Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Bjorn Helgaas @ 2018-03-14 18:55 UTC (permalink / raw)
To: Desnes Augusto Nunes do Rosário
Cc: linux-kernel, linux-pci, linuxppc-dev, bhelgaas, benh, paulus,
mpe, ruscur, aik, david, fbarrat, brking
In-Reply-To: <30c63477-620b-3f8b-82df-fd1e34cd99b8@linux.vnet.ibm.com>
On Wed, Mar 14, 2018 at 03:22:44PM -0300, Desnes Augusto Nunes do Rosário wrote:
> Hello Bjorn,
>
> On 03/14/2018 03:06 PM, Bjorn Helgaas wrote:
> > On Wed, Mar 14, 2018 at 01:34:54PM -0300, Desnes A. Nunes do Rosario wrote:
> > > Add PCI_DEV_FLAGS_QUIET_PCI_REALIGN to pci_dev_flags and use it to
> > > silent PCI realignment messages if the flag is turned on by a driver.
> > >
> > > Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
> > > ---
> > > drivers/pci/pci.c | 3 ++-
> > > drivers/pci/setup-res.c | 3 ++-
> > > include/linux/pci.h | 2 ++
> > > 3 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index 8c71d1a66cdd..be197c944e5f 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -5505,7 +5505,8 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)
> > > return;
> > > }
> > > - pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
> > > + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> > > + pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
> > > pci_read_config_word(dev, PCI_COMMAND, &command);
> > > command &= ~PCI_COMMAND_MEMORY;
> > > pci_write_config_word(dev, PCI_COMMAND, command);
> > > diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> > > index 369d48d6c6f1..00a538def763 100644
> > > --- a/drivers/pci/setup-res.c
> > > +++ b/drivers/pci/setup-res.c
> > > @@ -172,7 +172,8 @@ EXPORT_SYMBOL(pci_claim_resource);
> > > void pci_disable_bridge_window(struct pci_dev *dev)
> > > {
> > > - pci_info(dev, "disabling bridge mem windows\n");
> > > + if (!(dev->dev_flags & PCI_DEV_FLAGS_QUIET_PCI_REALIGN))
> > > + pci_info(dev, "disabling bridge mem windows\n");
> >
> > As far as I'm concerned, we can just remove these messages completely.
> > I don't think there's any real value there.
>
> After I found out that this was happening to all PCI devices on powerpc due
> to the __weak
> pcibios_default_alignment() interface (necessary for VFIO passthrough and
> performance), I confess that this was my first approach to this matter;
> however I couldn't vouch the need of these messages on other architectures.
>
> If there are no further concerns, I definitely prefer sending a second
> version of this patch only eliminating these messages and attesting the
> reason why.
>
> Thank you very much for your review Bjorn,
No problem, welcome to PCI, and I hope we see more of your work!
^ permalink raw reply
* Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
From: Ram Pai @ 2018-03-14 18:54 UTC (permalink / raw)
To: Dave Hansen
Cc: mingo, mpe, linuxppc-dev, linux-mm, x86, linux-arch, linux-kernel,
akpm, benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu,
mhocko, bauerman, ebiederm, corbet, arnd, fweimer, msuchanek
In-Reply-To: <5027ca9e-63c8-47ab-960d-a9c4466d7075@intel.com>
On Wed, Mar 14, 2018 at 10:51:26AM -0700, Dave Hansen wrote:
> On 03/14/2018 10:14 AM, Ram Pai wrote:
> > I look at key-0 as 'the key'. It has special status.
> > (a) It always exist.
>
> Do you mean "is always allocated"?
always allocated and cannot be freed. Hence always exists.
If we let it freed, than yes 'it is always allocated', but
may not 'always exist'.
>
> > (b) it cannot be freed.
>
> This is the one I'm questioning.
this is a philosophical question. Should we allow the application
shoot-its-own-feet or help it from doing so. I tend to
gravitate towards the later.
>
> > (c) it is assigned by default.
>
> I agree on this totally. :)
good. we have some common ground :)
>
> > (d) its permissions cannot be modified.
>
> Why not? You could pretty easily get a thread going that had its stack
> covered with another pkey and that was being very careful what it
> accesses. It could pretty easily set pkey-0's access or write-disable bits.
ok. I see your point. Will not argue against it.
>
> > (e) it bypasses key-permission checks when assigned.
>
> I don't think this is necessary. I think the only rule we *need* is:
>
> pkey-0 is allocated implicitly at execve() time. You do not
> need to call pkey_alloc() to allocate it.
And can be explicitly associated with any address range ?
>
> > An arch need not necessarily map 'the key-0' to its key-0. It could
> > internally map it to any of its internal key of its choice, transparent
> > to the application.
>
> I don't understand what you are saying here.
I was trying to disassociate the notion that "application's key-0
means hardware's key-0". Nevermind. its not important for this
discussion.
--
Ram Pai
^ permalink raw reply
* Re: [PATCH 1/1 v2] x86: pkey-mprotect must allow pkey-0
From: Dave Hansen @ 2018-03-14 18:58 UTC (permalink / raw)
To: Ram Pai
Cc: mingo, mpe, linuxppc-dev, linux-mm, x86, linux-arch, linux-kernel,
akpm, benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu,
mhocko, bauerman, ebiederm, corbet, arnd, fweimer, msuchanek
In-Reply-To: <20180314185452.GB1060@ram.oc3035372033.ibm.com>
On 03/14/2018 11:54 AM, Ram Pai wrote:
>>> (e) it bypasses key-permission checks when assigned.
>> I don't think this is necessary. I think the only rule we *need* is:
>>
>> pkey-0 is allocated implicitly at execve() time. You do not
>> need to call pkey_alloc() to allocate it.
> And can be explicitly associated with any address range ?
Yes, it should ideally be available for use just like any other key when
allocated.
^ permalink raw reply
* Re: [GIT PULL] Please pull JSON files for POWR9 PMU events
From: Arnaldo Carvalho de Melo @ 2018-03-14 20:41 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: linuxppc-dev, linux-kernel, Ingo Molnar, Namhyung Kim, Jiri Olsa
In-Reply-To: <20180313224647.GA22960@us.ibm.com>
Em Tue, Mar 13, 2018 at 03:46:47PM -0700, Sukadev Bhattiprolu escreveu:
>
> Hi Arnaldo,
>
> Please pull an update to the JSON files for POWER9 PMU events.
Can you please be a bit more verbose in the next pull requets, something
like describing what is the nature of this specific pull request, say it
is to better support some specific measurements, etc, so that people
don't have to go and peruse the patches looking for what has changed.
If you could even show it being used and drawind some interesting
conclusion, even better. Or point to documentation describing it being
used, a blog post, whatever that clarifies these updates and encourages
potential users to try the perf tools with those events.
- Arnaldo
> The following changes since commit 90d2614c4d10c2f9d0ada9a3b01e5f43ca8d1ae3:
>
> perf test: Fix exit code for record+probe_libc_inet_pton.sh (2018-03-13 15:14:43 -0300)
>
> are available in the git repository at:
>
> https://github.com/sukadev/linux/ p9-json-v5
>
> for you to fetch changes up to 99c9dff949f2502964005f9afa8d60c89b446f2c:
>
> perf vendor events: Update POWER9 events (2018-03-13 16:48:12 -0500)
>
> ----------------------------------------------------------------
> Sukadev Bhattiprolu (1):
> perf vendor events: Update POWER9 events
>
> .../perf/pmu-events/arch/powerpc/power9/cache.json | 25 ---
> .../pmu-events/arch/powerpc/power9/frontend.json | 10 -
> .../pmu-events/arch/powerpc/power9/marked.json | 5 -
> .../pmu-events/arch/powerpc/power9/memory.json | 5 -
> .../perf/pmu-events/arch/powerpc/power9/other.json | 241 ++++++++++++++-------
> .../pmu-events/arch/powerpc/power9/pipeline.json | 50 ++---
> tools/perf/pmu-events/arch/powerpc/power9/pmc.json | 5 -
> .../arch/powerpc/power9/translation.json | 10 +-
> 8 files changed, 178 insertions(+), 173 deletions(-)
^ permalink raw reply
* Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h
From: Arnd Bergmann @ 2018-03-14 20:52 UTC (permalink / raw)
To: Deepa Dinamani
Cc: kbuild test robot, Mark Rutland,
open list:RALINK MIPS ARCHITECTURE, Peter Zijlstra,
Benjamin Herrenschmidt, Heiko Carstens, Paul Mackerras,
H. Peter Anvin, sparclinux, devel, linux-s390, y2038 Mailman List,
Michael Ellerman, Helge Deller, the arch/x86 maintainers, sebott,
James E.J. Bottomley, Christian Borntraeger, Ingo Molnar,
oprofile-list, Catalin Marinas, Peter Oberparleiter,
Robert Richter, Chris Metcalf, Will Deacon,
Arnaldo Carvalho de Melo, Julian Wiedmann, John Stultz,
Steven Rostedt, Thomas Gleixner, gerald.schaefer, Parisc List,
Greg KH, cohuck, Linux Kernel Mailing List, Ralf Baechle,
David S. Miller, Jan Hoeppner, kbuild-all, Stefan Haberland,
Martin Schwidefsky, linuxppc-dev, Ursula Braun
In-Reply-To: <CABeXuvqNKfuvffU24Xydixv6Ro8R=2nAH4bruzx0AW=ax-6yOQ@mail.gmail.com>
On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> The file arch/arm64/kernel/process.c needs asm/compat.h also to be
> included directly since this is included conditionally from
> include/compat.h. This does seem to be typical of arm64 as I was not
> completely able to get rid of asm/compat.h includes for arm64 in this
> series. My plan is to have separate patches to get rid of asm/compat.h
> includes for the architectures that are not straight forward to keep
> this series simple.
> I will fix this and update the series.
>
I ran across the same thing in two more files during randconfig testing on
arm64 now, adding this fixup on top for the moment, but maybe there
is a better way:
commit 4f3e9e1211799a79b201a1af309a1ec3864147ec
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Mar 14 18:23:16 2018 +0100
arm64: fix perf_regs.c
arch/arm64/kernel/perf_regs.c: In function 'perf_reg_abi':
arch/arm64/kernel/perf_regs.c:50:6: error: implicit declaration of
function 'is_compat_thread'; did you mean 'is_compat_task'?
[-Werror=implicit-function-declaration]
arch/arm64/kernel/hw_breakpoint.c: In function 'is_compat_bp':
arch/arm64/kernel/hw_breakpoint.c:182:16: error: implicit
declaration of function 'is_compat_thread'; did you mean
'is_compat_task'? [-Werror=implicit-function-declaration]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/arch/arm64/kernel/hw_breakpoint.c
b/arch/arm64/kernel/hw_breakpoint.c
index 413dbe530da8..74bb56f656ef 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -30,6 +30,7 @@
#include <linux/smp.h>
#include <linux/uaccess.h>
+#include <asm/compat.h>
#include <asm/current.h>
#include <asm/debug-monitors.h>
#include <asm/hw_breakpoint.h>
diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
index 0bbac612146e..1b463a4efe49 100644
--- a/arch/arm64/kernel/perf_regs.c
+++ b/arch/arm64/kernel/perf_regs.c
@@ -6,6 +6,7 @@
#include <linux/bug.h>
#include <linux/sched/task_stack.h>
+#include <asm/compat.h>
#include <asm/perf_regs.h>
#include <asm/ptrace.h>
^ permalink raw reply related
* [PATCH v3] x86: treat pkey-0 special
From: Ram Pai @ 2018-03-14 21:00 UTC (permalink / raw)
To: mingo
Cc: mpe, linuxppc-dev, linux-mm, x86, linux-arch, linux-kernel, akpm,
dave.hansen, benh, paulus, khandual, aneesh.kumar, bsingharora,
hbabu, mhocko, bauerman, ebiederm, linuxram, corbet, arnd,
fweimer, msuchanek, Ulrich.Weigand
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
This patch clarifies the semantics of pkey-0 and provides the
corresponding implementation on powerpc.
Pkey-0 is special with the following semantics.
(a) it is implicitly allocated and can never be freed. It always exists.
(b) it is the default key assigned to any address-range.
(c) it can be explicitly associated with any address-range.
Tested on x86_64.
History:
v3 : added clarification of the semantics of pkey0.
-- suggested by Dave Hansen
v2 : split the patch into two, one for x86 and one for powerpc
-- suggested by Michael Ellermen
cc: Dave Hansen <dave.hansen@intel.com>
cc: Michael Ellermen <mpe@ellerman.id.au>
cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
---
arch/x86/include/asm/pkeys.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index a0ba1ff..6ea7486 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm/pkeys.h
@@ -52,7 +52,7 @@ bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
* from pkey_alloc(). pkey 0 is special, and never
* returned from pkey_alloc().
*/
- if (pkey <= 0)
+ if (pkey < 0)
return false;
if (pkey >= arch_max_pkey())
return false;
@@ -92,7 +92,8 @@ int mm_pkey_alloc(struct mm_struct *mm)
static inline
int mm_pkey_free(struct mm_struct *mm, int pkey)
{
- if (!mm_pkey_is_allocated(mm, pkey))
+ /* pkey 0 is special and can never be freed */
+ if (!pkey || !mm_pkey_is_allocated(mm, pkey))
return -EINVAL;
mm_set_pkey_free(mm, pkey);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3] powerpc: treat pkey-0 special
From: Ram Pai @ 2018-03-14 21:01 UTC (permalink / raw)
To: mpe
Cc: linuxppc-dev, linux-mm, x86, linux-arch, linux-kernel, mingo,
akpm, dave.hansen, benh, paulus, khandual, aneesh.kumar,
bsingharora, hbabu, mhocko, bauerman, ebiederm, linuxram, corbet,
arnd, fweimer, msuchanek, Ulrich.Weigand
Applications need the ability to associate an address-range with some
key and latter revert to its initial default key. Pkey-0 comes close to
providing this function but falls short, because the current
implementation disallows applications to explicitly associate pkey-0 to
the address range.
This patch clarifies the semantics of pkey-0 and provides the
corresponding implementation on powerpc.
Pkey-0 is special with the following semantics.
(a) it is implicitly allocated and can never be freed. It always exists.
(b) it is the default key assigned to any address-range.
(c) it can be explicitly associated with any address-range.
Tested on powerpc.
History:
v3 : added clarification of the semantics of pkey0.
-- suggested by Dave Hansen
v2 : split the patch into two, one for x86 and one for powerpc
-- suggested by Michael Ellermen
cc: Dave Hansen <dave.hansen@intel.com>
cc: Michael Ellermen <mpe@ellerman.id.au>
cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
---
arch/powerpc/include/asm/pkeys.h | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 0409c80..3c1deec 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -101,10 +101,18 @@ static inline u16 pte_to_pkey_bits(u64 pteflags)
static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
{
- /* A reserved key is never considered as 'explicitly allocated' */
- return ((pkey < arch_max_pkey()) &&
- !__mm_pkey_is_reserved(pkey) &&
- __mm_pkey_is_allocated(mm, pkey));
+ /* pkey 0 is allocated by default. */
+ if (!pkey)
+ return true;
+
+ if (pkey < 0 || pkey >= arch_max_pkey())
+ return false;
+
+ /* Reserved keys are never allocated. */
+ if (__mm_pkey_is_reserved(pkey))
+ return false;
+
+ return __mm_pkey_is_allocated(mm, pkey);
}
extern void __arch_activate_pkey(int pkey);
@@ -150,7 +158,8 @@ static inline int mm_pkey_free(struct mm_struct *mm, int pkey)
if (static_branch_likely(&pkey_disabled))
return -1;
- if (!mm_pkey_is_allocated(mm, pkey))
+ /* pkey 0 cannot be freed */
+ if (!pkey || !mm_pkey_is_allocated(mm, pkey))
return -EINVAL;
/*
--
1.8.3.1
^ permalink raw reply related
* [PATCH, pci, v2] pci: Delete PCI disabling informational messages
From: Desnes A. Nunes do Rosario @ 2018-03-14 21:10 UTC (permalink / raw)
To: linux-kernel, linux-pci, linuxppc-dev; +Cc: bhelgaas, brking
The disabling informational messages on the PCI subsystem should be deleted
since they do not represent any real value for the system logs.
These messages are either not presented, or presented for all PCI devices
(e.g., powerpc now realigns all PCI devices to its page size). Thus, they
are flooding system logs and can be interpreted as a false positive for
total PCI failure on the system.
[root@system user]# dmesg | grep -i disabling
[ 0.692270] pci 0000:00:00.0: Disabling memory decoding and releasing memory resources
[ 0.692324] pci 0000:00:00.0: disabling bridge mem windows
[ 0.729134] pci 0001:00:00.0: Disabling memory decoding and releasing memory resources
[ 0.737352] pci 0001:00:00.0: disabling bridge mem windows
[ 0.776295] pci 0002:00:00.0: Disabling memory decoding and releasing memory resources
[ 0.784509] pci 0002:00:00.0: disabling bridge mem windows
... and goes on for all PCI devices on the system ...
Fixes: 38274637699 ("powerpc/powernv: Override pcibios_default_alignment() to force PCI devices to be page aligned")
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
---
drivers/pci/pci.c | 1 -
drivers/pci/setup-res.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8c71d1a66cdd..1563ce1ee091 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5505,7 +5505,6 @@ void pci_reassigndev_resource_alignment(struct pci_dev *dev)
return;
}
- pci_info(dev, "Disabling memory decoding and releasing memory resources\n");
pci_read_config_word(dev, PCI_COMMAND, &command);
command &= ~PCI_COMMAND_MEMORY;
pci_write_config_word(dev, PCI_COMMAND, command);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 369d48d6c6f1..6bd35e8e7cde 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -172,8 +172,6 @@ EXPORT_SYMBOL(pci_claim_resource);
void pci_disable_bridge_window(struct pci_dev *dev)
{
- pci_info(dev, "disabling bridge mem windows\n");
-
/* MMIO Base/Limit */
pci_write_config_dword(dev, PCI_MEMORY_BASE, 0x0000fff0);
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 1/2, pci] pci: Addition of PCI_DEV_FLAGS_QUIET_PCI_REALIGN attribute to the PCI subsystem
From: Desnes Augusto Nunes do Rosário @ 2018-03-14 21:12 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-kernel, linux-pci, linuxppc-dev, bhelgaas, benh, paulus,
mpe, ruscur, aik, david, fbarrat, brking
In-Reply-To: <20180314185508.GE179719@bhelgaas-glaptop.roam.corp.google.com>
On 03/14/2018 03:55 PM, Bjorn Helgaas wrote:
>>> As far as I'm concerned, we can just remove these messages completely.
>>> I don't think there's any real value there.
>>
>> After I found out that this was happening to all PCI devices on powerpc due
>> to the __weak
>> pcibios_default_alignment() interface (necessary for VFIO passthrough and
>> performance), I confess that this was my first approach to this matter;
>> however I couldn't vouch the need of these messages on other architectures.
>>
>> If there are no further concerns, I definitely prefer sending a second
>> version of this patch only eliminating these messages and attesting the
>> reason why.
>>
>> Thank you very much for your review Bjorn,
>
> No problem, welcome to PCI, and I hope we see more of your work!
Bjorn,
Awesome! A second version of this fix has been sent with a new title:
"[PATCH, pci, v2] pci: Delete PCI disabling informational messages"
Thanks for the review and warm welcome!
--
Desnes A. Nunes do Rosário
--------------------------
^ permalink raw reply
* Re: [PATCH] powerpc: Use common error handling code in setup_new_fdt()
From: Thiago Jung Bauermann @ 2018-03-14 21:22 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linuxppc-dev, Benjamin Herrenschmidt, Borislav Petkov,
Brijesh Singh, Josh Sklar, Kees Cook, Michael Ellerman,
Paul Mackerras, Thomas Gleixner, Tom Lendacky, LKML,
kernel-janitors
In-Reply-To: <0dd9d938-8d89-f0e0-f05f-9a3e5dc42a57@users.sourceforge.net>
SF Markus Elfring <elfring@users.sourceforge.net> writes:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sun, 11 Mar 2018 09:03:42 +0100
>
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> arch/powerpc/kernel/machine_kexec_file_64.c | 28 ++++++++++++----------------
> 1 file changed, 12 insertions(+), 16 deletions(-)
I liked it. Thanks!
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
--
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC] powerpc/xive: Remove irq from queue when it is shutdown
From: Cédric Le Goater @ 2018-03-14 17:47 UTC (permalink / raw)
To: Frederic Barrat, linuxppc-dev, benh; +Cc: andrew.donnellan, vaibhav
In-Reply-To: <20180314165808.26628-1-fbarrat@linux.vnet.ibm.com>
On 03/14/2018 05:58 PM, Frederic Barrat wrote:
> If a driver has called free_irq() but an irq is waiting in a queue, an
> error is logged when a cpu processes it:
>
> irq 232, desc: 0000000044e5941a, depth: 1, count: 9823, unhandled: 0
> ->handle_irq(): 0000000023f2e352,
> handle_bad_irq+0x0/0x2e0
> ->irq_data.chip(): 000000007fd7bf50,
> no_irq_chip+0x0/0x110
> ->action(): (null)
> IRQ_NOREQUEST set
> unexpected IRQ trap at vector e8
>
> In most cases, it's due to a driver bug or a misbehaving device, but
> it can be observed with opencapi with no involvment of a device. AFU
> interrupts are triggered by writing a special page of a process, but
> it's possible for a thread of that process to write to that page as
> well. If that process exits abruptly, the driver will free the AFU
> interrupts resources, but there's no possible quiescing of the
> process, so we may have interrupts in the queue.
>
> This patch adds a scan of the queue when an interrupt is shutdown to
> replace any pending irq with XIVE_BAD_IRQ, since those are ignored.
> Also move when XIVE_BAD_IRQs are ignored closer to reading the queue,
> so that we can reset the CPPR if it's the last interrupt in the queue.
We could also loop on the ESB 'P' bit to wait for the irqs to be handled,
using :
xive_esb_read(irq, XIVE_ESB_GET)
which has no side effect. It looks simpler to me. Is that possible ?
> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> ---
> arch/powerpc/sysdev/xive/common.c | 69 ++++++++++++++++++++++++++++++++++++---
> 1 file changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
> index 3459015092fa..91047bc7c731 100644
> --- a/arch/powerpc/sysdev/xive/common.c
> +++ b/arch/powerpc/sysdev/xive/common.c
> @@ -148,8 +148,16 @@ static u32 xive_scan_interrupts(struct xive_cpu *xc, bool just_peek)
> prio = ffs(xc->pending_prio) - 1;
> DBG_VERBOSE("scan_irq: trying prio %d\n", prio);
>
> - /* Try to fetch */
> - irq = xive_read_eq(&xc->queue[prio], just_peek);
> + /*
> + * Try to fetch.
> + * When not peeking, drop any BAD_IRQ on the floor
> + * now. If we let it reach get_irq() and it's the last
> + * one, then we'd need to rescan again to reset the
> + * CPPR
> + */
> + do {
> + irq = xive_read_eq(&xc->queue[prio], just_peek);
> + } while (irq == XIVE_BAD_IRQ && !just_peek);
>
> /* Found something ? That's it */
> if (irq)
> @@ -282,8 +290,6 @@ static unsigned int xive_get_irq(void)
> irq, xc->pending_prio);
>
> /* Return pending interrupt if any */
> - if (irq == XIVE_BAD_IRQ)
> - return 0;
> return irq;
> }
>
> @@ -592,6 +598,58 @@ static unsigned int xive_irq_startup(struct irq_data *d)
> return 0;
> }
>
> +static void xive_remove_from_queue(unsigned int hw_irq, int cpu)
> +{
> + struct xive_cpu *xc;
> + struct xive_q *q;
> + u32 irq = 0, cur, idx, toggle, prev;
> + u8 prio;
> + int count;
> +
> + xc = per_cpu(xive_cpu, cpu);
> +
> + /*
> + * Only one queue is really in use, but let's try stay generic, and
> + * check all of them
> + */
nevertheless, we could use some helper routines to manipulate
the xive queues. This is beginning to be cryptic.
> + for (prio = 0; prio < XIVE_MAX_QUEUES; prio++) {
> + q = &xc->queue[prio];
> + if (!q->qpage)
> + continue;
> +
> + /*
> + * We can't read a reliable index and toggle without
> + * locking, as another cpu can process an interrupt
> + * and read the queue at any given time. So use the
> + * toggle from the previous index, which should be ok
> + * as long as the queue doesn't overflow.
> + */
> + idx = q->idx;
> + prev = (idx - 1) & q->msk;
> + cur = be32_to_cpup(q->qpage + prev);
> + toggle = (cur >> 31) ^ 1;
> + count = 0;
> + do {
> + count++;
> + cur = be32_to_cpup(q->qpage + idx);
> + if ((cur >> 31) == toggle)
> + irq = 0;
> + else
> + irq = cur & 0x7fffffff;
> +
> + if (irq == hw_irq) {
> + cur &= 1 << 31;
> + cur |= XIVE_BAD_IRQ;
> + *(q->qpage + idx) = cpu_to_be32(cur);
Are we sure that the XIVE controller is not updating the queue at
the same time ?
Thanks,
C.
> + }
> +
> + idx = (idx + 1) & q->msk;
> + if (idx == 0)
> + toggle ^= 1;
> + } while (irq && (count < q->msk));
> + }
> +}
> +
> static void xive_irq_shutdown(struct irq_data *d)
> {
> struct xive_irq_data *xd = irq_data_get_irq_handler_data(d);
> @@ -624,6 +682,9 @@ static void xive_irq_shutdown(struct irq_data *d)
> get_hard_smp_processor_id(xd->target),
> 0xff, XIVE_BAD_IRQ);
>
> + /* configure_irq() syncs the queue */
> + xive_remove_from_queue(hw_irq, xd->target);
> +
> xive_dec_target_count(xd->target);
> xd->target = XIVE_INVALID_TARGET;
> }
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox