* Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
From: Baruch Siach @ 2011-07-29 7:23 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXVsJUrCaNVHjhLkL=-GwAr79S9xQdoRLvjFG--k1jdRvw@mail.gmail.com>
Hi Tabi,
On Thu, Jul 28, 2011 at 07:56:53PM +0000, Tabi Timur-B04825 wrote:
> On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> > breaking clear_pages(), probably others too.
> >
> > Cc: Kumar Gala <galak@kernel.crashing.org>
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > Is this the right approach?
>
> It doesn't work for me.
>
> I need something that if an e500v2 platform (e.g. the P1022DS) is
> selected, then I won't be able to select any e500mc platforms (e.g.
> P4080DS). And if I don't select any e500v2 platforms, then I will be
> able to select an e500mc platform. This patch doesn't seem to do
> that.
The source of the trouble seems to be the user selectable CONFIG_PPC_E500MC
with the misleading "e500mc Support" description. I'll try to post something
better next week.
> It might be necessary to split the entire menu into two parts, one for
> e500v2 parts and one for e500mc parts.
baurch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
From: Scott Wood @ 2011-07-28 20:20 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Baruch Siach, linuxppc-dev@lists.ozlabs.org, Gala Kumar-B11780
In-Reply-To: <CAOZdJXVsJUrCaNVHjhLkL=-GwAr79S9xQdoRLvjFG--k1jdRvw@mail.gmail.com>
On Thu, 28 Jul 2011 19:56:53 +0000
Tabi Timur-B04825 <B04825@freescale.com> wrote:
> On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
> > breaking clear_pages(), probably others too.
> >
> > Cc: Kumar Gala <galak@kernel.crashing.org>
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > Is this the right approach?
>
> It doesn't work for me.
>
> I need something that if an e500v2 platform (e.g. the P1022DS) is
> selected, then I won't be able to select any e500mc platforms (e.g.
> P4080DS). And if I don't select any e500v2 platforms, then I will be
> able to select an e500mc platform. This patch doesn't seem to do
> that.
>
> It might be necessary to split the entire menu into two parts, one for
> e500v2 parts and one for e500mc parts.
>
How about making the "Processor Type" entry be either E500 or E500MC, both
of which select PPC_85xx?
-Scott
^ permalink raw reply
* Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
From: Timur Tabi @ 2011-07-28 20:02 UTC (permalink / raw)
To: Baruch Siach; +Cc: Kumar Gala, linuxppc-dev
In-Reply-To: <CAOZdJXVsJUrCaNVHjhLkL=-GwAr79S9xQdoRLvjFG--k1jdRvw@mail.gmail.com>
wrote:
> On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
>> breaking clear_pages(), probably others too.
>>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>> Is this the right approach?
>
> It doesn't work for me.
I also get this error if I try to build corenet32_smp_defconfig:
arch/powerpc/platforms/Kconfig.cputype:136:error: recursive dependency detected!
arch/powerpc/platforms/Kconfig.cputype:136: symbol PPC_E500MC is selected by
P2040_RDB
arch/powerpc/platforms/85xx/Kconfig:176: symbol P2040_RDB depends on PPC_E500MC
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC PATCH] powerpc: 85xx: Make e500/e500v2 depend on !E500MC
From: Tabi Timur-B04825 @ 2011-07-28 19:56 UTC (permalink / raw)
To: Baruch Siach; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fef1cfc9a418ec5aa3302915dcb392882f7dd5d2.1308545584.git.baruch@tkos.co.il>
On Sun, Jun 19, 2011 at 11:56 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6,=
thus
> breaking clear_pages(), probably others too.
>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> Is this the right approach?
It doesn't work for me.
I need something that if an e500v2 platform (e.g. the P1022DS) is
selected, then I won't be able to select any e500mc platforms (e.g.
P4080DS). And if I don't select any e500v2 platforms, then I will be
able to select an e500mc platform. This patch doesn't seem to do
that.
It might be necessary to split the entire menu into two parts, one for
e500v2 parts and one for e500mc parts.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: David Howells @ 2011-07-28 10:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tony.luck, Mike Frysinger, Shan Hai, linux-kernel, cmetcalf,
dhowells, paulus, uclinux-dist-devel, tglx, walken, linuxppc-dev,
akpm
In-Reply-To: <1311761831.24752.413.camel@twins>
Peter Zijlstra <peterz@infradead.org> wrote:
> Subject: mm: Fix fixup_user_fault() for MMU=n
>
> In commit 2efaca927 ("mm/futex: fix futex writes on archs with SW
> tracking of dirty & young") we forgot about MMU=n. This patch fixes
> that.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: HELP:PowerPc-Linux kernel
From: Vijay Nikam @ 2011-07-28 6:27 UTC (permalink / raw)
To: MJ embd; +Cc: naresh.kamboju, linuxppc-dev, cort, linas, hollis
In-Reply-To: <CAPUj1OOqRp-4h=7=x277P0cPSUJT4eCaxfCo0AAeA810hrb8Rg@mail.gmail.com>
Yes
/Vijay Nikam
On Thu, Jul 28, 2011 at 11:00 AM, MJ embd <mj.embd@gmail.com> wrote:
> Have you every worked on device trees before?
>
> On 7/28/11, Vijay Nikam <vijay.t.nikam@gmail.com> wrote:
>> Hello,
>>
>> Start with looking at the configuration of the board done which is
>> similar to yours
>> or based on the same CPU as yours. It is important to know role of
>> device tree so
>> read the documentation and understand the syntax and concept of device
>> tree. Once
>> the complete concept is understood then you should start the
>> configuration and achieve
>> successful creation of kernel image.
>>
>> Take a step forward and do some hands on. If any problem occurs then
>> post for specific help,
>> as porting itself is a big task and dosent have really straight forward
>> steps.
>> Good Luck
>>
>> Kind Regards,
>> Vijay Nikam
>>
>> On Wed, Jul 27, 2011 at 8:33 PM, <naresh.kamboju@wipro.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have take up the new assignment =A0Board bring up activity with Linux
>>> kernel on PowerPC MPC8272.
>>>
>>> I have been searching Linux bring up on PowerPC processor in Google and
>>> IBM wiki and not found good stuff.
>>>
>>> It would be more helpful for me if you could share related documents.
>>>
>>>
>>>
>>> Best regards
>>>
>>> Naresh Kamboju
>>>
>>>
>>>
>>> Please do not print this email unless it is absolutely necessary.
>>>
>>> The information contained in this electronic message and any attachment=
s
>>> to this message are intended for the exclusive use of the addressee(s) =
and
>>> may contain proprietary, confidential or privileged information. If you
>>> are not the intended recipient, you should not disseminate, distribute =
or
>>> copy this e-mail. Please notify the sender immediately and destroy all
>>> copies of this message and any attachments.
>>>
>>> WARNING: Computer viruses can be transmitted via email. The recipient
>>> should check this email and any attachments for the presence of viruses=
.
>>> The company accepts no liability for any damage caused by any virus
>>> transmitted by this email.
>>>
>>> www.wipro.com
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>
>
> --
> -mj
>
^ permalink raw reply
* Re: HELP:PowerPc-Linux kernel
From: MJ embd @ 2011-07-28 5:30 UTC (permalink / raw)
To: Vijay Nikam; +Cc: naresh.kamboju, linuxppc-dev, cort, linas, hollis
In-Reply-To: <CAGn8Sby3Swk8zXxDXnXDBM+bDn=RV2cmvqvwXZM+05P=Z1FMAg@mail.gmail.com>
Have you every worked on device trees before?
On 7/28/11, Vijay Nikam <vijay.t.nikam@gmail.com> wrote:
> Hello,
>
> Start with looking at the configuration of the board done which is
> similar to yours
> or based on the same CPU as yours. It is important to know role of
> device tree so
> read the documentation and understand the syntax and concept of device
> tree. Once
> the complete concept is understood then you should start the
> configuration and achieve
> successful creation of kernel image.
>
> Take a step forward and do some hands on. If any problem occurs then
> post for specific help,
> as porting itself is a big task and dosent have really straight forward
> steps.
> Good Luck
>
> Kind Regards,
> Vijay Nikam
>
> On Wed, Jul 27, 2011 at 8:33 PM, <naresh.kamboju@wipro.com> wrote:
>>
>> Hi,
>>
>>
>>
>> I have take up the new assignment =A0Board bring up activity with Linux
>> kernel on PowerPC MPC8272.
>>
>> I have been searching Linux bring up on PowerPC processor in Google and
>> IBM wiki and not found good stuff.
>>
>> It would be more helpful for me if you could share related documents.
>>
>>
>>
>> Best regards
>>
>> Naresh Kamboju
>>
>>
>>
>> Please do not print this email unless it is absolutely necessary.
>>
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s) a=
nd
>> may contain proprietary, confidential or privileged information. If you
>> are not the intended recipient, you should not disseminate, distribute o=
r
>> copy this e-mail. Please notify the sender immediately and destroy all
>> copies of this message and any attachments.
>>
>> WARNING: Computer viruses can be transmitted via email. The recipient
>> should check this email and any attachments for the presence of viruses.
>> The company accepts no liability for any damage caused by any virus
>> transmitted by this email.
>>
>> www.wipro.com
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--=20
-mj
^ permalink raw reply
* Re: HELP:PowerPc-Linux kernel
From: Vijay Nikam @ 2011-07-28 4:45 UTC (permalink / raw)
To: naresh.kamboju; +Cc: linas, cort, linuxppc-dev, hollis
In-Reply-To: <35CC4C9595855B43903A67B297EFA8E3C544FD@HYD-MKD-MBX01.wipro.com>
Hello,
Start with looking at the configuration of the board done which is
similar to yours
or based on the same CPU as yours. It is important to know role of
device tree so
read the documentation and understand the syntax and concept of device
tree. Once
the complete concept is understood then you should start the
configuration and achieve
successful creation of kernel image.
Take a step forward and do some hands on. If any problem occurs then
post for specific help,
as porting itself is a big task and dosent have really straight forward ste=
ps.
Good Luck
Kind Regards,
Vijay Nikam
On Wed, Jul 27, 2011 at 8:33 PM, <naresh.kamboju@wipro.com> wrote:
>
> Hi,
>
>
>
> I have take up the new assignment =A0Board bring up activity with Linux k=
ernel on PowerPC MPC8272.
>
> I have been searching Linux bring up on PowerPC processor in Google and I=
BM wiki and not found good stuff.
>
> It would be more helpful for me if you could share related documents.
>
>
>
> Best regards
>
> Naresh Kamboju
>
>
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments =
to this message are intended for the exclusive use of the addressee(s) and =
may contain proprietary, confidential or privileged information. If you are=
not the intended recipient, you should not disseminate, distribute or copy=
this e-mail. Please notify the sender immediately and destroy all copies o=
f this message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient sho=
uld check this email and any attachments for the presence of viruses. The c=
ompany accepts no liability for any damage caused by any virus transmitted =
by this email.
>
> www.wipro.com
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Mike Frysinger @ 2011-07-28 0:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tony.luck, Shan Hai, Peter Zijlstra, linux-kernel, cmetcalf,
David Howells, paulus, uclinux-dist-devel, tglx, walken,
linuxppc-dev, akpm
In-Reply-To: <1311762043.25044.679.camel@pasglop>
On Wed, Jul 27, 2011 at 03:20, Benjamin Herrenschmidt wrote:
> Hoping the BUG() isn't trippable by userspace but then it's no mmu, it's
> not like we care what userspace can do right :-)
side note ... common misconception that "no mmu" == "no memory
protection". a few of the nommu processors have memory protection,
just no virtual<->physical translation.
thanks for the patch !
-mike
^ permalink raw reply
* [PATCH] [6/99] seqlock: Don't smp_rmb in seqlock reader spin loop
From: Andi Kleen @ 2011-07-27 21:48 UTC (permalink / raw)
To: miltonm, linuxppc-dev, torvalds, andi, npiggin, benh, anton,
paulmck, eric.dumazet, ak, tglx, gregkh, linux-kernel, stable,
tim.bird
In-Reply-To: <20110727247.325703029@firstfloor.org>
2.6.35-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Milton Miller <miltonm@bga.com>
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller <miltonm@bga.com>
Cc: <linuxppc-dev@lists.ozlabs.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Nick Piggin <npiggin@kernel.dk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/seqlock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.35.y/include/linux/seqlock.h
===================================================================
--- linux-2.6.35.y.orig/include/linux/seqlock.h
+++ linux-2.6.35.y/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
^ permalink raw reply
* Re: HELP:PowerPc-Linux kernel
From: Scott Wood @ 2011-07-27 20:27 UTC (permalink / raw)
To: naresh.kamboju; +Cc: linuxppc-dev
In-Reply-To: <35CC4C9595855B43903A67B297EFA8E3C544FD@HYD-MKD-MBX01.wipro.com>
On Wed, 27 Jul 2011 20:33:54 +0530
<naresh.kamboju@wipro.com> wrote:
> Hi,
>
>
>
> I have take up the new assignment Board bring up activity with Linux
> kernel on PowerPC MPC8272.
>
> I have been searching Linux bring up on PowerPC processor in Google and
> IBM wiki and not found good stuff.
>
> It would be more helpful for me if you could share related documents.
Look at the support in current kernels for 82xx-based boards such as
mpc8272ads. Read the documentation on device trees
(Documentation/devicetree, devicetree.org, ePAPR).
-Scott
^ permalink raw reply
* [PATCH] ppc: Remove duplicate definition of PV_POWER7
From: Peter Zijlstra @ 2011-07-27 17:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Anton Blanchard
One definition of PV_POWER7 seems enough to me.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
arch/powerpc/include/asm/reg.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.=
h
index c5cae0d..fedf93b 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -986,7 +986,6 @@
#define PV_970 0x0039
#define PV_POWER5 0x003A
#define PV_POWER5p 0x003B
-#define PV_POWER7 0x003F
#define PV_970FX 0x003C
#define PV_POWER6 0x003E
#define PV_POWER7 0x003F
^ permalink raw reply related
* HELP:PowerPc-Linux kernel
From: naresh.kamboju @ 2011-07-27 15:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: cort, linas, hollis
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]
Hi,
I have take up the new assignment Board bring up activity with Linux
kernel on PowerPC MPC8272.
I have been searching Linux bring up on PowerPC processor in Google and
IBM wiki and not found good stuff.
It would be more helpful for me if you could share related documents.
Best regards
Naresh Kamboju
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
[-- Attachment #2: Type: text/html, Size: 5835 bytes --]
^ permalink raw reply
* [PATCH] PSeries: Cancel RTAS event scan before firmware flash
From: Ravi K. Nittala @ 2011-07-27 12:09 UTC (permalink / raw)
To: linuxppc-dev
Cc: antonb, subrata.modak, mikey, sbest, suzuki, ranittal,
divya.vikas
The firmware flash update is conducted using an RTAS call, that is serialized
by lock_rtas() which uses spin_lock. rtasd keeps scanning for the RTAS events
generated on the machine. This is performed via a delayed workqueue, invoking
an RTAS call to scan the events.
The flash update takes a while to complete and during this time, any other
RTAS call has to wait. In this case, rtas_event_scan() waits for a long time
on the spin_lock resulting in a soft lockup.
Approaches to fix the issue :
Approach 1: Stop all the other CPUs before we start flashing the firmware.
Before the rtas firmware update starts, all other CPUs should be stopped.
Which means no other CPU should be in lock_rtas(). We do not want other CPUs
execute while FW update is in progress and the system will be rebooted anyway
after the update.
--- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 -0400
+++ arch/powerpc/kernel/setup-common.c 2011-07-01 22:48:31.182507915 -0400
@@ -109,11 +109,12 @@ void machine_shutdown(void)
void machine_restart(char *cmd)
{
machine_shutdown();
- if (ppc_md.restart)
- ppc_md.restart(cmd);
#ifdef CONFIG_SMP
- smp_send_stop();
+ smp_send_stop();
#endif
+ if (ppc_md.restart)
+ ppc_md.restart(cmd);
+
printk(KERN_EMERG "System Halted, OK to turn off power\n");
local_irq_disable();
while (1) ;
Problems with this approach:
Stopping the CPUs suddenly may cause other serious problems depending on what
was running on them. Hence, this approach cannot be considered.
Approach 2: Cancel the rtas_scan_event work before starting the firmware flash.
Just before the flash update is performed, the queued rtas_event_scan() work
item is cancelled from the work queue so that there is no other RTAS call
issued while the flash is in progress. After the flash completes, the system
reboots and the rtas_event_scan() is rescheduled.
Approach 2 looks to be a better solution than Approach 1. Kindly let us know
your thoughts. Patch attached.
Signed-off-by: Suzuki Poulose <suzuki@in.ibm.com>
Signed-off-by: Ravi Nittala <ravi.nittala@in.ibm.com>
---
arch/powerpc/include/asm/rtas.h | 2 ++
arch/powerpc/kernel/rtas_flash.c | 6 ++++++
arch/powerpc/kernel/rtasd.c | 6 ++++++
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 58625d1..3f26f87 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -245,6 +245,8 @@ extern int early_init_dt_scan_rtas(unsigned long node,
extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
+extern bool rtas_cancel_event_scan(void);
+
/* Error types logged. */
#define ERR_FLAG_ALREADY_LOGGED 0x0
#define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index e037c74..4174b4b 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -568,6 +568,12 @@ static void rtas_flash_firmware(int reboot_type)
}
/*
+ * Just before starting the firmware flash, cancel the event scan work
+ * to avoid any soft lockup issues.
+ */
+ rtas_cancel_event_scan();
+
+ /*
* NOTE: the "first" block must be under 4GB, so we create
* an entry with no data blocks in the reserved buffer in
* the kernel data segment.
diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index 481ef06..e8f03fa 100644
--- a/arch/powerpc/kernel/rtasd.c
+++ b/arch/powerpc/kernel/rtasd.c
@@ -472,6 +472,12 @@ static void start_event_scan(void)
&event_scan_work, event_scan_delay);
}
+/* Cancel the rtas event scan work */
+bool rtas_cancel_event_scan(void)
+{
+ return cancel_delayed_work_sync(&event_scan_work);
+}
+
static int __init rtas_init(void)
{
struct proc_dir_entry *entry;
^ permalink raw reply related
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Benjamin Herrenschmidt @ 2011-07-27 10:20 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tony.luck, Mike Frysinger, Shan Hai, linux-kernel, cmetcalf,
David Howells, paulus, uclinux-dist-devel, tglx, walken,
linuxppc-dev, akpm
In-Reply-To: <1311761831.24752.413.camel@twins>
On Wed, 2011-07-27 at 12:17 +0200, Peter Zijlstra wrote:
> On Wed, 2011-07-27 at 11:09 +0100, David Howells wrote:
> > Can you inline this for the NOMMU case please?
>
> ---
> Subject: mm: Fix fixup_user_fault() for MMU=n
>
> In commit 2efaca927 ("mm/futex: fix futex writes on archs with SW
> tracking of dirty & young") we forgot about MMU=n. This patch fixes
> that.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Hoping the BUG() isn't trippable by userspace but then it's no mmu, it's
not like we care what userspace can do right :-)
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Thanks !
Cheers,
Ben.
> ---
> Index: linux-2.6/include/linux/mm.h
> ===================================================================
> --- linux-2.6.orig/include/linux/mm.h
> +++ linux-2.6/include/linux/mm.h
> @@ -962,6 +962,8 @@ int invalidate_inode_page(struct page *p
> #ifdef CONFIG_MMU
> extern int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> unsigned long address, unsigned int flags);
> +extern int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
> + unsigned long address, unsigned int fault_flags);
> #else
> static inline int handle_mm_fault(struct mm_struct *mm,
> struct vm_area_struct *vma, unsigned long address,
> @@ -971,6 +973,14 @@ static inline int handle_mm_fault(struct
> BUG();
> return VM_FAULT_SIGBUS;
> }
> +static inline int fixup_user_fault(struct task_struct *tsk,
> + struct mm_struct *mm, unsigned long address,
> + unsigned int fault_flags)
> +{
> + /* should never happen if there's no MMU */
> + BUG();
> + return -EFAULT;
> +}
> #endif
>
> extern int make_pages_present(unsigned long addr, unsigned long end);
> @@ -988,8 +998,6 @@ int get_user_pages(struct task_struct *t
> int get_user_pages_fast(unsigned long start, int nr_pages, int write,
> struct page **pages);
> struct page *get_dump_page(unsigned long addr);
> -extern int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
> - unsigned long address, unsigned int fault_flags);
>
> extern int try_to_release_page(struct page * page, gfp_t gfp_mask);
> extern void do_invalidatepage(struct page *page, unsigned long offset);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Peter Zijlstra @ 2011-07-27 10:17 UTC (permalink / raw)
To: David Howells
Cc: tony.luck, Mike Frysinger, Shan Hai, linux-kernel, cmetcalf,
paulus, uclinux-dist-devel, tglx, walken, linuxppc-dev, akpm
In-Reply-To: <20368.1311761379@redhat.com>
On Wed, 2011-07-27 at 11:09 +0100, David Howells wrote:
> Can you inline this for the NOMMU case please?
---
Subject: mm: Fix fixup_user_fault() for MMU=3Dn=20
In commit 2efaca927 ("mm/futex: fix futex writes on archs with SW
tracking of dirty & young") we forgot about MMU=3Dn. This patch fixes
that.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
Index: linux-2.6/include/linux/mm.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -962,6 +962,8 @@ int invalidate_inode_page(struct page *p
#ifdef CONFIG_MMU
extern int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vm=
a,
unsigned long address, unsigned int flags);
+extern int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long address, unsigned int fault_flags);
#else
static inline int handle_mm_fault(struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long address,
@@ -971,6 +973,14 @@ static inline int handle_mm_fault(struct
BUG();
return VM_FAULT_SIGBUS;
}
+static inline int fixup_user_fault(struct task_struct *tsk,=20
+ struct mm_struct *mm, unsigned long address,
+ unsigned int fault_flags)
+{
+ /* should never happen if there's no MMU */
+ BUG();
+ return -EFAULT;
+}
#endif
=20
extern int make_pages_present(unsigned long addr, unsigned long end);
@@ -988,8 +998,6 @@ int get_user_pages(struct task_struct *t
int get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
struct page *get_dump_page(unsigned long addr);
-extern int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
- unsigned long address, unsigned int fault_flags);
=20
extern int try_to_release_page(struct page * page, gfp_t gfp_mask);
extern void do_invalidatepage(struct page *page, unsigned long offset);
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: David Howells @ 2011-07-27 10:09 UTC (permalink / raw)
To: Peter Zijlstra
Cc: tony.luck, Mike Frysinger, Shan Hai, linux-kernel, cmetcalf,
dhowells, paulus, uclinux-dist-devel, tglx, walken, linuxppc-dev,
akpm
In-Reply-To: <1311757190.24752.406.camel@twins>
Peter Zijlstra <peterz@infradead.org> wrote:
> > What should nommu do anyways ? it's not like there's much it can do
> > right ? It should never even hit the fault path to start with ...
>
> Something like the below makes a nommu arm config build.. David, is this
> indeed the correct thing to do for nommu?
>
> ---
> Index: linux-2.6/mm/nommu.c
> ===================================================================
> --- linux-2.6.orig/mm/nommu.c
> +++ linux-2.6/mm/nommu.c
> @@ -190,6 +190,12 @@ int get_user_pages(struct task_struct *t
> }
> EXPORT_SYMBOL(get_user_pages);
>
> +int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
> + unsigned long address, unsigned int fault_flags)
> +{
> + BUG(); /* nommu should never call this */
> +}
> +
> /**
> * follow_pfn - look up PFN at a user virtual address
> * @vma: memory mapping
Or perhaps send SEGV? Can 'address' be bad at this point?
Can you inline this for the NOMMU case please?
David
^ permalink raw reply
* [PATCHv4 01/11] atomic: add *_dec_not_zero
From: Sven Eckelmann @ 2011-07-27 9:47 UTC (permalink / raw)
To: linux-arch
Cc: linux-m32r-ja, linux-mips, linux-ia64, linux-doc, H. Peter Anvin,
Heiko Carstens, Randy Dunlap, Paul Mackerras, Helge Deller,
sparclinux, Sven Eckelmann, linux-s390, Russell King,
user-mode-linux-devel, Richard Weinberger, Hirokazu Takata, x86,
James E.J. Bottomley, Ingo Molnar, Matt Turner, Fenghua Yu,
Arnd Bergmann, Jeff Dike, Chris Metcalf, linux-m32r,
Ivan Kokshaysky, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Tony Luck, linux-parisc, linux-kernel,
Ralf Baechle, Kyle McMartin, linux-alpha, Martin Schwidefsky,
linux390, linuxppc-dev, David S. Miller
Introduce an *_dec_not_zero operation. Make this a special case of
*_add_unless because batman-adv uses atomic_dec_not_zero in different
places like re-broadcast queue or aggregation queue management. There
are other non-final patches which may also want to use this macro.
Reported-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Hirokazu Takata <takata@linux-m32r.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux390@de.ibm.com
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-alpha@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-m32r@ml.linux-m32r.org
Cc: linux-m32r-ja@ml.linux-m32r.org
Cc: linux-mips@linux-mips.org
Cc: linux-parisc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: user-mode-linux-devel@lists.sourceforge.net
---
David S. Miller recommended this change in
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-May/004560.html
Arnd Bergmann wanted to apply it in 201106172320.26476.arnd@arndb.de
... and then Arun Sharma created a big merge conflict with
https://lkml.org/lkml/2011/6/6/430
I don't think that it is a a good idea to asume that everyone still agrees
with the patch after I've rewritten it.
Documentation/atomic_ops.txt | 1 +
arch/alpha/include/asm/atomic.h | 1 +
arch/alpha/include/asm/local.h | 1 +
arch/arm/include/asm/atomic.h | 1 +
arch/ia64/include/asm/atomic.h | 1 +
arch/m32r/include/asm/local.h | 1 +
arch/mips/include/asm/atomic.h | 1 +
arch/mips/include/asm/local.h | 1 +
arch/parisc/include/asm/atomic.h | 1 +
arch/powerpc/include/asm/atomic.h | 1 +
arch/powerpc/include/asm/local.h | 1 +
arch/s390/include/asm/atomic.h | 1 +
arch/sparc/include/asm/atomic_64.h | 1 +
arch/tile/include/asm/atomic_32.h | 1 +
arch/tile/include/asm/atomic_64.h | 1 +
arch/um/sys-i386/atomic64_cx8_32.S | 28 ++++++++++++++++++++++++++++
arch/x86/include/asm/atomic64_32.h | 12 ++++++++++++
arch/x86/include/asm/atomic64_64.h | 1 +
arch/x86/include/asm/local.h | 1 +
arch/x86/lib/atomic64_32.c | 4 ++++
arch/x86/lib/atomic64_386_32.S | 21 +++++++++++++++++++++
arch/x86/lib/atomic64_cx8_32.S | 28 ++++++++++++++++++++++++++++
include/asm-generic/atomic-long.h | 2 ++
include/asm-generic/atomic64.h | 1 +
include/asm-generic/local.h | 1 +
include/asm-generic/local64.h | 2 ++
include/linux/atomic.h | 9 +++++++++
27 files changed, 125 insertions(+), 0 deletions(-)
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index 3bd585b..1eec221 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -190,6 +190,7 @@ atomic_add_unless requires explicit memory barriers around the operation
unless it fails (returns 0).
atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0)
+atomic_dec_not_zero, equivalent to atomic_add_unless(v, -1, 0)
If a caller requires memory barrier semantics around an atomic_t
diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index 640f909..09d1571 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -225,6 +225,7 @@ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
#define atomic_add_negative(a, v) (atomic_add_return((a), (v)) < 0)
#define atomic64_add_negative(a, v) (atomic64_add_return((a), (v)) < 0)
diff --git a/arch/alpha/include/asm/local.h b/arch/alpha/include/asm/local.h
index 9c94b84..51eb678 100644
--- a/arch/alpha/include/asm/local.h
+++ b/arch/alpha/include/asm/local.h
@@ -79,6 +79,7 @@ static __inline__ long local_sub_return(long i, local_t * l)
c != (u); \
})
#define local_inc_not_zero(l) local_add_unless((l), 1, 0)
+#define local_dec_not_zero(l) local_add_unless((l), -1, 0)
#define local_add_negative(a, l) (local_add_return((a), (l)) < 0)
diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
index 86976d0..80ed975 100644
--- a/arch/arm/include/asm/atomic.h
+++ b/arch/arm/include/asm/atomic.h
@@ -458,6 +458,7 @@ static inline int atomic64_add_unless(atomic64_t *v, u64 a, u64 u)
#define atomic64_dec_return(v) atomic64_sub_return(1LL, (v))
#define atomic64_dec_and_test(v) (atomic64_dec_return((v)) == 0)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1LL, 0LL)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1LL, 0LL)
#endif /* !CONFIG_GENERIC_ATOMIC64 */
#endif
diff --git a/arch/ia64/include/asm/atomic.h b/arch/ia64/include/asm/atomic.h
index 3fad89e..af6e9b2 100644
--- a/arch/ia64/include/asm/atomic.h
+++ b/arch/ia64/include/asm/atomic.h
@@ -122,6 +122,7 @@ static __inline__ long atomic64_add_unless(atomic64_t *v, long a, long u)
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
#define atomic_add_return(i,v) \
({ \
diff --git a/arch/m32r/include/asm/local.h b/arch/m32r/include/asm/local.h
index 734bca8..d536082 100644
--- a/arch/m32r/include/asm/local.h
+++ b/arch/m32r/include/asm/local.h
@@ -272,6 +272,7 @@ static inline int local_add_unless(local_t *l, long a, long u)
}
#define local_inc_not_zero(l) local_add_unless((l), 1, 0)
+#define local_dec_not_zero(l) local_add_unless((l), -1, 0)
static inline void local_clear_mask(unsigned long mask, local_t *addr)
{
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
index 1d93f81..babb043 100644
--- a/arch/mips/include/asm/atomic.h
+++ b/arch/mips/include/asm/atomic.h
@@ -697,6 +697,7 @@ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
#define atomic64_dec_return(v) atomic64_sub_return(1, (v))
#define atomic64_inc_return(v) atomic64_add_return(1, (v))
diff --git a/arch/mips/include/asm/local.h b/arch/mips/include/asm/local.h
index 94fde8d..0242256 100644
--- a/arch/mips/include/asm/local.h
+++ b/arch/mips/include/asm/local.h
@@ -137,6 +137,7 @@ static __inline__ long local_sub_return(long i, local_t * l)
c != (u); \
})
#define local_inc_not_zero(l) local_add_unless((l), 1, 0)
+#define local_dec_not_zero(l) local_add_unless((l), -1, 0)
#define local_dec_return(l) local_sub_return(1, (l))
#define local_inc_return(l) local_add_return(1, (l))
diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index b1dc71f..8a50234 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -334,6 +334,7 @@ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
#endif /* !CONFIG_64BIT */
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/asm/atomic.h
index e2a4c26..c0131a6 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -468,6 +468,7 @@ static __inline__ int atomic64_add_unless(atomic64_t *v, long a, long u)
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
#endif /* __powerpc64__ */
diff --git a/arch/powerpc/include/asm/local.h b/arch/powerpc/include/asm/local.h
index b8da913..d182e34 100644
--- a/arch/powerpc/include/asm/local.h
+++ b/arch/powerpc/include/asm/local.h
@@ -134,6 +134,7 @@ static __inline__ int local_add_unless(local_t *l, long a, long u)
}
#define local_inc_not_zero(l) local_add_unless((l), 1, 0)
+#define local_dec_not_zero(l) local_add_unless((l), -1, 0)
#define local_sub_and_test(a, l) (local_sub_return((a), (l)) == 0)
#define local_dec_and_test(l) (local_dec_return((l)) == 0)
diff --git a/arch/s390/include/asm/atomic.h b/arch/s390/include/asm/atomic.h
index 8517d2a..92e7d5d 100644
--- a/arch/s390/include/asm/atomic.h
+++ b/arch/s390/include/asm/atomic.h
@@ -325,6 +325,7 @@ static inline long long atomic64_dec_if_positive(atomic64_t *v)
#define atomic64_dec_return(_v) atomic64_sub_return(1, _v)
#define atomic64_dec_and_test(_v) (atomic64_sub_return(1, _v) == 0)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
#define smp_mb__before_atomic_dec() smp_mb()
#define smp_mb__after_atomic_dec() smp_mb()
diff --git a/arch/sparc/include/asm/atomic_64.h b/arch/sparc/include/asm/atomic_64.h
index 9f421df..94cf160 100644
--- a/arch/sparc/include/asm/atomic_64.h
+++ b/arch/sparc/include/asm/atomic_64.h
@@ -106,6 +106,7 @@ static inline long atomic64_add_unless(atomic64_t *v, long a, long u)
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
/* Atomic operations are already serializing */
#define smp_mb__before_atomic_dec() barrier()
diff --git a/arch/tile/include/asm/atomic_32.h b/arch/tile/include/asm/atomic_32.h
index c03349e..9cfafb3 100644
--- a/arch/tile/include/asm/atomic_32.h
+++ b/arch/tile/include/asm/atomic_32.h
@@ -233,6 +233,7 @@ static inline void atomic64_set(atomic64_t *v, u64 n)
#define atomic64_dec_return(v) atomic64_sub_return(1LL, (v))
#define atomic64_dec_and_test(v) (atomic64_dec_return((v)) == 0)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1LL, 0LL)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1LL, 0LL)
/*
* We need to barrier before modifying the word, since the _atomic_xxx()
diff --git a/arch/tile/include/asm/atomic_64.h b/arch/tile/include/asm/atomic_64.h
index 27fe667..9c22f50 100644
--- a/arch/tile/include/asm/atomic_64.h
+++ b/arch/tile/include/asm/atomic_64.h
@@ -141,6 +141,7 @@ static inline long atomic64_add_unless(atomic64_t *v, long a, long u)
#define atomic64_add_negative(i, v) (atomic64_add_return((i), (v)) < 0)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
/* Atomic dec and inc don't implement barrier, so provide them if needed. */
#define smp_mb__before_atomic_dec() smp_mb()
diff --git a/arch/um/sys-i386/atomic64_cx8_32.S b/arch/um/sys-i386/atomic64_cx8_32.S
index 1e901d3..a58a1d4 100644
--- a/arch/um/sys-i386/atomic64_cx8_32.S
+++ b/arch/um/sys-i386/atomic64_cx8_32.S
@@ -223,3 +223,31 @@ ENTRY(atomic64_inc_not_zero_cx8)
jmp 3b
CFI_ENDPROC
ENDPROC(atomic64_inc_not_zero_cx8)
+
+ENTRY(atomic64_dec_not_zero_cx8)
+ CFI_STARTPROC
+ SAVE ebx
+
+ read64 %esi
+1:
+ testl %eax, %eax
+ je 4f
+2:
+ movl %eax, %ebx
+ movl %edx, %ecx
+ subl $1, %ebx
+ sbbl $0, %ecx
+ LOCK_PREFIX
+ cmpxchg8b (%esi)
+ jne 1b
+
+ movl $1, %eax
+3:
+ RESTORE ebx
+ ret
+4:
+ testl %edx, %edx
+ jne 2b
+ jmp 3b
+ CFI_ENDPROC
+ENDPROC(atomic64_dec_not_zero_cx8)
diff --git a/arch/x86/include/asm/atomic64_32.h b/arch/x86/include/asm/atomic64_32.h
index 24098aa..3cd4431 100644
--- a/arch/x86/include/asm/atomic64_32.h
+++ b/arch/x86/include/asm/atomic64_32.h
@@ -287,6 +287,18 @@ static inline int atomic64_inc_not_zero(atomic64_t *v)
return r;
}
+
+static inline int atomic64_dec_not_zero(atomic64_t *v)
+{
+ int r;
+ asm volatile(ATOMIC64_ALTERNATIVE(dec_not_zero)
+ : "=a" (r)
+ : "S" (v)
+ : "ecx", "edx", "memory"
+ );
+ return r;
+}
+
static inline long long atomic64_dec_if_positive(atomic64_t *v)
{
long long r;
diff --git a/arch/x86/include/asm/atomic64_64.h b/arch/x86/include/asm/atomic64_64.h
index 017594d..93c9d8b 100644
--- a/arch/x86/include/asm/atomic64_64.h
+++ b/arch/x86/include/asm/atomic64_64.h
@@ -220,6 +220,7 @@ static inline int atomic64_add_unless(atomic64_t *v, long a, long u)
}
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1, 0)
/*
* atomic64_dec_if_positive - decrement by 1 if old value positive
diff --git a/arch/x86/include/asm/local.h b/arch/x86/include/asm/local.h
index 9cdae5d..2c8c92d 100644
--- a/arch/x86/include/asm/local.h
+++ b/arch/x86/include/asm/local.h
@@ -185,6 +185,7 @@ static inline long local_sub_return(long i, local_t *l)
c != (u); \
})
#define local_inc_not_zero(l) local_add_unless((l), 1, 0)
+#define local_dec_not_zero(l) local_add_unless((l), -1, 0)
/* On x86_32, these are no better than the atomic variants.
* On x86-64 these are better than the atomic variants on SMP kernels
diff --git a/arch/x86/lib/atomic64_32.c b/arch/x86/lib/atomic64_32.c
index 042f682..7da05c3 100644
--- a/arch/x86/lib/atomic64_32.c
+++ b/arch/x86/lib/atomic64_32.c
@@ -24,6 +24,8 @@ long long atomic64_dec_if_positive_cx8(atomic64_t *v);
EXPORT_SYMBOL(atomic64_dec_if_positive_cx8);
int atomic64_inc_not_zero_cx8(atomic64_t *v);
EXPORT_SYMBOL(atomic64_inc_not_zero_cx8);
+int atomic64_dec_not_zero_cx8(atomic64_t *v);
+EXPORT_SYMBOL(atomic64_dec_not_zero_cx8);
int atomic64_add_unless_cx8(atomic64_t *v, long long a, long long u);
EXPORT_SYMBOL(atomic64_add_unless_cx8);
@@ -54,6 +56,8 @@ long long atomic64_dec_if_positive_386(atomic64_t *v);
EXPORT_SYMBOL(atomic64_dec_if_positive_386);
int atomic64_inc_not_zero_386(atomic64_t *v);
EXPORT_SYMBOL(atomic64_inc_not_zero_386);
+int atomic64_dec_not_zero_386(atomic64_t *v);
+EXPORT_SYMBOL(atomic64_dec_not_zero_386);
int atomic64_add_unless_386(atomic64_t *v, long long a, long long u);
EXPORT_SYMBOL(atomic64_add_unless_386);
#endif
diff --git a/arch/x86/lib/atomic64_386_32.S b/arch/x86/lib/atomic64_386_32.S
index e8e7e0d..c78337b 100644
--- a/arch/x86/lib/atomic64_386_32.S
+++ b/arch/x86/lib/atomic64_386_32.S
@@ -181,6 +181,27 @@ ENDP
#undef v
#define v %esi
+BEGIN(dec_not_zero)
+ movl (v), %eax
+ movl 4(v), %edx
+ testl %eax, %eax
+ je 3f
+1:
+ subl $1, %eax
+ sbbl $0, %edx
+ movl %eax, (v)
+ movl %edx, 4(v)
+ movl $1, %eax
+2:
+ RET
+3:
+ testl %edx, %edx
+ jne 1b
+ jmp 2b
+ENDP
+#undef v
+
+#define v %esi
BEGIN(dec_if_positive)
movl (v), %eax
movl 4(v), %edx
diff --git a/arch/x86/lib/atomic64_cx8_32.S b/arch/x86/lib/atomic64_cx8_32.S
index 391a083..989638c 100644
--- a/arch/x86/lib/atomic64_cx8_32.S
+++ b/arch/x86/lib/atomic64_cx8_32.S
@@ -220,3 +220,31 @@ ENTRY(atomic64_inc_not_zero_cx8)
jmp 3b
CFI_ENDPROC
ENDPROC(atomic64_inc_not_zero_cx8)
+
+ENTRY(atomic64_dec_not_zero_cx8)
+ CFI_STARTPROC
+ SAVE ebx
+
+ read64 %esi
+1:
+ testl %eax, %eax
+ je 4f
+2:
+ movl %eax, %ebx
+ movl %edx, %ecx
+ subl $1, %ebx
+ sbbl $0, %ecx
+ LOCK_PREFIX
+ cmpxchg8b (%esi)
+ jne 1b
+
+ movl $1, %eax
+3:
+ RESTORE ebx
+ ret
+4:
+ testl %edx, %edx
+ jne 2b
+ jmp 3b
+ CFI_ENDPROC
+ENDPROC(atomic64_dec_not_zero_cx8)
diff --git a/include/asm-generic/atomic-long.h b/include/asm-generic/atomic-long.h
index b7babf0..0fe75ab 100644
--- a/include/asm-generic/atomic-long.h
+++ b/include/asm-generic/atomic-long.h
@@ -130,6 +130,7 @@ static inline long atomic_long_add_unless(atomic_long_t *l, long a, long u)
}
#define atomic_long_inc_not_zero(l) atomic64_inc_not_zero((atomic64_t *)(l))
+#define atomic_long_dec_not_zero(l) atomic64_dec_not_zero((atomic64_t *)(l))
#define atomic_long_cmpxchg(l, old, new) \
(atomic64_cmpxchg((atomic64_t *)(l), (old), (new)))
@@ -247,6 +248,7 @@ static inline long atomic_long_add_unless(atomic_long_t *l, long a, long u)
}
#define atomic_long_inc_not_zero(l) atomic_inc_not_zero((atomic_t *)(l))
+#define atomic_long_dec_not_zero(l) atomic_dec_not_zero((atomic_t *)(l))
#define atomic_long_cmpxchg(l, old, new) \
(atomic_cmpxchg((atomic_t *)(l), (old), (new)))
diff --git a/include/asm-generic/atomic64.h b/include/asm-generic/atomic64.h
index b18ce4f..90ff9b1 100644
--- a/include/asm-generic/atomic64.h
+++ b/include/asm-generic/atomic64.h
@@ -38,5 +38,6 @@ extern int atomic64_add_unless(atomic64_t *v, long long a, long long u);
#define atomic64_dec_return(v) atomic64_sub_return(1LL, (v))
#define atomic64_dec_and_test(v) (atomic64_dec_return((v)) == 0)
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1LL, 0LL)
+#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1LL, 0LL)
#endif /* _ASM_GENERIC_ATOMIC64_H */
diff --git a/include/asm-generic/local.h b/include/asm-generic/local.h
index 9ceb03b..fabf4f3 100644
--- a/include/asm-generic/local.h
+++ b/include/asm-generic/local.h
@@ -44,6 +44,7 @@ typedef struct
#define local_xchg(l, n) atomic_long_xchg((&(l)->a), (n))
#define local_add_unless(l, _a, u) atomic_long_add_unless((&(l)->a), (_a), (u))
#define local_inc_not_zero(l) atomic_long_inc_not_zero(&(l)->a)
+#define local_dec_not_zero(l) atomic_long_dec_not_zero(&(l)->a)
/* Non-atomic variants, ie. preemption disabled and won't be touched
* in interrupt, etc. Some archs can optimize this case well. */
diff --git a/include/asm-generic/local64.h b/include/asm-generic/local64.h
index 5980002..76acbe2 100644
--- a/include/asm-generic/local64.h
+++ b/include/asm-generic/local64.h
@@ -45,6 +45,7 @@ typedef struct {
#define local64_xchg(l, n) local_xchg((&(l)->a), (n))
#define local64_add_unless(l, _a, u) local_add_unless((&(l)->a), (_a), (u))
#define local64_inc_not_zero(l) local_inc_not_zero(&(l)->a)
+#define local64_dec_not_zero(l) local_dec_not_zero(&(l)->a)
/* Non-atomic variants, ie. preemption disabled and won't be touched
* in interrupt, etc. Some archs can optimize this case well. */
@@ -83,6 +84,7 @@ typedef struct {
#define local64_xchg(l, n) atomic64_xchg((&(l)->a), (n))
#define local64_add_unless(l, _a, u) atomic64_add_unless((&(l)->a), (_a), (u))
#define local64_inc_not_zero(l) atomic64_inc_not_zero(&(l)->a)
+#define local64_dec_not_zero(l) atomic64_dec_not_zero(&(l)->a)
/* Non-atomic variants, ie. preemption disabled and won't be touched
* in interrupt, etc. Some archs can optimize this case well. */
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 42b77b5..ad2b750 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -27,6 +27,15 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u)
#define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
/**
+ * atomic_dec_not_zero - decrement unless the number is zero
+ * @v: pointer of type atomic_t
+ *
+ * Atomically decrements @v by 1, so long as @v is non-zero.
+ * Returns non-zero if @v was non-zero, and zero otherwise.
+ */
+#define atomic_dec_not_zero(v) atomic_add_unless((v), -1, 0)
+
+/**
* atomic_inc_not_zero_hint - increment if not null
* @v: pointer of type atomic_t
* @hint: probable value of the atomic before the increment
--
1.7.5.4
^ permalink raw reply related
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Peter Zijlstra @ 2011-07-27 8:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tony.luck, Mike Frysinger, Shan Hai, linux-kernel, cmetcalf,
dhowells, paulus, uclinux-dist-devel, tglx, walken, linuxppc-dev,
akpm
In-Reply-To: <1311753513.25044.663.camel@pasglop>
On Wed, 2011-07-27 at 17:58 +1000, Benjamin Herrenschmidt wrote:
> What should nommu do anyways ? it's not like there's much it can do
> right ? It should never even hit the fault path to start with ...
Something like the below makes a nommu arm config build.. David, is this
indeed the correct thing to do for nommu?
---
Index: linux-2.6/mm/nommu.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- linux-2.6.orig/mm/nommu.c
+++ linux-2.6/mm/nommu.c
@@ -190,6 +190,12 @@ int get_user_pages(struct task_struct *t
}
EXPORT_SYMBOL(get_user_pages);
=20
+int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
+ unsigned long address, unsigned int fault_flags)
+{
+ BUG(); /* nommu should never call this */
+}
+
/**
* follow_pfn - look up PFN at a user virtual address
* @vma: memory mapping
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Benjamin Herrenschmidt @ 2011-07-27 7:58 UTC (permalink / raw)
To: Mike Frysinger
Cc: tony.luck, Peter Zijlstra, Shan Hai, Peter Zijlstra, linux-kernel,
cmetcalf, dhowells, paulus, uclinux-dist-devel, tglx, walken,
linuxppc-dev, akpm
In-Reply-To: <CAMjpGUdxpaYBFfKjBEPFOJohnKoXfagLUHvhrst+NembeabxcA@mail.gmail.com>
On Tue, 2011-07-26 at 23:50 -0700, Mike Frysinger wrote:
> On Mon, Jul 18, 2011 at 21:29, Benjamin Herrenschmidt wrote:
> > The futex code currently attempts to write to user memory within
> > a pagefault disabled section, and if that fails, tries to fix it
> > up using get_user_pages().
> >
> > This doesn't work on archs where the dirty and young bits are
> > maintained by software, since they will gate access permission
> > in the TLB, and will not be updated by gup().
> >
> > In addition, there's an expectation on some archs that a
> > spurious write fault triggers a local TLB flush, and that is
> > missing from the picture as well.
> >
> > I decided that adding those "features" to gup() would be too much
> > for this already too complex function, and instead added a new
> > simpler fixup_user_fault() which is essentially a wrapper around
> > handle_mm_fault() which the futex code can call.
>
> unfortunately, this breaks all nommu ports. you added
> fixup_user_fault() to mm/memory.c only which is not used by nommu
Argh. Andrew, do you want to send a fix ? I won't be able to do that
tonight, I have to go.
What should nommu do anyways ? it's not like there's much it can do
right ? It should never even hit the fault path to start with ...
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty & young
From: Mike Frysinger @ 2011-07-27 6:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: tony.luck, Peter Zijlstra, Shan Hai, Peter Zijlstra, linux-kernel,
cmetcalf, dhowells, paulus, uclinux-dist-devel, tglx, walken,
linuxppc-dev, akpm
In-Reply-To: <1311049762.25044.392.camel@pasglop>
On Mon, Jul 18, 2011 at 21:29, Benjamin Herrenschmidt wrote:
> The futex code currently attempts to write to user memory within
> a pagefault disabled section, and if that fails, tries to fix it
> up using get_user_pages().
>
> This doesn't work on archs where the dirty and young bits are
> maintained by software, since they will gate access permission
> in the TLB, and will not be updated by gup().
>
> In addition, there's an expectation on some archs that a
> spurious write fault triggers a local TLB flush, and that is
> missing from the picture as well.
>
> I decided that adding those "features" to gup() would be too much
> for this already too complex function, and instead added a new
> simpler fixup_user_fault() which is essentially a wrapper around
> handle_mm_fault() which the futex code can call.
unfortunately, this breaks all nommu ports. you added
fixup_user_fault() to mm/memory.c only which is not used by nommu
logic.
-mike
^ permalink raw reply
* Re: [PATCH] powerpc: pseries: Fix kexec on machines with more than 4TB of RAM
From: Michael Neuling @ 2011-07-27 4:26 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev, miltonm, kexec
In-Reply-To: <20110727141503.3faa93f5@kryten>
> On a box with 8TB of RAM the MMU hashtable is 64GB in size. That
> means we have 4G PTEs. pSeries_lpar_hptab_clear was using a signed
> int to store the index which will overflow at 2G.
Wow, I hear... "Anton Blanchard's machine has more memory in it's MMU
than you have in total".
Acked-by: Michael Neuling <mikey@neuling.org>
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Cc: <stable@kernel.org>
> ---
>
> Index: linux-powerpc/arch/powerpc/platforms/pseries/lpar.c
> ===================================================================
> --- linux-powerpc.orig/arch/powerpc/platforms/pseries/lpar.c 2011-07-27 13:5
0:18.408091576 +1000
> +++ linux-powerpc/arch/powerpc/platforms/pseries/lpar.c 2011-07-27 13:5
1:19.359196131 +1000
> @@ -203,7 +203,7 @@ static void pSeries_lpar_hptab_clear(voi
> unsigned long ptel;
> } ptes[4];
> long lpar_rc;
> - int i, j;
> + unsigned long i, j;
>
> /* Read in batches of 4,
> * invalidate only valid entries not in the VRMA
>
^ permalink raw reply
* [PATCH] powerpc: pseries: Fix kexec on machines with more than 4TB of RAM
From: Anton Blanchard @ 2011-07-27 4:15 UTC (permalink / raw)
To: benh, paulus, mikey, miltonm; +Cc: kexec, linuxppc-dev
On a box with 8TB of RAM the MMU hashtable is 64GB in size. That
means we have 4G PTEs. pSeries_lpar_hptab_clear was using a signed
int to store the index which will overflow at 2G.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---
Index: linux-powerpc/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-powerpc.orig/arch/powerpc/platforms/pseries/lpar.c 2011-07-27 13:50:18.408091576 +1000
+++ linux-powerpc/arch/powerpc/platforms/pseries/lpar.c 2011-07-27 13:51:19.359196131 +1000
@@ -203,7 +203,7 @@ static void pSeries_lpar_hptab_clear(voi
unsigned long ptel;
} ptes[4];
long lpar_rc;
- int i, j;
+ unsigned long i, j;
/* Read in batches of 4,
* invalidate only valid entries not in the VRMA
^ permalink raw reply
* [PATCH] powerpc: Jump label misalignment causes oops at boot
From: Anton Blanchard @ 2011-07-27 0:35 UTC (permalink / raw)
To: benh, paulus, michael; +Cc: linuxppc-dev
In-Reply-To: <20110727101150.449574ef@kryten>
I hit an oops at boot on the first instruction of timer_cpu_notify:
NIP [c000000000722f88] .timer_cpu_notify+0x0/0x388
The code should look like:
c000000000722f78: eb e9 00 30 ld r31,48(r9)
c000000000722f7c: 2f bf 00 00 cmpdi cr7,r31,0
c000000000722f80: 40 9e ff 44 bne+ cr7,c000000000722ec4
c000000000722f84: 4b ff ff 74 b c000000000722ef8
c000000000722f88 <.timer_cpu_notify>:
c000000000722f88: 7c 08 02 a6 mflr r0
c000000000722f8c: 2f a4 00 07 cmpdi cr7,r4,7
c000000000722f90: fb c1 ff f0 std r30,-16(r1)
c000000000722f94: fb 61 ff d8 std r27,-40(r1)
But the oops output shows:
eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 7c0803a6 ebe1fff8 4e800020
00000000 ebe90030 c0000000 00ad0a28 00000000 2fa40007 fbc1fff0 fb61ffd8
So we scribbled over our instructions with c000000000ad0a28, which
is an address inside the jump_table ELF section.
It turns out the jump_table section is only aligned to 8 bytes but
we are aligning our entries within the section to 16 bytes. This
means our entries are offset from the table:
c000000000acd4a8 <__start___jump_table>:
...
c000000000ad0a10: c0 00 00 00 lfs f0,0(0)
c000000000ad0a14: 00 70 cd 5c .long 0x70cd5c
c000000000ad0a18: c0 00 00 00 lfs f0,0(0)
c000000000ad0a1c: 00 70 cd 90 .long 0x70cd90
c000000000ad0a20: c0 00 00 00 lfs f0,0(0)
c000000000ad0a24: 00 ac a4 20 .long 0xaca420
And the jump table sort code gets very confused and writes into the
wrong spot. Remove the alignment, and also remove the padding since
we it saves some space and we shouldn't need it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/include/asm/jump_label.h
===================================================================
--- linux-powerpc.orig/arch/powerpc/include/asm/jump_label.h 2011-07-27 09:35:04.266872078 +1000
+++ linux-powerpc/arch/powerpc/include/asm/jump_label.h 2011-07-27 09:39:32.581719669 +1000
@@ -22,7 +22,6 @@ static __always_inline bool arch_static_
asm goto("1:\n\t"
"nop\n\t"
".pushsection __jump_table, \"aw\"\n\t"
- ".align 4\n\t"
JUMP_ENTRY_TYPE "1b, %l[l_yes], %c0\n\t"
".popsection \n\t"
: : "i" (key) : : l_yes);
@@ -41,7 +40,6 @@ struct jump_entry {
jump_label_t code;
jump_label_t target;
jump_label_t key;
- jump_label_t pad;
};
#endif /* _ASM_POWERPC_JUMP_LABEL_H */
^ permalink raw reply
* [PATCH] powerpc: Jump label misalignment causes oops at boot
From: Anton Blanchard @ 2011-07-27 0:11 UTC (permalink / raw)
To: benh, paulus, michael; +Cc: linuxppc-dev
I hit an oops at boot on the first instruction of timer_cpu_notify:
Oops: Exception in kernel mode, sig: 4 [#1]
...
NIP [c000000000722f88] .timer_cpu_notify+0x0/0x388
The code should look like:
c000000000722f78: eb e9 00 30 ld r31,48(r9)
c000000000722f7c: 2f bf 00 00 cmpdi cr7,r31,0
c000000000722f80: 40 9e ff 44 bne+ cr7,c000000000722ec4
c000000000722f84: 4b ff ff 74 b c000000000722ef8
c000000000722f88 <.timer_cpu_notify>:
c000000000722f88: 7c 08 02 a6 mflr r0
c000000000722f8c: 2f a4 00 07 cmpdi cr7,r4,7
c000000000722f90: fb c1 ff f0 std r30,-16(r1)
c000000000722f94: fb 61 ff d8 std r27,-40(r1)
But the oops output shows these instructions:
eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 7c0803a6 ebe1fff8 4e800020 00000000
ebe90030 c0000000 00ad0a28 00000000 2fa40007 fbc1fff0 fb61ffd8
So we scribbled over our instructions with c000000000ad0a28 which
is an address inside the jump_table ELF section.
It turns out the jump_table section is only aligned to 8 bytes but
we are aligning our entries within the section to 16 bytes. This
means our entries can be offset from the table:
c000000000acd4a8 <__start___jump_table>:
...
c000000000ad0a10: c0 00 00 00 lfs f0,0(0)
c000000000ad0a14: 00 70 cd 5c .long 0x70cd5c
c000000000ad0a18: c0 00 00 00 lfs f0,0(0)
c000000000ad0a1c: 00 70 cd 90 .long 0x70cd90
c000000000ad0a20: c0 00 00 00 lfs f0,0(0)
c000000000ad0a24: 00 ac a4 20 .long 0xaca420
And the jump table sort code gets very confused and writes into the
wrong spot. Remove the alignment and also remove the padding since
we it saves some space and we shouldn't need it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-powerpc/arch/powerpc/include/asm/jump_label.h
===================================================================
--- linux-powerpc.orig/arch/powerpc/include/asm/jump_label.h
2011-07-27 09:35:04.266872078 +1000 +++
linux-powerpc/arch/powerpc/include/asm/jump_label.h 2011-07-27
09:39:32.581719669 +1000 @@ -22,7 +22,6 @@ static __always_inline bool
arch_static_ asm goto("1:\n\t" "nop\n\t"
".pushsection __jump_table, \"aw\"\n\t"
- ".align 4\n\t"
JUMP_ENTRY_TYPE "1b, %l[l_yes], %c0\n\t"
".popsection \n\t"
: : "i" (key) : : l_yes);
@@ -41,7 +40,6 @@ struct jump_entry {
jump_label_t code;
jump_label_t target;
jump_label_t key;
- jump_label_t pad;
};
#endif /* _ASM_POWERPC_JUMP_LABEL_H */
^ 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