lkml.org 
[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] Set MS_ACTIVE in isofs_fill_super()
From
On Wed, Mar 30, 2005 at 12:39:07PM -0800, Andrew Morton wrote:
> Russ Weight <rweight@us.ibm.com> wrote:
> > This patch sets the MS_ACTIVE bit in isofs_fill_super() prior to calling
> > iget() or iput(). This eliminates a race condition between mount
> > (for isofs) and kswapd that results in a system panic.
>
> The patch is obviously safe enough, but seems a bit kludgy.

Ehh, I think every filesystem must have that bug, since fill_super AFAIK
is expected to initialize the root dentry (sb->s_root), or at least that
is what the function used to do before it became 'fill_super'.

When I saw this bugreport I immediately knew that Coda did the same
thing "wrong". Let's see,

ext2/ext3, iget in fill_super
reiserfs, iget5_locked in fill_super
ramfs, new_inode in fill_super

There probably isn't a reason to keep looking further at this point...

I think logically if a filesystem needs to perform any setup before it
can handle VFS request that should probably be done in the registered
get_sb function before that function then calls back into the VFS to get
the actual superblock with get_sb_dev/nodev/single(..., fill_super).

Not sure how realistic this thought is, since we don't have an
initialized superblock at this time to hang things off of.

> I wonder if it would make more sense for all the ->fill_super callers to
> set MS_ACTIVE prior to calling ->fill_super(), and clear MS_ACTIVE if
> fill_super() failed?

This sounds like a better solution, although filesystems might have to
handle some operations earlier than they currently expect.

Jan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.051 / U:11.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site