lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160803150631.GA3789@fieldses.org>
Date:	Wed, 3 Aug 2016 11:06:31 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Nikolay Borisov <kernel@...p.com>
Cc:	Pavel Emelyanov <xemul@...tuozzo.com>,
	Jeff Layton <jlayton@...chiereds.net>,
	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 Wed, Aug 03, 2016 at 06:00:18PM +0300, Nikolay Borisov wrote:
> 
> 
> 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 :)

Digging around...  Oh, I see, there's an optional 'lock:..' line in
/proc/[pid]/fdinfo/[pid] file, is that what you're looking at?  I'd
forgotten.  Yeah, maybe that would make more sense long term.

--b.

> 
> [/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

Powered by Openwall GNU/*/Linux Powered by OpenVZ