Greg KH announced the first maintenance release of the 2.6.11 kernel [story], 2.6.11.1. Quickly acting on the recent lengthy discussion regarding kernel release numbering [story] [story], Greg and Chris Wright have begun to maintain this branch. With each 2.6.x release, they will maintain 2.6.x.y releases available from your nearest kernel.org mirror. This first maintenance release includes three simple patches, not including the makefile change, addressing a problem with keyboards on Dell machines, and raid6 compilation on the ppc architecture. Andrew Morton [interview] noted that he has additional fixes appropriate for this tree that will likely lead to a 2.6.11.2 release in the relatively near future.

Greg went on to highlight the requirements for patches to be able to be merged into this new tree: they must be no bigger than 100 lines, they must fix only one thing, they must fix real bugs that are confirmed to be affecting people, and they must fix a build error, an oops, a hang, or a real security issue. Patches explicitly not allowed include things to fix "theoretical race conditions" without an exploit, or "trivial" fixes like spelling changes or whitespace cleanups. Greg described the effort's mantra as "release early and often".

From: Greg KH [email blocked]
To:  linux-kernel
Subject: Linux 2.6.11.1
Date: 	Fri, 4 Mar 2005 09:53:02 -0800

For those of you who haven't waded through the huge "RFD: Kernel release
numbering" thread on lkml to realize that we are now going to start
putting out 2.6.x.y releases, here's the summary:

	A few of us $suckers will be trying to maintain a 2.6.x.y set of
	releases that happen after 2.6.x is released.  It will contain
	only a set of bugfixes and security fixes that meet a strict set
	of guidelines, as defined by Linus at:
		http://article.gmane.org/gmane.linux.kernel/283396

Chris Wright and I are going to start working on doing this work, we
will have a <SOME_ALIAS>@kernel.org to post these types of bug fixes to,
and a set of people we bounce the patches off of to test for "smells
good" validation.  We will also have a bk-commits type mailing list for
those who want to watch the patches flow in, and a bk tree from which
changsets can be pulled from.

Chris and I will be hashing all of the details out next Tuesday, and
hopefully all the infrastructure will be in place soon.  When that
happens, we will post the full details on how all of this is going to
work.  In the meantime, feel free to CC: me and Chris on patches that
everyone thinks should go into the 2.6.11.y releases.

But right now, Chris is on a plane, and we don't have the email alias
set up, or the proper permissions set up on kernel.org to push changes
into the v2.6 directory, but we have a few bugs that are needing to be
fixed in the 2.6.11 release.  And since our mantra is, "release early
and often", here's the first release.

---------------

I've released the 2.6.11.1 patch:
	kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/patch-2.6.11.1.gz

With a detailed changelog at:
	kernel.org/pub/linux/kernel/people/gregkh/v2.6.11/ChangeLog-2.6.11.1

A bitkeeper tree for the 2.6.11.y releases can be found at:
	bk://linux-release.bkbits.net/linux-2.6.11

The diffstat and short summary of the fixes are below.  

I'll also be replying to this message with a copy of the patch itself,
as it is small enough to do so.

thanks,

greg k-h

-------

 Makefile                              |    2 +-
 drivers/input/serio/i8042-x86ia64io.h |    6 +++---
 drivers/md/raid6altivec.uc            |    4 ++++
 3 files changed, 8 insertions(+), 4 deletions(-)


Summary of changes from v2.6.11 to v2.6.11.1
============================================

Dmitry Torokhov:
  o Fix keyboards for Dell machines

Greg Kroah-Hartman:
  o Linux 2.6.11.1

Olof Johansson:
  o Fix for trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec

Rene Rebe:
  o trivial fix for 2.6.11 raid6 compilation on ppc w/ Altivec



From: Greg KH [email blocked]
Subject: Re: Linux 2.6.11.1
Date: 	Fri, 4 Mar 2005 09:53:50 -0800

On Fri, Mar 04, 2005 at 09:53:02AM -0800, Greg KH wrote:
> I'll also be replying to this message with a copy of the patch itself,
> as it is small enough to do so.

Here it is....


diff -Nru a/Makefile b/Makefile
--- a/Makefile	2005-03-04 09:27:15 -08:00
+++ b/Makefile	2005-03-04 09:27:15 -08:00
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 11

-EXTRAVERSION =
+EXTRAVERSION = .1
 NAME=Woozy Numbat
 
 # *DOCUMENTATION*
diff -Nru a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
--- a/drivers/input/serio/i8042-x86ia64io.h	2005-03-04 09:27:15 -08:00
+++ b/drivers/input/serio/i8042-x86ia64io.h	2005-03-04 09:27:15 -08:00
@@ -88,7 +88,7 @@
 };
 #endif
 
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
 #include <linux/acpi.h>
 #include <acpi/acpi_bus.h>
 
@@ -281,7 +281,7 @@
 	i8042_kbd_irq = I8042_MAP_IRQ(1);
 	i8042_aux_irq = I8042_MAP_IRQ(12);
 
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
 	if (i8042_acpi_init())
 		return -1;
 #endif
@@ -300,7 +300,7 @@
 
 static inline void i8042_platform_exit(void)
 {
-#ifdef CONFIG_ACPI
+#if defined(__ia64__) && defined(CONFIG_ACPI)
 	i8042_acpi_exit();
 #endif
 }
diff -Nru a/drivers/md/raid6altivec.uc b/drivers/md/raid6altivec.uc
--- a/drivers/md/raid6altivec.uc	2005-03-04 09:27:15 -08:00
+++ b/drivers/md/raid6altivec.uc	2005-03-04 09:27:15 -08:00
@@ -108,7 +108,11 @@
 int raid6_have_altivec(void)
 {
 	/* This assumes either all CPUs have Altivec or none does */
+#ifdef CONFIG_PPC64
 	return cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC;
+#else
+	return cur_cpu_spec[0]->cpu_features & CPU_FTR_ALTIVEC;
+#endif
 }
 #endif
 


From: Andrew Morton [email blocked]
Subject: Re: Linux 2.6.11.1
Date: 	Fri, 4 Mar 2005 12:44:31 -0800

Greg KH [email blocked] wrote:
>
> A few of us $suckers will be trying to maintain a 2.6.x.y set of
>  	releases that happen after 2.6.x is released.

Just to test things out a bit...

Here's the list of things which we might choose to put into 2.6.11.2.  I was
planning on sending them in for 2.6.12 when that was going to be
errata-only.


>From 2.6.11-mm1:

cramfs-small-stat2-fix.patch
setup_per_zone_lowmem_reserve-oops-fix.patch
dv1394-ioctl-retval-fix.patch
ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch
nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
nfsd--exportfs-reduce-stack-usage.patch
nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
nfsd--svcrpc-rename-pg_authenticate.patch
nfsd--svcrpc-move-export-table-checks-to-a-per-program-pg_add_client-method.patch
nfsd--nfs4-use-new-pg_set_client-method-to-simplify-nfs4-callback-authentication.patch
nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch
audit-mips-fix.patch
make-st-seekable-again.patch

wrt the nfsd patches, Neil said:

The problem they fix is that currently:
    Client A holds a lock
    Client B tries to get the lock and blocks
    Client A drops the lock
  **Client B doesn't get the lock immediately, but has to wait for a
           timeout. (several seconds)



From: Greg KH [email blocked]
Subject: Re: Linux 2.6.11.1
Date: 	Fri, 4 Mar 2005 12:58:43 -0800

On Fri, Mar 04, 2005 at 12:44:31PM -0800, Andrew Morton wrote:
> Greg KH [email blocked] wrote:
> >
> > A few of us $suckers will be trying to maintain a 2.6.x.y set of
> >  	releases that happen after 2.6.x is released.
> 
> Just to test things out a bit...
> 
> Here's the list of things which we might choose to put into 2.6.11.2.  I was
> planning on sending them in for 2.6.12 when that was going to be
> errata-only.

Ok, care to forward them on?

> From 2.6.11-mm1:
> 
> cramfs-small-stat2-fix.patch
> setup_per_zone_lowmem_reserve-oops-fix.patch
> dv1394-ioctl-retval-fix.patch
> ppc32-compilation-fixes-for-ebony-luan-and-ocotea.patch
> nfsd--sgi-921857-find-broken-with-nohide-on-nfsv3.patch
> nfsd--exportfs-reduce-stack-usage.patch
> nfsd--svcrpc-add-a-per-flavor-set_client-method.patch
> nfsd--svcrpc-rename-pg_authenticate.patch
> nfsd--svcrpc-move-export-table-checks-to-a-per-program-pg_add_client-method.patch
> nfsd--nfs4-use-new-pg_set_client-method-to-simplify-nfs4-callback-authentication.patch
> nfsd--lockd-dont-try-to-match-callback-requests-against-export-table.patch
> audit-mips-fix.patch
> make-st-seekable-again.patch
> 
> wrt the nfsd patches, Neil said:
> 
> The problem they fix is that currently:
>     Client A holds a lock
>     Client B tries to get the lock and blocks
>     Client A drops the lock
>   **Client B doesn't get the lock immediately, but has to wait for a
>            timeout. (several seconds)

Hm, odds are the nfsd one doesn't fit our list of "acceptable things",
but let's see the patches...

thanks,

greg k-h



From: Andrew Morton [email blocked]
Subject: Re: Linux 2.6.11.1
Date: 	Fri, 4 Mar 2005 13:15:37 -0800

Greg KH [email blocked] wrote:
>
> > Here's the list of things which we might choose to put into 2.6.11.2.  I was
>  > planning on sending them in for 2.6.12 when that was going to be
>  > errata-only.
> 
>  Ok, care to forward them on?

Sure.  How do they get to Linus?

>  Hm, odds are the nfsd one doesn't fit our list of "acceptable things",

Was there such a list?  It's kinda what I'm asking about here.

Yes, the NFSD fixes are relatively minor, although Neil did want them in
the 2.6.12 errata kernel.

Perhaps they could be backported to 2.6.11.x in a few weeks ;)



From: Linus Torvalds [email blocked]
Subject: Re: Linux 2.6.11.1
Date: 	Fri, 4 Mar 2005 13:53:47 -0800 (PST)



On Fri, 4 Mar 2005, Andrew Morton wrote:
> > 
> >  Ok, care to forward them on?
> 
> Sure.  How do they get to Linus?

I'll just pull from the sucker-tree. 

		Linus



From: Greg KH [email blocked]
Subject: [RFQ] Rules for accepting patches into the linux-releases tree
Date: 	Fri, 4 Mar 2005 14:21:46 -0800

Anything else anyone can think of?  Any objections to any of these?
I based them off of Linus's original list.

thanks,

greg k-h

------

Rules on what kind of patches are accepted, and what ones are not, into
the "linux-release" tree.

 - It can not bigger than 100 lines, with context.
 - It must fix only one thing.
 - It must fix a real bug that bothers people (not a, "This could be a
   problem..." type thing.)
 - It must fix a problem that causes a build error (but not for things
   marked CONFIG_BROKEN), an oops, a hang, or a real security issue.
 - No "theoretical race condition" issues, unless an explanation of how
   the race can be exploited.
 - It can not contain any "trivial" fixes in it (spelling changes,
   whitespace cleanups, etc.)

• Archive of above thread
• KernelTrap interview with Andrew Morton