Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
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
===
--- 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv4 01/11] atomic: add *_dec_not_zero
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 da...@davemloft.net Signed-off-by: Sven Eckelmann s...@narfation.org Cc: Randy Dunlap rdun...@xenotime.net Cc: Richard Henderson r...@twiddle.net Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru Cc: Matt Turner matts...@gmail.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Luck tony.l...@intel.com Cc: Fenghua Yu fenghua...@intel.com Cc: Hirokazu Takata tak...@linux-m32r.org Cc: Ralf Baechle r...@linux-mips.org Cc: Kyle McMartin k...@mcmartin.ca Cc: Helge Deller del...@gmx.de Cc: James E.J. Bottomley j...@parisc-linux.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Martin Schwidefsky schwidef...@de.ibm.com Cc: Heiko Carstens heiko.carst...@de.ibm.com Cc: linux...@de.ibm.com Cc: David S. Miller da...@davemloft.net Cc: Chris Metcalf cmetc...@tilera.com Cc: Jeff Dike jd...@addtoit.com Cc: Richard Weinberger rich...@nod.at Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Cc: Arnd Bergmann a...@arndb.de Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-al...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-i...@vger.kernel.org Cc: linux-m...@ml.linux-m32r.org Cc: linux-m32r...@ml.linux-m32r.org Cc: linux-m...@linux-mips.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: user-mode-linux-de...@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.a...@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)
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
Peter Zijlstra pet...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
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.zijls...@chello.nl
---
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);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
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.zijls...@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 b...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] PSeries: Cancel RTAS event scan before firmware flash
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.orig2011-07-01 22:41:12.952507971
-0400
+++ arch/powerpc/kernel/setup-common.c2011-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 suz...@in.ibm.com
Signed-off-by: Ravi Nittala ravi.nitt...@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_LOGGED0x0
#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;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
HELP:PowerPc-Linux kernel
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ppc: Remove duplicate definition of PV_POWER7
One definition of PV_POWER7 seems enough to me. Signed-off-by: Peter Zijlstra a.p.zijls...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: HELP:PowerPc-Linux kernel
On Wed, 27 Jul 2011 20:33:54 +0530 naresh.kamb...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] [6/99] seqlock: Don't smp_rmb in seqlock reader spin loop
2.6.35-longterm review patch. If anyone has any objections, please let me know.
--
From: Milton Miller milt...@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 milt...@bga.com
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Andi Kleen a...@firstfloor.org
Cc: Nick Piggin npig...@kernel.dk
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Anton Blanchard an...@samba.org
Cc: Paul McKenney paul...@linux.vnet.ibm.com
Acked-by: Eric Dumazet eric.duma...@gmail.com
Signed-off-by: Andi Kleen a...@linux.intel.com
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Greg Kroah-Hartman gre...@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;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm/futex: Fix futex writes on archs with SW tracking of dirty young
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: HELP:PowerPc-Linux kernel
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.kamb...@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. 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 ___ 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
Re: HELP:PowerPc-Linux kernel
Have you every worked on device trees before? On 7/28/11, Vijay Nikam vijay.t.ni...@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.kamb...@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. 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 ___ 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
