netdev - RE: usbnet transmit path problems

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: <AE90C24D6B3A694183C094C60CF0A2F6026B7326@saturn3.aculab.com>
Date:	Wed, 11 Sep 2013 13:56:48 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Ming Lei" <ming.lei@...onical.com>,
	"Oliver Neukum" <oliver@...kum.org>
Cc:	<netdev@...r.kernel.org>
Subject: RE: usbnet transmit path problems

> > > 2) If 'length % dev->maxpacket == 0' for a multi-fragment packet then
> > >    the extra byte isn't added correctly (the code probably falls off
> > >    the end of the scatter-gather list).
> >
> > Indeed. Ming Lei, should usbnet handle this in the sg case or better
> > leave it to the subdriver you introduced this for?

Is the ZLP issue a problem with the host or with the target?
If it is a host problem then the necessity comes from the host,
but the fix needs to be target dependant.
If it is a common target problem then generic code can apply
a common fix.

AFICT there are at least 3 fixes:
1) Extend the ethernet frame by one byte and hope the receiving
   system doesn't object to the padding.
   This is probably the only option if tx_fixup() doesn't
   add a header.
2) Put the ethernet frame length in the header and have the
   target discard the added pad byte (ax88179_178a.c).
3) Add a second zero-length frame in the same USB data block
   (ax88172a.c).

Only the third requires that tx_fixup() append to the packet.
For the other two actual pad can be added by usbnet.

> IMO, it should be handled by usbnet, could you comment on below patch?

Seems excessive to kmalloc() one byte!
If you can't assume that the 'dev' structure itself can be dma'd from
allocate the extra byte in the sg list.

	David

--
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