From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2948 invoked by alias); 20 Aug 2012 15:27:16 -0000 Received: (qmail 2936 invoked by uid 22791); 20 Aug 2012 15:27:15 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RP_MATCHES_RCVD,TW_JL X-Spam-Check-By: sourceware.org Received: from www.linutronix.de (HELO Galois.linutronix.de) (62.245.132.108) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Aug 2012 15:27:01 +0000 Received: from localhost ([127.0.0.1] helo=[172.123.10.21]) by Galois.linutronix.de with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1T3TsN-0006iZ-1o; Mon, 20 Aug 2012 17:26:47 +0200 Message-ID: <50325734.3090905@linutronix.de> Date: Mon, 20 Aug 2012 15:27:00 -0000 From: Sebastian Andrzej Siewior User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Peter Zijlstra CC: linux-kernel@vger.kernel.org, x86@kernel.org, Arnaldo Carvalho de Melo , Roland McGrath , Oleg Nesterov , Srikar Dronamraju , Ananth N Mavinakaynahalli , stan_shebs@mentor.com, gdb-patches@sourceware.org Subject: Re: [RFC 5/5] uprobes: add global breakpoints References: <1344355952-2382-1-git-send-email-bigeasy@linutronix.de> <1344355952-2382-6-git-send-email-bigeasy@linutronix.de> <1344857686.31459.25.camel@twins> In-Reply-To: <1344857686.31459.25.camel@twins> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00545.txt.bz2 On 08/13/2012 01:34 PM, Peter Zijlstra wrote: > I'm not really happy with any of this. I would suggest limiting this > stuff much further, like say only have it affect ptraced > processes/tasks. That way you cannot accidentally freeze the entire > system into oblivion. I'be been browsing over the cgroup Documentation and it seems to look usefull. What I have in mind is the following: /sys/fs/cgroup/gb The root group is the default one where a breakpoint triggers. Below you could have two groups: - excluded - active The excluded group would never trigger a breakpoint. Once a task in the root set triggers a breakpoint it will be moved into to the active set. The eventfd notifcation API of cgroups could be used to learn about this change. The whole concept fails if the user does not move a single task into the excluded group. To be overprotective here, I could try not do anything until we have at least one pid in the "excluded" set. So far I like this, it could be heat though. Sebastian