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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201008111449.48141.arnd@arndb.de>
Date:	Wed, 11 Aug 2010 14:49:47 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Dave Airlie <airlied@...il.com>
Cc:	Luca Tettamanti <kronos.it@...il.com>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.sourceforge.net
Subject: Re: [DRM] BUG: sleeping function called from invalid context, drm_lastclose

On Wednesday 11 August 2010, Dave Airlie wrote:
> On Wed, Aug 11, 2010 at 6:48 PM, Luca Tettamanti <kronos.it@...il.com> wrote:
> >
> >
> > moved the call to (inside drm_release) drm_lastclose inside dev->count_lock
> > spinlock.
> > drm_lastclose however takes dev->struct_mutex (now inside an atomic
> > context):

Yes, that's obviously been broken by me, sorry about the trouble.

I must have been trying to simplify the error handling by adding a
goto at the end of drm_release, which then happened to break
the common path.

The easiest way to fix this would be to go back to the way drm_release()
worked previously and /only/ replace {,un}lock_kernel() with
mutex_{,un}lock(&drm_global_mutex);.

> I have a patch from Chris Wilson that I need to push to fix this,
> basically reducing the spin lock coverage,
> and relying on the global mutex to handle the open race.

Yes, that sounds good, it's what the code used to do before my broken
change.

You might also be able to find a way to remove drm_global_lock from the
open/close path entirely.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ