Fwd: Linux Broadcom 5820 Cryptonet Driver Integer Overflow

Simon Weller simon at nzservers.com
Sat Jul 3 15:01:44 UTC 2004


On Saturday 03 July 2004 08:21 am, Dave Jones wrote:
> 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 phrase 'extremely painful' comes to mind ;-)
>
> 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).
>
I'll try and dig out a spare box, put 7.3 on it and give it a go...just have 
to find some time to do it. 

But ultimately the less that has to be maintained has got to be a good thing.

- Si
> 	Dave
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list

-- 
Simon Weller LPIC-2, BCIP
Systems Engineer
NZServers LTD
http://www.nzservers.com/
U.S. Branch

<-
To mess up a Linux box, you need to work at it; to mess up your Windows box, 
you just need to work on it.
 - Scott Granneman, Security Focus
->





More information about the fedora-legacy-list mailing list