linux-kernel - Re: Formal Reiser4 inclusion and todo list?

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:	Mon, 2 Aug 2010 17:25:40 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	Christian Stroetmann <stroetmann@...olinux.com>
Cc:	Glenn D <doiggl@...ocitynet.com.au>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux reiserfs-devel <reiserfs-devel@...r.kernel.org>
Subject: Re: Formal Reiser4 inclusion and todo list?

On Sun, Aug 01, 2010 at 03:43:05PM +0200, Christian Stroetmann wrote:
> Hi Glenn;
> 
> On the 28.07.2010 21:58, I wrote:
> >Aloha Glenn;
> >
> >At the 28.07.2010 17:21, you (doiggl@...ocitynet.com.au) wrote:
> >>>The following items are still unaddressed:
> >>>
> >>>1. running igrab() in the writepage() path is really going to hammer
> >>>    inode_lock.  Something else will need to be done here.
> >>>
> >>>2. Running iput() in entd() is a bit surprising.  iirc there
> >>>are various
> >>>ways
> >>>    in which this can recur into the filesystem, perform I/O, etc.  I
> >>>guess it
> >>>    works..
> >>>    But again, it will hammer inode_lock.

inode_lock should be going away within 6 months or so, with the
vfs-scaling developments (see linux-fsdevel).

Inode refcounting becomes very light-weight, as it should be.


> >>>3. the writeout logic in entd_flush() is interesting (as in
> >>>"holy cow").
> >>>    It's very central and really needs some good comments describing
> >>what's
> >>>    going on in there - what problems are being solved, which decisions
> >>were
> >>>    taken and why, etc.
> >>>
> >>>4. reiser4_wait_page_writeback() needs commenting.
> >>>
> >>>5. reading the comment in txnmgr.c regarding MAP_SHARED pages: a number
> >>of
> >>>    things have changed since then.  We have page-becoming-writeable
> >>>    notifications and probably soon we'll always take a
> >>>pagefault when a
> >>>    MAP_SHARED page transitions from pte-clean to pte-dirty (although I
> >>>wouldn't
> >>>    recommend that a filesystem rely upon the latter for a while yet).

It is now possible to trap all dirtying activity from all sources
except get_user_pages (but filesystems tend to ignore that little
problem).

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