[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130718190703.GB4165@ZenIV.linux.org.uk>
Date: Thu, 18 Jul 2013 20:07:04 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Nathan Rutman <nathan_rutman@...atex.com>
Cc: Peng Tao <bergwolf@...il.com>,
"Dilger, Andreas" <andreas.dilger@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [lustre mess] is mgc_fs_setup() reachable at all?
On Thu, Jul 18, 2013 at 11:40:16AM -0700, Nathan Rutman wrote:
> >> }
> >> RETURN(rc);
> >> }
> >> What is going on here? We cast something to struct super_block *?
> >> Where does it come from? The function it's in is
> Well, addressing the "what's going on" question without getting into the larger philosophy,
> keys and values are used as a generic mechanism to pass various items between Lustre clients
> and servers. In this case, a specific key should only have a value of "a superblock", and so this is
> just a sanity check to make sure the value length is sane. It should probably be more of an ASSERT,
> but we can't reasonably assert on remotely-supplied data.
What? Excuse me, but have you seriously been intending to pass struct
super_block instances around? Ones that are choke-full of pointers to
all kinds of things, not to mention a mutex, spinlock, etc.?
_THAT_ was going to be a remotely supplied data? I really hope I've
misparsed what you said above...
And that still leaves the question about the code path that could lead to
execution of mgc_fs_setup().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists