From: Christian Dietrich <christian.dietrich@tuhh.de>
To: linux-kernel@vger.kernel.org
Cc: "Max Krüger" <maxk@posteo.de>,
"John 'Warthog9' Hawley" <warthog9@eaglescrag.net>
Subject: Unexpected behavior: Sending signalfd over AF_UNIX
Date: Tue, 30 Aug 2022 14:57:06 +0200 [thread overview]
Message-ID: <s7b1qsx3n4t.fsf@dokucode.de> (raw)
[John is also on Cc: since I sent the mail before, but somehow vger ate
the mail and it did not arrive on the LKML]
Hi everyone!
For a small pet project of mine[1], I experimented with signalfd and
wanted to send it over UNIX domain sockets. Thereby, I encountered an
unexpected behavior:
My expectation was that task A can create a signalfd and send it to
task B, whereby B becomes able to receive the signals of task A.
However, this is not whats happening there. What is actually happening
is that I can correctly transfer the fd to the other process. But
instead of read(2)-ing the siginfos of task A in task B, I now receive
the signals of task B on this foreign file descriptor.
And by looking at the code, this is also the implemented behavior.
There, the code references `current' at various places and signalfd_ctx
does not hold a `struct task_struct*' but only a signal mask.
As already said, this behavior was unexpected for me. What would be
less surpringing would be one of the following:
A. I cannot transfer the signalfd fd at all (are there non-transferable fds?)
B. I can read the signals of task A in task B
With B, there remains the question, whether I should read those signals
directed to task A or to its task group. If route B is chosen, it would
also be great to derive a signalfd from a pidfd.
And yes, the whole idea of sending my own signalfd to another task is
kind of insane. However, for the sake of orthogonality, this would just
be beautiful and I could point my students to this and say: Look! In
Linux, file descriptors are just capabilities that can be transferred
between processes.
chris
[1] I'm currently working on a system-call Christmas calendar that has
a nice exercise for every day before Christmas.
--
Prof. Dr.-Ing. Christian Dietrich
Operating System Group (E-EXK4)
Technische Universität Hamburg
Am Schwarzenberg-Campus 3 (E), 4.092
21073 Hamburg
eMail: christian.dietrich@tuhh.de
Tel: +49 40 42878 2188
WWW: https://osg.tuhh.de/
reply other threads:[~2022-08-30 13:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=s7b1qsx3n4t.fsf@dokucode.de \
--to=christian.dietrich@tuhh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@posteo.de \
--cc=warthog9@eaglescrag.net \
/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