* Gary Jennejohn <[EMAIL PROTECTED]> [000402 01:43] wrote:
> This is a HEADS UP.
>
> The recent increase in MLEN from 128 to 256 bytes led to very surprising
> problems with the latest, so called developers', version of isdn4bsd.
>
> The new version uses slcompress by default. The change in MLEN makes
> struct slcompress 2KB larger than it used to be. BTW the entry csu_hdr
> in struct cstate, which has size MLEN, is not used anywhere in the kernel
> that I could find. csu_hdr is what leads to the increase in the size of
> struct slcompress. There's a comment in slcompress.h which states that
> MAX_HDR should really be defined as 128 and not MLEN. Maybe this should
> be taken to heart and MAX_HDR redefined as 128 and not MLEN.
>
> But I digress.
>
> struct slcompress is now in struct sppp, which is passed by ispppcontrol
> as part of an ioctl call. Eventually the kernel lands in sppp_params,
> which does a copyin to a struct spppreq (which contains struct sppp) on
> the kernel stack. Because struct sppp is 2KB larger as a result of the
> change in MLEN the copyin overruns the kernel stack which immediately
> results in a crash - no trace output, no ddb, zilch.
> Interesting is that the crash only happens on a Pentium (tested with
> a II and III). On a K6 it doesn't happen. AFAICT it's not related to
> using the FPU for copyin/copyout since I turned that functionality
> off using npx0 flags and the crash still happened.
>
> Moving the struct spppreq into global address space solves the problem,
> but that makes the kernel BSS somewhat larger. Redefining MAX_HDR to be
> 128 also fixes the problem, even with the struct spppreq on the stack.
>
> If those of you using slcompress start seeing problems then they may well
> be due to the increase in MLEN.
>
> I wonder how wise it was to change MLEN without more testing. But hey,
> this is -current, that's what it's there for.
>
> Anyway, I think MAX_HDR should be hardwired to 128 in slcompress. Any
> comments ?
>
Why not just malloc the structure instread of using a stack variable?
Various other parts of the kernel do so to get around this problem,
since we're heading up SMP now it _not_ the time to start using
global variables.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
