All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Herrmann <dh.herrmann@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 08/11] drm: Enforce unlocked ioctl operation for kms driver ioctls
Date: Mon, 28 Sep 2015 17:21:17 +0200	[thread overview]
Message-ID: <CANq1E4TNWZE3fdJM2UicNYMZas7CSoY0C0AtkwSLuyq5me5=AQ@mail.gmail.com> (raw)
In-Reply-To: <1441713391-24732-9-git-send-email-daniel.vetter@ffwll.ch>

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> With the prep patches for i915 all kms drivers either have
> DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
> with an invariant return value when in modeset mode. But that's only
> the case for i915 and radeon. The drm core ioctls are unfortunately
> too much a mess still to dare this.
>
> Follow-up patches will remove DRM_UNLOCKED from all kms drivers to
> prove that this is indeed the case.
>
> Also update the documentation.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm_setclientcap() should probably lock _something_. It's not very
crucial, but I think we should guarantee consistency when setting
multiple values. struct_mutex of the corresponding DRM device sounds
sufficient, though not very promising. But drm_file doesn't have any
suitable lock..

drm_setversion(): This definitely needs _some_ lock. DRM_MASTER is not
reliable (we never merged the master-reliability patches).

...skipping review of the other ioctls...
...re-reading patch description...

So this patch is just meant to drop DRM_UNLOCKED from driver-ioctls,
right? See below.

> ---
>  Documentation/DocBook/drm.tmpl | 4 +++-
>  drivers/gpu/drm/drm_ioctl.c    | 6 +++++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index cfb43203a6a7..55dc106686df 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3747,7 +3747,9 @@ int num_ioctls;</synopsis>
>             </para></listitem>
>              <listitem><para>
>               DRM_UNLOCKED - The ioctl handler will be called without locking
> -             the DRM global mutex
> +             the DRM global mutex. This is the enforced default for kms drivers
> +             (i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
> +             any more for new drivers.
>             </para></listitem>
>           </itemizedlist>
>         </para>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 75df8ea87cd7..a5a4aa89b1b4 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -728,6 +728,7 @@ long drm_ioctl(struct file *filp,
>         }
>
>         retcode = drm_ioctl_permit(ioctl->flags, file_priv);
> +

Weird new-line. I actually prefer the previous style, anyway.

>         if (unlikely(retcode))
>                 goto err_i1;
>
> @@ -755,7 +756,10 @@ long drm_ioctl(struct file *filp,
>                 memset(kdata, 0, usize);
>         }
>
> -       if (ioctl->flags & DRM_UNLOCKED)
> +       /* Enforce sane locking for kms driver ioctls. Core ioctls are
> +        * too messy still. */
> +       if (drm_core_check_feature(dev, DRIVER_MODESET) ||
> +           (ioctl->flags & DRM_UNLOCKED))
>                 retcode = func(dev, kdata, file_priv);

This looks.. weird. Now we *never* lock *anything* for MODESET
drivers? This contradicts your commit-message, which rather tells me
you want _driver_ ioctls of modeset drivers to never rely on
drm_global_mutex. Several ways to make that work (and I'd review it
gladly), but this looks.. weird.

Care to elaborate?

Thanks
David

>         else {
>                 mutex_lock(&drm_global_mutex);
> --
> 2.5.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2015-09-28 15:21 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08 11:56 [PATCH 00/11] Mixed bag of ioctl and agp cleanups Daniel Vetter
2015-09-08 11:56 ` [PATCH 01/11] drm: Remove __OS_HAS_AGP Daniel Vetter
2015-09-09 12:53   ` Ville Syrjälä
2015-09-09 14:45   ` [PATCH] " Daniel Vetter
2015-09-28 15:05     ` David Herrmann
2015-09-08 11:56 ` [PATCH 02/11] drm/i915: Kill cross-module option depencies Daniel Vetter
2015-09-08 11:56 ` [PATCH 03/11] drm/i915: Mark debug mod options as _unsafe Daniel Vetter
2015-09-22  9:34   ` Jani Nikula
2015-09-22  9:54     ` Daniel Vetter
2015-09-08 11:56 ` [PATCH 04/11] drm/i915: Remove setparam ioctl Daniel Vetter
2015-09-09 13:02   ` Ville Syrjälä
2015-09-09 14:46   ` [PATCH] drm/i915: Mark getparam ioctl as DRM_UNLOCKED Daniel Vetter
2015-09-30  8:46   ` [PATCH] drm/i915: Remove setparam ioctl Daniel Vetter
2015-09-30  8:50     ` Chris Wilson
2015-09-30 13:40     ` Ville Syrjälä
2015-09-08 11:56 ` [PATCH 05/11] drm/i915: Mark getparam ioctl as DRM_UNLOCKED Daniel Vetter
2015-10-09 10:00   ` Chris Wilson
2015-09-08 11:56 ` [PATCH 06/11] drm: Define a drm_invalid_op ioctl implementation Daniel Vetter
2015-09-09 12:28   ` David Herrmann
2015-09-08 11:56 ` [PATCH 07/11] drm/drm_ioctl.c: kerneldoc Daniel Vetter
2015-09-28 15:07   ` David Herrmann
2015-09-08 11:56 ` [PATCH 08/11] drm: Enforce unlocked ioctl operation for kms driver ioctls Daniel Vetter
2015-09-08 18:45   ` Gustavo Padovan
2015-09-28 15:21   ` David Herrmann [this message]
2015-09-28 19:42   ` [PATCH] " Daniel Vetter
2015-09-08 11:56 ` [PATCH 09/11] drm/vmwgfx: Stop checking for DRM_UNLOCKED Daniel Vetter
2015-09-28 15:22   ` David Herrmann
2015-09-08 11:56 ` [PATCH 10/11] drm/<drivers>: Drop DRM_UNLOCKED from modeset drivers Daniel Vetter
2015-09-08 18:46   ` [Intel-gfx] " Gustavo Padovan
2015-09-28 15:24   ` David Herrmann
2015-09-08 11:56 ` [PATCH 11/11] drm: Remove dummy agp ioctl wrappers Daniel Vetter
2015-09-28 15:25   ` David Herrmann
2015-09-08 12:58 ` [PATCH 00/11] Mixed bag of ioctl and agp cleanups Christian König
2015-10-08 17:01   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANq1E4TNWZE3fdJM2UicNYMZas7CSoY0C0AtkwSLuyq5me5=AQ@mail.gmail.com' \
    --to=dh.herrmann@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.