linux-kernel - Re: [PATCH] powerpc pseries eeh: Convert to kthread API

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: <1177378733.14873.52.camel@localhost.localdomain>
Date:	Tue, 24 Apr 2007 11:38:53 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linas Vepstas <linas@...tin.ibm.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"<Andrew Morton" <akpm@...l.org>, containers@...ts.osdl.org,
	Oleg Nesterov <oleg@...sign.ru>, linux-kernel@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>, linux-s390@...r.kernel.org,
	linuxppc-dev@...abs.org
Subject: Re: [PATCH] powerpc pseries eeh: Convert to kthread API


> The only reason for using threads here is to get the error recovery
> out of an interrupt context (where errors may be detected), and then,
> an hour later, decrement a counter (which is how we limit these to 
> 6 per hour). Thread reaping is "trivial", the thread just exits
> after an hour.

In addition, it should be a thread and not done from within keventd
because :

 - It can take a long time (well, relatively but still too long for a
work queue)

 - The driver callbacks might need to use keventd or do flush_workqueue
to synchronize with their own workqueues when doing an internal
recovery.

> Since these are events rare, I've no particular concern about
> performance or resource consumption. The current code seems 
> to work just fine. :-)

I think moving to kthread's is cleaner (just a wrapper around kernel
threads that simplify dealing with reaping them out mostly) and I agree
with Christoph that it would be nice to be able to "fire off" kthreads
from interrupt context.. in many cases, we abuse work queues for things
that should really done from kthreads instead (basically anything that
takes more than a couple hundred microsecs or so).

Ben.


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