On Wed, Aug 26, 2020 at 7:10 AM Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote: > > Hello Alex, > > Thanks for the patch. > > On Tue, Aug 25, 2020, 11:56 AM Alexandre Courbot <gnurou@xxxxxxxxx> wrote: > > > > This addresses a very corner case that probably nobody ever encounters, > > but I have hit it when playing with vicoded so here is a tentative fix. > > > > I'll try to make a more complete review soon, but meanwhile > I was thinking if it was possible to include a little kselftest program > for this issue, something CIs can pick-up and test corner cases like this, > making sure we don't regress on the issue. > > (Or alternatively, v4l2-compliance?) I am not very familiar with kselftest, but IIUC the conditions that lead to this issue are easier to reproduce using v4l2-compliance, where we can have a user-space driving the queues. It would also have the benefit to exercise all drivers. I'll think about adding such a test, thanks for the suggestion! > > Thanks! > Ezequiel > > > Patch 1/2 addresses the issue that when the last buffer of a m2m device > > has been dequeued, any attempt to poll with EPOLLOUT will result in only > > EPOLLIN being returned, even if OUTPUT buffers are still pending. The > > issue stems from the fact that the last buffer check if done first, and > > returns immediately if true. > > > > Patch 2/2 builds on the first one to (hopefully) clean up the code a bit > > and make the function flow easier to follow. Functionally speaking it is > > supposed to be a no-op and it can safely be dropped if the former code > > is preferred - the actual fix is in 1/2. > > > > Alexandre Courbot (2): > > media: v4l2-mem2mem: consider OUTPUT queue first when polling > > media: v4l2-mem2mem: simplify poll logic a bit > > > > drivers/media/v4l2-core/v4l2-mem2mem.c | 42 +++++++++++--------------- > > 1 file changed, 18 insertions(+), 24 deletions(-) > > > > -- > > 2.28.0 > >
