On Tue, May 18, 2010 at 12:00:01AM -0700, Eric W. Biederman wrote:
> Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> writes:
>
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/sysfs/mount.c: In function 'sysfs_exit_ns':
> > fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function)
> >
> > Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs:
> > Implement sysfs tagged directory support") from the driver-core tree
> > interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get
> > rid of S_BIAS") from the vfs tree.
> >
> > I don't know how to fix this, so I just commented the code out for now
> > (see below). Please someone supply a correct fix.
> >
> > [Al, I notice that the "get rid of S_BIAS" patch has an author date of
> > March 22 - it would have been nice if it had been in linux-next during
> > the last two months so that we could have had a fix for this some time
> > ago.]
>
> Stephen what is the easiest way to get a copy of Al's tree so I can take
> a look to see what needs to happen?
What needs to happen is the end of s_instances abuse in there. If you
do something to all your sysfs_super_info instances, put those into a
list of its own. What seems to be done there is blind "slap NULL at
that member in all those structures, no matter what might be going on".
Since the only thing you apparently care about is that sb->s_fs_info won't
disappear under you...
I really wonder what you intend to happen with readdir/sysfs_exit_ns races,
but that's a separate question. Note that there you drop all locks many
times (and don't get me started on the amount of contention in sysfs), you
have no protection against old info->ns[...] contents getting stale, AFAICS.
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
