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: <20070502043100.GI26093@thunk.org>
Date:	Wed, 2 May 2007 00:31:00 -0400
From:	Theodore Tso <tytso@....edu>
To:	Ulrich Drepper <drepper@...il.com>
Cc:	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 Tue, May 01, 2007 at 05:17:28PM -0700, Ulrich Drepper wrote:
> 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.

Indeed; in fact it would be easier to do per-thread accounting than
our current per-process accounting, as you note.

> The thread library can also not simply hijack the SIGXCPU signal,
> the application want to use it.... 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.

The question is should we use setrlimit() to set the per-thread CPU
limit, given that we would need some separate interface to set signal
that should be sent.  

Is there any reason why we should have the interface specify whether
the signal should be directed to a specified process or kernel
thread-id, perhaps using si_pid field in the siginfo_t to specify
which thread had exceeded its CPU limit.  Or would this be overkill?

> 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.

Yep, I agree that thread cancellation is the right thing to happen at
the Posix Threads level.

Do you think this is something that we could get standardized into an
upcoming Posix/Posix Threads standard?  

						- Ted
-
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/