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:	Tue, 1 Aug 2006 07:33:16 -0700
From:	Andrew Morton <akpm@...l.org>
To:	"Vladimir V. Saveliev" <vs@...esys.com>
Cc:	vda.linux@...glemail.com, linux-kernel@...r.kernel.org,
	Reiserfs-List@...esys.com
Subject: Re: reiser4: maybe just fix bugs?

On Tue, 01 Aug 2006 15:24:37 +0400
"Vladimir V. Saveliev" <vs@...esys.com> wrote:

> > >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.
> 
> Yes. reiser4 writeouts atoms. Most of pages get into atoms via
> sys_write. But pages dirtied via shared mapping do not. They get into
> atoms in reiser4's writepages address space operation.

It think you mean ->writepage - reiser4 desn't implement ->writepages().

I assume you considered hooking into ->set_page_dirty() to do the
add-to-atom thing earlier on?

We'll merge mm-tracking-shared-dirty-pages.patch into 2.6.19-rc1, which
would make that approach considerably more successful, I expect. 
->set_page_dirty() is a bit awkward because it can be called under
spinlock.

Maybe comething could also be gained from the new
vm_operations_struct.page_mkwrite(), although that's less obvious...

> That is why
> reiser4_sync_inodes has two steps: on first one it calls
> generic_sync_sb_inodes to call writepages for dirty inodes to capture
> pages dirtied via shared mapping into atoms. Second step flushes atoms.
> 
> > >
> > 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. 
> 
> xattrs is really a problem.

That's not good.  The ability to properly support SELinux is likely to be
important.
-
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/