> If anybody else was relying on the driver exceeding the
> maximum allowed bandwidth, wouldn't they run across the same BUG as
> you did?
>
> In which case there wouldn't be any downside to putting your patch in
> the -stable kernels.
>
> Alan Stern
>
Hey,
So it turns out, I wasn't completely
On Wed, 8 Jun 2016, Michał Pecio wrote:
> > The best way to protect against this is to call INIT_LIST_HEAD in
> > ed_alloc() and list_del_init() in finish_unlinks().
>
> This means silently sweeping a whole class of bugs under the rug.
> I wouldn't want to have this in mainline. And as for longte
> If the list pointer contains LIST_POISON then it's already too late;
> we've been accessing memory that was deallocated.
Not really. I figured that LIST_POISON happens if the ED had been
linked and unlinked normally before being submitted abnormally.
And in fact, knowing that, I justs managed t
On Tue, 7 Jun 2016, Michał Pecio wrote:
> > Greg, in principle this should go to -stable. However, it looks like
> > this might break some applications that currently sort-of work, even
> > though they shouldn't. Therefore we have decided not to mark this
> > patch for -stable at present.
>
> Greg, in principle this should go to -stable. However, it looks like
> this might break some applications that currently sort-of work, even
> though they shouldn't. Therefore we have decided not to mark this
> patch for -stable at present.
This means leaving three longterm branches with a k
On Tue, 7 Jun 2016, Michał Pecio wrote:
> Since ed_schedule begins with marking the ED as "operational",
> the ED may be left in such state even if scheduling actually
> fails.
>
> This allows future submission attempts to smuggle this ED to the
> hardware behind the scheduler's back and without
Since ed_schedule begins with marking the ED as "operational",
the ED may be left in such state even if scheduling actually
fails.
This allows future submission attempts to smuggle this ED to the
hardware behind the scheduler's back and without linking it to
the ohci->eds_in_use list.
The former
