Description of problem: After creation of a POSIX message queue using mq_open(3), the queue is listed under /dev/mqueue - as /dev/mqueue/mymq, for instance. The command "cat /dev/mqueue/mymq" then lists some queue properties. QSIZE - the number of all bytes of data in all messages in the queue - should be zero after message queue creation, I suppose. But it is 48. Version-Release number of selected component (if applicable): kernel 3.13.6-200.fc20.x86_64 #1 SMP How reproducible: Run a C program that calls mq_open(3), then inspect the files under /dev/mqueue. Actual results: cat /dev/mqueue/mymq QSIZE:48 ... Expected results: cat /dev/mqueue/mymq QSIZE:0 ... Additional info: none
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
[root@mime mqtest-0.1]# cat /dev/mqueue/TestQueue QSIZE:48 NOTIFY:0 SIGNO:0 NOTIFY_PID:0 [root@mime mqtest-0.1]# uname -a Linux mime.narrenschiff 3.14.4-200.fc20.x86_64 #1 SMP Tue May 13 13:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux It's still 48 with kernel 3.14.4-200.fc20.x86_64.
Can you share your reproducer? I tried the following on 3.14.13-100 and newer kernels and it worked fine: #include <fcntl.h> #include <mqueue.h> #include <stdio.h> int main(void) { if (mq_open("/test", O_RDWR|O_CREAT, 0600, NULL) == -1) err(1, "mq_open"); return (0); }
Created attachment 943987 [details] a reproducer "package" Well, the reproducer attached writes a message "Hello World!" (13 Bytes) to the queue, then it reads it back completely. Tracing QSIZE yields: cat: /dev/mqueue/TestQueue: Datei oder Verzeichnis nicht gefunden [asi@mime mqtest-0.1]$ cat /dev/mqueue/TestQueue QSIZE:0 NOTIFY:0 SIGNO:0 NOTIFY_PID:0 [asi@mime mqtest-0.1]$ cat /dev/mqueue/TestQueue QSIZE:61 NOTIFY:0 SIGNO:0 NOTIFY_PID:0 [asi@mime mqtest-0.1]$ cat /dev/mqueue/TestQueue QSIZE:48 NOTIFY:0 SIGNO:0 NOTIFY_PID:0 Thus, the first value 0 is correct. (not wrong as stated in the bug report so far - I'm sorry.) The second value is 61 after the write of 13 Bytes? This may be a problem. The last value is 61 - 13 = 48.
Ok, I see. This is a result of the following commit: commit ce2d52cc1364a22fc1a161781e60ee3cbb499a6d Author: Doug Ledford <dledford> Date: Thu May 31 16:26:38 2012 -0700 ipc/mqueue: add rbtree node caching support When I wrote the first patch that added the rbtree support for message queue insertion, it sped up the case where the queue was very full drastically from the original code. It, however, slowed down the case where the queue was empty (not drastically though). This patch caches the last freed rbtree node struct so we can quickly reuse it when we get a new message. This is the common path for any queue that very frequently goes from 0 to 1 then back to 0 messages in queue. [..] This '48' comes from cached node. As such, I'm inclined to closed this bz with NOTABUG.