On Friday 15 February 2013 08:53:28 Bjørn Mork wrote: > Oliver Neukum <oliver@xxxxxxxxxx> writes: > > We have to let user space recover. To do so we need to indicate when > > exactly we dropped data. > > The problem with that is that this is likely to happen when a client > just doesn't care. It will just continue happily ignoring the read data, > writing new commands or whatever. Then the *next* client opening the > file for reading will see this error. Well, this may be a separate bug. Should the buffer be cleared when we run out of openers? > Sorry, but I find that still too fragile. To know whether this solves > the problem I will have to check every possible site where desc->rerr > can be reset, including those we may add in the future. I trust that But clearing desc->rerr without at least clearing the buffer is a bug. But we can have a separate flag. > you have verified that this works now, but it is still too easy to break > without noticing. > > There should be an explicit test for buffer space here. Indirect > testing via some other variable is risky IMHO. Very well. Was the initial assumption that a single response cannot be longer than wMaxCommand valid in practice? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
