From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [RFC] lustre treatment of dentry->d_name Date: Tue, 21 Oct 2014 21:07:42 +0100 Message-ID: <20141021200742.GU7996@ZenIV.linux.org.uk> References: <20141021011346.GP7996@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "linux-fsdevel@vger.kernel.org" , "Dilger, Andreas" , "Hammond, John" To: "Drokin, Oleg" Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:58751 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932627AbaJUUHo (ORCPT ); Tue, 21 Oct 2014 16:07:44 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Oct 21, 2014 at 03:46:02AM +0000, Drokin, Oleg wrote: > Hello! >=20 > On Oct 20, 2014, at 9:13 PM, Al Viro wrote: >=20 > > a) what protects ->d_name in ll_intent_file_open()? It copies > > ->d_name.name and ->d_name.len into local variables and proceeds to > > use those; what's to guarantee that dentry won't get hit with d_mov= e() > > halfway through that? None of the locks that would give an exclusi= on > > against d_move() appear to be held=E2=80=A6 >=20 > You are right. We hit something very similar not too long ago. Umm... While we are at it - what's the story with ll_setxattr() handli= ng of "trusted.lov"? What happens on the protocol level and why do we nee= d a file name for that, while for directories we don't seem to need it? -- 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