I fixed this in x86_64. Looks like the kind of thing that will break
voyager on i386.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
arch/i386/kernel/hpet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- tglx.orig/arch/i386/kernel/hpet.c
+++ tglx/arch/i386/kernel/hpet.c
Lost when merged with i386. Happy to drop, but I suspect Andi would
rather not break existing users (I noticed because it was part of my
testing). If dropped, Documentation needs updating.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
arch/i386/kernel/hpet.c |8
1 file changed
Disable by programming pit directly when performing CLOCK_EVT_MODE_UNUSED
or CLOCK_EVT_MODE_SHUTDOWN transitions. (A variant) tested successfully
by Joachim Deguara on a Geode that exhibited BZ 8027 behaviour (with
bad bogomips).
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Cc: Joachim Deguara
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
On Tue, 2007-05-08 at 02:39 -0700, Chris Wright wrote:
OK, looks very similar all things considered. One thing I didn't do
was fix lapic timer calibration (was hoping you'd do that part, and you
did ;-) I've noticed that something has changed
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
Hmm, that's even more strange. Can you please provide the output
of /proc/timer_list ?
It's quite normal looking, and a printk in clockevents_set_mode looks normal
too.
[EMAIL PROTECTED] ~]$ cat /proc/timer_list
Timer List Version: v0.3
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-05-07 at 09:31 -0700, Chris Wright wrote:
> > * Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> > > I'm pleased to announce the first cut of the final x86_64
> > > highres/dyntick support, which I did based
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> I'm pleased to announce the first cut of the final x86_64
> highres/dyntick support, which I did based on Chris Wright's patch set,
> which is again based on Arjan van de Ven's initial work:
Cool. I had finished mine as well, just didn't get time to
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
I'm pleased to announce the first cut of the final x86_64
highres/dyntick support, which I did based on Chris Wright's patch set,
which is again based on Arjan van de Ven's initial work:
Cool. I had finished mine as well, just didn't get time to
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
On Mon, 2007-05-07 at 09:31 -0700, Chris Wright wrote:
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
I'm pleased to announce the first cut of the final x86_64
highres/dyntick support, which I did based on Chris Wright's patch set,
which
* Herbert Xu ([EMAIL PROTECTED]) wrote:
> Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > ===
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -1213,10 +1213,10 @@ static int netif_poll(struct
* Herbert Xu ([EMAIL PROTECTED]) wrote:
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
===
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1213,10 +1213,10 @@ static int netif_poll(struct net_device
* Greg KH ([EMAIL PROTECTED]) wrote:
> And is this really a problem? The whole goal of the -stable tree was to
> accomidate the users who relied on kernel.org kernels, and wanted
> bugfixes and security updates. It was not for new features or new
> hardware support.
>
> If people feel we should
* Greg KH ([EMAIL PROTECTED]) wrote:
And is this really a problem? The whole goal of the -stable tree was to
accomidate the users who relied on kernel.org kernels, and wanted
bugfixes and security updates. It was not for new features or new
hardware support.
If people feel we should
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Andrew Morton wrote:
> > Yeah, a new-id patch is a pretty critical bugfix if you happen to have that
> > hardware. I'll get all these into 2.6.22 by whatever means and will adopt
> > your advice in future.
> >
> > Probably these should go into -stable
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Andrew Morton wrote:
Yeah, a new-id patch is a pretty critical bugfix if you happen to have that
hardware. I'll get all these into 2.6.22 by whatever means and will adopt
your advice in future.
Probably these should go into -stable too, but I
* Peter Keilty ([EMAIL PROTECTED]) wrote:
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 6077300..35ad71f 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -480,10 +480,12 @@ #endif
> /* Get end time (ticks)
* Greg KH ([EMAIL PROTECTED]) wrote:
> On Thu, Apr 26, 2007 at 09:48:22AM -0700, David Lang wrote:
> > any idea why there are so many more -stable patches for 2.6.20? this is
> > the
> > 10th -stable series, and most of them have been dozens of patches.
> >
> > is there a new team reporting
* Greg KH ([EMAIL PROTECTED]) wrote:
On Thu, Apr 26, 2007 at 09:48:22AM -0700, David Lang wrote:
any idea why there are so many more -stable patches for 2.6.20? this is
the
10th -stable series, and most of them have been dozens of patches.
is there a new team reporting and fixing
* Peter Keilty ([EMAIL PROTECTED]) wrote:
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 6077300..35ad71f 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -480,10 +480,12 @@ #endif
/* Get end time (ticks) */
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Eric W. Biederman wrote:
> > Then why you had to allocate enough pages to cause a failure has me stumped.
> > Perhaps there is some other bug?
>
> Perhaps, but nothing comes to mind. I'll see what happens when I boot
> this kernel on real
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Eric W. Biederman wrote:
Then why you had to allocate enough pages to cause a failure has me stumped.
Perhaps there is some other bug?
Perhaps, but nothing comes to mind. I'll see what happens when I boot
this kernel on real hardware
* Brian Gernhardt ([EMAIL PROTECTED]) wrote:
> Hm. I should drink my coffee, then read the mailing list, not the
> other way around. If you do update HEAD to be the most recent
> stable, my thanks. Apologies for the noise.
No problem, was a good suggestion (and it's done).
thanks,
-chris
* Brian Gernhardt ([EMAIL PROTECTED]) wrote:
> On Apr 14, 2007, at 4:34 AM, Chris Wright wrote:
> >I've already put a tree like this up on kernel.org. The master branch
> >is Linus' tree, and there's branches for each of the stable releases
> >called linux-2.6.[12-20].y (
* Rene Herman ([EMAIL PROTECTED]) wrote:
> Stumbling around with git here. I'd like to use git to efficiently track
> the current -stable as well as -current. Say, my local tree is a clone of
> Linus current:
>
> git clone \
>
* Rene Herman ([EMAIL PROTECTED]) wrote:
Stumbling around with git here. I'd like to use git to efficiently track
the current -stable as well as -current. Say, my local tree is a clone of
Linus current:
git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
* Brian Gernhardt ([EMAIL PROTECTED]) wrote:
On Apr 14, 2007, at 4:34 AM, Chris Wright wrote:
I've already put a tree like this up on kernel.org. The master branch
is Linus' tree, and there's branches for each of the stable releases
called linux-2.6.[12-20].y (I didn't add 2.6.11.y).
http
* Brian Gernhardt ([EMAIL PROTECTED]) wrote:
Hm. I should drink my coffee, then read the mailing list, not the
other way around. If you do update HEAD to be the most recent
stable, my thanks. Apologies for the noise.
No problem, was a good suggestion (and it's done).
thanks,
-chris
-
; kernel pagetables as well as the kernel itself. It ends up using an
> additional two pages of unreclaimable memory.
Yup, fixes it up here, nice catch.
Acked-by: Chris Wright <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
using an
additional two pages of unreclaimable memory.
Yup, fixes it up here, nice catch.
Acked-by: Chris Wright [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Jeremy Fitzhardinge wrote:
> >Why not submit a patch to do what you need here? (The Geode comment is
> >a bit worrying though.)
>
> Why should VMI add workaround into PIT code?
I'm not sure it's a workaround, seems more like a subtle diff (perhaps
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Yes, but unfortunately that is a nop:
>
> /*
> * Avoid unnecessary state transitions, as it confuses
> * Geode / Cyrix based boxen.
> */
> case CLOCK_EVT_MODE_SHUTDOWN:
> if (evt->mode ==
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> >>+void __init vmi_time_init(void)
> >>+{
> >>+ /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */
> >>+ outb_p(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */
> >
> >That shouldn't be necessary using clockevents.
>
> Actually, I'm
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
+void __init vmi_time_init(void)
+{
+ /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */
+ outb_p(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */
That shouldn't be necessary using clockevents.
Actually, I'm not so sure. If
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Yes, but unfortunately that is a nop:
/*
* Avoid unnecessary state transitions, as it confuses
* Geode / Cyrix based boxen.
*/
case CLOCK_EVT_MODE_SHUTDOWN:
if (evt-mode ==
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
Jeremy Fitzhardinge wrote:
Why not submit a patch to do what you need here? (The Geode comment is
a bit worrying though.)
Why should VMI add workaround into PIT code?
I'm not sure it's a workaround, seems more like a subtle diff (perhaps
it's
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> diff -r c02ab981c99c arch/i386/kernel/vmiclock.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/arch/i386/kernel/vmiclock.c Mon Apr 09 15:47:17 2007 -0700
> @@ -0,0 +1,318 @@
> +/*
> + * VMI paravirtual timer support routines.
> + *
> + *
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> It is the stable-queue tree that's not up-to-date:
Ah, yes that is updated (but only within the last half-hour or so).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> That tree is not up-to-date. So much for using it to track -stable --
> what should I use instead?
It's updated, perhaps you hit a stale mirror?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
That tree is not up-to-date. So much for using it to track -stable --
what should I use instead?
It's updated, perhaps you hit a stale mirror?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
It is the stable-queue tree that's not up-to-date:
Ah, yes that is updated (but only within the last half-hour or so).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
diff -r c02ab981c99c arch/i386/kernel/vmiclock.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/arch/i386/kernel/vmiclock.c Mon Apr 09 15:47:17 2007 -0700
@@ -0,0 +1,318 @@
+/*
+ * VMI paravirtual timer support routines.
+ *
+ * Copyright
diff --git a/Makefile b/Makefile
index 3f194d1..e81e106 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION = .5
+EXTRAVERSION = .6
NAME = Homicidal Dwarf Hamster
# *DOCUMENTATION*
diff --git a/crypto/scatterwalk.c
v2.6.20.5 to v2.6.20.6
==
Chris Wright (1):
Linux 2.6.20.6
Herbert Xu (1):
CRYPTO api: Use the right value when advancing scatterwalk_copychunks
Paolo 'Blaisorblade' Giarrusso (1):
uml: fix static linking for real
-
To unsubscribe from
* Chris Wright ([EMAIL PROTECTED]) wrote:
> diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
> index 35172d3..a664231 100644
> --- a/crypto/scatterwalk.c
> +++ b/crypto/scatterwalk.c
> @@ -91,6 +91,8 @@ void scatterwalk_copychunks(void *buf, struct scatte
We (the -stable team) are announcing the release of the 2.6.20.5 kernel.
It contains a number of important bugfixes including a fix for possible
remote DoS.
f8c08c340b83: APPLETALK: Fix a remotely triggerable crash [CVE-2007-1357]
The diffstat and short summary of the fixes are below.
I'll
We (the -stable team) are announcing the release of the 2.6.20.5 kernel.
It contains a number of important bugfixes including a fix for possible
remote DoS.
f8c08c340b83: APPLETALK: Fix a remotely triggerable crash [CVE-2007-1357]
The diffstat and short summary of the fixes are below.
I'll
* Chris Wright ([EMAIL PROTECTED]) wrote:
diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index 35172d3..a664231 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -91,6 +91,8 @@ void scatterwalk_copychunks(void *buf, struct scatter_walk
*walk
v2.6.20.5 to v2.6.20.6
==
Chris Wright (1):
Linux 2.6.20.6
Herbert Xu (1):
CRYPTO api: Use the right value when advancing scatterwalk_copychunks
Paolo 'Blaisorblade' Giarrusso (1):
uml: fix static linking for real
-
To unsubscribe from
diff --git a/Makefile b/Makefile
index 3f194d1..e81e106 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION = .5
+EXTRAVERSION = .6
NAME = Homicidal Dwarf Hamster
# *DOCUMENTATION*
diff --git a/crypto/scatterwalk.c
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
>
> for all thats worth since I am not a i386 specialist.
>
> How much of the issues with page struct sharing between slab and arch code
> does this address?
I think the answer is 'none yet.' It
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
Acked-by: Christoph Lameter [EMAIL PROTECTED]
for all thats worth since I am not a i386 specialist.
How much of the issues with page struct sharing between slab and arch code
does this address?
I think the answer is 'none yet.' It uses page
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-04-02 at 14:39 -0700, Chris Wright wrote:
> > the part i know is broken is lapic broadcast, so i'd like to fix that
> > up too. trouble is, it's broken on vanilla too, so i'm not 100% sure
> > what i'm debuggi
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> On Sun, 2007-04-01 at 11:54 -0700, Chris Wright wrote:
> > * Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> > > On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote:
> > > > This series converts x86_64
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
On Sun, 2007-04-01 at 11:54 -0700, Chris Wright wrote:
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote:
This series converts x86_64 timers to clockevents drivers
and then enables dynticks
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
On Mon, 2007-04-02 at 14:39 -0700, Chris Wright wrote:
the part i know is broken is lapic broadcast, so i'd like to fix that
up too. trouble is, it's broken on vanilla too, so i'm not 100% sure
what i'm debugging yet.
You need to remove
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote:
> > This series converts x86_64 timers to clockevents drivers
> > and then enables dynticks. There's some minor cleanups along
> > the way. The lapic broadcast mechanism
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
On Sat, 2007-03-31 at 01:31 -0700, Chris Wright wrote:
This series converts x86_64 timers to clockevents drivers
and then enables dynticks. There's some minor cleanups along
the way. The lapic broadcast mechanism is untested, I'm sure
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> * Chris Wright <[EMAIL PROTECTED]> wrote:
> > This series converts x86_64 timers to clockevents drivers and then
> > enables dynticks. There's some minor cleanups along the way. The
> > lapic broadcast mechanism is untest
Everything is in place, so give the CONFIG_NO_HZ option.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: john stultz <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x8
This is how it's done on i386, and it makes one less bit
of code to trim from main_timer_handler() when converting
to clockevents.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: john stultz <
Convert lapic, pit and hpet based timers to clockevents.
This brings x86_64 in line with i386. And it is needed
to enable dynticks.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: john stultz <
Add tick_nohz_{stop,restart}_sched_tick to idle
loop in prepartion for turning on dynticks. These
are just noops until NO_HZ is enabled in next patch.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]&g
This series converts x86_64 timers to clockevents drivers
and then enables dynticks. There's some minor cleanups along
the way. The lapic broadcast mechanism is untested, I'm sure it
still needs work, there's still some cruft in lapic_setup_timer.
This is just for comments at this point, now
When making changes to x86_64 timers, I noticed that touching
hpet.h triggered an unreasonably large rebuild. Untangling
it from timex.h quiets the extra rebuild quite a bit.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
drivers/char/rtc.c
This series converts x86_64 timers to clockevents drivers
and then enables dynticks. There's some minor cleanups along
the way. The lapic broadcast mechanism is untested, I'm sure it
still needs work, there's still some cruft in lapic_setup_timer.
This is just for comments at this point, now
When making changes to x86_64 timers, I noticed that touching
hpet.h triggered an unreasonably large rebuild. Untangling
it from timex.h quiets the extra rebuild quite a bit.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
---
drivers/char/rtc.c |2
Convert lapic, pit and hpet based timers to clockevents.
This brings x86_64 in line with i386. And it is needed
to enable dynticks.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: john stultz [EMAIL PROTECTED]
Cc: Andi
Add tick_nohz_{stop,restart}_sched_tick to idle
loop in prepartion for turning on dynticks. These
are just noops until NO_HZ is enabled in next patch.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: john stultz [EMAIL
Everything is in place, so give the CONFIG_NO_HZ option.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: john stultz [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
---
arch/x86_64/Kconfig |2 ++
1 file changed, 2
This is how it's done on i386, and it makes one less bit
of code to trim from main_timer_handler() when converting
to clockevents.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: john stultz [EMAIL PROTECTED]
Cc: Andi Kleen
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Chris Wright [EMAIL PROTECTED] wrote:
This series converts x86_64 timers to clockevents drivers and then
enables dynticks. There's some minor cleanups along the way. The
lapic broadcast mechanism is untested, I'm sure it still needs work
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> William Lee Irwin III wrote:
> >>clone_pgd_range() for consistency? and it seems we lost a
> >>paravirt_alloc_pd_clone() in there somewhere.
> >>
> >
> >Yes, another reason why it shouldn't have been posted as-is. It was not
> >intended to for
gd) kmem_cache_free(pgd_cache, pgd)
>
> On Wed, Mar 28, 2007 at 03:26:56PM -0700, Chris Wright wrote:
> > I must've glazed over something, I thought this was removal of slabs?
>
> The pgd slab is not fully removable in the PAE case because a dedicated
> slab is the onl
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> +#ifdef CONFIG_HIGHMEM64G
> +#define __pgd_alloc()kmem_cache_alloc(pgd_cache,
> GFP_KERNEL|__GFP_REPEAT)
> +#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
I must've glazed over something, I thought this was
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
+#ifdef CONFIG_HIGHMEM64G
+#define __pgd_alloc()kmem_cache_alloc(pgd_cache,
GFP_KERNEL|__GFP_REPEAT)
+#define __pgd_free(pgd) kmem_cache_free(pgd_cache, pgd)
I must've glazed over something, I thought this was
, Mar 28, 2007 at 03:26:56PM -0700, Chris Wright wrote:
I must've glazed over something, I thought this was removal of slabs?
The pgd slab is not fully removable in the PAE case because a dedicated
slab is the only way to enforce alignment for allocations as small as
PAE PGD's.
Heh, yeah
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
William Lee Irwin III wrote:
clone_pgd_range() for consistency? and it seems we lost a
paravirt_alloc_pd_clone() in there somewhere.
Yes, another reason why it shouldn't have been posted as-is. It was not
intended to for anything more than
* Greg KH ([EMAIL PROTECTED]) wrote:
> From: Chris Wright <[EMAIL PROTECTED]>
>
> [IPV6] fix ipv6_getsockopt_sticky copy_to_user leak
>
> User supplied len < 0 can cause leak of kernel memory.
> Use unsigned compare instead.
You can drop this one.
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
> Is it truly critical to inline any of these instructions?
I don't have any current measurements. But we'd been aiming
at getting irq_{en,dis}able to a simple memory write to pda.
But simplicity, maintenance, etc. win over trimming a couple
cycles,
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
> Chris Wright <[EMAIL PROTECTED]> writes:
>
> > * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> >> > ENTRY(swapper_pg_dir)
> >> > +.align PAGE_SIZE_asm
> >> > .fill 1024,
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
Chris Wright [EMAIL PROTECTED] writes:
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
ENTRY(swapper_pg_dir)
+.align PAGE_SIZE_asm
.fill 1024,4,0
does the native kernel lose memory here?
Not in my builds.
Shouldn't
* Greg KH ([EMAIL PROTECTED]) wrote:
From: Chris Wright [EMAIL PROTECTED]
[IPV6] fix ipv6_getsockopt_sticky copy_to_user leak
User supplied len 0 can cause leak of kernel memory.
Use unsigned compare instead.
You can drop this one. It's dependent on a patch
that is not in 2.6.20
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
Is it truly critical to inline any of these instructions?
I don't have any current measurements. But we'd been aiming
at getting irq_{en,dis}able to a simple memory write to pda.
But simplicity, maintenance, etc. win over trimming a couple
cycles,
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > I mean like this (bunch of work, for a type check that we're really ignoring
> > anwyay, but this is the idea...)
>
> Oh, I see. I think this is the best argument yet for the current
> arrangem
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > how about __paravirt_nop_start < func < __paravirt_nop_end and preserve
> > the types?
> >
>
> Er? The reason for the (void *) cast is to stop gcc complaining about
> mismatched poi
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Ingo Molnar wrote:
> > but only as a cleanup of the current open-coded (void *) casts. My
> > problem with this is that it loses the types. Not that there is much to
> > check for, but still, this adds some assumptions about how function
> >
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > ENTRY(swapper_pg_dir)
> > + .align PAGE_SIZE_asm
> > .fill 1024,4,0
>
> does the native kernel lose memory here?
Not in my builds.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > That's been fixed, the two are built as seperate objects now.
>
> Actually, we tried it but it causes bad kernel images with some
> binutils, so it has to be included for now.
Ah, missed that.
>
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > Add a new mm function apply_to_page_range() which applies a given
> > function to every pte in a given virtual address range in a given mm
> > structure. This is a generic alternative to
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> please indicate any such review feedback (and approval) via
> signed-off-by lines done by that person.
Certainly, Greg didn't sign off, he simply gave review feedback.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > Core Xen Implementation
> >
> > This patch is a rollup of all the core pieces of the Xen
> > implementation, including booting, memory management, interrupts, time
> > and so on.
>
> > ---
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > This communicates with the machine control software via a registry
> > residing in a controlling virtual machine. This allows dynamic
> > creation, destruction and modification of virtual device
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
This communicates with the machine control software via a registry
residing in a controlling virtual machine. This allows dynamic
creation, destruction and modification of virtual device
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Core Xen Implementation
This patch is a rollup of all the core pieces of the Xen
implementation, including booting, memory management, interrupts, time
and so on.
---
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
please indicate any such review feedback (and approval) via
signed-off-by lines done by that person.
Certainly, Greg didn't sign off, he simply gave review feedback.
thanks,
-chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Add a new mm function apply_to_page_range() which applies a given
function to every pte in a given virtual address range in a given mm
structure. This is a generic alternative to cut-and-pasting
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
That's been fixed, the two are built as seperate objects now.
Actually, we tried it but it causes bad kernel images with some
binutils, so it has to be included for now.
Ah, missed that.
@@ -437,9 +437,9 @@ static
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
ENTRY(swapper_pg_dir)
+ .align PAGE_SIZE_asm
.fill 1024,4,0
does the native kernel lose memory here?
Not in my builds.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Ingo Molnar wrote:
but only as a cleanup of the current open-coded (void *) casts. My
problem with this is that it loses the types. Not that there is much to
check for, but still, this adds some assumptions about how function
calls look
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Chris Wright wrote:
how about __paravirt_nop_start func __paravirt_nop_end and preserve
the types?
Er? The reason for the (void *) cast is to stop gcc complaining about
mismatched pointer types.
I mean like this (bunch of work
601 - 700 of 1959 matches
Mail list logo
