netdev - Re: ICMP packets - ll_temac with Microblaze

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4EF32A21.3060503@linux.vnet.ibm.com>
Date:	Thu, 22 Dec 2011 21:01:21 +0800
From:	Michael Wang <wangyun@...ux.vnet.ibm.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	monstr@...str.eu, David Miller <davem@...emloft.net>,
	John Williams <john.williams@...alogix.com>,
	netdev@...r.kernel.org
Subject: Re: ICMP packets - ll_temac with Microblaze

On 12/22/2011 06:46 PM, Eric Dumazet wrote:

> Le jeudi 22 décembre 2011 à 18:32 +0800, Michael Wang a écrit :
>> On 12/21/2011 06:11 PM, Michal Simek wrote:
>>
>>> Hi Eric and David,
>>>
>>> I have found one problem with ll_temac driver and
>>> this commit: net: more accurate skb truesize
>>> sha1: 87fb4b7b533073eeeaed0b6bf7c2328995f6c075
>>>
>>> The problem is only with icmp packets from the target. It is sent and
>>> driver receive it
>>> but it is not proceed to the application.
>>>
>>
>> Hi, Michal
>>
>> What's the type of icmp you are using? such as "EchoReps", we can find
>> the actually handler routine by this type.
>>
>> And you said the packet already received by driver, can you tell me the
>> way you used to confirm this?
>>
>> And have you checked when was the icmp packet being dropped, is it in
>> icmp_rcv or before or later?
> 
> Packet was dropped right before being queued in RAW socket
> receive_queue, because of low sk_rcvbuf setting (against skb->truesize)
> 

Hi, Eric

So do you mean the way is:

ip_local_deliver_finish --> raw_local_deliver --> raw_v4_input -->
raw_rcv --> raw_rcv_skb --> sock_queue_rcv_skb

And in sock_queue_rcv_skb:

        if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
            (unsigned)sk->sk_rcvbuf) {
                atomic_inc(&sk->sk_drops);
                trace_sock_rcvqueue_full(sk, skb);
                return -ENOMEM;				//drop?
        }

Is this the way the packet being dropped? Is this confirmed by some printk?

Sorry if the question is naive, I just want to make sure I am checking
at the right place.

Regards,
Michael Wang

> 
> 


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html