From: Hans Reiser <reiser@namesys.com>
To: Pekka Enberg <penberg@gmail.com>, vs <vs@thebsh.namesys.com>
Cc: Andi Kleen <ak@suse.de>,
Alexander Lyamin aka FLX <flx@namesys.com>,
Alexander Zarochentcev <zam@namesys.com>,
vs <vs@thebsh.namesys.com>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org,
ReiserFS List <reiserfs-list@namesys.com>,
Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: -mm -> 2.6.13 merge status
Date: Thu, 23 Jun 2005 00:42:01 -0700 [thread overview]
Message-ID: <42BA67C9.7060604@namesys.com> (raw)
In-Reply-To: <84144f0205062223226d560e41@mail.gmail.com>
Pekka Enberg wrote:
>Hi Hans,
>
>On 6/22/05, Hans Reiser <reiser@namesys.com> wrote:
>
>
>>I would in particular love to have you Andi Kleen do a full review of V4
>>if you could be that generous with your time, as I liked much of the
>>advice you gave us on V3.
>>
>>
>
>Well, I am not Andi Kleen and this is not even in the ballpark of a full
>review but here goes...
>
>
thanks kindly for your time, your comments were appreciated
>P.S. Would it be possible to have a version without the plugin stuff
>submitted (and perhaps file as directory)?
>
No, I am sorry. It is like asking for ext2 without directories.
> It would make much more
>sense for the rest of us to review reiser4 without the most controversial
>bits and get the bits that people agree on merged.
>
> Pekka
>
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/pool.c 2005-06-03 17:49:38.668204642 +0400
>>+/* initialise new pool */
>>+reiser4_internal void
>>+reiser4_init_pool(reiser4_pool * pool /* pool to initialise */ ,
>>+ size_t obj_size /* size of objects in @pool */ ,
>>+ int num_of_objs /* number of preallocated objects */ ,
>>+ char *data /* area for preallocated objects */ )
>>+{
>>+ reiser4_pool_header *h;
>>+ int i;
>>+
>>+ assert("nikita-955", pool != NULL);
>>
>>
>
>These assertion codes are meaningless to the rest of us so please drop
>them.
>
>
I think you don't appreciate the role of assertions in making code
easier to audit and debug.
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/type_safe_hash.h 2005-06-03 17:49:38.751209197 +0400
>>@@ -0,0 +1,320 @@
>>+/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by
>>+ * reiser4/README */
>>+
>>+/* A hash table class that uses hash chains (singly-linked) and is
>>+ parametrized to provide type safety. */
>>
>>
>
>This belongs to include/linux, not reiser4.
>
>
Too much politics are involved in modifying other peoples directories,
or I'd agree with you. The first person outside the reiser4 project to
use it should move it into a different place.
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/type_safe_list.h 2005-06-03 17:49:38.755209417 +0400
>>@@ -0,0 +1,436 @@
>>+/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by reiser4/README */
>>+
>>+#ifndef __REISER4_TYPE_SAFE_LIST_H__
>>+#define __REISER4_TYPE_SAFE_LIST_H__
>>+
>>+#include "debug.h"
>>+/* A circular doubly linked list that differs from the previous
>>+ <linux/list.h> implementation because it is parametrized to provide
>>+ type safety. This data structure is also useful as a queue or stack.
>>
>>
>
>This belongs to include/linux, not reiser4.
>
>
Yes, but see above about first person outside reiser4 project should.....
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/vfs_ops.c 2005-06-03 17:51:28.110210237 +0400
>>+/* ->get_sb() method of file_system operations. */
>>+static struct super_block *
>>+reiser4_get_sb(struct file_system_type *fs_type /* file
>>+ * system
>>+ * type */ ,
>>+ int flags /* flags */ ,
>>+ const char *dev_name /* device name */ ,
>>+ void *data /* mount options */ )
>>
>>
>
>Please drop the useless parameter comments.
>
>
vs, figure out who added the flags and device name comments and ask them
to prepare a patch. If nobody admits to the shameful act,;-) have
Edward fix it.
>
>
>>+/*
>>+ * Initialization stages for reiser4.
>>+ *
>>+ * These enumerate various things that have to be done during reiser4
>>+ * startup. Initialization code (init_reiser4()) keeps track of what stage was
>>+ * reached, so that proper undo can be done if error occurs during
>>+ * initialization.
>>+ */
>>+typedef enum {
>>+ INIT_NONE, /* nothing is initialized yet */
>>+ INIT_INODECACHE, /* inode cache created */
>>+ INIT_CONTEXT_MGR, /* list of active contexts created */
>>+ INIT_ZNODES, /* znode slab created */
>>+ INIT_PLUGINS, /* plugins initialized */
>>+ INIT_PLUGIN_SET, /* psets initialized */
>>+ INIT_TXN, /* transaction manager initialized */
>>+ INIT_FAKES, /* fake inode initialized */
>>+ INIT_JNODES, /* jnode slab initialized */
>>+ INIT_EFLUSH, /* emergency flush initialized */
>>+ INIT_FQS, /* flush queues initialized */
>>+ INIT_DENTRY_FSDATA, /* dentry_fsdata slab initialized */
>>+ INIT_FILE_FSDATA, /* file_fsdata slab initialized */
>>+ INIT_D_CURSOR, /* d_cursor suport initialized */
>>+ INIT_FS_REGISTERED, /* reiser4 file system type registered */
>>+} reiser4_init_stage;
>>
>>
>
>Please use regular gotos instead. This is a silly hack especially since you
>don't have release function for all of the stages.
>
>
I'll let vs comment.
>
>
>>+reiser4_internal void reiser4_handle_error(void)
>>+{
>>+ struct super_block *sb = reiser4_get_current_sb();
>>+
>>+ if ( !sb )
>>+ return;
>>+ reiser4_status_write(REISER4_STATUS_DAMAGED, 0, "Filesystem error occured");
>>+ switch ( get_super_private(sb)->onerror ) {
>>+ case 0:
>>+ reiser4_panic("foobar-42", "Filesystem error occured\n");
>>+ case 1:
>>+ if ( sb->s_flags & MS_RDONLY )
>>+ return;
>>+ sb->s_flags |= MS_RDONLY;
>>+ break;
>>+ case 2:
>>+ machine_restart(NULL);
>>
>>
>
>Probably not something you should do at fs level.
>
>
Not sure why you say that.
vs, given the existence of case 0, why do we need to have case 2?
>
>
>>+/* free this znode */
>>+reiser4_internal void
>>+zfree(znode * node /* znode to free */ )
>>+{
>>+ assert("nikita-465", node != NULL);
>>+ assert("nikita-2120", znode_page(node) == NULL);
>>+ assert("nikita-2301", owners_list_empty(&node->lock.owners));
>>+ assert("nikita-2302", requestors_list_empty(&node->lock.requestors));
>>+ assert("nikita-2663", capture_list_is_clean(ZJNODE(node)) && NODE_LIST(ZJNODE(node)) == NOT_CAPTURED);
>>+ assert("nikita-2773", !JF_ISSET(ZJNODE(node), JNODE_EFLUSH));
>>+ assert("nikita-3220", list_empty(&ZJNODE(node)->jnodes));
>>+ assert("nikita-3293", !znode_is_right_connected(node));
>>+ assert("nikita-3294", !znode_is_left_connected(node));
>>+ assert("nikita-3295", node->left == NULL);
>>+ assert("nikita-3296", node->right == NULL);
>>
>>
>
>Are all these still required? Seems bit too defensive for the kernel.
>
>
Hmm, someday must put you in a room with DARPA guys, and let you get us
another round of funding by trying to convince them that our code is too
defensive.;-)
This is not too defensive. Nikita did well here. The culture of code
auditors is very different from most programmers. Like most
specialists, they have wisdom to offer those who listen to them. In
essence, they teach that every function should have a specification of
every possible restriction on allowed input that can be imagined and is
correct as a restriction. Code auditors love assertions like this. I
look at my understanding of this before DARPA, and I wince. DARPA
patiently taught me much in this area as I listened to security talks at
our meetings, and I thank them for it.
Large scale projects like reiser4 are crippled by debugging costs.
Anything that reduces debugging time is worth so much.....
>
>
>>+
>>+
>>+ /* not yet phash_jnode_destroy(ZJNODE(node)); */
>>+
>>+ /* poison memory. */
>>+ ON_DEBUG(memset(node, 0xde, sizeof *node));
>>
>>
>
>Poisoning belongs to slab, not fs.
>
>
vs, please comment.
>
>
>>+/* allocate fresh znode */
>>+reiser4_internal znode *
>>+zalloc(int gfp_flag /* allocation flag */ )
>>+{
>>+ znode *node;
>>+
>>+ node = kmem_cache_alloc(znode_slab, gfp_flag);
>>+ return node;
>>+}
>>
>>
>
>Please drop this useless wrapper.
>
>
Thanks. vs, I think he is right here.... I see zalloc used in only two
places..... Or is the desire to ease future porting work?
>
>
>>+reiser4_internal void
>>+znode_remove(znode * node /* znode to remove */ , reiser4_tree * tree)
>>+{
>>+ assert("nikita-2108", node != NULL);
>>+ assert("nikita-470", node->c_count == 0);
>>+ assert("zam-879", rw_tree_is_write_locked(tree));
>>+
>>+ /* remove reference to this znode from cbk cache */
>>+ cbk_cache_invalidate(node, tree);
>>+
>>+ /* update c_count of parent */
>>+ if (znode_parent(node) != NULL) {
>>+ assert("nikita-472", znode_parent(node)->c_count > 0);
>>+ /* father, onto your hands I forward my spirit... */
>>+ znode_parent(node)->c_count --;
>>+ node->in_parent.node = NULL;
>>+ } else {
>>+ /* orphaned znode?! Root? */
>>
>>
>
>Drop the useless else branch.
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/debug.c 2005-06-03 17:49:38.293184063 +0400
>>@@ -0,0 +1,447 @@
>>+/* Copyright 2001, 2002, 2003 by Hans Reiser, licensing governed by
>>+ * reiser4/README */
>>+
>>+/* Debugging facilities. */
>>+
>>+/*
>>+ * This file contains generic debugging functions used by reiser4. Roughly
>>+ * following:
>>+ *
>>+ * panicking: reiser4_do_panic(), reiser4_print_prefix().
>>+ *
>>+ * locking: schedulable(), lock_counters(), print_lock_counters(),
>>+ * no_counters_are_held(), commit_check_locks()
>>+ *
>>+ * {debug,trace,log}_flags: reiser4_are_all_debugged(),
>>+ * reiser4_is_debugged(), get_current_trace_flags(),
>>+ * get_current_log_flags().
>>+ *
>>+ * kmalloc/kfree leak detection: reiser4_kmalloc(), reiser4_kfree(),
>>+ * reiser4_kfree_in_sb().
>>
>>
>
>Please don't do this! We've had enough trouble trying to get the
>current subsystem specific allocators out, so do not introduce a new one. If
>you need memory leak detection, make it generic and submit that. Reiser4, like
>all other subsystems, should use kmalloc() and friends directly.
>
>
I will let vs comment.
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/debug.h 2005-06-03 17:49:38.297184283 +0400
>>+
>>+/*
>>+ * Error code tracing facility. (Idea is borrowed from XFS code.)
>>
>>
>
>Could this be turned into a generic facility?
>
>
Probably it already is one. Getting it used as such sounds like a lot
of political work though. Maybe the first person outside the reiser4
project to want to use it should move the code into a different location.
>
>
>>+ *
>>+ * Suppose some strange and/or unexpected code is returned from some function
>>+ * (for example, write(2) returns -EEXIST). It is possible to place a
>>+ * breakpoint in the reiser4_write(), but it is too late here. How to find out
>>
>>
>--
>
>
>>+#define RETERR(code) \
>>+({ \
>>+ typeof(code) __code; \
>>+ \
>>+ __code = (code); \
>>+ return_err(__code, __FILE__, __LINE__); \
>>+ __code; \
>>+})
>>
>>
>
>
>
>>+#define reiser4_internal
>>
>>
>
>Please drop the above useless #define.
>
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/emergency_flush.c 2005-06-03 17:51:59.000905353 +0400
>>@@ -0,0 +1,913 @@
>>+/* Copyright 2002, 2003 by Hans Reiser, licensing governed by reiser4/README */
>>+
>>+/* This file exists only until VM gets fixed to reserve pages properly, which
>>+ * might or might not be very political. */
>>
>>
>
>Please fix vm instead of working around it in fs.
>
>
actually I want to see emergency flush die very very much. As for
fixing vm, easier said than done, politically.
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/init_super.c 2005-06-03 17:51:27.959201950 +0400
>>+
>>+#define _INIT_PARAM_LIST (struct super_block * s, reiser4_context * ctx, void * data, int silent)
>>+#define _DONE_PARAM_LIST (struct super_block * s)
>>+
>>+#define _INIT_(subsys) static int _init_##subsys _INIT_PARAM_LIST
>>+#define _DONE_(subsys) static void _done_##subsys _DONE_PARAM_LIST
>>
>>
>
>Please remove this macro obfuscation.
>
>
vs, I think he is right, do you?
>
>
>>+
>>+_DONE_EMPTY(exit_context)
>>+
>>+struct reiser4_subsys {
>>+ int (*init) _INIT_PARAM_LIST;
>>+ void (*done) _DONE_PARAM_LIST;
>>+};
>>+
>>+#define _SUBSYS(subsys) {.init = &_init_##subsys, .done = &_done_##subsys}
>>+static struct reiser4_subsys subsys_array[] = {
>>+ _SUBSYS(mount_flags_check),
>>+ _SUBSYS(sinfo),
>>+ _SUBSYS(context),
>>+ _SUBSYS(parse_options),
>>+ _SUBSYS(object_ops),
>>+ _SUBSYS(read_super),
>>+ _SUBSYS(tree0),
>>+ _SUBSYS(txnmgr),
>>+ _SUBSYS(ktxnmgrd_context),
>>+ _SUBSYS(ktxnmgrd),
>>+ _SUBSYS(entd),
>>+ _SUBSYS(formatted_fake),
>>+ _SUBSYS(disk_format),
>>+ _SUBSYS(sb_counters),
>>+ _SUBSYS(d_cursor),
>>+ _SUBSYS(fs_root),
>>+ _SUBSYS(safelink),
>>+ _SUBSYS(exit_context)
>>+};
>>
>>
>
>The above is overkill and silly. parse_options and read_super, for
>example, are _not_ a subsystem inits but regular fs ops. Please consider
>dropping this altogether but at least trim it down to something sane.
>
>
vs please comment.
>
>
>>--- /dev/null 2003-09-23 21:59:22.000000000 +0400
>>+++ linux-2.6.11-vs/fs/reiser4/page_cache.c 2005-06-03 17:51:59.003905518 +0400
>>+/* one-time initialization of fake inodes handling functions. */
>>+reiser4_internal int
>>+init_fakes()
>>+{
>>+ return 0;
>>+}
>>
>>
>
>Please drop this empty function.
>
>
>
>
sure.
next prev parent reply other threads:[~2005-06-23 8:29 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050620235458.5b437274.akpm@osdl.org.suse.lists.linux.kernel>
2005-06-21 11:14 ` -mm -> 2.6.13 merge status Andi Kleen
2005-06-21 18:44 ` Hans Reiser
2005-06-21 19:56 ` Andi Kleen
2005-06-21 20:21 ` Christoph Hellwig
2005-06-22 1:38 ` Hans Reiser
2005-06-22 1:57 ` Jeff Garzik
2005-06-22 1:57 ` Andi Kleen
2005-06-22 2:55 ` Hans Reiser
2005-06-22 3:01 ` Jeff Garzik
2005-06-22 8:09 ` Hans Reiser
2005-06-22 8:24 ` Jeff Garzik
2005-06-23 6:22 ` Pekka Enberg
2005-06-23 7:42 ` Hans Reiser [this message]
2005-06-23 8:08 ` Pekka J Enberg
2005-06-23 13:10 ` Hans Reiser
2005-06-23 16:15 ` Vladimir Saveliev
2005-06-23 16:23 ` Olivier Galibert
2005-06-23 19:56 ` Ross Biro
2005-06-23 17:17 ` Hans Reiser
2005-06-23 21:18 ` Nikita Danilov
2005-06-23 18:37 ` Jeff Mahoney
2005-06-23 18:43 ` Andrew Morton
2005-06-23 19:29 ` Jeff Mahoney
2005-06-23 19:45 ` Hans Reiser
2005-06-23 19:32 ` Jens Axboe
2005-06-25 16:46 ` Pekka Enberg
2005-06-25 19:23 ` Hans Reiser
2005-06-25 21:08 ` Theodore Ts'o
2005-06-26 1:03 ` Hans Reiser
2005-06-25 23:54 ` Hubert Chan
2005-06-26 10:03 ` Nikita Danilov
2005-06-27 7:24 ` Jens Axboe
2005-06-27 7:28 ` Andi Kleen
2005-06-27 7:49 ` Pekka J Enberg
2005-06-27 8:19 ` Jörn Engel
2005-06-27 8:20 ` Andi Kleen
2005-06-27 12:27 ` [PATCH] verbose BUG_ON reporting Pekka J Enberg
2005-06-27 12:38 ` Andi Kleen
2005-06-27 12:45 ` Pekka J Enberg
2005-06-27 12:40 ` [PATCH] " Jörn Engel
2005-06-23 19:24 ` -mm -> 2.6.13 merge status Hans Reiser
2005-06-24 1:13 ` Hubert Chan
2005-06-26 0:45 ` Christian Trefzer
2005-06-26 1:13 ` Hans Reiser
2005-06-26 2:23 ` Christian Trefzer
[not found] ` <42B831B4.9020603@pobox.com.suse.lists.linux.kernel>
[not found] ` <42B87318.80607@namesys.com.suse.lists.linux.kernel>
[not found] ` <20050621202448.GB30182@infradead.org.suse.lists.linux.kernel>
[not found] ` <42B8B9EE.7020002@namesys.com.suse.lists.linux.kernel>
[not found] ` <42B8BB5E.8090008@pobox.com.suse.lists.linux.kernel>
2005-06-22 1:26 ` reiser4 plugins Andi Kleen
2005-06-22 2:47 ` Hans Reiser
2005-06-22 3:16 ` Kyle Moffett
2005-06-22 15:29 ` Nikita Danilov
2005-06-23 13:20 -mm -> 2.6.13 merge status Ian Pratt
2005-06-23 13:37 ` Mark Williamson
[not found] <4hNoW-1yo-37@gated-at.bofh.it>
[not found] ` <4hT1h-5V0-41@gated-at.bofh.it>
[not found] ` <4hXHv-1br-41@gated-at.bofh.it>
2005-06-22 14:40 ` Bodo Eggert
-- strict thread matches above, loose matches on Subject: below --
2005-06-21 6:54 Andrew Morton
2005-06-21 12:01 ` Andrey Panin
2005-06-21 12:35 ` Alan Cox
2005-06-21 13:07 ` Arjan van de Ven
2005-06-22 10:50 ` Erik Slagter
2005-06-21 12:43 ` Carsten Otte
2005-06-21 12:58 ` Jörn Engel
2005-06-21 14:08 ` Martin Hicks
2005-06-21 19:54 ` Andrew Morton
2005-06-21 20:00 ` Martin Hicks
2005-06-21 15:26 ` Jeff Garzik
2005-06-21 15:39 ` Robert Love
2005-06-21 19:22 ` Christoph Lameter
2005-06-21 19:38 ` Robert Love
2005-06-21 19:44 ` Christoph Lameter
2005-06-21 20:02 ` Zan Lynx
2005-06-21 20:06 ` Christoph Lameter
2005-06-21 20:07 ` Robert Love
2005-06-21 20:10 ` Christoph Lameter
2005-06-21 20:15 ` Zan Lynx
2005-06-22 5:53 ` Matthias Urlichs
2005-06-21 22:54 ` Alan Cox
2005-06-21 20:52 ` Stephen Hemminger
2005-06-21 22:45 ` Jeff Garzik
2005-06-21 23:30 ` Christoph Lameter
2005-06-21 23:39 ` Jeff Garzik
2005-06-22 6:19 ` Christoph Lameter
2005-06-21 15:43 ` Matt Porter
2005-06-21 19:41 ` randy_dunlap
2005-06-21 20:05 ` Hans Reiser
2005-06-21 20:24 ` Christoph Hellwig
2005-06-21 20:22 ` Andrew Morton
2005-06-21 20:56 ` Gerrit Huizenga
2005-06-21 21:04 ` Andrew Morton
2005-06-21 21:23 ` Gerrit Huizenga
2005-06-21 21:38 ` Arjan van de Ven
2005-06-22 6:33 ` Martin J. Bligh
2005-06-21 21:28 ` Carsten Otte
2005-06-22 23:32 ` Chris Wright
2005-06-23 13:04 ` Carsten Otte
2005-06-22 16:53 ` Eric W. Biederman
2005-06-22 20:52 ` Andrew Morton
2005-06-23 2:14 ` Eric W. Biederman
2005-06-24 4:06 ` Paul Jackson
2005-06-24 4:54 ` randy_dunlap
2005-06-21 15:50 ` Lee Revell
2005-06-21 18:56 ` Nish Aravamudan
2005-06-22 18:00 ` Nish Aravamudan
2005-06-21 20:32 ` Andrew Morton
2005-06-21 20:37 ` Lee Revell
2005-06-22 5:51 ` Christoph Hellwig
2005-06-27 9:06 ` Christoph Hellwig
2005-06-27 14:25 ` Vladimir Saveliev
2005-06-27 19:26 ` Christoph Hellwig
2005-06-27 19:44 ` Joel Becker
2005-06-27 20:26 ` Christoph Hellwig
2005-06-27 19:30 ` Christoph Hellwig
2005-06-27 20:37 ` Hans Reiser
2005-06-30 18:30 ` Vitaly Fertman
2005-06-27 20:19 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42BA67C9.7060604@namesys.com \
--to=reiser@namesys.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=flx@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=penberg@gmail.com \
--cc=reiserfs-list@namesys.com \
--cc=vs@thebsh.namesys.com \
--cc=zam@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox