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"