public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2.6.21] udf: Decrement correct link count in udf_rmdir
@ 2007-05-01 18:23 Stephen Mollett
  2007-05-01 21:00 ` Andrew Morton
  0 siblings, 1 reply; 2+ messages in thread
From: Stephen Mollett @ 2007-05-01 18:23 UTC (permalink / raw)
  To: bfennema; +Cc: linux-kernel

It appears that a minor thinko occurred in udf_rmdir and the (already-cleared) 
link count on the directory that is being removed was being decremented 
instead of the link count on its parent directory. This gives rise to lots of 
kernel messages similar to:

UDF-fs warning (device loop1): udf_rmdir: empty directory has nlink != 2 (8)

when removing directory trees. No other ill effects have been observed but I 
guess it could theoretically result in the link count overflowing on a very 
long-lived, much modified directory.

Signed-off-by: Stephen Mollett <molletts@yahoo.com>
---

Patch applies cleanly to latest git snapshot and other recent 2.6 kernels.

Please CC: me as I'm not currently subscribed to linux-kernel.

First attempt at formally submitting a kernel patch - apologies if I've cocked 
something up - please be nice :-)


--- linux-2.6.21/fs/udf/namei.c.orig	2007-05-01 18:52:02.000000000 +0100
+++ linux-2.6.21/fs/udf/namei.c	2007-05-01 18:53:00.000000000 +0100
@@ -878,7 +878,7 @@ static int udf_rmdir(struct inode * dir,
 			inode->i_nlink);
 	clear_nlink(inode);
 	inode->i_size = 0;
-	inode_dec_link_count(inode);
+	inode_dec_link_count(dir);
 	inode->i_ctime = dir->i_ctime = dir->i_mtime = current_fs_time(dir->i_sb);
 	mark_inode_dirty(dir);
 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH 2.6.21] udf: Decrement correct link count in udf_rmdir
  2007-05-01 18:23 [PATCH 2.6.21] udf: Decrement correct link count in udf_rmdir Stephen Mollett
@ 2007-05-01 21:00 ` Andrew Morton
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2007-05-01 21:00 UTC (permalink / raw)
  To: Stephen Mollett; +Cc: bfennema, linux-kernel, Jan Kara, Dave Hansen

On Tue, 1 May 2007 19:23:14 +0100
Stephen Mollett <molletts@yahoo.com> wrote:

> It appears that a minor thinko occurred in udf_rmdir and the (already-cleared) 
> link count on the directory that is being removed was being decremented 
> instead of the link count on its parent directory. This gives rise to lots of 
> kernel messages similar to:
> 
> UDF-fs warning (device loop1): udf_rmdir: empty directory has nlink != 2 (8)
> 
> when removing directory trees. No other ill effects have been observed but I 
> guess it could theoretically result in the link count overflowing on a very 
> long-lived, much modified directory.
> 
> Signed-off-by: Stephen Mollett <molletts@yahoo.com>
> ---
> 
> Patch applies cleanly to latest git snapshot and other recent 2.6 kernels.
> 
> Please CC: me as I'm not currently subscribed to linux-kernel.
> 
> First attempt at formally submitting a kernel patch - apologies if I've cocked 
> something up - please be nice :-)
> 
> 
> --- linux-2.6.21/fs/udf/namei.c.orig	2007-05-01 18:52:02.000000000 +0100
> +++ linux-2.6.21/fs/udf/namei.c	2007-05-01 18:53:00.000000000 +0100
> @@ -878,7 +878,7 @@ static int udf_rmdir(struct inode * dir,
>  			inode->i_nlink);
>  	clear_nlink(inode);
>  	inode->i_size = 0;
> -	inode_dec_link_count(inode);
> +	inode_dec_link_count(dir);
>  	inode->i_ctime = dir->i_ctime = dir->i_mtime = current_fs_time(dir->i_sb);
>  	mark_inode_dirty(dir);
>  

OK, thanks.  git-blame says

9a53c3a7 (Dave Hansen    2006-09-30 23:29:03 -0700  881)        inode_dec_link_count(inode);

This bug is also fixed in Jan's UDF fixes for 2.6.22, but it looks like I
should make your fix a separate thing, with a 2.6.21.x backport.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-05-01 21:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-05-01 18:23 [PATCH 2.6.21] udf: Decrement correct link count in udf_rmdir Stephen Mollett
2007-05-01 21:00 ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox