linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>, Jan Kara <jack@suse.cz>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Commit 'fs: Do not check if there is a fsnotify watcher on pseudo inodes' breaks chromium here
Date: Sun, 28 Jun 2020 15:53:51 +0300	[thread overview]
Message-ID: <CAOQ4uxg8E-im=B6L0PQNaTTKdtxVAO=MSJki7kxq875ME4hOLw@mail.gmail.com> (raw)
In-Reply-To: <7b4aa1e985007c6d582fffe5e8435f8153e28e0f.camel@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]

On Sun, Jun 28, 2020 at 2:14 PM Maxim Levitsky <mlevitsk@redhat.com> wrote:
>
> Hi,
>
> I just did usual kernel update and now chromium crashes on startup.
> It happens both in a KVM's VM (with virtio-gpu if that matters) and natively with amdgpu driver.
> Most likely not GPU related although I initially suspected that it is.
>
> Chromium starts as a white rectangle, shows few white rectangles
> that resemble its notifications and then crashes.
>
> The stdout output from chromium:
>
[...]

> Received signal 6
> #0 0x55f6da0120d9 base::debug::CollectStackTrace()
> #1 0x55f6d9f75246 base::debug::StackTrace::StackTrace()
> #2 0x55f6da01170a base::debug::(anonymous namespace)::StackDumpSignalHandler()
> #3 0x55f6da011cfe base::debug::(anonymous namespace)::StackDumpSignalHandler()
> #4 0x7ff46643ab20 (/usr/lib64/libpthread-2.30.so+0x14b1f)
> #5 0x7ff462d87625 __GI_raise
> #6 0x7ff462d708d9 __GI_abort
> #7 0x55f6da0112d5 base::debug::BreakDebugger()
> #8 0x55f6d9f86405 logging::LogMessage::~LogMessage()
> #9 0x55f6d7ed5488 content::(anonymous namespace)::IntentionallyCrashBrowserForUnusableGpuProcess()
> #10 0x55f6d7ed8479 content::GpuDataManagerImplPrivate::FallBackToNextGpuMode()
> #11 0x55f6d7ed4eef content::GpuDataManagerImpl::FallBackToNextGpuMode()
> #12 0x55f6d7ee0f41 content::GpuProcessHost::RecordProcessCrash()
> #13 0x55f6d7ee105d content::GpuProcessHost::OnProcessCrashed()
> #14 0x55f6d7cbe308 content::BrowserChildProcessHostImpl::OnChildDisconnected()
> #15 0x55f6da8b511a IPC::ChannelMojo::OnPipeError()
> #16 0x55f6da13cd62 mojo::InterfaceEndpointClient::NotifyError()
> #17 0x55f6da8c1f9d IPC::(anonymous namespace)::ChannelAssociatedGroupController::OnPipeError()
> #18 0x55f6da138968 mojo::Connector::HandleError()
> #19 0x55f6da15bce7 mojo::SimpleWatcher::OnHandleReady()
> #20 0x55f6da15c0fb mojo::SimpleWatcher::Context::CallNotify()
> #21 0x55f6d78eaa73 mojo::core::WatcherDispatcher::InvokeWatchCallback()
> #22 0x55f6d78ea38f mojo::core::Watch::InvokeCallback()
> #23 0x55f6d78e6efa mojo::core::RequestContext::~RequestContext()
> #24 0x55f6d78db76a mojo::core::NodeChannel::OnChannelError()
> #25 0x55f6d78f232a mojo::core::(anonymous namespace)::ChannelPosix::OnFileCanReadWithoutBlocking()
> #26 0x55f6da03345e base::MessagePumpLibevent::OnLibeventNotification()
> #27 0x55f6da0f9b2d event_base_loop
> #28 0x55f6da03316d base::MessagePumpLibevent::Run()
> #29 0x55f6d9fd79c9 base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run()
> #30 0x55f6d9fada7a base::RunLoop::Run()
> #31 0x55f6d7ce6324 content::BrowserProcessSubThread::IOThreadRun()
> #32 0x55f6d9fe0cb8 base::Thread::ThreadMain()
> #33 0x55f6da024705 base::(anonymous namespace)::ThreadFunc()
> #34 0x7ff46642f4e2 start_thread
> #35 0x7ff462e4c6a3 __GI___clone
>   r8: 0000000000000000  r9: 00007ff44e6a58d0 r10: 0000000000000008 r11: 0000000000000246
>  r12: 00007ff44e6a6b40 r13: 00007ff44e6a6d00 r14: 000000000000006d r15: 00007ff44e6a6b30
>   di: 0000000000000002  si: 00007ff44e6a58d0  bp: 00007ff44e6a5b20  bx: 00007ff44e6a9700
>   dx: 0000000000000000  ax: 0000000000000000  cx: 00007ff462d87625  sp: 00007ff44e6a58d0
>   ip: 00007ff462d87625 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
>  trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
> [end of stack trace]
> Calling _exit(1). Core file will not be generated.
>
>

I guess this answers our question whether we could disable fsnoitfy
watches on pseudo inodes....

From comments like these in chromium code:
https://chromium.googlesource.com/chromium/src/+/master/mojo/core/watcher_dispatcher.cc#77
https://chromium.googlesource.com/chromium/src/+/master/base/files/file_descriptor_watcher_posix.cc#176
https://chromium.googlesource.com/chromium/src/+/master/ipc/ipc_channel_mojo.cc#240

I am taking a wild guess that the missing FS_CLOSE event on anonymous pipes is
the cause for regression.

The motivation for the patch "fs: Do not check if there is a fsnotify
watcher on pseudo inodes"
was performance, but actually, FS_CLOSE and FS_OPEN events probably do
not impact
performance as FS_MODIFY and FS_ACCESS.

Mel,

Do your perf results support the claim above?

Jan/Linus,

Do you agree that dropping FS_MODIFY/FS_ACCESS events for FMODE_STREAM
files as a general rule should be safe?

Maxim, can you try if the attached patch fixes the chromium regression.
It is expected to leave the FS_OPEN/FS_CLOSE events on anonymous pipes
but drop the FS_MODIFY/FS_ACCESS events.

Thanks,
Amir.

[-- Attachment #2: fsnotify-suppress-access-modify-events-on-stream-files.patch.txt --]
[-- Type: text/plain, Size: 1966 bytes --]

From a81c729a5c52ddb2d8d98220478e492b71956574 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il@gmail.com>
Date: Sun, 28 Jun 2020 15:36:56 +0300
Subject: [PATCH] fsnotify: suppress access/modify events on stream files

We wanted to suppress all fsnotify events on anonymous pipes/sockets,
but chromioum seems to be relying on some of those events.

Let's try to suppress only access/modify events on stream files.

Reported-by: Maxim Levitsky <mlevitsk@redhat.com>
Link: https://lore.kernel.org/lkml/7b4aa1e985007c6d582fffe5e8435f8153e28e0f.camel@redhat.com
Fixes: e9c15badbb7b ("fs: Do not check if there is a fsnotify watcher on pseudo inodes")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 fs/file_table.c          | 2 +-
 include/linux/fsnotify.h | 6 ++++++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/fs/file_table.c b/fs/file_table.c
index 65603502fed6..656647f9575a 100644
--- a/fs/file_table.c
+++ b/fs/file_table.c
@@ -230,7 +230,7 @@ struct file *alloc_file_pseudo(struct inode *inode, struct vfsmount *mnt,
 		d_set_d_op(path.dentry, &anon_ops);
 	path.mnt = mntget(mnt);
 	d_instantiate(path.dentry, inode);
-	file = alloc_file(&path, flags | FMODE_NONOTIFY, fops);
+	file = alloc_file(&path, flags, fops);
 	if (IS_ERR(file)) {
 		ihold(inode);
 		path_put(&path);
diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
index 5ab28f6c7d26..3a07824332f5 100644
--- a/include/linux/fsnotify.h
+++ b/include/linux/fsnotify.h
@@ -246,6 +246,9 @@ static inline void fsnotify_rmdir(struct inode *dir, struct dentry *dentry)
  */
 static inline void fsnotify_access(struct file *file)
 {
+	if (file->f_mode & FMODE_STREAM)
+		return 0;
+
 	fsnotify_file(file, FS_ACCESS);
 }
 
@@ -254,6 +257,9 @@ static inline void fsnotify_access(struct file *file)
  */
 static inline void fsnotify_modify(struct file *file)
 {
+	if (file->f_mode & FMODE_STREAM)
+		return 0;
+
 	fsnotify_file(file, FS_MODIFY);
 }
 
-- 
2.17.1


       reply	other threads:[~2020-06-28 12:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7b4aa1e985007c6d582fffe5e8435f8153e28e0f.camel@redhat.com>
2020-06-28 12:53 ` Amir Goldstein [this message]
2020-06-28 13:14   ` Commit 'fs: Do not check if there is a fsnotify watcher on pseudo inodes' breaks chromium here Maxim Levitsky
2020-06-28 13:17     ` Maxim Levitsky
2020-06-28 13:34       ` Amir Goldstein
2020-06-29  9:31         ` Mel Gorman
2020-06-29 13:09   ` Jan Kara
2020-06-29 14:05     ` Amir Goldstein
2020-06-29 14:32       ` Mel Gorman
2020-06-29 14:41       ` [PATCH] Revert "fs: Do not check if there is a fsnotify watcher on pseudo inodes" Mel Gorman
2020-06-29 18:12         ` Jan Kara

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='CAOQ4uxg8E-im=B6L0PQNaTTKdtxVAO=MSJki7kxq875ME4hOLw@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mlevitsk@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).