11.04.2013 17:24, Greg KH пишет:
On Thu, Apr 11, 2013 at 08:59:45AM +0400, Stanislav Kinsbursky wrote:
11.04.2013 00:38, Greg KH пишет:
On Tue, Apr 02, 2013 at 09:24:00AM +0400, Stanislav Kinsbursky wrote:
27.03.2013 05:51, Andrew Morton пишет:
I'm about to disappear for 1.5 weeks. Stanislav, someone, please let's
get this sorted out!
Hello, Andrew.
Thanks to Peter - he found where the bug is.
And I believe, that his series fixes it.
There is another thread, where we discussed it:
https://lkml.org/lkml/2013/3/20/546
There is also my answer to Linus in this message (same thread as above):
https://lkml.org/lkml/2013/4/1/80
with bug description and the small patch, which fixes the problem (in case you'd prefer it instead of reorganising the do_msgrcv()).
I put the patch once more here below:
ipc: set msg back to -EAGAIN if copy wasn't performed
Make sure, that msg pointer is set back to error value in case of MSG_COPY
flag is set and desired message to copy wasn't found. This garantees, that msg
is either a error pointer or a copy address.
Otherwise last message in queue will be freed without unlinking from queue
(which leads to memory corruption) plus dummy allocated copy won't be released.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx>
diff --git a/ipc/msg.c b/ipc/msg.c
index 31cd1bf..fede1d0 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -872,6 +872,7 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, long msgtyp,
goto out_unlock;
break;
}
+ msg = ERR_PTR(-EAGAIN);
} else
break;
msg_counter++;
So what happened here?
Is there anything that I should do for the 3.8-stable kernel?
thanks,
greg k-h
Yes. This patch should be applied for the 3.8-stable kernel.
I need a corresponding patch in Linus's tree to reference it to as well,
what is the git commit id of that one?
thanks,
greg k-h
Here you are: 2dc958fa2fe6987e7ab106bd97029a09a82fcd8d
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html