linux-kernel - Re: [PATCH] locks: export device name

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]

Date:	Wed, 15 Feb 2012 07:42:30 -0500
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Davidlohr Bueso <dave@....org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Wilcox <matthew@....cx>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] locks: export device name

On Wed, Feb 15, 2012 at 11:52:42AM +0100, Davidlohr Bueso wrote:
> On Tue, 2012-02-14 at 14:09 -0500, J. Bruce Fields wrote:
> > On Mon, Feb 13, 2012 at 04:34:25PM -0800, Andrew Morton wrote:
> > > I don't get it.  This is an immediate and non-back-compatible change to
> > > the format of /proc/locks.  The only way this can avoid breaking things
> > > is if there are no programs or scripts in use by anyone which use
> > > this field.  What am I missing here?
> > 
> > I'm a little surprised anything parses that file.
> 
> To my knowledge only lslk - but the whole point here is that its going
> to be replaced by lslocks.
> 
> > 
> > But, yes, looks like I can "yum install" lslk on Fedora 16, as an
> > example.  Can't get it to do anything useful, though.  Does it actually
> > work on any recent distro?
> 
> It works on Ubuntu's latest release.

OK, in that case I'm with Andrew, we'd need to do this more carefully.

People should be able to use something like a recent Ubuntu release to
test more recent kernels, and we don't want their tools to break when we
do that.

> > Perhaps safest would be to replace /proc/locks by another interface and
> > deprecate this one.
> 
> If exporting the name in the current /proc/locks file is out of the
> question, then IMHO I don't think it would be worth adding a new
> interface just for such a small change.

OK.

If you want to just change this over, I guess the thing to do would be
to stick something in feature-removal-schedule.txt saying "we'll switch
this in 2 years" (or however long you think before there are
realistically no more lslk users left), then do it then.

Switching to a new api would be better as we could warn users of the old
api then.  Maybe it'd be worth it if there was some other change we'd
been wanting to make?   Can't think of anything off the top of my head.

We may be adding more lock types--will lslk and lslocks handle that
gracefully?

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/