Bug 1078532
| Summary: | cat /dev/mqueue/mymq shows QSIZE:48 for a newly created POSIX message queue "/mymq" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Armin W. Singer <armin.singer> | ||||
| Component: | kernel | Assignee: | Mateusz Guzik <mguzik> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 20 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, mguzik | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-10-07 17:28:01 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Armin W. Singer
2014-03-19 20:34:07 UTC
*********** 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.
|