On 12/21/2012 03:46 PM, Stanislav Kinsbursky wrote: > 21.12.2012 00:47, Andrew Morton пишет: >> On Thu, 20 Dec 2012 08:06:32 +0400 >> Stanislav Kinsbursky<skinsbursky@xxxxxxxxxxxxx> wrote: >> >>> 19.12.2012 00:36, Andrew Morton __________: >>>> On Wed, 24 Oct 2012 19:34:51 +0400 >>>> Stanislav Kinsbursky<skinsbursky@xxxxxxxxxxxxx> wrote: >>>> >>>>> 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. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
