[lustre-devel] [PATCH 29/37] lustre: handles: discard h_owner in favour of h_ops

[Andreas Dilger]

On Feb 27, 2019, at 14:41, NeilBrown <neilb at suse.com> wrote:
> 
> On Wed, Feb 27 2019, Andreas Dilger wrote:
> 
>> On Feb 18, 2019, at 17:09, NeilBrown <neilb at suse.com> wrote:
>>> 
>>> lustre_handles  assigned a  64bit  unique identifier  (a 'cookie')  to
>>> objects of  various types and  stored them  in a hash  table, allowing
>>> them to be accessed by the cookie.
>>> 
>>> The is a facility for type checking by recording an 'owner' for each
>>> object, and checking the owner on lookup.  Unfortunately this is not
>>> used - owner is always zero.
>>> 
>>> Eahc object also contains an h_ops pointer which can be used to
>>> reliably identify an owner.
>>> 
>>> So discard h_owner, pass and 'ops' pointer to class_handle2object(),
>>> and only return objects for which the h_ops matches.
>>> 
>>> Signed-off-by: NeilBrown <neilb at suse.com>
>> 
>> The h_owner is not used in the client code, but it is still used in the
>> server code to ensure that only clients which have already opened a file
>> handle can use the open file handle cookie to re-open the file.  The
>> h_owner in this case is an MDS-local pointer to the client export data,
>> so just using the h_ops pointer (which is generic to the class of users,
>> not the specific user) would not provide this functionality.
> 
> Is it possible for two different clients to be using the same cookie?
> The lookup code in class_handle2object() appears to allow this, but I
> assume it doesn't happen.
> 
> If it *does*, then the 'owner' does need to be part of the lookup key,
> at least on the server.
> If it doesn't, then I think it would be better for the owner to live in
> struct mdt_file_data rather than in the handle.  In the handle it
> wastes space in the thousands of instances that don't need it.

No, since the cookie is generated by the MDS in this case, it should be
unique among all clients, and a single open file handle can't be used
by multiple clients.  The goal of class_handle2object() was to ensure
that the handle was only valid for the right caller, and some other
client couldn't accidentally or maliciously use the same cookie to get
access to an object that they weren't allowed to.

That said, it looks like the caller mdt_open_handle2mfd() could also do
this check itself, to verify that the found handle actually belongs to
the client using it.  That would need an "owner" pointer to be stored in
struct mdt_file_data to reference the export, but at least this overhead
would be contained to the one place that needs it.

While the MDS could also verify this by scanning the entire list of open
files for that client, there could potentially be thousands of files per
client that need to be checked.

Cheers, Andreas
---
Andreas Dilger
Principal Lustre Architect
Whamcloud