| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
syzbot says that the change exposes UB in usb_free_device and I can't
see how, so revert until I have a better understanding of what's going on.
Reported-by: syzbot+c445f7149cce07d4c252@syzkaller.appspotmail.com
Reported-by: syzbot+a2ae42f37de765a54b20@syzkaller.appspotmail.com
|
|
|
|
|
|
|
|
In uhub_explore instead of waiting 300ms after powering up each
connected port, power up all of the connected ports and then wait for
300ms total.
|
|
New usb_in_event_thread(dev) returns true if dev is a USB device --
that is, a device with a usbN ancestor -- and the current thread is
the USB event thread.
(Kinda kludgey to pass around the device_t instead of, say, struct
usbd_bus, but I don't see a good way to get to the usbN device_t or
struct usb_softc from there.)
|
|
Keep all of the USB bus exploration in a single thread -- this
appears to have been the original assumption, violated back in 2008
when uhub_rescan was added, and will make everything simpler.
|
|
Otherwise, if uhub4 is attached at uhub1, then when we do
# drvctl -d uhub4
# drvctl -r -a usbdevif uhub1
the rescan never discovers devices attached recursively at uhub4, and
uhub4 leaks a config_pending_incr count so it can't be detached.
|
|
|
|
|
|
Otherwise we might simultaneously attach two autoconf instances of
the same device, which leads to no good.
|
|
|
|
|
|
threads other than curlwp, which is useful when fuzzing components that
defer processing, such as the network stack (partially runs in softints)
and the USB stack (partially runs in uhub kthreads).
A subsystem that whishes to provide coverage for its threads creates a
"mailbox" via kcov_remote_register() and gives it a (subsystem, id)
identifier. There is one mailbox per "target lwp". The target lwp(s)
must then call kcov_remote_enter() and kcov_remote_leave() with the
identifier, to respectively enable and disable coverage within the
thread.
On the userland side, the fuzzer has access to the mailboxes on the
system with the KCOV_IOC_REMOTE_ATTACH and KCOV_IOC_REMOTE_DETACH ioctls.
When attached to a mailbox with a given identifier, the KCOV_IOC_ENABLE,
KCOV_IOC_DISABLE and mmap() operations will affect the mailbox.
As a demonstrator, the vHCI subsystem is changed to use KCOV mailboxes.
When the vHCI bus attaches it creates as many mailboxes as it has USB
ports, each mailbox being associated with a distinct port. Uhub is changed
to enable KCOV coverage in usbd_new_device(). With that in place, all of
the USB enumeration procedure can be traced with KCOV.
|
|
|
|
USBHIST_CALLARGS() calls. this reduces the number of
kernel history lines consumed by these callers, and
for the +LOGN versions, add useful log info to a
message that just says "called!".
reduces the line spam which means the total info in a
full log is significantly increased.
|
|
|
|
This complements change in revision 1.140
|
|
Make sure USB ports numbers are displayed with the first one as number one
and not number zero when rescanning bus. The change makes the display
consistent with the display at boot time USB discovery.
While we are there, make port iteration consistent everywhere in the code,
always starting at one instead of zero.
|
|
- call config_pending_incr() and config_pending_decr() around attaching
devices against "usbdevif" attribute.
uhub:
- convert sc_explorepending and sc_running to bool. add new sc_first_explore.
- call config_pending_incr() at the start of uhub_attach(). dropped in
uhub_explore(), if this is the first explore.
|
|
controller drivers detachable. OK'd by Nick.
|
|
in PR kern/52639, as well as some general cleaning-up...
(As proposed on tech-kern@ with additional changes and enhancements.)
Details of changes:
* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)
* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.
* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.
* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."
* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.
* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).
* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).
* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.
* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.
[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".
[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.
|
|
kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()
all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.
|
|
|
|
|
|
- API / infrastructure changes to support memory management changes.
- Memory management improvements and bug fixes.
- HCDs should now be MP safe
- conversion to KERNHIST based debug
- FS/LS isoc support on ehci(4).
- conversion to kmem(9)
- Some USB 3 support - mostly from Takahiro HAYASHI (t-hash).
- interrupt transfers now get proper DMA operations
- general bug fixes
- kern/48308
- uhub status notification improvements
- umass(4) probe fix (applied to HEAD already)
- ohci(4) short transfer fix
|
|
|
|
|
|
usbd_clear_port_feature(dev, port, UHF_C_PORT_RESET)
The Gadget USB HUB in the IBM x3250 sborrill sent me returns the wrong
status and this would appear to leave the attached cdce(4) in the default
state. The next device probed fails as a result.
|
|
|
|
|
|
|
|
PR/49106: panic: ehci_open: bad device speed 4
|
|
|
|
|
|
|
|
|
|
- include opt_usb.h in usb.h so that USB_DEBUG gets set properly in it.
- normalize and sort debugging variables
|
|
- remove trailing whitespace
- add missing KERNEL_RCSID
|
|
|
|
This prevents a kernel panic at shutdown on my laptop.
|
|
triggering KERNEL_LOCK_P() asserts in both scsi and usb code.
with this and other recent fixes i can now "drvctl -d ehci0".
|
|
|
|
|
|
(ya dependencies).
Cleanup usb_mem.c a little more and add block tracking code. Help find
corruption problems.
Comment out the SPEED check for ETTF. XXX why doesn't that work right?
|
|
free the port's subdevice list. This allows for detaching a driver from
a USB device and loading a different one without disconnecting the device.
|
|
kernels.
|