Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow

[Dave Jones]

On Fri, 2004-07-02 at 21:17, Marc Deslauriers wrote:
> On Fri, 2004-07-02 at 11:58, Jon Peatfield wrote:
> > Maybe now would be a good time to start thinking about moving (in a
> > few months maybe) to a kernel tree based on 2.4.26/27pre just to
> > reduce the total number of overlapping patches.
> > 
> 
> This would be a major undertaking. For starters, someone would have to
> backport nptl to work with 2.4.26/27, which would not be an easy task...

I did actually intend to do a rebase a while ago when 2.4.25 was
current, as it would've meant being able to drop a bunch of patches.
(And back then, I was hoping it would fix the 'fc1 smp crashes randomly'
bug as folks reported 2.4.25 fixed it for them -- this was before the
lowlatency problem was discovered).
I spent 2-3 days working off and on battling rejects, and didn't even
get close to finishing. I think I may have fixed up the rejects in NPTL
and started on execshield. I've no idea if it even would've booted,
there's always the danger of introducing new bugs when you rebase to a
newer release due to interactions with code in other parts of the kernel
which have changed without you realising, or just simple introductions
of typos.
I gave up in the end (and before anyone asks, I don't have the
work-in-progress stuff I did any more).

The really invasive patches in FC1 are 2.4.22-ac, NPTL, Exec-shield
and the O(1) process scheduler. 
The -ac patch could probably be dropped with a rebase (apart from maybe
a handful of fixes).   There is no newer NPTL patch (and there isn't
likely to be, as Ingo has enough on his plate).
A newer exec-shield exists, and shouldn't be too hard a merge after
a rebase.  The real painful bit is NPTL.

Thankfully from FC2 onwards, support after EOL should be a lot
easier for you folks due to the small number of patches, and
also do to us constantly tracking upstream anyway.

> > Fedora are maintaining 2.4.22 for fc1 
> > and we have 2.4.20 for RH73/80/9 etc.
> FL will only have to maintain two when fc1 stops being maintained by RH:
> 2.4.20 and 2.4.22. 

One thing I did have planned at one point was to migrate RHL to the FC1
kernel before end of life.  I never managed to nail enough critical bugs
before end of life of RHL9 though, so this never happened.
Todays FC1 kernel is in much better shape, so at some point, you may
want to consider it as an update for RHL9.  All the nptl switches
and the like are still present in the kernel spec too, allowing you
to use it for RHL7 updates if desired. (caveat: I've not tried using one
of these kernels -- or even built one, so I've no idea if this will just
work out of the box).

	Dave