On Tue, 26 Feb 2019 13:46:19 +0100 Nicolas Saenz Julienne <nsaenzjulienne@xxxxxxx> wrote: >[...] > > USB and "critical" should never be in the same sentance, without the > > word "not" being in there as well. :) > > Fair enough. It might still annoy someone, which computers were never meant to. > :) I prefer to say "unrecoverable". While a block device may simply retry a write, and nobody notices (unless it's to frequent), it's easily audible (and may be annoying) if a USB sound card skips a frame. > > > I wonder if anyone has been able to log any failure on that area. I was > > > unable > > > to find anything on the relevant bugzillas, nor by talking with some > > > knowledgeable people. Note that some drivers actively protect themselves > > > from > > > URB submission failures, taking care to resubmit them (see usbhid/hid- > > > core.c). > > > > > > Making the allocation fail on some controlled test system seems feasible (it > > > might not be that easy, it really depends on how realistic you want to be). > > > But > > > it might be pointless without a real life failure scenario. > > > > We have the memory allocation fault system, try using that to see how > > well we recover (or not) from such failures. > > You can also inject memory allocation failures with BPF & BCC which is very fun > and easy to use. I've managed to break some drivers as there is a recurring > pattern where they don't try to resubmit a URB once it failed on a completion > routine. > > That said I'm under the impression that there is a huge difference in relevance > between forcing a kmalloc failure on a 512bytes buffer and managing for the > allocator to fail in the wild. Indeed. Since the URB buffer is short-lived, the same slab often gets reused again and again. Of course, it's not too hard to deplete all free objects in the kmalloc-512 slab cache; I can even think of some realistic scenarios. However, if this happens, the slab cache can usually grab a free page even in atomic context. It fails only if the system is either out of memory already, and/or if pages are allocated faster than they can be reclaimed. Now, if my system is in such state, the last thing I'm concerned about is an occasional dropped audio frame... ;-) And that's where we get down to the question of a realistic scenario, I think. Petr T > > Look at how syzbot tested the USB layer, I think they had some > > scripts/programs that got kind of deep into the driver layers for this > > type of testing. > > I'll look into it. > > Thanks, > Nicolas >
Attachment:
pgpVB2QkqqUkp.pgp
Description: Digitálnà podpis OpenPGP
