Revert "fs: Do not check if there is a fsnotify watcher on pseudo inodes"
authorMel Gorman <mgorman@techsingularity.net>
Mon, 29 Jun 2020 14:41:45 +0000 (15:41 +0100)
committerLinus Torvalds <torvalds@linux-foundation.org>
Mon, 29 Jun 2020 16:40:55 +0000 (09:40 -0700)
commitb6509f6a8c4313c068c69785c001451415969e44
tree33c9de54d80e0ac86fb8707abaac0a87dece3d19
parent9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68
Revert "fs: Do not check if there is a fsnotify watcher on pseudo inodes"

This reverts commit e9c15badbb7b ("fs: Do not check if there is a
fsnotify watcher on pseudo inodes"). The commit intended to eliminate
fsnotify-related overhead for pseudo inodes but it is broken in
concept. inotify can receive events of pipe files under /proc/X/fd and
chromium relies on close and open events for sandboxing. Maxim Levitsky
reported the following

  Chromium starts as a white rectangle, shows few white rectangles that
  resemble its notifications and then crashes.

  The stdout output from chromium:

  [mlevitsk@starship ~]$chromium-freeworld
  mesa: for the   --simplifycfg-sink-common option: may only occur zero or one times!
  mesa: for the   --global-isel-abort option: may only occur zero or one times!
  [3379:3379:0628/135151.440930:ERROR:browser_switcher_service.cc(238)] XXX Init()
  ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0072
  Received signal 11 SEGV_MAPERR 0000004a9048

Crashes are not universal but even if chromium does not crash, it certainly
does not work properly. While filtering just modify and access might be
safe, the benefit is not worth the risk hence the revert.

Reported-by: Maxim Levitsky <mlevitsk@redhat.com>
Fixes: e9c15badbb7b ("fs: Do not check if there is a fsnotify watcher on pseudo inodes")
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/file_table.c