linux-kernel - Re: [PATCH] async: Don't call async_synchronize_full_special() while holding sb

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: <20090109123140.GA18948@ioremap.net>
Date:	Fri, 9 Jan 2009 15:31:41 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Grissiom <chaos.proton@...il.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
Subject: Re: [PATCH] async: Don't call async_synchronize_full_special() while holding sb_lock

Hi Arjan.

Likely my mail is in your blacklist that's why you did not reply on
comment on the discussion about this async interface month or so ago :)

Anyway, what you did for the boot process should be only there, but vfs
changes have to be discussed in fsdevel.

For example generic_delete_inode() does not delete inode anymore,
instead it queues the work to the set of threads, serialized by the
global spinlock and atomic variables, allocating additional structure
for this not from the memory pool or at least memory cache, but
directly via slab.
This atomic allocation thus may be invoked during the cache shrink
path to free some memory, which is not a good idea. So if you do insist
that deletion of every inode should be async, at least shrink size of
the async_event and embed it into the inode, or use memory pool.

Just several other notes on the code.

__async_schedule() could first check amount of pending requests and
do not allocate and free the entry if all threads are busy.

entry processing code run_one_entry() should not free entry under the
irq-off lock.

Thread start routing should check if thread successfully started before
increasing number of the running thread, or this can be done in the
thread callback itself.

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