Re: [PATCH 05/40] staging/lustre: validate open handle cookies

[Dilger, Andreas]

On 2013/11/14 9:13 PM, "Greg Kroah-Hartman" <gregkh@xxxxxxxxxxxxxxxxxxx>
wrote:

>On Fri, Nov 15, 2013 at 12:13:07AM +0800, Peng Tao wrote:
>> From: "John L. Hammond" <john.hammond@xxxxxxxxx>
>> 
>> Add a const void *h_owner member to struct portals_handle. Add a const
>> void *owner parameter to class_handle2object() which must be matched
>> by the h_owner member of the handle in addition to the cookie.
>
>Ick ick ick.
>
>NEVER use a void pointer if you can help it, and for a "handle", never.
>This isn't other operating systems, sorry.  We know what types our
>pointers to structures are, use them, so that the compiler can catch our
>problems, and don't try to cheat by using void *.

The portals_handle is used as a generic type for objects referenced over
the network, like a file handle.  The "owner" parameter is just used as
an extra check that the cookie passed from the client is actually a
valid value for the code in which it is being used (e.g. metadata or
data object).  It isn't actually dereferenced by anything, it is just
like a magic value.

>> Adjust
>> the callers of class_handle2object() accordingly, using NULL as the
>> argument to the owner parameter, except in the case of
>> mdt_handle2mfd() where we add an explicit mdt_export_data parameter
>> which we use as the owner when searching for a MFD. When allocating a
>> new MFD, pass a pointer to the mdt_export_data into mdt_mfd_new() and
>> store it in h_owner. This allows the MDT to validate that the client
>> has not sent the wrong open handle cookie, or sent the right cookie to
>> the wrong MDT.
>
>This changelog entry doesn't even match up with the code below.  ALl
>callers of class_handle2object are passing NULL here, which makes this
>patch pretty pointless, right?

As Tao wrote, this is the patch summary that matches what was committed
in our own tree and in this case mostly describes the changes made on the
server.  Keeping the same commits and comments in both trees makes it
easier to keep the code in sync.

>And that's a _very_ generic global symbol name, please don't do that, it
>needs to be "lustre_*" at the front to even expect it to be acceptable.

There's already something else called a "lustre_handle", so what about
obdclass_handle2object(), since this is in the obdclass module?

Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division


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