Fix POSIX mqueue open issue

Quoted 1 line · On Wed, 14 Mar 2012 17:28:33 -0400 Doug Ledford <[email protected]> wrote:

This has obviously fallen through the cracks.

It sure has. Please dig out whatever is the currently favored patchset, refresh, retest and resend, with changelogging which fully covers the reasoning and decision process?

Quoted 3 lines

so that if there are any apps out there that have been coded to expect this behavior, then there is a workaround path for them until they get coded

We'll be especially interested in the implications of this part.

The various defines for minimums and maximums of the sysctl controllable mqueue values are scattered amongst different files and named inconsistently. Move them all into ipc_namespace.h and make them have consistent names. Additionally, make the number of queues per namespace also have a minimum and maximum and use the same sysctl function as the other two settable variables.

Signed-off-by Doug Ledford<[email protected]>

The various defines for minimums and maximums of the sysctl controllable mqueue values are scattered amongst different files and named inconsistently. Move them all into ipc_namespace.h and make them have consistent names. Additionally, make the number of queues per namespace also have a minimum and maximum and use the same sysctl function as the other two settable variables.

Signed-off-by Doug Ledford <[email protected]>

---
 include/linux/ipc_namespace.h |    5 +++++
 ipc/mq_sysctl.c               |   31 ++++++++-----------------------
 2 files changed, 13 insertions(+), 23 deletions(-)

include/linux/ipc_namespace.h +5 -0

index 8a297a5..1372b56 100644
@@ -91,10 +91,15 @@ static inline void shm_destroy_orphaned(struct ipc_namespace *ns) {}
 #ifdef CONFIG_POSIX_MQUEUE
 extern int mq_init_ns(struct ipc_namespace *ns);
 /* default values */
+#define MIN_QUEUESMAX  1
 #define DFLT_QUEUESMAX 256     /* max number of message queues */
+#define HARD_QUEUESMAX 1024
+#define MIN_MSGMAX     1
 #define DFLT_MSGMAX    10      /* max number of messages in each queue */
 #define HARD_MSGMAX    (32768*sizeof(void *)/4)
+#define MIN_MSGSIZEMAX  128
 #define DFLT_MSGSIZEMAX 8192   /* max message size */
+#define HARD_MSGSIZEMAX (8192*128)
 #else
 static inline int mq_init_ns(struct ipc_namespace *ns) { return 0; }
 #endif

ipc/mq_sysctl.c +8 -23

index 0c09366..e22336a 100644
@@ -13,15 +13,6 @@
 #include <linux/ipc_namespace.h>
 #include <linux/sysctl.h>
 
-/*
- * Define the ranges various user-specified maximum values can
- * be set to.
- */
-#define MIN_MSGMAX	1		/* min value for msg_max */
-#define MAX_MSGMAX	HARD_MSGMAX	/* max value for msg_max */
-#define MIN_MSGSIZEMAX	128		/* min value for msgsize_max */
-#define MAX_MSGSIZEMAX	(8192*128)	/* max value for msgsize_max */
-
 #ifdef CONFIG_PROC_SYSCTL
 static void *get_mq(ctl_table *table)
 {

@@ -31,16 +22,6 @@ static void *get_mq(ctl_table *table)
 	return which;
 }
 
-static int proc_mq_dointvec(ctl_table *table, int write,
-	void __user *buffer, size_t *lenp, loff_t *ppos)
-{
-	struct ctl_table mq_table;
-	memcpy(&mq_table, table, sizeof(mq_table));
-	mq_table.data = get_mq(table);
-
-	return proc_dointvec(&mq_table, write, buffer, lenp, ppos);
-}
-
 static int proc_mq_dointvec_minmax(ctl_table *table, int write,
 	void __user *buffer, size_t *lenp, loff_t *ppos)
 {

@@ -52,15 +33,17 @@ static int proc_mq_dointvec_minmax(ctl_table *table, int write,
 					lenp, ppos);
 }
 #else
-#define proc_mq_dointvec NULL
 #define proc_mq_dointvec_minmax NULL
 #endif
 
+static int msg_queues_limit_min = MIN_QUEUESMAX;
+static int msg_queues_limit_max = HARD_QUEUESMAX;
+
 static int msg_max_limit_min = MIN_MSGMAX;
-static int msg_max_limit_max = MAX_MSGMAX;
+static int msg_max_limit_max = HARD_MSGMAX;
 
 static int msg_maxsize_limit_min = MIN_MSGSIZEMAX;
-static int msg_maxsize_limit_max = MAX_MSGSIZEMAX;
+static int msg_maxsize_limit_max = HARD_MSGSIZEMAX;
 
 static ctl_table mq_sysctls[] = {
 	{

@@ -68,7 +51,9 @@ static ctl_table mq_sysctls[] = {
 		.data		= &init_ipc_ns.mq_queues_max,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_mq_dointvec,
+		.proc_handler	= proc_mq_dointvec_minmax,
+		.extra1		= &msg_queues_limit_min,
+		.extra2		= &msg_queues_limit_max,
 	},
 	{
 		.procname	= "msg_max",

Signature · 7 lines

1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Commit b231cca4381ee15ec99afbfb244fbc0324869927 changed how we create a queue that does not include an attr struct passed to open so that it creates the queue with whatever the maximum values are. However, if the admin has set the maximums to allow flexibility in creating a queue (aka, both a large size and large queue are allowed, but combined they create a queue too large for the RLIMIT_MSGQUEUE of the user), then attempts to create a queue without an attr struct will fail. Switch back to using acceptable defaults regardless of what the maximums are.

Note: so far, we only know of a few applications that rely on this behavior (specifically, set the maximums in /proc, then run the application which calls mq_open() without passing in an attr struct, and the application expects the newly created message queue to have the maximum sizes that were set in /proc used on the mq_open() call, and all of those applications that we know of are actually part of regression test suites that were coded to do something like this:

for size in 4096 65536 $((1024 * 1024)) $((16 * 1024 * 1024)); do

	echo $size > /proc/sys/fs/mqueue/msgsize_max
	mq_open || echo "Error opening mq with size $size"

done

These test suites that depend on any behavior like this are broken. The concept that programs should rely upon the system wide maximum in order to get their desired results instead of simply using a attr struct to specify what they want is fundamentally unfriendly programming practice for any multi-tasking OS.

Fixing this will break those few apps that we know of (and those app authors recognize the brokenness of their code and the need to fix it). However, a future patch will allow a workaround in the form of new knobs for the default msg queue creation parameters for any software out there that we don't already know about that might rely on this behavior at the moment.

Quoted 34 lines · On Tue, 17 Apr 2012 11:46:19 -0400 Doug Ledford<[email protected]> wrote:

Commit b231cca4381ee15ec99afbfb244fbc0324869927 changed how we create a queue that does not include an attr struct passed to open so that it creates the queue with whatever the maximum values are. However, if the admin has set the maximums to allow flexibility in creating a queue (aka, both a large size and large queue are allowed, but combined they create a queue too large for the RLIMIT_MSGQUEUE of the user), then attempts to create a queue without an attr struct will fail. Switch back to using acceptable defaults regardless of what the maximums are.

Note: so far, we only know of a few applications that rely on this behavior (specifically, set the maximums in /proc, then run the application which calls mq_open() without passing in an attr struct, and the application expects the newly created message queue to have the maximum sizes that were set in /proc used on the mq_open() call, and all of those applications that we know of are actually part of regression test suites that were coded to do something like this:

for size in 4096 65536 $((1024 * 1024)) $((16 * 1024 * 1024)); do

	echo $size>  /proc/sys/fs/mqueue/msgsize_max
	mq_open || echo "Error opening mq with size $size"

done

These test suites that depend on any behavior like this are broken. The concept that programs should rely upon the system wide maximum in order to get their desired results instead of simply using a attr struct to specify what they want is fundamentally unfriendly programming practice for any multi-tasking OS.

Quoted 7 lines

Fixing this will break those few apps that we know of (and those app authors recognize the brokenness of their code and the need to fix it). However, a future patch will allow a workaround in the form of new knobs for the default msg queue creation parameters for any software out there that we don't already know about that might rely on this behavior at the moment.

Here the "future patch" is "mqueue: separate mqueue default value from maximum value v2" in this series, yes?

So people who have applications which are broken by this patch will need to manually set /proc/sys/fs/mqueue/msg_default and/or /proc/sys/fs/mqueue/msgsize_default to get those apps working again?

Quoted 7 lines

Here the "future patch" is "mqueue: separate mqueue default value from maximum value v2" in this series, yes?

So people who have applications which are broken by this patch will need to manually set /proc/sys/fs/mqueue/msg_default and/or /proc/sys/fs/mqueue/msgsize_default to get those apps working again?

Yes, it works.

Quoted 10 lines · On Tue, 17 Apr 2012 18:32:25 -0400 KOSAKI Motohiro <[email protected]>…

Quoted 7 lines

Here the "future patch" is "mqueue: separate mqueue default value from maximum value v2" in this series, yes?

So people who have applications which are broken by this patch will need to manually set /proc/sys/fs/mqueue/msg_default and/or /proc/sys/fs/mqueue/msgsize_default to get those apps working again?

Yes, it works.

OK, I updated the changelog for this patch to reflect that.

I worry a bit that some people who we don't know about will hit this problem and will have to spend a lot of time working out why it broke. Is there some way in which we can make it easier for them? A little printk_once() in a suitable place?

From: KOSAKI Motohiro <[email protected]>

Mqueue limitation is slightly naieve parameter likes other ipcs because unprivileged user can consume kernel memory by using ipcs.

Thus, too aggressive raise bring us security issue. Example, current setting allow evil unprivileged user use 256GB (= 256
* 1024 * 1024*1024) and it's enough large to system will belome unresponsive. Don't do that.

Instead, every admin should adjust the knobs for their own systems.

Signed-off-by KOSAKI Motohiro <[email protected]>

Acked-by Doug Ledford <[email protected]>

Acked-by Joe Korty <[email protected]>

Cc Amerigo Wang <[email protected]>

Cc Serge E. Hallyn <[email protected]>

Cc Jiri Slaby <[email protected]>

---
 include/linux/ipc_namespace.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

include/linux/ipc_namespace.h +3 -3

index 6e1dd08..2488535 100644
@@ -118,12 +118,12 @@ extern int mq_init_ns(struct ipc_namespace *ns);
 #define DFLT_QUEUESMAX		      256
 #define HARD_QUEUESMAX		     1024
 #define MIN_MSGMAX			1
-#define DFLT_MSG		       64U
-#define DFLT_MSGMAX		     1024
+#define DFLT_MSG		       10U
+#define DFLT_MSGMAX		       10
 #define HARD_MSGMAX		    65536
 #define MIN_MSGSIZEMAX		      128
 #define DFLT_MSGSIZE		     8192U
-#define DFLT_MSGSIZEMAX	       (1024*1024)
+#define DFLT_MSGSIZEMAX		     8192
 #define HARD_MSGSIZEMAX	    (16*1024*1024)
 #else
 static inline int mq_init_ns(struct ipc_namespace *ns) { return 0; }

Signature · 7 lines

1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Quoted 10 lines · Doug Ledford

From: KOSAKI Motohiro<[email protected]>

Mqueue limitation is slightly naieve parameter likes other ipcs because unprivileged user can consume kernel memory by using ipcs.

Thus, too aggressive raise bring us security issue. Example, current setting allow evil unprivileged user use 256GB (= 256
* 1024 * 1024*1024) and it's enough large to system will belome unresponsive. Don't do that.

Quoted 1 line

Instead, every admin should adjust the knobs for their own systems.

Would you be terribly averse to having a higher limit in init_ipc_ns, and the lower values by default in all child namespaces?

Sorry it sounds from the intro like you've already had quite a bit of discussion on this...

Of course I realize the values can just be raised by distro boot scripts...

Quoted 11 lines · Doug Ledford

From: KOSAKI Motohiro <[email protected]>

Mqueue limitation is slightly naieve parameter likes other ipcs because unprivileged user can consume kernel memory by using ipcs.

Thus, too aggressive raise bring us security issue. Example, current setting allow evil unprivileged user use 256GB (= 256
* 1024 * 1024*1024) and it's enough large to system will belome unresponsive. Don't do that.

Instead, every admin should adjust the knobs for their own systems.

Would you be terribly averse to having a higher limit in init_ipc_ns, and the lower values by default in all child namespaces?

Sorry it sounds from the intro like you've already had quite a bit of discussion on this...

Of course I realize the values can just be raised by distro boot scripts...

Quoted 19 lines · Serge E. Hallyn

Quoted 11 lines · Doug Ledford

From: KOSAKI Motohiro <[email protected]>

Mqueue limitation is slightly naieve parameter likes other ipcs because unprivileged user can consume kernel memory by using ipcs.

Thus, too aggressive raise bring us security issue. Example, current setting allow evil unprivileged user use 256GB (= 256
* 1024 * 1024*1024) and it's enough large to system will belome unresponsive. Don't do that.

Instead, every admin should adjust the knobs for their own systems.

Would you be terribly averse to having a higher limit in init_ipc_ns, and the lower values by default in all child namespaces?

Sorry it sounds from the intro like you've already had quite a bit of discussion on this...

Quoted 2 lines

Of course I realize the values can just be raised by distro boot scripts...

The default maximums this patch put into place were in fact in place from 2008 until my earlier patch in this same series, so in that regard this is merely restoring an already established default maximum. It

*could* be raised, yes, but as Motohiro pointed out, this is pinned memory that any user can allocate, so the smaller the default amount the better. The sysadmin can make changes as they see fit.

From: KOSAKI Motohiro <[email protected]>

KMALLOC_MAX_SIZE is no good threshold. It is extream high and problematic. Unfortunately, some silly drivers depend on and we can't change it. but any new code don't use such extream ugly high order allocations. It bring us awful fragmentation issue and system slowdown.

Signed-off-by KOSAKI Motohiro <[email protected]>

Acked-by Doug Ledford <[email protected]>

Acked-by Joe Korty <[email protected]>

Cc Amerigo Wang <[email protected]>

Cc Serge E. Hallyn <[email protected]>

Cc Jiri Slaby <[email protected]>

---
 ipc/mqueue.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

ipc/mqueue.c +2 -2

index 3ced596..f9f0782 100644
@@ -150,7 +150,7 @@ static struct inode *mqueue_get_inode(struct super_block *sb,
 			info->attr.mq_msgsize = attr->mq_msgsize;
 		}
 		mq_msg_tblsz = info->attr.mq_maxmsg * sizeof(struct msg_msg *);
-		if (mq_msg_tblsz > KMALLOC_MAX_SIZE)
+		if (mq_msg_tblsz > PAGE_SIZE)
 			info->messages = vmalloc(mq_msg_tblsz);
 		else
 			info->messages = kmalloc(mq_msg_tblsz, GFP_KERNEL);

@@ -263,7 +263,7 @@ static void mqueue_evict_inode(struct inode *inode)
 	spin_lock(&info->lock);
 	for (i = 0; i < info->attr.mq_curmsgs; i++)
 		free_msg(info->messages[i]);
-	if (info->attr.mq_maxmsg * sizeof(struct msg_msg *) > KMALLOC_MAX_SIZE)
+	if (is_vmalloc_addr(info->messages))
 		vfree(info->messages);
 	else
 		kfree(info->messages);

Signature · 7 lines

1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

From: KOSAKI Motohiro <[email protected]>

commit b231cca438 (message queues: increase range limits) changed mqueue default value when attr parameter is specified NULL from hard coded value to fs.mqueue.{msg,msgsize}_max sysctl value.

This made large side effect. When user need to use two mqueue applications 1) using !NULL attr parameter and it require big message size and 2) using NULL attr parameter and only need small size message, app (1) require to raise fs.mqueue.msgsize_max and app (2) consume large memory size even though it doesn't need.

Doug Ledford propsed to switch back it to static hard coded value. However it also has a compatibility problem. Some applications might started depend on the default value is tunable.

The solution is to separate default value from maximum value.

Signed-off-by KOSAKI Motohiro <[email protected]>

Acked-by Doug Ledford <[email protected]>

Acked-by Joe Korty <[email protected]>

Cc Amerigo Wang <[email protected]>

Cc Serge E. Hallyn <[email protected]>

Cc Jiri Slaby <[email protected]>

v1->v2: Slightly modified because msgutil.c no longer needs mq
namespace initialization

Signed-off-by (v2): Doug Ledford <[email protected]>

---
 Documentation/sysctl/fs.txt   |    7 +++++++
 include/linux/ipc_namespace.h |    2 ++
 ipc/mq_sysctl.c               |   18 ++++++++++++++++++
 ipc/mqueue.c                  |    9 ++++++---
 4 files changed, 33 insertions(+), 3 deletions(-)

Documentation/sysctl/fs.txt +7 -0

index 88fd7f5..13d6166 100644
@@ -225,6 +225,13 @@ a queue must be less or equal then msg_max.
 maximum  message size value (it is every  message queue's attribute set during
 its creation).
 
+/proc/sys/fs/mqueue/msg_default is  a read/write  file for setting/getting the
+default number of messages in a queue value if attr parameter of mq_open(2) is
+NULL. If it exceed msg_max, the default value is initialized msg_max.
+
+/proc/sys/fs/mqueue/msgsize_default is a read/write file for setting/getting
+the default message size value if attr parameter of mq_open(2) is NULL. If it
+exceed msgsize_max, the default value is initialized msgsize_max.
 
 4. /proc/sys/fs/epoll - Configuration options for the epoll interface
 --------------------------------------------------------

include/linux/ipc_namespace.h +0 -0

index 2488535..5499c92 100644

include/linux/ipc_namespace.h +0 -0

 	/* user_ns which owns the ipc ns */
 	struct user_namespace *user_ns;

ipc/mq_sysctl.c +18 -0

index e22336a..383d638 100644
@@ -73,6 +73,24 @@ static ctl_table mq_sysctls[] = {
 		.extra1		= &msg_maxsize_limit_min,
 		.extra2		= &msg_maxsize_limit_max,
 	},
+	{
+		.procname	= "msg_default",
+		.data		= &init_ipc_ns.mq_msg_default,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_mq_dointvec_minmax,
+		.extra1		= &msg_max_limit_min,
+		.extra2		= &msg_max_limit_max,
+	},
+	{
+		.procname	= "msgsize_default",
+		.data		= &init_ipc_ns.mq_msgsize_default,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_mq_dointvec_minmax,
+		.extra1		= &msg_maxsize_limit_min,
+		.extra2		= &msg_maxsize_limit_max,
+	},
 	{}
 };
 

ipc/mqueue.c +6 -3

index f9f0782..04cc77e 100644
@@ -142,9 +142,10 @@ static struct inode *mqueue_get_inode(struct super_block *sb,
 		info->qsize = 0;
 		info->user = NULL;	/* set when all is ok */
 		memset(&info->attr, 0, sizeof(info->attr));
-		info->attr.mq_maxmsg = min(ipc_ns->mq_msg_max, DFLT_MSG);
-		info->attr.mq_msgsize =
-			min(ipc_ns->mq_msgsize_max, DFLT_MSGSIZE);
+		info->attr.mq_maxmsg = min(ipc_ns->mq_msg_max,
+					   ipc_ns->mq_msg_default);
+		info->attr.mq_msgsize = min(ipc_ns->mq_msgsize_max,
+					    ipc_ns->mq_msgsize_default);
 		if (attr) {
 			info->attr.mq_maxmsg = attr->mq_maxmsg;
 			info->attr.mq_msgsize = attr->mq_msgsize;

@@ -1254,6 +1255,8 @@ int mq_init_ns(struct ipc_namespace *ns)
 	ns->mq_queues_max    = DFLT_QUEUESMAX;
 	ns->mq_msg_max       = DFLT_MSGMAX;
 	ns->mq_msgsize_max   = DFLT_MSGSIZEMAX;
+	ns->mq_msg_default   = DFLT_MSG;
+	ns->mq_msgsize_default  = DFLT_MSGSIZE;
 
 	ns->mq_mnt = kern_mount_data(&mqueue_fs_type, ns);
 	if (IS_ERR(ns->mq_mnt)) {

Signature · 7 lines

1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/