[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57A20702.3040805@kyup.com>
Date: Wed, 3 Aug 2016 18:00:18 +0300
From: Nikolay Borisov <kernel@...p.com>
To: Pavel Emelyanov <xemul@...tuozzo.com>,
Nikolay Borisov <kernel@...p.com>,
Jeff Layton <jlayton@...chiereds.net>, bfields@...ldses.org
Cc: Andrey Vagin <avagin@...nvz.org>,
containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, ebiederm@...ssion.com,
linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: [PATCH v2] locks: Filter /proc/locks output on proc pid ns
On 08/03/2016 05:54 PM, Pavel Emelyanov wrote:
> On 08/03/2016 05:17 PM, Nikolay Borisov wrote:
>>
>>
[SNIP]
>>
>> [CCing some people from openvz/CRIU]
>
> Thanks :)
>
>> My train of thought was "we should have means which would be the one
>> universal truth about everything and this would be a process in the
>> init_pid_ns". I don't have strong preference as long as I'm not breaking
>> userspace. As I said before - I think the CRIU guys might be using that
>> interface.
>
> This particular change won't break us mostly because we've switched to
> reading the /proc/pid/fdinfo/n files for locks.
[thinking out loud here]
I've never actually looked into those files but now that I have it seems
to make sense to also switch 'lsof' to actually reading the locks from
the available pids directories rather than relying on the global
/proc/locks interface. Oh well :)
[/thinking out loud here]
>
> -- Pavel
>
>>>
>>>>>> + && (proc_pidns != 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)
>>>
>> .
>>
>
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers
>
Powered by blists - more mailing lists