All of lore.kernel.org
 help / color / mirror / Atom feed
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.