On Wed, 2017-07-12 at 11:37 +0530, Aneesh Kumar K.V wrote:
> > So we need to test those errors early in do_page_fault(),
> > I chose to generate a SIGBUS which is more correct than a SIGSEGV.
>
> This is true even for hash right ? If so do we want to update
> do_hash_page:
> #ifdef CONFIG_PPC_STD_
On Wed, 5 Jul 2017 14:21:52 -0700
Ram Pai wrote:
> Implements helper functions to read and write the key related
> registers; AMR, IAMR, UAMOR.
>
> AMR register tracks the read,write permission of a key
> IAMR register tracks the execute permission of a key
> UAMOR register enables and disables
While this driver expects to interact asynchronously, OPAL is well
within its rights to return OPAL_SUCCESS to indicate that the operation
completed without the need for a callback. We shouldn't treat
OPAL_SUCCESS as an error rather we should wrap up and return promptly to
the caller.
Signed-off-b
Signed-off-by: Cyril Bur
---
drivers/mtd/devices/powernv_flash.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mtd/devices/powernv_flash.c
b/drivers/mtd/devices/powernv_flash.c
index d50b5f200f73..d7243b72ba6e 100644
--- a/drivers/mtd/devices/power
This patch adds an _interruptible version of opal_async_wait_response().
This is useful when a long running OPAL call is performed on behalf of a
userspace thread, for example, the opal_flash_{read,write,erase}
functions performed by the powernv-flash MTD driver.
It is foreseeable that these funct
Future work will add an opal_async_wait_response_interruptible()
which will call wait_event_interruptible(). This work requires extra
token state to be tracked as wait_event_interruptible() can return and
the caller could release the token before OPAL responds.
Currently token state is tracked wit
The OPAL calls performed in this driver shouldn't be using
opal_async_wait_response() as this performs a wait_event() which, on
long running OPAL calls could result in hung task warnings. wait_event()
prevents timely signal delivery which is also undesirable.
This patch also attempts to quieten do
There are no callers of both __opal_async_get_token() and
__opal_async_release_token().
This patch also removes the possibility of "emergency through
synchronous call to __opal_async_get_token()" as such it makes more
sense to initialise opal_sync_sem for the maximum number of async
tokens.
Signe
V3: export opal_error_code() so that powernv_flash can be built=m
Hello,
Version one of this series ignored that OPAL may continue to use
buffers passed to it after Linux kfree()s the buffer. This version
addresses this, not in a particularly nice way - future work could
make this better. This ve
From: Stewart Smith
Parallel sensor reads could run out of async tokens due to
opal_get_sensor_data grabbing tokens but then doing the sensor
read behind a mutex, essentially serializing the (possibly
asynchronous and relatively slow) sensor read.
It turns out that the mutex isn't needed at all,
OPAL can only manage one flash access at a time and will return an
OPAL_BUSY error for each concurrent access to the flash. The simplest
way to prevent this from happening is with a mutex.
Signed-off-by: Cyril Bur
---
drivers/mtd/devices/powernv_flash.c | 18 +++---
1 file changed, 1
BUG_ON() should be reserved in situations where we can not longer
guarantee the integrity of the system. In the case where
powernv_flash_async_op() receives an impossible op, we can still
guarantee the integrity of the system.
Signed-off-by: Cyril Bur
---
drivers/mtd/devices/powernv_flash.c | 3
Also export opal_error_code() so that it can be used in modules
Signed-off-by: Cyril Bur
---
arch/powerpc/platforms/powernv/opal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index 59684b4af4d1..c4008a612473
On Wed, 5 Jul 2017 14:21:51 -0700
Ram Pai wrote:
> Initial plumbing to manage all the keys supported by the
> hardware.
>
> Total 32 keys are supported on powerpc. However pkey 0,1
> and 31 are reserved. So effectively we have 29 pkeys.
>
> This patch keeps track of reserved keys, allocated k
On POWER9 and bad paste instruction (targeting the wrong memory
type) or an invalid opcode in an AMO (atomic memory operation)
will result in specific DSISR bits to be set.
We currently don't understand those bits and thus just "hang"
the process taking constant page faults.
Additionally in the c
On Tue, 11 Jul 2017 08:44:15 -0700
Ram Pai wrote:
> On Tue, Jul 11, 2017 at 03:59:59PM +1000, Balbir Singh wrote:
> > On Wed, 5 Jul 2017 14:21:39 -0700
> > Ram Pai wrote:
> >
> > > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6
> > > in the 64K backed HPTE pages. This along with t
Hi Arnaldo,
Please pull the JSON files for POWER9 PMU events.
The following changes since commit 07d306c838c5c30196619baae36107d0615e459b:
Merge git://www.linux-watchdog.org/linux-watchdog (2017-07-11 09:59:37 -0700)
are available in the git repository at:
https://github.com/sukadev/linux/
On Tue, 2017-07-11 at 12:32 -0700, Ram Pai wrote:
> Ideally the MMU looks at the PTE for keys, in order to enforce
> protection. This is the case with x86 and is the case with power9 Radix
> page table. Hence the keys have to be programmed into the PTE.
POWER9 radix doesn't currently support keys.
On Wed, Jul 12, 2017 at 08:08:56AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > > On 07/05/2017 02:21 PM, Ram Pai
On 07/11/2017 03:14 PM, Ram Pai wrote:
> Now how many does the kernel use to reserve for itself is something
> the kernel knows too and hence can expose it, though the information
> may change dynamically as the kernel reserves and releases the key
> based on its internal needs.
>
> So i think we
On Tue, Jul 11, 2017 at 02:57:30PM -0700, Dave Hansen wrote:
> On 07/11/2017 02:51 PM, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> >> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> >>> On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently
On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > > Currently sys_pkey_create() provides the ability to disable read
On 07/11/2017 02:51 PM, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
>> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
>>> On 07/05/2017 02:21 PM, Ram Pai wrote:
Currently sys_pkey_create() provides the ability to disable read
and write p
On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > Currently sys_pkey_create() provides the ability to disable read
> > > and write permission on the key, at creation. powe
On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> On 07/05/2017 02:21 PM, Ram Pai wrote:
> > Currently sys_pkey_create() provides the ability to disable read
> > and write permission on the key, at creation. powerpc has the
> > hardware support to disable execute on a pkey as well.This pat
On Tue, Jul 11, 2017 at 04:52:46PM +0200, Michal Hocko wrote:
> On Wed 05-07-17 14:21:37, Ram Pai wrote:
> > Memory protection keys enable applications to protect its
> > address space from inadvertent access or corruption from
> > itself.
> >
> > The overall idea:
> >
> > A process allocates a
On 07/11/2017 02:28 AM, Arvind Yadav wrote:
> attribute_groups are not supposed to change at runtime. All functions
> working with attribute_groups provided by work
> with const attribute_group. So mark the non-const structs as const.
>
> File size before:
>text data bss dec
Hi Michal,
Thanks for the review..
On Monday 26 June 2017 05:45 PM, Michal Suchánek wrote:
Hello,
On Tue, 20 Jun 2017 21:14:08 +0530
Hari Bathini wrote:
On Friday 09 June 2017 05:34 PM, Michal Suchánek wrote:
On Thu, 8 Jun 2017 23:30:37 +0530
Hari Bathini wrote:
On Monday 15 May 2017 0
On 07/05/2017 02:22 PM, Ram Pai wrote:
> Add documentation updates that capture PowerPC specific changes.
>
> Signed-off-by: Ram Pai
> ---
> Documentation/vm/protection-keys.txt | 85
> ++
> 1 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/D
On 07/05/2017 02:21 PM, Ram Pai wrote:
> x86 does not support disabling execute permissions on a pkey.
>
> Signed-off-by: Ram Pai
> ---
> arch/x86/kernel/fpu/xstate.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/f
On 07/05/2017 02:22 PM, Ram Pai wrote:
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> +{
> + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> +}
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
This seems like k
On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently sys_pkey_create() provides the ability to disable read
> and write permission on the key, at creation. powerpc has the
> hardware support to disable execute on a pkey as well.This patch
> enhances the interface to let disable execute at key c
On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently there are only 4bits in the vma flags to support 16 keys
> on x86. powerpc supports 32 keys, which needs 5bits. This patch
> introduces an addition bit in the vma flags.
>
> Signed-off-by: Ram Pai
> ---
> fs/proc/task_mmu.c |6 +-
> inc
powerpc/numa: Correct the currently broken capability to set the
topology for shared CPUs in LPARs. At boot time for shared CPU
lpars, the topology for each shared CPU is set to node zero, however,
this is now updated correctly using the Virtual Processor Home Node
(VPHN) capabilities information
powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU
or memory resources, it may occur that the new resources are to be
inserted into nodes that were not used for these resources at bootup.
In the kernel, any node that is used must be defined and initialized
at boot. In order to
On Power systems with shared configurations of CPUs and memory, there
are some issues with association of additional CPUs and memory to nodes
when hot-adding resources. These patches address some of those problems.
powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU
or memory r
On 07/05/2017 02:22 PM, Ram Pai wrote:
> Abstracted out the arch specific code into the header file, and
> added powerpc specific changes.
>
> a) added 4k-backed hpte, memory allocator, powerpc specific.
> b) added three test case where the key is associated after the page is
> accessed/allo
On Mon, 10 Jul 2017 11:18:35 +0530
Mahesh Jagannath Salgaonkar wrote:
> On 07/06/2017 11:26 PM, Nicholas Piggin wrote:
> > On Wed, 5 Jul 2017 14:04:19 +1000
> > Nicholas Piggin wrote:
> > + /*
> > +* We reached here. There can be three possibilities:
> > +* 1. We are running on a fir
On Tue, Jul 11, 2017 at 03:59:59PM +1000, Balbir Singh wrote:
> On Wed, 5 Jul 2017 14:21:39 -0700
> Ram Pai wrote:
>
> > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6
> > in the 64K backed HPTE pages. This along with the earlier
> > patch will entirely free up the four bits from 64
On Wed 05-07-17 14:21:37, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.
>
> The overall idea:
>
> A process allocates a key and associates it with
> an address range withinits address
Sent: 11 July 2017 01:12
This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
because it doesn't copy anything from/to userspace to access the
argument.
Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl")
...
-#define TIOCGPTPEER_IOR('T', 0x41, int) /* Safely open the slave */
+#de
On 30 June 2017 at 13:53, Ivan Mikhaylov wrote:
> shdci-st driver can be used for ppc476 fsp2 soc.
>
> Signed-off-by: Ivan Mikhaylov
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/Kconfig |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/driv
From: Linuxppc-dev Gleb Fotengauer-Malinovskiy
> Sent: 11 July 2017 01:12
> This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
> because it doesn't copy anything from/to userspace to access the
> argument.
>
> Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl")
...
> -#define TIOCGPTPE
On Sat, 2017-07-08 at 12:45:32 UTC, Benjamin Herrenschmidt wrote:
> On radix, the process table entry we want to clear when
> destroying a context is entry 0, not entry 1
>
> Signed-off-by: Benjamin Herrenschmidt
> Reviewed-by: Aneesh Kumar K.V
Applied to powerpc fixes, thanks.
https://git.ker
On Fri, 2017-07-07 at 21:12:16 UTC, Benjamin Herrenschmidt wrote:
> When writing to the process table, we need to ensure the store is
> visible to a subsequent access by the MMU. We assume we never have
> the PID active while doing the update, so a ptesync/isync pair
> should hopefully be a big eno
On Thu, 2017-07-06 at 10:51:28 UTC, Nicholas Piggin wrote:
> There are two cases outside the normal address space management
> where a CPU's local TLB is to be flushed:
>
> 1. Host boot; in case something has left stale entries in the
> TLB (e.g., kexec).
>
> 2. Machine check; to clean c
On Thu, 2017-07-06 at 08:46:43 UTC, Oliver O'Halloran wrote:
> The workaround for the CELL timebase bug does not correctly mark cr0 as
> being clobbered. This can result in GCC making some poor^W completely
> broken optimisations.
>
> Signed-off-by: Oliver O'Halloran
Applied to powerpc fixes, th
On Fri, 2017-06-30 at 22:37:32 UTC, Michael Neuling wrote:
> From: Benjamin Herrenschmidt
>
> That will allow OPAL to configure the CPU in an optimal way.
>
> Signed-off-by: Benjamin Herrenschmidt
> Signed-off-by: Michael Neuling
Applied to powerpc fixes, thanks.
https://git.kernel.org/power
On Thu, 2017-06-29 at 11:57:26 UTC, Balbir Singh wrote:
> This patch fixes a crash seen while doing a kexec from
> radix mode to hash mode. Key 0 is special in hash and
> used in the RPN by default, we set the key values to 0
> today. In radix mode key 0 is used to control
> supervisor<->user acces
Although it's not documented anywhere, there is an expectation that
atomic64_inc_not_zero() returns a result which fits in an int. This is
the behaviour implemented on all arches except powerpc.
This has caused at least one bug in practice, in the percpu-refcount
code, where the long result from o
In commit e6f81a92015b ("powerpc/mm/hash: Support 68 bit VA") the
masking is folded into ASM_VSID_SCRAMBLE but the comment about masking
is removed only from the firt use of ASM_VSID_SCRAMBLE.
Signed-off-by: Michal Suchanek
---
arch/powerpc/mm/slb_low.S | 4
1 file changed, 4 deletions(-)
On 07/10/2017 11:25 AM, Ram Pai wrote:
> On Mon, Jul 10, 2017 at 08:41:30AM +0530, Anshuman Khandual wrote:
>> On 07/06/2017 02:52 AM, Ram Pai wrote:
>>> get_pte_pkey() helper returns the pkey associated with
>>> a address corresponding to a given mm_struct.
>>>
>>> Signed-off-by: Ram Pai
>>> ---
Incase of continous sampling, code currently defaults
MMCRA[SDAR_MODE] to 0b01 for power9 DD1 which is
'Continous sampling mode update SDAR on TLB miss'.
And for the rest it copies the sdar_mode value from
the event code, which mostly turns out to be 0b00
('No Updates').
Instead, fix the sdar_mode
On Tue, Jul 11, 2017 at 03:12:17AM +0300, Gleb Fotengauer-Malinovskiy wrote:
> This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
> because it doesn't copy anything from/to userspace to access the
> argument.
>
> Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl")
I think its recommend
Hi Matt,
> Currently ppc_md.get_random_seed uses the powernv_get_random_long function.
> A guest calling this function would have to go through the hypervisor. The
> 'darn' instruction, introduced in POWER9, allows us to bypass this by
> directly obtaining a value from the mmio region.
>
> This pa
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
File size before:
textdata bss dec hex filename
418 160 8 586 24a drive
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by work
with const attribute_group. So mark the non-const structs as const.
Arvind Yadav (3):
[PATCH 1/3] PCI: pci-sysfs: constify attribute_group structures.
[PATCH 2/3] PCI: pci-labe
On Mon, Jul 10, 2017 at 9:38 PM, Oliver wrote:
> On Tue, Jul 11, 2017 at 9:53 AM, Dan Williams
> wrote:
>> On Tue, Jun 27, 2017 at 3:28 AM, Oliver O'Halloran wrote:
>>> struct device contains the ->of_node pointer so that devices can be
>>> assoicated with the device-tree node that created them
On Tue, Jul 11, 2017 at 2:12 AM, Gleb Fotengauer-Malinovskiy
wrote:
> This ioctl does nothing to justify an _IOC_READ or _IOC_WRITE flag
> because it doesn't copy anything from/to userspace to access the
> argument.
>
> Fixes: 54ebbfb1 ("tty: add TIOCGPTPEER ioctl")
> Signed-off-by: Gleb Fotengaue
59 matches
Mail list logo
