• Marcus Gelderie's avatar
    ipc: modify message queue accounting to not take kernel data structures into account · dbbf0fec
    Marcus Gelderie authored
    commit de54b9ac upstream.
    
    A while back, the message queue implementation in the kernel was
    improved to use btrees to speed up retrieval of messages, in commit
    d6629859 ("ipc/mqueue: improve performance of send/recv").
    
    That patch introducing the improved kernel handling of message queues
    (using btrees) has, as a by-product, changed the meaning of the QSIZE
    field in the pseudo-file created for the queue.  Before, this field
    reflected the size of the user-data in the queue.  Since, it also takes
    kernel data structures into account.  For example, if 13 bytes of user
    data are in the queue, on my machine the file reports a size of 61
    bytes.
    
    There was some discussion on this topic before (for example
    https://lkml.org/lkml/2014/10/1/115).  Commenting on a th lkml, Michael
    Kerrisk gave the following background
    (https://lkml.org/lkml/2015/6/16/74):
    
        The pseudofiles in the mqueue filesystem (usually mounted at
        /dev/mqueue) expose fields with metadata describing a message
        queue. One of these fields, QSIZE, as originally implemented,
        showed the total number of bytes of user data in all messages in
        the message queue, and this feature was documented from the
        beginning in the mq_overview(7) page. In 3.5, some other (useful)
        work happened to break the user-space API in a couple of places,
        including the value exposed via QSIZE, which now includes a measure
        of kernel overhead bytes for the queue, a figure that renders QSIZE
        useless for its original purpose, since there's no way to deduce
        the number of overhead bytes consumed by the implementation.
        (The other user-space breakage was subsequently fixed.)
    
    This patch removes the accounting of kernel data structures in the
    queue.  Reporting the size of these data-structures in the QSIZE field
    was a breaking change (see Michael's comment above).  Without the QSIZE
    field reporting the total size of user-data in the queue, there is no
    way to deduce this number.
    
    It should be noted that the resource limit RLIMIT_MSGQUEUE is counted
    against the worst-case size of the queue (in both the old and the new
    implementation).  Therefore, the kernel overhead accounting in QSIZE is
    not necessary to help the user understand the limitations RLIMIT imposes
    on the processes.
    Signed-off-by: default avatarMarcus Gelderie <redmnic@gmail.com>
    Acked-by: default avatarDoug Ledford <dledford@redhat.com>
    Acked-by: default avatarMichael Kerrisk <mtk.manpages@gmail.com>
    Acked-by: default avatarDavidlohr Bueso <dbueso@suse.de>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: John Duffy <jb_duffy@btinternet.com>
    Cc: Arto Bendiken <arto@bendiken.net>
    Cc: Manfred Spraul <manfred@colorfullife.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    dbbf0fec
mqueue.c 35.1 KB