> I took a look at the code generation, and honestly, I think we're > better off just making __fget_files_rcu() have special logic for this > all, and not use __get_file_rcu(). My initial massaging of the patch did that btw. Then I sat there wondering whether it would matter if we just made it possible to reuse that code and I went through a bunch of iterations. Oh well, it seems to matter. > Comments? I also looked at that odd OPTIMIZER_HIDE_VAR() that Concept looks sane to me. > __get_file_rcu() does, and I don't get it. Both things come from > volatile accesses, I don't see the point of those games, but I also > didn't care, since it's no longer in a critical code path. > > Christian? Puts his completely imagined "I understand RCU head on". SLAB_TYPESAFE_BY_RCU makes the RCU consume memory ordering that the compiler doesn't officialy support (afaik) a bit wonky. So the thinking was that we could have code patterns where you could free the object and reallocate it while legitimatly passing the pointer recheck. In that case there is no memory ordering between the allocation and the pointer recheck because the last (re)allocation could have been after the rcu_dereference(). To combat that all future loads were made to have a dependency on the first load using the hidevar trick. I guess that might only be theoretically possible but not in practice? But then I liked that we explicitly commented on it as a reminder.
