linux-kernel - [PATCH 0/4] unionfs: work better with tmpfs

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-next>] [day] [month] [year] [list]

Date:	Tue, 18 Dec 2007 22:10:34 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	Erez Zadok <ezk@...sunysb.edu>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] unionfs: work better with tmpfs

Here's a few patches to unionfs, which together with the tmpfs
patches I just posted, get that combination working better.

 fs/stack.c         |    6 +++
 fs/unionfs/inode.c |   83 +++++++++++++++++++++----------------------
 fs/unionfs/mmap.c  |    3 -
 3 files changed, 47 insertions(+), 45 deletions(-)

But on the way I've noticed a number of issues with unionfs not dealt
with in these patches.

1. Please try unionfs with lockdep configured on (perhaps while running LTP
to get coverage of a variety of cases): I soon gave up, not knowing which
way round the locks should really be taken e.g. unionfs_read_lock versus
unionfs_lock_dentry.

2. I'm worried about the locking generally (no doubt it's difficult!).
My 2/4 patch half-fixes one issue, but raises others: if some function
in a filesystem is usually called with i_mutex held, are you safe to be
calling it (not knowing that lower filesystem) without its i_mutex held?

3. LTP's rename14 tends to fill the filesystem with inodes, which prevent
further tests from running (but not on all machines: a timing issue perhaps).
I have to run LTP with rename14 moved aside.

4. Though you made improvements, some blocks still remain mysteriously
allocated even after the unionfs should be empty e.g. after an LTP run.

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