Re: metadata plugins (was Re: the 'official' point of view expressed by kernelnewbies.org regarding reiser4 inclusion)
Most users not only cannot patch a kernel, they don't know what a patch is. It most certainly does. obviously you can provide complete kernels, including precompiled ones. Most distros have a yum or apt or similar tool to suck down packages, it's trivial for users to add a site to that, so you could provide packages if you want and make it easy for them. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Re: [patch] lockdep: annotate vfs_rmdir for filesystems that take i_mutex in delete_inode
On Wed, 2006-07-26 at 08:32 +0200, Arjan van de Ven wrote: The VFS takes the directory i_mutex and reiserfs_delete_inode() takes the to-be-deleted file's i_mutex. That's notabug and lockdep will need to be taught about it. Actually the annotation is in vfs_rmdir() since that is where the parent is taken (this may sound odd but the I_MUTEX_* ordering rules require the parent taking to be annotated rather than the child) Ignore this; this one is wrong, more later
[patch] lockdep: annotate vfs_rmdir for filesystems that take i_mutex in delete_inode
On Tue, 2006-07-25 at 22:33 -0700, Andrew Morton wrote: On Wed, 26 Jul 2006 00:16:42 +0200 The VFS takes the directory i_mutex and reiserfs_delete_inode() takes the to-be-deleted file's i_mutex. That's notabug and lockdep will need to be taught about it. [2nd try, now with coffee] This is another 3 level locking ordering: do_rmdir takes the mutex of the parent directory vfs_rmdir takes the mutex of the victim shrink_dcache_parent ends up in the reiser delete_inode which takes the mutex of dead children of the victim the I_MUTEX ordering rules are I_MUTEX_PARENT - I_MUTEX_CHILD - normal do_rmdir already has I_MUTEX_PARENT, delete_inode does normal so vfs_rmdir needs I_MUTEX_CHILD (which is also logical) Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] Index: linux-2.6.18-rc2-git5/fs/namei.c === --- linux-2.6.18-rc2-git5.orig/fs/namei.c +++ linux-2.6.18-rc2-git5/fs/namei.c @@ -1967,7 +1967,7 @@ int vfs_rmdir(struct inode *dir, struct DQUOT_INIT(dir); - mutex_lock(dentry-d_inode-i_mutex); + mutex_lock_nested(dentry-d_inode-i_mutex, I_MUTEX_CHILD); dentry_unhash(dentry); if (d_mountpoint(dentry)) error = -EBUSY;
[patch] lockdep: annotate vfs_rmdir for filesystems that take i_mutex in delete_inode
The VFS takes the directory i_mutex and reiserfs_delete_inode() takes the to-be-deleted file's i_mutex. That's notabug and lockdep will need to be taught about it. Actually the annotation is in vfs_rmdir() since that is where the parent is taken (this may sound odd but the I_MUTEX_* ordering rules require the parent taking to be annotated rather than the child) Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] Index: linux-2.6.18-rc2-git5/fs/namei.c === --- linux-2.6.18-rc2-git5.orig/fs/namei.c +++ linux-2.6.18-rc2-git5/fs/namei.c @@ -1967,7 +1967,7 @@ int vfs_rmdir(struct inode *dir, struct DQUOT_INIT(dir); - mutex_lock(dentry-d_inode-i_mutex); + mutex_lock_nested(dentry-d_inode-i_mutex, I_MUTEX_PARENT); dentry_unhash(dentry); if (d_mountpoint(dentry)) error = -EBUSY;
Re: What's the state of Reiser4 inclusion in the mainline kernel ...
On Mon, 2006-01-09 at 09:54 +, Giovanni A. Orlando wrote: Hi folks, A stupid guy like me don't understand some strange messages. I download the latest kernel and don't see the Reiser4 code. your question was asked last week as well, and answered. You probably should read the archives of this list for that...
Re: [2.6 patch] fs/reiser4/: possible cleanups
On Fri, 2005-11-18 at 00:24 -0800, Hans Reiser wrote: Seems ok to me. Is it valuable reasons I don't know about to keep reiser4_* functions from crowding the namespaces of the rest of the kernel? Is linking faster or? gcc can and does optimize static functions more. A function being static (and not having it's address taken) means that gcc is aware of all callers of this one function (unlike non-static obviously where places outside the current .c may call it). That knowledge can and is used for optimization. (and increasingly so in newer gcc's)
Re: BUG() in radix-tree.c, 2.6.11, reiserfs ?
On Wed, 2005-05-25 at 00:48 +0200, Stephane Jourdois wrote:
Hello all,
I was burning a DVD-R at 16x speed on IDE, the .iso was on /dev/sda1,
which is a reiserfs part on a SATA disk. I was at the same time
building another .iso on /dev/sda1, with files from an lvm spawned on
/dev/sd{b,c,d}.
I suggest you try it again but without the evil nvidia driver.
