linux-kernel - Re: [PATCH V2 2/2] of: remove /proc/device-tree

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] [day] [month] [year] [list]

Date:	Fri, 15 Nov 2013 16:10:39 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Nathan Fontenot <nfont@...ux.vnet.ibm.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	devicetree-discuss <devicetree-discuss@...ts.ozlabs.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rob Herring <rob.herring@...xeda.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH V2 2/2] of: remove /proc/device-tree

On Fri, 22 Mar 2013 20:29:18 +0100, Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
> On Fri, 2013-03-22 at 13:03 -0500, Nathan Fontenot wrote:
> > We don't ever free old property values, mainly I assume since we don't keep
> > reference counts and can't know when it is safe to do so. The problem I
> > am starting to see on pseries is that we are getting very large properties.
> > One of the biggest culprits is the property on pseries systems to describe
> > the memory on the system in the device tree. These are big and getting
> > bigger as memory increases, additionally this property is update every
> > time memory is DLPAR added or removed from the system which can lead to
> > leaving a bunch of memory that should be free'ed.
> > 
> > Given that, is there (or has there been) any discussion on adding reference
> > counts to properties in the device tree? With the myriad ways to get at
> > the value of a property this may not be feasible but I would like to hear
> > any thoughts from the community.
> 
> My assumption was always that the lifetime of property values is tied
> the the lifetime of the node they are in. IE, we wouldn't free a
> property removed from a node but we could free all properties when
> the node goes away...
> 
> Not the best but would do...

As a middle way, we could modify the property in-place if the size of
the new prop is <= the size of the old. Anyone foresee a problem with
that approach? It could expose race conditions between reading and
writing the new property value into the buffer and updating the length
field.

g.
--
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/