I see no reason to wait until after the "set" operation returns to set the s_type. We do call destroy_super() in some cases with that value unset. That seems to be OK in almost all cases, but we had a fire-drill recently with some RHEL-only patches that oopsed because the s_type was unset when destroy_super() got called. Move the setting of the s_type into alloc_super() as a defensive coding measure. Cc: Eric Sandeen <sandeen@xxxxxxxxxx> Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> --- fs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/super.c b/fs/super.c index 12f1237..080d60f 100644 --- a/fs/super.c +++ b/fs/super.c @@ -218,6 +218,7 @@ static struct super_block *alloc_super(struct file_system_type *type, int flags) s->s_shrink.seeks = DEFAULT_SEEKS; s->s_shrink.shrink = prune_super; s->s_shrink.batch = 1024; + s->s_type = type; } out: return s; @@ -487,7 +488,6 @@ retry: destroy_super(s); return ERR_PTR(err); } - s->s_type = type; strlcpy(s->s_id, type->name, sizeof(s->s_id)); list_add_tail(&s->s_list, &super_blocks); hlist_add_head(&s->s_instances, &type->fs_supers); -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
