netdev - Re: [PATCH] USBNET: fix handling padding packet

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: <CACVXFVPOyr3eDrJxGhmoxDdZS2FL17qm6jv0ezDECUAk267jFg@mail.gmail.com>
Date:	Thu, 19 Sep 2013 21:08:08 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	Oliver Neukum <oneukum@...e.de>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Network Development <netdev@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>
Subject: Re: [PATCH] USBNET: fix handling padding packet

On Thu, Sep 19, 2013 at 3:18 PM, Bjørn Mork <bjorn@...k.no> wrote:
> Oliver Neukum <oneukum@...e.de> writes:
>> On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
>>> Oliver Neukum <oneukum@...e.de> wrote:
>>
>>> >No, USB 3.0 uses no companion controllers, so you can have devices
>>> >of any speed connected to it.
>>> >
>>>
>>> Ah, right. I don't own such modern hardware, but I should have known
>>> this anyway.
>>>
>>> This still doesn't change the fact that the driver is brand new for
>>> brand new devices. I believe we should assume such devices will
>>> support ZLPs unless we have documentation stating anything else.
>>
>> For such devices we might assume it. But how does that matter for
>> generic code?
>
> The code isn't generic yet.  Most of it is placed inside the
> ax88179_178a minidriver.

No, the patch doesn't touch code of ax99179_178a.

And it is really generic to fix the padding in case of dma sg.

>
> But I do agree that adding this padding support can be seen as one step
> towards making the code generic.  So if you really anticipate this being
> enabled for e.g. the ECM class driver, then yes, padding must be
> supported.

1byte padding frame is already supported by usbnet before, isn't it?

>
> I would have had less trouble understanding the value if this patch was
> part of a generalisation series, though...

As my below test on ax99179_178a, I believe the patch should fix padding
for dma sg, but need a little update, and I will send out v1 later:

           $ping -s 974 another_machine  #from host with ax99179_178a attached

If FLAG_SEND_ZLP is set for ax99179_178a, the above ping won't work any
more either on USB3.0 or USB 2.0 host controller.

So don't assume that these brand new devices can support ZLP well.

>
>> As any kind of device may be connected to XHCI, the sg
>> code is relevant for every driver. And I certainly don't want trouble
>> for older devices' drivers converted to sg.
>
> I wonder what the gain of that really is?  Yes, I can see the advantage
> of making the class drivers more effective.  But padding is only
> relevant for the ECM class, isn't it? And are there any ECM class
> devices where SG support matters?

Why is padding only relevant for the ECM? Of course, other devices
need it too, such as asix devices.

Thanks,
--
Ming Lei
--
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