Messages in this thread | | | Date | Sun, 21 Jun 2020 15:54:37 +0200 | From | Dominique Martinet <> | Subject | Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand |
| |
Alexander Kapshuk wrote on Sun, Jun 21, 2020: > Export symbol __lock_task_sighand, so it is accessible from code compiled > as modules. > This fixes the following modpost error: > ERROR: modpost: "__lock_task_sighand" [net/9p/9pnet.ko] undefined!
This can't fix something that's not broken (yet)! :)
I think it'd make more sense to describe why you think we should export it, rather than describe a precise usecase e.g. justify why this would be interesting to use from modules (e.g. it would help modules like 9p take a lock on the current signal handler safely and cleanly through lock_task_sighand())
Christian, Andrew - assuming this passes reviews from someone else I'm not sure how to go forward with this; it'd be simpler for me if I could take it in the 9p tree as I need it for the patch Alexander pointed at, but I'm not normally touching any file outside of the 9p tree. Is it better to let either of you take it normally (I think it'd be you?) and wait for that to land, or can I take it in my tree for the next merge window?
If we don't want to export it for some reason, I'm the one who suggested using lock_task_sighand() so would be interested in how to go forward as well; 9p probably shouldn't mess with signals at all... That part of the code is especially bad as it makes the task unkillable in a weird way.
Actually I do have a patch that makes flush asynchronous and removes the need for this altogether, maybe it's time I finish that patch serie instead :P
Thanks, -- Dominique
| |