Hi,
For the sake of clarity, I am starting this new thread to discuss the interface we should adopt for the check_user_ptr interface, introduced by the "New user_ptr helpers for uaccess" series [1.1]. This function is meant to check that the specifier user pointer (capability in PCuABI) allows a given range to be accessed in a given way. The range is specified quite naturally by the address of the pointer + a separate size argument. As to the nature of the access (read and/or write), as suggested [2.2] during the review of the preliminary RFC, it is currently specified in the function name itself: check_user_ptr_read(), check_user_ptr_write(), check_user_ptr_rw().
I believe this is looking pretty good, but Luca's recent explicit check patch [3] has shown that it is a little inconvenient in the cases where the nature of the access is only known at runtime, often through an integer set to either READ or WRITE. This led me to suggest [1.2] to use these constants as an argument for check_user_ptr too, only to realise later that it doesn't work, as it is not possible to use them together (READ | WRITE is meaningless).
The question now is therefore the following: should we go back to something like in the RFC [2.1], i.e. pass the access type as argument, introducing a whole new type / constants for the access type? Or should we stick to [1.1], i.e. the access type in the function name itself. At this point I would tend to favour the latter option, as there are not so many situations where the access type is only known at runtime (just 3 so far), but maybe this is short-sighted.
Opinions very welcome!
Thanks, Kevin
[1.1] https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org/... [1.2] https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org/... [2.1] https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org/... [2.2] https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org/... [3] https://op-lists.linaro.org/archives/list/linux-morello@op-lists.linaro.org/...