Re: [PATCH 00/10] ipc MSG_COPY fixes
26.02.2013 16:00, Peter Hurley пишет: On Tue, 2013-02-26 at 11:53 +0400, Stanislav Kinsbursky wrote: Looks good to me. Thanks you, Peter! Acked-by: Stanislav Kinsbursky Next time please, add maintainer to "To" list instead of "CC" list (no need to resend - I've added Andrew Morton to "To" list in this reply). Ok. Can the alloc_msg() be further simplified to allocate one block with vmalloc() and link the msg segments in-place? Any thoughts on this suggestion? Emm... You can do so, is you want. But this will be just an optimisation on a slow-path. I.e. I have nothing to object, but don't see any other reason except striving for perfection. Regards, Peter Hurley -- Best regards, Stanislav Kinsbursky -- 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/
Re: [PATCH 00/10] ipc MSG_COPY fixes
On Mon, 25 Feb 2013 21:21:37 -0500 Peter Hurley wrote: > Over the weekend testing with trinity on KVM, I hit a similar oops > (pasted below) to what others have already reported here > http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01465.html > > While trying to uncover the underlying cause of the list corruption, > I uncovered two other bugs which are addressed in > ipc: Fix potential oops when src msg > 4k w/ MSG_COPY > ipc: Don't allocate a copy larger than max > > The other cleanup was incidental to trying to uncover the oops (so far > unsuccessfully). afacit, only the above two are needed in 3.9 and 3.8.x, agree? The changelog for "ipc: Don't allocate a copy larger than max" is rather poor - it doesn't actually describe the bug's effects, so people will have trouble understanding whether they need the patch in their kernels. Can you please send along some additional description of this one? -- 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/
Re: [PATCH 00/10] ipc MSG_COPY fixes
On Mon, 25 Feb 2013 21:21:37 -0500 Peter Hurley pe...@hurleysoftware.com wrote: Over the weekend testing with trinity on KVM, I hit a similar oops (pasted below) to what others have already reported here http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01465.html While trying to uncover the underlying cause of the list corruption, I uncovered two other bugs which are addressed in ipc: Fix potential oops when src msg 4k w/ MSG_COPY ipc: Don't allocate a copy larger than max The other cleanup was incidental to trying to uncover the oops (so far unsuccessfully). afacit, only the above two are needed in 3.9 and 3.8.x, agree? The changelog for ipc: Don't allocate a copy larger than max is rather poor - it doesn't actually describe the bug's effects, so people will have trouble understanding whether they need the patch in their kernels. Can you please send along some additional description of this one? -- 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/
Re: [PATCH 00/10] ipc MSG_COPY fixes
26.02.2013 16:00, Peter Hurley пишет: On Tue, 2013-02-26 at 11:53 +0400, Stanislav Kinsbursky wrote: Looks good to me. Thanks you, Peter! Acked-by: Stanislav Kinsbursky skinsbur...@parallels.com Next time please, add maintainer to To list instead of CC list (no need to resend - I've added Andrew Morton to To list in this reply). Ok. Can the alloc_msg() be further simplified to allocate one block with vmalloc() and link the msg segments in-place? Any thoughts on this suggestion? Emm... You can do so, is you want. But this will be just an optimisation on a slow-path. I.e. I have nothing to object, but don't see any other reason except striving for perfection. Regards, Peter Hurley -- Best regards, Stanislav Kinsbursky -- 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/
Re: [PATCH 00/10] ipc MSG_COPY fixes
On Tue, 2013-02-26 at 11:53 +0400, Stanislav Kinsbursky wrote: > Looks good to me. Thanks you, Peter! > > Acked-by: Stanislav Kinsbursky > > Next time please, add maintainer to "To" list instead of "CC" list (no need > to resend - I've added Andrew Morton to "To" list in this reply). Ok. > > Can the alloc_msg() be further simplified to allocate one block with > > vmalloc() and link the msg segments in-place? Any thoughts on this suggestion? Regards, Peter Hurley -- 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/
Re: [PATCH 00/10] ipc MSG_COPY fixes
On Tue, 2013-02-26 at 11:53 +0400, Stanislav Kinsbursky wrote: Looks good to me. Thanks you, Peter! Acked-by: Stanislav Kinsbursky skinsbur...@parallels.com Next time please, add maintainer to To list instead of CC list (no need to resend - I've added Andrew Morton to To list in this reply). Ok. Can the alloc_msg() be further simplified to allocate one block with vmalloc() and link the msg segments in-place? Any thoughts on this suggestion? Regards, Peter Hurley -- 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/
Re: [PATCH 00/10] ipc MSG_COPY fixes
Looks good to me. Thanks you, Peter! Acked-by: Stanislav Kinsbursky Next time please, add maintainer to "To" list instead of "CC" list (no need to resend - I've added Andrew Morton to "To" list in this reply). 26.02.2013 06:21, Peter Hurley пишет: Over the weekend testing with trinity on KVM, I hit a similar oops (pasted below) to what others have already reported here http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01465.html While trying to uncover the underlying cause of the list corruption, I uncovered two other bugs which are addressed in ipc: Fix potential oops when src msg > 4k w/ MSG_COPY ipc: Don't allocate a copy larger than max The other cleanup was incidental to trying to uncover the oops (so far unsuccessfully). Can the alloc_msg() be further simplified to allocate one block with vmalloc() and link the msg segments in-place? [ 86.026309] BUG: unable to handle kernel paging request at 00058134 [ 86.035004] IP: [] testmsg.isra.5+0x30/0x60 [ 86.035004] PGD 5ff2d067 PUD 5ee34067 PMD 0 [ 86.035004] Oops: [#1] PREEMPT SMP [ 86.035004] Modules linked in: can_bcm bridge stp dlci af_rxrpc ... [ 86.035004] CPU 5 [ 86.035004] Pid: 1736, comm: trinity-child37 Not tainted 3.9.0-next-20130220+ldsem-xeon+lockdep #20130220+ldsem Bochs Bochs [ 86.035004] RIP: 0010:[] [] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP: 0018:88005ee2fe78 EFLAGS: 00010246 [ 86.035004] RAX: RBX: 0004 RCX: 0001 [ 86.035004] RDX: 0004 RSI: 8000 RDI: 00058134 [ 86.035004] RBP: 88005ee2fe78 R08: 000b0ff4 R09: [ 86.035004] R10: 0001 R11: R12: 8000 [ 86.035004] R13: 880061275c20 R14: 00058124 R15: 880061275b70 [ 86.035004] FS: 7f9b37442700() GS:88007d40() knlGS: [ 86.035004] CS: 0010 DS: ES: CR0: 80050033 [ 86.035004] CR2: 00058134 CR3: 5ff2c000 CR4: 07e0 [ 86.035004] DR0: DR1: DR2: [ 86.035004] DR3: DR6: 0ff0 DR7: 0400 [ 86.035004] Process trinity-child37 (pid: 1736, threadinfo 88005ee2e000, task 88005edaa440) [ 86.035004] Stack: [ 86.035004] 88005ee2ff68 81309c06 001d5b00 88005edaa440 [ 86.035004] 88005edaa440 88005edaa440 813085e0 [ 86.035004] 88005ff7e458 006fe000 [ 86.035004] Call Trace: [ 86.035004] [] do_msgrcv+0x1d6/0x6a0 [ 86.035004] [] ? load_msg+0x180/0x180 [ 86.035004] [] ? trace_hardirqs_on_caller+0x10d/0x1a0 [ 86.035004] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 86.035004] [] sys_msgrcv+0x15/0x20 [ 86.035004] [] system_call_fastpath+0x16/0x1b [ 86.035004] Code: 55 83 fa 02 48 89 e5 74 32 7e 10 83 fa 03 74 3b 83 fa 04 74 16 31 c0 5d c3 66 90 83 fa 01 b8 01 00 00 00 74 f2 31 c0 eb ee 66 90 <48> 39 37 b8 01 00 00 00 7e e2 31 c0 eb de 66 90 48 3b 37 75 d5 [ 86.035004] RIP [] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP [ 86.035004] CR2: 00058134 [ 86.183799] ---[ end trace f8a403aaa782a5b4 ]--- Peter Hurley (10): ipc: Fix potential oops when src msg > 4k w/ MSG_COPY ipc: Clamp with min() ipc: Separate msg allocation from userspace copy ipc: Tighten msg copy loops ipc: Set EFAULT as default error in load_msg() ipc: Don't allocate a copy larger than max ipc: Remove msg handling from queue scan ipc: Implement MSG_COPY as a new receive mode ipc: Simplify msg list search ipc: Refactor msg list search into separate function ipc/msg.c | 84 +--- ipc/msgutil.c | 109 +++--- 2 files changed, 90 insertions(+), 103 deletions(-) -- Best regards, Stanislav Kinsbursky -- 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/
[PATCH 00/10] ipc MSG_COPY fixes
Over the weekend testing with trinity on KVM, I hit a similar oops (pasted below) to what others have already reported here http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01465.html While trying to uncover the underlying cause of the list corruption, I uncovered two other bugs which are addressed in ipc: Fix potential oops when src msg > 4k w/ MSG_COPY ipc: Don't allocate a copy larger than max The other cleanup was incidental to trying to uncover the oops (so far unsuccessfully). Can the alloc_msg() be further simplified to allocate one block with vmalloc() and link the msg segments in-place? [ 86.026309] BUG: unable to handle kernel paging request at 00058134 [ 86.035004] IP: [] testmsg.isra.5+0x30/0x60 [ 86.035004] PGD 5ff2d067 PUD 5ee34067 PMD 0 [ 86.035004] Oops: [#1] PREEMPT SMP [ 86.035004] Modules linked in: can_bcm bridge stp dlci af_rxrpc ... [ 86.035004] CPU 5 [ 86.035004] Pid: 1736, comm: trinity-child37 Not tainted 3.9.0-next-20130220+ldsem-xeon+lockdep #20130220+ldsem Bochs Bochs [ 86.035004] RIP: 0010:[] [] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP: 0018:88005ee2fe78 EFLAGS: 00010246 [ 86.035004] RAX: RBX: 0004 RCX: 0001 [ 86.035004] RDX: 0004 RSI: 8000 RDI: 00058134 [ 86.035004] RBP: 88005ee2fe78 R08: 000b0ff4 R09: [ 86.035004] R10: 0001 R11: R12: 8000 [ 86.035004] R13: 880061275c20 R14: 00058124 R15: 880061275b70 [ 86.035004] FS: 7f9b37442700() GS:88007d40() knlGS: [ 86.035004] CS: 0010 DS: ES: CR0: 80050033 [ 86.035004] CR2: 00058134 CR3: 5ff2c000 CR4: 07e0 [ 86.035004] DR0: DR1: DR2: [ 86.035004] DR3: DR6: 0ff0 DR7: 0400 [ 86.035004] Process trinity-child37 (pid: 1736, threadinfo 88005ee2e000, task 88005edaa440) [ 86.035004] Stack: [ 86.035004] 88005ee2ff68 81309c06 001d5b00 88005edaa440 [ 86.035004] 88005edaa440 88005edaa440 813085e0 [ 86.035004] 88005ff7e458 006fe000 [ 86.035004] Call Trace: [ 86.035004] [] do_msgrcv+0x1d6/0x6a0 [ 86.035004] [] ? load_msg+0x180/0x180 [ 86.035004] [] ? trace_hardirqs_on_caller+0x10d/0x1a0 [ 86.035004] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 86.035004] [] sys_msgrcv+0x15/0x20 [ 86.035004] [] system_call_fastpath+0x16/0x1b [ 86.035004] Code: 55 83 fa 02 48 89 e5 74 32 7e 10 83 fa 03 74 3b 83 fa 04 74 16 31 c0 5d c3 66 90 83 fa 01 b8 01 00 00 00 74 f2 31 c0 eb ee 66 90 <48> 39 37 b8 01 00 00 00 7e e2 31 c0 eb de 66 90 48 3b 37 75 d5 [ 86.035004] RIP [] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP [ 86.035004] CR2: 00058134 [ 86.183799] ---[ end trace f8a403aaa782a5b4 ]--- Peter Hurley (10): ipc: Fix potential oops when src msg > 4k w/ MSG_COPY ipc: Clamp with min() ipc: Separate msg allocation from userspace copy ipc: Tighten msg copy loops ipc: Set EFAULT as default error in load_msg() ipc: Don't allocate a copy larger than max ipc: Remove msg handling from queue scan ipc: Implement MSG_COPY as a new receive mode ipc: Simplify msg list search ipc: Refactor msg list search into separate function ipc/msg.c | 84 +--- ipc/msgutil.c | 109 +++--- 2 files changed, 90 insertions(+), 103 deletions(-) -- 1.8.1.2 -- 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/
Re: [PATCH 00/10] ipc MSG_COPY fixes
Looks good to me. Thanks you, Peter! Acked-by: Stanislav Kinsbursky skinsbur...@parallels.com Next time please, add maintainer to To list instead of CC list (no need to resend - I've added Andrew Morton to To list in this reply). 26.02.2013 06:21, Peter Hurley пишет: Over the weekend testing with trinity on KVM, I hit a similar oops (pasted below) to what others have already reported here http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01465.html While trying to uncover the underlying cause of the list corruption, I uncovered two other bugs which are addressed in ipc: Fix potential oops when src msg 4k w/ MSG_COPY ipc: Don't allocate a copy larger than max The other cleanup was incidental to trying to uncover the oops (so far unsuccessfully). Can the alloc_msg() be further simplified to allocate one block with vmalloc() and link the msg segments in-place? [ 86.026309] BUG: unable to handle kernel paging request at 00058134 [ 86.035004] IP: [813087d0] testmsg.isra.5+0x30/0x60 [ 86.035004] PGD 5ff2d067 PUD 5ee34067 PMD 0 [ 86.035004] Oops: [#1] PREEMPT SMP [ 86.035004] Modules linked in: can_bcm bridge stp dlci af_rxrpc ... [ 86.035004] CPU 5 [ 86.035004] Pid: 1736, comm: trinity-child37 Not tainted 3.9.0-next-20130220+ldsem-xeon+lockdep #20130220+ldsem Bochs Bochs [ 86.035004] RIP: 0010:[813087d0] [813087d0] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP: 0018:88005ee2fe78 EFLAGS: 00010246 [ 86.035004] RAX: RBX: 0004 RCX: 0001 [ 86.035004] RDX: 0004 RSI: 8000 RDI: 00058134 [ 86.035004] RBP: 88005ee2fe78 R08: 000b0ff4 R09: [ 86.035004] R10: 0001 R11: R12: 8000 [ 86.035004] R13: 880061275c20 R14: 00058124 R15: 880061275b70 [ 86.035004] FS: 7f9b37442700() GS:88007d40() knlGS: [ 86.035004] CS: 0010 DS: ES: CR0: 80050033 [ 86.035004] CR2: 00058134 CR3: 5ff2c000 CR4: 07e0 [ 86.035004] DR0: DR1: DR2: [ 86.035004] DR3: DR6: 0ff0 DR7: 0400 [ 86.035004] Process trinity-child37 (pid: 1736, threadinfo 88005ee2e000, task 88005edaa440) [ 86.035004] Stack: [ 86.035004] 88005ee2ff68 81309c06 001d5b00 88005edaa440 [ 86.035004] 88005edaa440 88005edaa440 813085e0 [ 86.035004] 88005ff7e458 006fe000 [ 86.035004] Call Trace: [ 86.035004] [81309c06] do_msgrcv+0x1d6/0x6a0 [ 86.035004] [813085e0] ? load_msg+0x180/0x180 [ 86.035004] [810d473d] ? trace_hardirqs_on_caller+0x10d/0x1a0 [ 86.035004] [813b52fe] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 86.035004] [8130a0e5] sys_msgrcv+0x15/0x20 [ 86.035004] [817aebd9] system_call_fastpath+0x16/0x1b [ 86.035004] Code: 55 83 fa 02 48 89 e5 74 32 7e 10 83 fa 03 74 3b 83 fa 04 74 16 31 c0 5d c3 66 90 83 fa 01 b8 01 00 00 00 74 f2 31 c0 eb ee 66 90 48 39 37 b8 01 00 00 00 7e e2 31 c0 eb de 66 90 48 3b 37 75 d5 [ 86.035004] RIP [813087d0] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP 88005ee2fe78 [ 86.035004] CR2: 00058134 [ 86.183799] ---[ end trace f8a403aaa782a5b4 ]--- Peter Hurley (10): ipc: Fix potential oops when src msg 4k w/ MSG_COPY ipc: Clamp with min() ipc: Separate msg allocation from userspace copy ipc: Tighten msg copy loops ipc: Set EFAULT as default error in load_msg() ipc: Don't allocate a copy larger than max ipc: Remove msg handling from queue scan ipc: Implement MSG_COPY as a new receive mode ipc: Simplify msg list search ipc: Refactor msg list search into separate function ipc/msg.c | 84 +--- ipc/msgutil.c | 109 +++--- 2 files changed, 90 insertions(+), 103 deletions(-) -- Best regards, Stanislav Kinsbursky -- 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/
[PATCH 00/10] ipc MSG_COPY fixes
Over the weekend testing with trinity on KVM, I hit a similar oops (pasted below) to what others have already reported here http://lkml.indiana.edu/hypermail/linux/kernel/1302.2/01465.html While trying to uncover the underlying cause of the list corruption, I uncovered two other bugs which are addressed in ipc: Fix potential oops when src msg 4k w/ MSG_COPY ipc: Don't allocate a copy larger than max The other cleanup was incidental to trying to uncover the oops (so far unsuccessfully). Can the alloc_msg() be further simplified to allocate one block with vmalloc() and link the msg segments in-place? [ 86.026309] BUG: unable to handle kernel paging request at 00058134 [ 86.035004] IP: [813087d0] testmsg.isra.5+0x30/0x60 [ 86.035004] PGD 5ff2d067 PUD 5ee34067 PMD 0 [ 86.035004] Oops: [#1] PREEMPT SMP [ 86.035004] Modules linked in: can_bcm bridge stp dlci af_rxrpc ... [ 86.035004] CPU 5 [ 86.035004] Pid: 1736, comm: trinity-child37 Not tainted 3.9.0-next-20130220+ldsem-xeon+lockdep #20130220+ldsem Bochs Bochs [ 86.035004] RIP: 0010:[813087d0] [813087d0] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP: 0018:88005ee2fe78 EFLAGS: 00010246 [ 86.035004] RAX: RBX: 0004 RCX: 0001 [ 86.035004] RDX: 0004 RSI: 8000 RDI: 00058134 [ 86.035004] RBP: 88005ee2fe78 R08: 000b0ff4 R09: [ 86.035004] R10: 0001 R11: R12: 8000 [ 86.035004] R13: 880061275c20 R14: 00058124 R15: 880061275b70 [ 86.035004] FS: 7f9b37442700() GS:88007d40() knlGS: [ 86.035004] CS: 0010 DS: ES: CR0: 80050033 [ 86.035004] CR2: 00058134 CR3: 5ff2c000 CR4: 07e0 [ 86.035004] DR0: DR1: DR2: [ 86.035004] DR3: DR6: 0ff0 DR7: 0400 [ 86.035004] Process trinity-child37 (pid: 1736, threadinfo 88005ee2e000, task 88005edaa440) [ 86.035004] Stack: [ 86.035004] 88005ee2ff68 81309c06 001d5b00 88005edaa440 [ 86.035004] 88005edaa440 88005edaa440 813085e0 [ 86.035004] 88005ff7e458 006fe000 [ 86.035004] Call Trace: [ 86.035004] [81309c06] do_msgrcv+0x1d6/0x6a0 [ 86.035004] [813085e0] ? load_msg+0x180/0x180 [ 86.035004] [810d473d] ? trace_hardirqs_on_caller+0x10d/0x1a0 [ 86.035004] [813b52fe] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 86.035004] [8130a0e5] sys_msgrcv+0x15/0x20 [ 86.035004] [817aebd9] system_call_fastpath+0x16/0x1b [ 86.035004] Code: 55 83 fa 02 48 89 e5 74 32 7e 10 83 fa 03 74 3b 83 fa 04 74 16 31 c0 5d c3 66 90 83 fa 01 b8 01 00 00 00 74 f2 31 c0 eb ee 66 90 48 39 37 b8 01 00 00 00 7e e2 31 c0 eb de 66 90 48 3b 37 75 d5 [ 86.035004] RIP [813087d0] testmsg.isra.5+0x30/0x60 [ 86.035004] RSP 88005ee2fe78 [ 86.035004] CR2: 00058134 [ 86.183799] ---[ end trace f8a403aaa782a5b4 ]--- Peter Hurley (10): ipc: Fix potential oops when src msg 4k w/ MSG_COPY ipc: Clamp with min() ipc: Separate msg allocation from userspace copy ipc: Tighten msg copy loops ipc: Set EFAULT as default error in load_msg() ipc: Don't allocate a copy larger than max ipc: Remove msg handling from queue scan ipc: Implement MSG_COPY as a new receive mode ipc: Simplify msg list search ipc: Refactor msg list search into separate function ipc/msg.c | 84 +--- ipc/msgutil.c | 109 +++--- 2 files changed, 90 insertions(+), 103 deletions(-) -- 1.8.1.2 -- 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/
