linux-kernel - Re: [PATCH] Reiser4 bug fixes

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] [day] [month] [year] [list]

Message-ID: <20060819201612.GB12853@infradead.org>
Date:	Sat, 19 Aug 2006 21:16:12 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	Hans Reiser <reiser@...esys.com>
Cc:	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <Linux-Kernel@...r.Kernel.ORG>
Subject: Re: [PATCH] Reiser4 bug fixes

On Wed, Jul 19, 2006 at 01:22:23PM -0700, Hans Reiser wrote:
> Hopefully this will make reiser4 stable code again.  Or at least, a lot more stable than v3 (or other FSes) was when it went in....
> 
> 
> Signed-off-by: Hans Reiser
> 
> From: Vladimir Saveliev <vs@...esys.com>
> 
> This patch contains 4 reiser4 bug fixes:
> - missing long term lock unlock on read' error handling code path is added
> - truncate_inode_pages is now called with embedded mapping. 
>   It is needed to deal properly with block device special files.
> - copy_to_user might be called for more bytes than was prefaulted with fault_in_pages_writeable.
>   That caused undesirable major page faults.
> - readdir bug similar to the previous one:
>   call to filldir might lead to deadlock due to major page fault.
> 
> Signed-off-by: Vladimir Saveliev <vs@...esys.com>
> 
> 
> 
> diff -puN fs/reiser4/super_ops.c~reiser4-one-line-fixes fs/reiser4/super_ops.c
> --- linux-2.6.18-rc-mm2/fs/reiser4/super_ops.c~reiser4-one-line-fixes	2006-07-19 16:25:49.000000000 +0400
> +++ linux-2.6.18-rc-mm2-vs/fs/reiser4/super_ops.c	2006-07-19 16:25:49.000000000 +0400
> @@ -202,7 +202,7 @@ static void reiser4_delete_inode(struct 
>  			fplug->delete_object(inode);
>  	}
>  
> -	truncate_inode_pages(inode->i_mapping, 0);
> +	truncate_inode_pages(&inode->i_data, 0);

Where do you reset i_mapping to be different from i_data?  It is a valid
thing to do in theory (that's why we have those different fields), but in
practice most usages I've seen are bogus.

(And yes, this is not a personal attack again you, just a normal review)

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