Transfer USB OHCI data via subsystem interface (SIF) DMA #17
Comments
frno7
added
help wanted
|
As I wrote in the other thread, there is no documentation for such a function by the hardware. Otherwise everything would have been easier and better, even for Sony. Even if it does exist, nobody knows how to use it. So the best alternative at this point, is to plan how you will use the IOP's resources and to write the necessary code. |
|
This topic certainly requires some research, especially regarding the capabilities of the IOP. I hope we can design things better than Sony ever did, and honestly that is a rather fun part of this project, but I also recognise that it will not be particularly easy. I also think that sharing resources such as IRX modules with PS2SDK is very valuable, whenever it makes sense. My personal focus at the moment is to prepare #1 along with the necessary tooling and documentation. The MIPS architecture in general is no longer maintained at the level it once was, which is unfortunate, but nevertheless I think it is good to have a set of solid PlayStation 2 Linux kernel base patches. |
Eric reported a syzbot warning: BUG: KMSAN: uninit-value in nh_valid_get_del_req+0x6f1/0x8c0 net/ipv4/nexthop.c:1510 CPU: 0 PID: 11812 Comm: syz-executor444 Not tainted 5.3.0-rc3+ #17 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x162/0x2d0 mm/kmsan/kmsan_report.c:109 __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:294 nh_valid_get_del_req+0x6f1/0x8c0 net/ipv4/nexthop.c:1510 rtm_del_nexthop+0x1b1/0x610 net/ipv4/nexthop.c:1543 rtnetlink_rcv_msg+0x115a/0x1580 net/core/rtnetlink.c:5223 netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x50/0x60 net/core/rtnetlink.c:5241 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0xf6c/0x1050 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x110f/0x1330 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg net/socket.c:657 [inline] ___sys_sendmsg+0x14ff/0x1590 net/socket.c:2311 __sys_sendmmsg+0x53a/0xae0 net/socket.c:2413 __do_sys_sendmmsg net/socket.c:2442 [inline] __se_sys_sendmmsg+0xbd/0xe0 net/socket.c:2439 __x64_sys_sendmmsg+0x56/0x70 net/socket.c:2439 do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:297 entry_SYSCALL_64_after_hwframe+0x63/0xe7 The root cause is nlmsg_parse calling __nla_parse which means the header struct size is not checked. nlmsg_parse should be a wrapper around __nlmsg_parse with NL_VALIDATE_STRICT for the validate argument very much like nlmsg_parse_deprecated is for NL_VALIDATE_LIBERAL. Fixes: 3de6440 ("netlink: re-add parse/validate functions in strict mode") Reported-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David Ahern <dsahern@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
USB OHCI bounce buffers are currently allocated in input/output processor (IOP) local memory. This simple approach supports basic USB devices such as keyboards, but there are two severe drawbacks:
IOP local memory is limited to 2 MiB, of which only 256 KiB is available for all connected USB device drivers in total. See the implementation details in commit e85d170. Many complex USB device drivers need much larger buffers to operate. For example, commit 0b3a20c reduces the memory requirements for wireless rt2x00 devices. In addition, mass storage device drivers may busy-loop waiting for buffer memory to become available. This is inefficient and a potential deadlock.
Bounce buffers for USB OHCI data is very slow, and relies on misuse of kernel interfaces. The drivers drivers/usb/host/ohci-sm501.c and drivers/usb/host/ohci-tmio.c seem to do this too, and they appear to be unmaintained.
Is it possible to transfer USB OHCI data via subsystem interface (SIF) DMA, for main memory buffers?
See also #2 and #11.
The text was updated successfully, but these errors were encountered: