linux-kernel - Re: [PATCH] V1 1/2] ipc: let message queues use SIGEV_THREAD_ID with mq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 21 Sep 2014 17:40:14 +0000 (GMT)
From:	Steven Stewart-Gallus <sstewartgallus00@...angara.bc.ca>
To:	Manfred Spraul <manfred@...orfullife.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dbueso@...e.de
Subject: Re: [PATCH] V1 1/2] ipc: let message queues use SIGEV_THREAD_ID with
 mq_notify

> Could you explain what you mean with "only thread-safe way"?
> I'm a bit relunctant to extend mq_notify() without understanding 
> the reason.
> 
> What about:
> - use sigprocmask()
> - create one worker thread
> - then in a loop in that worker thread: use sigwaitinfo() or 
> signalfd() 
> to collect the signals.

Those all modify global state and are unusable by library
code. Hogging a signal for your own library is bad.

> And one point I don't like: Within timer_create():

> >  SIGEV_THREAD_ID (Linux-specific)
> >  [...]
> > The sigev_notify_thread_id field specifies a kernel thread ID,
> > that is, the value returned by clone(2) or gettid(2).
>
> Does that mean that SIGEV_THREAD_ID is guaranteed to remain
> Linux-specific, it's implicitely linked to the Linux
> clone()/gettid() threading model?
>
> > This flag is intended only for use by threading libraries.

Yes this is low-level Linux specific stuff.

Maybe GLibc could create a more abstract and portable interface on top
of SIGEV_THREAD_ID that other OS's and libraries could implement? This
is pretty much not relevant to Linux kernel code though except that
more features that use SIGEV_THREAD_ID would motivate GLibc developers
to create a wrapper over this and that maybe the Linux kernel could be
modified to make it easier to create a more abstract and portable
wrapper.

If you feel that the whole SIGEV_THREAD_ID line of functionality was a
mistake in the first place and that people should use signals less and
use functionality like epoll more that's also okay.

If you also feel that nobody would use the feature in the first place
that's okay too.

Personally, it just bugged me that SIGEV_THREAD_ID was only used by
timers and not in a few other places where it seems like an obvious
fit.

Thank you,
Steven Stewart-Gallus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/