[so2] [Tema 5][__skb_recv_datagram]

[Alex Teaca]

Salut,

Nu mai conteaza, am rezolvat.

Pentru cine se mai loveste de problema aceasta, functia implementata pentru
notificarea pachetelor la receptie:

struct packet_type prot_hook.func = stp_rcv;//de exemplu

pentru fiecare packet trimis, se apela de 2 ori(pentru ambii socketi).

Am rezolvat filtrand dupa portul destinatie al pachetelor.

Multumesc, Alex Teaca



On Fri, May 16, 2014 at 5:36 PM, Alex Teaca <ionutalex.teaca at gmail.com>wrote:

> Salut,
>
> Am facut putin debugging, si am gasit linia.
>
> La apelul __skb_unlink din __skb_recv_datagram, ajunge skb->prev sa fie
> NULL.
>
> static inline void __skb_unlink(struct sk_buff *skb, struct sk_buff_head
> *list)
> {
>         struct sk_buff *next, *prev;
>
>         list->qlen--;
>         next       = skb->next;
>         prev       = skb->prev;
>         skb->next  = skb->prev = NULL;
>         next->prev = prev;
>         *prev->next = next;//la adresa asta obtin BUG-ul*
> }
>
> In stp_rcv, pun skb-ul in coada cu __skb_queue_tail(&sk->sk_receive_queue,
> skb), cu lock-ul cozii luat.
>
> Care ar putea fi motivul ca skb->prev sa fie NULL ? Ar trebui eu
> sa-mi pun probleme de consistenta cozii?
>
> Multumesc, Alex Teaca
>
>
>
> On Thu, May 15, 2014 at 9:12 PM, Alex Teaca <ionutalex.teaca at gmail.com>wrote:
>
>>
>> Salut,
>>
>> Am implementat stp_sendmsg si stp_recvmsg; pentru un singur
>> send si recv pe socket ajunge mesajul la destinatie in userspace.
>>
>> La testul test_sendto_recvfrom_ping_pong in schimb, primesc local si pe
>> vmchecker:
>>
>> BUG: unable to handle kernel NULL pointer dereference at   (null)
>> [    9.816208] IP: [] __skb_recv_datagram+0x148/0x480
>> [    9.816208] *pde = 00000000
>> [    9.816208] Oops: 0002 [#1] SMP
>> [    9.816208] Modules linked in: af_stp(O) netconsole [last unloaded:
>> af_stp]
>> [    9.816208] CPU: 0 PID: 1088 Comm: stp_test Tainted: G           O
>> 3.13.0 #13
>> [    9.816208] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>> [    9.816208] task: c6bbb340 ti: c6a00000 task.ti: c6a00000
>> [    9.816208] EIP: 0060:[] EFLAGS: 00000002 CPU: 0
>> [    9.816208] EIP is at __skb_recv_datagram+0x148/0x480
>> [    9.816208] EAX: 00000282 EBX: c6ab7540 ECX: c6ab7600 EDX: 00000000
>> [    9.816208] ESI: c6a54400 EDI: 00000000 EBP: c6a01c80 ESP: c6a01c24
>> [    9.816208]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
>> [    9.816208] CR0: 8005003b CR2: 00000000 CR3: 0761b000 CR4: 00000690
>> [    9.816208] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
>> [    9.816208] DR6: 00000000 DR7: 00000000
>> [    9.816208] Stack:
>> [    9.816208]  c6bbb340 0000007b 0000007b 000000d8 00000000 7fffffff
>> c6bbb340 00000000
>> [    9.816208]  c6bbb340 00000000 c6a01c90 c6a544c0 00000000 c6a54400
>> c6a544b4 c6a01c80
>> [    9.816208]  00000000 00000246 00000006 c0c04900 00000000 c6a54400
>> c6a01d74 c6a01c9c
>> [    9.816208] Call Trace:
>> [    9.816208]  [] skb_recv_datagram+0x36/0x40
>> [    9.816208]  [] stp_recvmsg+0x9a/0x160 [af_stp]
>> [    9.816208]  [] sock_recvmsg+0x99/0xd0
>> [    9.816208]  [] ? sockfd_lookup_light+0x25/0x70
>> [    9.816208]  [] SYSC_recvfrom+0xae/0x110
>> [    9.816208]  [] ? i_size_read+0x80/0x80
>> [    9.816208]  [] ? shmem_fault+0x45/0x80
>> [    9.816208]  [] ? _copy_from_user+0x35/0x50
>> [    9.816208]  [] SYSC_socketcall+0x45a/0x8c0
>> [    9.816208]  [] ? __do_fault+0x11f/0x410
>> [    9.816208]  [] ? __do_fault+0x1a4/0x410
>> [    9.816208]  [] ? unlock_page+0x48/0x50
>> [    9.816208]  [] ? __do_fault+0x1ac/0x410
>> [    9.816208]  [] ? _raw_spin_unlock_irq+0x22/0x30
>> [    9.816208]  [] ? finish_task_switch+0x7f/0xd0
>> [    9.816208]  [] ? finish_task_switch+0x3d/0xd0
>> [    9.816208]  [] ? __schedule+0x31f/0x720
>> [    9.816208]  [] ? __do_page_fault+0x28f/0x4c0
>> [    9.816208]  [] ? __fput+0x149/0x1f0
>> [    9.816208]  [] SyS_socketcall+0x13/0x20
>> [    9.816208]  [] sysenter_do_call+0x12/0x2d
>> [    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
>> [    9.816208] EIP: [] __skb_recv_datagram+0x148/0x480 SS:ESP
>> 0068:c6a01c24
>> [    9.816208] CR2: 0000000000000000
>> [    9.816208] ---[ end trace e06641adf6321bb2 ]---
>>
>>
>> Din mesajele de debug, deduc faptul ca prima pereche (sendto_message -
>> recvfrom_message)
>> se termina cu succes si bug-ul se produce la apelul recvfrom_message din
>> sender.
>>
>> In stp_recvmsg, apelez
>> struct sock *sk = sock->sk;
>> ................................
>> skb = skb_recv_datagram(sk, flags, flags & MSG_DONTWAIT, &err);
>>
>> Care ar fi motivul pentru care in __skb_recv_datagram ajunge un NULL
>> pointer ?
>> (cel putin asta inteleg eu din trace)
>>
>> Multumesc, Alex Teaca
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so2/attachments/20140517/99233189/attachment.html>