Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932477AbcKYRHP (ORCPT ); Fri, 25 Nov 2016 12:07:15 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:46586 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754244AbcKYRHH (ORCPT ); Fri, 25 Nov 2016 12:07:07 -0500 Date: Fri, 25 Nov 2016 11:58:27 -0500 (EST) Message-Id: <20161125.115827.2014848246966159357.davem@davemloft.net> To: mlord@pobox.com Cc: greg@kroah.com, romieu@fr.zoreil.com, hayeswang@realtek.com, netdev@vger.kernel.org, nic_swsd@realtek.com, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable From: David Miller In-Reply-To: <1816ec7e-2733-f4ba-5d30-29dbabd20aad@pobox.com> References: <20161125095350.GA20653@kroah.com> <1816ec7e-2733-f4ba-5d30-29dbabd20aad@pobox.com> X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 25 Nov 2016 07:59:05 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1038 Lines: 22 From: Mark Lord Date: Fri, 25 Nov 2016 07:49:35 -0500 > On 16-11-25 04:53 AM, Greg KH wrote: >> On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote: >>> There is no possibility for them to be used for anything other than >>> USB receive buffers, for this driver only. Nothing in the driver >>> or kernel ever writes to those buffers after initial allocation, >>> and only the driver and USB host controller ever have pointers to the buffers. >> >> You really are going to have to break out that USB monitor to verify >> that this is the data coming across the wire. > > Not sure why, because there really is no other way for the data to > appear where it does at the beginning of that URB buffer. > > This does seem a rather unexpected burden to place upon someone > reporting a regression in a USB network driver that corrupts user data. If you are the only person who can actively reproduce this, which seems to be the case right now, this is unfortunately the only way to reach a proper analysis and fix.