All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: kernel test robot <oliver.sang@intel.com>,
	oe-lkp@lists.linux.dev, lkp@intel.com,
	linux-kernel@vger.kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Ajay Kaher <ajay.kaher@broadcom.com>,
	linux-trace-kernel@vger.kernel.org
Subject: Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address
Date: Tue, 30 Jan 2024 15:04:00 -0500	[thread overview]
Message-ID: <20240130150400.119a3909@gandalf.local.home> (raw)
In-Reply-To: <CAHk-=whMJgqu2v1_Uopg5NBschGFa_BK1Ct=s7ehwnzPpPi6nQ@mail.gmail.com>

On Tue, 30 Jan 2024 11:54:56 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 30 Jan 2024 at 11:37, Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Do you want me to put this in my urgent branch and mark them for stable,
> > and then send them for 6.8?  
> 
> Hmm. I think the only one that fixes a _reported_ bug is that [PTCH
> 2/6]. And it turns out that while 'ti->private' really is entirely
> uninitialized (and I still think it's the cause of the kernel test
> robot report that started this thread), the ti->flags field _is_
> initialized to zero in tracefs_alloc_inode().
> 
> So even in that [PATCH 2/6], these parts:
> 
>   -     ti->flags |= TRACEFS_EVENT_INODE;
>   +     ti->flags = TRACEFS_EVENT_INODE;
> 
> aren't strictly needed (but aren't wrong either).
> 
> The 'make sure to initialize ti->private before exposing the dentry'
> part *definitely* needs to be part of 6.8, though. That has an
> outstanding actually triggered bug report on it.
> 
> I do think that tracefs_alloc_inode() should also initialize
> ti->private to NULL, but while that would fix the oops that the test
> robot reported, it wouldn't fix the data-race on any ti->private
> accesses.
> 
> So that "ti->private = ei" needs to be done before the d_instantiate()
> (that later became a d_add()) regardless. But not having random fields
> left uninitialized for future subtle bugs would be a good idea too.


I'll add a patch to add __GFP_ZERO to the tracefs inode allocation, and
modify your patch 2 to just move the ti->private = ei;


> 
> Anyway.
> 
> If you do run the full tracefs tests on the whole series, and there
> are no other major problems, I'll happily take it all for 6.8. And
> yes, even mark it for stable. I think the other bugs are much harder
> to hit, but I do think they exist. And code deletion is always good.

Sounds good.

> 
> So give it the full test attention, and *if* it all still looks good
> and there are no new subtle issues that crop up, let's just put this
> saga behind us asap.

Yes, I've been wanting to get away from eventfs for a month now.

Again, I really do appreciate the time you put in to fixing this for me.
I'm going to be backporting this to older Chromebooks as we really need to
cut down on the memory overhead of instances.

-- Steve

  reply	other threads:[~2024-01-30 20:03 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-29  2:58 [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address kernel test robot
2024-01-29  4:36 ` Linus Torvalds
2024-01-29 17:01   ` Steven Rostedt
2024-01-29 17:40     ` Linus Torvalds
2024-01-29 17:44       ` Steven Rostedt
2024-01-29 17:45         ` Steven Rostedt
2024-01-29 17:56         ` Linus Torvalds
2024-01-29 17:55       ` Linus Torvalds
2024-01-29 19:24       ` Linus Torvalds
2024-01-29 19:51         ` Linus Torvalds
2024-01-29 20:26           ` Steven Rostedt
2024-01-29 20:51             ` Linus Torvalds
2024-01-29 21:45               ` Steven Rostedt
2024-01-29 22:19                 ` Linus Torvalds
2024-01-29 21:55               ` Steven Rostedt
2024-01-29 22:22               ` Steven Rostedt
2024-01-29 22:35                 ` Linus Torvalds
2024-01-29 22:42                   ` Linus Torvalds
2024-01-29 22:49                     ` Steven Rostedt
2024-01-30  0:01                       ` Linus Torvalds
2024-01-30  0:35                         ` Steven Rostedt
2024-01-30  1:50                           ` Linus Torvalds
2024-01-30  3:56                             ` Linus Torvalds
2024-01-30  8:43                               ` Linus Torvalds
2024-01-30  9:12                                 ` Linus Torvalds
2024-01-30 12:45                                   ` Rasmus Villemoes
2024-01-30 14:39                                   ` Steven Rostedt
2024-01-30 16:49                                     ` Steven Rostedt
2024-01-30 16:55                                       ` Linus Torvalds
2024-01-30 17:06                                         ` Steven Rostedt
2024-01-30 17:09                                         ` Linus Torvalds
2024-01-30 16:51                                     ` Linus Torvalds
2024-01-30 18:23                               ` Steven Rostedt
2024-01-30 19:19                                 ` Linus Torvalds
2024-01-30 19:37                                   ` Steven Rostedt
2024-01-30 19:54                                     ` Linus Torvalds
2024-01-30 20:04                                       ` Steven Rostedt [this message]
2024-01-31 15:58                                       ` Steven Rostedt
2024-01-31 16:13                                         ` Steven Rostedt
2024-01-31 17:28                                           ` Steven Rostedt
2024-01-31 17:26                                         ` Steven Rostedt
2024-01-31 19:35                                         ` Linus Torvalds
2024-01-31 19:42                                           ` Steven Rostedt
2024-01-30 18:36                               ` Steven Rostedt
2024-01-29 22:47                   ` Steven Rostedt
2024-01-29 23:15                     ` Steven Rostedt
2024-01-30  2:08   ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240130150400.119a3909@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=ajay.kaher@broadcom.com \
    --cc=brauner@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.