This is the start of the stable review cycle for the 2.6.14.7 release.
There are 6 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 Monday, January 30, 00:00:00 UTC. Anything
received after that time, might be too late.
thanks,
the -stable release team
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <[email protected]>
The PPTP NAT helper calculates the offset at which the packet needs
to be mangled as difference between two pointers to the header. With
non-linear skbs however the pointers may point to two seperate buffers
on the stack and the calculation results in a wrong offset beeing
used.
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/netfilter/ip_nat_helper_pptp.c | 57 +++++++++++++++-----------------
1 file changed, 27 insertions(+), 30 deletions(-)
--- linux-2.6.14.6.orig/net/ipv4/netfilter/ip_nat_helper_pptp.c
+++ linux-2.6.14.6/net/ipv4/netfilter/ip_nat_helper_pptp.c
@@ -148,14 +148,14 @@ pptp_outbound_pkt(struct sk_buff **pskb,
{
struct ip_ct_pptp_master *ct_pptp_info = &ct->help.ct_pptp_info;
struct ip_nat_pptp *nat_pptp_info = &ct->nat.help.nat_pptp_info;
-
- u_int16_t msg, *cid = NULL, new_callid;
+ u_int16_t msg, new_callid;
+ unsigned int cid_off;
new_callid = htons(ct_pptp_info->pns_call_id);
switch (msg = ntohs(ctlh->messageType)) {
case PPTP_OUT_CALL_REQUEST:
- cid = &pptpReq->ocreq.callID;
+ cid_off = offsetof(union pptp_ctrl_union, ocreq.callID);
/* FIXME: ideally we would want to reserve a call ID
* here. current netfilter NAT core is not able to do
* this :( For now we use TCP source port. This breaks
@@ -172,10 +172,10 @@ pptp_outbound_pkt(struct sk_buff **pskb,
ct_pptp_info->pns_call_id = ntohs(new_callid);
break;
case PPTP_IN_CALL_REPLY:
- cid = &pptpReq->icreq.callID;
+ cid_off = offsetof(union pptp_ctrl_union, icreq.callID);
break;
case PPTP_CALL_CLEAR_REQUEST:
- cid = &pptpReq->clrreq.callID;
+ cid_off = offsetof(union pptp_ctrl_union, clrreq.callID);
break;
default:
DEBUGP("unknown outbound packet 0x%04x:%s\n", msg,
@@ -197,18 +197,15 @@ pptp_outbound_pkt(struct sk_buff **pskb,
/* only OUT_CALL_REQUEST, IN_CALL_REPLY, CALL_CLEAR_REQUEST pass
* down to here */
-
- IP_NF_ASSERT(cid);
-
DEBUGP("altering call id from 0x%04x to 0x%04x\n",
- ntohs(*cid), ntohs(new_callid));
+ ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
/* mangle packet */
if (ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
- (void *)cid - ((void *)ctlh - sizeof(struct pptp_pkt_hdr)),
- sizeof(new_callid),
- (char *)&new_callid,
- sizeof(new_callid)) == 0)
+ cid_off + sizeof(struct pptp_pkt_hdr) +
+ sizeof(struct PptpControlHeader),
+ sizeof(new_callid), (char *)&new_callid,
+ sizeof(new_callid)) == 0)
return NF_DROP;
return NF_ACCEPT;
@@ -297,7 +294,8 @@ pptp_inbound_pkt(struct sk_buff **pskb,
union pptp_ctrl_union *pptpReq)
{
struct ip_nat_pptp *nat_pptp_info = &ct->nat.help.nat_pptp_info;
- u_int16_t msg, new_cid = 0, new_pcid, *pcid = NULL, *cid = NULL;
+ u_int16_t msg, new_cid = 0, new_pcid;
+ unsigned int pcid_off, cid_off = 0;
int ret = NF_ACCEPT, rv;
@@ -305,23 +303,23 @@ pptp_inbound_pkt(struct sk_buff **pskb,
switch (msg = ntohs(ctlh->messageType)) {
case PPTP_OUT_CALL_REPLY:
- pcid = &pptpReq->ocack.peersCallID;
- cid = &pptpReq->ocack.callID;
+ pcid_off = offsetof(union pptp_ctrl_union, ocack.peersCallID);
+ cid_off = offsetof(union pptp_ctrl_union, ocack.callID);
break;
case PPTP_IN_CALL_CONNECT:
- pcid = &pptpReq->iccon.peersCallID;
+ pcid_off = offsetof(union pptp_ctrl_union, iccon.peersCallID);
break;
case PPTP_IN_CALL_REQUEST:
/* only need to nat in case PAC is behind NAT box */
return NF_ACCEPT;
case PPTP_WAN_ERROR_NOTIFY:
- pcid = &pptpReq->wanerr.peersCallID;
+ pcid_off = offsetof(union pptp_ctrl_union, wanerr.peersCallID);
break;
case PPTP_CALL_DISCONNECT_NOTIFY:
- pcid = &pptpReq->disc.callID;
+ pcid_off = offsetof(union pptp_ctrl_union, disc.callID);
break;
case PPTP_SET_LINK_INFO:
- pcid = &pptpReq->setlink.peersCallID;
+ pcid_off = offsetof(union pptp_ctrl_union, setlink.peersCallID);
break;
default:
@@ -343,25 +341,24 @@ pptp_inbound_pkt(struct sk_buff **pskb,
* WAN_ERROR_NOTIFY, CALL_DISCONNECT_NOTIFY pass down here */
/* mangle packet */
- IP_NF_ASSERT(pcid);
DEBUGP("altering peer call id from 0x%04x to 0x%04x\n",
- ntohs(*pcid), ntohs(new_pcid));
+ ntohs(*(u_int16_t *)pptpReq + pcid_off), ntohs(new_pcid));
- rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
- (void *)pcid - ((void *)ctlh - sizeof(struct pptp_pkt_hdr)),
+ rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
+ pcid_off + sizeof(struct pptp_pkt_hdr) +
+ sizeof(struct PptpControlHeader),
sizeof(new_pcid), (char *)&new_pcid,
sizeof(new_pcid));
if (rv != NF_ACCEPT)
return rv;
if (new_cid) {
- IP_NF_ASSERT(cid);
DEBUGP("altering call id from 0x%04x to 0x%04x\n",
- ntohs(*cid), ntohs(new_cid));
- rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
- (void *)cid - ((void *)ctlh - sizeof(struct pptp_pkt_hdr)),
- sizeof(new_cid),
- (char *)&new_cid,
+ ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_cid));
+ rv = ip_nat_mangle_tcp_packet(pskb, ct, ctinfo,
+ cid_off + sizeof(struct pptp_pkt_hdr) +
+ sizeof(struct PptpControlHeader),
+ sizeof(new_cid), (char *)&new_cid,
sizeof(new_cid));
if (rv != NF_ACCEPT)
return rv;
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Bart De Schuymer <[email protected]>
Signed-off-by: Bart De Schuymer <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/bridge/netfilter/ebt_ip.c | 3 +++
1 file changed, 3 insertions(+)
--- linux-2.6.14.6.orig/net/bridge/netfilter/ebt_ip.c
+++ linux-2.6.14.6/net/bridge/netfilter/ebt_ip.c
@@ -15,6 +15,7 @@
#include <linux/netfilter_bridge/ebtables.h>
#include <linux/netfilter_bridge/ebt_ip.h>
#include <linux/ip.h>
+#include <net/ip.h>
#include <linux/in.h>
#include <linux/module.h>
@@ -51,6 +52,8 @@ static int ebt_filter_ip(const struct sk
if (!(info->bitmask & EBT_IP_DPORT) &&
!(info->bitmask & EBT_IP_SPORT))
return EBT_MATCH;
+ if (ntohs(ih->frag_off) & IP_OFFSET)
+ return EBT_NOMATCH;
pptr = skb_header_pointer(skb, ih->ihl*4,
sizeof(_ports), &_ports);
if (pptr == NULL)
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Shaohua Li <[email protected]>
Setting irq affinity stops working when MSI is enabled. With MSI, move_irq
is empty, so we can't change irq affinity. It appears a typo in Ashok's
original commit for this issue. X86_64 actually is using move_native_irq.
Signed-off-by: Shaohua Li <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/i386/kernel/io_apic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.14.6.orig/arch/i386/kernel/io_apic.c
+++ linux-2.6.14.6/arch/i386/kernel/io_apic.c
@@ -1937,7 +1937,7 @@ static void ack_edge_ioapic_vector(unsig
{
int irq = vector_to_irq(vector);
- move_irq(vector);
+ move_native_irq(vector);
ack_edge_ioapic_irq(irq);
}
@@ -1952,7 +1952,7 @@ static void end_level_ioapic_vector (uns
{
int irq = vector_to_irq(vector);
- move_irq(vector);
+ move_native_irq(vector);
end_level_ioapic_irq(irq);
}
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: "David S. Miller" <[email protected]>
Noticed by Jakub Jelinek.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/sparc64/kernel/systbls.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.14.6.orig/arch/sparc64/kernel/systbls.S
+++ linux-2.6.14.6/arch/sparc64/kernel/systbls.S
@@ -98,7 +98,7 @@ sys_call_table:
.word sys_umount, sys_setgid, sys_getgid, sys_signal, sys_geteuid
/*50*/ .word sys_getegid, sys_acct, sys_memory_ordering, sys_nis_syscall, sys_ioctl
.word sys_reboot, sys_nis_syscall, sys_symlink, sys_readlink, sys_execve
-/*60*/ .word sys_umask, sys_chroot, sys_newfstat, sys_stat64, sys_getpagesize
+/*60*/ .word sys_umask, sys_chroot, sys_newfstat, sys_fstat64, sys_getpagesize
.word sys_msync, sys_vfork, sys_pread64, sys_pwrite64, sys_nis_syscall
/*70*/ .word sys_nis_syscall, sys_mmap, sys_nis_syscall, sys64_munmap, sys_mprotect
.word sys_madvise, sys_vhangup, sys_nis_syscall, sys_mincore, sys_getgroups
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <[email protected]>
When an inbound PPTP_IN_CALL_REQUEST packet is received the
PPTP NAT helper uses a NULL pointer in pointer arithmentic to
calculate the offset in the packet which needs to be mangled
and corrupts random memory or crashes.
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/netfilter/ip_nat_helper_pptp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.14.6.orig/net/ipv4/netfilter/ip_nat_helper_pptp.c
+++ linux-2.6.14.6/net/ipv4/netfilter/ip_nat_helper_pptp.c
@@ -313,7 +313,7 @@ pptp_inbound_pkt(struct sk_buff **pskb,
break;
case PPTP_IN_CALL_REQUEST:
/* only need to nat in case PAC is behind NAT box */
- break;
+ return NF_ACCEPT;
case PPTP_WAN_ERROR_NOTIFY:
pcid = &pptpReq->wanerr.peersCallID;
break;
--
-stable review patch. If anyone has any objections, please let us know.
------------------
From: Richard Mortimer <[email protected]>
Don't clobber register %l0 while checking TI_SYS_NOERROR value in
syscall return path. This bug was introduced by:
db7d9a4eb700be766cc9f29241483dbb1e748832
Problem narrowed down by Luis F. Ortiz and Richard Mortimer.
I tried using %l2 as suggested by Luis and that works for me.
Looking at the code I wonder if it makes sense to simplify the code
a little bit. The following works for me but I'm not sure how to
exercise the "NOERROR" codepath.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/sparc64/kernel/entry.S | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- linux-2.6.14.6.orig/arch/sparc64/kernel/entry.S
+++ linux-2.6.14.6/arch/sparc64/kernel/entry.S
@@ -1657,13 +1657,10 @@ ret_sys_call:
/* Check if force_successful_syscall_return()
* was invoked.
*/
- ldub [%curptr + TI_SYS_NOERROR], %l0
- brz,pt %l0, 1f
- nop
- ba,pt %xcc, 80f
+ ldub [%curptr + TI_SYS_NOERROR], %l2
+ brnz,a,pn %l2, 80f
stb %g0, [%curptr + TI_SYS_NOERROR]
-1:
cmp %o0, -ERESTART_RESTARTBLOCK
bgeu,pn %xcc, 1f
andcc %l0, (_TIF_SYSCALL_TRACE|_TIF_SECCOMP|_TIF_SYSCALL_AUDIT), %l6
--
On Fri, 27 Jan 2006, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.14.7 release.
> There are 6 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 correct me if I'm wrong here, but aren't we supposed to stop doing
this for the 2.6.14 release now that 2.6.15 is out?
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"The measure of the restoration lies in the extent to which we apply
social values more noble than mere monetary profit." - FDR
On Sat, 28 Jan 2006 20:30:25 -0800 (PST) Chuck Wolber wrote:
> On Fri, 27 Jan 2006, Greg KH wrote:
>
> > This is the start of the stable review cycle for the 2.6.14.7 release.
> > There are 6 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 correct me if I'm wrong here, but aren't we supposed to stop doing
> this for the 2.6.14 release now that 2.6.15 is out?
Some people wanted more -stable so the stable team agreed
to do a little more. Is it a problem?
---
~Randy
On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
>
> Please correct me if I'm wrong here, but aren't we supposed to stop doing
> this for the 2.6.14 release now that 2.6.15 is out?
>
I don't see a problems with doing additional stable releases for any
kernel, I just wouldn't commit to supporting any specific number of
releases. Basically if people send enough patches to warrant a
review/release there is obviously some interest. What is the harm?
Justin
On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> >
> > Please correct me if I'm wrong here, but aren't we supposed to stop doing
> > this for the 2.6.14 release now that 2.6.15 is out?
>
> I don't see a problems with doing additional stable releases for any
> kernel, I just wouldn't commit to supporting any specific number of
> releases. Basically if people send enough patches to warrant a
> review/release there is obviously some interest. What is the harm?
The harm is that stable release patches will eventually start being
maintained and we'll have to add another stable release "dot" to the end
of the growing width of the release version moniker. This stable branch
was meant only for "one-off" fixes to a stable release, not for adding
fixes upon fixes upon fixes that eventually turn into features that have
to be maintained. A new stable release means we change our focus to it and
ignore the old stable release.
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"The measure of the restoration lies in the extent to which we apply
social values more noble than mere monetary profit." - FDR
On Sat, 28 Jan 2006 20:52:46 -0800 (PST) Chuck Wolber wrote:
> On Sat, 28 Jan 2006, Justin M. Forbes wrote:
>
> > On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > >
> > > Please correct me if I'm wrong here, but aren't we supposed to stop doing
> > > this for the 2.6.14 release now that 2.6.15 is out?
> >
> > I don't see a problems with doing additional stable releases for any
> > kernel, I just wouldn't commit to supporting any specific number of
> > releases. Basically if people send enough patches to warrant a
> > review/release there is obviously some interest. What is the harm?
>
> The harm is that stable release patches will eventually start being
> maintained and we'll have to add another stable release "dot" to the end
> of the growing width of the release version moniker. This stable branch
> was meant only for "one-off" fixes to a stable release, not for adding
> fixes upon fixes upon fixes that eventually turn into features that have
> to be maintained. A new stable release means we change our focus to it and
> ignore the old stable release.
It's a 6-month sliding window for stable releases IIRC.
Maybe <[email protected]> can add something like that to
Documentation/stable_kernel_rules.txt>.
---
~Randy
On Sat, 28 Jan 2006, Randy.Dunlap wrote:
> On Sat, 28 Jan 2006 20:30:25 -0800 (PST) Chuck Wolber wrote:
>
> > On Fri, 27 Jan 2006, Greg KH wrote:
> >
> > > This is the start of the stable review cycle for the 2.6.14.7
> > > release. There are 6 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 correct me if I'm wrong here, but aren't we supposed to stop
> > doing this for the 2.6.14 release now that 2.6.15 is out?
>
> Some people wanted more -stable so the stable team agreed to do a little
> more. Is it a problem?
I don't know if there is a problem, but it goes against the concept of
"one-off" fixes that aren't maintained (aka the purpose of the -stable
team). This slope eventually leads us to backporting -stable fixes from
other -stable releases etc etc.
If there's one thing I've learned from watching guys like Alan Cox
maintain stable releases, it's that they're profoundly good at saying
"no". I'm not saying that's warranted here, I'm just trying to encourage
the dialog (I suspect that I've missed part of the conversation as I am
not currently subscribed to LKML).
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"The measure of the restoration lies in the extent to which we apply
social values more noble than mere monetary profit." - FDR
On Sat, Jan 28, 2006 at 08:57:01PM -0800, Randy.Dunlap wrote:
> On Sat, 28 Jan 2006 20:52:46 -0800 (PST) Chuck Wolber wrote:
>
> > On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> >
> > > On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > > >
> > > > Please correct me if I'm wrong here, but aren't we supposed to stop doing
> > > > this for the 2.6.14 release now that 2.6.15 is out?
> > >
> > > I don't see a problems with doing additional stable releases for any
> > > kernel, I just wouldn't commit to supporting any specific number of
> > > releases. Basically if people send enough patches to warrant a
> > > review/release there is obviously some interest. What is the harm?
> >
> > The harm is that stable release patches will eventually start being
> > maintained and we'll have to add another stable release "dot" to the end
> > of the growing width of the release version moniker. This stable branch
> > was meant only for "one-off" fixes to a stable release, not for adding
> > fixes upon fixes upon fixes that eventually turn into features that have
> > to be maintained. A new stable release means we change our focus to it and
> > ignore the old stable release.
>
> It's a 6-month sliding window for stable releases IIRC.
> Maybe <[email protected]> can add something like that to
> Documentation/stable_kernel_rules.txt>.
No, it's not a 6 month window, I released this because people sent us
patches that they said should go into the 2.6.14-stable tree. And as
people complained so much on lkml that we were dropping the old kernels
too fast, I never thought that people would complain that we are
maintaining older stuff that people seem interested in...
And, odds are, it will probably be the last 2.6.14 stable kernel we (the
stable team) release, unless something unusual happens...
And, as always, anyone is free to take on maintaining any of the
different kernel versions for as long as they wish.
Does that help?
Man, people complain when you don't maintain older kernels, and they
complain when you do...
thanks,
greg k-h
On Sat, Jan 28, 2006 at 09:34:58PM -0800, Greg KH wrote:
> On Sat, Jan 28, 2006 at 08:57:01PM -0800, Randy.Dunlap wrote:
> > On Sat, 28 Jan 2006 20:52:46 -0800 (PST) Chuck Wolber wrote:
> >
> > > On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> > >
> > > > On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> > > > >
> > > > > Please correct me if I'm wrong here, but aren't we supposed to stop doing
> > > > > this for the 2.6.14 release now that 2.6.15 is out?
> > > >
> > > > I don't see a problems with doing additional stable releases for any
> > > > kernel, I just wouldn't commit to supporting any specific number of
> > > > releases. Basically if people send enough patches to warrant a
> > > > review/release there is obviously some interest. What is the harm?
> > >
> > > The harm is that stable release patches will eventually start being
> > > maintained and we'll have to add another stable release "dot" to the end
> > > of the growing width of the release version moniker. This stable branch
> > > was meant only for "one-off" fixes to a stable release, not for adding
> > > fixes upon fixes upon fixes that eventually turn into features that have
> > > to be maintained. A new stable release means we change our focus to it and
> > > ignore the old stable release.
> >
> > It's a 6-month sliding window for stable releases IIRC.
> > Maybe <[email protected]> can add something like that to
> > Documentation/stable_kernel_rules.txt>.
>
> No, it's not a 6 month window, I released this because people sent us
> patches that they said should go into the 2.6.14-stable tree. And as
> people complained so much on lkml that we were dropping the old kernels
> too fast, I never thought that people would complain that we are
> maintaining older stuff that people seem interested in...
>
> And, odds are, it will probably be the last 2.6.14 stable kernel we (the
> stable team) release, unless something unusual happens...
>
> And, as always, anyone is free to take on maintaining any of the
> different kernel versions for as long as they wish.
>
> Does that help?
>
> Man, people complain when you don't maintain older kernels, and they
> complain when you do...
Greg, there will always be stupid people who don't understand the work
of others. These are the same type of people who won't understand at all
why there's a -stable branch. When I started 2.4-hf, I've been told
"you're dumb, 2.4 is dead". I'm very glad that you take care of people
who cannot easily upgrade to latest version, and I'm sure that a lot of
users are too.
> thanks,
>
> greg k-h
Thanks for keeping up the good work,
Willy
On Sat, Jan 28, 2006 at 09:02:16PM -0800, Chuck Wolber wrote:
> On Sat, 28 Jan 2006, Randy.Dunlap wrote:
>
> > On Sat, 28 Jan 2006 20:30:25 -0800 (PST) Chuck Wolber wrote:
> >
> > > On Fri, 27 Jan 2006, Greg KH wrote:
> > >
> > > > This is the start of the stable review cycle for the 2.6.14.7
> > > > release. There are 6 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 correct me if I'm wrong here, but aren't we supposed to stop
> > > doing this for the 2.6.14 release now that 2.6.15 is out?
> >
> > Some people wanted more -stable so the stable team agreed to do a little
> > more. Is it a problem?
>
>
> I don't know if there is a problem, but it goes against the concept of
> "one-off" fixes that aren't maintained (aka the purpose of the -stable
> team). This slope eventually leads us to backporting -stable fixes from
> other -stable releases etc etc.
The purpose of -stable is to provide stable kernels to 2.6 users. If time
was not a problem, it's possible that there would be even more versions
supported. The day you will install Linux on a server, you'll understand
why it's problematic for some people to upgrade to latest version to get
fixes. And when you get something that works, you hope to be able to use
it as an alternative to a simple upgrade when the later breaks on your
hardware.
> If there's one thing I've learned from watching guys like Alan Cox
> maintain stable releases, it's that they're profoundly good at saying
> "no". I'm not saying that's warranted here, I'm just trying to encourage
> the dialog (I suspect that I've missed part of the conversation as I am
> not currently subscribed to LKML).
It's not a matter of saying "yes" or "no", it's a matter of helping
users in getting something which works best on their hardware while
still being reliable and secure. Maintainers propose some solutions
for this, and can adapt to users' demands. I don't see anything wrong
with this.
> ..Chuck..
Willy
On Sat, 28 Jan 2006, Greg KH wrote:
> No, it's not a 6 month window, I released this because people sent us
> patches that they said should go into the 2.6.14-stable tree. And as
> people complained so much on lkml that we were dropping the old kernels
> too fast, I never thought that people would complain that we are
> maintaining older stuff that people seem interested in...
Don't think of it as a complaint. I'm sorry if it came off that way. It's
anyone's job if they want to maintain any kernel release as long as they
see fit.
I guess it's how we want to define ourselves. Was I mistaken to think that
the -stable team maintains -stable for the current patch release only?
> And, as always, anyone is free to take on maintaining any of the
> different kernel versions for as long as they wish.
>
> Does that help?
Well, that's the way it's always been. We have a late model 2.5 kernel
that we still maintain in a level C avionics device on Boeing jets. You'd
be amazed at how stable a 2.5 kernel can be made ;)
> Man, people complain when you don't maintain older kernels, and they
> complain when you do...
Nope, wasn't complaining. It was an attempt at a dialog to more clearly
define our purpose (or perhaps my personal understanding of it) *AND* let
other developers know what to expect of us. We can choose to take on as
much or as little as we want. I personally am good with whatever everyone
else is comfortable taking on. We should manage outside expectations
though so you don't have to answer "why do you drop old kernels" questions
on your own.
Things have changed a lot with the 2.6 release series and -stable seems to
me to be one of those growing pains that still isn't fully resolved. It's
a blending between the traditional stable release maintainers and the more
nimble release schedule these days. Can the -stable team fill the void, or
do we limit our scope to certain patch releases?
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"The measure of the restoration lies in the extent to which we apply
social values more noble than mere monetary profit." - FDR
On Sun, 29 Jan 2006, Willy Tarreau wrote:
> Greg, there will always be stupid people who don't understand the work
> of others.
Hmmm, true, but I wouldn't call them stupid, just a bit ignorant. It's
incumbent upon us to manage and maintain expectations to fix that problem.
> I'm very glad that you take care of people who cannot easily upgrade to
> latest version, and I'm sure that a lot of users are too.
Me too. I'd never dream of criticizing Greg's efforts. He's done an
incredible job. I think better defining -stable will make life easier for
him and help us be more productive.
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"The measure of the restoration lies in the extent to which we apply
social values more noble than mere monetary profit." - FDR
On Sun, 29 Jan 2006, Willy Tarreau wrote:
> The purpose of -stable is to provide stable kernels to 2.6 users. If time
> was not a problem, it's possible that there would be even more versions
> supported.
Mmmm, yup. I was there when this whole thing was brewed up ;)
> The day you will install Linux on a server, you'll understand why it's
> problematic for some people to upgrade to latest version to get fixes.
Sure hope you're not implying I haven't done that before...
> It's not a matter of saying "yes" or "no", it's a matter of helping
> users in getting something which works best on their hardware while
> still being reliable and secure. Maintainers propose some solutions for
> this, and can adapt to users' demands. I don't see anything wrong with
> this.
Neither do I. To a great extent, that void is already filled by distro
maintainers.
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"The measure of the restoration lies in the extent to which we apply
social values more noble than mere monetary profit." - FDR
On Sat, 28 Jan 2006, Justin M. Forbes wrote:
> On Sat, Jan 28, 2006 at 08:30:25PM -0800, Chuck Wolber wrote:
> >
> > Please correct me if I'm wrong here, but aren't we supposed to stop doing
> > this for the 2.6.14 release now that 2.6.15 is out?
>
> I don't see a problems with doing additional stable releases for any
> kernel, I just wouldn't commit to supporting any specific number of
> releases. Basically if people send enough patches to warrant a
> review/release there is obviously some interest. What is the harm?
No harm at all, and that settles it for me then. I like the idea of having
a demand based release system. If no patches arrive, no releases go out.
..Chuck..
--
http://www.quantumlinux.com
Quantum Linux Laboratories, LLC.
ACCELERATING Business with Open Technology
"The measure of the restoration lies in the extent to which we apply
social values more noble than mere monetary profit." - FDR
Chuck Wolber <[email protected]> writes:
> I don't know if there is a problem, but it goes against the concept of
> "one-off" fixes that aren't maintained
If they have time for this then great, I can't see any drawbacks.
The early concept was just meant to limit the workload.
> (aka the purpose of the -stable
> team). This slope eventually leads us to backporting -stable fixes from
> other -stable releases etc etc.
As long as they can contribute their time it's a win.
--
Krzysztof Halasa
On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> - ntohs(*cid), ntohs(new_callid));
> + ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
Note that this fix introduces another bug in the above use DEBUGP
statement, as there is (u_int16_t *) ptr arithmetic used, whereas
cid_off is a byte offset.
A fix for that was send a few weeks ago on netfilter-devel.
/holger
On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
>
> > DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > - ntohs(*cid), ntohs(new_callid));
> > + ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
>
> Note that this fix introduces another bug in the above use DEBUGP
> statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> cid_off is a byte offset.
>
> A fix for that was send a few weeks ago on netfilter-devel.
Great, care to forward it to [email protected] so we can get it in the
next release?
thanks,
greg k-h
Greg KH <[email protected]> wrote:
>
> On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> > On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> >
> > > DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > > - ntohs(*cid), ntohs(new_callid));
> > > + ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
> >
> > Note that this fix introduces another bug in the above use DEBUGP
> > statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> > cid_off is a byte offset.
> >
> > A fix for that was send a few weeks ago on netfilter-devel.
>
> Great, care to forward it to [email protected] so we can get it in the
> next release?
>
I have a copy of the patch and I'll cc stable@ on it. Although afaik this
bug just causes wrong debug info to come out, so I don't think it's
terribly important (?)
On Thu, Feb 09, 2006 at 08:57:29PM -0800, Andrew Morton wrote:
> Greg KH <[email protected]> wrote:
> >
> > On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> > > On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> > >
> > > > DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > > > - ntohs(*cid), ntohs(new_callid));
> > > > + ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
> > >
> > > Note that this fix introduces another bug in the above use DEBUGP
> > > statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> > > cid_off is a byte offset.
> > >
> > > A fix for that was send a few weeks ago on netfilter-devel.
> >
> > Great, care to forward it to [email protected] so we can get it in the
> > next release?
> >
>
> I have a copy of the patch and I'll cc stable@ on it. Although afaik this
> bug just causes wrong debug info to come out, so I don't think it's
> terribly important (?)
If that's the only problem with it, no it's not worth adding to -stable.
thanks though.
greg k-h
On Thu, Feb 09, 2006 at 09:08:19PM -0800, Greg KH wrote:
> On Thu, Feb 09, 2006 at 08:57:29PM -0800, Andrew Morton wrote:
> > Greg KH <[email protected]> wrote:
> > >
> > > On Wed, Feb 08, 2006 at 01:35:41PM +0100, Holger Eitzenberger wrote:
> > > > On Fri, Jan 27, 2006 at 06:18:35PM -0800, Greg KH wrote:
> > > >
> > > > > DEBUGP("altering call id from 0x%04x to 0x%04x\n",
> > > > > - ntohs(*cid), ntohs(new_callid));
> > > > > + ntohs(*(u_int16_t *)pptpReq + cid_off), ntohs(new_callid));
> > > >
> > > > Note that this fix introduces another bug in the above use DEBUGP
> > > > statement, as there is (u_int16_t *) ptr arithmetic used, whereas
> > > > cid_off is a byte offset.
> > > >
> > > > A fix for that was send a few weeks ago on netfilter-devel.
> > >
> > > Great, care to forward it to [email protected] so we can get it in the
> > > next release?
> > >
> >
> > I have a copy of the patch and I'll cc stable@ on it. Although afaik this
> > bug just causes wrong debug info to come out, so I don't think it's
> > terribly important (?)
>
> If that's the only problem with it, no it's not worth adding to -stable.
Yes, this patch only fixes code in DEBUG statements. Debug can only be
enabled at compile time, so I agree it's not a candidate for -stable.
--
- Harald Welte <[email protected]> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie