On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
> > On 3/26/2018 5:30 PM, Arnd Bergmann wrote:
> > > > But that was never a requirement of writel(),
> > > > Documentation/memory-barriers.txt gives an explicit example dem
On Mon, 2018-03-26 at 18:08 -0400, Sinan Kaya wrote:
> On 3/26/2018 6:01 PM, Benjamin Herrenschmidt wrote:
> > On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote:
> > > On 3/26/2018 5:30 PM, Arnd Bergmann wrote:
> > > > > But that was never a requirement of writel(),
> > > > > Documentation/memory
"Naveen N. Rao" writes:
> If function_graph tracer is enabled during kexec, we see the below
> exception in the simulator:
> root@(none):/# kexec -e
> kvm: exiting hardware virtualization
> kexec_core: Starting new kernel
> [ 19.262020070,5] OPAL: Switch to big-endian OS
Michael Ellerman writes:
> "Naveen N. Rao" writes:
>> If function_graph tracer is enabled during kexec, we see the below
>> exception in the simulator:
>> root@(none):/# kexec -e
>> kvm: exiting hardware virtualization
>> kexec_core: Starting new kernel
>> [ 19.262020070,5]
On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote:
> > Otherwise almost all drivers out there are broken which I very much
> > doubt :-)
>
> But.. Sinan is right, you look anywhere in the driver tree and you
> find stuff like this:
>
> drivers/net/ethernet/intel/i40e/i40e_txrx.c
>
>
On Tue, 2018-03-27 at 09:36 +1100, Benjamin Herrenschmidt wrote:
> I don't kow, it used to be the case, at least that's what drove us to
> define things the way we did.
>
> Maybe things changed, but if that's the case, nobody knows for sure,
> and we probably want to get Linus POV on the matter.
>
On Tue, Mar 27, 2018 at 09:36:11AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote:
> > > Otherwise almost all drivers out there are broken which I very much
> > > doubt :-)
> >
> > But.. Sinan is right, you look anywhere in the driver tree and you
>
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/powerpc/include/asm/cputable.h
arch/powerpc/kernel/dt_cpu_ftrs.c
between commit:
a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9")
from the powerpc-fixes tree and commits:
9bbf0b576d3
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.
Lets
On Mon, 2018-03-26 at 16:50 -0600, Jason Gunthorpe wrote:
> On Tue, Mar 27, 2018 at 09:36:11AM +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote:
> > > > Otherwise almost all drivers out there are broken which I very much
> > > > doubt :-)
> > >
> >
On Sun, Mar 25, 2018 at 8:44 PM, John Paul Adrian Glaubitz
wrote:
<
> FWIW, we are maintaining an x32 port in Debian and there are some people
> actually using it [1]. There is one build instance running on VMWare that
> I am hosting [2] and around 10800 out of 12900 source packages build fine
> o
On Mon, Mar 26, 2018 at 04:31:41PM -0700, Ram Pai wrote:
> 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 applic
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.
Lets
When mprotect(,PROT_EXEC) is called, the kernel allocates a
execute-only pkey and associates the pkey with the given address space.
The permission of this key should not be modifiable from userspace.
However a bug in the current implementation lets the permissions on the
key modifiable from use
On Tue, Mar 27, 2018 at 10:59:40AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2018-03-26 at 16:50 -0600, Jason Gunthorpe wrote:
> > On Tue, Mar 27, 2018 at 09:36:11AM +1100, Benjamin Herrenschmidt wrote:
> > > On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote:
> > > > > Otherwise almost
thread_pkey_regs_init() initializes the pkey related registers
instead of initializing the fields in the task structures. Fortunately
those key related registers are re-set to zero when the task
gets scheduled on the cpu. However its good to fix this glaringly
visible error.
cc: Michael Ellermen
On 03/27/2018 10:03 AM, Linus Torvalds wrote:
> Hmm. Do you have a few statically built binaries that could be tested
> without installing a whole distribution? Something real and meaningful
> enough that it actually exercised a few real system calls, but not
> something that needs to bring in 50 d
On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
wrote:
>
> What about a tarball with a minimal Debian x32 chroot? Then you can
> install interesting packages you would like to test yourself.
That probably works fine.
Linus
Ram Pai writes:
> On Fri, Mar 16, 2018 at 10:02:22PM +1100, Balbir Singh wrote:
>> On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai wrote:
>> > 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
>> > providin
On Mon, Mar 26, 2018 at 02:44:48PM -0700, David Rientjes wrote:
> On Tue, 13 Mar 2018, Laurent Dufour wrote:
>
> > Add support for the new speculative faults event.
> >
> > Signed-off-by: Laurent Dufour
>
> Acked-by: David Rientjes
>
> Aside: should there be a new spec_flt field for struct ta
On Tue, Mar 27, 2018 at 1:36 PM, Ram Pai wrote:
> thread_pkey_regs_init() initializes the pkey related registers
> instead of initializing the fields in the task structures. Fortunately
> those key related registers are re-set to zero when the task
> gets scheduled on the cpu. However its good to
On Tue, Mar 27, 2018 at 2:48 PM, Michael Ellerman wrote:
> Ram Pai writes:
>
>> On Fri, Mar 16, 2018 at 10:02:22PM +1100, Balbir Singh wrote:
>>> On Fri, Mar 16, 2018 at 9:33 PM, Ram Pai wrote:
>>> > Applications need the ability to associate an address-range with some
>>> > key and latter rever
We've had dynamic ftrace support for over 9 years since Steve first
wrote it, all the distros use dynamic, and static is basically
untested these days, so drop support for static ftrace.
Signed-off-by: Michael Ellerman
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/inclu
Add ppc_breakpoint_available() to determine if a breakpoint is
available currently via the DAWR or DABR.
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/debug.h | 1 +
arch/powerpc/kernel/process.c| 12
2 files changed, 13 insertions(+)
diff --git a/arch/powerpc/in
Return H_P2 on a h_set_mode(SET_DAWR) on POWER9 where the DAWR is
disabled.
Current Linux guests ignore this error, so they will silently not get
the DAWR (sigh). The same error code is being used by POWERVM in this
case.
Signed-off-by: Michael Neuling
---
arch/powerpc/kvm/book3s_hv.c | 2 ++
1
Using the DAWR on POWER9 can cause xstops, hence we need to disable
it.
The current CPU_FTR for DAWR is a bit messy. Despite having
CPU_FTR_DAWR, currently we assume DAWR exists in the KVM code based on
CPU_FTR_ARCH_207. In other places we assume DAWR exists if
CPU_FTR_DAWR is set.
This attempts
This updates the ptrace code to use ppc_breakpoint_available().
We now advertise via PPC_PTRACE_GETHWDBGINFO zero breakpoints when the
DAWR is missing (ie. POWER9). This results in GDB falling back to
software emulation of the breakpoint (which is slow).
For the features advertised by PPC_PTRACE_
The 'bd' command will now print an error and not set the breakpoint on
P9.
Signed-off-by: Michael Neuling
---
arch/powerpc/xmon/xmon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index a06cf6e389..047a682c6d 100644
--- a/arch/power
POWER7 compat mode guests can use h_set_dabr on POWER9. POWER9 should
use the DAWR but since it's disabled there we can't.
This returns H_UNSUPPORTED on a h_set_dabr() on POWER9 where the DAWR
is disabled.
Current Linux guests ignore this error, so they will silently not get
the DAWR (sigh). The
POWER9 with the DAWR disabled causes problems for partition
migration. Either we have to fail the migration (since we lose the
DAWR) or we silently drop the DAWR and allow the migration to pass.
This patch does the latter and allows the migration to pass (at the
cost of silently losing the DAWR).
This disables the DAWR on all POWER9 CPUs via cpu feature quirk.
Using the DAWR on POWER9 can cause xstops, hence we need to disable
it.
Signed-off-by: Michael Neuling
---
arch/powerpc/kernel/dt_cpu_ftrs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
Using the DAWR on POWER9 can cause xstops, hence we need to disable
it.
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/cputable.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
> arch/powerpc/include/asm/cputable.h
> arch/powerpc/kernel/dt_cpu_ftrs.c
>
> between commit:
>
> a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on POWER9")
>
> from the
On 03/27/2018 12:40 PM, Linus Torvalds wrote:
> On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
> wrote:
>>
>> What about a tarball with a minimal Debian x32 chroot? Then you can
>> install interesting packages you would like to test yourself.
>
> That probably works fine.
I just crea
On 03/26/2018 01:28 PM, Joe Perches wrote:
drivers/hwmon is the most frequent user of symbolic permissions
like S_IRUGO in the kernel tree.
$ git grep -w -P "S_[A-Z]{5,5}" | \
cut -f1 -d: | cut -f1-2 -d"/" | sed -r 's/[A-Za-z0-9_-]+\.[ch]$//' | \
sort | uniq -c | sort -rn | head
3862 d
On Mon, 2018-03-26 at 23:33 -0700, Guenter Roeck wrote:
> On 03/26/2018 01:28 PM, Joe Perches wrote:
> > drivers/hwmon is the most frequent user of symbolic permissions
> > like S_IRUGO in the kernel tree.
[]
> I have something similar using coccinelle,
Please post the script.
I expect it doesn't
Michael Ellerman wrote:
Michael Ellerman writes:
"Naveen N. Rao" writes:
If function_graph tracer is enabled during kexec, we see the below
exception in the simulator:
root@(none):/# kexec -e
kvm: exiting hardware virtualization
kexec_core: Starting new kernel
101 - 137 of 137 matches
Mail list logo
