Re: [PATCH 1/7 v2] tracefs: Revert ccbd54ff54e8 ("tracefs: Restrict tracefs when the kernel is locked down")

2019-10-12 Thread Steven Rostedt
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

Re: [PATCH 1/7 v2] tracefs: Revert ccbd54ff54e8 ("tracefs: Restrict tracefs when the kernel is locked down")

2019-10-12 Thread Steven Rostedt
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

Re: [PATCH 1/7 v2] tracefs: Revert ccbd54ff54e8 ("tracefs: Restrict tracefs when the kernel is locked down")

2019-10-12 Thread Linus Torvalds
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

[PATCH 1/7 v2] tracefs: Revert ccbd54ff54e8 ("tracefs: Restrict tracefs when the kernel is locked down")

2019-10-11 Thread Steven Rostedt
From: "Steven Rostedt (VMware)" Running the latest kernel through my "make instances" stress tests, I triggered the following bug (with KASAN and kmemleak enabled): mkdir invoked oom-killer: gfp_mask=0x40cd0(GFP_KERNEL|__GFP_COMP|__GFP_RECLAIMABLE), order=0, oom_score_adj=0 CPU: 1 PID: 2229