This is the start of the stable review cycle for the 2.6.25.6 release.
There are 50 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let us know. If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email [email protected]
to add your name to the list. If you want to be off the reviewer list,
also email us.
Responses should be made by Mon, Jun 9 01:00 UTC.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.6-rc1.gz
and the diffstat can be found below.
thanks,
the -stable release team
--
Makefile | 2 +-
arch/powerpc/kernel/smp.c | 2 +
arch/powerpc/mm/slb.c | 21 +++--
arch/x86/kernel/apic_64.c | 2 +-
arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c | 10 ++
arch/x86/kernel/irq_32.c | 2 +-
arch/x86/kernel/process_32.c | 5 +-
arch/x86/kernel/process_64.c | 5 +-
arch/x86/kernel/ptrace.c | 7 +-
arch/x86/kernel/tsc_32.c | 38 ++++----
arch/x86/kernel/tsc_64.c | 5 +-
arch/x86/pci/common.c | 17 ----
block/genhd.c | 9 ++-
drivers/ata/libata-core.c | 12 +++
drivers/block/brd.c | 1 +
drivers/cpufreq/cpufreq.c | 4 +-
drivers/hid/hid-input.c | 5 +-
drivers/hid/usbhid/hid-quirks.c | 38 ++++----
drivers/i2c/busses/i2c-nforce2.c | 28 +++++-
drivers/i2c/chips/max6875.c | 3 -
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 6 ++
drivers/md/md.c | 2 +-
drivers/md/raid5.c | 10 ++-
drivers/net/atl1/atl1_main.c | 1 +
drivers/net/ps3_gelic_wireless.c | 2 +
drivers/usb/class/cdc-acm.c | 3 +
drivers/usb/host/ohci-omap.c | 3 +-
drivers/usb/host/ohci-sm501.c | 3 +-
drivers/usb/misc/ldusb.c | 4 -
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio.h | 6 ++
drivers/usb/serial/option.c | 9 ++-
drivers/usb/serial/pl2303.c | 1 -
drivers/usb/serial/pl2303.h | 1 -
drivers/usb/storage/unusual_devs.h | 10 ++
fs/cifs/inode.c | 15 +++-
fs/ecryptfs/ecryptfs_kernel.h | 2 -
fs/ecryptfs/read_write.c | 22 -----
fs/ext3/xattr.c | 5 +
fs/ext4/xattr.c | 5 +
fs/proc/array.c | 2 +-
fs/proc/base.c | 33 ++++++--
fs/proc/task_mmu.c | 28 ++----
fs/xfs/linux-2.6/xfs_buf.c | 24 ++++-
fs/xfs/linux-2.6/xfs_buf.h | 19 ++++
include/asm-x86/tlbflush.h | 13 +++-
include/linux/capability.h | 29 +++++--
include/linux/genhd.h | 4 +-
include/linux/hid.h | 1 +
include/linux/types.h | 4 +-
init/do_mounts.c | 27 ++++++-
kernel/capability.c | 111 ++++++++++++++++--------
kernel/cgroup.c | 2 +-
mm/memory_hotplug.c | 78 ++++++++--------
mm/mmap.c | 8 ++-
mm/page_alloc.c | 3 +-
net/ipv6/netfilter/nf_conntrack_reasm.c | 8 +-
net/netfilter/nf_conntrack_expect.c | 4 +-
net/netfilter/xt_connlimit.c | 3 +-
net/netfilter/xt_iprange.c | 2 +
security/smack/smack_lsm.c | 12 +++
61 files changed, 483 insertions(+), 259 deletions(-)
On Fri, 6 Jun 2008, Chris Wright wrote:
> This is the start of the stable review cycle for the 2.6.25.6 release.
> There are 50 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let us know. If anyone is a maintainer of the proper subsystem, and
> wants to add a Signed-off-by: line to the patch, please respond with it.
Please add 2.6.26-rc5's 2884f110d5409714f3a04eeb6d2ecd77da66b242
into 2.6.25.6: it's actually not a serious problem, but it does
look as if it's a serious problem, so we should stamp it out.
Thanks,
Hugh
x86: fix bad pmd ffff810000207xxx(9090909090909090)
OGAWA Hirofumi and Fede have reported rare pmd_ERROR messages:
mm/memory.c:127: bad pmd ffff810000207xxx(9090909090909090).
Initialization's cleanup_highmap was leaving alignment filler
behind in the pmd for MODULES_VADDR: when vmalloc's guard page
would occupy a new page table, it's not allocated, and then
module unload's vfree hits the bad 9090 pmd entry left over.
Signed-off-by: Hugh Dickins <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 32ba13b..998a06e 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -206,7 +206,7 @@ void __init cleanup_highmap(void)
pmd_t *last_pmd = pmd + PTRS_PER_PMD;
for (; pmd < last_pmd; pmd++, vaddr += PMD_SIZE) {
- if (!pmd_present(*pmd))
+ if (pmd_none(*pmd))
continue;
if (vaddr < (unsigned long) _text || vaddr > end)
set_pmd(pmd, __pmd(0));
* Hugh Dickins ([email protected]) wrote:
> Please add 2.6.26-rc5's 2884f110d5409714f3a04eeb6d2ecd77da66b242
> into 2.6.25.6: it's actually not a serious problem, but it does
> look as if it's a serious problem, so we should stamp it out.
Got it, thanks for the reminder.
-chris
David Miller wrote:
> From: Herbert Xu <[email protected]>
> Date: Tue, 20 May 2008 17:25:11 +0800
>
>> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
>> >
>> > I hope this helps.
>>
>> OK found the problem, it was my fault after all :)
>>
>> Dave, this patch needs to go into stable too.
>>
>> [IPSEC]: Use the correct ip_local_out function
>>
>> Because the IPsec output function xfrm_output_resume does its
>> own dst_output call it should always call __ip_local_output
>> instead of ip_local_output as the latter may invoke dst_output
>> directly. Otherwise the return values from nf_hook and dst_output
>> may clash as they both use the value 1 but for different purposes.
>>
>> When that clash occurs this can cause a packet to be used after
>> it has been freed which usually leads to a crash. Because the
>> offending value is only returned from dst_output with qdiscs
>> such as HTB, this bug is normally not visible.
>>
>> Thanks to Marco Berizzi for his perseverance in tracking this
>> down.
>>
>> Signed-off-by: Herbert Xu <[email protected]>
>
> Applied and queued to -stable, thanks!
Hi David,
I don't see this patch in Chris 2.6.25.6 -stable review message.
On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
> David Miller wrote:
>
> > From: Herbert Xu <[email protected]>
> > Date: Tue, 20 May 2008 17:25:11 +0800
> >
> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> >> >
> >> > I hope this helps.
> >>
> >> OK found the problem, it was my fault after all :)
> >>
> >> Dave, this patch needs to go into stable too.
> >>
> >> [IPSEC]: Use the correct ip_local_out function
> >>
> >> Because the IPsec output function xfrm_output_resume does its
> >> own dst_output call it should always call __ip_local_output
> >> instead of ip_local_output as the latter may invoke dst_output
> >> directly. Otherwise the return values from nf_hook and dst_output
> >> may clash as they both use the value 1 but for different purposes.
> >>
> >> When that clash occurs this can cause a packet to be used after
> >> it has been freed which usually leads to a crash. Because the
> >> offending value is only returned from dst_output with qdiscs
> >> such as HTB, this bug is normally not visible.
> >>
> >> Thanks to Marco Berizzi for his perseverance in tracking this
> >> down.
> >>
> >> Signed-off-by: Herbert Xu <[email protected]>
> >
> > Applied and queued to -stable, thanks!
>
> Hi David,
>
> I don't see this patch in Chris 2.6.25.6 -stable review message.
Is it already in mainline ? (stable should only contain already merged
patches). It generally helps the stable team if you indicate the commit
id, as it's easier to "git show" than to "git log|grep".
Regards,
Willy
Willy Tarreau wrote:
> On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
>> David Miller wrote:
>>
>> > From: Herbert Xu <[email protected]>
>> > Date: Tue, 20 May 2008 17:25:11 +0800
>> >
>> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
>> >> >
>> >> > I hope this helps.
>> >>
>> >> OK found the problem, it was my fault after all :)
>> >>
>> >> Dave, this patch needs to go into stable too.
>> >>
>> >> [IPSEC]: Use the correct ip_local_out function
>> >>
>> >> Because the IPsec output function xfrm_output_resume does its
>> >> own dst_output call it should always call __ip_local_output
>> >> instead of ip_local_output as the latter may invoke dst_output
>> >> directly. Otherwise the return values from nf_hook and dst_output
>> >> may clash as they both use the value 1 but for different purposes.
>> >>
>> >> When that clash occurs this can cause a packet to be used after
>> >> it has been freed which usually leads to a crash. Because the
>> >> offending value is only returned from dst_output with qdiscs
>> >> such as HTB, this bug is normally not visible.
>> >>
>> >> Thanks to Marco Berizzi for his perseverance in tracking this
>> >> down.
>> >>
>> >> Signed-off-by: Herbert Xu <[email protected]>
>> >
>> > Applied and queued to -stable, thanks!
>>
>> Hi David,
>>
>> I don't see this patch in Chris 2.6.25.6 -stable review message.
>
> Is it already in mainline ?
yes, since 2008/05/20
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3
On Sun, Jun 08, 2008 at 01:56:01PM +0200, Marco Berizzi wrote:
> Willy Tarreau wrote:
>
> > On Sat, Jun 07, 2008 at 10:27:58PM +0200, Marco Berizzi wrote:
> >> David Miller wrote:
> >>
> >> > From: Herbert Xu <[email protected]>
> >> > Date: Tue, 20 May 2008 17:25:11 +0800
> >> >
> >> >> On Wed, May 14, 2008 at 10:19:57AM +0200, Marco Berizzi wrote:
> >> >> >
> >> >> > I hope this helps.
> >> >>
> >> >> OK found the problem, it was my fault after all :)
> >> >>
> >> >> Dave, this patch needs to go into stable too.
> >> >>
> >> >> [IPSEC]: Use the correct ip_local_out function
> >> >>
> >> >> Because the IPsec output function xfrm_output_resume does its
> >> >> own dst_output call it should always call __ip_local_output
> >> >> instead of ip_local_output as the latter may invoke dst_output
> >> >> directly. Otherwise the return values from nf_hook and dst_output
> >> >> may clash as they both use the value 1 but for different purposes.
> >> >>
> >> >> When that clash occurs this can cause a packet to be used after
> >> >> it has been freed which usually leads to a crash. Because the
> >> >> offending value is only returned from dst_output with qdiscs
> >> >> such as HTB, this bug is normally not visible.
> >> >>
> >> >> Thanks to Marco Berizzi for his perseverance in tracking this
> >> >> down.
> >> >>
> >> >> Signed-off-by: Herbert Xu <[email protected]>
> >> >
> >> > Applied and queued to -stable, thanks!
> >>
> >> Hi David,
> >>
> >> I don't see this patch in Chris 2.6.25.6 -stable review message.
> >
> > Is it already in mainline ?
>
> yes, since 2008/05/20
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3
Indeed. Most likely it was simply lost somewhere in the e-mail chain.
Then best thing to do is to retransmit it for next batch of patches.
Chris, here's the fix in question.
Thanks,
Willy
--
>From 1ac06e0306d0192a7a4d9ea1c9e06d355ce7e7d3 Mon Sep 17 00:00:00 2001
From: Herbert Xu <[email protected]>
Date: Tue, 20 May 2008 14:32:14 -0700
Subject: ipsec: Use the correct ip_local_out function
Because the IPsec output function xfrm_output_resume does its
own dst_output call it should always call __ip_local_output
instead of ip_local_output as the latter may invoke dst_output
directly. Otherwise the return values from nf_hook and dst_output
may clash as they both use the value 1 but for different purposes.
When that clash occurs this can cause a packet to be used after
it has been freed which usually leads to a crash. Because the
offending value is only returned from dst_output with qdiscs
such as HTB, this bug is normally not visible.
Thanks to Marco Berizzi for his perseverance in tracking this
down.
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
---
net/ipv4/route.c | 2 +-
net/ipv6/route.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 92f90ae..df41026 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -160,7 +160,7 @@ static struct dst_ops ipv4_dst_ops = {
.negative_advice = ipv4_negative_advice,
.link_failure = ipv4_link_failure,
.update_pmtu = ip_rt_update_pmtu,
- .local_out = ip_local_out,
+ .local_out = __ip_local_out,
.entry_size = sizeof(struct rtable),
.entries = ATOMIC_INIT(0),
};
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b7a4a87..48534c6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -109,7 +109,7 @@ static struct dst_ops ip6_dst_ops_template = {
.negative_advice = ip6_negative_advice,
.link_failure = ip6_link_failure,
.update_pmtu = ip6_rt_update_pmtu,
- .local_out = ip6_local_out,
+ .local_out = __ip6_local_out,
.entry_size = sizeof(struct rt6_info),
.entries = ATOMIC_INIT(0),
};
--
1.5.3.8
From: Willy Tarreau <[email protected]>
Date: Sun, 8 Jun 2008 14:36:01 +0200
> Indeed. Most likely it was simply lost somewhere in the e-mail chain.
> Then best thing to do is to retransmit it for next batch of patches.
> Chris, here's the fix in question.
It did not get lost at all, it's perfectly sitting in my
networking -stable queue waiting for me to have an
opportunity to submit it to the -stable folks after I do
some testing.
If you ask me in the future about the status of a -stable
patch from the networking, I'll let you know exactly what
is happening to that patch wrt. stable. I rarely forget
to submit an appropriate patch, and when I do forget you
merely have to let me know (rather than submitting it
to -stable directly, please don't do that) so that I can
fit it in with what I plan to submit to -stable already.
Right now is an unusual situation where I am in a 3 week
period of near constant travel, otherwise all of this
stuff would have been submitted already. As I stated in
another reply to you, that period is ending tomorrow so I
should be able to crank out all of these patches to -stable
some time this week.
Thanks.
On Sun, Jun 08, 2008 at 07:10:51AM -0700, David Miller wrote:
> From: Willy Tarreau <[email protected]>
> Date: Sun, 8 Jun 2008 14:36:01 +0200
>
> > Indeed. Most likely it was simply lost somewhere in the e-mail chain.
> > Then best thing to do is to retransmit it for next batch of patches.
> > Chris, here's the fix in question.
>
> It did not get lost at all, it's perfectly sitting in my
> networking -stable queue waiting for me to have an
> opportunity to submit it to the -stable folks after I do
> some testing.
>
> If you ask me in the future about the status of a -stable
> patch from the networking, I'll let you know exactly what
> is happening to that patch wrt. stable. I rarely forget
> to submit an appropriate patch, and when I do forget you
> merely have to let me know (rather than submitting it
> to -stable directly, please don't do that) so that I can
> fit it in with what I plan to submit to -stable already.
OK
> Right now is an unusual situation where I am in a 3 week
> period of near constant travel, otherwise all of this
> stuff would have been submitted already. As I stated in
> another reply to you, that period is ending tomorrow so I
> should be able to crank out all of these patches to -stable
> some time this week.
Perfect, thank you David.
Willy
On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
David Miller <[email protected]> wrote:
> If you ask me in the future about the status of a -stable
> patch from the networking, I'll let you know exactly what
> is happening to that patch wrt. stable. I rarely forget
> to submit an appropriate patch, and when I do forget you
> merely have to let me know (rather than submitting it
> to -stable directly, please don't do that) so that I can
> fit it in with what I plan to submit to -stable already.
As a netdev driver maintainer, I've been following this workflow for
patches that need to go to -stable:
1. I submit a mainline patch to Jeff Garzik.
2. Jeff submits to David.
3. David submits to Linus.
4. Linus merges patch into mainline.
5. I extract mainline commit ID.
6. I apply and test patch against appropriate 2.6.x.y git tree.
7. I submit patch directly to -stable.
David's admonition tells me I'm doing it wrong, and that I should
submit the stable patch to Jeff as well. Am I right?
Jay
On Sun, Jun 08, 2008 at 10:38:35AM -0500, Jay Cliburn wrote:
> On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
> David Miller <[email protected]> wrote:
>
>
> > If you ask me in the future about the status of a -stable
> > patch from the networking, I'll let you know exactly what
> > is happening to that patch wrt. stable. I rarely forget
> > to submit an appropriate patch, and when I do forget you
> > merely have to let me know (rather than submitting it
> > to -stable directly, please don't do that) so that I can
> > fit it in with what I plan to submit to -stable already.
>
>
> As a netdev driver maintainer, I've been following this workflow for
> patches that need to go to -stable:
>
> 1. I submit a mainline patch to Jeff Garzik.
> 2. Jeff submits to David.
> 3. David submits to Linus.
> 4. Linus merges patch into mainline.
> 5. I extract mainline commit ID.
> 6. I apply and test patch against appropriate 2.6.x.y git tree.
> 7. I submit patch directly to -stable.
>
> David's admonition tells me I'm doing it wrong, and that I should
> submit the stable patch to Jeff as well. Am I right?
The normal recommended method to get patches automatically sent to
stable is to add a "Cc: [email protected]" line above your signed-off-by
line. That way it is automatically sent to stable when Linus merges it,
and David gets notified. This should *theorically* save him some of the
work consisting in checking his stable queue for unmerged patches, but
his workflow may be different. Also, this method is particularly suited
to ensure that patches don't get lost when the maintainer does not have
a specific stable queue, which is not the case here, according to David.
Regards,
Willy
Jay Cliburn wrote:
> On Sun, 08 Jun 2008 07:10:51 -0700 (PDT)
> David Miller <[email protected]> wrote:
>
>
>> If you ask me in the future about the status of a -stable
>> patch from the networking, I'll let you know exactly what
>> is happening to that patch wrt. stable. I rarely forget
>> to submit an appropriate patch, and when I do forget you
>> merely have to let me know (rather than submitting it
>> to -stable directly, please don't do that) so that I can
>> fit it in with what I plan to submit to -stable already.
>
>
> As a netdev driver maintainer, I've been following this workflow for
> patches that need to go to -stable:
>
> 1. I submit a mainline patch to Jeff Garzik.
> 2. Jeff submits to David.
> 3. David submits to Linus.
> 4. Linus merges patch into mainline.
> 5. I extract mainline commit ID.
> 6. I apply and test patch against appropriate 2.6.x.y git tree.
> 7. I submit patch directly to -stable.
>
> David's admonition tells me I'm doing it wrong, and that I should
> submit the stable patch to Jeff as well. Am I right?
I usually encourage a more-parallel process where you simply email
[email protected] with the upstream commit id of the change(s) in question.
Jeff
From: Jeff Garzik <[email protected]>
Date: Sun, 08 Jun 2008 16:07:47 -0400
> Jay Cliburn wrote:
> > David's admonition tells me I'm doing it wrong, and that I should
> > submit the stable patch to Jeff as well. Am I right?
>
> I usually encourage a more-parallel process where you simply email
> [email protected] with the upstream commit id of the change(s) in question.
Right, and if Jeff wants to work things that way for the
networking drivers that's fine.
Personally, I like to make sure some time passes between when
a fix goes into Linus's tree and when I push it into -stable
because time is often what shakes out the last remaining problems
introduced by some change no matter how seeming obvious the
patch is.