From: Dominique Martinet <asmadeus@codewreck.org>
To: Alexander Kapshuk <alexander.kapshuk@gmail.com>
Cc: linux-kernel@vger.kernel.org, christian.brauner@ubuntu.com,
oleg@redhat.com, ebiederm@xmission.com,
akpm@linux-foundation.org, liuzhiqiang26@huawei.com,
joel@joelfernandes.org, paulmck@linux.vnet.ibm.com,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand
Date: Sun, 21 Jun 2020 15:54:37 +0200 [thread overview]
Message-ID: <20200621135437.GA18092@nautica> (raw)
In-Reply-To: <20200621133704.77896-1-alexander.kapshuk@gmail.com>
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
next prev parent reply other threads:[~2020-06-21 13:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-21 13:37 [PATCH] kernel/signal.c: Export symbol __lock_task_sighand Alexander Kapshuk
2020-06-21 13:54 ` Dominique Martinet [this message]
2020-06-22 8:39 ` Christian Brauner
2020-06-22 8:50 ` Alexander Kapshuk
2020-06-22 6:25 ` Oleg Nesterov
2020-06-22 8:39 ` Christian Brauner
2020-06-22 10:24 ` Dominique Martinet
2020-06-22 11:31 ` Oleg Nesterov
2020-06-22 11:36 ` Christian Brauner
2020-06-22 12:03 ` Oleg Nesterov
2020-06-22 12:29 ` Christian Brauner
2020-06-22 13:01 ` Oleg Nesterov
2020-06-22 13:04 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200621135437.GA18092@nautica \
--to=asmadeus@codewreck.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.kapshuk@gmail.com \
--cc=christian.brauner@ubuntu.com \
--cc=ebiederm@xmission.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuzhiqiang26@huawei.com \
--cc=lkp@intel.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox