** Description changed: - 15:11:31 DEBUG| [stdout] <<<test_start>>> - 15:11:31 DEBUG| [stdout] tag=mlock203 stime=1537369891 - 15:11:31 DEBUG| [stdout] cmdline="mlock203" - 15:11:31 DEBUG| [stdout] contacts="" - 15:11:31 DEBUG| [stdout] analysis=exit - 15:11:31 DEBUG| [stdout] <<<test_output>>> - 15:11:31 DEBUG| [stdout] tst_test.c:1063: INFO: Timeout per run is 0h 05m 00s - 15:11:31 DEBUG| [stdout] mlock203.c:63: FAIL: Locking one memory again increased VmLck - 15:11:31 DEBUG| [stdout] - 15:11:31 DEBUG| [stdout] Summary: - 15:11:31 DEBUG| [stdout] passed 0 - 15:11:31 DEBUG| [stdout] failed 1 - 15:11:31 DEBUG| [stdout] skipped 0 - 15:11:31 DEBUG| [stdout] warnings 0 - 15:11:31 DEBUG| [stdout] <<<execution_status>>> - 15:11:31 DEBUG| [stdout] initiation_status="ok" - 15:11:31 DEBUG| [stdout] duration=0 termination_type=exited termination_id=1 corefile=no - 15:11:31 DEBUG| [stdout] cutime=0 cstime=0 - 15:11:31 DEBUG| [stdout] <<<test_end>>> + == Justification == + When one vma was with flag VM_LOCKED|VM_LOCKONFAULT (by invoking + mlock2(,MLOCK_ONFAULT)), it can again be populated with mlock() with + VM_LOCKED flag only. + + There is a hole in mlock_fixup() which increase mm->locked_vm twice even + the two operations are on the same vma and both with VM_LOCKED flags. + + The issue can be reproduced by following code: + + mlock2(p, 1024 * 64, MLOCK_ONFAULT); //VM_LOCKED|VM_LOCKONFAULT + mlock(p, 1024 * 64); //VM_LOCKED + + Then check the increase VmLck field in /proc/pid/status(to 128k). + + When vma is set with different vm_flags, and the new vm_flags is with + VM_LOCKED, it is not necessarily be a "new locked" vma. + + There is a dedicated reproducer called "mlock203" test in + ubuntu_ltp_syscalls, you can see the failure for all the Ubuntu 4.4 + kernel: + + <<<test_start>>> + tag=mlock203 stime=1537369891 + cmdline="mlock203" + contacts="" + analysis=exit + <<<test_output>>> + tst_test.c:1063: INFO: Timeout per run is 0h 05m 00s + mlock203.c:63: FAIL: Locking one memory again increased VmLck + + Summary: + passed 0 + failed 1 + skipped 0 + warnings 0 + + == Fix == + b155b4fd (mm: mlock: avoid increase mm->locked_vm on mlock() when already mlock2(,MLOCK_ONFAULT)) + + A test kernel for Xenial / Xenial-KVM could be found here: + http://people.canonical.com/~phlin/kernel/lp-1793451-mlock203/ + + == Regression Potential == + Low, this patch prevents mm->locked_vm from increment just by adding an extra check to see if the old vm_flags is already VM_LOCKED. + + == Test Case == + Run the mlock203 test in ubuntu_ltp_syscalls test suite. And it will pass with the patched kernel. + ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: linux-image-4.4.0-1068-aws 4.4.0-1068.78 ProcVersionSignature: User Name 4.4.0-1068.78-aws 4.4.144 Uname: Linux 4.4.0-1068-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Thu Sep 20 06:44:13 2018 Ec2AMI: ami-0e32ec5bc225539f5 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-west-2b Ec2InstanceType: c3.large Ec2Kernel: unavailable Ec2Ramdisk: unavailable SourcePackage: linux-aws UpgradeStatus: No upgrade log present (probably fresh install)
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1793451 Title: mlock203 test in ubuntu_ltp_syscalls failed with Xenial kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1793451/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
