group.of.nepali.translators team mailing list archive

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

** Also affects: linux (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
       Status: New

** Also affects: linux-azure (Ubuntu Artful)
   Importance: Undecided
       Status: New

** Changed in: linux (Ubuntu Xenial)
       Status: New => Invalid

** Changed in: linux-azure (Ubuntu Artful)
       Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1765564

Title:
  fsnotify: Fix fsnotify_mark_connector race

Status in Linux:
  Incomplete
Status in linux package in Ubuntu:
  New
Status in linux-azure package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux source package in Artful:
  Incomplete
Status in linux-azure source package in Artful:
  Invalid
Status in linux source package in Bionic:
  Incomplete
Status in linux-azure source package in Bionic:
  Fix Released

Bug description:
  On Azure we have had sporadic cases of soft lockups in fsnotify that
  may very well be mitigated by the following fix. The LKML thread is
  "kernel panics with 4.14.X".

  This should be applied to 4.13 and 4.15 versions of the linux-azure
  kernel, and possibly the 4.15 generic kernel in bionic as well.

  -----

  fsnotify() acquires a reference to a fsnotify_mark_connector through
  the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it
  appears that no precautions are taken in fsnotify_put_mark() to
  ensure that fsnotify() drops its reference to this
  fsnotify_mark_connector before assigning a value to its 'destroy_next'
  field. This can result in fsnotify_put_mark() assigning a value
  to a connector's 'destroy_next' field right before fsnotify() tries to
  traverse the linked list referenced by the connector's 'list' field.
  Since these two fields are members of the same union, this behavior
  results in a kernel panic.

  This issue is resolved by moving the connector's 'destroy_next' field
  into the object pointer union. This should work since the object pointer
  access is protected by both a spinlock and the value of the 'flags'
  field, and the 'flags' field is cleared while holding the spinlock in
  fsnotify_put_mark() before 'destroy_next' is updated. It shouldn't be
  possible for another thread to accidentally read from the object pointer
  after the 'destroy_next' field is updated.

  The offending behavior here is extremely unlikely; since
  fsnotify_put_mark() removes references to a connector (specifically,
  it ensures that the connector is unreachable from the inode it was
  formerly attached to) before updating its 'destroy_next' field, a
  sizeable chunk of code in fsnotify_put_mark() has to execute in the
  short window between when fsnotify() acquires the connector reference
  and saves the value of its 'list' field. On the HEAD kernel, I've only
  been able to reproduce this by inserting a udelay(1) in fsnotify().
  However, I've been able to reproduce this issue without inserting a
  udelay(1) anywhere on older unmodified release kernels, so I believe
  it's worth fixing at HEAD.

  References: https://bugzilla.kernel.org/show_bug.cgi?id=199437
  Fixes: 08991e83b7286635167bab40927665a90fb00d81
  CC: stable@xxxxxxxxxxxxxxx
  Signed-off-by: Robert Kolchmeyer <rkolchmeyer@xxxxxxxxxx>
  Signed-off-by: Jan Kara <jack@xxxxxxx>

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1765564/+subscriptions