Re: 2.6.6-rc3-mm2 (4KSTACK)

From: Bartlomiej Zolnierkiewicz (B.Zolnierkiewicz_at_elka.pw.edu.pl)
Date: 05/12/04

  • Next message: Fernando Paredes: "Toshiba keyboard lockups"
    To: Bill Davidsen <davidsen@tmr.com>
    Date:	Wed, 12 May 2004 01:27:33 +0200
    
    

    On Tuesday 11 of May 2004 18:24, Bill Davidsen wrote:
    > On Sun, 9 May 2004, Bartlomiej Zolnierkiewicz wrote:
    > > On Sunday 09 of May 2004 19:00, Bill Davidsen wrote:
    > > > No it's not that simple, this has nothing to do with binary modules,
    > > > and everything to do with not making 4k stack the only available
    > > > configuration in 2.6. Options are fine, but in a stable kernel series I
    > > > don't think think that the default should change part way into the
    > > > series, and certainly the availability of the original functionality
    > > > shouldn't go away, which is what I read AKPMs original post to state as
    > > > the goal.
    > >
    > > What functionality are you talking about?
    > > We don't care about out of tree kernel code (be it GPL or Proprietary).
    >
    > Let me say this one more time, since you keep changing the topic so you
    > can say that you don't care about something I never mentioned. I am
    > **NOT** talking about binary modules, I am **NOT** talking about out of
    > tree code, I am talking about applications which make calls that cause the
    > **IN TREE** code to use more than 4k.

    No need to flame, I really didn't know what you were talking about.

    I agree that this is a very good argument against pushing this
    change to mainline quickly (proposed originally by AKPM).

    > > > Making changes to the kernel which will break existing applications
    > > > seems to be the opposite of "stable." People who want a new kernel for
    > > > fixes don't usually want to have to upgrade and/or rewrite their
    > > > applications. The "we change the system interface everything we fix a
    > >
    > > You don't understand what the patch is really about.
    > >
    > > This is kernel stack not the user-space one so
    > > this change can't brake any application.
    >
    > Right, the kernel code does not contain any places where the data passed
    > in a system call isn't reflected in stack usage.

    It won't break applications it will break kernel first. ;-)

    You need to fix kernel code not the user space.

    > > > bug" approach comes from a well-known software company, but shouldn't
    > > > be the way *good* software is done.
    > >
    > > It doesn't change any kernel interface visible to user-space
    > > and stack hungry kernel code needs fixing anyway.
    >
    > And what better way to detect it than to release it in a stable kernel.
    > Don't bother to say "don't use -mm" AKPM has said it is intended for the
    > stable kernel, work or not.

    I see no problem with this approach (this patch in -mm then in linus')
    but issues mentioned by you need fixing first. I'm not proposing to
    push it to mainline NOW - it needs to be done CAREFULLY but CAN be
    done in 2.6 (i.e. 2.6.15).

    I guess this is what we can't agree on.

    > ===
    > Third request for info
    > ===
    > I still haven't seen any objective data showing that there is any
    > measureable benefit from this, although I agree that smaller is good
    > practice, I don't think that throwing in a feature in a stable kernel,
    > which has been reported by others to corrupt data, is the best way to do
    > it.

    There was some evidence from AKPM (and Arjan AFAIR).
    [ BTW wasn't the corruption only seen with nvidia module? ]
    I think we can prevent it by adding something ala 4kstack flag
    to the module.

    Regards,
    Bartlomiej

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Fernando Paredes: "Toshiba keyboard lockups"

    Relevant Pages

    • Re: [RFC: 2.6 patch] let GROUP_SCHED depend on BROKEN
      ... kernel developers. ... you've never before written a _single_ Linux kernel feature ... have no desire _at all_ to write true kernel code. ... the level of trivialities. ...
      (Linux-Kernel)
    • Re: [patch 4/4] KVM-trace port to tracepoints
      ... Tracepoints allow dormat instrumentation, like the kernel markers, but also ... This patch depends on the "Tracepoints" patch. ... Is it a specific property of KVM-trace that causes this LOC blow-up? ... strings into the kernel code, which, to some, looks like debugging code. ...
      (Linux-Kernel)
    • Re: 2.6.6-rc3-mm2 (4KSTACK)
      ... > We don't care about out of tree kernel code. ... in a system call isn't reflected in stack usage. ... And what better way to detect it than to release it in a stable kernel. ...
      (Linux-Kernel)
    • Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes
      ... If XCRYPT may be interrupted and the interrupt code again uses this optimized ... How could any kernel code use MMX/SSE/FPU when the interrupt case isn't ... Or is your argument that its lazy allocation itself is the problem: ... If this were right than any kernel code executing SSE may trigger now a oops ...
      (Linux-Kernel)
    • Re: When was /dev/cua* depreciated?
      ... so it has a kernel module in it. ... The installer shell script has no shebang at the top. ... so perhaps they no what needs to be done for the kernel code. ... to the serial/ethernet converter on the network, ...
      (uk.comp.os.linux)