Recent 2.5 kernels have added a function that's special purposed to handle the MAY_EXEC case of permission during pathname resolution. Previously, permission(MAY_EXEC) was called on each pathname element. Part of the dcache fastwalk changes brought this new function to life. Unfortunately, simply adding the existing inode_ops->permission() hook into exec_permission_lite() can be problematic. exec_permission_lite() is called with the dcache lock held, and modules that sleep in the inode_ops->permission() hook will cause trouble. As Stephen Smalley suggested, one option is to add a new hook that is aware of the locking paradigm. Specifically, this hook would return -EAGAIN if it needed to force the kernel to release the dcache lock and retry by calling full permission(), or return 0 on success of course. This is still not perfect, because exec_permission_lite() calls capable(), which could, in theory, sleep in some modules. Another option is to change the prototype of exec_permission_lite() so that it can unlock before calling the standard permission() hook. This option has the same issue wrt. capable() as first option. Both of these options are attached as patches. Neither feels particularly clean, and I'd welcome alternatives. Thanks, -chris
This archive was generated by hypermail 2b30 : Tue May 07 2002 - 00:20:54 PDT