Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754286Ab0KHN2a (ORCPT ); Mon, 8 Nov 2010 08:28:30 -0500 Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:56482 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753803Ab0KHN23 (ORCPT ); Mon, 8 Nov 2010 08:28:29 -0500 Message-ID: <4CD7FAFD.1060802@fusionio.com> Date: Mon, 08 Nov 2010 14:28:29 +0100 From: Jens Axboe MIME-Version: 1.0 To: "paulmck@linux.vnet.ibm.com" CC: Daniel J Blueman , Linux Kernel Subject: Re: [2.6.37-rc1] sys_ioprio_set and RCU locking... References: <20101107185433.GD15561@linux.vnet.ibm.com> In-Reply-To: <20101107185433.GD15561@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2007 Lines: 77 On 2010-11-07 19:54, Paul E. McKenney wrote: > On Tue, Nov 02, 2010 at 12:15:30PM +0000, Daniel J Blueman wrote: >> With 2.6.37-rc1, I observe sys_ioprio_set not taking the RCU lock [1] >> across access to the task credentials. >> >> Inspecting the code in fs/ioprio.c, the tasklist_lock is held for read >> across the __task_cred call, which is presumably sufficient to prevent >> the task credentials becoming stale. >> >> Thus, is there preference to take the RCU lock for read across the >> credential access eg at [2], or annotate the call? >> >> Thanks, >> Daniel >> >> --- [1] >> >> =================================================== >> >> [ INFO: suspicious rcu_dereference_check() usage. ] >> >> --------------------------------------------------- >> >> kernel/pid.c:419 invoked rcu_dereference_check() without protection! >> >> >> >> other info that might help us debug this: >> >> >> >> >> rcu_scheduler_active = 1, debug_locks = 1 >> >> 1 lock held by start-stop-daem/2246: >> >> #0: (tasklist_lock){.?.?..}, at: [] >> sys_ioprio_set+0x8a/0x400 >> >> >> >> stack backtrace: >> >> Pid: 2246, comm: start-stop-daem Not tainted 2.6.37-rc1-330cd+ #2 >> >> Call Trace: >> >> [] lockdep_rcu_dereference+0xa4/0xc0 >> >> [] find_task_by_pid_ns+0x81/0x90 >> >> [] find_task_by_vpid+0x1d/0x20 >> >> [] sys_ioprio_set+0x3f0/0x400 >> >> [] ? trace_hardirqs_on_thunk+0x3a/0x3f >> >> [] system_call_fastpath+0x16/0x1b >> >> >> --- [2] >> >> Take the RCU lock for read across acquiring the pointer to the task >> credentials and dereferencing it. > > Jens, does this look sane? Yes, looks clean enough to me. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/