public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Arun Raghavan <arun.raghavan@collabora.co.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] [RESEND] rlimits: Print more information when limits are exceeded
Date: Fri, 30 Mar 2012 16:12:43 +0200	[thread overview]
Message-ID: <4F75BF5B.7000306@canonical.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1203301455360.2542@ionos>

On 03/30/2012 03:39 PM, Thomas Gleixner wrote:
> On Fri, 24 Feb 2012, Arun Raghavan wrote:
>
>> This dumps some information in logs when a process exceeds its CPU or RT
>> limits (soft and hard). Makes debugging easier when userspace triggers
>> these limits.
>
> Why do we need to spam the logs with such information?
>
> SIGXCPU is only ever sent by this code. If there is a signal handler
> in the application it's easy to debug. If not it's even easier, the
> thing will simply be killed and you get the reason printed.

I'm not totally sure, but don't we log SIGSEGVs? If so, the same 
reasoning would apply to SIGSEGV.

> For the SIGKILL case there only a limited number of reasons why a
> SIGKILL is sent. So no, I rather commit a patch which removes that
> ugly printk which is already there instead of adding more of them.

The reason I proposed some kind of printk for SIGKILL, was to get some 
diagnostic information out of the SIGKILL. E g, if you have two threads 
both running on rtprio rlimits in the same process, it would be very 
interesting to know which one of them was causing the kernel to send 
SIGKILL.

Also, it could be useful to know whether the SIGKILL was actually sent 
by the kernel, or by some other process feeling evil (e g "kill -9").

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

  reply	other threads:[~2012-03-30 14:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 19:29 [PATCH] [RESEND] rlimits: Print more information when limits are exceeded Arun Raghavan
2012-03-30 13:39 ` Thomas Gleixner
2012-03-30 14:12   ` David Henningsson [this message]
2012-03-30 14:29     ` Thomas Gleixner
2012-03-30 17:19       ` Arun Raghavan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F75BF5B.7000306@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=arun.raghavan@collabora.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox