linux-kernel - Re: per-thread rusage

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]

Message-ID: <a36005b50705011717g28023c58m431ec28413c1b613@mail.gmail.com>
Date:	Tue, 1 May 2007 17:17:28 -0700
From:	"Ulrich Drepper" <drepper@...il.com>
To:	"Theodore Tso" <tytso@....edu>,
	"Ulrich Drepper" <drepper@...il.com>,
	"Bill Irwin" <bill.irwin@...cle.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Eric Dumazet" <dada1@...mosbay.com>, linux-kernel@...r.kernel.org,
	wli@...omorphy.com
Subject: Re: per-thread rusage

On 5/1/07, Theodore Tso <tytso@....edu> wrote:
>         There are two ways of implementing this.  One is to have the
> JVM periodically poll using a pthread_getrusage() interface.

Not a good idea.

>  A better
> choice might be some kind of per-thread CPU limit, that would result
> in a thread-specific SIGXCPU signal.  But there are no interfaces
> today that do anything like this.

We have, in principal: setrlimit.  We jump through hoops in the moment
to make RLIMIT_CPU a per-process facility.  This is all nice.  All you
need to do is to add resources RLIMIT_*_THREAD (e.g.,
RLIMIT_CPU_THREAD) and additionally do accounting in a per-thread
basis.

The only issue which has to be decided is what is the action when the
limit is exceeded.  An unanswered signal kills the process, not just
the thread.  And you cannot just terminate a thread in the kernel
since there might be userlevel cleanup to do.  The thread library can
also not simply hijack the SIGXCPU signal, the application want to use
it.  The thread cancellation must appear like any other cancellation,
perhaps with a special status value (PTHREAD_CANCELED_XCPU instead of
PTHREAD_CANCEL).  But that's a userlevel detail.

So what would be additionally needed is a method to specify what
signal to sent.  The default might just as well be SIGXCPU but this
must be changable.
-
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/