From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935992AbcHBRlQ (ORCPT ); Tue, 2 Aug 2016 13:41:16 -0400 Received: from fieldses.org ([173.255.197.46]:49766 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935876AbcHBRkH (ORCPT ); Tue, 2 Aug 2016 13:40:07 -0400 Date: Tue, 2 Aug 2016 13:40:03 -0400 From: "J. Bruce Fields" To: "Eric W. Biederman" Cc: Nikolay Borisov , jlayton@poochiereds.net, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, containers@lists.linux-foundation.org, serge.hallyn@canonical.com Subject: Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process Message-ID: <20160802174003.GD11767@fieldses.org> References: <1470148943-21835-1-git-send-email-kernel@kyup.com> <87r3a7qhy0.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r3a7qhy0.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 02, 2016 at 11:00:39AM -0500, Eric W. Biederman wrote: > Nikolay Borisov writes: > > > Currently when /proc/locks is read it will show all the file locks > > which are currently created on the machine. On containers, hosted > > on busy servers this means that doing lsof can be very slow. I > > observed up to 5 seconds stalls reading 50k locks, while the container > > itself had only a small number of relevant entries. Fix it by > > filtering the locks listed by the pidns of the current process > > and the process which created the lock. > > The locks always confuse me so I am not 100% connecting locks > to a pid namespace is appropriate. > > That said if you are going to filter by pid namespace please use the pid > namespace of proc, not the pid namespace of the process reading the > file. Oh, that makes sense, thanks. What does /proc/mounts use, out of curiosity? The mount namespace that /proc was originally mounted in? --b. > > Different contents of files depending on who opens them is generally to > be discouraged. > > Eric > > > Signed-off-by: Nikolay Borisov > > --- > > fs/locks.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/fs/locks.c b/fs/locks.c > > index 6333263b7bc8..53e96df4c583 100644 > > --- a/fs/locks.c > > +++ b/fs/locks.c > > @@ -2615,9 +2615,17 @@ static int locks_show(struct seq_file *f, void *v) > > { > > struct locks_iterator *iter = f->private; > > struct file_lock *fl, *bfl; > > + struct pid_namespace *pid_ns = task_active_pid_ns(current); > > + > > > > fl = hlist_entry(v, struct file_lock, fl_link); > > > > + pr_info ("Current pid_ns: %p init_pid_ns: %p, fl->fl_nspid: %p nspidof:%p\n", pid_ns, &init_pid_ns, > > + fl->fl_nspid, ns_of_pid(fl->fl_nspid)); > > + if ((pid_ns != &init_pid_ns) && fl->fl_nspid && > > + (pid_ns != ns_of_pid(fl->fl_nspid))) > > + return 0; > > + > > lock_get_status(f, fl, iter->li_pos, ""); > > > > list_for_each_entry(bfl, &fl->fl_block, fl_block)