Created By: David Coronel (28/05/2018 4:28 PM)
Good day Sam, Jamie,

The kernel 4.4.0-128-generic #154 is now ready for testing by Nvidia:

linux | 4.4.0-128.154 | xenial-proposed | source
linux-image-4.4.0-128-generic | 4.4.0-128.154 | xenial-proposed | amd64, arm64, 
armhf, i386, ppc64el, s390x

You have 5 working days from today to test and report results. If you
don't test this package, the patch will be reverted from the kernel.

You can find the instructions to test from -proposed here:

Let me know if you have any questions.

Thank you,

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  user space process hung in 'D' state waiting for disk io to complete

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  == SRU Justification ==

  Occasionally an application gets stuck in "D" state on NFS reads/sync and 
close system calls. All the subsequent operations on the NFS mounts are stuck 
and reboot is required to rectify the situation.

  Use GPF_NOIO in some allocations in writeback to avoid a deadlock. This is 
upstream in:
  ae97aa524ef4 ("NFS: Use GFP_NOIO for two allocations in writeback")

  See Test scenario in previous description.

  A test kernel with this patch was tested heavily (>100hrs of test
  suite) without issue.

  [Regression Potential]
  This changes memory allocation in NFS to use a different policy. This could 
potentially affect NFS. 

  However, the patch is already in Artful and Bionic without issue.

  The patch does not apply to Trusty.

  == Previous Description ==

  Using Ubuntu Xenial user reports processes hang in D state waiting for
  disk io.

  Ocassionally one of the applications gets into "D" state on NFS
  reads/sync and close system calls. based on the kernel backtraces
  seems to be stuck in kmalloc allocation during cleanup of dirty NFS

  All the subsequent operations on the NFS mounts are stuck and reboot
  is required to rectify the situation.

  [Test scenario]

  1) Applications running in Docker environment
  2) Application have cgroup limits --cpu-shares --memory -shm-limit
  3) python and C++ based applications (torch and caffe)
  4) Applications read big lmdb files and write results to NFS shares
  5) use NFS v3 , hard and fscache is enabled
  6) now swap space is configured

  This prevents all other I/O activity on that mount to hang.

  we are running into this issue more frequently and identified few
  applications causing this problem.

  As updated in the description, the problem seems to be happening when
  exercising the stack


  we see this with docker containers with cgroup option --memory

  whenever there is a deadlock, we see that the process that is hung has
  reached the maximum cgroup limit, multiple times and typically cleans
  up dirty data and caches to bring the usage under the limit.

  This reclaim path happens many times and finally we hit probably a
  race get into deadlock

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to