From: "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
To: Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org>
Cc: serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jlayton-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org
Subject: Re: [RFC PATCH] locks: Show only file_locks created in the same pidns as current process
Date: Tue, 2 Aug 2016 11:43:30 -0400 [thread overview]
Message-ID: <20160802154330.GC11767@fieldses.org> (raw)
In-Reply-To: <57A0BA40.5010406-6AxghH7DbtA@public.gmane.org>
On Tue, Aug 02, 2016 at 06:20:32PM +0300, Nikolay Borisov wrote:
> On 08/02/2016 06:05 PM, J. Bruce Fields wrote:
> > (And what process was actually reading /proc/locks, out of curiosity?)
>
> lsof in my case
Oh, thanks, and you said that at the start, and I overlooked
it--apologies.
> >> 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.
> >
> > Thanks, that's interesting. So you show a lock if it was created by
> > someone in the current pid namespace. With a special exception for the
> > init namespace so that
>
> I admit this is a rather naive approach. Something else I was pondering was
> checking whether the user_ns of the lock's creator pidns is the same as the
> reader's user_ns. That should potentially solve your concerns re.
> shared filesystems, no? Or whether the reader's userns is an ancestor
> of the user'ns of the creator's pidns? Maybe Eric can elaborate whether
> this would make sense?
If I could just imagine myself king of the world for a moment--I wish I
could have an interface that took a path or a filehandle and gave back a
list of locks on the associated filesystem. Then if lsof wanted a
global list, it would go through /proc/mounts and request the list of
locks for each filesystem.
For /proc/locks it might be nice if we could restrict to locks on
filesystem that are somehow visible to the current process, but I don't
know if there's a simple way to do that.
--b.
>
> >
> > If a filesystem is shared between containers that means you won't
> > necessarily be able to figure out from within a container which lock is
> > conflicting with your lock. (I don't know if that's really a problem.
> > I'm unfortunately short on evidence aobut what people actually use
> > /proc/locks for....)
> >
> > --b.
> >
> >>
> >> Signed-off-by: Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org>
> >> ---
> >> 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)
> >> --
> >> 2.5.0
next prev parent reply other threads:[~2016-08-02 15:43 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 14:42 [RFC PATCH] locks: Show only file_locks created in the same pidns as current process Nikolay Borisov
[not found] ` <20160802150521.GB11767@fieldses.org>
[not found] ` <20160802150521.GB11767-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2016-08-02 15:20 ` Nikolay Borisov
[not found] ` <57A0BA40.5010406-6AxghH7DbtA@public.gmane.org>
2016-08-02 15:43 ` J. Bruce Fields [this message]
[not found] ` <1470148943-21835-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2016-08-02 14:45 ` Nikolay Borisov
2016-08-02 15:05 ` J. Bruce Fields
2016-08-02 16:00 ` Eric W. Biederman
[not found] ` <87r3a7qhy0.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-08-02 17:40 ` J. Bruce Fields
[not found] ` <20160802174003.GD11767-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2016-08-02 19:09 ` Eric W. Biederman
[not found] ` <87invjq97h.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-08-02 19:44 ` J. Bruce Fields
[not found] ` <20160802194437.GD15324-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2016-08-02 20:01 ` Jeff Layton
[not found] ` <1470168082.15226.14.camel-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>
2016-08-02 20:11 ` Nikolay Borisov
2016-08-02 20:34 ` J. Bruce Fields
2016-08-03 7:35 ` [PATCH v2] locks: Filter /proc/locks output on proc pid ns Nikolay Borisov
[not found] ` <1470209710-30022-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2016-08-03 13:46 ` Jeff Layton
[not found] ` <1470232012.18285.4.camel-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>
2016-08-03 14:17 ` Nikolay Borisov
[not found] ` <57A1FCE5.3040206-6AxghH7DbtA@public.gmane.org>
2016-08-03 14:28 ` J. Bruce Fields
2016-08-03 14:54 ` Pavel Emelyanov
[not found] ` <57A205BE.3070202-5HdwGun5lf+gSpxsJD1C4w@public.gmane.org>
2016-08-03 15:00 ` Nikolay Borisov
[not found] ` <57A20702.3040805@kyup.com>
[not found] ` <57A20702.3040805-6AxghH7DbtA@public.gmane.org>
2016-08-03 15:06 ` J. Bruce Fields
[not found] ` <20160803150631.GA3789-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2016-08-03 15:10 ` Nikolay Borisov
[not found] ` <57A2097C.7060206-6AxghH7DbtA@public.gmane.org>
2016-08-03 17:35 ` Eric W. Biederman
[not found] ` <20160803142850.GA27072@fieldses.org>
[not found] ` <20160803142850.GA27072-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
2016-08-03 14:33 ` Nikolay Borisov
2016-08-03 14:54 ` [PATCHv3] " Nikolay Borisov
[not found] ` <1470236078-2389-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2016-08-03 15:24 ` Jeff Layton
2016-08-03 16:23 ` Eric W. Biederman
[not found] ` <87k2fxom8a.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-08-03 16:50 ` Jeff Layton
[not found] ` <1470243015.13804.7.camel-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>
2016-08-03 21:09 ` Eric W. Biederman
[not found] ` <87twf1ftk9.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-08-03 21:26 ` Nikolay Borisov
[not found] ` <a0a58f75-0e40-c14f-d8e3-8f094e9fc62c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-04 4:18 ` Eric W. Biederman
[not found] ` <87eg659ngh.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-08-04 5:07 ` Eric W. Biederman
2016-08-03 17:40 ` Eric W. Biederman
2016-08-04 7:26 ` [PATCHv4] " Nikolay Borisov
[not found] ` <1470295588-9803-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2016-08-04 11:29 ` Jeff Layton
[not found] ` <1470310175.22052.3.camel-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>
2016-08-04 14:09 ` Eric W. Biederman
[not found] ` <874m707hhm.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-08-04 14:34 ` Nikolay Borisov
2016-08-04 15:09 ` Nikolay Borisov
[not found] ` <57A35AC7.7040105-6AxghH7DbtA@public.gmane.org>
2016-08-04 15:21 ` Eric W. Biederman
2016-08-05 7:30 ` [PATCHv5] " Nikolay Borisov
[not found] ` <1470382204-21480-1-git-send-email-kernel-6AxghH7DbtA@public.gmane.org>
2016-08-05 10:47 ` Jeff Layton
[not found] ` <1470394036.8100.2.camel-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>
2016-08-05 14:58 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160802154330.GC11767@fieldses.org \
--to=bfields-uc3wqj2krung9huczpvpmw@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=jlayton-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org \
--cc=kernel-6AxghH7DbtA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox