linux-kernel - Re: partial reiser4 review comments

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:	Fri, 4 Aug 2006 00:11:16 +0400
From:	Alexander Zarochentsev <zam@...esys.com>
To:	reiserfs-dev@...esys.com
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: partial reiser4 review comments

> I'm only partway through this, but let me unload my observations thus
> far. I still need to find a chunk of time for a file-by-file
> walkthrough and it's unobvious where that chunk will come from at
> present :(
>
>
> reiser4 as found in 2.6.18-rc2-mm1.
>
> - set_page_dirty_internal() pokes around in VFS internals.  Use
>   __set_page_dirty_no_buffers() or create a new library function in
>   mm/page-writeback.c.
>
>   In particular, it gets the radix-tree dirty tagging out of sync.
>
> - running igrab() in the writepage() path is really going to hammer
>   inode_lock.  Something else will need to be done here.
>
> - The preferred way of solving the above would be to mark the page as
>   PageWriteback() with set_page_writeback() prior to unlocking it. 
> That'll pin the page and the inode.  It does require that the page
> actually get written later on.  If we cannot do that then more
> thought is needed.
>
> - wbq.sem should be using a completion for the "wait until entd
> finishes", not a semaphore.  Because there's a teeny theoretical race
> when using semaphores this way which completions were designed to
> avoid.  (The waker can still be playing with the semaphore when it
> has gone out of scope on the wakee's stack).
>
> - write_page_by_ent(): the "spin until entd thread" thing is gross.

that spinlock is especially against the "teeny theoretical race...".  
good if completion will allow us to remove it.

>
>   This function is really lock-intensive.


Thanks,
Alex.

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