<feed xmlns='http://www.w3.org/2005/Atom'>
<title>musl/src/mq, branch master</title>
<subtitle>musl - an implementation of the standard library for Linux-based systems</subtitle>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/'/>
<entry>
<title>mq: add x32-specific implementations to work around mismatched kernel ABI</title>
<updated>2024-12-23T07:05:06+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2024-12-23T07:05:06+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=d36e5bf83b601da15b2b4ab0cc225d3fb93ef489'/>
<id>d36e5bf83b601da15b2b4ab0cc225d3fb93ef489</id>
<content type='text'>
the kernel mq_attr structure has 8 64-bit longs instead of 8 32-bit
longs.

it's not clear that this is the nicest way to implement the fix, but
the concept (translation) is right, and the details can be changed
later if desired.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the kernel mq_attr structure has 8 64-bit longs instead of 8 32-bit
longs.

it's not clear that this is the nicest way to implement the fix, but
the concept (translation) is right, and the details can be changed
later if desired.
</pre>
</div>
</content>
</entry>
<entry>
<title>mq_notify: block all (application) signals in the worker thread</title>
<updated>2023-02-12T20:05:39+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2023-02-12T00:13:10+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=0ab97350f01b42de0f9fd811ee08653169661859'/>
<id>0ab97350f01b42de0f9fd811ee08653169661859</id>
<content type='text'>
until the mq notification event arrives, it is mandatory that signals
be blocked. otherwise, a signal can be received, and its handler
executed, in a thread which does not yet exist on the abstract
machine.

after the point of the event arriving, having signals blocked is not a
conformance requirement but a QoI requirement. while the application
can unblock any signals it wants unblocked in the event handler
thread, if they did not start out blocked, it could not block them
without a race window where they are momentarily unblocked, and this
would preclude controlled delivery or other forms of acceptance
(sigwait, etc.) anywhere in the application.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
until the mq notification event arrives, it is mandatory that signals
be blocked. otherwise, a signal can be received, and its handler
executed, in a thread which does not yet exist on the abstract
machine.

after the point of the event arriving, having signals blocked is not a
conformance requirement but a QoI requirement. while the application
can unblock any signals it wants unblocked in the event handler
thread, if they did not start out blocked, it could not block them
without a race window where they are momentarily unblocked, and this
would preclude controlled delivery or other forms of acceptance
(sigwait, etc.) anywhere in the application.
</pre>
</div>
</content>
</entry>
<entry>
<title>mq_notify: join worker thread before returning in error path</title>
<updated>2023-02-12T20:05:38+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2023-02-12T00:09:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=711673ee772e20a74aaf301c2d7745c20c4f4d47'/>
<id>711673ee772e20a74aaf301c2d7745c20c4f4d47</id>
<content type='text'>
this avoids leaving behind transient resource consumption whose
cleanup is subject to scheduling behavior.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this avoids leaving behind transient resource consumption whose
cleanup is subject to scheduling behavior.
</pre>
</div>
</content>
</entry>
<entry>
<title>mq_notify: rework to fix use-after-close/double-close bugs</title>
<updated>2023-02-12T20:05:38+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2023-02-10T16:22:45+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=8c0c9c69a12acc0a82590d4fd64cf633ff1dedd2'/>
<id>8c0c9c69a12acc0a82590d4fd64cf633ff1dedd2</id>
<content type='text'>
in the error path where the mq_notify syscall fails, the initiating
thread may have closed the socket before the worker thread calls recv
on it. even in the absence of such a race, if the recv call failed,
e.g. due to seccomp policy blocking it, the worker thread could
proceed to close, producing a double-close condition.

this can all be simplified by moving the mq_notify syscall into the
new thread, so that the error case does not require pthread_cancel.
now, the initiating thread only needs to read back the error status
after waiting for the worker thread to consume its arguments.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
in the error path where the mq_notify syscall fails, the initiating
thread may have closed the socket before the worker thread calls recv
on it. even in the absence of such a race, if the recv call failed,
e.g. due to seccomp policy blocking it, the worker thread could
proceed to close, producing a double-close condition.

this can all be simplified by moving the mq_notify syscall into the
new thread, so that the error case does not require pthread_cancel.
now, the initiating thread only needs to read back the error status
after waiting for the worker thread to consume its arguments.
</pre>
</div>
</content>
</entry>
<entry>
<title>mq_notify: use semaphore instead of barrier to sync args consumption</title>
<updated>2023-02-11T18:00:37+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2023-02-10T16:17:02+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=fde6891e59c315e4a0ec7e69182e1d6314e3795e'/>
<id>fde6891e59c315e4a0ec7e69182e1d6314e3795e</id>
<content type='text'>
semaphores are a much lighter primitive, and more idiomatic with
current usage in the code base.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
semaphores are a much lighter primitive, and more idiomatic with
current usage in the code base.
</pre>
</div>
</content>
</entry>
<entry>
<title>mq_timedsend, mq_timedreceive: add time64, decouple 32-bit time_t</title>
<updated>2019-07-28T21:09:30+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2019-07-28T19:49:10+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=2ab90de7ac53317a63d999b3e26d44d66684464c'/>
<id>2ab90de7ac53317a63d999b3e26d44d66684464c</id>
<content type='text'>
time64 syscall is used only if it's the only one defined for the arch,
or if the requested absolute timeout does not fit in 32 bits. on
current 32-bit archs where time_t is a 32-bit type, this makes it
statically unreachable.

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the timeout is passed via an intermediate
copy to remove the assumption that time_t is a 32-bit type.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
time64 syscall is used only if it's the only one defined for the arch,
or if the requested absolute timeout does not fit in 32 bits. on
current 32-bit archs where time_t is a 32-bit type, this makes it
statically unreachable.

on 64-bit archs, there is no change to the code after preprocessing.
on current 32-bit archs, the timeout is passed via an intermediate
copy to remove the assumption that time_t is a 32-bit type.
</pre>
</div>
</content>
</entry>
<entry>
<title>use restrict everywhere it's required by c99 and/or posix 2008</title>
<updated>2012-09-07T02:44:55+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2012-09-07T02:44:55+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=400c5e5c8307a2ebe44ef1f203f5a15669f20347'/>
<id>400c5e5c8307a2ebe44ef1f203f5a15669f20347</id>
<content type='text'>
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.
</pre>
</div>
</content>
</entry>
<entry>
<title>fix longstanding missing static in mq_notify (namespace pollution)</title>
<updated>2012-04-29T04:20:53+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2012-04-29T04:20:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=8b7112191020f1e44386a6311e0cb62ee4cea2ef'/>
<id>8b7112191020f1e44386a6311e0cb62ee4cea2ef</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>const correctness in mq_notify</title>
<updated>2011-06-25T13:23:36+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2011-06-25T13:23:36+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=4d95a58524d277ce51a5d27d964f0628f6e23841'/>
<id>4d95a58524d277ce51a5d27d964f0628f6e23841</id>
<content type='text'>
why did gcc allow this invalid assignment to compile in the first place?
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
why did gcc allow this invalid assignment to compile in the first place?
</pre>
</div>
</content>
</entry>
<entry>
<title>mq names without leading / have impl-def behavior; allowing them is easier</title>
<updated>2011-06-07T19:07:54+00:00</updated>
<author>
<name>Rich Felker</name>
<email>dalias@aerifal.cx</email>
</author>
<published>2011-06-07T19:07:54+00:00</published>
<link rel='alternate' type='text/html' href='http://git.musl-libc.org/cgit/musl/commit/?id=e1d2a8e2394640e4b573117b7653fd0f163671fe'/>
<id>e1d2a8e2394640e4b573117b7653fd0f163671fe</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
