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]
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/

Powered by blists - more mailing lists