[PATCH] [drivers/video/fb] Eliminate recursive mutex in compat fb ioctl path - Kernel

This is a discussion on [PATCH] [drivers/video/fb] Eliminate recursive mutex in compat fb ioctl path - Kernel ; fb_compat_ioctl grabbed the fb mutex and then called fb_ioctl, which also grabs the same mutex. I traced through all existing fb_compat_ioctl functions in the various fb drivers and found that they also transform their arguments and call the native fb_ioctl ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: [PATCH] [drivers/video/fb] Eliminate recursive mutex in compat fb ioctl path

  1. [PATCH] [drivers/video/fb] Eliminate recursive mutex in compat fb ioctl path

    fb_compat_ioctl grabbed the fb mutex and then called fb_ioctl, which also
    grabs the same mutex. I traced through all existing fb_compat_ioctl
    functions in the various fb drivers and found that they also transform their
    arguments and call the native fb_ioctl function. So, it is correct to just
    remove the mutex_lock/mutex_unlock pair in the top-level compat path.

    Signed-off-by: Keith Packard
    ---
    drivers/video/fbmem.c | 2 --
    1 files changed, 0 insertions(+), 2 deletions(-)

    diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
    index cd5f20d..548cf26 100644
    --- a/drivers/video/fbmem.c
    +++ b/drivers/video/fbmem.c
    @@ -1253,7 +1253,6 @@ fb_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
    struct fb_ops *fb = info->fbops;
    long ret = -ENOIOCTLCMD;

    - mutex_lock(&info->lock);
    switch(cmd) {
    case FBIOGET_VSCREENINFO:
    case FBIOPUT_VSCREENINFO:
    @@ -1279,7 +1278,6 @@ fb_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
    ret = fb->fb_compat_ioctl(info, cmd, arg);
    break;
    }
    - mutex_unlock(&info->lock);
    return ret;
    }
    #endif
    --
    1.5.6.5

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] [drivers/video/fb] Eliminate recursive mutex in compat fb ioctl path

    On Sun, 2 Nov 2008, Keith Packard wrote:
    > fb_compat_ioctl grabbed the fb mutex and then called fb_ioctl, which also
    > grabs the same mutex. I traced through all existing fb_compat_ioctl
    > functions in the various fb drivers and found that they also transform their
    > arguments and call the native fb_ioctl function. So, it is correct to just
    > remove the mutex_lock/mutex_unlock pair in the top-level compat path.


    Last week I submitted an alternative fix: http://lkml.org/lkml/2008/10/31/162

    Probably Rafael wants to keep track of this regression, too?

    > Signed-off-by: Keith Packard
    > ---
    > drivers/video/fbmem.c | 2 --
    > 1 files changed, 0 insertions(+), 2 deletions(-)
    >
    > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
    > index cd5f20d..548cf26 100644
    > --- a/drivers/video/fbmem.c
    > +++ b/drivers/video/fbmem.c
    > @@ -1253,7 +1253,6 @@ fb_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
    > struct fb_ops *fb = info->fbops;
    > long ret = -ENOIOCTLCMD;
    >
    > - mutex_lock(&info->lock);
    > switch(cmd) {
    > case FBIOGET_VSCREENINFO:
    > case FBIOPUT_VSCREENINFO:
    > @@ -1279,7 +1278,6 @@ fb_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
    > ret = fb->fb_compat_ioctl(info, cmd, arg);
    > break;
    > }
    > - mutex_unlock(&info->lock);
    > return ret;
    > }
    > #endif


    With kind regards,

    Geert Uytterhoeven
    Software Architect

    Sony Techsoft Centre Europe
    The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

    Phone: +32 (0)2 700 8453
    Fax: +32 (0)2 700 8622
    E-mail: Geert.Uytterhoeven@sonycom.com
    Internet: http://www.sony-europe.com/

    A division of Sony Europe (Belgium) N.V.
    VAT BE 0413.825.160 · RPR Brussels
    Fortis · BIC GEBABEBB · IBAN BE41293037680010

+ Reply to Thread