Re: [RFC PATCH v8 0/5] IPC: checkpoint/restore in userspace enhancements

On Wed, Jan 9, 2013 at 3:24 AM, Stanislav Kinsbursky
[off-list ref] wrote:

22.12.2012 19:43, Sasha Levin пишет:

quoted

On 12/21/2012 04:57 PM, Sasha Levin wrote:

quoted

On 12/21/2012 03:46 PM, Stanislav Kinsbursky wrote:

quoted

21.12.2012 00:47, Andrew Morton пишет:

quoted

On Thu, 20 Dec 2012 08:06:32 +0400
Stanislav Kinsbursky[off-list ref]  wrote:

quoted

19.12.2012 00:36, Andrew Morton __________:

quoted

On Wed, 24 Oct 2012 19:34:51 +0400
Stanislav Kinsbursky[off-list ref]  wrote:

quoted

This respin of the patch set was significantly reworked. Most part
of new API
was replaced by sysctls (by one per messages, semaphores and shared
memory),
allowing to preset desired id for next new IPC object.

This patch set is aimed to provide additional functionality for all
IPC
objects, which is required for migration of these objects by
user-space
checkpoint/restore utils (CRIU).

The main problem here was impossibility to set up object id. This
patch set
solves the problem by adding new sysctls for preset of desired id
for new IPC
object.

Another problem was to peek messages from queues without deleting
them.
This was achived by introducing of new MSG_COPY flag for
sys_msgrcv(). If
MSG_COPY flag is set, then msgtyp is interpreted as message number.

According to my extensive records, Sasha hit a bug in
ipc-message-queue-copy-feature-introduced.patch and Fengguang found a
bug in

ipc-message-queue-copy-feature-introduced-cleanup-do_msgrcv-aroung-msg_copy-feature.patch

It's not obvious (to me) that these things have been identified and
fixed.  What's the status, please?

Hello, Andrew.
Fengguang's issue was solved by "ipc: simplify message copying" I sent
you.
But I can't find Sasha's issue. As I remember, there was some problem
in
early
version of the patch set. But I believe its fixed now.

http://lkml.indiana.edu/hypermail/linux/kernel/1210.3/01710.html

Subject: "ipc, msgqueue: NULL ptr deref in msgrcv"

Ah, yes. Thanks.
Hi found it in initial version of code, which was significantly changed
(or cleaned and simplified) by further patch series.
And I cant find out, how this can happen, because this patch he bisect
to do not modify the queue itself, while he found the
problem in testmsg.

I actually can't reproduce it on the latest -next.

I was reverting the IPC changes in the past couple of weeks so that I
could test the
rest of the IPC code with the fuzzer, and when I added them back in again
I can't
reproduce the issue I've reported earlier.

We can probably figure out where it got fixed by bisecting between -next
trees if anyone
is interested in that.

Ignore that. It just took more fuzzing to stumble on it again:

Hello, Sasha!
Thanks!
But I still can't understand, how this can happen... And I can't reproduce.
Could you specify your load? I.e. how do you stumble on this panic?
Looks like you don't use new "copy" feature.

I just fuzz with trinity
(http://git.codemonkey.org.uk/?p=trinity.git;a=tree) inside a pretty
basic KVM guest.


Thanks,
Sasha