From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263642AbUEGPzR (ORCPT ); Fri, 7 May 2004 11:55:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263644AbUEGPyk (ORCPT ); Fri, 7 May 2004 11:54:40 -0400 Received: from outgoingmail.adic.com ([63.81.117.28]:29115 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id S263642AbUEGPxj (ORCPT ); Fri, 7 May 2004 11:53:39 -0400 Message-ID: <409BAFAC.70601@xfs.org> Date: Fri, 07 May 2004 10:47:56 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.6 (X11/20040502) X-Accept-Language: en MIME-Version: 1.0 To: Dave Jones CC: Arjan van de Ven , Paul Jakma , Valdis.Kletnieks@vt.edu, Andrew Morton , Linux Kernel ML Subject: Re: 2.6.6-rc3-mm2 (4KSTACK) References: <20040505013135.7689e38d.akpm@osdl.org> <200405051312.30626.dominik.karall@gmx.net> <200405051822.i45IM2uT018573@turing-police.cc.vt.edu> <20040505215136.GA8070@wohnheim.fh-wedel.de> <200405061518.i46FIAY2016476@turing-police.cc.vt.edu> <1083858033.3844.6.camel@laptop.fenrus.com> <20040507065105.GA10600@devserv.devel.redhat.com> <20040507151317.GA15823@redhat.com> In-Reply-To: <20040507151317.GA15823@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Dave Jones wrote: > On Fri, May 07, 2004 at 08:51:05AM +0200, Arjan van de Ven wrote: > > > > On Fri, May 07, 2004 at 01:37:54AM +0100, Paul Jakma wrote: > > > On Thu, 6 May 2004, Arjan van de Ven wrote: > > > > > > > Ok I don't want to start a flamewar but... Do we want to hold linux > > > > back until all binary only module vendors have caught up ?? > > > > > > What about normal linux modules though? Eg, NFS (most likely): > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121804 > > > > NFSv4 has a > 1Kb stack user; Dave Jones has a fix pending for that... > > Hmm, this one maybe? > > Dave > > > - if (mlen > sizeof(buf)) > + obj.data = kmalloc(1024, GFP_KERNEL); > + if (!obj.data) > + return -ENOMEM; > + > + if (mlen > 1024) { That's what I hate about all of this, just think how much stack that kmalloc can take in low memory situations.... it might end up in writepage on another nfs file.... Moving stuff off the stack and into kmalloc just reduces the possibility of stack overflow, it does not fix the problem. Having memory reclaim take place inside the thread which is waiting for memory makes that a pretty hard problem to fix. Steve