* Hector Marco Gisbert wrote:
> +unsigned long randomize_et_dyn(unsigned long base)
> +{
> + unsigned long ret;
> + if ((current->personality & ADDR_NO_RANDOMIZE) ||
> + !(current->flags & PF_RANDOMIZE))
> + return base;
> + ret = base + mmap_rnd();
> + re
* Ingo Molnar wrote:
>
> * Anton Blanchard wrote:
>
> > +static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> > +static int die_owner = -1;
> > +static unsigned int die_nest_count;
> > +
> > +unsigned long __die_spin_lock_irqsave(void)
> > +{
> > + unsigned long flags;
> > + int
Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
"kernel BUG at kernel/smpboot.c:134!" issue during boot:
BUG_ON(td->cpu != smp_processor_id());
Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output confirms it:
CPU: 0
Comm: watchdog/130
Th
* Anton Blanchard wrote:
> +static arch_spinlock_t die_lock = __ARCH_SPIN_LOCK_UNLOCKED;
> +static int die_owner = -1;
> +static unsigned int die_nest_count;
> +
> +unsigned long __die_spin_lock_irqsave(void)
> +{
> + unsigned long flags;
> + int cpu;
> +
> + /* racy, but better than
* Anton Blanchard wrote:
> Every now and then I end up with an undebuggable issue
> because multiple CPUs hit something at the same time and
> everything is interleaved:
>
> CR: 4882 XER:
> ,RI
> c003dc72fd10
> ,LE
> d65b84e8
>
On Fri, 2015-02-20 at 16:07 +0100, Cédric Le Goater wrote:
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/platforms/powernv/opal-sensor.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/opal-sensor.c
> b/arch/powerpc/platforms/powernv/opal-s
On Mon, 2015-02-23 at 09:45 +0100, Geert Uytterhoeven wrote:
> On Mon, Feb 23, 2015 at 9:33 AM, Geert Uytterhoeven
> wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v4.0-rc1[1] compared to v3.19[2].
> >
> > Summarized:
> > - build errors: +11/-10
>
> > [1] ht
On Fri, 2015-02-20 at 11:40 +0700, Arseny Solokha wrote:
> > If I just get a patch saying "removed unused foo()", I have to go and dig
> > and
> > find out:
> > - was it recently added and will be used soon?
> > - is it ancient and never used, if so can we work out why, ie. feature X
> > n
On Mon, 2015-02-23 at 10:54 -0800, Nishanth Aravamudan wrote:
> On 23.02.2015 [13:27:24 +1100], Michael Ellerman wrote:
> > On Sat, 2015-21-02 at 19:00:50 UTC, Nishanth Aravamudan wrote:
> > > On 20.02.2015 [15:31:29 +1100], Michael Ellerman wrote:
> > > > On Thu, 2015-02-19 at 10:41 -0800, Nishant
Excerpts from Joe Perches's message of 2015-02-24 01:59:45 +1100:
> On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote:
> > 24 of the %.16llx
> > matches are in drivers/misc/cxl/, so internal consistency wins.
>
> I think that's more an argument for changing all of the
> cx1 uses to "%016ll
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Mon, 2015-02-23 at 18:10 -0600, Suresh E. Warrier wrote:
> Export __spin_yield so that the arch_spin_unlock() function
> can be invoked from a module.
Make it EXPORT_SYMBOL_GPL. Also explain why a module might need it
> Signed-off-by: Suresh Warrier
> ---
> arch/powerpc/lib/locks.c | 1 +
>
A simple kernel module was used to create concurrent WARNs and BUGs:
http://ozlabs.org/~anton/junkcode/warnstorm.tar.gz
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/traps.c | 44
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git
Remove another version of a recursive lock in dump_stack.
Signed-off-by: Anton Blanchard
---
lib/dump_stack.c | 40
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git a/lib/dump_stack.c b/lib/dump_stack.c
index 6745c62..f64ee3c 100644
--- a/lib/
A simple kernel module was used to create concurrent soft and
hard lockups:
http://ozlabs.org/~anton/junkcode/badguy.tar.gz
Signed-off-by: Anton Blanchard
---
kernel/watchdog.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 70bf118..dd161e3 1
Replace the x86 specific oops locking with the common one.
Signed-off-by: Anton Blanchard
---
arch/x86/kernel/dumpstack.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index b74ebc7..b635f
Replace the ARM specific oops locking with the common one.
Signed-off-by: Anton Blanchard
---
arch/arm/kernel/traps.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 788e23f..3e3469d 100644
--
Replace the powerpc specific oops locking with the common one.
Signed-off-by: Anton Blanchard
---
arch/powerpc/kernel/traps.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 19e4744..4cc
Many architectures have their own oops locking code that allows
the lock to be taken recursively. Create a common version.
Avoid creating generic locking functions, so they can't be
abused in other parts of the kernel.
Signed-off-by: Anton Blanchard
---
include/linux/die_lock.h | 23 +++
Every now and then I end up with an undebuggable issue because multiple
CPUs hit something at the same time and everything is interleaved:
CR: 4882 XER:
,RI
c003dc72fd10
,LE
d65b84e8
Instruction dump:
MSR: 800100
On Fri, 2015-02-20 at 15:25 -0400, Julian Margetson wrote:
> On 2/18/2015 11:25 PM, Julian Margetson wrote:
> re PPC4XX PCI(E) MSI support.
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/087273.html
Hmm, I think all those comments were addressed before it was merged.
I tried to
Export __spin_yield so that the arch_spin_unlock() function
can be invoked from a module.
Signed-off-by: Suresh Warrier
---
arch/powerpc/lib/locks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index bb7cfec..d100de8 100644
--- a/arch/po
On Mon, 2015-02-23 at 06:59 -0800, Joe Perches wrote:
> On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote:
> > 24 of the %.16llx
> > matches are in drivers/misc/cxl/, so internal consistency wins.
>
> I think that's more an argument for changing all of the
> cx1 uses to "%016llx".
+1
che
On Mon, 2015-02-23 at 10:59 +0100, Geert Uytterhoeven wrote:
> Hi Michael,
>
> On Tue, Jan 20, 2015 at 8:05 AM, Michael Ellerman wrote:
> > It looks like it's ~4 years since we updated some of these, so do a bulk
> > update.
> >
> > Verified that the before and after generated configs are exactly
On Fri, 2015-02-20 at 15:54 +0100, Sebastian Andrzej Siewior wrote:
> On 02/20/2015 03:12 PM, Paolo Bonzini wrote:
> >> Thomas, what is the usual approach for patches like this? Do you take
> >> them into your rt tree or should they get integrated to upstream?
> >
> > Patch 1 is definitely suitabl
Hello Scott,
On 02/23/2015 04:01 PM, Scott Wood wrote:
> On Wed, 2015-02-18 at 16:04 +0200, Igal.Liberman wrote:
>> From: Igal Liberman
>>
>> Get the FMan devices/sub-nodes (MAC, MDIO, etc.) auto-probed
>>
>> Signed-off-by: Igal Liberman
>> ---
>> arch/powerpc/platforms/85xx/common.c
On Fri, 2015-02-20 at 14:45 +0100, Alexander Graf wrote:
>
> On 18.02.15 10:32, Bogdan Purcareata wrote:
> > Due to the introduction of the raw_spinlock for the KVM openpic, guests
> > with a
> > high number of VCPUs may induce great latencies on the underlying RT Linux
> > system (e.g. cyclictes
On Wed, 2015-02-18 at 09:32 +, Bogdan Purcareata wrote:
> This patch enables running intensive I/O workloads, e.g. netperf, in a guest
> deployed on a RT host. It also enable guests to be SMP.
>
> The openpic spinlock becomes a sleeping mutex on a RT system. This no longer
> guarantees that EP
On Wed, 2015-02-18 at 16:04 +0200, Igal.Liberman wrote:
> From: Igal Liberman
>
> Get the FMan devices/sub-nodes (MAC, MDIO, etc.) auto-probed
>
> Signed-off-by: Igal Liberman
> ---
> arch/powerpc/platforms/85xx/common.c |1 +
> arch/powerpc/platforms/85xx/corenet_generic.c |3
On Thu, 2015-02-19 at 19:26 +0700, Arseny Solokha wrote:
> + fsl_mpic_primary_get_version() is just a safe wrapper around
> fsl_mpic_get_version() for SMP configurations. While the latter is
> called explicitly for handling PIC initialization and setting up error
> interrupt vector depending on P
Hi ! Please try sending patches inline rather than as attachments, it
makes replying a bit easier... Also don't CC stable, we can shoot to
stable later on if we think it's justified but first we need to get the
patch upstream
A few comments:
On Mon, 2015-02-23 at 12:58 +0100, Thomas Haschka wrote
On 21.02.2015 [11:00:50 -0800], Nishanth Aravamudan wrote:
> On 20.02.2015 [15:31:29 +1100], Michael Ellerman wrote:
> > On Thu, 2015-02-19 at 10:41 -0800, Nishanth Aravamudan wrote:
> > > After d905c5df9aef ("PPC: POWERNV: move iommu_add_device earlier"), the
> > > refcnt on the kobject backing th
[PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
The issue appears on PIE linked executables when all memory areas of a
process are randomized. In this case, the attack "offset2lib" de-randomizes
all library areas on 64 bit Linux systems in less than one second.
Further details of
(I've added some additional CCs to make sure the arch maintainers
notice this patch.)
This patch seems white-space damaged to me. I had to do a lot of
manual editing to get it to apply. Please use "git format-patch", if
you're not already. What version of the kernel was this based on?
On Mon, Feb
Fastsleep is one of the idle state which cpuidle subsystem currently
uses on power8 machines. In this state L2 cache is brought down to a
threshold voltage. Therefore when the core is in fastsleep, the
communication between L2 and L3 needs to be fenced. But there is a bug
in the current power8 chip
On 23.02.2015 [13:27:24 +1100], Michael Ellerman wrote:
> On Sat, 2015-21-02 at 19:00:50 UTC, Nishanth Aravamudan wrote:
> > On 20.02.2015 [15:31:29 +1100], Michael Ellerman wrote:
> > > On Thu, 2015-02-19 at 10:41 -0800, Nishanth Aravamudan wrote:
> > > > After d905c5df9aef ("PPC: POWERNV: move io
This patch removes the redundant sysfs cacheinfo code by reusing
the newly introduced generic cacheinfo infrastructure through the
commit 246246cbde5e ("drivers: base: support cpu cache information
interface to userspace via sysfs")
Signed-off-by: Sudeep Holla
Cc: Benjamin Herrenschmidt
Cc: Paul
Signed-off-by: Thomas Haschka
---
drivers/macintosh/therm_adt746x.c | 158 +-
1 file changed, 121 insertions(+), 37 deletions(-)
diff --git a/drivers/macintosh/therm_adt746x.c
b/drivers/macintosh/therm_adt746x.c
index f433521..a29f15d 100644
--- a/drivers/mac
On 2/23/2015 9:03 AM, Julian Margetson wrote:
On 2/18/2015 10:56 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 21:36 -0400, Julian Margetson wrote:
On 2/18/2015 8:13 PM, Michael Ellerman wrote:
On Wed, 2015-02-18 at 15:45 -0400, Julian Margetson wrote:
On 2/15/2015 8:18 PM, Michael Eller
On 02/23/2015 12:58 PM, Thomas Haschka wrote:
> Hi everyone,
>
> The current driver linux/drivers/macintosh/therm_adt746x.c does not take the
> HDD BUTTOMSIDE sensor into account. It actually should as the 12" Powerbooks
> and IBooks are build in a way that the airflow cools the harddrive and
>
The goal is to verify vphn_unpack_associativity() parses VPHN numbers
correctly. We feed it with a variety of input values and compare with
expected results.
PAPR+ does not say much about VPHN parsing: I came up with a list of
tests that check many simple cases and some corner ones. I wouldn't
dar
The current VPHN parsing logic has some flaws that this patch aims to fix:
1) when the value 0x is read, the value 0x gets added to the
the output list and its element count isn't incremented. This is wrong.
According to PAPR+ the domain identifiers are packed into a sequence
The goal behind this patch is to be able to write userland tests for the
VPHN parsing code.
Suggested-by: Michael Ellerman
Signed-off-by: Greg Kurz
---
arch/powerpc/mm/Makefile |1 +
arch/powerpc/mm/numa.c | 61 ++
arch/powerpc/mm/vphn.c |
The first argument to vphn_unpack_associativity() is a const long *, but the
parsing code expects __be64 values actually. Let's move the endian fixing
down for consistency.
Signed-off-by: Greg Kurz
---
arch/powerpc/mm/numa.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
dif
Michael,
As suggested in...
https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-February/124647.html
... I repost the whole series with an extra patch to implement selftests
for VPHN (this is the only change between v2 and v3).
Please review.
---
Greg Kurz (5):
powerpc/vphn: clarify th
The number of values returned by the H_HOME_NODE_ASSOCIATIVITY h_call deserves
to be explicitly defined, for a better understanding of the code.
Signed-off-by: Greg Kurz
---
arch/powerpc/mm/numa.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/numa
On Mon, 2015-02-23 at 11:55 +0100, Rasmus Villemoes wrote:
> 24 of the %.16llx
> matches are in drivers/misc/cxl/, so internal consistency wins.
I think that's more an argument for changing all of the
cx1 uses to "%016llx".
___
Linuxppc-dev mailing lis
Hi everyone,
The current driver linux/drivers/macintosh/therm_adt746x.c does not take
the HDD BUTTOMSIDE sensor into account. It actually should as the 12"
Powerbooks and IBooks are build in a way that the airflow cools the
harddrive and components around it. Actually there are air intake openings
On Monday 23 February 2015 11:28:12 Geert Uytterhoeven wrote:
> On Mon, Feb 23, 2015 at 11:24 AM, Arnd Bergmann wrote:
> > On Monday 23 February 2015 10:14:55 Geert Uytterhoeven wrote:
> >> On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote:
> >> >> > + /home/kisskb/slave/src/fs/dax.c: error
C99 says that a precision given as simply '.' with no following digits
or * should be interpreted as 0. The kernel's printf implementation,
however, treats this case as if the precision was omitted. C99 also
says that if both the precision and value are 0, no digits should be
printed. Even if the k
On 02/21/2015 12:03 PM, Guenter Roeck wrote:
> On 02/20/2015 11:14 PM, Cedric Le Goater wrote:
>> On 02/21/2015 12:52 AM, Guenter Roeck wrote:
>>> On 02/20/2015 12:15 PM, Cedric Le Goater wrote:
On 02/20/2015 05:52 PM, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 04:07:34PM +0100, Cédric
On Mon, Feb 23, 2015 at 11:24 AM, Arnd Bergmann wrote:
> On Monday 23 February 2015 10:14:55 Geert Uytterhoeven wrote:
>> On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote:
>> >> > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of
>> >> > function 'copy_user_page' [-Werror=
On Monday 23 February 2015 10:14:55 Geert Uytterhoeven wrote:
> On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote:
> >> > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of
> >> > function 'copy_user_page' [-Werror=implicit-function-declaration]: =>
> >> > 266:2
> >
> > DAX
Hi Michael,
On Tue, Jan 20, 2015 at 8:05 AM, Michael Ellerman wrote:
> It looks like it's ~4 years since we updated some of these, so do a bulk
> update.
>
> Verified that the before and after generated configs are exactly the
> same.
Yep, that's guaranteed by the tool (modulo bugs).
> Which be
On Mon, Feb 23, 2015 at 10:03 AM, Arnd Bergmann wrote:
>> > + /home/kisskb/slave/src/fs/dax.c: error: implicit declaration of
>> > function 'copy_user_page' [-Werror=implicit-function-declaration]: =>
>> > 266:2
>
> DAX support was merged with 'depends on !(ARM || MIPS || SPARC)', so I don't
On Monday 23 February 2015 09:45:43 Geert Uytterhoeven wrote:
> On Mon, Feb 23, 2015 at 9:33 AM, Geert Uytterhoeven
> wrote:
> > Below is the list of build error/warning regressions/improvements in
> > v4.0-rc1[1] compared to v3.19[2].
> >
> > Summarized:
> > - build errors: +11/-10
>
> > [1] h
On Mon, Feb 23, 2015 at 9:33 AM, Geert Uytterhoeven
wrote:
> Below is the list of build error/warning regressions/improvements in
> v4.0-rc1[1] compared to v3.19[2].
>
> Summarized:
> - build errors: +11/-10
> [1] http://kisskb.ellerman.id.au/kisskb/head/8494/ (256 out of 257 configs)
> [2] htt
On 20.02.2015 17:17, Sebastian Andrzej Siewior wrote:
On 02/20/2015 04:10 PM, Paolo Bonzini wrote:
On 20/02/2015 16:06, Sebastian Andrzej Siewior wrote:
On 02/20/2015 03:57 PM, Paolo Bonzini wrote:
Yes, but large latencies just mean the code has to be rewritten (x86
doesn't anymore do event
58 matches
Mail list logo
