linux-kernel - Re: [PATCH v2 02/10] media-request: Add a request complete operation to allow m2m scheduling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Apr 2018 07:38:57 +0000
From:   Alexandre Courbot <acourbot@...omium.org>
To:     Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc:     Linux Media Mailing List <linux-media@...r.kernel.org>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        LKML <linux-kernel@...r.kernel.org>,
        linux-sunxi@...glegroups.com,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        robh+dt@...nel.org, mark.rutland@....com,
        Maxime Ripard <maxime.ripard@...tlin.com>, wens@...e.org,
        Pawel Osciak <pawel@...iak.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        kyungmin.park@...sung.com, Hans Verkuil <hans.verkuil@...co.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        p.zabel@...gutronix.de, arnd@...db.de,
        Tomasz Figa <tfiga@...omium.org>
Subject: Re: [PATCH v2 02/10] media-request: Add a request complete operation
 to allow m2m scheduling

On Fri, Apr 20, 2018 at 12:43 AM Paul Kocialkowski <
paul.kocialkowski@...tlin.com> wrote:

> When using the request API in the context of a m2m driver, the
> operations that come with a m2m run scheduling call in their
> (m2m-specific) ioctl handler are delayed until the request is queued
> (for instance, this includes queuing buffers and streamon).

> Thus, the m2m run scheduling calls are not called in due time since the
> request AP's internal plumbing will (rightfully) use the relevant core
> functions directly instead of the ioctl handler.

> This ends up in a situation where nothing happens if there is no
> run-scheduling ioctl called after queuing the request.

> In order to circumvent the issue, a new media operation is introduced,
> called at the time of handling the media request queue ioctl. It gives
> m2m drivers a chance to schedule a m2m device run at that time.

> The existing req_queue operation cannot be used for this purpose, since
> it is called with the request queue mutex held, that is eventually needed
> in the device_run call to apply relevant controls.

> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@...tlin.com>
> ---
>   drivers/media/media-request.c | 3 +++
>   include/media/media-device.h  | 2 ++
>   2 files changed, 5 insertions(+)

> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
> index 415f7e31019d..28ac5ccfe6a2 100644
> --- a/drivers/media/media-request.c
> +++ b/drivers/media/media-request.c
> @@ -157,6 +157,9 @@ static long media_request_ioctl_queue(struct
media_request *req)
>                  media_request_get(req);
>          }

> +       if (mdev->ops->req_complete)
> +               mdev->ops->req_complete(req);
> +
>          return ret;
>   }

> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 07e323c57202..c7dcf2079cc9 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -55,6 +55,7 @@ struct media_entity_notify {
>    * @req_alloc: Allocate a request
>    * @req_free: Free a request
>    * @req_queue: Queue a request
> + * @req_complete: Complete a request
>    */
>   struct media_device_ops {
>          int (*link_notify)(struct media_link *link, u32 flags,
> @@ -62,6 +63,7 @@ struct media_device_ops {
>          struct media_request *(*req_alloc)(struct media_device *mdev);
>          void (*req_free)(struct media_request *req);
>          int (*req_queue)(struct media_request *req);
> +       void (*req_complete)(struct media_request *req);

This is called *before* the request is actually run, isn't it? In that
case, wouldn't something like "req_schedule" be less confusing?
req_complete implies that the request is already completed.