From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24971C54FCE for ; Mon, 23 Mar 2020 15:08:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F02E820663 for ; Mon, 23 Mar 2020 15:08:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OF9gx+Ag" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727227AbgCWPII (ORCPT ); Mon, 23 Mar 2020 11:08:08 -0400 Received: from us-smtp-delivery-74.mimecast.com ([216.205.24.74]:28884 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727008AbgCWPII (ORCPT ); Mon, 23 Mar 2020 11:08:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584976087; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=boyhvrzOtDio58DSfyyVO/3598sZBoxhLyRpe5w9LWs=; b=OF9gx+AgfDr1RzecVZvxC28BauyXJHW9Kde00fz6YrBC1YfHJZcj51wcz6iUAYOWZePDZJ 2iWY5Kw/tRgmiZkHxSlQJ/n80VkM01goWyJsiAmtAwYooY9mv9z22r0ASxjKySBz3msud2 r9GDbqnhHYjx/gKmdEULgRz/JFMXklI= 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-289-Nc8wrUQJMRuUCpd_uzXOxw-1; Mon, 23 Mar 2020 11:08:02 -0400 X-MC-Unique: Nc8wrUQJMRuUCpd_uzXOxw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 858158017CC; Mon, 23 Mar 2020 15:08:01 +0000 (UTC) Received: from optiplex-lnx (unknown [10.33.36.220]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9EDA460BE0; Mon, 23 Mar 2020 15:07:59 +0000 (UTC) Date: Mon, 23 Mar 2020 11:07:56 -0400 From: Rafael Aquini To: Michal Hocko Cc: Shakeel Butt , LKML , linux-kselftest@vger.kernel.org, shuah@kernel.org, Andrew Morton Subject: Re: [PATCH] tools/testing/selftests/vm/mlock2-tests: fix mlock2 false-negative errors Message-ID: <20200323150756.GE23364@optiplex-lnx> References: <20200322013525.1095493-1-aquini@redhat.com> <20200323141659.GA23364@optiplex-lnx> <20200323142941.GK7524@dhcp22.suse.cz> <20200323150134.GN7524@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200323150134.GN7524@dhcp22.suse.cz> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 23, 2020 at 04:01:34PM +0100, Michal Hocko wrote: > On Mon 23-03-20 15:29:43, Michal Hocko wrote: > > On Mon 23-03-20 10:16:59, Rafael Aquini wrote: > > > On Sun, Mar 22, 2020 at 09:31:04AM -0700, Shakeel Butt wrote: > > > > On Sat, Mar 21, 2020 at 6:35 PM Rafael Aquini wrote: > > > > > > > > > > Changes for commit 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping pagevecs") > > > > > break this test expectations on the behavior of mlock syscall family immediately > > > > > inserting the recently faulted pages into the UNEVICTABLE_LRU, when MCL_ONFAULT is > > > > > passed to the syscall as part of its flag-set. > > > > > > > > mlock* syscalls do not provide any guarantee that the pages will be in > > > > unevictable LRU, only that the pages will not be paged-out. The test > > > > is checking something very internal to the kernel and this is expected > > > > to break. > > > > > > It was a check expected to be satisfied before the commit, though. > > > Getting the mlocked pages inserted directly into the unevictable LRU, > > > skipping the pagevec, was established behavior before the aforementioned > > > commit, and even though one could argue userspace should not be aware, > > > or care, about such inner kernel circles the program in question is not an > > > ordinary userspace app, but a kernel selftest that is supposed to check > > > for the functionality correctness. > > > > But mlock (in neither mode) is reall forced to put pages to the > > ble I meant to say "is not really forced" > > > UNEVICTABLE_LRU for correctness. If the test is really depending on it > > then the selftest is bogus. A real MCL_ONFAULT test should focus on the > > user observable contract of this api. And that is that a new mapping > > doesn't fault in the page during the mlock call but the memory is locked > > after the memory is faulted in. You can use different methods to observe > > locked memory - e.g. try to reclaim it and check or check /proc//smaps > > I have just checked the testcase and I believe it is really dubious to > check for page flags. Those are really an internal implementation > detail. All the available information is available in the > /proc//smaps file which is already parsed in the test so the test > is easily fixable. That surely is another take for this test. I still think the test is reasonable when it checks what was expected to be there, from the kernel standpoint, and just needs to be adjusted for the current state of affairs. -- Rafael