From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1030546AbdADXts (ORCPT <rfc822;w@1wt.eu>);
        Wed, 4 Jan 2017 18:49:48 -0500
Received: from mga05.intel.com ([192.55.52.43]:65251 "EHLO mga05.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751548AbdADXtp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 4 Jan 2017 18:49:45 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.33,318,1477983600"; 
   d="scan'208";a="45805714"
Subject: Re: [RFC PATCH v3] sparc64: Add support for Application Data
 Integrity (ADI)
To: Rob Gardner <rob.gardner@oracle.com>,
        Khalid Aziz <khalid.aziz@oracle.com>, davem@davemloft.net,
        corbet@lwn.net, arnd@arndb.de, akpm@linux-foundation.org
References: <1483569999-13543-1-git-send-email-khalid.aziz@oracle.com>
 <6fcaab9f-40fb-fdfb-2c7e-bf21a862ab7c@linux.intel.com>
 <ae0b7d0b-54fa-fa93-3b50-d14ace1b16f5@oracle.com>
 <d234fb8b-965f-d966-46fe-965478fdf7cb@linux.intel.com>
 <8612e7db-97c5-f757-0aae-24c3acedbc29@oracle.com>
Cc: hpa@zytor.com, viro@zeniv.linux.org.uk, nitin.m.gupta@oracle.com,
        chris.hyser@oracle.com, tushar.n.dave@oracle.com,
        sowmini.varadhan@oracle.com, mike.kravetz@oracle.com,
        adam.buchbinder@gmail.com, minchan@kernel.org, hughd@google.com,
        kirill.shutemov@linux.intel.com, keescook@chromium.org,
        allen.pais@oracle.com, aryabinin@virtuozzo.com, atish.patra@oracle.com,
        joe@perches.com, pmladek@suse.com, jslaby@suse.cz,
        cmetcalf@mellanox.com, paul.gortmaker@windriver.com, mhocko@suse.com,
        jmarchan@redhat.com, lstoakes@gmail.com, 0x7f454c46@gmail.com,
        vbabka@suse.cz, tglx@linutronix.de, mingo@redhat.com,
        dan.j.williams@intel.com, iamjoonsoo.kim@lge.com,
        mgorman@techsingularity.net, vdavydov.dev@gmail.com,
        hannes@cmpxchg.org, namit@vmware.com, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
        linux-arch@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
        Khalid Aziz <khalid@gonehiking.org>
From: Dave Hansen <dave.hansen@linux.intel.com>
Message-ID: <2c0502d0-20ef-44ac-db5b-7f651a70b978@linux.intel.com>
Date: Wed, 4 Jan 2017 15:49:43 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <8612e7db-97c5-f757-0aae-24c3acedbc29@oracle.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01/04/2017 03:44 PM, Rob Gardner wrote:
> On 01/04/2017 03:40 PM, Dave Hansen wrote:
>> On 01/04/2017 03:35 PM, Rob Gardner wrote:
>>> Tags are not cleared at all when memory is freed, but rather, lazily
>>> (and automatically) cleared when memory is allocated.
>> What does "allocated" mean in this context?  Physical or virtual? What
>> does this do, for instance?
> 
> The first time a virtual page is touched by a process after the malloc,
> the kernel does clear_user_page() or something similar, which zeroes the
> memory. At the same time, the memory tags are cleared.

OK, so the tags can't survive a MADV_FREE.  That's definitely something
for apps to understand that use MADV_FREE as a substitute for memset().
It also means that tags can't be set for physically unallocated memory.

Neither of those are deal killers, but it would be nice to document it.

How does this all work with large pages?