From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262118AbTKCQz5 (ORCPT ); Mon, 3 Nov 2003 11:55:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262119AbTKCQz5 (ORCPT ); Mon, 3 Nov 2003 11:55:57 -0500 Received: from fw.osdl.org ([65.172.181.6]:21145 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S262118AbTKCQzy (ORCPT ); Mon, 3 Nov 2003 11:55:54 -0500 Date: Mon, 3 Nov 2003 08:55:42 -0800 (PST) From: Linus Torvalds To: Konstantin Boldyshev cc: Kernel Mailing List , , Al Viro Subject: Re: minix fs corruption fix for 2.4 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 Nov 2003, Konstantin Boldyshev wrote: > > Enclosed is a simple patch to fix corruption of minix filesystem > when deleting character and block device nodes (special files). > From what I've found out the bug was introduced somehwere in 2.3 > and is present in all 2.4 versions, and I guess also goes into 2.6. Oops, yes. The problem is that block and character devices put not a block number but a _device_ number in the place where other files put their block allocations. Your patch is wrong, though - you shouldn't test for APPEND and IMMUTABLE here. That should be done at higher layers. I'd also prefer to do the test the other way around: test for CHRDEV and BLKDEV in inode.c the same way the other functions do. Something like the appended.. Al, can you verify? I think this crept in when you did the block lookup cleanups. I also worry whether anybody else got the bug? Linus ===== fs/minix/inode.c 1.38 vs edited ===== --- 1.38/fs/minix/inode.c Fri Sep 5 04:31:53 2003 +++ edited/fs/minix/inode.c Mon Nov 3 08:51:01 2003 @@ -547,6 +547,8 @@ */ void minix_truncate(struct inode * inode) { + if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode)) + return; if (INODE_VERSION(inode) == MINIX_V1) V1_minix_truncate(inode); else