From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [RFC PATCH 0/2] Introduce unlocked version of igrab Date: Mon, 28 Mar 2011 17:01:57 +1100 Message-ID: <20110328060157.GA3008@dastard> References: <1301277361-9453-1-git-send-email-ryan@bluewatersys.com> <20110328044334.GA1022@dastard> <4D9012C5.8070401@bluewatersys.com> <4D9016B7.1080505@bluewatersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org, viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org, dchinner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Ryan Mallon Return-path: Content-Disposition: inline In-Reply-To: <4D9016B7.1080505-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org> Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Mar 28, 2011 at 06:03:51PM +1300, Ryan Mallon wrote: > On 03/28/2011 05:47 PM, Ryan Mallon wrote: > > On 03/28/2011 05:43 PM, Dave Chinner wrote: > >> On Mon, Mar 28, 2011 at 02:55:59PM +1300, Ryan Mallon wrote: > >>> Commit 250df6ed274d767da844a5d9f05720b804240197 "fs: protect > >>> inode->i_state with inode->i_lock" introduces a change to igrab to acquire > >>> inode->i_lock. > >>> > >>> This change causes a panic on boot on my ARM EP93xx board when the rootfs > >>> uses NFS. The problem occurs because nfs_inode_add_request acquires > >>> inode->i_lock and then calls igrab, resulting in the following panic: > >>> > >>> BUG: spinlock recursion on CPU#0, getty/262 > >>> lock: cc421cb4, .magic: dead4ead, .owner: getty/262, .owner_cpu: 0 > >>> [] (unwind_backtrace+0x0/0xe4) from [] (do_raw_spin_lock+0x40/0x13c) > >>> [] (do_raw_spin_lock+0x40/0x13c) from [] (igrab+0x14/0x48) > >>> [] (igrab+0x14/0x48) from [] (nfs_updatepage+0x2e0/0x524) > >>> [] (nfs_updatepage+0x2e0/0x524) from [] (nfs_write_end+0x23c/0x270) > >>> [] (nfs_write_end+0x23c/0x270) from [] (generic_file_buffered_write+0x180/0x248) > >>> [] (generic_file_buffered_write+0x180/0x248) from [] (__generic_file_aio_write+0x3b8/0x3f4) > >>> [] (__generic_file_aio_write+0x3b8/0x3f4) from [] (generic_file_aio_write+0x6c/0xdc) > >>> [] (generic_file_aio_write+0x6c/0xdc) from [] (nfs_file_write+0xec/0x178) > >>> [] (nfs_file_write+0xec/0x178) from [] (do_sync_write+0xa4/0xe4) > >>> [] (do_sync_write+0xa4/0xe4) from [] (vfs_write+0xb4/0x12c) > >>> [] (vfs_write+0xb4/0x12c) from [] (sys_write+0x3c/0x68) > >>> [] (sys_write+0x3c/0x68) from [] (ret_fast_syscall+0x0/0x2c) > >>> > >>> This series introduces a new function called __igrab, which is an unlocked > >>> version of igrab and modifies nfs_inode_add_request to use the unlocked > >>> version. > >> It's called ihold() and already exists. > > Thanks. Missed that one. > > > > Is ihold the correct replacement for the fs/ceph cases I mentioned in my > > other email? > > > > ~Ryan > > > > i.e. this: > --- > > fs/ceph: Use ihold instead of igrab when i_lock is already held > > Signed-off-by: Ryan Mallon In essence, yes, though the NFS case (nfs4state.c) also needs the same treatment. I posted a patch that fixes all the cases you reported so you can continue to work without needing Tronnnd's bigger fix for the initial problem. Cheers, Dave. -- Dave Chinner david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html