Date: Mon, 08 Nov 2010 16:28:54 +0200 From: Andriy Gapon <avg@freebsd.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held Message-ID: <4CD80926.2010507@freebsd.org> In-Reply-To: <4CD80792.7070402@freebsd.org> References: <4CD3B1D2.30003@icyb.net.ua> <4CD7E401.1010206@freebsd.org> <20101108120403.GC2392@deviant.kiev.zoral.com.ua> <4CD7F5B9.3010606@freebsd.org> <20101108131620.GG2392@deviant.kiev.zoral.com.ua> <4CD80792.7070402@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 08/11/2010 16:22 Nathan Whitehorn said the following: > > The other issue is that this can be a legal thing to do. If you have taken care to > wire the userland buffers ahead of time, there is no problem copying > copyin()/copyout() with sleepable locks held. The sysctl code does this. As such, > you can't check for problems by panicing if sleepable locks are held. Nathan, very good point, thank you. BTW, perhaps drm should be doing the same? It seems that there are quite a few copyin/copyout calls (disguised with macros) in e.g. sys/dev/drm/radeon_state.c and likely all of them are under dev_lock. So it would be painful to add unlock+lock around each such call. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CD80926.2010507>