<div dir="ltr"><div>Salut,</div><div><br></div><div>Am facut putin debugging, si am gasit linia.</div><div><br></div><div>La apelul __skb_unlink din __skb_recv_datagram, ajunge skb->prev sa fie NULL.</div><div><br></div>
<div>static inline void __skb_unlink(struct sk_buff *skb, struct sk_buff_head *list)</div><div>{</div><div>        struct sk_buff *next, *prev;</div><div><br></div><div>        list->qlen--;</div><div>        next       = skb->next;</div>
<div>        prev       = skb->prev;</div><div>        skb->next  = skb->prev = NULL;</div><div>        next->prev = prev;</div><div>        <b>prev->next = next;//la adresa asta obtin BUG-ul</b></div><div>
}</div><div><br></div><div>In stp_rcv, pun skb-ul in coada cu __skb_queue_tail(&sk->sk_receive_queue, skb), cu lock-ul cozii luat.</div><div><br></div><div>Care ar putea fi motivul ca skb->prev sa fie NULL ? Ar trebui eu </div>
<div>sa-mi pun probleme de consistenta cozii?</div><div><br></div><div>Multumesc, Alex Teaca</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 9:12 PM, Alex Teaca <span dir="ltr"><<a href="mailto:ionutalex.teaca@gmail.com" target="_blank">ionutalex.teaca@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Salut,</div><div><br></div><div>Am implementat stp_sendmsg si stp_recvmsg; pentru un singur</div>
<div>send si recv pe socket ajunge mesajul la destinatie in userspace.</div><div><br></div>
<div>La testul test_sendto_recvfrom_ping_pong in schimb, primesc local si pe vmchecker:</div><div><br></div><div>BUG: unable to handle kernel NULL pointer dereference at   (null)</div><div>[    9.816208] IP: [] __skb_recv_datagram+0x148/0x480</div>

<div>[    9.816208] *pde = 00000000 </div><div>[    9.816208] Oops: 0002 [#1] SMP </div><div>[    9.816208] Modules linked in: af_stp(O) netconsole [last unloaded: af_stp]</div><div>[    9.816208] CPU: 0 PID: 1088 Comm: stp_test Tainted: G           O 3.13.0 #13</div>

<div>[    9.816208] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011</div><div>[    9.816208] task: c6bbb340 ti: c6a00000 task.ti: c6a00000</div><div>[    9.816208] EIP: 0060:[] EFLAGS: 00000002 CPU: 0</div><div>[    9.816208] EIP is at __skb_recv_datagram+0x148/0x480</div>

<div>[    9.816208] EAX: 00000282 EBX: c6ab7540 ECX: c6ab7600 EDX: 00000000</div><div>[    9.816208] ESI: c6a54400 EDI: 00000000 EBP: c6a01c80 ESP: c6a01c24</div><div>[    9.816208]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068</div>

<div>[    9.816208] CR0: 8005003b CR2: 00000000 CR3: 0761b000 CR4: 00000690</div><div>[    9.816208] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000</div><div>[    9.816208] DR6: 00000000 DR7: 00000000</div><div>
[    9.816208] Stack:</div>
<div>[    9.816208]  c6bbb340 0000007b 0000007b 000000d8 00000000 7fffffff c6bbb340 00000000</div><div>[    9.816208]  c6bbb340 00000000 c6a01c90 c6a544c0 00000000 c6a54400 c6a544b4 c6a01c80</div><div>[    9.816208]  00000000 00000246 00000006 c0c04900 00000000 c6a54400 c6a01d74 c6a01c9c</div>

<div>[    9.816208] Call Trace:</div><div>[    9.816208]  [] skb_recv_datagram+0x36/0x40</div><div>[    9.816208]  [] stp_recvmsg+0x9a/0x160 [af_stp]</div><div>[    9.816208]  [] sock_recvmsg+0x99/0xd0</div><div>[    9.816208]  [] ? sockfd_lookup_light+0x25/0x70</div>

<div>[    9.816208]  [] SYSC_recvfrom+0xae/0x110</div><div>[    9.816208]  [] ? i_size_read+0x80/0x80</div><div>[    9.816208]  [] ? shmem_fault+0x45/0x80</div><div>[    9.816208]  [] ? _copy_from_user+0x35/0x50</div><div>

[    9.816208]  [] SYSC_socketcall+0x45a/0x8c0</div><div>[    9.816208]  [] ? __do_fault+0x11f/0x410</div><div>[    9.816208]  [] ? __do_fault+0x1a4/0x410</div><div>[    9.816208]  [] ? unlock_page+0x48/0x50</div><div>[    9.816208]  [] ? __do_fault+0x1ac/0x410</div>

<div>[    9.816208]  [] ? _raw_spin_unlock_irq+0x22/0x30</div><div>[    9.816208]  [] ? finish_task_switch+0x7f/0xd0</div><div>[    9.816208]  [] ? finish_task_switch+0x3d/0xd0</div><div>[    9.816208]  [] ? __schedule+0x31f/0x720</div>

<div>[    9.816208]  [] ? __do_page_fault+0x28f/0x4c0</div><div>[    9.816208]  [] ? __fput+0x149/0x1f0</div><div>[    9.816208]  [] SyS_socketcall+0x13/0x20</div><div>[    9.816208]  [] sysenter_do_call+0x12/0x2d</div><div>

[    9.816208] Code: 1c 02 00 00 89 45 b8 e9 12 ff ff ff 8b 4d d8 83 a9 bc 00 00 00 01 8b 0b 8b 53 04 c7 03 00 00 00 00 c7 43 04 00 00 00 00 89 51 04 <89> 0a eb 85 8d 74 26 00 8b 45 c8 89 df 89 c2 8b 45 d0 e8 31 68</div>

<div>[    9.816208] EIP: [] __skb_recv_datagram+0x148/0x480 SS:ESP 0068:c6a01c24</div><div>[    9.816208] CR2: 0000000000000000</div><div>[    9.816208] ---[ end trace e06641adf6321bb2 ]---</div><div><br></div><div><br></div>

<div>Din mesajele de debug, deduc faptul ca prima pereche (sendto_message - recvfrom_message)</div><div>se termina cu succes si bug-ul se produce la apelul recvfrom_message din sender.</div><div><br></div><div>In stp_recvmsg, apelez </div>

<div>struct sock *sk = sock->sk;</div><div>................................</div><div>skb = skb_recv_datagram(sk, flags, flags & MSG_DONTWAIT, &err);</div><div><br></div><div>Care ar fi motivul pentru care in __skb_recv_datagram ajunge un NULL pointer ?</div>

<div>(cel putin asta inteleg eu din trace)</div><div><br></div><div>Multumesc, Alex Teaca</div><div><br></div></div>
</blockquote></div><br></div>