On Wed, Aug 22, 2018 at 12:44 PM Felix Kuehling <felix.kuehling@xxxxxxx> wrote:
>
> You're right, but that's a bit fragile and convoluted. I'll fix KFD to
> handle this more robustly. See the attached (untested) patch.
Yes, this patch that makes the whole "has to use current mm" or uses
"get_task_mm()" looks good from a VM< worry standpoint.
Thanks.
> And
> obviously that opaque pointer didn't work as intended. It just gets
> promoted to an mm_struct * without a warning from the compiler. Maybe I
> should change that to a long to make abuse easier to spot.
Using a "void *" is actually just about the worst possible type for
something that should be a cookie, because it silently translates to
any pointer.
"long" is actually not much better, becuase it will silently convert
to any integer type.
A good fairly type-safe cookie type is actually this:
typedef volatile const struct no_such_struct *cookie_ptr_t;
and now something of type "cookie_ptr_t" is actually very hard to
convert to other types by mistake.
Note that the "volatile const" is not just random noise - it's so that
it won't even convert without warnings to things that take a "const
void *" as an argument (like, say, the source of 'memcpy()').
So you almost _have_ to explicitly cast it to use it.
Linus
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
