From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: [PATCH] remove read-only/immutable checks from fat_truncate Date: Wed, 18 Aug 2004 16:38:13 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040818143813.GA3395@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from verein.lst.de ([213.95.11.210]:46737 "EHLO mail.lst.de") by vger.kernel.org with ESMTP id S266427AbUHROiS (ORCPT ); Wed, 18 Aug 2004 10:38:18 -0400 To: hirofumi@mail.parknet.co.jp Content-Disposition: inline List-Id: linux-fsdevel.vger.kernel.org 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: 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.