linux-kernel - Re: [4/7] dst: thread pool.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090119170749.GA24775@ioremap.net>
Date:	Mon, 19 Jan 2009 20:07:49 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	dst@...emap.net, David Howells <dhowells@...hat.com>
Subject: Re: [4/7] dst: thread pool.

Hi.

On Sun, Jan 18, 2009 at 04:10:41PM -0800, Arjan van de Ven (arjan@...radead.org) wrote:
> > 4: Your "dst thread pool"
> 
> from the context... I wouldn't be surprised if this can just use async
> function calls as well... it's simple enough on first sight.

No it can't. Since async function call requires additional allocation
which if failed fallbacks to the sync execution. This defeats the whole
purpose of the kernel thread. And this was already pointed to you Arjan,
but apparently you like to hide this.

Allocation in this path is very dangerous and even in case of atomic one
(which is used in the patch) this is a way heavy and unneded additional
overhead.

So neither DST nor pdflush should use such approach.

Arjan, please update your patch to met the feedback I gave in the
fsdevel mail list and do not allow to sneak the implementation if you do
not like the author :)

The only way to work with your async threads in the described cases is
to have a way to embed the needed event structure into the existing
objects like inode (which will be nacked by the fsdevel community for
reasone) or dst transaction (this may work). But existing size is
actually too big.

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