From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: [PATCH] vfs: set s_type in alloc_super() Date: Tue, 29 Jan 2013 19:16:11 -0500 Message-ID: <1359504971-20153-1-git-send-email-jlayton@redhat.com> Cc: linux-fsdevel@vger.kernel.org, sandeen@redhat.com To: viro@ZenIV.linux.org.uk Return-path: Received: from mail-yh0-f49.google.com ([209.85.213.49]:57066 "EHLO mail-yh0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751467Ab3A3Aih (ORCPT ); Tue, 29 Jan 2013 19:38:37 -0500 Received: by mail-yh0-f49.google.com with SMTP id m1so178394yhg.8 for ; Tue, 29 Jan 2013 16:38:36 -0800 (PST) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 Signed-off-by: Jeff Layton --- 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