On Tue, Oct 15, 2002 at 07:00:19PM -0700, David S. Miller wrote:
> + return (u32)dentry;
>
> Um, isn't this supposed to uniquely identify the dentry?
> On a platform with 64-bit pointers there's now the theoretical
> possibility of different dentries getting the same cookie ...
>
> That's true.
>
> We dealt with this (trying to use a kernel pointer as a cache held by
> userspace) in tcp_diag by making the actual object opaque. It was
> actually two u32's, and that way it worked independant of kernel
> vs. user word size.
I'm not sure that's an option :
o userspace needs to know the size of the cookie in the event buffer
o userspace would like to use the cookie as a hash value to avoid
repeated lookups
Perhaps the best solution would be to use a separate u32 ID value,
allocated linearly. I could just refuse to allocate new dcookies in
theoretical case of overflow.
The other possibility is a dcookiefs (cat
/dev/oprofile/dcookie/34343234) but that's a lot of extra
code/complexity ...
regards
john
-- "It's a cardboard universe ... and if you lean too hard against it, you fall through." - Philip K. Dick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:29 EST