From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760182AbZBLUIm (ORCPT ); Thu, 12 Feb 2009 15:08:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759080AbZBLUIa (ORCPT ); Thu, 12 Feb 2009 15:08:30 -0500 Received: from gw.goop.org ([64.81.55.164]:57269 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751110AbZBLUI3 (ORCPT ); Thu, 12 Feb 2009 15:08:29 -0500 Message-ID: <499481B9.4090202@goop.org> Date: Thu, 12 Feb 2009 12:08:25 -0800 From: Jeremy Fitzhardinge User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Yinghai Lu CC: Ingo Molnar , the arch/x86 maintainers , Linux Kernel Mailing List Subject: Can request_irq be called under spinlock? X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Relatively recently, I've started seeing this report from my code: BUG: sleeping function called from invalid context at /home/jeremy/git/linux-2.6/mm/slab.c:2982 in_atomic(): 1, irqs_disabled(): 1, pid: 2249, name: xenstored Pid: 2249, comm: xenstored Not tainted 2.6.29-rc4-tip #22 Call Trace: [] __might_sleep+0x113/0x115 [] __kmalloc+0x67/0xe2 [] __proc_create+0x89/0x127 [] ? bind_evtchn_to_cpu+0x4f/0xa0 [] proc_mkdir_mode+0x2e/0x57 [] proc_mkdir+0x16/0x18 [] register_irq_proc+0x74/0xcf [] __setup_irq+0x19b/0x200 [] request_irq+0xd7/0x100 [] ? evtchn_interrupt+0x0/0xc1 [] ? evtchn_interrupt+0x0/0xc1 [] bind_evtchn_to_irqhandler+0x3d/0x5f [] evtchn_bind_to_user+0x54/0x72 [] evtchn_ioctl+0x180/0x39c [] ? __dentry_open+0x1a4/0x2a2 [] ? nameidata_to_filp+0x46/0x57 [] ? pnpacpi_parse_allocated_resource+0x94/0x9b [] ? xen_force_evtchn_callback+0xd/0xf [] vfs_ioctl+0x2f/0x7c [] do_vfs_ioctl+0x4ab/0x503 [] ? __fput+0x1a1/0x1ae [] sys_ioctl+0x47/0x6a [] system_call_fastpath+0x16/0x1b because I'm calling request_irq() while holding a spinlock. request_irq() itself looks like its OK with that (it allocates with GFP_ATOMIC, for example), but __setup_irq -> register_irq_proc -> proc_mkdir ends up doing a GFP_KERNEL allocation, which leads to this message. I can rearrange this code to not do the call under lock, but it seems like there was an unintentional change in API here. Thanks, J