linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: dave.hansen@linux.intel.com
Cc: khalid.aziz@oracle.com, corbet@lwn.net, arnd@arndb.de,
	akpm@linux-foundation.org, 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
Subject: Re: [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7
Date: Mon, 16 Jan 2017 23:47:49 -0500 (EST)	[thread overview]
Message-ID: <20170116.234749.545252655332977761.davem@davemloft.net> (raw)
In-Reply-To: <11d20dac-2c0f-6e9a-7f98-3839c749adb6@linux.intel.com>

From: Dave Hansen <dave.hansen@linux.intel.com>
Date: Wed, 11 Jan 2017 10:13:54 -0800

> For memory shared by two different processes, do they have to agree on
> what the tags are, or can they differ?

Whoever allocates the memory (does the mmap()+mprotect() or whatever),
decides on the tag.  They set it, and this determines which virtual
address is valid to access that mapping.

It's like kmalloc() returns pointers with some weird bits set in the
upper bits of the address.  Behind the scenes kmalloc() sets the
TAG bits appropriately.

It doesn't, in that sense, matter where in the non-tagged virtual
address space the memory is mapped.  All that matters is that, for
a given page, the TAG bits in the virtual address used for loads
and stores to that mapping are set properly.

I think the fundamental thing being missed is that the TAG bits in the
virtual address are not interpreted by the TLB.  They are chopped off
before virtual address translation occurs.

The TAG bits of the virtual address serve only to indicate what ADI
value the load or store thinks is valid to use for access to that
piece of memory.

Or something like that... :-)

  parent reply	other threads:[~2017-01-17  4:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-11 16:12 [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7 Khalid Aziz
2017-01-11 16:12 ` [PATCH v4 1/4] signals, sparc: Add signal codes for ADI violations Khalid Aziz
2017-01-11 16:12 ` [PATCH v4 2/4] mm: Add function to support extra actions on swap in/out Khalid Aziz
2017-01-11 16:56   ` Dave Hansen
2017-01-11 17:15     ` Khalid Aziz
2017-01-11 16:12 ` [PATCH v4 3/4] sparc64: Add support for ADI register fields, ASIs and traps Khalid Aziz
2017-01-17  4:23   ` David Miller
2017-01-17 15:55     ` Khalid Aziz
2017-01-11 16:12 ` [PATCH v4 4/4] sparc64: Add support for ADI (Application Data Integrity) Khalid Aziz
2017-01-17  4:39   ` David Miller
2017-01-17 19:32     ` Khalid Aziz
2017-01-17 19:42       ` David Miller
2017-01-17 20:12         ` Khalid Aziz
2017-01-18  0:14     ` Khalid Aziz
2017-01-11 16:33 ` [PATCH v4 0/4] Application Data Integrity feature introduced by SPARC M7 Dave Hansen
2017-01-11 16:56   ` Khalid Aziz
2017-01-11 18:13     ` Dave Hansen
2017-01-11 18:50       ` Khalid Aziz
2017-01-11 19:11         ` Dave Hansen
2017-01-12  0:22           ` Khalid Aziz
2017-01-12  0:49             ` Dave Hansen
2017-01-12 16:50               ` Khalid Aziz
2017-01-12 17:53                 ` Dave Hansen
2017-01-13  0:22                   ` Khalid Aziz
2017-01-13  1:31                     ` Rob Gardner
2017-01-13 14:48                       ` Khalid Aziz
2017-01-13 15:29                         ` Rob Gardner
2017-01-13 15:59                           ` Khalid Aziz
2017-01-13 16:08                           ` Dave Hansen
2017-01-13 17:36                             ` Rob Gardner
2017-01-17  4:47       ` David Miller [this message]
2017-01-17 21:43         ` Khalid Aziz
2017-01-17  4:42   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170116.234749.545252655332977761.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=0x7f454c46@gmail.com \
    --cc=adam.buchbinder@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=allen.pais@oracle.com \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=atish.patra@oracle.com \
    --cc=chris.hyser@oracle.com \
    --cc=cmetcalf@mellanox.com \
    --cc=corbet@lwn.net \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=hpa@zytor.com \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=jmarchan@redhat.com \
    --cc=joe@perches.com \
    --cc=jslaby@suse.cz \
    --cc=keescook@chromium.org \
    --cc=khalid.aziz@oracle.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=minchan@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namit@vmware.com \
    --cc=nitin.m.gupta@oracle.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=pmladek@suse.com \
    --cc=sowmini.varadhan@oracle.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tushar.n.dave@oracle.com \
    --cc=vbabka@suse.cz \
    --cc=vdavydov.dev@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).