[so2] [Tema 5][__skb_recv_datagram]

[Alex Teaca]

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/20140516/366362b7/attachment.html>