Benjamin Herrenschmidt wrote:
>On Sat, 2011-07-16 at 10:50 -0400, Shan Hai wrote:
>>
>> That's right the gup(.write=1) want to do the same thing as the
>> above code snippet, but it failed for the following reason:
>> because the get_user_pages() would not dirty pte for the reason
>> the follow_
On Sun, 2011-07-17 at 09:49 +1000, Benjamin Herrenschmidt wrote:
> In the meantime, other than rewriting the futex code to not require
> those in-atomic accesses (can't it just access the pages via the linear
> mapping and/or kmap after the gup ?),
That'll wreck performance on things like ARM and
> On Tue, Jun 28, 2011 at 09:47:11AM -0400, Josh Boyer wrote:
> > The *p variable is declared and used to save inb->ptr, however p is
> > later never used. This has been the case since commit 6c0f3676 and can
> > lead to build failures with -Werror=unused-but-set-variable:
> >
> > flattree.c:
> On Tue, Jun 28, 2011 at 08:47:09AM -0400, Josh Boyer wrote:
> > Commit 376ab6f2 removed the old style check functionality from DTC,
> > however the check option and variable were not removed. This leads to
> > build failures when -Werror=unused-but-set-variable is specified:
> >
> > dtc.c:
On 07/17/2011 07:02 PM, Peter Zijlstra wrote:
On Sun, 2011-07-17 at 09:49 +1000, Benjamin Herrenschmidt wrote:
In the meantime, other than rewriting the futex code to not require
those in-atomic accesses (can't it just access the pages via the linear
mapping and/or kmap after the gup ?),
That'l
On Sun, 2011-07-17 at 11:38 +0200, Peter Zijlstra wrote:
> Whats this talk about interrup context? There is non of that involved.
Ok, let's not mix things here. I was going to fast and may have murkied
the waters. First let's get back to the futex code issue with gup:
> Furthermore, I still dont
On Sun, 2011-07-17 at 13:02 +0200, Peter Zijlstra wrote:
>
> Again, _WHY_ isn't gup(.write=1) a complete write fault? Its supposed to
> be, it needs to break COW, do dirty page tracking and call page_mkwrite.
> I'm still thinking this e500 stuff is smoking crack.
>
> ARM has no hardware dirty bit
On Sun, 2011-07-17 at 21:33 +0800, Shan Hai wrote:
>
> On ARM you could not protect pages from supervisor-mode writes,
> isn't it? That means, all writable user pages are writable for
> supervisor too, but its not hold for at least x86 and powerpc,
> x86 and powerpc can be configured to protect p
On 07/17/2011 10:48 PM, Benjamin Herrenschmidt wrote:
On Sun, 2011-07-17 at 21:33 +0800, Shan Hai wrote:
On ARM you could not protect pages from supervisor-mode writes,
isn't it? That means, all writable user pages are writable for
supervisor too, but its not hold for at least x86 and powerpc,
On Sun, 2011-07-17 at 23:40 +0800, Shan Hai wrote:
> On 07/17/2011 10:48 PM, Benjamin Herrenschmidt wrote:
> > On Sun, 2011-07-17 at 21:33 +0800, Shan Hai wrote:
> >> On ARM you could not protect pages from supervisor-mode writes,
> >> isn't it? That means, all writable user pages are writable for
On Mon, 2011-07-18 at 00:29 +1000, Benjamin Herrenschmidt wrote:
> A better approach might be a flag to pass to gup (via the "write"
> argument ? top bits ?) to tell it to immediately perform dirty/young
> updates.
So I dug a bit now that it's not 1am anymore :-)
Looks like gup changed a lot sin
The notifier error injection provides the ability to inject artifical
errors to specified notifier chain callbacks. It is useful to test
the error handling of notifier call chain failures.
This adds common basic functions to define which type of events can be
fail and to initialize the debugfs int
This provides the ability to inject artifical errors to pSeries reconfig
notifier chain callbacks. It is controlled through debugfs interface
under /sys/kernel/debug/pSeries-reconfig-notifier-error-inject/
Each of the files in the directory represents an event which can be
failed and contains the
On Fri, Jul 15, 2011 at 11:40:27AM -0500, Ayman Elkhashab wrote:
> @@ -1582,8 +1628,8 @@ static int __init ppc4xx_setup_one_pciex_POM(struct
> ppc4xx_pciex_port *port,
> dcr_write(port->dcrs, DCRO_PEGPL_OMR2BAH, lah);
> dcr_write(port->dcrs, DCRO_PEGPL_OMR2BAL, lal);
On Mon, 2011-07-18 at 09:14 +1000, Benjamin Herrenschmidt wrote:
> In fact, with such a flag, we could probably avoid the ifdef entirely, and
> always go toward the PTE fixup path when called in such a fixup case, my gut
> feeling is that this is going to be seldom enough not to hurt x86 measurabl
On Mon, 2011-07-18 at 09:14 +1000, Benjamin Herrenschmidt wrote:
> In fact, with such a flag, we could probably avoid the ifdef entirely, and
> always go toward the PTE fixup path when called in such a fixup case, my gut
> feeling is that this is going to be seldom enough not to hurt x86 measurabl
On 07/12/11 12:14, Suzuki K. Poulose wrote:
Changes from V1: Uses a tmp mapping in the other address space to setup
the 1:1 mapping (suggested by Sebastian Andrzej Siewior).
Note: Should we do the same for kernel entry code for PPC44x ?
This patch adds kexec support for PPC440
On Mon, 2011-07-18 at 13:53 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-07-18 at 09:14 +1000, Benjamin Herrenschmidt wrote:
>
> > In fact, with such a flag, we could probably avoid the ifdef entirely, and
> > always go toward the PTE fixup path when called in such a fixup case, my gut
> >
> -Original Message-
> From: Anton Vorontsov [mailto:avoront...@mvista.com]
> Sent: Tuesday, July 05, 2011 18:18 PM
> To: Zang Roy-R61911
> Cc: linux-...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; akpm@linux-
> foundation.org
> Subject: Re: [PATCH 3/3] eSDHC: fix incorrect default va
> -Original Message-
> From: S, Venkatraman [mailto:svenk...@ti.com]
> Sent: Tuesday, July 05, 2011 14:17 PM
> To: Zang Roy-R61911
> Cc: linux-mmc; linuxppc-dev; cbouatmailru; akpm; Xu Lei-B33228; Kumar Gala
> Subject: Re: [PATCH 2/3] eSDHC: Fix errors when booting kernel with fsl esdhc
>
On 07/18/2011 12:01 PM, Benjamin Herrenschmidt wrote:
On Mon, 2011-07-18 at 09:14 +1000, Benjamin Herrenschmidt wrote:
In fact, with such a flag, we could probably avoid the ifdef entirely, and
always go toward the PTE fixup path when called in such a fixup case, my gut
feeling is that this is
21 matches
Mail list logo
