public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: linux-kernel@vger.kernel.org
Cc: bfennema@falcon.csc.calpoly.edu
Subject: [PATCH]: initialize parts of udf inode earlier in create
Date: Fri, 04 Aug 2006 10:57:20 -0500	[thread overview]
Message-ID: <44D36E60.2020006@sandeen.net> (raw)

I saw an oops down this path when trying to create a new file on a UDF 
filesystem which was internally marked as readonly, but mounted rw:

udf_create
        udf_new_inode
                new_inode
                        alloc_inode
                        	udf_alloc_inode
                udf_new_block
                        returns EIO due to readonlyness
                iput (on error)
                        udf_put_inode
                                udf_discard_prealloc
                                        udf_next_aext
                                                udf_current_aext
                                                        udf_get_fileshortad
                                                                OOPS

the udf_discard_prealloc() path was examining uninitialized fields of the 
udf inode.

udf_discard_prealloc() already has this code to short-circuit the discard 
path if no extents are preallocated:

        if (UDF_I_ALLOCTYPE(inode) == ICBTAG_FLAG_AD_IN_ICB ||
                inode->i_size == UDF_I_LENEXTENTS(inode))
        {
                return;
        }

so if we initialize UDF_I_LENEXTENTS(inode) = 0 earlier in udf_new_inode, we
won't try to free the (not) preallocated blocks, since this will match
the i_size = 0 set when the inode was initialized.

Thanks,

-Eric

Signed-off-by: Eric Sandeen <sandeen@sandeen.net>

Index: linux-2.6.17/fs/udf/ialloc.c
===================================================================
--- linux-2.6.17.orig/fs/udf/ialloc.c
+++ linux-2.6.17/fs/udf/ialloc.c
@@ -75,6 +75,12 @@ struct inode * udf_new_inode (struct ino
 	}
 	*err = -ENOSPC;
 
+	UDF_I_UNIQUE(inode) = 0;
+	UDF_I_LENEXTENTS(inode) = 0;
+	UDF_I_NEXT_ALLOC_BLOCK(inode) = 0;
+	UDF_I_NEXT_ALLOC_GOAL(inode) = 0;
+	UDF_I_STRAT4096(inode) = 0;
+
 	block = udf_new_block(dir->i_sb, NULL, UDF_I_LOCATION(dir).partitionReferenceNum,
 		start, err);
 	if (*err)
@@ -84,11 +90,6 @@ struct inode * udf_new_inode (struct ino
 	}
 
 	mutex_lock(&sbi->s_alloc_mutex);
-	UDF_I_UNIQUE(inode) = 0;
-	UDF_I_LENEXTENTS(inode) = 0;
-	UDF_I_NEXT_ALLOC_BLOCK(inode) = 0;
-	UDF_I_NEXT_ALLOC_GOAL(inode) = 0;
-	UDF_I_STRAT4096(inode) = 0;
 	if (UDF_SB_LVIDBH(sb))
 	{
 		struct logicalVolHeaderDesc *lvhd;
 


             reply	other threads:[~2006-08-04 15:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-04 15:57 Eric Sandeen [this message]
2006-08-07  7:14 ` [PATCH]: initialize parts of udf inode earlier in create dan
2006-08-07 22:45   ` Eric Sandeen
2006-08-08  6:44     ` Dan Bastone

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44D36E60.2020006@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=bfennema@falcon.csc.calpoly.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox