hardware architecture and userspace API is provided in
subsequent patches.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
drivers/misc/cxl/context.c | 169
drivers/misc/cxl/cxl-pci.c | 977
From: Ian Munsie imun...@au1.ibm.com
Some of the MSI IRQ code in pnv_pci_ioda_msi_setup() is generically useful so
split it out.
This will be used by some of the cxl PCIe code later.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc
-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/mm/Makefile | 1 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/cxl/Kconfig | 7
drivers/misc/cxl/Makefile | 1 +
drivers/misc/cxl/base.c | 102 ++
6 files
From: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/mm/hash_utils_64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index
-off-by: Michael Neuling mi...@neuling.org
---
include/uapi/Kbuild | 1 +
include/uapi/misc/Kbuild | 2 ++
include/uapi/misc/cxl.h | 88
3 files changed, 91 insertions(+)
create mode 100644 include/uapi/misc/Kbuild
create mode 100644 include
-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/mm/hash_native_64.c | 6 +-
arch/powerpc/mm/hash_utils_64.c | 3 +++
arch/powerpc/mm/slice.c | 3 +++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm
this wastage.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/sysdev/msi_bitmap.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
From: Ian Munsie imun...@au1.ibm.com
This adds a number of functions for allocating IRQs under powernv PCIe for cxl.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm/pnv-pci.h| 27 +
arch/powerpc/platforms
process.
We need to be careful here as the current hash_page() assumes current in a few
places.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm/mmu-hash64.h | 1 +
arch/powerpc/mm/hash_utils_64.c | 20
.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm/mmu-hash64.h | 2 ++
arch/powerpc/mm/copro_fault.c | 48 ++
arch/powerpc/mm/slb.c | 3 ---
arch/powerpc
Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm/copro.h | 18 ++
arch/powerpc/include/asm/spu.h | 5 ++---
arch/powerpc/mm/Makefile | 1
From: Ian Munsie imun...@au1.ibm.com
This adds the OPAL call to change a PHB into cxl mode.
Signed-off-by: Ian Munsie imun...@au1.ibm.com
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm/opal.h| 2 ++
arch/powerpc/platforms/powernv/opal-wrappers.S
On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote:
> On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
> > The Debian powerpc little endian architecture is called ppc64le. This
>
> Huh? ppc64le or ppc64el?
ppc64el. Commit message is wrong. Fixed below
On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote:
On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
The Debian powerpc little endian architecture is called ppc64le. This
Huh? ppc64le or ppc64el?
ppc64el. Commit message is wrong. Fixed below.
Mikey
From: Michael
The Debian powerpc little endian architecture is called ppc64le. This
is the default architecture used by Ubuntu for powerpc.
The below checks the kernel config to see if we are compiling little
endian and sets the Debian arch appropriately.
Signed-off-by: Michael Neuling
diff --git a/scripts
The Debian powerpc little endian architecture is called ppc64le. This
is the default architecture used by Ubuntu for powerpc.
The below checks the kernel config to see if we are compiling little
endian and sets the Debian arch appropriately.
Signed-off-by: Michael Neuling mi...@neuling.org
left the behaviour of that
> > code unchanged.
>
> Mikey, does that stuff work as expected?
Sorry for the slow response. v1 and v2 both pass testing on POWER7. So
FWIW...
Acked-By: Michael Neuling
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
,
in that groups with below average load average are ignored, but I
have no hardware to test that so I have left the behaviour of that
code unchanged.
Mikey, does that stuff work as expected?
Sorry for the slow response. v1 and v2 both pass testing on POWER7. So
FWIW...
Acked-By: Michael Neuling mi
On Tue, 2014-07-01 at 10:52 +1000, Michael Ellerman wrote:
> On Mon, 2014-06-30 at 11:54 +0530, Preeti U Murthy wrote:
> > Commit 8d6f7c5a: "powerpc/powernv: Make it possible to skip the IRQHAPPENED
> > check in power7_nap()" added code that prevents even cores which enter sleep
> > on idle, from
is.
>
> Signed-off-by: Preeti U Murthy
Acked-by: Michael Neuling
> ---
>
> arch/powerpc/kernel/idle_power7.S |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/idle_power7.S
> b/arch/powerpc/kernel/idle_power7.S
> index 24
Murthy pre...@linux.vnet.ibm.com
Acked-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/kernel/idle_power7.S |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/idle_power7.S
b/arch/powerpc/kernel/idle_power7.S
index 2480256..5cf3d36 100644
On Tue, 2014-07-01 at 10:52 +1000, Michael Ellerman wrote:
On Mon, 2014-06-30 at 11:54 +0530, Preeti U Murthy wrote:
Commit 8d6f7c5a: powerpc/powernv: Make it possible to skip the IRQHAPPENED
check in power7_nap() added code that prevents even cores which enter sleep
on idle, from checking
On Mon, 2014-06-02 at 14:59 +0200, Stephane Eranian wrote:
> On Wed, May 28, 2014 at 10:04 AM, Anshuman Khandual
> wrote:
> > On 05/27/2014 05:39 PM, Stephane Eranian wrote:
> >> I have been looking at those patches and ran some tests.
> >> And I found a few issues so far.
> >>
> >> I am running:
On Mon, 2014-06-02 at 14:59 +0200, Stephane Eranian wrote:
On Wed, May 28, 2014 at 10:04 AM, Anshuman Khandual
khand...@linux.vnet.ibm.com wrote:
On 05/27/2014 05:39 PM, Stephane Eranian wrote:
I have been looking at those patches and ran some tests.
And I found a few issues so far.
I
> So in sum, it very much looks like the intention is for
> PTRACE_GETREGSET/PTRACE_SETREGSET to return ENODEV in the
> case the regset doesn't exist on the running machine, and then
> it looks like at least x86 works that way.
Good point... agreed. We should ENODEV when we don't have TM
So in sum, it very much looks like the intention is for
PTRACE_GETREGSET/PTRACE_SETREGSET to return ENODEV in the
case the regset doesn't exist on the running machine, and then
it looks like at least x86 works that way.
Good point... agreed. We should ENODEV when we don't have TM hardware
On Tue, 2014-05-13 at 00:12 -0700, Cody P Schafer wrote:
> On 05/12/2014 11:23 PM, Michael Neuling wrote:
> >> powerpc/pseries: relocate "config DTL" so KConfig nests properly
> >
> > I don't know what that means. Can you describe it in more detail?
&
> powerpc/pseries: relocate "config DTL" so KConfig nests properly
I don't know what that means. Can you describe it in more detail?
Mikey
On Mon, 2014-05-12 at 20:09 -0700, Cody P Schafer wrote:
> Signed-off-by: Cody P Schafer
> ---
> arch/powerpc/platforms/pseries/Kconfig | 20
powerpc/pseries: relocate config DTL so KConfig nests properly
I don't know what that means. Can you describe it in more detail?
Mikey
On Mon, 2014-05-12 at 20:09 -0700, Cody P Schafer wrote:
Signed-off-by: Cody P Schafer c...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/Kconfig
On Tue, 2014-05-13 at 00:12 -0700, Cody P Schafer wrote:
On 05/12/2014 11:23 PM, Michael Neuling wrote:
powerpc/pseries: relocate config DTL so KConfig nests properly
I don't know what that means. Can you describe it in more detail?
So the config DTL refers to the configuration entry
Anshuman Khandual wrote:
> On 04/29/2014 01:52 PM, Michael Neuling wrote:
> > That's not what that patch does. It shouldn't make any user visible changes
> > to DSCR or PPR.
>
> It may not when it runs uninterrupted but after the tracee process has
> stopped, thread.d
Anshuman Khandual khand...@linux.vnet.ibm.com wrote:
On 04/29/2014 01:52 PM, Michael Neuling wrote:
That's not what that patch does. It shouldn't make any user visible changes
to DSCR or PPR.
It may not when it runs uninterrupted but after the tracee process has
stopped, thread.dscr
Anshuman Khandual wrote:
> This patch adds few more ptrace request macros expanding
> the existing capability. These ptrace requests macros can
> be classified into two categories.
Why is this only an RFC?
Also, please share the test case that you wrote for this.
Mikey
>
> (1)
Anshuman Khandual khand...@linux.vnet.ibm.com wrote:
This patch adds few more ptrace request macros expanding
the existing capability. These ptrace requests macros can
be classified into two categories.
Why is this only an RFC?
Also, please share the test case that you wrote for this.
Mikey
> Please cc the guilty parties when sending patches like this.
Crud, sorry about that.
Can we add a comment at the end of include/linux/auxvec.h that says you
need to update this? Then plebs like me are less likely to miss it in
future.
Mikey
> Also, just out of interest, please describe how
Please cc the guilty parties when sending patches like this.
Crud, sorry about that.
Can we add a comment at the end of include/linux/auxvec.h that says you
need to update this? Then plebs like me are less likely to miss it in
future.
Mikey
Also, just out of interest, please describe how
short of introducing more
> conditional barrier primitives this is the best we can do.
>
> Cc: Mathieu Desnoyers
> Cc: mich...@ellerman.id.au
> Cc: Paul McKenney
> Cc: Michael Neuling
> Cc: Frederic Weisbecker
> Cc: an...@samba.org
> Cc: b...@kernel.crashing.
mathieu.desnoy...@polymtl.ca
Cc: mich...@ellerman.id.au
Cc: Paul McKenney paul...@linux.vnet.ibm.com
Cc: Michael Neuling mi...@neuling.org
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: an...@samba.org
Cc: b...@kernel.crashing.org
Reported-by: Victor Kaplansky vict...@il.ibm.com
Tested
> I would argue for:
>
> READ ->data_tailREAD ->data_head
> smp_rmb() (A) smp_rmb() (C)
> WRITE $data READ $data
> smp_wmb() (B) smp_mb()(D)
> STORE ->data_head WRITE
I would argue for:
READ -data_tailREAD -data_head
smp_rmb() (A) smp_rmb() (C)
WRITE $data READ $data
smp_wmb() (B) smp_mb()(D)
STORE -data_head WRITE -data_tail
Frederic,
In the perf ring buffer code we have this in perf_output_get_handle():
if (!local_dec_and_test(>nest))
goto out;
/*
* Publish the known good head. Rely on the full barrier implied
* by atomic_dec_and_test() order the rb->head read and
Frederic,
In the perf ring buffer code we have this in perf_output_get_handle():
if (!local_dec_and_test(rb-nest))
goto out;
/*
* Publish the known good head. Rely on the full barrier implied
* by atomic_dec_and_test() order the rb-head read and
of checking if the domain has an idle cpu,
> because cpumask_first_and() will not yield any set bits if this domain
> has no idle cpu.
>
> Hence, nr_busy check against group weight can be removed.
>
> Reported-by: Michael Neuling
Tested-by: Michael Neuling
Peter, I tested t
an idle cpu,
because cpumask_first_and() will not yield any set bits if this domain
has no idle cpu.
Hence, nr_busy check against group weight can be removed.
Reported-by: Michael Neuling michael.neul...@au1.ibm.com
Tested-by: Michael Neuling mi...@neuling.org
Peter, I tested this only a brief
>> Well we don't have to, I think Mikey wasn't totally clear about that
>> "making all registers volatile" business :-) This is just something we
>> need to handle in assembly if we are going to reclaim the suspended
>> transaction.
Yeah, sorry. The slow path with all registers as volatile is
Ben,
> On Mon, 2013-09-30 at 12:29 -0700, Linus Torvalds wrote:
> >
> > But I'm cc'ing the POWER people, because I don't know the POWER8
> > interfaces, and I don't want to necessarily call this "xbegin"/"xend"
> > when I actually wrap it in some helper functions.
>
> The main problem with
Ben,
On Mon, 2013-09-30 at 12:29 -0700, Linus Torvalds wrote:
But I'm cc'ing the POWER people, because I don't know the POWER8
interfaces, and I don't want to necessarily call this xbegin/xend
when I actually wrap it in some helper functions.
The main problem with powerpc TM is that
Well we don't have to, I think Mikey wasn't totally clear about that
making all registers volatile business :-) This is just something we
need to handle in assembly if we are going to reclaim the suspended
transaction.
Yeah, sorry. The slow path with all registers as volatile is only
needed
_capacity()
> which is only used on POWER7+ and that code excludes this case by
> being limited to SD_SHARE_CPUPOWER which is only ever set on the SMT
> domain which must be the lowest domain and this has singleton groups.
>
> So nothing should be affected by this change.
>
> Cc:
()
which is only used on POWER7+ and that code excludes this case by
being limited to SD_SHARE_CPUPOWER which is only ever set on the SMT
domain which must be the lowest domain and this has singleton groups.
So nothing should be affected by this change.
Cc: Michael Neuling mi...@neuling.org
> Anyway, I'm attaching my completely mindless test program. It has
> hacky things like "unsigned long count[MAXTHREADS][32]" which are
> purely to just spread out the counts so that they aren't in the same
> cacheline etc.
>
> Also note that the performance numbers it spits out depend a lot on
>
Anyway, I'm attaching my completely mindless test program. It has
hacky things like unsigned long count[MAXTHREADS][32] which are
purely to just spread out the counts so that they aren't in the same
cacheline etc.
Also note that the performance numbers it spits out depend a lot on
tings
setup any of the icp VCPU
pointers. This manifests itself later in boot when trying to raise an
IRQ resulting in a null pointer deference/segv.
This moves xics_init() to use dev_base_init() to ensure it happens after
kvm_cpu_init().
Signed-off-by: Michael Neuling
diff --git a/tools/kvm/powerpc/xics.c b/
VCPU
pointers. This manifests itself later in boot when trying to raise an
IRQ resulting in a null pointer deference/segv.
This moves xics_init() to use dev_base_init() to ensure it happens after
kvm_cpu_init().
Signed-off-by: Michael Neuling mi...@neuling.org
diff --git a/tools/kvm/powerpc
Bharat Bhushan wrote:
> Signed-off-by: Bharat Bhushan
Acked-by: Michael Neuling
> ---
> arch/powerpc/kernel/process.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> i
Alexander Graf wrote:
>
> On 09.07.2013, at 06:24, Michael Neuling wrote:
>
> > Alexander Graf wrote:
> >
> >>
> >> On 04.07.2013, at 08:15, Bharat Bhushan wrote:
> >>
> >>> From: Bharat Bhushan
> >>>
> >>
Bharat Bhushan wrote:
> This way we can use same data type struct with KVM and
> also help in using other debug related function.
>
> Signed-off-by: Bharat Bhushan
Acked-by: Michael Neuling
> ---
> arch/powerpc/include/asm/processor.h | 38 +
> arc
Alexander Graf ag...@suse.de wrote:
On 09.07.2013, at 06:24, Michael Neuling wrote:
Alexander Graf ag...@suse.de wrote:
On 04.07.2013, at 08:15, Bharat Bhushan wrote:
From: Bharat Bhushan bharat.bhus...@freescale.com
This patchset moves the debug registers in a structure
Bharat Bhushan r65...@freescale.com wrote:
This way we can use same data type struct with KVM and
also help in using other debug related function.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
Acked-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm
Bharat Bhushan r65...@freescale.com wrote:
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
Acked-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/kernel/process.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b
Alexander Graf wrote:
>
> On 04.07.2013, at 08:15, Bharat Bhushan wrote:
>
> > From: Bharat Bhushan
> >
> > This patchset moves the debug registers in a structure, which allows
> > kvm to use same structure for debug emulation.
> >
> > Note: Earilier a patchset
> >
Alexander Graf ag...@suse.de wrote:
On 04.07.2013, at 08:15, Bharat Bhushan wrote:
From: Bharat Bhushan bharat.bhus...@freescale.com
This patchset moves the debug registers in a structure, which allows
kvm to use same structure for debug emulation.
Note: Earilier a patchset
Aruna Balakrishnaiah wrote:
> Since now we have pstore support for nvram in pseries, enable it
> in the default config. With this config option enabled, pstore
> infra-structure will be used to read/write the messages from/to nvram.
>
> Signed-off-by: Aruna Balakrishnaiah
Ac
...@linux.vnet.ibm.com
Acked-by: Michael Neuling mi...@neuling.org
---
v3:
Move pstore config to right place
v2:
Change patch description
arch/powerpc/configs/pseries_defconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/configs/pseries_defconfig
> Enable PSTORE in pseries_defconfig
Please add a "why" to your changelogs eg. "Now we have pstore support for
nvram on pseries, enable it in the default config"
"Why" you are changing something is more important than "what", since
you can always determine "what" is being changed, by looking at
Enable PSTORE in pseries_defconfig
Please add a why to your changelogs eg. Now we have pstore support for
nvram on pseries, enable it in the default config
Why you are changing something is more important than what, since
you can always determine what is being changed, by looking at the diff.
Aruna Balakrishnaiah wrote:
> Hi Michael,
>
> On Wednesday 19 June 2013 11:45 AM, Michael Neuling wrote:
> > Aruna Balakrishnaiah wrote:
> >> Currently the kernel provides the contents of p-series NVRAM only as a
> >> simple stream of bytes via /dev/nvram,
Aruna Balakrishnaiah wrote:
> Currently the kernel provides the contents of p-series NVRAM only as a
> simple stream of bytes via /dev/nvram, which must be interpreted in user
> space by the nvram command in the powerpc-utils package. This patch set
> exploits the pstore subsystem to expose each
Aruna Balakrishnaiah ar...@linux.vnet.ibm.com wrote:
Currently the kernel provides the contents of p-series NVRAM only as a
simple stream of bytes via /dev/nvram, which must be interpreted in user
space by the nvram command in the powerpc-utils package. This patch set
exploits the pstore
Aruna Balakrishnaiah ar...@linux.vnet.ibm.com wrote:
Hi Michael,
On Wednesday 19 June 2013 11:45 AM, Michael Neuling wrote:
Aruna Balakrishnaiah ar...@linux.vnet.ibm.com wrote:
Currently the kernel provides the contents of p-series NVRAM only as a
simple stream of bytes via /dev/nvram
Suka,
One of these two patches breaks pmac32_defconfig and I suspect all other
32 bit configs (against mainline)
arch/powerpc/perf/core-book3s.c: In function 'record_and_restart':
arch/powerpc/perf/core-book3s.c:1632:4: error: passing argument 1 of
'ppmu->get_mem_data_src' from incompatible
Sukadev Bhattiprolu wrote:
> From 9f1a8a16e0ef36447e343d1cd4797c2b6a81225f Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Fri, 7 Jun 2013 13:26:31 -0700
> Subject: [PATCH 2/2] perf: Add support for the mem_xlvl field.
>
> A follow-on patch to adding perf_mem_data_src support for
Grant Likely wrote:
> On Tue, 18 Jun 2013 10:05:31 +0100, Grant Likely
> wrote:
> > On Tue, Jun 18, 2013 at 2:25 AM, Michael Neuling wrote:
> > > Michael Neuling wrote:
> > >
> > >> Grant,
> > >>
> > >> In next-20130617 w
Grant Likely grant.lik...@linaro.org wrote:
On Tue, 18 Jun 2013 10:05:31 +0100, Grant Likely grant.lik...@linaro.org
wrote:
On Tue, Jun 18, 2013 at 2:25 AM, Michael Neuling mi...@neuling.org wrote:
Michael Neuling mi...@neuling.org wrote:
Grant,
In next-20130617 we are getting
Sukadev Bhattiprolu suka...@linux.vnet.ibm.com wrote:
From 9f1a8a16e0ef36447e343d1cd4797c2b6a81225f Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu suka...@linux.vnet.ibm.com
Date: Fri, 7 Jun 2013 13:26:31 -0700
Subject: [PATCH 2/2] perf: Add support for the mem_xlvl field.
A follow-on
Suka,
One of these two patches breaks pmac32_defconfig and I suspect all other
32 bit configs (against mainline)
arch/powerpc/perf/core-book3s.c: In function 'record_and_restart':
arch/powerpc/perf/core-book3s.c:1632:4: error: passing argument 1 of
'ppmu-get_mem_data_src' from incompatible
Michael Neuling wrote:
> Grant,
>
> In next-20130617 we are getting the below crash on POWER7. Bisecting,
> points to this patch (d39046ec72 in next)
Also, reverting just d39046ec72 fixes the crash in next-20130617.
Mikey
>
> Any clues?
>
> Mikey
>
>
>
Grant,
In next-20130617 we are getting the below crash on POWER7. Bisecting,
points to this patch (d39046ec72 in next)
Any clues?
Mikey
Using pSeries machine description
Page sizes from device-tree:
base_shift=12: shift=12, sllp=0x, avpnm=0x, tlbiel=1, penc=0
base_shift=24:
Grant,
In next-20130617 we are getting the below crash on POWER7. Bisecting,
points to this patch (d39046ec72 in next)
Any clues?
Mikey
Using pSeries machine description
Page sizes from device-tree:
base_shift=12: shift=12, sllp=0x, avpnm=0x, tlbiel=1, penc=0
base_shift=24:
Michael Neuling mi...@neuling.org wrote:
Grant,
In next-20130617 we are getting the below crash on POWER7. Bisecting,
points to this patch (d39046ec72 in next)
Also, reverting just d39046ec72 fixes the crash in next-20130617.
Mikey
Any clues?
Mikey
Using pSeries machine
Guenter Roeck wrote:
> On Fri, Jun 07, 2013 at 12:58:16PM -0700, Greg KH wrote:
> > I'm announcing the release of the 3.9.5 kernel.
> >
> > All users of the 3.9 kernel series must upgrade.
> >
> > The updated 3.9.y git tree can be found at:
> >
Guenter Roeck li...@roeck-us.net wrote:
On Fri, Jun 07, 2013 at 12:58:16PM -0700, Greg KH wrote:
I'm announcing the release of the 3.9.5 kernel.
All users of the 3.9 kernel series must upgrade.
The updated 3.9.y git tree can be found at:
Andy Lutomirski wrote:
> I broke them in this commit:
>
> commit 1be374a0518a288147c6a7398792583200a67261
> Author: Andy Lutomirski
> Date: Wed May 22 14:07:44 2013 -0700
>
> net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
>
> This patch adds __sys_sendmsg and
On Thu, May 23, 2013 at 7:07 AM, Andy Lutomirski wrote:
> MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
> it's a hack that steals a bit to indicate to other networking code
> that a compat entry was used. So don't allow it from a non-compat
> syscall.
Dave & Linus
This is
On Thu, May 23, 2013 at 7:07 AM, Andy Lutomirski l...@amacapital.net wrote:
MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
it's a hack that steals a bit to indicate to other networking code
that a compat entry was used. So don't allow it from a non-compat
syscall.
Dave
Andy Lutomirski l...@amacapital.net wrote:
I broke them in this commit:
commit 1be374a0518a288147c6a7398792583200a67261
Author: Andy Lutomirski l...@amacapital.net
Date: Wed May 22 14:07:44 2013 -0700
net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
This
Anshuman Khandual wrote:
> On 05/22/2013 02:29 PM, Anshuman Khandual wrote:
> >>
> >> Your description from patch 0 should be here.
> > Does it sound better ?
> >
> >>
> >>> - if ((br_privilege != 7) && (br_privilege != 0))
> >>> - return -1;
> >>> +
> >>> + if (br_privilege)
> >>> +
Anshuman Khandual khand...@linux.vnet.ibm.com wrote:
On 05/22/2013 02:29 PM, Anshuman Khandual wrote:
Your description from patch 0 should be here.
Does it sound better ?
- if ((br_privilege != 7) (br_privilege != 0))
- return -1;
+
+ if (br_privilege)
+
Peter Zijlstra wrote:
> On Wed, May 22, 2013 at 11:52:38AM +0530, Anshuman Khandual wrote:
> > Enables conditional branch filter support for POWER8
> > utilizing MMCRA register based filter and also invalidates
> > a BHRB branch filter combination involving conditional
> > branches.
> >
> >
Peter Zijlstra pet...@infradead.org wrote:
On Wed, May 22, 2013 at 11:52:38AM +0530, Anshuman Khandual wrote:
Enables conditional branch filter support for POWER8
utilizing MMCRA register based filter and also invalidates
a BHRB branch filter combination involving conditional
branches.
Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
> > On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra
> > wrote:
> > > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
> > >> Peter,
> > >>
&
Peter Zijlstra pet...@infradead.org wrote:
On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra pet...@infradead.org
wrote:
On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
Peter,
BTW PowerPC also has
Stephane Eranian wrote:
> On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra wrote:
> > On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
> >> Peter Zijlstra wrote:
> >
> >> > Wouldn't it be mostly conditional branches that are the primary con
Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
> > On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra
> > wrote:
> > > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
> > >> Peter,
> > >>
&
Peter Zijlstra pet...@infradead.org wrote:
On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra pet...@infradead.org
wrote:
On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
Peter,
BTW PowerPC also has
Stephane Eranian eran...@google.com wrote:
On Fri, May 17, 2013 at 1:39 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
Peter Zijlstra pet...@infradead.org wrote:
Wouldn't it be mostly conditional branches
Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
> > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra
> > wrote:
> > > We should always have proper privileges when requesting kernel data.
> > >
> > > Cc: Andi Kleen
> > > Cc: eran...@google.com
> > >
Peter Zijlstra wrote:
> On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
> > On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra
> > wrote:
> > > We should always have proper privileges when requesting kernel data.
> > >
> > > Cc: Andi Kleen
> > > Cc: eran...@google.com
> > >
Peter Zijlstra pet...@infradead.org wrote:
On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra a.p.zijls...@chello.nl
wrote:
We should always have proper privileges when requesting kernel data.
Cc: Andi Kleen
Peter Zijlstra pet...@infradead.org wrote:
On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra a.p.zijls...@chello.nl
wrote:
We should always have proper privileges when requesting kernel data.
Cc: Andi Kleen
301 - 400 of 573 matches
Mail list logo
