linux-kernel.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).