All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harvey Harrison <harvey.harrison@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrea Righi <righi.andrea@gmail.com>,
	hannes@cmpxchg.org, davej@redhat.com, rjw@sisk.pl,
	hannes@saeurebad.de, krzysztof.h1@wp.pl,
	stefanr@s5r6.in-berlin.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fbmem: copy_from/to_user() with mutex held (v3)
Date: Tue, 27 Jan 2009 13:29:51 -0800	[thread overview]
Message-ID: <1233091791.6717.3.camel@brick> (raw)
In-Reply-To: <20090127125255.ea9c0d40.akpm@linux-foundation.org>

On Tue, 2009-01-27 at 12:52 -0800, Andrew Morton wrote:
> On Tue, 20 Jan 2009 10:27:56 +0100
> Andrea Righi <righi.andrea@gmail.com> wrote:
> 
> > Avoid to call copy_from/to_user() with fb_info->lock mutex held in fbmem
> > ioctl().
> > 
> > fb_mmap() is called under mm->mmap_sem (A) held, that also acquires
> > fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does
> > copy_from/to_user() that might acquire mm->mmap_sem (A), causing a
> > deadlock.
> > 
> > NOTE: it doesn't push down the fb_info->lock in each own driver's
> > fb_ioctl(), so there're still potential deadlocks somewhere.
> > 
> 
> Looks good to me.
> 
> > ...
> >
> >  static long fb_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> > -__acquires(&info->lock)
> > -__releases(&info->lock)
> 
> Should the __acquires/__releases annotation be relocated to
> do_fb_ioctl()?  I've never actually got down and understood those
> things.
> 
> 

There's not really any point as the way lock_fb_info is done, it's essentially
impossible to annotate properly.  You could look at how spin_trylock is done,
but it will require a wrapping macro.  As I suggested the first time this
was posted.

Harvey




      reply	other threads:[~2009-01-27 21:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-20  9:27 [PATCH] fbmem: copy_from/to_user() with mutex held (v3) Andrea Righi
2009-01-27 20:52 ` Andrew Morton
2009-01-27 21:29   ` Harvey Harrison [this message]

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=1233091791.6717.3.camel@brick \
    --to=harvey.harrison@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=hannes@saeurebad.de \
    --cc=krzysztof.h1@wp.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=righi.andrea@gmail.com \
    --cc=rjw@sisk.pl \
    --cc=stefanr@s5r6.in-berlin.de \
    /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.