And to further test this whole -stable system, I've released 2.6.11.2.
It contains one patch, which is already in the -bk tree, and came from
the security team (hence the lack of the longer review cycle).
It's available now in the normal kernel.org places:
kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
which is a patch against the 2.6.11.1 release. If consensus arrives
that this patch should be against the 2.6.11 tree, it will be done that
way in the future.
A detailed changelog can be found at:
kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.2
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 +-
fs/eventpoll.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
Summary of changes from v2.6.11.1 to v2.6.11.2
============================================
Greg Kroah-Hartman:
o Linux 2.6.11.2
Linus Torvalds:
o epoll: return proper error on overflow condition
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2005-03-09 00:13:29 -08:00
+++ b/Makefile 2005-03-09 00:13:29 -08:00
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 11
-EXTRAVERSION = .1
+EXTRAVERSION = .2
NAME=Woozy Numbat
# *DOCUMENTATION*
diff -Nru a/fs/eventpoll.c b/fs/eventpoll.c
--- a/fs/eventpoll.c 2005-03-09 00:13:29 -08:00
+++ b/fs/eventpoll.c 2005-03-09 00:13:29 -08:00
@@ -619,6 +619,7 @@
return error;
}
+#define MAX_EVENTS (INT_MAX / sizeof(struct epoll_event))
/*
* Implement the event wait interface for the eventpoll file. It is the kernel
@@ -635,7 +636,7 @@
current, epfd, events, maxevents, timeout));
/* The maximum number of event must be greater than zero */
- if (maxevents <= 0)
+ if (maxevents <= 0 || maxevents > MAX_EVENTS)
return -EINVAL;
/* Verify that the area passed by the user is writeable */
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 9 Mar 2005, Greg KH wrote:
> which is a patch against the 2.6.11.1 release. If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.
IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt againt
the last -rc but against 2.6.x.
Marcos Marado
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFCLsdwmNlq8m+oD34RApSIAJ4rAaaDduX7Xp1ChqGj9KJkqg/HuwCfYb5X
5UAEW4srRcpOqspM8JaScAM=
=REDu
-----END PGP SIGNATURE-----
On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> On Wed, 9 Mar 2005, Greg KH wrote:
> > which is a patch against the 2.6.11.1 release. If consensus arrives
> > that this patch should be against the 2.6.11 tree, it will be done that
> > way in the future.
>
> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> againt
> the last -rc but against 2.6.x.
It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical to
me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
>>> which is a patch against the 2.6.11.1 release. If consensus arrives
>>> that this patch should be against the 2.6.11 tree, it will be done that
>>> way in the future.
>>
>> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
>> againt
>> the last -rc but against 2.6.x.
>
> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical to
> me.
Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last instead
of 2.6.11. And, well, either one will cause great panic for hose who aren't and
the mailing lists and just visit kernel.org to downoad the latest stuff.
Marado
- --
/* *************************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against html email, Microsoft
/\ attachments and Software patents. They endanger the World.
Sign a petition against patents: http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFCLs0rmNlq8m+oD34RAk+0AJsFwRyZ7vF9cE9thGYs/QjiVIjwjgCfclMR
nopc5sBPVauXqQCUeMxjYlM=
=YlzR
-----END PGP SIGNATURE-----
On Wednesday 09 March 2005 11:04, Geert Uytterhoeven wrote:
> On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> > On Wed, 9 Mar 2005, Greg KH wrote:
> > > which is a patch against the 2.6.11.1 release. If consensus arrives
> > > that this patch should be against the 2.6.11 tree, it will be done that
> > > way in the future.
> >
> > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> > againt
> > the last -rc but against 2.6.x.
>
> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most
> logical to me.
>
> Gr{oetje,eeting}s,
>
> Geert
I don't think so. The latest patch (2.6.11.2 now) is on the frontpage of
kernel.org, so IMHO the user should not need to search the kernel.org/pub
archives to get 2.6.11.1 patch before he can start working with 2.6.11.2.
I think it's a small problem too, that 2.6.11 source isn't directly accessable
through the kernel.org frontpage while there is no "full tarball" of 2.6.11.X
trees.
greetings,
dominik
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 9 Mar 2005, Dominik Karall wrote:
>>>> which is a patch against the 2.6.11.1 release. If consensus arrives
>>>> that this patch should be against the 2.6.11 tree, it will be done that
>>>> way in the future.
>>>
>>> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
>>> againt
>>> the last -rc but against 2.6.x.
>>
>> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most
>> logical to me.
>
> I don't think so. The latest patch (2.6.11.2 now) is on the frontpage of
> kernel.org, so IMHO the user should not need to search the kernel.org/pub
> archives to get 2.6.11.1 patch before he can start working with 2.6.11.2.
>
> I think it's a small problem too, that 2.6.11 source isn't directly accessable
> through the kernel.org frontpage while there is no "full tarball" of 2.6.11.X
> trees.
With that "full tarball" for 2.6.11.X the issues would be over.
I think there should be one.
Marado
- --
/* *********************************************************** */
Marcos Daniel Marado Torres AKA Mind Booster Noori
http://student.dei.uc.pt/~marado - [email protected]
() Join the ASCII ribbon campaign against HTML e-mail and
/\ Microsoft attachments. They endanger the World.
/* *********************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFCLs/gmNlq8m+oD34RAnu6AJwOvkvet1kLLGzLQ5EGuiVxtNbeEQCg7Ar9
Stnv4wmM74a5mX3fFrAh34Y=
=fCVH
-----END PGP SIGNATURE-----
On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
> > > > which is a patch against the 2.6.11.1 release. If consensus arrives
> > > > that this patch should be against the 2.6.11 tree, it will be done that
> > > > way in the future.
> > >
> > > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> > > againt
> > > the last -rc but against 2.6.x.
> >
> > It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical
> > to
> > me.
>
> Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last
> instead
> of 2.6.11. And, well, either one will cause great panic for hose who aren't
> and
> the mailing lists and just visit kernel.org to downoad the latest stuff.
Probably the 2.6.12 patch will be against 2.6.11, since:
- The 2.6.11.x line may continue after 2.6.12 was released
- 2.6.11.x may contain `quick and dirty' fixes for problems, which will be
fixed `properly' in 2.6.12 (or later), cfr. Alan Cox' presentation at
FOSDEM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Mar 09, 2005 at 10:28:32AM +0000, Marcos D. Marado Torres wrote:
>
> With that "full tarball" for 2.6.11.X the issues would be over.
> I think there should be one.
It's already there....
> Marado
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 9 Mar 2005, Greg KH wrote:
>
> >which is a patch against the 2.6.11.1 release. If consensus arrives
> >that this patch should be against the 2.6.11 tree, it will be done that
> >way in the future.
>
> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> againt
> the last -rc but against 2.6.x.
You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
means .11.2 should be relative to .11.1, because otherwise people will
have to revert (ugly). And you want people to track -stable kernels as
fast as possible.
So Greg did it right.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
> On Wed, 9 Mar 2005, Marcos D. Marado Torres wrote:
> > On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
> > > > > which is a patch against the 2.6.11.1 release. If consensus arrives
> > > > > that this patch should be against the 2.6.11 tree, it will be done that
> > > > > way in the future.
> > > >
> > > > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> > > > againt
> > > > the last -rc but against 2.6.x.
> > >
> > > It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most logical
> > > to
> > > me.
> >
> > Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last
> > instead
> > of 2.6.11. And, well, either one will cause great panic for hose who aren't
> > and
> > the mailing lists and just visit kernel.org to downoad the latest stuff.
>
> Probably the 2.6.12 patch will be against 2.6.11, since:
> - The 2.6.11.x line may continue after 2.6.12 was released
> - 2.6.11.x may contain `quick and dirty' fixes for problems, which will be
> fixed `properly' in 2.6.12 (or later), cfr. Alan Cox' presentation at
> FOSDEM.
>
Would it be that hard to have scripts on kernel.org generate the diff
against 2.6.11 when Greg puts up the 2.6.11.3 diff against 2.6.22.2, then
have the front page have two links, one for patch against 2.6.11 and one
for patch against previous 2.6.11.z ? That along with the full source
(which I see is up there already) should make everyone happy, and if it is
automated the burden on Greg should be minimal.
--
Jesper Juhl
> which is a patch against the 2.6.11.1 release. If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.
It seems to me that we have V (delta?) and VI (delta incremental) for
all the other kernel patch series. So perhaps we could have both, the V
being from 2.6.11 and the VI from 2.6.11.1.
-apw
On Wed, Mar 09, 2005 at 10:28:32AM +0000, Marcos D. Marado Torres wrote:
> On Wed, 9 Mar 2005, Dominik Karall wrote:
>
> >>>> which is a patch against the 2.6.11.1 release. If consensus arrives
> >>>> that this patch should be against the 2.6.11 tree, it will be done that
> >>>> way in the future.
> >>>
> >>> IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> >>> againt
> >>> the last -rc but against 2.6.x.
> >>
> >> It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most
> >> logical to me.
> >
> > I don't think so. The latest patch (2.6.11.2 now) is on the frontpage of
> > kernel.org, so IMHO the user should not need to search the kernel.org/pub
> > archives to get 2.6.11.1 patch before he can start working with 2.6.11.2.
> >
> > I think it's a small problem too, that 2.6.11 source isn't directly accessable
> > through the kernel.org frontpage while there is no "full tarball" of 2.6.11.X
> > trees.
>
> With that "full tarball" for 2.6.11.X the issues would be over.
> I think there should be one.
There is one, did you not look?
kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.2.tar.gz
thanks,
greg k-h
Hi Greg,
The st/ide-tape/osst llseek changes havent been applied for what reason?
And what about the rest of fixups which Andrew sent you?
I suppose they didnt pass the -stable criteria. Can you share your thoughts
with the rest of us?
On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> And to further test this whole -stable system, I've released 2.6.11.2.
> It contains one patch, which is already in the -bk tree, and came from
> the security team (hence the lack of the longer review cycle).
>
> It's available now in the normal kernel.org places:
> kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> which is a patch against the 2.6.11.1 release. If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.
>
> A detailed changelog can be found at:
> kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.2
>
> 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 +-
> fs/eventpoll.c | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>
> Summary of changes from v2.6.11.1 to v2.6.11.2
> ============================================
>
> Greg Kroah-Hartman:
> o Linux 2.6.11.2
>
> Linus Torvalds:
> o epoll: return proper error on overflow condition
On Wed, Mar 09, 2005 at 11:03:59AM -0300, Marcelo Tosatti wrote:
>
> Hi Greg,
>
> The st/ide-tape/osst llseek changes havent been applied for what reason?
>
> And what about the rest of fixups which Andrew sent you?
>
> I suppose they didnt pass the -stable criteria. Can you share your thoughts
> with the rest of us?
They are in the -stable queue, and should go our for review later today,
and will attempt to follow the proposed proceedure.
I didn't add them to .2 as that was released just due to the security
update.
thanks,
greg k-h
Greg KH wrote:
> And to further test this whole -stable system, I've released 2.6.11.2.
> It contains one patch, which is already in the -bk tree, and came from
> the security team (hence the lack of the longer review cycle).
>
> It's available now in the normal kernel.org places:
> kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> which is a patch against the 2.6.11.1 release. If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.
I think you need both x.y.z=>x.y.z.N and x.y.z.N-1=>x.y.z.N patches. My
systems which are following the -stable will just need the most recent,
but doing x.y.z-1=>x.y.z.N gets really ugly for higher values of N.
It can be automated, it's just two (presumably tiny) patchsets per release.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> And to further test this whole -stable system, I've released 2.6.11.2.
> It contains one patch, which is already in the -bk tree, and came from
> the security team (hence the lack of the longer review cycle).
>
> It's available now in the normal kernel.org places:
> kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> which is a patch against the 2.6.11.1 release.
Argh! @*#$&!!&!
> If consensus arrives
> that this patch should be against the 2.6.11 tree, it will be done that
> way in the future.
Consensus arrived back when 2.6.8.1 came out.
Please, folks, there are automated tools that "know" about kernel
release numbering and so on. Said tools broke with 2.6.11.1 because it
wasn't in the same place that 2.6.8.1 was and now this breaks with all
precedent by being an interdiff along a branch.
Fixing it in the future is too #*$%* late because you've now turned it
into a special case.
--
Mathematics is the supreme nostalgia of our time.
Matt Mackall wrote:
> On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
>
>>And to further test this whole -stable system, I've released 2.6.11.2.
>>It contains one patch, which is already in the -bk tree, and came from
>>the security team (hence the lack of the longer review cycle).
>>
>>It's available now in the normal kernel.org places:
>> kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
>>which is a patch against the 2.6.11.1 release.
>
>
> Argh! @*#$&!!&!
I have to Argh this also (with Matt).
>>If consensus arrives
>>that this patch should be against the 2.6.11 tree, it will be done that
>>way in the future.
It would be much easier on users/testers to have to apply
only one patch to base (2.6.11 e.g.) to get to 2.6.x.y
(2.6.11.3 e.g.). One Patch File. Not three.
> Consensus arrived back when 2.6.8.1 came out.
>
> Please, folks, there are automated tools that "know" about kernel
> release numbering and so on. Said tools broke with 2.6.11.1 because it
> wasn't in the same place that 2.6.8.1 was and now this breaks with all
> precedent by being an interdiff along a branch.
>
> Fixing it in the future is too #*$%* late because you've now turned it
> into a special case.
--
~Randy
Marcos D. Marado Torres wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 9 Mar 2005, Geert Uytterhoeven wrote:
>
> >>>which is a patch against the 2.6.11.1 release. If consensus arrives
> >>>that this patch should be against the 2.6.11 tree, it will be done that
> >>>way in the future.
> >>
> >>IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> >>againt
> >>the last -rc but against 2.6.x.
> >
> >It's a stable release, not a pre/rc, so against 2.6.11.1 sounds most
> >logical to
> >me.
>
> Well, yes, _if_ 2.6.12 patch is going to be to aply against 2.6.11.last
> instead
> of 2.6.11. And, well, either one will cause great panic for hose who aren't
> and
> the mailing lists and just visit kernel.org to downoad the latest stuff.
<mode="enduser">
IMHO, as long as 2.6.12 patches against 2.6.11, I'm cool with 2.6.11.2
patching against 2.6.11.1, but I think it should patch against 2.6.11
instead
</mode>
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Wed, Mar 09, 2005 at 03:11:57PM -0800, Greg KH wrote:
> On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote:
> > On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> > > And to further test this whole -stable system, I've released 2.6.11.2.
> > > It contains one patch, which is already in the -bk tree, and came from
> > > the security team (hence the lack of the longer review cycle).
> > >
> > > It's available now in the normal kernel.org places:
> > > kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> > > which is a patch against the 2.6.11.1 release.
> >
> > Argh! @*#$&!!&!
> >
> > > If consensus arrives
> > > that this patch should be against the 2.6.11 tree, it will be done that
> > > way in the future.
> >
> > Consensus arrived back when 2.6.8.1 came out.
>
> It did? So, what was it agreed to be? Any pointers to that agreement?
Deltas against 2.6.x tarballs. The discussion was some large fraction
of the 2.6.8.1 announce thread. I think someone else mentioned it in
the recent renumbering thread, so I didn't feel the need to
pre-emptively whinge this time around..
> > Fixing it in the future is too #*$%* late because you've now turned it
> > into a special case.
>
> No, I can always respin the patch, and re-release it if it's a problem.
That'd make things easier, yes.
--
Mathematics is the supreme nostalgia of our time.
On Wed, Mar 09, 2005 at 12:11:02PM +0100, Pavel Machek wrote:
> On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Wed, 9 Mar 2005, Greg KH wrote:
> >
> > >which is a patch against the 2.6.11.1 release. If consensus arrives
> > >that this patch should be against the 2.6.11 tree, it will be done that
> > >way in the future.
> >
> > IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> > againt
> > the last -rc but against 2.6.x.
>
> You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
> means .11.2 should be relative to .11.1, because otherwise people will
> have to revert (ugly). And you want people to track -stable kernels as
> fast as possible.
There are three ways we can do this:
a) all 2.6.x.y are diffs against 2.6.x
b) interdiffs for .1, .2, etc. with 2.6.x+1 diffed against 2.6.x
c) interdiffs and 2.6.12 is a diff against 2.6.11.last
Imagine we want to go from 2.6.11.3 to 2.6.12
case a)
revert patch 2.6.11.3
get and apply 2.6.12
case b)
revert patch 2.6.11.3
revert patch 2.6.11.2
revert patch 2.6.11.1
get and apply 2.6.12
case c)
poke around on kernel.org and figure out that the last kernel in .11 is .11.5
get and apply 2.6.11.4
get and apply 2.6.11.5
get and apply 2.6.12
Note this gets increasingly more painful in cases b and c when there
are a large number of post-releases. And case c) is really stupid when
you want to go from 2.6.12 to 2.6.11.
Also note that -pre, -rc, -bk, -mm, -ac, and every other branch off a
release has worked the a) way.
--
Mathematics is the supreme nostalgia of our time.
Bill Davidsen <[email protected]> wrote:
> I think you need both x.y.z=>x.y.z.N and x.y.z.N-1=>x.y.z.N patches. My
> systems which are following the -stable will just need the most recent,
> but doing x.y.z-1=>x.y.z.N gets really ugly for higher values of N.
bzcat ../patch-2.6.nn.[0-9].*|patch -p1
On Thu, Mar 10, 2005 at 02:46:29AM +0100, Bodo Eggert wrote:
> Bill Davidsen <[email protected]> wrote:
>
> > I think you need both x.y.z=>x.y.z.N and x.y.z.N-1=>x.y.z.N patches. My
> > systems which are following the -stable will just need the most recent,
> > but doing x.y.z-1=>x.y.z.N gets really ugly for higher values of N.
>
> bzcat ../patch-2.6.nn.[0-9].*|patch -p1
You left out the steps where you fetch them and verify their signatures.
--
Mathematics is the supreme nostalgia of our time.
On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote:
> On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
> > And to further test this whole -stable system, I've released 2.6.11.2.
> > It contains one patch, which is already in the -bk tree, and came from
> > the security team (hence the lack of the longer review cycle).
> >
> > It's available now in the normal kernel.org places:
> > kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
> > which is a patch against the 2.6.11.1 release.
>
> Argh! @*#$&!!&!
>
> > If consensus arrives
> > that this patch should be against the 2.6.11 tree, it will be done that
> > way in the future.
>
> Consensus arrived back when 2.6.8.1 came out.
It did? So, what was it agreed to be? Any pointers to that agreement?
> Please, folks, there are automated tools that "know" about kernel
> release numbering and so on. Said tools broke with 2.6.11.1 because it
> wasn't in the same place that 2.6.8.1 was and now this breaks with all
> precedent by being an interdiff along a branch.
2.6.11.1 is now in the proper place, sorry for any inconvience that
caused. This happened yesterday.
> Fixing it in the future is too #*$%* late because you've now turned it
> into a special case.
No, I can always respin the patch, and re-release it if it's a problem.
thanks,
greg k-h
On Wed, Mar 09, 2005 at 03:57:16PM -0800, Matt Mackall wrote:
> Imagine we want to go from 2.6.11.3 to 2.6.12
The easiest way would be to keep a local fresh copy of 2.6.11 before
applying 2.6.11.3 anyway. That would solve a) and b) even more easily.
And yes, I find a) more logical. This is the way all private trees have
been working for ages. When you download 2.6.11-ac2, it's not a patch
against -ac1, but against 2.6.11. If you want to start from -ac1, you
get the 2.6.11-ac1-ac2 patch.
And last, since these patches are mostly bugfixes for the reference kernel
(eg: 2.6.11), it seems logical to be able to patch that kernel with the
latest bug fix.
cheers,
willy
> case a)
> revert patch 2.6.11.3
> get and apply 2.6.12
>
> case b)
> revert patch 2.6.11.3
> revert patch 2.6.11.2
> revert patch 2.6.11.1
> get and apply 2.6.12
>
> case c)
> poke around on kernel.org and figure out that the last kernel in .11 is .11.5
> get and apply 2.6.11.4
> get and apply 2.6.11.5
> get and apply 2.6.12
>
> Note this gets increasingly more painful in cases b and c when there
> are a large number of post-releases. And case c) is really stupid when
> you want to go from 2.6.12 to 2.6.11.
>
> Also note that -pre, -rc, -bk, -mm, -ac, and every other branch off a
> release has worked the a) way.
>
> --
> Mathematics is the supreme nostalgia of our time.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Wednesday 09 March 2005 18:11, Greg KH wrote:
>On Wed, Mar 09, 2005 at 01:06:31PM -0800, Matt Mackall wrote:
>> On Wed, Mar 09, 2005 at 12:39:23AM -0800, Greg KH wrote:
>> > And to further test this whole -stable system, I've released
>> > 2.6.11.2. It contains one patch, which is already in the -bk
>> > tree, and came from the security team (hence the lack of the
>> > longer review cycle).
>> >
>> > It's available now in the normal kernel.org places:
>> > kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.2.gz
>> > which is a patch against the 2.6.11.1 release.
>>
>> Argh! @*#$&!!&!
>>
>> > If consensus arrives
>> > that this patch should be against the 2.6.11 tree, it will be
>> > done that way in the future.
>>
>> Consensus arrived back when 2.6.8.1 came out.
>
>It did? So, what was it agreed to be? Any pointers to that
> agreement?
>
>> Please, folks, there are automated tools that "know" about kernel
>> release numbering and so on. Said tools broke with 2.6.11.1
>> because it wasn't in the same place that 2.6.8.1 was and now this
>> breaks with all precedent by being an interdiff along a branch.
>
>2.6.11.1 is now in the proper place, sorry for any inconvience that
>caused. This happened yesterday.
>
>> Fixing it in the future is too #*$%* late because you've now
>> turned it into a special case.
>
>No, I can always respin the patch, and re-release it if it's a
> problem.
Somewhat Greg, it caught me out. OTOH, once we know that .2 needs .1,
we'll be ok. And it does give a quick method for us frogs to define
if one of them is a regression. The only thing that should break if
we leave one out of the squence is the EXTRAVERSION path in the
Makefile & we can certainly fix that easily enough for testing.
Question? Is it a given that these, if they don't have warts, will be
in mainline 2.6.12?
>thanks,
>
>greg k-h
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
* Krzysztof Halasa ([email protected]) wrote:
> Another patch for 2.6.11.x: already in main tree, fixes kernel panic
> on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
> PCI200SYN.
> Also a documentation change fixing user-panic can-t-find-required-software
> failure (just the same patch as in mainline) :-)
We are not accepting documentation fixes. Could you please send just
the panic fix to [email protected] (cc lkml)? And add Signed-off-by...
thanks,
-chris
Matt Mackall wrote:
> On Wed, Mar 09, 2005 at 12:11:02PM +0100, Pavel Machek wrote:
>
>>On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>On Wed, 9 Mar 2005, Greg KH wrote:
>>>
>>>
>>>>which is a patch against the 2.6.11.1 release. If consensus arrives
>>>>that this patch should be against the 2.6.11 tree, it will be done that
>>>>way in the future.
>>>
>>>IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
>>>againt
>>>the last -rc but against 2.6.x.
>>
>>You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
>>means .11.2 should be relative to .11.1, because otherwise people will
>>have to revert (ugly). And you want people to track -stable kernels as
>>fast as possible.
>
>
> There are three ways we can do this:
>
> a) all 2.6.x.y are diffs against 2.6.x
> b) interdiffs for .1, .2, etc. with 2.6.x+1 diffed against 2.6.x
> c) interdiffs and 2.6.12 is a diff against 2.6.11.last
>
> Imagine we want to go from 2.6.11.3 to 2.6.12
>
> case a)
> revert patch 2.6.11.3
> get and apply 2.6.12
Would anyone actually do that? About the time of the first patch usually
do something like:
cd linux-2.6.11
cp -rl . ../linux-2.6.11.1
cd $_
bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
make oldconfig
By doing copy with links for all unchanged files you use virtually no
extra space for each revision, and that encourages creating a separate
tree for testing patches from -ck, or -ac, or Nick.
I use it to compile with various options as well, I usually build test
versions for P-II, P-III, P4-HT and Athlon depending on what I'm testing.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Fri, Mar 11, 2005 at 01:45:46PM -0500, Bill Davidsen wrote:
> Matt Mackall wrote:
> >On Wed, Mar 09, 2005 at 12:11:02PM +0100, Pavel Machek wrote:
> >
> >>On St 09-03-05 09:52:46, Marcos D. Marado Torres wrote:
> >>
> >>>-----BEGIN PGP SIGNED MESSAGE-----
> >>>Hash: SHA1
> >>>
> >>>On Wed, 9 Mar 2005, Greg KH wrote:
> >>>
> >>>
> >>>>which is a patch against the 2.6.11.1 release. If consensus arrives
> >>>>that this patch should be against the 2.6.11 tree, it will be done that
> >>>>way in the future.
> >>>
> >>>IMHO it sould be against 2.6.11 and not 2.6.11.1, like -rc's that are'nt
> >>>againt
> >>>the last -rc but against 2.6.x.
> >>
> >>You expect people to go through all 2.6.11.1, 2.6.11.2, ... . That
> >>means .11.2 should be relative to .11.1, because otherwise people will
> >>have to revert (ugly). And you want people to track -stable kernels as
> >>fast as possible.
> >
> >
> >There are three ways we can do this:
> >
> >a) all 2.6.x.y are diffs against 2.6.x
> >b) interdiffs for .1, .2, etc. with 2.6.x+1 diffed against 2.6.x
> >c) interdiffs and 2.6.12 is a diff against 2.6.11.last
> >
> >Imagine we want to go from 2.6.11.3 to 2.6.12
> >
> >case a)
> >revert patch 2.6.11.3
> >get and apply 2.6.12
>
> Would anyone actually do that? About the time of the first patch usually
> do something like:
> cd linux-2.6.11
> cp -rl . ../linux-2.6.11.1
> cd $_
> bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
> make oldconfig
In your world, do you want to do:
cp -rl linux-2.6.11 linux-2.6.11.5
cd linux-2.6.11.5
bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.2.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.3.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.4.bz2 | patch -p1
bzcat ../Patches/patch-2.6.11.5.bz2 | patch -p1
I suspect you might find that tedious, especially if only the last one
addressed a bug that affected you.
Or do you want to do it the same way you do for every other branch? I
don't want to special-case it in my code and I don't think users want
to special-case it in their brains. Have separate interdiffs on the
side, please, and then people can choose, but do it the standard way.
Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
broken for 2.6.11.2 and I don't want to cut a new release until a firm
decision is made. Obviously I have a strong preference for all 2.6.x.y
diffs being against 2.6.x, it means that .y can be treated the same as
-rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
out).
--
Mathematics is the supreme nostalgia of our time.
Gene Heskett wrote:
> Somewhat Greg, it caught me out. OTOH, once we know that .2 needs .1,
> we'll be ok. And it does give a quick method for us frogs to define
> if one of them is a regression. The only thing that should break if
> we leave one out of the squence is the EXTRAVERSION path in the
> Makefile & we can certainly fix that easily enough for testing.
2nd that, I'm so delighted to have -stable that I will happily accept
patches of what ever type you find easiest to produce, in this case
sequential incrementals. Just don't screw the process by changing it, we
can cope! Anyone who can't figure out how to generate the single big
diff against mainline shouldn't be patching kernels ;-)
>
> Question? Is it a given that these, if they don't have warts, will be
> in mainline 2.6.12?
I think Linus noted his intention to grab the fixes he likes. That's not
a determanent process by any means ;-)
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Chris Wright wrote:
> * Krzysztof Halasa ([email protected]) wrote:
>
>>Another patch for 2.6.11.x: already in main tree, fixes kernel panic
>>on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
>>PCI200SYN.
>>Also a documentation change fixing user-panic can-t-find-required-software
>>failure (just the same patch as in mainline) :-)
>
>
> We are not accepting documentation fixes. Could you please send just
> the panic fix to [email protected] (cc lkml)? And add Signed-off-by...
I really think you should not have a hard and fast rule on doc, for the
case where a fix also makes the mainline doc wrong and someone might do
something destructive reading the mainline docs and using the fixed
code. Drivers come to mind.
I am NOT saying this is such a case, I'm just against zero tolerance
rules when I can see a reasonable case where they don't do what you want.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
* Matt Mackall ([email protected]) wrote:
> Or do you want to do it the same way you do for every other branch? I
> don't want to special-case it in my code and I don't think users want
> to special-case it in their brains. Have separate interdiffs on the
> side, please, and then people can choose, but do it the standard way.
>
> Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> broken for 2.6.11.2 and I don't want to cut a new release until a firm
> decision is made. Obviously I have a strong preference for all 2.6.x.y
> diffs being against 2.6.x, it means that .y can be treated the same as
> -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> out).
I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
available on the side. Greg, any issue with that?
thanks,
-chris
Chris Wright <[email protected]> writes:
> * Krzysztof Halasa ([email protected]) wrote:
>> Another patch for 2.6.11.x: already in main tree, fixes kernel panic
>> on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
>> PCI200SYN.
>> Also a documentation change fixing user-panic can-t-find-required-software
>> failure (just the same patch as in mainline) :-)
>
> We are not accepting documentation fixes. Could you please send just
> the panic fix to [email protected] (cc lkml)? And add Signed-off-by...
Sure:
Signed-off-by: Krzysztof Halasa <[email protected]>
--- linux/drivers/net/wan/hd6457x.c 28 Oct 2004 06:16:08 -0000 1.15
+++ linux/drivers/net/wan/hd6457x.c 1 Mar 2005 00:58:08 -0000
@@ -315,7 +315,7 @@
#endif
stats->rx_packets++;
stats->rx_bytes += skb->len;
- skb->dev->last_rx = jiffies;
+ dev->last_rx = jiffies;
skb->protocol = hdlc_type_trans(skb, dev);
netif_rx(skb);
}
--
Krzysztof Halasa
* Krzysztof Halasa ([email protected]) wrote:
> Chris Wright <[email protected]> writes:
>
> > * Krzysztof Halasa ([email protected]) wrote:
> >> Another patch for 2.6.11.x: already in main tree, fixes kernel panic
> >> on receive with WAN cards based on Hitachi SCA/SCA-II: N2, C101,
> >> PCI200SYN.
> >> Also a documentation change fixing user-panic can-t-find-required-software
> >> failure (just the same patch as in mainline) :-)
> >
> > We are not accepting documentation fixes. Could you please send just
> > the panic fix to [email protected] (cc lkml)? And add Signed-off-by...
>
> Sure:
Thanks, added to queue.
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Fri, Mar 11, 2005 at 11:19:28AM -0800, Chris Wright wrote:
> * Matt Mackall ([email protected]) wrote:
> > Or do you want to do it the same way you do for every other branch? I
> > don't want to special-case it in my code and I don't think users want
> > to special-case it in their brains. Have separate interdiffs on the
> > side, please, and then people can choose, but do it the standard way.
> >
> > Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> > broken for 2.6.11.2 and I don't want to cut a new release until a firm
> > decision is made. Obviously I have a strong preference for all 2.6.x.y
> > diffs being against 2.6.x, it means that .y can be treated the same as
> > -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> > out).
>
> I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
> available on the side. Greg, any issue with that?
No, I agree with that, and will not be hard to do at all (the release
script already handles this just fine.)
I've held off rediffing 2.6.11.2 so far, as I don't know where to put
the x.y+1 interdiffs? kernel/v2.6/incr/ ? Any thoughts?
thanks,
greg k-h
On Friday 11 March 2005 14:23, Bill Davidsen wrote:
>Gene Heskett wrote:
>> Somewhat Greg, it caught me out. OTOH, once we know that .2 needs
>> .1, we'll be ok. And it does give a quick method for us frogs to
>> define if one of them is a regression. The only thing that should
>> break if we leave one out of the squence is the EXTRAVERSION path
>> in the Makefile & we can certainly fix that easily enough for
>> testing.
>
>2nd that, I'm so delighted to have -stable that I will happily
> accept patches of what ever type you find easiest to produce, in
> this case sequential incrementals. Just don't screw the process by
> changing it, we can cope! Anyone who can't figure out how to
> generate the single big diff against mainline shouldn't be patching
> kernels ;-)
Humm, that might be a pretty high fence for me to jump there Bill.
ATM, what I'm running is 11.2, with the bk-ieee1394.patch, and for my
uses, it certainly seems to be bulletproof. But then I'm not running
a server with 30,000 clients either, this is your classic geeks
desktop here, even if the geek is 70 years old. Firewire Just
Works(TM), usb seems to be back among the living and I'm a relatively
happy camper. Till the next patch comes out & I'll just *have* to
try it... :)
Heck, if the next .3 patch just was a relabeled bk-ieee1394.patch, I'd
be in Hog Heaven. And if the next patch after that made my
pcHDTV-3000 card work out of the box, I'd offer the patch maker a
couple of his favorite libations. Hows that for a good deal? So
far, thats a re-install after every reboot situation now because the
replacement modules are built out of the tree.
>> Question? Is it a given that these, if they don't have warts,
>> will be in mainline 2.6.12?
>
>I think Linus noted his intention to grab the fixes he likes. That's
> not a determanent process by any means ;-)
We've noted that previously. OTOH, he has always managed to come up
with perfectly valid objections to those not accepted if queried
about the whynots. I can't argue with that for a heartbeat since I
don't and cannot come close to having an overall view in as much
detail as he obviously keeps in his head.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Fri, 11 Mar 2005, Greg KH wrote:
> On Fri, Mar 11, 2005 at 11:19:28AM -0800, Chris Wright wrote:
> > * Matt Mackall ([email protected]) wrote:
> > > Or do you want to do it the same way you do for every other branch? I
> > > don't want to special-case it in my code and I don't think users want
> > > to special-case it in their brains. Have separate interdiffs on the
> > > side, please, and then people can choose, but do it the standard way.
> > >
> > > Dear ${SUCKER}s, can we have a decision on this? My ketchup tool is
> > > broken for 2.6.11.2 and I don't want to cut a new release until a firm
> > > decision is made. Obviously I have a strong preference for all 2.6.x.y
> > > diffs being against 2.6.x, it means that .y can be treated the same as
> > > -rc, -bk, -mm, ... (and I already coded it that way when 2.6.8.1 came
> > > out).
> >
> > I agree with having the patch be against .x, with x.y -> x.y+1 interdiffs
> > available on the side. Greg, any issue with that?
>
> No, I agree with that, and will not be hard to do at all (the release
> script already handles this just fine.)
>
> I've held off rediffing 2.6.11.2 so far, as I don't know where to put
> the x.y+1 interdiffs? kernel/v2.6/incr/ ? Any thoughts?
I guess incr is as good as any, I thought you would put the "against base"
somewhere, having already decided to do incrementals. Hopefully you will
at least change the numbering on the patch file (no, not the version in
the Makefile), so patch 2.6.11.3i is againt 2.6.11.2, and 2.6.11.3 is
against 2.6.11. That way people can tell after the download which one they
have if they forget.
I didn't like the initial decision to go incremental, and I even less like
changing now, but it's the right thing to do. It's not like we have a big
investment in scripts or anything, and you're doing the work.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, Mar 14, 2005 at 12:10:19PM -0500, Bill Davidsen wrote:
> I didn't like the initial decision to go incremental, and I even less like
> changing now, but it's the right thing to do. It's not like we have a big
> investment in scripts or anything, and you're doing the work.
And it's already done, see the 2.6.11.3 release announcement :)
greg k-h
Matt Mackall wrote:
> In your world, do you want to do:
>
> cp -rl linux-2.6.11 linux-2.6.11.5
> cd linux-2.6.11.5
> bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.2.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.3.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.4.bz2 | patch -p1
> bzcat ../Patches/patch-2.6.11.5.bz2 | patch -p1
>
> I suspect you might find that tedious, especially if only the last one
> addressed a bug that affected you.
Being lazy, I would do
bzcat ../Patches/patch-2.6.11.*.bz | patch -p1
(or similar). But as I posted long ago when this discussion started it
is desirable to have both.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Bill Davidsen wrote:
> Matt Mackall wrote:
>
>> In your world, do you want to do:
>>
>> cp -rl linux-2.6.11 linux-2.6.11.5
>> cd linux-2.6.11.5
>> bzcat ../Patches/patch-2.6.11.1.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.2.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.3.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.4.bz2 | patch -p1
>> bzcat ../Patches/patch-2.6.11.5.bz2 | patch -p1
>>
>> I suspect you might find that tedious, especially if only the last one
>> addressed a bug that affected you.
>
>
> Being lazy, I would do
> bzcat ../Patches/patch-2.6.11.*.bz | patch -p1
> (or similar). But as I posted long ago when this discussion started it
> is desirable to have both.
>
being super lazy I'd type:
scripts/patch-kernel . ../Patches
nb it's currently broke as mentioned in another thread:
Re: [BUG] Re: [PATCH] scripts/patch-kernel: use EXTRAVERSION
being fixed though. It will (I assume!) embody whatever rules are needed
to revoke patches to go from 2.6.11.5 to 2.6.12 (and since I think the
new version has d/l facilities, that should assist in the case of a base
kernel d/l of 2.6.11.3 for which no local patches exist to revert prior
to patching to 2.6.12)
David
On Wednesday 09 March 2005 03:39, Greg KH wrote:
>diff -Nru a/Makefile b/Makefile
>--- a/Makefile 2005-03-09 00:13:29 -08:00
>+++ b/Makefile 2005-03-09 00:13:29 -08:00
>@@ -1,7 +1,7 @@
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 11
>-EXTRAVERSION = .1
>+EXTRAVERSION = .2
> NAME=Woozy Numbat
>
> # *DOCUMENTATION*
>diff -Nru a/fs/eventpoll.c b/fs/eventpoll.c
>--- a/fs/eventpoll.c 2005-03-09 00:13:29 -08:00
>+++ b/fs/eventpoll.c 2005-03-09 00:13:29 -08:00
>@@ -619,6 +619,7 @@
> return error;
> }
>
>+#define MAX_EVENTS (INT_MAX / sizeof(struct epoll_event))
>
> /*
> * Implement the event wait interface for the eventpoll file. It is
> the kernel @@ -635,7 +636,7 @@
> current, epfd, events, maxevents, timeout));
>
> /* The maximum number of event must be greater than zero */
>- if (maxevents <= 0)
>+ if (maxevents <= 0 || maxevents > MAX_EVENTS)
> return -EINVAL;
>
> /* Verify that the area passed by the user is writeable */
>-
Greg, I have now pretty well confirmed that this patch is what caused
the tvtime audio breakage I was observing here. Rebooting to
2.6.11.1, everything works, rebooting to 2.6.11.2, and its broken.
ditto for .3 and .4, so last night I built a .5 (had to patch the
Makefiles EXTRAVERSION & rebuild before it would boot after the
build) but I built it *without* this patch, and everything works.
This patch looks good to me except for the added MAX_EVENTS define.
Did anyone actually put in a printk at that point and see what
MAX_EVENTS actually was by that define?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.