Messages in this thread | | | From | Bartlomiej Zolnierkiewicz <> | Subject | Re: 2.6.6-rc3-mm2 (4KSTACK) | 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/
| |