From mboxrd@z Thu Jan 1 00:00:00 1970 From: OGAWA Hirofumi Subject: Re: [PATCH] remove read-only/immutable checks from fat_truncate Date: Thu, 19 Aug 2004 01:06:26 +0900 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <87fz6kfn25.fsf@devron.myhome.or.jp> References: <20040818143813.GA3395@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Linus Torvalds , Andrew Morton Return-path: Received: from mail.parknet.co.jp ([210.171.160.6]:14596 "EHLO mail.parknet.co.jp") by vger.kernel.org with ESMTP id S267307AbUHRQHQ (ORCPT ); Wed, 18 Aug 2004 12:07:16 -0400 To: Christoph Hellwig In-Reply-To: <20040818143813.GA3395@lst.de> List-Id: linux-fsdevel.vger.kernel.org Christoph Hellwig writes: > Looking through Herberts bind-mount patches I saw that fat_truncate > checks for the inode beeing read-only or immutable. > > This looks wrong to me. Rationale: Yes. Looks good to me. Since vfs layer is already checking those flags at all path, I think those are unneeded. (open, truncate, unlink, and rmdir) Please appply the Christoph's patch. Thanks. -- OGAWA Hirofumi Signed-off-by: OGAWA Hirofumi There's two callers: - the truncate path via notify_change, ->setattr, vmtruncate. We already check for permissions here at the upper level - fat_delete_inode. This one looks bogus to me - even if we delete an read-only or immutable inode we want to free the space allocated by it, else you leak disk blocks. --- 1.25/fs/fat/file.c 2004-05-25 11:53:07 +02:00 +++ edited/fs/fat/file.c 2004-08-18 16:32:42 +02:00 @@ -90,12 +90,6 @@ const unsigned int cluster_size = sbi->cluster_size; int nr_clusters; - /* Why no return value? Surely the disk could fail... */ - if (IS_RDONLY (inode)) - return /* -EPERM */; - if (IS_IMMUTABLE(inode)) - return /* -EPERM */; - /* * This protects against truncating a file bigger than it was then * trying to write into the hole.