From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/208 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: holywar: malloc() vs. OOM Date: Sun, 24 Jul 2011 18:19:07 -0400 Message-ID: <20110724221907.GL132@brightrain.aerifal.cx> References: <20110724103325.GA24069@albatros> <20110724124034.GI132@brightrain.aerifal.cx> <20110724182533.GB6429@albatros> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1311546601 32387 80.91.229.12 (24 Jul 2011 22:30:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2011 22:30:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-292-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 25 00:29:58 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Ql7BN-0002S8-HT for gllmg-musl@lo.gmane.org; Mon, 25 Jul 2011 00:29:57 +0200 Original-Received: (qmail 8020 invoked by uid 550); 24 Jul 2011 22:29:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 8012 invoked from network); 24 Jul 2011 22:29:57 -0000 Content-Disposition: inline In-Reply-To: <20110724182533.GB6429@albatros> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:208 Archived-At: On Sun, Jul 24, 2011 at 10:25:33PM +0400, Vasiliy Kulikov wrote: > Oh, I forgot one major detail - the kernel by default have memory > overcommit enabled (sysctl vm.overcommit_memory=0). It means that even > [...] > For overcommit disabled OOM graceful handling should be possible, but > I'm not sure it is _guaranteed_ that memory allocated by brk() and > mmap() will be really available in the future. Any system without this guarantee is a TOY, nothing more. I'm aware that the default sucks, but that's not an excuse to break things for competent admins who know how to fix the default... > So, yes, if the program guarantees that it gracefully handle OOM *for > sure*, then the workaround is indeed a breakage. But I'm sure such > programs are hell rare. BTW, do you know such programs, except DBUS? :) Pretty much any decent httpd, sshd, database, etc. should handle OOM just fine - rejecting any connections for which the necessary allocation fails. Having the daemon crash and not accept further connections after the OOM condition is over would be very bad behavior. Of course DJB liked writing software that way and using a secondary daemon to restart his daemons when they crash, but that's really unprofessional... and you can certainly come up with applications where it would be very bad to have to restart when somebody OOM'd it - a multiplayer game server comes to mind... > > A better solution might be to have a gcc option to generate a read > > from the base address the first time a function performs arithmetic on > > a pointer it has not already checked. This is valid because the C > > language does not allow pointer arithmetic to cross object boundaries, > > and this approach could be made 100% correct rather than being a > > heuristic that breaks correct applications. > > A good idea. It would be interesting to show actual numbers of the > slowdown. However, most of the time it would be a slowdown for no > actual gain. Actually it might be a speedup since it would act like a prefetch... :) Rich