All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
Date: Thu, 8 Aug 2019 17:27:02 +0100	[thread overview]
Message-ID: <20190808162702.GJ10425@arm.com> (raw)
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>

On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:

[Random comments below on a couple of points]

> On 8/7/19 8:53 AM, Catalin Marinas wrote:
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > +  - flags have the **MAP_ANONYMOUS** bit set
> > +  - the file descriptor refers to a regular file (including those returned
> > +    by memfd_create()) or **/dev/zero**
> 
> What's a "regular file"? ;)

A file, as distinct from device nodes, sockets, symlinks etc.

I think this is fairly standard UNIX terminology, even though it sounds
vague:

From glibc's <bits/stat.h>:

#define	__S_IFREG	0100000	/* Regular file.  */


Or for POSIX test (a.k.a. "[")

       -f file
              True if file exists and is a regular file.

Using memfd_create() or opening /dev/zero doesn't yield a regular file
though, so perhaps those should be a separate bullet.

[...]

> > +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> > +control it via **prctl()** as follows:
> > +
> > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> > +  ABI for the calling process.
> > +
> > +  The (unsigned int) arg2 argument is a bit mask describing the control mode
> > +  used:
> > +
> > +  - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> > +    status is disabled.
> > +
> > +  The arguments arg3, arg4, and arg5 are ignored.
> 
> For previous prctl()'s, we've found that it's best to require that the
> unused arguments be 0.  Without that, apps are free to put garbage
> there, which makes extending the prctl to use other arguments impossible
> in the future.

Because arg2 is already a mask of flags with some flags unallocated,
we can add a new flag for ABI extensions.

If arg3 is used someday, it may or may not be natural for 0 to mean
"default".  Enabling this argument with an explicit flag in arg2 may
be cleaner than mangling the semantics of arg3 so that 0 can have
the right meaning.

Avoiding redundant 0 arguments also allows userspace to take advantage
of the glibc's variadic prototype for prctl() for example.

Not a huge deal, but that was my rationale anyway.

> Also, shouldn't this be converted over to an arch_prctl()?

Most arch-specific prctls seem to use prctl(), and arm64 already has a
few there.

arch_prctl() is x86-specific.  I don't know the history.

[...]

Cheers
---Dave

WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <Dave.Martin@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
Date: Thu, 8 Aug 2019 17:27:02 +0100	[thread overview]
Message-ID: <20190808162702.GJ10425@arm.com> (raw)
Message-ID: <20190808162702.RQNvVBE_CIhgSWCOP0Q8zsz7X51AwS-MQtsJ5ZtLCFE@z> (raw)
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>

On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:

[Random comments below on a couple of points]

> On 8/7/19 8:53 AM, Catalin Marinas wrote:
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > +  - flags have the **MAP_ANONYMOUS** bit set
> > +  - the file descriptor refers to a regular file (including those returned
> > +    by memfd_create()) or **/dev/zero**
> 
> What's a "regular file"? ;)

A file, as distinct from device nodes, sockets, symlinks etc.

I think this is fairly standard UNIX terminology, even though it sounds
vague:

WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <Dave.Martin@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
Date: Thu, 8 Aug 2019 17:27:02 +0100	[thread overview]
Message-ID: <20190808162702.GJ10425@arm.com> (raw)
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>

On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:

[Random comments below on a couple of points]

> On 8/7/19 8:53 AM, Catalin Marinas wrote:
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > +  - flags have the **MAP_ANONYMOUS** bit set
> > +  - the file descriptor refers to a regular file (including those returned
> > +    by memfd_create()) or **/dev/zero**
> 
> What's a "regular file"? ;)

A file, as distinct from device nodes, sockets, symlinks etc.

I think this is fairly standard UNIX terminology, even though it sounds
vague:

From glibc's <bits/stat.h>:

#define	__S_IFREG	0100000	/* Regular file.  */


Or for POSIX test (a.k.a. "[")

       -f file
              True if file exists and is a regular file.

Using memfd_create() or opening /dev/zero doesn't yield a regular file
though, so perhaps those should be a separate bullet.

[...]

> > +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> > +control it via **prctl()** as follows:
> > +
> > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> > +  ABI for the calling process.
> > +
> > +  The (unsigned int) arg2 argument is a bit mask describing the control mode
> > +  used:
> > +
> > +  - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> > +    status is disabled.
> > +
> > +  The arguments arg3, arg4, and arg5 are ignored.
> 
> For previous prctl()'s, we've found that it's best to require that the
> unused arguments be 0.  Without that, apps are free to put garbage
> there, which makes extending the prctl to use other arguments impossible
> in the future.

Because arg2 is already a mask of flags with some flags unallocated,
we can add a new flag for ABI extensions.

If arg3 is used someday, it may or may not be natural for 0 to mean
"default".  Enabling this argument with an explicit flag in arg2 may
be cleaner than mangling the semantics of arg3 so that 0 can have
the right meaning.

Avoiding redundant 0 arguments also allows userspace to take advantage
of the glibc's variadic prototype for prctl() for example.

Not a huge deal, but that was my rationale anyway.

> Also, shouldn't this be converted over to an arch_prctl()?

Most arch-specific prctls seem to use prctl(), and arm64 already has a
few there.

arch_prctl() is x86-specific.  I don't know the history.

[...]

Cheers
---Dave

WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <Dave.Martin@arm.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
Date: Thu, 8 Aug 2019 17:27:02 +0100	[thread overview]
Message-ID: <20190808162702.GJ10425@arm.com> (raw)
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>

On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:

[Random comments below on a couple of points]

> On 8/7/19 8:53 AM, Catalin Marinas wrote:
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > +  - flags have the **MAP_ANONYMOUS** bit set
> > +  - the file descriptor refers to a regular file (including those returned
> > +    by memfd_create()) or **/dev/zero**
> 
> What's a "regular file"? ;)

A file, as distinct from device nodes, sockets, symlinks etc.

I think this is fairly standard UNIX terminology, even though it sounds
vague:

From glibc's <bits/stat.h>:

#define	__S_IFREG	0100000	/* Regular file.  */


Or for POSIX test (a.k.a. "[")

       -f file
              True if file exists and is a regular file.

Using memfd_create() or opening /dev/zero doesn't yield a regular file
though, so perhaps those should be a separate bullet.

[...]

> > +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> > +control it via **prctl()** as follows:
> > +
> > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> > +  ABI for the calling process.
> > +
> > +  The (unsigned int) arg2 argument is a bit mask describing the control mode
> > +  used:
> > +
> > +  - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> > +    status is disabled.
> > +
> > +  The arguments arg3, arg4, and arg5 are ignored.
> 
> For previous prctl()'s, we've found that it's best to require that the
> unused arguments be 0.  Without that, apps are free to put garbage
> there, which makes extending the prctl to use other arguments impossible
> in the future.

Because arg2 is already a mask of flags with some flags unallocated,
we can add a new flag for ABI extensions.

If arg3 is used someday, it may or may not be natural for 0 to mean
"default".  Enabling this argument with an explicit flag in arg2 may
be cleaner than mangling the semantics of arg3 so that 0 can have
the right meaning.

Avoiding redundant 0 arguments also allows userspace to take advantage
of the glibc's variadic prototype for prctl() for example.

Not a huge deal, but that was my rationale anyway.

> Also, shouldn't this be converted over to an arch_prctl()?

Most arch-specific prctls seem to use prctl(), and arm64 already has a
few there.

arch_prctl() is x86-specific.  I don't know the history.

[...]

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-08-08 16:27 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 15:53 [PATCH v7 0/2] arm64 tagged address ABI Catalin Marinas
2019-08-07 15:53 ` Catalin Marinas
2019-08-07 15:53 ` Catalin Marinas
2019-08-07 15:53 ` [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst Catalin Marinas
2019-08-07 15:53   ` Catalin Marinas
2019-08-07 15:53   ` Catalin Marinas
2019-08-07 20:38   ` Dave Hansen
2019-08-07 20:38     ` Dave Hansen
2019-08-07 20:38     ` Dave Hansen
2019-08-08  9:25     ` Szabolcs Nagy
2019-08-08  9:25       ` Szabolcs Nagy
2019-08-08  9:25       ` Szabolcs Nagy
2019-08-08 16:20     ` Szabolcs Nagy
2019-08-08 16:20       ` Szabolcs Nagy
2019-08-08 16:20       ` Szabolcs Nagy
2019-08-08 16:27     ` Dave Martin [this message]
2019-08-08 16:27       ` Dave Martin
2019-08-08 16:27       ` Dave Martin
2019-08-08 16:27       ` Dave Martin
2019-08-08 17:27     ` Catalin Marinas
2019-08-08 17:27       ` Catalin Marinas
2019-08-08 17:27       ` Catalin Marinas
2019-08-09 14:10       ` Dave Hansen
2019-08-09 14:10         ` Dave Hansen
2019-08-09 14:10         ` Dave Hansen
2019-08-12 17:36         ` Catalin Marinas
2019-08-12 17:36           ` Catalin Marinas
2019-08-12 17:36           ` Catalin Marinas
2019-08-13 11:10           ` Dave Martin
2019-08-13 11:10             ` Dave Martin
2019-08-13 11:10             ` Dave Martin
2019-08-08 16:30   ` Szabolcs Nagy
2019-08-08 16:30     ` Szabolcs Nagy
2019-08-08 16:30     ` Szabolcs Nagy
2019-08-08 17:04   ` Will Deacon
2019-08-08 17:04     ` Will Deacon
2019-08-08 17:04     ` Will Deacon
2019-08-12 10:46     ` Andrew Murray
2019-08-12 10:46       ` Andrew Murray
2019-08-12 10:46       ` Andrew Murray
2019-08-12 17:17       ` Catalin Marinas
2019-08-12 17:17         ` Catalin Marinas
2019-08-12 17:17         ` Catalin Marinas
2019-08-07 15:53 ` [PATCH v7 2/2] arm64: Relax Documentation/arm64/tagged-pointers.rst Catalin Marinas
2019-08-07 15:53   ` Catalin Marinas
2019-08-07 15:53   ` Catalin Marinas
2019-08-08 17:06   ` Will Deacon
2019-08-08 17:06     ` Will Deacon
2019-08-08 17:06     ` Will Deacon
2019-08-08  9:32 ` [PATCH v7 0/2] arm64 tagged address ABI Szabolcs Nagy
2019-08-08  9:32   ` Szabolcs Nagy
2019-08-08  9:32   ` Szabolcs Nagy

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=20190808162702.GJ10425@arm.com \
    --to=dave.martin@arm.com \
    --cc=andreyknvl@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@intel.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=szabolcs.nagy@arm.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.