From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 14:28:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F089106566B; Mon, 8 Nov 2010 14:28:57 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC0C8FC08; Mon, 8 Nov 2010 14:28:56 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA02513; Mon, 08 Nov 2010 16:28:54 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD80926.2010507@freebsd.org> Date: Mon, 08 Nov 2010 16:28:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Nathan Whitehorn 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> In-Reply-To: <4CD80792.7070402@freebsd.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-x11@freebsd.org, freebsd-current@freebsd.org Subject: Re: radeon_cp_texture: page fault with non-sleepable locks held X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 14:28:57 -0000 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