Subject: + ipc-semc-add-a-printk_once-for-semctlgetncnt-getzcnt.patch added to -mm tree
To: manfred@xxxxxxxxxxxxxxxx,davidlohr@xxxxxx,joe@xxxxxxxxxxx,mtk.manpages@xxxxxxxxx
From: akpm@xxxxxxxxxxxxxxxxxxxx
Date: Tue, 27 May 2014 15:53:26 -0700
The patch titled
Subject: ipc/sem.c: add a printk_once for semctl(GETNCNT/GETZCNT)
has been added to the -mm tree. Its filename is
ipc-semc-add-a-printk_once-for-semctlgetncnt-getzcnt.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/ipc-semc-add-a-printk_once-for-semctlgetncnt-getzcnt.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/ipc-semc-add-a-printk_once-for-semctlgetncnt-getzcnt.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
Subject: ipc/sem.c: add a printk_once for semctl(GETNCNT/GETZCNT)
The actual Linux implementation for semctl(GETNCNT) and semctl(GETZCNT)
always (since 0.99.10) reported a thread as sleeping on all semaphores
that are listed in the semop() call.
The documented behavior (both in the Linux man page and in the Single Unix
Specification) is that a task should be reported on exactly one semaphore:
The semaphore that caused the thread to got to sleep.
This patch adds a pr_info_once() that is triggered if a thread hits
the relevant case.
The code triggers slightly too often, otherwise it would be necessary to
replicate the old code. As there are no known users of GETNCNT or
GETZCNT, this is done to prevent unnecessary bloat.
The task that triggered is reported with name (tsk->comm) and pid.
Signed-off-by: Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>
Acked-by: Davidlohr Bueso <davidlohr@xxxxxx>
Cc: Michael Kerrisk <mtk.manpages@xxxxxxxxx>
Cc: Joe Perches <joe@xxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
ipc/sem.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff -puN ipc/sem.c~ipc-semc-add-a-printk_once-for-semctlgetncnt-getzcnt ipc/sem.c
--- a/ipc/sem.c~ipc-semc-add-a-printk_once-for-semctlgetncnt-getzcnt
+++ a/ipc/sem.c
@@ -1000,6 +1000,17 @@ static int check_qop(struct sem_array *s
{
struct sembuf *sop = q->blocking;
+ /*
+ * Linux always (since 0.99.10) reported a task as sleeping on all
+ * semaphores. This violates SUS, therefore it was changed to the
+ * standard compliant behavior.
+ * Give the administrators a chance to notice that an application
+ * might misbehave because it relies on the Linux behavior.
+ */
+ pr_info_once("semctl(GETNCNT/GETZCNT) is since 3.16 Single Unix Specification compliant.\n"
+ "The task %s (%d) triggered the difference, watch for misbehavior.\n",
+ current->comm, task_pid_nr(current));
+
if (sop->sem_num != semnum)
return 0;
_
Patches currently in -mm which might be from manfred@xxxxxxxxxxxxxxxx are
ipc-constify-ipc_ops.patch
ipc-shmc-check-for-ulong-overflows-in-shmat.patch
ipc-shmc-check-for-overflows-of-shm_tot.patch
ipc-shmc-check-for-integer-overflow-during-shmget.patch
ipc-shmc-increase-the-defaults-for-shmall-shmmax.patch
ipcshm-document-new-limits-in-the-uapi-header.patch
ipcshm-document-new-limits-in-the-uapi-header-v2.patch
ipcshm-document-new-limits-in-the-uapi-header-v3.patch
ipcmsg-move-some-msgq-ns-code-around.patch
ipcmsg-document-volatile-r_msg.patch
ipc-semc-bugfix-for-semctlgetzcnt.patch
ipc-semc-remove-code-duplication.patch
ipc-semc-change-perform_atomic_semop-parameters.patch
ipc-semc-store-which-operation-blocks-in-perform_atomic_semop.patch
ipc-semc-make-semctlgetncntgetzcnt-standard-compliant.patch
ipc-semc-add-a-printk_once-for-semctlgetncnt-getzcnt.patch
slab-leaks3-default-y.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
