From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: [PATCH 1/7 v2] tracefs: Revert ccbd54ff54e8 ("tracefs: Restrict tracefs when the kernel is locked down") Date: Sat, 12 Oct 2019 20:39:22 -0400 Message-ID: <20191012203922.3f29b258@gandalf.local.home> References: <20191012005747.210722465@goodmis.org> <20191012005920.630331484@goodmis.org> <20191012203502.065258d2@gandalf.local.home> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20191012203502.065258d2@gandalf.local.home> Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds Cc: Linux Kernel Mailing List , Ingo Molnar , Andrew Morton , Matthew Garrett , James Morris James Morris , LSM List , Linux API , Ben Hutchings , Al Viro List-Id: linux-api@vger.kernel.org On Sat, 12 Oct 2019 20:35:02 -0400 Steven Rostedt wrote: > On Sat, 12 Oct 2019 15:56:15 -0700 > Linus Torvalds wrote: > > > On Fri, Oct 11, 2019 at 5:59 PM Steven Rostedt wrote: > > > > > > > > > I bisected this down to the addition of the proxy_ops into tracefs for > > > lockdown. It appears that the allocation of the proxy_ops and then freeing > > > it in the destroy_inode callback, is causing havoc with the memory system. > > > Reading the documentation about destroy_inode and talking with Linus about > > > this, this is buggy and wrong. > > > > Can you still add the explanation about the inode memory leak to this message? > > > > Right now it just says "it's buggy and wrong". True. But doesn't > > explain _why_ it is buggy and wrong. > > > > Sure. The patches just finished my testing (along with other fixes that > I need to send you). I have to make a few other updates in the change > log though, so I'll be rebasing them (but not touching the code), to > clean up the change logs. > I updated this change log to state: "I bisected this down to the addition of the proxy_ops into tracefs for lockdown. It appears that the allocation of the proxy_ops and then freeing it in the destroy_inode callback, is causing havoc with the memory system. Reading the documentation about destroy_inode and talking with Linus about this, this is buggy and wrong. When defining the destroy_inode() method, it is expected that the destroy_inode() will also free the inode, and not just the extra allocations done in the creation of the inode. The faulty commit causes a memory leak of the inode data structure when they are deleted." -- Steve