linux-kernel - Re: Out of memory management in embedded systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1191020439.2702.3.camel@entropy>
Date:	Fri, 28 Sep 2007 16:00:39 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	Rik van Riel <riel@...hat.com>
Cc:	Eric Dumazet <dada1@...mosbay.com>,
	"linux-os (Dick Johnson)" <linux-os@...logic.com>,
	Daniel Spång <daniel.spang@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Out of memory management in embedded systems

On Fri, 2007-09-28 at 11:15 -0400, Rik van Riel wrote:
> On Fri, 28 Sep 2007 16:36:34 +0200
> Eric Dumazet <dada1@...mosbay.com> wrote:
> 
> > On Fri, 28 Sep 2007 10:17:11 -0400
> > Rik van Riel <riel@...hat.com> wrote:
> > 
> > > On Fri, 28 Sep 2007 10:04:23 -0400
> > > "linux-os \(Dick Johnson\)" <linux-os@...logic.com> wrote:
> > > > On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
> > > > 
> > > > > On 9/28/07, linux-os (Dick Johnson) <linux-os@...logic.com> wrote:
> > > > >>
> > > > >> On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
> > > 
> > > > >>> Some kind of notification to the application that the available memory
> > > > >>> is scarce and let the application free up some memory (e.g., by
> > > > >>> flushing caches), could be used to improve the situation 
> > > 
> > > > Any networked appliance can (will) throw data away if there are
> > > > no resources available.
> > > 
> > > That is exactly what Daniel proposed in his first email.
> > > 
> > > I think his idea makes sense.
> > 
> > IBM AIX uses SIGDANGER, that kernel can raise in OOM conditions to warn
> > processes that are willing to handle this signal (default action for the
> >  SIGDANGER signal is to ignore the signal)
> 
> I suspect that SIGDANGER is not the right approach, because glibc
> memory arenas cannot be manipulated from inside a signal handler.
> 
> Also, "nearly OOM" is not the only such signal we would want to
> send to userspace programs. It would also be useful to inform
> userspace programs when we are about to start swapping something
> out, so userspace can discard cached data instead of having to
> wait for disk IO in the future.
> 
> A unix signal cannot encapsulate two different messages, while
> something like a "/dev/lowmem" device can simply be added into
> the program's main poll() loop and give many different messages.

SIGDANGER could stick useful information in siginfo_t's si_code field
and be delivered via a signalfd.

-- 
Nicholas Miell <nmiell@...cast.net>

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