Andrew Hi
I'm picking on you because I don't have any one else to pick on.
The 3 first patches here, are just good for today. Please see if
you would like to take them? or tell me who should take them?
The 4th patch is an RFC, which got me looking into this.
My motivation is that I added yet another Kernel dependency on the
call_usermodehelper() function and am not completely happy with the
error case of having the user-mode program stuck forever. In such
case I would like the Kernel part to timeout and properly error recover
and clean up. So therefor the proposed 4th patch.
It is still in RFC because it is only lightly tested. I have booted
with this patch and tested my use of it, with the new timeout. I have
also dprinted the new reference counting introduced, and it does not
look like we have any reference leaks.
Though I have not seen in dmesgs one of the three possible cases.
If the General Idea is acceptable and there is a chance this gets
accepted, I will conduct heavy unit testing of all the cases and
will resubmit the 4th patch.
So please review and tell me what you guys think.
[I have CCed all these that scripts/get_maintainers.pl suggested
so sorry for the noise for some]
The list of patches:
[PATCH 1/4] kmod: Unexport call_usermodehelper_freeinfo()
[PATCH 2/4] kmod: kmod: Convert two call sites to call_usermodehelper_fns()
[PATCH 3/4] kmod: kmod: Move call_usermodehelper_fns() to .c file and unexport it's helpers
These 3 are good cleanups, regardless of any new fixtures
[RFC 4/4] {RFC} kmod.c: Add new call_usermodehelper_timeout() API
This patch is my motivation. Please review and comment on the
new API, as well as the implementation details.
---
fs/exec.c | 2 +-
include/linux/kmod.h | 47 +++++++++-----------------------
kernel/kmod.c | 62 +++++++++++++++++++++++++++++++++++-------
kernel/sys.c | 11 +------
security/keys/request_key.c | 13 ++-------
5 files changed, 71 insertions(+), 64 deletions(-)
---
Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
