From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27636 invoked by alias); 26 Oct 2009 16:17:20 -0000 Received: (qmail 27584 invoked by uid 48); 26 Oct 2009 16:17:05 -0000 Date: Mon, 26 Oct 2009 16:17:00 -0000 From: "fche at redhat dot com" To: systemtap@sources.redhat.com Message-ID: <20091026161705.10848.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug runtime/10848] New: enforcement of memory limits X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00286.txt.bz2 It would be useful for a sysadmin to assert that a stap module (especially in unprivileged mode) not be allowed to consume more than some give MB of memory. This sort of thing could involve: - checking the .ko file at -p4 or -p5 time for ELF stats about .text/.data/.bss sizes, and comparing them to limits - perhaps teaching staprun to "create" free kernel memory (such as by creating a short-lived process that touches/consumes enough memory, then killing it just before the module_insert) - extending the _stp_*alloc functions to prematurely reject requests if limits are about to be exceeded - checking that every other use of kernel allocations go through _stp_alloc* - checking that all kernel-side memory allocations use __GFP_NORETRY or such to preclude triggering OOM handling elsewhere -- Summary: enforcement of memory limits Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime AssignedTo: systemtap at sources dot redhat dot com ReportedBy: fche at redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=10848 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.