[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: A few patches for 2.4.x for Alpha...



Attached is a (possibly temporary) patch for another 2.4 bug I found. This
time, executing something like the following code will cause a crash to srm
or an oops:
{
  unsigned long *myaddr = 0xffffffffffffc000;
  *myaddr = 7; /* bye bye */
}

It appears to me that the self-mapping entry in each task page table is
somehow getting corrupted, causing user mode permission bits to be set. I
don't even know why we have this mapping because a running kernel does not
use it. While the patch does make it go away, I'm still concerned that
something just happened to trash that memory. This one needs to be examined
closer.

Line 63 of linux-2.4.7/arch/alpha/mm/init.c

Btw, the clrfen and illop bug patch (entry.S/proto.h/traps.c) need to be
applied to 2.2.x kernels also!

Cheers,
Daniel

> -----Original Message-----
> From: Christopher C. Chimelis [mailto:chris@debian.org]
> Sent: Wednesday, August 01, 2001 5:59 PM
> To: Andrea Arcangeli
> Cc: daniel.potts@api-networks.com; rick.gorton@api-networks.com;
> debian-alpha@lists.debian.org
> Subject: A few patches for 2.4.x for Alpha...
> 
> 
> 
> I seem to be VERY unsuccessful in getting patches into the 
> kernel anymore,
> so I figured I'd try sending them to you first due to your 
> high success
> rate :-)
> 
> Attached is a patch that does three things:
> * drivers/char/rtc.c:
>   Removes MIPS DECstation epoch support for non-MIPS machines and adds
>   standard PC (1900) epoch support in its place (which will act
>   as a pre-2000 VMS epoch support patch as well).  It also 
> adds post-2000
>   VMS epoch support.
> 
>   My testing so far has shown that, with this patch, I can 
> NEVER seem to
>   guess the year incorrectly, regardless of where it was set.
> 
> * arch/alpha/kernel/smp.c:
>   Removed smp_tune_scheduling() function and the cacheflush_time var
>   since they weren't being used.  I also ran into a few machine types 
>   where this function being executed on an SMP machine during 
> boot caused
>   an oops.  I didn't bother looking into it too much (since the entire
>   purpose of the function was to determine cacheflush_time, which is
>   unused in the 2.4 scheduler code), but deleting the 
> function works in
>   getting SMP systems to boot 2.4 SMP kernels.
> 
> * arch/alpha/kernel/entry.S:
>   arch/alpha/kernel/proto.h:
>   arch/alpha/kernel/traps.c:
>   This patch is from Daniel Potts (a coworker) who found out 
> that, if the
>   user invokes the crlfen PALcode call, the kernel is unable 
> to cope with
>   not having access to the FP registers.  He wrote two asm stubs to
>   basically skip FP register access in these cases.  The 
> problem was found
>   to be extremely rare, but definite is a way for a user (non-root) to
>   crash a running Alpha.
> 
>   There's also a small patch from Rick Gorton (also a coworker) that
>   allows an illop trap to be handled correctly by the kernel.
> 
> If you have any questions about the patches, feel free to ask :-)  I'm
> extremely concerned about the problems that Daniel found 
> (with the ability
> of a common user to crash a running machine by just disabling FP
> registers), so the sooner this goes in, the better off we all 
> will be :-)
> 
> Thanks!
> C
> 
> 
> 

Attachment: linux-2.4.7-selfmap.patch
Description: Binary data

Attachment: clrfen-2.2.19-API.patch
Description: Binary data


Reply to: