From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754653AbbGIVlz (ORCPT ); Thu, 9 Jul 2015 17:41:55 -0400 Received: from mail-yk0-f178.google.com ([209.85.160.178]:33160 "EHLO mail-yk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753905AbbGIVlp (ORCPT ); Thu, 9 Jul 2015 17:41:45 -0400 Date: Thu, 9 Jul 2015 17:41:43 -0400 From: Tejun Heo To: Nikolay Borisov Cc: Greg Kroah-Hartman , axboe@kernel.dk, jack@suse.cz, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 4/5] kernfs: implement kernfs_path_len() Message-ID: <20150709214143.GD18734@mtj.duckdns.org> References: <1436281823-1947-1-git-send-email-tj@kernel.org> <1436281823-1947-5-git-send-email-tj@kernel.org> <559CDA8B.6040909@siteground.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559CDA8B.6040909@siteground.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Nioklay. I restored the cc list. Please use reply-to-all. On Wed, Jul 08, 2015 at 11:08:43AM +0300, Nikolay Borisov wrote: > > +size_t kernfs_path_len(struct kernfs_node *kn) > > +{ > > + size_t len = 0; > > + unsigned long flags; > > + > > + spin_lock_irqsave(&kernfs_rename_lock, flags); > > + > > + do { > > + len += strlen(kn->name) + 1; > > + kn = kn->parent; > > + } while (kn && kn->parent); > > + > > + spin_unlock_irqrestore(&kernfs_rename_lock, flags); > > + > > + return len; > > +} > > + > > Can you explain the reason why you need to disable the irqs while > executing this function? Presumably it has to do with the context of its > usage - tracepoints but I wasn't able to find any information about the > implications of interrupts being enabled while in a trace point? It doesn't have much to do with the specific usage. kernfs_rename_lock is irq-safe because we want to be able to call functions like kernfs_name() and kernfs_path() regardless of the current context. Thanks. -- tejun