On Friday 15 February 2013 08:53:28 Bjørn Mork wrote:
> Oliver Neukum <[email protected]> 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 stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
