linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hayes Wang <hayeswang@realtek.com>
To: Mark Lord <mlord@pobox.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: nic_swsd <nic_swsd@realtek.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
Subject: RE: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable
Date: Wed, 23 Nov 2016 03:52:30 +0000	[thread overview]
Message-ID: <0835B3720019904CB8F7AA43166CEEB2010517CE@RTITMBSV03.realtek.com.tw> (raw)
In-Reply-To: <b9809516-d036-bfc3-b7a3-6563033ec957@pobox.com>

Mark Lord [mailto:mlord@pobox.com]
> Sent: Friday, November 18, 2016 8:03 PM
[..]
> How does the RTL8152 know that the limit is 16KB,
> rather than some other number?  Is this a hardwired number
> in the hardware, or is it a parameter that the software
> sends to the chip during initialization?

It is the limitation of the hardware.

> I have a USB analyzer, but it is difficult to figure out how
> to program an appropriate trigger point for the capture,
> since the problem (with 16KB URBs) takes minutes to hours
> or even days to trigger.

It is good. Our hw engineers real want it. Maybe you could send
a specific packet, and trigger it. You could allocate a skb and
fill the data which you prefer, and call

	skb_queue_tail(&tp->tx_queue, skb);

[...]
> The first issue is that a packet sometimes begins in one URB,
> and completes in the next URB, without an rx_desc at the start
> of the second URB.  This I have already reported earlier.

However, our hw engineer says it wouldn't happen. Our hw always
sends rx_desc + packet + padding. The hw wouldn't split it to
two or more transmission. That is why I wonder who does it.

> But the driver, as written, sometimes accesses bytes outside
> of the 16KB URB buffer, because it trusts the non-existent
> rx_desc in these cases, and also because it accesses bytes
> from the rx_desc without first checking whether there is
> sufficient remaining space in the URB to hold an rx_desc.

I think I check them. According to the followning code,

	list_for_each_safe(cursor, next, &rx_queue) {
		struct rx_desc *rx_desc;
		struct rx_agg *agg;
		int len_used = 0;
		struct urb *urb;
		u8 *rx_data;

		...

		rx_desc = agg->head;
		rx_data = agg->head;
		len_used += sizeof(struct rx_desc); //<-- add the size of next rx_desc

		while (urb->actual_length > len_used) {
			struct net_device *netdev = tp->netdev;
			struct net_device_stats *stats = &netdev->stats;
			unsigned int pkt_len;
			struct sk_buff *skb;

			pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
			if (pkt_len < ETH_ZLEN)
				break;

			len_used += pkt_len;
			if (urb->actual_length < len_used)
				break;

			pkt_len -= CRC_SIZE;
			rx_data += sizeof(struct rx_desc);

			...

find_next_rx:
			rx_data = rx_agg_align(rx_data + pkt_len + CRC_SIZE);
			rx_desc = (struct rx_desc *)rx_data;
			len_used = (int)(rx_data - (u8 *)agg->head);
			len_used += sizeof(struct rx_desc); //<-- add the size of next rx_desc
		}

submit:
		...
	}

The while loop would check if the next rx_desc is inside the urb
buffer, because the len_used includes the size of the next rx_desc.
Then, in the while loop, the len_used adds the packet size and check
with urb->actual_length again. These make sure the rx_desc and the
packet are inside the urb buffer. Except the urb->actual_length
is more than agg_buf_sz. However, I don't think it would happen.

Best Regards,
Hayes

  parent reply	other threads:[~2016-11-23  3:52 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-11  7:15 [PATCH net 0/2] r8152: rx patches Hayes Wang
2016-11-11  7:15 ` [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Hayes Wang
2016-11-17  3:36   ` Hayes Wang
2016-11-17 14:14     ` Mark Lord
2016-11-17 14:25       ` Mark Lord
     [not found]     ` <d683c019-4e0f-6fe6-368c-c4fc86c72fe6@pobox.com>
2016-11-18  7:57       ` Hayes Wang
2016-11-18 12:03         ` Mark Lord
2016-11-22 13:12           ` Mark Lord
2016-11-23  3:52           ` Hayes Wang [this message]
2016-11-23 13:41             ` Mark Lord
2016-11-23 15:12               ` Hayes Wang
2016-11-23 19:29                 ` Mark Lord
2016-11-24  3:24                   ` Hayes Wang
2016-11-24 12:31                   ` Mark Lord
2016-11-24 13:26                     ` Hayes Wang
2016-11-24 15:24                       ` Mark Lord
2016-11-25  6:11                         ` Hayes Wang
2016-11-25 12:36                           ` Mark Lord
2016-11-24 16:21                       ` David Miller
2016-11-24 16:43                         ` Mark Lord
2016-11-24 17:00                           ` Mark Lord
2016-11-24 17:13                             ` David Miller
2016-11-24 17:11                           ` David Miller
2016-11-24 18:34                             ` Mark Lord
2016-11-24 18:49                               ` Mark Lord
2016-11-24 19:00                               ` Greg KH
2016-11-24 19:10                                 ` Mark Lord
2016-11-24 19:17                                   ` Greg KH
2016-11-25  9:52                                   ` Hayes Wang
2016-11-25 13:32                                     ` Mark Lord
2016-11-25  0:27                               ` Francois Romieu
2016-11-25  3:49                                 ` Mark Lord
2016-11-25  9:53                                   ` Greg KH
2016-11-25 12:34                                     ` Mark Lord
2016-11-25 12:41                                       ` Mark Lord
2016-11-25 14:22                                         ` Greg KH
2016-11-25 14:35                                           ` Mark Lord
2016-11-25 12:49                                     ` Mark Lord
2016-11-25 14:24                                       ` Greg KH
2016-11-25 16:58                                       ` David Miller
2016-11-30 11:58                                         ` Hayes Wang
2016-12-09  3:23                                           ` Hayes Wang
2016-12-09 13:05                                             ` Mark Lord
2017-01-01  0:07                                           ` Ansis Atteka
2017-01-03  0:40                                             ` Ansis Atteka
2017-01-03 13:19                                               ` Mark Lord
2017-01-09  7:58                                               ` Hayes Wang
2019-01-05 14:14                                             ` r8152: data corruption in various scenarios Mark Lord
2019-01-05 14:22                                               ` Mark Lord
2019-01-06 19:14                                               ` Kai Heng Feng
2019-01-06 21:13                                                 ` Mark Lord
2019-01-06 21:16                                                   ` Mark Lord
2019-01-07  3:53                                                     ` Hayes Wang
2019-01-07 16:01                                                       ` Mario.Limonciello
2019-01-07 18:06                                                         ` Mark Lord
2019-01-07 18:27                                                           ` Mario.Limonciello
2019-01-07 19:24                                                             ` Mark Lord
2019-01-07  4:09                                                     ` Kai Heng Feng
2019-01-07  4:13                                                       ` Mark Lord
2019-01-07  6:46                                                         ` Kai Heng Feng
2019-01-07  7:01                                                           ` Mark Lord
2016-11-24 18:42                           ` [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable Greg KH
2016-11-24 18:58                             ` Mark Lord
2016-11-25  6:31                           ` Hayes Wang
2016-11-25  6:51                             ` Hayes Wang
2016-11-25 12:35                               ` Mark Lord
2016-11-24 16:19                     ` David Miller
2016-11-24 12:37               ` Hayes Wang
2016-11-11  7:15 ` [PATCH net 2/2] r8152: rx descriptor check Hayes Wang
2016-11-11 12:13   ` Francois Romieu
2016-11-12 13:21     ` Mark Lord
2016-11-14  6:43     ` Hayes Wang
2016-11-15  1:10       ` Francois Romieu
2016-11-17  3:05         ` Hayes Wang
2016-11-13 17:39   ` David Miller
2016-11-13 20:34     ` Mark Lord
2016-11-13 20:38       ` Mark Lord
2016-11-14  7:23       ` Hayes Wang
2016-11-14 17:27         ` David Miller
2016-11-14  7:03     ` Hayes Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0835B3720019904CB8F7AA43166CEEB2010517CE@RTITMBSV03.realtek.com.tw \
    --to=hayeswang@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mlord@pobox.com \
    --cc=netdev@vger.kernel.org \
    --cc=nic_swsd@realtek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).