All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Davidlohr Bueso <davidlohr@hp.com>,
	Manfred Spraul <manfred@colorfullife.com>
Cc: mtk.manpages@gmail.com, akpm@linux-foundation.org, aswin@hp.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] ipc,msg: loosen check for full queue
Date: Fri, 16 May 2014 14:47:20 +0200	[thread overview]
Message-ID: <537608D8.7030000@gmail.com> (raw)
In-Reply-To: <1400168793.6946.10.camel@buesod1.americas.hpqcorp.net>


Hi Davidlohr,

On 05/15/2014 05:46 PM, Davidlohr Bueso wrote:
> On Thu, 2014-05-15 at 06:20 +0200, Manfred Spraul wrote:
>> Hi Davidlohr,
>>
>> On 05/14/2014 09:50 PM, Davidlohr Bueso wrote:
>>> Do you have any preferences? I can cook up a patch if you think that
>>> this merits Linux having MSGTQL.
>> MSGTQL means a global counter - therefore zero scalability. That's why I 
>> didn't implement it when I noticed the issue with 0-byte messages.
> 
> Hmmm so I was actually thinking of calculating it on demand, but after a
> closer look, we don't track each queue in the system, which would have
> made this rather trivial.
> 
> We do however have plenty of similar counters in the kernel, and the
> natural way of dealing with the scalability issue is using percpu
> counters. But I won't argue much if we leave it as it is, it's been like
> that since almost forever and no one is complaining but me.
> 
> Andrew, could you please drop this patch from -mm, I'll send another one
> to add a comment instead.
> 
>>> Worst case scenario, we should update the msgsnd(2) manpage and document
>>> this unique Linux behavior.
>> I would document the current behavior.
> 
> Cc'ing Michael. Here is a vague attempt to update our manpage, feel free
> to update it to your taste.
> 
> Thanks,
> Davidlohr
> 
> 8<------------------------------------------------------------
> From: Davidlohr Bueso <davidlohr@hp.com>
> Subject: [PATCH] msgop.2: Document full queue criteria
> 
> Explicitly mention the two conditions we rely on when
> checking if a message queue is full when calling msgsnd(2).
> 
> Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
> ---
>  man2/msgop.2 | 22 +++++++++++++++++++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/man2/msgop.2 b/man2/msgop.2
> index 3f5bc36..b4c8c04 100644
> --- a/man2/msgop.2
> +++ b/man2/msgop.2
> @@ -105,13 +105,29 @@ by
>  If sufficient space is available in the queue,
>  .BR msgsnd ()
>  succeeds immediately.
> -(The queue capacity is defined by the
> -.I msg_qbytes
> +The queue capacity is governed by the
> +.I msg_qbytes 
>  field in the associated data structure for the message queue.
>  During queue creation this field is initialized to
>  .B MSGMNB
>  bytes, but this limit can be modified using
> -.BR msgctl (2).)
> +.BR msgctl (2).
> +A full queue is defined by two factors :
> +.IP * 2
> +The new msg size + current size of the queue is greater than the 
> +queue's maximum size (the
> +.I msg_qbytes
> +field).
> +.IP *
> +The current amount of messages in the queue + 1 (the new msg) is 
> +greater than the queue's maximum size (the
> +.I msg_qbytes
> +field). This is necessary to prevent users from using infinite 
> +amounts of locked memory (used by the kernel for headers) by 
> +sending 0-byte messages. This is equivalent to the traditional
> +MSGTQL parameter present in many Unix systems. This behavior
> +is unique to Linux.
> +.PP
>  If insufficient space is available in the queue, then the default
>  behavior of
>  .BR msgsnd ()


I applied, and reworded a little. Also: I dropped the piece about
MSGTQL, since it is not quite right. As noted elsewhere on the page
MSGTQL is a *system-wide* (not per-queue) limit on the number of
messages in all MQs. Also: I dropped the piece saying this is unique
to Linux. I believe that's true, but it implies there's a lot
more standardization around these limits than there actually is
in my observation.

Thanks for the patch!

Cheers,

Michael

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  reply	other threads:[~2014-05-16 17:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 20:27 [PATCH -next 0/5] ipc,msg: fixes and updates Davidlohr Bueso
2014-05-13 20:27 ` [PATCH 1/5] ipc,msg: use current->state helpers Davidlohr Bueso
2014-05-17 17:55   ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 2/5] ipc,msg: move some msgq ns code around Davidlohr Bueso
2014-05-17 17:57   ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 3/5] ipc,msg: always respect MSG_NOERROR Davidlohr Bueso
2014-05-18  5:53   ` Manfred Spraul
2014-05-18 18:01     ` Davidlohr Bueso
2014-05-19 18:01       ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 4/5] ipc,msg: document volatile r_msg Davidlohr Bueso
2014-05-18  6:08   ` Manfred Spraul
2014-05-13 20:27 ` [PATCH 5/5] ipc,msg: loosen check for full queue Davidlohr Bueso
2014-05-14 18:00   ` Manfred Spraul
2014-05-14 19:50     ` Davidlohr Bueso
2014-05-15  4:20       ` Manfred Spraul
2014-05-15 15:46         ` Davidlohr Bueso
2014-05-16 12:47           ` Michael Kerrisk (man-pages) [this message]
2014-05-18 18:16             ` Davidlohr Bueso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=537608D8.7030000@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aswin@hp.com \
    --cc=davidlohr@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.