hi, Joseph I have built a kernel by myself clone from below link. The version is 4.18.
git://kernel.ubuntu.com/kernel-ppa/mirror/ubuntu-cosmic.git commit d4b160782ac74f5301651346495903a30cf752d3 (HEAD -> master, tag: Ubuntu-4.18.0-7.8, origin/master, origin/HEAD) Author: Seth Forshee <[email protected]> Date: Tue Aug 28 11:09:06 2018 -0500 UBUNTU: Ubuntu-4.18.0-7.8 Signed-off-by: Seth Forshee <[email protected]> in this branch, there is no patch. Test failed. I apply the new patch, the test works. Therefore for 4.18, it will be fine with patch. For your new kernel, I will have a try, will let you know the result. -- 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: Triaged Status in linux package in Ubuntu: Fix Committed Bug description: Description: On Mon, Apr 16, 2018 at 8:20 AM, Czurylo, Krzysztof <[email protected]> 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 : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
