Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,stable@vger.kernel.org,
	manfred@colorfullife.com,david.laight.linux@gmail.com,dave@stgolabs.net,
	akpm@linux-foundation.org
Subject: [to-be-updated] ipc-msg-clamp-negative-statistics.patch removed from -mm tree
Date: Thu, 29 Oct 2026 09:43:40 -0700	[thread overview]
Message-ID: <20261029164341.521631F01816@smtp.kernel.org> (raw)


The quilt patch titled
     Subject: ipc/msg: clamp negative MSG_INFO usage counts
has been removed from the -mm tree.  Its filename was
     ipc-msg-clamp-negative-statistics.patch

This patch was dropped because an updated version will be issued

------------------------------------------------------
From: Andrew Morton <akpm@linux-foundation.org>
Subject: ipc/msg: clamp negative MSG_INFO usage counts
Date: Thu, 29 Oct 2026 01:43:24 +0000

MSG_INFO can report negative message and byte counts during ordinary queue
traffic.  For example, ipcs -q -u prints a negative header count and can
convert a negative byte count into an enormous unsigned used-space value.

percpu_counter_sum() does not take an atomic snapshot of all CPUs.  While
a third CPU sums the counters, it can read the sending CPU's local count
before an enqueue and the receiving CPU's local count after the matching
dequeue.  The sampled total is then negative, even if the queue was
initially empty and is empty again.  The sum's lock serializes folding
into the global count, but not ordinary local counter updates.  Queue
locking does not serialize these updates with the statistics reader.

Use percpu_counter_sum_positive() for both usage counters before applying
the upper clamp.  Keep the comparison in s64 so the result is not narrowed
before saturation.

This bounds the reported usage without making the statistics an atomic
snapshot.  Message delivery and queue-limit enforcement are unchanged.

This is a follow-up to David Laight's "ipc/msg: Fix saturation of percpu
counts in msgctl_info()".

Validated with a source-extraction regression harness, including a forced
three-CPU sampling trace and failing old-code controls.  No running-kernel
reproduction or kernel build was performed.

Backporting: kernels such as v6.1 and v6.6 require matching min() operand
types.  Use min_t(s64, ...) instead of min() on those kernels.  For trees
still using min_t(int, ...), also retain the s64 upper clamp; the separate
standalone variant includes both adjustments.

Fixes: 72d1e611082e ("ipc/msg: mitigate the lock contention with percpu counter")
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: David Laight <david.laight.linux@gmail.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.org>
---

 ipc/msg.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/ipc/msg.c~ipc-msg-clamp-negative-statistics
+++ a/ipc/msg.c
@@ -501,10 +501,12 @@ static int msgctl_info(struct ipc_namesp
 	max_idx = ipc_get_maxidx(&msg_ids(ns));
 	up_read(&msg_ids(ns).rwsem);
 	if (cmd == MSG_INFO) {
-		msginfo->msgmap = min(percpu_counter_sum(&ns->percpu_msg_hdrs),
-				     INT_MAX);
-		msginfo->msgtql = min(percpu_counter_sum(&ns->percpu_msg_bytes),
-				     INT_MAX);
+		msginfo->msgmap = min(
+			percpu_counter_sum_positive(&ns->percpu_msg_hdrs),
+			INT_MAX);
+		msginfo->msgtql = min(
+			percpu_counter_sum_positive(&ns->percpu_msg_bytes),
+			INT_MAX);
 	} else {
 		msginfo->msgmap = MSGMAP;
 		msginfo->msgpool = MSGPOOL;
_

Patches currently in -mm which might be from akpm@linux-foundation.org are

openrisc-export-mulsi3.patch
maintainers-add-ipc-maintainers.patch
profile-account-for-partial-proc-profile-reads.patch
profile-simplify-proc-profile-read-layout.patch
drivers-media-v4l2-core-v4l2-vp9c-reduce-inlining.patch


                 reply	other threads:[~2026-10-29 16:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261029164341.521631F01816@smtp.kernel.org \
    --to=akpm@linux-foundation.org \
    --cc=dave@stgolabs.net \
    --cc=david.laight.linux@gmail.com \
    --cc=manfred@colorfullife.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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