linux-kernel - Re: [RESEND RFC] SIGOOM Proposal

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20230112051342.GB19712@1wt.eu>
Date:   Thu, 12 Jan 2023 06:13:42 +0100
From:   Willy Tarreau <w@....eu>
To:     Arseniy Lesin <emptiedsoul@...dclanz.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [RESEND RFC] SIGOOM Proposal

Hello,

On Thu, Jan 12, 2023 at 07:51:45AM +0300, Arseniy Lesin wrote:
> 2.1. The SIGOOM Signal
> ------------------
> 
> I propose the addition of new signal: SIGOOM (Out-Of-Memory SIGnal) 
> 
> This signal is intended to be sent to the most memory-hungry process(es)
> in order to give process a chance to release memory used for
> non-valuable data (for example, browser can unload tabs, that are
> currently not in use, assuming tabs are not separate processes) or to
> write down valuable data and exit gracefully (for example, some
> graphical editor).
> 
> Some applications can even set up a poll for OOM event by using signalfd
> 
> Default action: 	IGNORE
> Proposed senders: 	kernel- and user-space OOM-killers
> 
> The technical detail of this addition is a bit unpleasant: there is
> actually no room for new signals! 

Do this simpler, let userspace configure the signal it wants to
receive for this via a new prctl(PR_SET_OOMSIG) and this would allow
each process to voluntarily declare this intended behavior and the
associated signal at the same time. There are already other comparable
mechanisms existing there (signal to receive on parent's death, or on
memory error for example).

Willy