Messages in this thread | | | Subject | Re: [PATCH] fbmem: copy_from/to_user() with mutex held (v3) | From | Harvey Harrison <> | Date | Tue, 27 Jan 2009 13:29:51 -0800 |
| |
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
| |