linux-kernel - Re: [PATCH 0/4] add task handling notifier

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]

Date:	Tue, 08 Jan 2008 13:38:03 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Christoph Hellwig" <hch@...radead.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	<pagg@....sgi.com>, <erikj@....com>, <pj@....com>,
	<matthltc@...ibm.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] add task handling notifier

>>> Andrew Morton <akpm@...ux-foundation.org> 25.12.07 23:05 >>>
>On Sun, 23 Dec 2007 12:26:21 +0000 Christoph Hellwig <hch@...radead.org> wrote:
>
>> On Thu, Dec 20, 2007 at 01:11:24PM +0000, Jan Beulich wrote:
>> > With more and more sub-systems/sub-components leaving their footprint
>> > in task handling functions, it seems reasonable to add notifiers that
>> > these components can use instead of having them all patch themselves
>> > directly into core files.
>> 
>> I agree that we probably want something like this.  As do some others,
>> so we already had a few a few attempts at similar things.  The first one
>> is from SGI and called PAGG (http://oss.sgi.com/projects/pagg/) and also
>> includes allocating per-task data for it's users.  Then also from SGI
>> there has been a simplified version called pnotify that's also available
>> from the website above.
>> 
>> Later Matt Helsley had something called "Task Watchers" which lwn has
>> an article on: http://lwn.net/Articles/208117/.
>> 
>> For some reason neither ever made a lot of progess (performance
>> problems?).
>> 
>
>I had it in -mm, sorted out all the problems but ended up not pulling the
>trigger.
>
>Problem is, it adds runtime overhead purely for the convenience of kernel
>programmers, and I don't think that's a good tradeoff.
>
>Sprinkling direct calls into a few well-known sites won't kill us, and
>we've survived this long.  Why not keep doing that, and save everyone a few
>cycles?

Am I to conclude then that there's no point in addressing the issues other
people pointed out? While I (obviously, since I submitted the patch disagree),
I'm not certain how others feel. My main point for disagreement here is (I'm
sorry to repeat this) that as long as certain code isn't allowed into the kernel
I think it is not unreasonable to at least expect the kernel to provide some
fundamental infrastructure that can be used for those (supposedly
unacceptable) bits. All I did here was utilizing the base infrastructure I want
added to clean up code that appeared pretty ad-hoc.

Jan

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