Bug 250842

Description of problem:

The attached code runs as root because it sends ICMP but otherwise
is a normal userspace process; its purpose is to find a 'partner'
host in the same network for some automated network testing later.

After the code has run, latest RHEL4 kernels are panicing.  We are sure we
have bugs in the code but so far unable to find any.

How reproducible:
very likely

Steps to Reproduce:
Run "make && ./pair" on two machines behind the same switch.

Actual results:
Jun 11 11:14:32 lxb7913.cern.ch login: Unable to handle kernel NULL pointer dereference at 0000000000000130 RIP: 
Jun 11 11:14:32 <ffffffff80162798>{free_block+179}
Jun 11 11:14:32 PML4 220d23067 PGD 21f847067 PMD 0 
Jun 11 11:14:32 Oops: 0002 [1] SMP 
Jun 11 11:14:32 CPU 3 
Jun 11 11:14:33 Modules linked in: edac_mc ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler autofs4 i2c_dev i2c_core md5 ipv6 ds yenta_socket pcmcia_core dm_mirror dm_mod button battery ac joydev uhci_hcd ehci_hcd e1000 ext3 jbd ata_piix libata sd_mod scsi_mod
Jun 11 11:14:33 Pid: 13, comm: events/3 Not tainted 2.6.9-55.ELsmp
Jun 11 11:14:33 RIP: 0010:[<ffffffff80162798>] <ffffffff80162798>{free_block+179}
Jun 11 11:14:33 RSP: 0018:00000100cfc5bde8  EFLAGS: 00010006
Jun 11 11:14:33 RAX: 0000000000000128 RBX: 00000100cfedd1c0 RCX: 0000010000012000
Jun 11 11:14:33 RDX: 0000000000000000 RSI: 000001022605d700 RDI: 000001021bea5000
Jun 11 11:14:33 RBP: 00000100cfe1c0d0 R08: 00000100cfe02090 R09: 0000000000000000
Jun 11 11:14:33 R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000001
Jun 11 11:14:33 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff80492740
Jun 11 11:14:33 FS:  0000000000000000(0000) GS:ffffffff804ed880(0000) knlGS:0000000000000000
Jun 11 11:14:33 CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Jun 11 11:14:34 CR2: 0000000000000130 CR3: 0000000006974000 CR4: 00000000000006e0
Jun 11 11:14:34 Process events/3 (pid: 13, threadinfo 00000100cfc5a000, task 00000100cfc31030)
Jun 11 11:14:34 Stack: 00000100cfe1c0c0 00000100cfe1c0d0 0000000000000001 00000100cfe1c0c0 
Jun 11 11:14:34        00000100cfedd1c0 ffffffff801628ae 000001000107de40 000001000107de48 
Jun 11 11:14:34        00000100cfedd2b0 ffffffff80163774 
Jun 11 11:14:34 Call Trace:<ffffffff801628ae>{drain_array_locked+99} <ffffffff80163774>{cache_reap+162} 
Jun 11 11:14:34        <ffffffff801636d2>{cache_reap+0} <ffffffff80147d1a>{worker_thread+419} 
Jun 11 11:14:34        <ffffffff801342a4>{default_wake_function+0} <ffffffff801342f5>{__wake_up_common+67} 
Jun 11 11:14:34        <ffffffff801342a4>{default_wake_function+0} <ffffffff80147b77>{worker_thread+0} 
Jun 11 11:14:34        <ffffffff8014ba3f>{kthread+200} <ffffffff80110f47>{child_rip+8} 
Jun 11 11:14:34        <ffffffff8014b977>{kthread+0} <ffffffff80110f3f>{child_rip+0} 
Jun 11 11:14:34        
Jun 11 11:14:34 
Jun 11 11:14:34 Code: 48 89 50 08 48 89 02 48 2b 7e 18 48 c7 06 00 01 10 00 48 c7 
Jun 11 11:14:34 RIP <ffffffff80162798>{free_block+179} RSP <00000100cfc5bde8>
Jun 11 11:14:34 CR2: 0000000000000130
Jun 11 11:14:34  <0>Kernel panic - not syncing: Oops
Jun 11 11:15:05  NMI Watchdog detected LOCKUP, CPU=1, registers:
Jun 11 11:15:05 CPU 1 
Jun 11 11:15:05 Modules linked in: edac_mc ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler autofs4 i2c_dev i2c_core md5 ipv6 ds yenta_socket pcmcia_core dm_mirror dm_mod button battery ac joydev uhci_hcd ehci_hcd e1000 ext3 jbd ata_piix libata sd_mod scsi_mod
Jun 11 11:15:05 Pid: 10704, comm: fsprobe Not tainted 2.6.9-55.ELsmp
Jun 11 11:15:05 RIP: 0010:[<ffffffff8030cf66>] <ffffffff8030cf66>{.text.lock.spinlock+5}
Jun 11 11:15:05 RSP: 0018:000001022143f718  EFLAGS: 00000086
Jun 11 11:15:05 RAX: 0000000000000010 RBX: 00000100cfedd268 RCX: 0000000000000001
Jun 11 11:15:05 RDX: 0000000000000000 RSI: 0000000000000850 RDI: 00000100cfedd268
Jun 11 11:15:05 RBP: 00000100cfeb90c0 R08: 0000000000003e9f R09: 0000010220791ba8
Jun 11 11:15:05 R10: 0000010227610a28 R11: 0000010227610a28 R12: 00000100cfedd208
Jun 11 11:15:05 R13: 00000100cfedd1c0 R14: 0000000000000850 R15: 000001022143f8ec
Jun 11 11:15:06 FS:  0000002a95584b00(0000) GS:ffffffff804ed780(0000) knlGS:0000000000000000
Jun 11 11:15:06 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jun 11 11:15:06 CR2: 0000002a95780b70 CR3: 0000000037e88000 CR4: 00000000000006e0
Jun 11 11:15:06 Process fsprobe (pid: 10704, threadinfo 000001022143e000, task 00000102190c57f0)
Jun 11 11:15:06 Stack: 000000000000000c ffffffff80161f75 00000100cfedd1c0 00000100cfedd1c0 
Jun 11 11:15:06        0000000000000850 000001021bb00190 0000010224f888c0 00000102269714c0 
Jun 11 11:15:06        000001022143f8ec ffffffff80161e47 
Jun 11 11:15:06 Call Trace:<ffffffff80161f75>{cache_alloc_refill+93} <ffffffff80161e47>{__kmalloc+123} 
Jun 11 11:15:06        <ffffffffa0058acc>{:jbd:__jbd_kmalloc+21} <ffffffffa0054543>{:jbd:do_get_write_access+1046} 
Jun 11 11:15:06        <ffffffff8015a97c>{find_get_page+65} <ffffffff8017b62c>{__find_get_block_slow+255} 
Jun 11 11:15:06        <ffffffffa0054780>{:jbd:journal_get_undo_access+50} 
Jun 11 11:15:06        <ffffffffa0065aba>{:ext3:ext3_try_to_allocate_with_rsv+84} 
Jun 11 11:15:06        <ffffffffa006613e>{:ext3:ext3_new_block+497} <ffffffffa00683e6>{:ext3:ext3_alloc_block+7} 
Jun 11 11:15:06        <ffffffffa0069fcb>{:ext3:ext3_get_block_handle+881} 
Jun 11 11:15:07        <ffffffff8016ae3b>{get_user_pages+1339} <ffffffffa006a564>{:ext3:ext3_direct_io_get_blocks+164} 
Jun 11 11:15:07        <ffffffff8019b4f8>{__blockdev_direct_IO+1820} <ffffffffa0069950>{:ext3:ext3_mark_iloc_dirty+803} 
Jun 11 11:15:07        <ffffffffa006b532>{:ext3:ext3_direct_IO+251} <ffffffffa006a4c0>{:ext3:ext3_direct_io_get_blocks+0} 
Jun 11 11:15:07        <ffffffff8015c2b6>{generic_file_direct_IO+78} <ffffffff8015c343>{generic_file_direct_write+103} 
Jun 11 11:15:07        <ffffffff8015c660>{__generic_file_aio_write_nolock+662} 
Jun 11 11:15:07        <ffffffff8015c943>{generic_file_aio_write_nolock+32} 
Jun 11 11:15:07        <ffffffff8015ca0d>{generic_file_aio_write+126} <ffffffffa0066f01>{:ext3:ext3_file_write+22} 
Jun 11 11:15:07        <ffffffff80179da3>{do_sync_write+178} <ffffffff8030bcf5>{thread_return+88} 
Jun 11 11:15:07        <ffffffff80135c64>{autoremove_wake_function+0} <ffffffff80179e9e>{vfs_write+207} 
Jun 11 11:15:07        <ffffffff80179f86>{sys_write+69} <ffffffff8011026a>{system_call+126} 
Jun 11 11:15:07        
Jun 11 11:15:07 
Jun 11 11:15:08 Code: 7e f9 e9 60 fc ff ff f3 90 83 3b 00 7e f9 e9 ce fc ff ff e8 
Jun 11 11:15:08 Kernel panic - not syncing: nmi watchdog
Jun 11 11:15:08  <1>Unable to handle kernel NULL pointer dereference at 00000000000000ff RIP: 
Jun 11 11:15:08 [<00000000000000ff>]
Jun 11 11:15:08 PML4 220d23067 PGD 21f847067 PMD 0 
Jun 11 11:15:08 Oops: 0000 [2] SMP 
Jun 11 11:15:08 CPU 1 
Jun 11 11:15:08 Modules linked in: edac_mc ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler autofs4 i2c_dev i2c_core md5 ipv6 ds yenta_socket pcmcia_core dm_mirror dm_mod button battery ac joydev uhci_hcd ehci_hcd e1000 ext3 jbd ata_piix libata sd_mod scsi_mod
Jun 11 11:15:08 Pid: 10704, comm: fsprobe Not tainted 2.6.9-55.ELsmp
Jun 11 11:15:08 RIP: 0010:[<00000000000000ff>] [<00000000000000ff>]
Jun 11 11:15:08 RSP: 0018:0000010037e9bfa0  EFLAGS: 00010006
Jun 11 11:15:08 RAX: 000001022143ffd8 RBX: 0000000000000000 RCX: 0000000000000002
Jun 11 11:15:08 RDX: 00000000000000ff RSI: 0000000000000000 RDI: 0000000000000002
Jun 11 11:15:08 RBP: 0000010037e8bcf8 R08: 0000000000000008 R09: 0000000000000000
Jun 11 11:15:08 R10: 0000000000000000 R11: 0000000000000002 R12: 00000100cfedd208
Jun 11 11:15:09 R13: 00000100cfedd1c0 R14: 0000000000000850 R15: 000001022143f8ec
Jun 11 11:15:09 FS:  0000002a95584b00(0000) GS:ffffffff804ed780(0000) knlGS:0000000000000000
Jun 11 11:15:09 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Jun 11 11:15:09 CR2: 00000000000000ff CR3: 0000000037e88000 CR4: 00000000000006e0
Jun 11 11:15:09 Process fsprobe (pid: 10704, threadinfo 000001022143e000, task 00000102190c57f0)
Jun 11 11:15:09 Stack: ffffffff8011c6b2 ffffffff8031fbd4 ffffffff80110b69 0000010037e8bcf8  <EOI> 
Jun 11 11:15:09        000001022143f8ec 0000000000000850 00000100cfedd1c0 00000100cfedd208 
Jun 11 11:15:09        0000010037e8bf58 ffffffff8031fbd4 
Jun 11 11:15:09 Call Trace:<IRQ> <ffffffff8011c6b2>{smp_call_function_interrupt+64} 
Jun 11 11:15:09        <ffffffff80110b69>{call_function_interrupt+133}  <EOI> <ffffffff8011c665>{smp_send_stop+76} 
Jun 11 11:15:09        <ffffffff80137ea2>{panic+235} <ffffffff80111860>{show_stack+241} 
Jun 11 11:15:09        <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} 
Jun 11 11:15:10        <ffffffff8011d16d>{nmi_watchdog_tick+210} <ffffffff80144ac3>{notifier_call_chain+31} 
Jun 11 11:15:10        <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d223>{do_nmi+115} 
Jun 11 11:15:10        <ffffffff80111173>{paranoid_exit+0} <ffffffff8030d37c>{bad_gs+259} 
Jun 11 11:15:10        
Jun 11 11:15:10 
Jun 11 11:15:10 Code:  Bad RIP value.
Jun 11 11:15:10 RIP [<00000000000000ff>] RSP <0000010037e9bfa0>
Jun 11 11:15:10 CR2: 00000000000000ff
Jun 11 11:15:10  <0>Kernel panic - not syncing: Oops
Jun 11 11:15:10  Badness in panic at kernel/panic.c:118
Jun 11 11:15:10 
Jun 11 11:15:10 Call Trace:<IRQ> <ffffffff80137fc6>{panic+527} <ffffffff80110833>{ret_from_intr+0} 
Jun 11 11:15:10        <ffffffff80111aec>{oops_end+38} <ffffffff80111b07>{oops_end+65} 
Jun 11 11:15:10        <ffffffff80124651>{do_page_fault+1125} <ffffffff801326d3>{activate_task+124} 
Jun 11 11:15:10        <ffffffff80132bfe>{try_to_wake_up+876} <ffffffff80110d91>{error_exit+0} 
Jun 11 11:15:10        <ffffffff8011c6b2>{smp_call_function_interrupt+64} 
Jun 11 11:15:10        <ffffffff80110b69>{call_function_interrupt+133}  <EOI> <ffffffff8011c665>{smp_send_stop+76} 
Jun 11 11:15:10        <ffffffff80137ea2>{panic+235} <ffffffff80111860>{show_stack+241} 
Jun 11 11:15:11        <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} 
Jun 11 11:15:11        <ffffffff8011d16d>{nmi_watchdog_tick+210} <ffffffff80144ac3>{notifier_call_chain+31} 
Jun 11 11:15:11        <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d223>{do_nmi+115} 
Jun 11 11:15:11        <ffffffff80111173>{paranoid_exit+0} <ffffffff8030d37c>{bad_gs+259} 
Jun 11 11:15:11        
Jun 11 11:15:11 Badness in i8042_panic_blink at drivers/input/serio/i8042.c:987
Jun 11 11:15:11 
Jun 11 11:15:11 Call Trace:<IRQ> <ffffffff802434c3>{i8042_panic_blink+238} <ffffffff80137f74>{panic+445} 
Jun 11 11:15:12        <ffffffff80110833>{ret_from_intr+0} <ffffffff80111aec>{oops_end+38} 
Jun 11 11:15:12        <ffffffff80111b07>{oops_end+65} <ffffffff80124651>{do_page_fault+1125} 
Jun 11 11:15:12        <ffffffff801326d3>{activate_task+124} <ffffffff80132bfe>{try_to_wake_up+876} 
Jun 11 11:15:12        <ffffffff80110d91>{error_exit+0} <ffffffff8011c6b2>{smp_call_function_interrupt+64} 
Jun 11 11:15:12        <ffffffff80110b69>{call_function_interrupt+133}  <EOI> <ffffffff8011c665>{smp_send_stop+76} 
Jun 11 11:15:12        <ffffffff80137ea2>{panic+235} <ffffffff80111860>{show_stack+241} 
Jun 11 11:15:12        <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} 
Jun 11 11:15:12        <ffffffff8011d16d>{nmi_watchdog_tick+210} <ffffffff80144ac3>{notifier_call_chain+31} 
Jun 11 11:15:12        <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d223>{do_nmi+115} 
Jun 11 11:15:12        <ffffffff80111173>{paranoid_exit+0} <ffffffff8030d37c>{bad_gs+259} 
Jun 11 11:15:12        
Jun 11 11:15:12 Badness in i8042_panic_blink at drivers/input/serio/i8042.c:990
Jun 11 11:15:12 
Jun 11 11:15:13 Call Trace:<IRQ> <ffffffff80243555>{i8042_panic_blink+384} <ffffffff80137f74>{panic+445} 
Jun 11 11:15:13        <ffffffff80110833>{ret_from_intr+0} <ffffffff80111aec>{oops_end+38} 
Jun 11 11:15:13        <ffffffff80111b07>{oops_end+65} <ffffffff80124651>{do_page_fault+1125} 
Jun 11 11:15:13        <ffffffff801326d3>{activate_task+124} <ffffffff80132bfe>{try_to_wake_up+876} 
Jun 11 11:15:13        <ffffffff80110d91>{error_exit+0} <ffffffff8011c6b2>{smp_call_function_interrupt+64} 
Jun 11 11:15:13        <ffffffff80110b69>{call_function_interrupt+133}  <EOI> <ffffffff8011c665>{smp_send_stop+76} 
Jun 11 11:15:13        <ffffffff80137ea2>{panic+235} <ffffffff80111860>{show_stack+241} 
Jun 11 11:15:13        <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} 
Jun 11 11:15:13        <ffffffff8011d16d>{nmi_watchdog_tick+210} <ffffffff80144ac3>{notifier_call_chain+31} 
Jun 11 11:15:13        <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d223>{do_nmi+115} 
Jun 11 11:15:13        <ffffffff80111173>{paranoid_exit+0} <ffffffff8030d37c>{bad_gs+259} 
Jun 11 11:15:13        
Jun 11 11:15:13 Badness in i8042_panic_blink at drivers/input/serio/i8042.c:992
Jun 11 11:15:13 
Jun 11 11:15:14 Call Trace:<IRQ> <ffffffff802435ba>{i8042_panic_blink+485} <ffffffff80137f74>{panic+445} 
Jun 11 11:15:14        <ffffffff80110833>{ret_from_intr+0} <ffffffff80111aec>{oops_end+38} 
Jun 11 11:15:14        <ffffffff80111b07>{oops_end+65} <ffffffff80124651>{do_page_fault+1125} 
Jun 11 11:15:14        <ffffffff801326d3>{activate_task+124} <ffffffff80132bfe>{try_to_wake_up+876} 
Jun 11 11:15:14        <ffffffff80110d91>{error_exit+0} <ffffffff8011c6b2>{smp_call_function_interrupt+64} 
Jun 11 11:15:14        <ffffffff80110b69>{call_function_interrupt+133}  <EOI> <ffffffff8011c665>{smp_send_stop+76} 
Jun 11 11:15:14        <ffffffff80137ea2>{panic+235} <ffffffff80111860>{show_stack+241} 
Jun 11 11:15:14        <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} 
Jun 11 11:15:14        <ffffffff8011d16d>{nmi_watchdog_tick+210} <ffffffff80144ac3>{notifier_call_chain+31} 
Jun 11 11:15:14        <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d223>{do_nmi+115} 
Jun 11 11:15:14        <ffffffff80111173>{paranoid_exit+0} <ffffffff8030d37c>{bad_gs+259} 
Jun 11 11:15:14        
06/11/07 11:16:00 lxb7913 Heartbeat Stopped lxb7913.cern.ch
Jun 11 11:21:55 Badness in i8042_panic_blink at drivers/input/serio/i8042.c:989
Jun 11 11:21:55 
Jun 11 11:21:55 Call Trace:<IRQ> <ffffffff802434c3>{i8042_panic_blink+238} <ffffffff80137f74>{panic+445} 
Jun 11 11:21:55        <ffffffff80110833>{ret_from_intr+0} <ffffffff80111aec>{oops_end+38} 
Jun 11 11:21:55        <ffffffff80111b07>{oops_end+65} <ffffffff80124651>{do_page_fault+1125} 
Jun 11 11:21:55        <ffffffff801326d3>{activate_task+124} <ffffffff80132bfe>{try_to_wake_up+876} 
Jun 11 11:21:55        <ffffffff80110d91>{error_exit+0} <ffffffff8011c6b2>{smp_call_function_interrupt+64} 
Jun 11 11:21:55        <ffffffff80110b69>{call_function_interrupt+133}  <EOI> <ffffffff8011c665>{smp_send_stop+76} 
Jun 11 11:21:55        <ffffffff80137ea2>{panic+235} <ffffffff80111860>{show_stack+241} 
Jun 11 11:21:56        <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} 
Jun 11 11:21:56        <ffffffff8011d16d>{nmi_watchdog_tick+210} <ffffffff80144ac3>{notifier_call_chain+31} 
Jun 11 11:21:56        <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d223>{do_nmi+115} 
Jun 11 11:21:56        <ffffffff80111173>{paranoid_exit+0} <ffffffff8030d37c>{bad_gs+259} 
Jun 11 11:21:56        

Expected results:
no panic?

Additional info:

This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

File uploaded: pairing.tar.gz

This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624
it_file 93334

File uploaded: pagealloc-debug.log

This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624
it_file 95482

Attaching the oops when the DEBUG_PAGEALLOC is enabled.


This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

Updating:

I've been able to reproduce it on upstream kernel too.

I've done some tests here and passive mode always triggers it, then
removing some code parts to see what triggers and what doesn't I
found that the bug only happens when you receive a connection
(passive mode) bind on multicast. I commented out the accept()
close() pair and didn't reproduced it.

There is an ioctl() setting SO_LINGER which doesn't affect the bug and 
setting socket to O_NONBLOCK doesn't affect too.

I'll check the code path of accept and close if there is any special
situation for multicasting packets.

-Flavio


This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

I've found the bug:

starting from sys_accept() it ends up at tcp_v4_syn_recv_sock() to alloc 
new socket doing as below:
...
  newsk = tcp_create_openreq_child(sk, req, skb);
...

but this function does:
tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct
sk_buff *sk) {
        struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC);
...

it's starting to clone the parent socket:
struct sock *inet_csk_clone(struct sock *sk, const struct request_sock
*req,
                            const gfp_t priority)
{
        struct sock *newsk = sk_clone(sk, priority);


sk_clone() ends up at sock_copy(newsk, sk) which does:
memcpy(nsk, osk, osk->sk_prot->obj_size);

Here all struct tcp_sock are copied as-is, including the ->mc_list
pointer
which includes objects with refcounts, so in the end we have two sockets
with the same ->mc_list, but the contents are only for one.

The solution here is to include a new _copy method because it does now:

inet_csk_clone() -> sk_clone() -> sock_copy().

and it should does:

inet_csk_clone() -> inet_sk_clone()  -> sk_clone() -> sock_copy()

and this inet_sk_clone() should bump all objects refcounts in ->mc_list.

I'll cook a patch and test now.
-Flavio


This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

File uploaded: inet_csk_clone-null-mc_list.patch

This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624
it_file 97581

The inet_csk_clone-null-mc_list.patch does ->mc_list = NULL when cloning
the
parent sock. I did just to make sure we are on track and after it I had no

more oopses.

Now I have to figure out if this list should be cloned and the refcnt
bumped
or if we should just nullify it.

-Flavio


This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

Updating:

Looking into other protocol I've found this:
net/sctp/protocol.c:
 sctp_v4_create_accept_sk() {
...
 newinet = inet_sk(newsk);
...
=> newinet->mc_list = NULL;

I sent the patch to upstream but there is no url point to the submit until
now.
-Flavio



This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

Upstream submit url:
http://www.mail-archive.com/netdev%40vger.kernel.org/msg43761.html
-Flavio


This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

Updating:

This is from David Miller answer:
"...
Multicast subscriptions cannot even be used with TCP and DCCP, which
are the only two users of these connection oriented socket functions.
..." 

and he is right, we are trying to use connection oriented socket to
do multicasting work and this is wrong.

I'm sending another patch fixing setsockopt() to return an error when
the socket is connection oriented.

Two things:
1) The customer's application needs to be fixed to use 
SOCK_DGRAM (connectionless) instead of SOCK_STREAM (connection oriented)
See this tips:
http://www.cs.unc.edu/~jeffay/dirt/FAQ/comp249-001-F99/mcast-socket.html

2) Fix the kernel to not allow connection oriented there.
- patch sent, waiting for feedback.

Is that ok with you?
-Flavio


Internal Status set to 'Waiting on Support'

This event sent from IssueTracker by fleitner  [Support Engineering Group]
 issue 123624

Hi,

The latest patch I'm trying to push is this:
http://www.mail-archive.com/netdev%40vger.kernel.org/msg43919.html

but I'm still waiting for feedback.
Could it be on next one?

-Flavio

Patch accepted
http://www.mail-archive.com/netdev%40vger.kernel.org/msg46196.html
-Flavio

Created attachment 175861 [details]
Proposed patch

patch backported to RHEL4 from upstream.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Committed in 68.8

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2008-0665.html