Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2307103ybb; Sat, 21 Mar 2020 18:37:07 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuoFtpY6sijBWN033OxuauOBB+WrJKu5Q1eXx+XlW8tYkoxe7ll1MtJXH9wlRaj741DIO/b X-Received: by 2002:a9d:6354:: with SMTP id y20mr13046458otk.171.1584841027377; Sat, 21 Mar 2020 18:37:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584841027; cv=none; d=google.com; s=arc-20160816; b=0MhstjLTO1Wkr7EjkeXLeulXpSmZIJxM8fQEJO8DXEnm+RyCBZRrHPDhvyCZTZO3Fm EBJKauVSjPNQRFj1Il1qA6d0A776kDAaksQyOgAhbMJ8aIzs19KO229/iqtyDpbbpI/7 aEPMfQQkrxVSWmD5c3dlj7i7jW0/KfrUlCuiTmmpCyRRYOIWdoS7MAfxKA72ujaOxZQV yrjASOx2Pi/UmoU4hR3K0LmA3FoMTDMHgRAK2OgxT4m/L0iM3R586TAMX47J4F66g7fQ UZeFT38mk+V2TGwduXbuyDBQrPWj+7ckJjRpbiUnT5/sG24qRa95lc6paf8W0Q2BuaJw sd6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=vC6nIVunZ7Rm0krd+FFCpzgbO+fh9BWQe1SFxACqKGo=; b=0Q6aK2agNy/QKYXcUMjneG7zdC3SwBzI0cQqBQ6qRU7NTRj9/fRB/LIZo+EVar40hw eYmXUL31TfnqQ6tyjnHG28OpfODRKDaKQMT+apVGx9ZXW7D0+1/aQkb4p7HrwkSzIf6A Ht8WdbcTN8GH2InrItisI4ZvPkQRjQSCH/XLFxunexPT804ZY+jh5UkiJ6kiGZppwf5k 4FG5uFw320QKUAHJRi+DOxhchRH482eJ4NFp2cPFa0Paz+PD/gPLICeC4slwWXQcMf0Y kSqJG42P6UtnZBv536vTYd8MQ1SS3riJPwGuADpNB1kNQa8AYrDPcHDglhboKjaRNLSj ROcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fZ0kAe9J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c10si5636104oto.202.2020.03.21.18.36.54; Sat, 21 Mar 2020 18:37:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fZ0kAe9J; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728111AbgCVBff (ORCPT + 99 others); Sat, 21 Mar 2020 21:35:35 -0400 Received: from us-smtp-delivery-74.mimecast.com ([216.205.24.74]:38551 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726859AbgCVBff (ORCPT ); Sat, 21 Mar 2020 21:35:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584840933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=vC6nIVunZ7Rm0krd+FFCpzgbO+fh9BWQe1SFxACqKGo=; b=fZ0kAe9JqMI1qQPecNUSmsEqlXo1X5RH5NGjzi3s4Oj0gVOWvrfFuVjoCh8V0/3KF64LAD sx/mxVc9AB/qQWYjfBEqhuxsCZTXoKAMtI1FHNJizF4B/D/xWPRsFM8SXWw+FuvAcjWTGL btLnGc2rCK0oyQd4qiUxEk+F5Ze4wrc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-211-xaRD8C2UOfGUK-pcPgABGA-1; Sat, 21 Mar 2020 21:35:29 -0400 X-MC-Unique: xaRD8C2UOfGUK-pcPgABGA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7C5638017CC; Sun, 22 Mar 2020 01:35:28 +0000 (UTC) Received: from t490s.redhat.com (ovpn-112-44.phx2.redhat.com [10.3.112.44]) by smtp.corp.redhat.com (Postfix) with ESMTP id AC9C610002A7; Sun, 22 Mar 2020 01:35:27 +0000 (UTC) From: Rafael Aquini To: linux-kernel@vger.kernel.org Cc: linux-kselftest@vger.kernel.org, shuah@kernel.org, shakeelb@google.com, akpm@linux-foundation.org Subject: [PATCH] tools/testing/selftests/vm/mlock2-tests: fix mlock2 false-negative errors Date: Sat, 21 Mar 2020 21:35:25 -0400 Message-Id: <20200322013525.1095493-1-aquini@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Changes for commit 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping pa= gevecs") break this test expectations on the behavior of mlock syscall family imme= diately inserting the recently faulted pages into the UNEVICTABLE_LRU, when MCL_O= NFAULT is passed to the syscall as part of its flag-set. There is no functional error introduced by the aforementioned commit, but it opens up a time window where the recently faulted and locked pages might yet not be put back into the UNEVICTABLE_LRU, thus causing a subsequent and immediate PFN flag check for the UNEVICTABLE bit to trip on false-negative errors, as it happens with this test. This patch fix the false negative by forcefully resorting to a code path = that will call a CPU pagevec drain right after the fault but before the PFN fl= ag check takes place, sorting out the race that way. Fixes: 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping pagevecs") Signed-off-by: Rafael Aquini --- tools/testing/selftests/vm/mlock2-tests.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/tools/testing/selftests/vm/mlock2-tests.c b/tools/testing/se= lftests/vm/mlock2-tests.c index 637b6d0ac0d0..26dc320ca3c9 100644 --- a/tools/testing/selftests/vm/mlock2-tests.c +++ b/tools/testing/selftests/vm/mlock2-tests.c @@ -7,6 +7,7 @@ #include #include #include +#include #include "mlock2.h" =20 #include "../kselftest.h" @@ -328,6 +329,22 @@ static int test_mlock_lock() return ret; } =20 +/* + * After commit 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping page= vecs") + * changes made by calls to mlock* family might not be immediately refle= cted + * on the LRUs, thus checking the PFN flags might race against pagevec d= rain. + * + * In order to sort out that race, and get the after fault checks consis= tent, + * the "quick and dirty" trick below is required in order to force a cal= l to + * lru_add_drain_all() to get the recently MLOCK_ONFAULT pages moved to + * the unevictable LRU, as expected by the checks in this selftest. + */ +static void force_lru_add_drain_all(void) +{ + sched_yield(); + system("echo 1 > /proc/sys/vm/compact_memory"); +} + static int onfault_check(char *map) { unsigned long page_size =3D getpagesize(); @@ -343,6 +360,9 @@ static int onfault_check(char *map) } =20 *map =3D 'a'; + + force_lru_add_drain_all(); + page1_flags =3D get_pageflags((unsigned long)map); page2_flags =3D get_pageflags((unsigned long)map + page_size); =20 @@ -465,6 +485,8 @@ static int test_lock_onfault_of_present() goto unmap; } =20 + force_lru_add_drain_all(); + page1_flags =3D get_pageflags((unsigned long)map); page2_flags =3D get_pageflags((unsigned long)map + page_size); page1_flags =3D get_kpageflags(page1_flags & PFN_MASK); --=20 2.24.1