All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: dan@pwienterprises.com
Cc: linux-kernel@vger.kernel.org, bfennema@falcon.csc.calpoly.edu
Subject: Re: [PATCH]: initialize parts of udf inode earlier in create
Date: Mon, 07 Aug 2006 17:45:03 -0500	[thread overview]
Message-ID: <44D7C26F.1040609@sandeen.net> (raw)
In-Reply-To: <1154934860.6783.267775866@webmail.messagingengine.com>

dan@pwienterprises.com wrote:
> I ran into the same issue today, but when listing a directory with
> invalid/corrupt entries:

...

> The following patch to udf_alloc_inode() should take care of both (and
> other similar) cases, but I've only tested it with udf_lookup().
> 
> Dan
> 
> --
> 
> Signed-off-by: Dan Bastone <dan@pwienterprises.com>
> 
> --- linux-2.6.17.7/fs/udf/super.c.orig
> +++ linux-2.6.17.7/fs/udf/super.c
> @@ -116,6 +116,13 @@
>         ei = (struct udf_inode_info *)kmem_cache_alloc(udf_inode_cachep,
>         SLAB_KERNEL);
>         if (!ei)
>                 return NULL;
> +
> +       ei->i_unique = 0;
> +       ei->i_lenExtents = 0;
> +       ei->i_next_alloc_block = 0;
> +       ei->i_next_alloc_goal = 0;
> +       ei->i_strat4096 = 0;
> +
>         return &ei->vfs_inode;
>  }

That looks fine to me, but I wonder if there's a cleaner way, rather 
than sprinkling these initializations in the code.  If __udf_read_inode 
fails, then it calls mark_bad_inode; maybe the code should check for 
that before trying to discard prealloced blocks?  I don't really know 
enough about all the UDF codepaths (by far!) to know for sure what the 
best solution is, here.

I do notice that for example ext2_put_inode() checks for bad_inode 
before calling ext2_discard_prealloc.  And it looks like the udf code 
may have a little ext2 history in it :)

-Eric

(hm, just realized that my original patch in this thread isn't strictly 
necessary for the reasons I originally proposed; udf_clear_inode checks 
for MS_RDONLY before discarding the prealloc, and my first UDF patch set 
the MS_RDONLY flag on these read-only-marked filesystems... ah well)

  reply	other threads:[~2006-08-07 22:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-04 15:57 [PATCH]: initialize parts of udf inode earlier in create Eric Sandeen
2006-08-07  7:14 ` dan
2006-08-07 22:45   ` Eric Sandeen [this message]
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=44D7C26F.1040609@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=bfennema@falcon.csc.calpoly.edu \
    --cc=dan@pwienterprises.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.