linux-kernel - Re: reiser4: maybe just fix bugs?

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, 31 Jul 2006 20:18:50 -0600
From:	Hans Reiser <reiser@...esys.com>
To:	Andrew Morton <akpm@...l.org>
CC:	Denis Vlasenko <vda.linux@...glemail.com>,
	linux-kernel@...r.kernel.org,
	Reiserfs mail-list <Reiserfs-List@...esys.com>,
	Reiserfs developers mail-list <Reiserfs-Dev@...esys.com>
Subject: Re: reiser4: maybe just fix bugs?

Andrew Morton wrote:

>On Mon, 31 Jul 2006 10:26:55 +0100
>"Denis Vlasenko" <vda.linux@...glemail.com> wrote:
>
>  
>
>>The reiser4 thread seem to be longer than usual.
>>    
>>
>
>Meanwhile here's poor old me trying to find another four hours to finish
>reviewing the thing.
>  
>
Thanks Andrew.

>The writeout code is ugly, although that's largely due to a mismatch between
>what reiser4 wants to do and what the VFS/MM expects it to do.
>
I agree --- both with it being ugly, and that being part of why.

>  If it
>works, we can live with it, although perhaps the VFS could be made smarter.
>  
>
I would be curious regarding any ideas on that.  Next time I read
through that code, I will keep in mind that you are open to making VFS
changes if it improves things, and I will try to get clever somehow and
send it by you.  Our squalloc code though is I must say the most
complicated and ugliest piece of code I ever worked on for which every
cumulative ugliness had a substantive performance advantage requiring us
to keep it.  If you spare yourself from reading that, it is
understandable to do so.

>I'd say that resier4's major problem is the lack of xattrs, acls and
>direct-io.  That's likely to significantly limit its vendor uptake.  (As
>might the copyright assignment thing, but is that a kernel.org concern?)
>  
>
Thanks to you and the batch write code, direct io support will now be
much easier to code, and it probably will get coded the soonest of those
features.  acls are on the todo list, but doing them right might require
solving a few additional issues (finishing the inheritance code, etc.)

>The plugins appear to be wildly misnamed - they're just an internal
>abstraction layer which permits later feature additions to be added in a
>clean and safe manner.  Certainly not worth all this fuss.
>
>Could I suggest that further technical critiques of reiser4 include a
>file-and-line reference?  That should ease the load on vger.
>
>Thanks.
>
>
>  
>

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