From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755870Ab1AKM51 (ORCPT ); Tue, 11 Jan 2011 07:57:27 -0500 Received: from mail-ww0-f44.google.com ([74.125.82.44]:36004 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753540Ab1AKM5Y convert rfc822-to-8bit (ORCPT ); Tue, 11 Jan 2011 07:57:24 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kxoXIuTNuESuu7PojRM9YapYAOGcNiTGV4ApDm7QhymcqsqA12HHe5podpO8XBss1I 0Cvy31ij7VMEzTZWxMrRpmmnsy0NisKZc0pznln804BxrvqHTHedT7xDmnqXPjoJwxE2 PPOm/FRCudZhTHD0IkzMTY52PZKrf3Mp/x4S0= MIME-Version: 1.0 In-Reply-To: <22537.1294670327@jrobl> References: <22537.1294670327@jrobl> Date: Tue, 11 Jan 2011 23:57:22 +1100 Message-ID: Subject: Re: Important for fs devs: rcu-walk merged upstream From: Nick Piggin To: "J. R. Okajima" Cc: linux-fsdevel , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, January 11, 2011, J. R. Okajima wrote: > > Nick Piggin: >> This is a big and complex change by any measure, so >> please don't be afraid to ask for help or clarification. I'd >> also really like to be able to update documentation >> based on questions from fs maintainers (in and out of >> tree) who are trying to follow it and bring their code up to >> speed. > > Question about what d_lock protects. > Can we skip d_lock when we access d_inode and d_name during its parent > i_mutex is held? That is a good observation. I think we are ok here because parent mutex should stabilize children names and linkages. But the documentation for a lot of locking is not complete. It would be nice to improve. > Should these BUG_ON be placed after d_lock? > > void dentry_update_name_case(struct dentry *dentry, struct qstr *name) > { >        BUG_ON(!mutex_is_locked(&dentry->d_inode->i_mutex)); >        BUG_ON(dentry->d_name.len != name->len); /* d_lookup gives this */ > >        spin_lock(&dentry->d_lock); >        ::: > > > J. R. Okajima > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: Important for fs devs: rcu-walk merged upstream Date: Tue, 11 Jan 2011 23:57:22 +1100 Message-ID: References: <22537.1294670327@jrobl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel , "linux-kernel@vger.kernel.org" To: "J. R. Okajima" Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:36004 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753540Ab1AKM5Y convert rfc822-to-8bit (ORCPT ); Tue, 11 Jan 2011 07:57:24 -0500 In-Reply-To: <22537.1294670327@jrobl> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tuesday, January 11, 2011, J. R. Okajima wro= te: > > Nick Piggin: >> This is a big and complex change by any measure, so >> please don't be afraid to ask for help or clarification. I'd >> also really like to be able to update documentation >> based on questions from fs maintainers (in and out of >> tree) who are trying to follow it and bring their code up to >> speed. > > Question about what d_lock protects. > Can we skip d_lock when we access d_inode and d_name during its paren= t > i_mutex is held? That is a good observation. I think we are ok here because parent mutex should stabilize children names and linkages. But the documentation for a lot of locking is not complete. It would be nice to improve. > Should these BUG_ON be placed after d_lock? > > void dentry_update_name_case(struct dentry *dentry, struct qstr *name= ) > { > =A0 =A0 =A0 =A0BUG_ON(!mutex_is_locked(&dentry->d_inode->i_mutex)); > =A0 =A0 =A0 =A0BUG_ON(dentry->d_name.len !=3D name->len); /* d_looku= p gives this */ > > =A0 =A0 =A0 =A0spin_lock(&dentry->d_lock); > =A0 =A0 =A0 =A0::: > > > J. R. Okajima > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html