On Tue, 26 Mar 2013 15:28:52 -0400 Dave Jones <da...@redhat.com> wrote:
> On Thu, Mar 21, 2013 at 02:10:58PM -0700, Andrew Morton wrote:
>
> > Whichever way we go, we should get a wiggle on - this has been hanging
> > around for too long. Dave, do you have time to determine whether
> > reverting 88b9e456b1649722673ff ("ipc: don't allocate a copy larger
> > than max") fixes things up?
>
> Ok, with that reverted it's been grinding away for a few hours without
> incident.
> Normally I see the oops within a minute or so.
>
OK, thanks, I queued a revert:
From: Andrew Morton <a...@linux-foundation.org>
Subject: revert "ipc: don't allocate a copy larger than max"
Revert 88b9e456b164. Dave has confirmed that this was causing oopses
during trinity testing.
Cc: Peter Hurley <pe...@hurleysoftware.com>
Cc: Stanislav Kinsbursky <skinsbur...@parallels.com>
Reported-by: Dave Jones <da...@redhat.com>
Cc: <sta...@vger.kernel.org>
Signed-off-by: Andrew Morton <a...@linux-foundation.org>
---
ipc/msg.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff -puN ipc/msg.c~revert-ipc-dont-allocate-a-copy-larger-than-max ipc/msg.c
--- a/ipc/msg.c~revert-ipc-dont-allocate-a-copy-larger-than-max
+++ a/ipc/msg.c
@@ -820,17 +820,15 @@ long do_msgrcv(int msqid, void __user *b
struct msg_msg *copy = NULL;
unsigned long copy_number = 0;
- ns = current->nsproxy->ipc_ns;
-
if (msqid < 0 || (long) bufsz < 0)
return -EINVAL;
if (msgflg & MSG_COPY) {
- copy = prepare_copy(buf, min_t(size_t, bufsz, ns->msg_ctlmax),
- msgflg, &msgtyp, ©_number);
+ copy = prepare_copy(buf, bufsz, msgflg, &msgtyp, ©_number);
if (IS_ERR(copy))
return PTR_ERR(copy);
}
mode = convert_mode(&msgtyp, msgflg);
+ ns = current->nsproxy->ipc_ns;
msq = msg_lock_check(ns, msqid);
if (IS_ERR(msq)) {
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
