This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed- bionic'.
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1789146 Title: [Bug][CLX]assertion failure with util_range_rw using libpmemlog, possible kernel DAX bug Status in intel: Fix Released Status in linux package in Ubuntu: Fix Released Bug description: Description: On Mon, Apr 16, 2018 at 8:20 AM, Czurylo, Krzysztof <krzysztof.czur...@intel.com> wrote: > > I suspect the problem is caused by a bug in the kernel. > > I did a few experiments and it looks like the issue occurs only if the > filesystem is mounted with "-o dax". I can reproduce is both for xfs > and ext4, so it's not FS-specific, but rather DAX-specific. It also > reproduces on an emulated PMEM - no need to use real AEP DIMMs. > > Using the latest kernel (4.16.0) does not help. > > What happens: > > In debug version of libpmemlog (but also libpmemblk), the entire pool > is by default write-protected with mprotect(..., PROT_READ). > > When the program attempts to write some data to the pool (i.e. > pmemlog_append, pmemblk_write, ...), the library unprotects the pages > to be modified (usually just one or two pages) and once the data is > stored, the pages are protected again. > > Inside the kernel, mprotect splits the memory region associated with > the pool into 3 regions: the read-only head and tail + one r/w page in > the middle. > > The problem is that after the last step, the memory region associated > with the modified page is not merged with the adjacent regions having > the same protection flags (ro) to form one big read-only region again. > This leads to the situation where we have thousands of 4K memory > mappings per process that are tracked by the kernel separately. When > the number of maps exceeds the limit (default is 65536 - see: > /proc/sys/vm/max_map_count), mprotect fails with ENOMEM, which aborts > the program. Commitid: e1fb4a0864958fac2fb1b23f9f4562a9f90e3e8f dax: remove VM_MIXEDMAP for fsdax and device dax Target Kernel: 4.19 Target Release: 18.10 To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1789146/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
