On 2020/2/19 上午2:30, Aleksandar Markovic wrote:
On Tuesday, February 4, 2020, Jason Wang <jasow...@redhat.com
<mailto:jasow...@redhat.com>> wrote:
On 2020/1/29 下午5:27, Finn Thain wrote:
Hi All,
There are bugs in the emulated dp8393x device that can stop packet
reception in a Linux/m68k guest (q800 machine).
With a Linux/m68k v5.5 guest (q800), it's possible to remotely
trigger
an Oops by sending ping floods.
With a Linux/mips guest (magnum machine), the driver fails to
probe
the dp8393x device.
With a NetBSD/arc 5.1 guest (magnum), the bugs in the device
can be
fatal to the guest kernel.
Whilst debugging the device, I found that the receiver algorithm
differs from the one described in the National Semiconductor
datasheet.
This patch series resolves these bugs.
AFAIK, all bugs in the Linux sonic driver were fixed in Linux
v5.5.
---
Changed since v1:
- Minor revisions as described beneath commit logs.
- Dropped patches 4/10 and 7/10.
- Added 5 new patches.
Changed since v2:
- Minor revisions as described beneath commit logs.
- Dropped patch 13/13.
- Added 2 new patches.
Changed since v3:
- Replaced patch 13/14 with patch suggested by Philippe
Mathieu-Daudé.
Finn Thain (14):
dp8393x: Mask EOL bit from descriptor addresses
dp8393x: Always use 32-bit accesses
dp8393x: Clean up endianness hacks
dp8393x: Have dp8393x_receive() return the packet size
dp8393x: Update LLFA and CRDA registers from rx descriptor
dp8393x: Clear RRRA command register bit only when appropriate
dp8393x: Implement packet size limit and RBAE interrupt
dp8393x: Don't clobber packet checksum
dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
dp8393x: Pad frames to word or long word boundary
dp8393x: Clear descriptor in_use field to release packet
dp8393x: Always update RRA pointers and sequence numbers
dp8393x: Don't reset Silicon Revision register
dp8393x: Don't stop reception upon RBE interrupt assertion
hw/net/dp8393x.c | 202
+++++++++++++++++++++++++++++++----------------
1 file changed, 134 insertions(+), 68 deletions(-)
Applied.
Hi, Jason,
I generally have some reservations towards patches that did not
receive any R-bs. I think we should hear from Herve in this case, to
confirm that this change doesn't cause other problems while solving
the original ones.
That's fine but if it's agreed that we should hear from somebody for a
specific part of the code, it's better to have the one as
maintainer/reviewer in MAINTAINERS.
Thanks
I hope this is not the case.
Regards,
Aleksandar