* Andrew Morton ([EMAIL PROTECTED]) wrote:
> Sorry, but I can't be bothered splitting it up. Greg, Chris: please just
> apply the bits which apply and drop the other bits if that's OK.
Yup
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
* Andrew Morton ([EMAIL PROTECTED]) wrote:
Sorry, but I can't be bothered splitting it up. Greg, Chris: please just
apply the bits which apply and drop the other bits if that's OK.
Yup
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> In that case, it's almost certainly that that tree isn't doing the proper
> "git update-server-info" when people push to it.
Yup, should be fixed now.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
In that case, it's almost certainly that that tree isn't doing the proper
git update-server-info when people push to it.
Yup, should be fixed now.
thanks,
-chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
* Nish Aravamudan ([EMAIL PROTECTED]) wrote:
> On 7/12/07, Greg KH <[EMAIL PROTECTED]> wrote:
> > That is a tree that Chris did, and I didn't realize we were maintaining
> > it as the "official" stable tree, that is why it is not mentioned in the
> > release notes :)
>
> Fair enough -- it's just
* Nish Aravamudan ([EMAIL PROTECTED]) wrote:
On 7/12/07, Greg KH [EMAIL PROTECTED] wrote:
That is a tree that Chris did, and I didn't realize we were maintaining
it as the official stable tree, that is why it is not mentioned in the
release notes :)
Fair enough -- it's just a little bit
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> Ok by me, although I suspect a lot of the cases where the hpet one
> was needed got resolved with the PCI HPET resource fix But it's still
> safer to check.
>
> However I don't think patches should go into stable before they
> hit Linus' tree.
Agreed,
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> Andrew,
>
> On Wed, 2007-07-11 at 16:57 -0700, Andrew Morton wrote:
> > They all look pretty innocuous to me.
> >
> > Could you please take a second look, decide if any of them should also be
> > in 2.6.22.x and let me know?
>
>
* Andi Kleen ([EMAIL PROTECTED]) wrote:
> The equivalent to the powerpc way would be essentially to report i386
> into the x86-64 code base and leave the really old hardware only
> in arch/i386. I've considered doing it, but it would be an awful
> lot of work and to tempt distributions to actually
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> The HPET change, which is the larger part of the conversion set simply
> because we now share the code with i386, might be split out by disabling
> HPET in the first step, doing the PIT / APIC conversion and then the
> HPET one in a separate step.
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
> For example, we can make sure that the code in question that actually
> touches the hardware stays exactly the same, and then just move the
> interfaces around - and basically guarantee that _zero_ hardware-specific
> issues pop up when you switch
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Andrew - how do you feel about keeping this in the -mm tree until Linus,
> Andi, Ingo, and Thomas get on the same page (which may be around the 2.6.24
> merge window, by my guesstimate)?
Well, that's supposed to be Andi's tree and aggregated by
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
> (Note - I'm just a usually-confused crash test dummy here...)
>
> > Well I spent a lot of time making the x86-64 timing code work
> > well on a variety of machines; working around a wide
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> > If that isn't possible it needs very careful review which just hasn't
> > happened yet. But I'm not convinced even step by step is not possible
> > here.
>
> There is no step by step thing. You convert an arch to clock events or
> you convert it
> +static inline void bprm_clear_caps(struct linux_binprm *bprm)
> +{
> + cap_clear (bprm->cap_inheritable);
> + cap_clear (bprm->cap_permitted);
> + cap_clear (bprm->cap_effective);
While there, can you clean that bit up a touch?
cap_clear(bprm->cap_inheritable);
+static inline void bprm_clear_caps(struct linux_binprm *bprm)
+{
+ cap_clear (bprm-cap_inheritable);
+ cap_clear (bprm-cap_permitted);
+ cap_clear (bprm-cap_effective);
While there, can you clean that bit up a touch?
cap_clear(bprm-cap_inheritable);
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
If that isn't possible it needs very careful review which just hasn't
happened yet. But I'm not convinced even step by step is not possible
here.
There is no step by step thing. You convert an arch to clock events or
you convert it not.
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
On Wed, 11 Jul 2007 23:16:38 +0200, Andi Kleen said:
(Note - I'm just a usually-confused crash test dummy here...)
Well I spent a lot of time making the x86-64 timing code work
well on a variety of machines; working around a wide variety
of
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
Andrew - how do you feel about keeping this in the -mm tree until Linus,
Andi, Ingo, and Thomas get on the same page (which may be around the 2.6.24
merge window, by my guesstimate)?
Well, that's supposed to be Andi's tree and aggregated by Andrew
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
For example, we can make sure that the code in question that actually
touches the hardware stays exactly the same, and then just move the
interfaces around - and basically guarantee that _zero_ hardware-specific
issues pop up when you switch over,
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
The HPET change, which is the larger part of the conversion set simply
because we now share the code with i386, might be split out by disabling
HPET in the first step, doing the PIT / APIC conversion and then the
HPET one in a separate step.
The
* Andi Kleen ([EMAIL PROTECTED]) wrote:
The equivalent to the powerpc way would be essentially to report i386
into the x86-64 code base and leave the really old hardware only
in arch/i386. I've considered doing it, but it would be an awful
lot of work and to tempt distributions to actually use
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
Andrew,
On Wed, 2007-07-11 at 16:57 -0700, Andrew Morton wrote:
They all look pretty innocuous to me.
Could you please take a second look, decide if any of them should also be
in 2.6.22.x and let me know?
* Andi Kleen ([EMAIL PROTECTED]) wrote:
Ok by me, although I suspect a lot of the cases where the hpet one
was needed got resolved with the PCI HPET resource fix But it's still
safer to check.
However I don't think patches should go into stable before they
hit Linus' tree.
Agreed, we're
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Zachary Amsden wrote:
> >I'd rather keep it, even with bitrot - it was non-trivial to get
> >correct, and found many surprises in the code; most notably, it can
> >detect
> >
> >1) PTE writes to pages not declared as page tables
> >2) Failure to
LTIPLE_NODES dependency,
dunno if VMI has the same limitation). It definitely should not have
a misleading Kconfig name. I'd nuke it all rather than #if 0.
thanks,
-chris
--
Subject: [PATCH] VMI: remove CONFIG_DEBUG_PAGE_TYPE and associated bitrotted
code
From: Chris Wright <[EMAIL PROTECTE
if VMI has the same limitation). It definitely should not have
a misleading Kconfig name. I'd nuke it all rather than #if 0.
thanks,
-chris
--
Subject: [PATCH] VMI: remove CONFIG_DEBUG_PAGE_TYPE and associated bitrotted
code
From: Chris Wright [EMAIL PROTECTED]
Remove the poorly named (non Kconfig
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
Zachary Amsden wrote:
I'd rather keep it, even with bitrot - it was non-trivial to get
correct, and found many surprises in the code; most notably, it can
detect
1) PTE writes to pages not declared as page tables
2) Failure to allocate or
* Uli Luckas ([EMAIL PROTECTED]) wrote:
> On Tuesday, 3. July 2007, Chuck Ebbert wrote:
> > On 07/03/2007 03:28 PM, Chris Friesen wrote:
> > > Arne Georg Gleditsch wrote:
> > >> An interesting exercise might be to
> > >> code up a small program to call adjtimex with timex.status |= STA_INS,
> > >>
* Uli Luckas ([EMAIL PROTECTED]) wrote:
On Tuesday, 3. July 2007, Chuck Ebbert wrote:
On 07/03/2007 03:28 PM, Chris Friesen wrote:
Arne Georg Gleditsch wrote:
An interesting exercise might be to
code up a small program to call adjtimex with timex.status |= STA_INS,
to see if this
* Hawk Xu ([EMAIL PROTECTED]) wrote:
> Add hook inode_post_removexattr for updating inode security field after
> successful removexattr operation.
That is an insufficient explanation of why it's needed, who is using it,
etc.
thanks,
-chris
-
To unsubscribe from this list: send the line
* Hawk Xu ([EMAIL PROTECTED]) wrote:
Add hook inode_post_removexattr for updating inode security field after
successful removexattr operation.
That is an insufficient explanation of why it's needed, who is using it,
etc.
thanks,
-chris
-
To unsubscribe from this list: send the line
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> and simple LSMs that can be
> unloaded safely can permit it.
there are none, and making the above possible is prohibitively
expensive.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
* Crispin Cowan ([EMAIL PROTECTED]) wrote:
and simple LSMs that can be
unloaded safely can permit it.
there are none, and making the above possible is prohibitively
expensive.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
> Sigh, as much as I would *like* to stay out of this (I don't
> use modules at all on any system where I can avoid it), won't
> it make development - and especially testing - of new lsms
> much more painful and therefore less likely?
Dev, hopefully
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> Just hoping to avoid a change collision. If I have to deal
> with this today it's easy, if it doesn't show up anywhere
> until 2.6.28 I'm breezing, but if it all hits in two weeks I
> have some scrambling and yet another delay to deal with. Not
> your
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
> So, for planning purposes, when ought I expect to have to start
> dealing with this?
What is your specific concern or use case?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
* James Morris ([EMAIL PROTECTED]) wrote:
> On Sun, 24 Jun 2007, Chris Wright wrote:
>
> > * James Morris ([EMAIL PROTECTED]) wrote:
> > > -module_param_named(disable, capability_disable, int, 0);
> > > -MODULE_PARM_DESC(disable, "To disable capabil
* James Morris ([EMAIL PROTECTED]) wrote:
> -module_param_named(disable, capability_disable, int, 0);
> -MODULE_PARM_DESC(disable, "To disable capabilities module set disable = 1");
> +
> +static int __init capability_disable_setup(char *str)
> +{
> + capability_disable = simple_strtol(str,
* James Morris ([EMAIL PROTECTED]) wrote:
-module_param_named(disable, capability_disable, int, 0);
-MODULE_PARM_DESC(disable, To disable capabilities module set disable = 1);
+
+static int __init capability_disable_setup(char *str)
+{
+ capability_disable = simple_strtol(str, NULL, 0);
* James Morris ([EMAIL PROTECTED]) wrote:
On Sun, 24 Jun 2007, Chris Wright wrote:
* James Morris ([EMAIL PROTECTED]) wrote:
-module_param_named(disable, capability_disable, int, 0);
-MODULE_PARM_DESC(disable, To disable capabilities module set disable =
1);
+
+static int
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
So, for planning purposes, when ought I expect to have to start
dealing with this?
What is your specific concern or use case?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
* Casey Schaufler ([EMAIL PROTECTED]) wrote:
Just hoping to avoid a change collision. If I have to deal
with this today it's easy, if it doesn't show up anywhere
until 2.6.28 I'm breezing, but if it all hits in two weeks I
have some scrambling and yet another delay to deal with. Not
your
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
Sigh, as much as I would *like* to stay out of this (I don't
use modules at all on any system where I can avoid it), won't
it make development - and especially testing - of new lsms
much more painful and therefore less likely?
Dev, hopefully not.
* Chris Mason ([EMAIL PROTECTED]) wrote:
> I'm sure people there will have a different versions of events. The
> one part that was discussed was if pathname based security was
> useful, and a number of the people in the room (outside of
> novell) said it was. Now, it could be that nobody wanted
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Chris, thanks a hell of a lot for looking into this!!!
>
> -rt doesn't do much with paravirt, but since both -rt and lguest are two
> things I love to play with, it was really bothering me that they were
> not getting along.
It was bugging me too,
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> * Chris Wright <[EMAIL PROTECTED]> wrote:
> > Current -rt is broken when compiling with CONFIG_PARAVIRT and
> > CONFIG_MCOUNT both enabled. Because CONFIG_MCOUNT disables
> > CONFIG_REGPARM, the calling convention
debugging.
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
Patch against patch-2.6.21.5-rt17
arch/i386/kernel/paravirt.c | 98 ++--
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/para
debugging.
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
Patch against patch-2.6.21.5-rt17
arch/i386/kernel/paravirt.c | 98 ++--
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/arch/i386/kernel/paravirt.c b/arch/i386/kernel/paravirt.c
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
* Chris Wright [EMAIL PROTECTED] wrote:
Current -rt is broken when compiling with CONFIG_PARAVIRT and
CONFIG_MCOUNT both enabled. Because CONFIG_MCOUNT disables
CONFIG_REGPARM, the calling convention must once again be explicit
with fastcall
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
Chris, thanks a hell of a lot for looking into this!!!
-rt doesn't do much with paravirt, but since both -rt and lguest are two
things I love to play with, it was really bothering me that they were
not getting along.
It was bugging me too, now if
* Chris Mason ([EMAIL PROTECTED]) wrote:
I'm sure people there will have a different versions of events. The
one part that was discussed was if pathname based security was
useful, and a number of the people in the room (outside of
novell) said it was. Now, it could be that nobody wanted to
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Jay Vosburgh wrote:
> > The following patch (based on a patch from Stephen Hemminger
> ><[EMAIL PROTECTED]>) removes use after free conditions in
> >the unregister path for the bonding master. Without this patch, an
> >operation of the form "echo
* Jeff Garzik ([EMAIL PROTECTED]) wrote:
Jay Vosburgh wrote:
The following patch (based on a patch from Stephen Hemminger
[EMAIL PROTECTED]) removes use after free conditions in
the unregister path for the bonding master. Without this patch, an
operation of the form echo -bond0
* Stefan Richter ([EMAIL PROTECTED]) wrote:
> + Other kernel trees can be found listed at http://kernel.org/git and in
Should be http://git.kernel.org/ these days
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
* Stefan Richter ([EMAIL PROTECTED]) wrote:
+ Other kernel trees can be found listed at http://kernel.org/git and in
Should be http://git.kernel.org/ these days
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
* Nish Aravamudan ([EMAIL PROTECTED]) wrote:
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=summary
> shows 2.6.21.1 as the last 2.6.21.Y release. Is that intentional?
Updated, thanks.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
* Nish Aravamudan ([EMAIL PROTECTED]) wrote:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=summary
shows 2.6.21.1 as the last 2.6.21.Y release. Is that intentional?
Updated, thanks.
-chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
* Stephane Eranian ([EMAIL PROTECTED]) wrote:
> * allocate_msrs() allocates two tables per CPU. One for the
>counters, the other for the eventsel registers. But then
>nmi_setup() copies the cpu_msrs[0] into cpu_msrs[] of all
>other cpus. This operation overrides the
* Chris Rankin ([EMAIL PROTECTED]) wrote:
> Shouldn't this patch from Tejun be applied to 2.6.21.x as well as 2.6.20.x?
>
> Tejun Heo (2):
> ...
> driver-core: don't free devt_attr till the device is released
It is in both.
thanks,
-chris
-
To unsubscribe from this list: send the
* Pallipadi, Venkatesh ([EMAIL PROTECTED]) wrote:
> > * Thomas Gleixner (mailto:[EMAIL PROTECTED]) wrote:
> > I fixed this against -mm already. I don't think that it is relevant for
> > stable. The issue was found with Venkis hpet force enable patches on a
> > ICH4 system. I doubt that any of
* Pallipadi, Venkatesh ([EMAIL PROTECTED]) wrote:
* Thomas Gleixner (mailto:[EMAIL PROTECTED]) wrote:
I fixed this against -mm already. I don't think that it is relevant for
stable. The issue was found with Venkis hpet force enable patches on a
ICH4 system. I doubt that any of those
* Chris Rankin ([EMAIL PROTECTED]) wrote:
Shouldn't this patch from Tejun be applied to 2.6.21.x as well as 2.6.20.x?
Tejun Heo (2):
...
driver-core: don't free devt_attr till the device is released
It is in both.
thanks,
-chris
-
To unsubscribe from this list: send the line
* Stephane Eranian ([EMAIL PROTECTED]) wrote:
* allocate_msrs() allocates two tables per CPU. One for the
counters, the other for the eventsel registers. But then
nmi_setup() copies the cpu_msrs[0] into cpu_msrs[] of all
other cpus. This operation overrides the cpu_msrs[].counters
TED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
[chrisw: rebase against Len's changes in -mm]
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
drivers/acpi/processor_idle.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/proc
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
> The PC-speaker code has a quite creative method to serialize access to
> the PIT: It uses a local lock.
>
> On i386 and x86_64 the access to the PIT is serialized by a lock in the
> architecture code. The separate locking in the PC-speaker code
* Paul Albrecht ([EMAIL PROTECTED]) wrote:
> Yes, i8042.noaux works. Here's the dmesg output:
>
> Linux version 2.6.21.4 ([EMAIL PROTECTED]) (gcc version 3.3.3) #1
Does 2.6.21.5 work w/out noaux on command line?
thanks
-chris
-
To unsubscribe from this list: send the line "unsubscribe
Auke Kok (1):
e1000: disable polling before registering netdevice
Björn Steinbrink (1):
timer statistics: fix race
Chris Wright (2):
x86: fix oprofile double free
Linux 2.6.21.5
Daniel Drake (2):
ALSA: usb-audio: explicitly match Logitech QuickCam
zd1211rw: Add
diff --git a/Makefile b/Makefile
index a87a7d1..710c004 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION = .13
+EXTRAVERSION = .14
NAME = Homicidal Dwarf Hamster
# *DOCUMENTATION*
diff --git a/arch/arm/mach-iop13xx/pci.c
mod_timer() interval
ntfs_init_locked_inode(): fix array indexing
Andy Green (1):
kbuild: fixdep segfault on pathological string-o-death
Chris Wright (1):
Linux 2.6.20.14
Dan Williams (1):
iop13xx: fix i/o address translation
Daniel Drake (1):
ALSA: usb-audio
mod_timer() interval
ntfs_init_locked_inode(): fix array indexing
Andy Green (1):
kbuild: fixdep segfault on pathological string-o-death
Chris Wright (1):
Linux 2.6.20.14
Dan Williams (1):
iop13xx: fix i/o address translation
Daniel Drake (1):
ALSA: usb-audio
diff --git a/Makefile b/Makefile
index a87a7d1..710c004 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 20
-EXTRAVERSION = .13
+EXTRAVERSION = .14
NAME = Homicidal Dwarf Hamster
# *DOCUMENTATION*
diff --git a/arch/arm/mach-iop13xx/pci.c
Auke Kok (1):
e1000: disable polling before registering netdevice
Björn Steinbrink (1):
timer statistics: fix race
Chris Wright (2):
x86: fix oprofile double free
Linux 2.6.21.5
Daniel Drake (2):
ALSA: usb-audio: explicitly match Logitech QuickCam
zd1211rw: Add
* Paul Albrecht ([EMAIL PROTECTED]) wrote:
Yes, i8042.noaux works. Here's the dmesg output:
Linux version 2.6.21.4 ([EMAIL PROTECTED]) (gcc version 3.3.3) #1
Does 2.6.21.5 work w/out noaux on command line?
thanks
-chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
* Thomas Gleixner ([EMAIL PROTECTED]) wrote:
The PC-speaker code has a quite creative method to serialize access to
the PIT: It uses a local lock.
On i386 and x86_64 the access to the PIT is serialized by a lock in the
architecture code. The separate locking in the PC-speaker code ignores
-by: Thomas Gleixner [EMAIL PROTECTED]
[chrisw: rebase against Len's changes in -mm]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
drivers/acpi/processor_idle.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi
* Chris Wright ([EMAIL PROTECTED]) wrote:
> Roll-up patch available at:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.21.5-rc1.{gz,bz2}
Roll-up updated to fix broken aacraid patch:
http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch
* Greg KH ([EMAIL PROTECTED]) wrote:
> On Fri, Jun 08, 2007 at 10:47:29AM -0700, Chris Wright wrote:
> > * Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> > > Maybe a mailing list for stable-commits could be added, like mm-commits?
> >
> > I was thinking the same thing.
platform function
pointer. The enclosed patch, unmodified as tested by Rainer, solves the
problem.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
[chrisw: backport to 2.6.21.4]
* Salyzyn, Mark ([EMAIL PROTECTED]) wrote:
> Yes, split the patch into the two pieces for 2.6.21.1/2.6.21.4
Sorry, didn't parse. Are you suggesting to use the patch I included
(which simply drops the ->adapter_restart init), or the original patch
plus Mark Havercamp's patch to add
* Theodore Tso ([EMAIL PROTECTED]) wrote:
> If this doesn't fix a user-visiable bug, should we be including it in
> the stable patch series? (Assuming that it doesn't, I wouldn't, but I
> tend to be more conservative about what I would include in a stable
> production release.)
Rolf, despite
* Chuck Ebbert ([EMAIL PROTECTED]) wrote:
> Maybe a mailing list for stable-commits could be added, like mm-commits?
I was thinking the same thing.
thanks,
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
: Mark Salyzyn <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
[chrisw: backport to 2.6.21.4]
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/aacraid.h |1 +
drivers/scsi/aacr
* Chris Wright ([EMAIL PROTECTED]) wrote:
> Roll-up patch available at:
>
> http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.20.14-rc1.{gz,bz2}
Roll-up updated to fix broken patch.
http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.
OTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
[chrisw: backport to 2.6.20]
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
net/core/dev.c | 10 ++
net/core/net-sysfs.c |8 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
--- linux-2
* Fortier,Vincent [Montreal] ([EMAIL PROTECTED]) wrote:
> I have encoutered a bug using fixdep when compiling the Apani VPN
> contivity client v3.3 (v3.5 seems fine). The bug started happening with
> the release of the 2948 build of FC6 kernel (corresponding to a post
> 2.6.20.7) and caused
PROTECTED]>
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
X-Git-Url:
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinu
til we found the root cause of that problem.
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
kernel/time/tick-sched
* Chris Wright ([EMAIL PROTECTED]) wrote:
> This is the start of the stable review cycle for the 2.6.21.5 release.
> There are 54 patches in this series, all will be posted as a response
Roll-up patch available at:
http://www.kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.
* Chris Wright ([EMAIL PROTECTED]) wrote:
> This is the start of the stable review cycle for the 2.6.20.14 release.
> There are 32 patches in this series, all will be posted as a response
Roll-up patch available at:
http://www.kernel.org/pub/linux/kernel/v2.6/stable-review
rything and retry the lookup.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/net/af_unix.h |8 +--
net/unix/af_unix.c| 127 +++-
ROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
net/bluetooth/hci_sock.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.21.4.orig/n
13-bit, this the mask being
tested against the PTE was 0x1000 sign-extended to 32-bits
instead of just plain 0x1000.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/sp
-stable review patch. If anyone has any objections, please let us know.
-
From: Kazunori MIYAZAWA <[EMAIL PROTECTED]>
---
net/ipv4/xfrm4_input.c |6 ++
net/ipv4/xfrm4_mode_tunnel.c |2 ++
net/ipv6/xfrm6_input.c |6 ++
ddress is completely parsed. This
function is indeed called from nf_conntrack_sip.c in this way to parse
textual ip:port combinations which fails due to the reason stated above.
Signed-off-by: Jerome Borsboom <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Si
Cc: "Christoph Lameter" <[EMAIL PROTECTED]>
Acked-by: Anton Altaparmakov <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signe
t
info for the offline CPUs. This results in a stuck for ever call to
smp_call_function_single() on an offline CPU.
Ignore the bogus information and print a kernel error to remind ACPI
folks to fix it.
Affects 2.6.21 / 2.6.22-rc
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Chris Wr
erface is chosen as ICMP source address since skb->dev doesn't
point to the incoming interface anymore.
Fix this by doing an interface lookup on rt->dst.iif and using that device.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]&
off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
include/linux/workqueue.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.21.4.orig/include/linux/workqueu
-stable review patch. If anyone has any objections, please let us know.
-
From: David Miller <[EMAIL PROTECTED]>
Noticed by Matvejchikov Ilya.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
Signed-
101 - 200 of 1959 matches
Mail list logo
