Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 04:05 PM, Rob Gardner wrote: >> What if two different small pages have different tags and khugepaged >> comes along and tries to collapse them? Will the page be split if a >> user attempts to set two different tags inside two different small-page >> portions of a single THP? > >

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 04:01 PM, Dave Hansen wrote: On 01/04/2017 03:58 PM, Khalid Aziz wrote: How does this all work with large pages? It works with large pages the same way as normal sized pages. The TTE for a large page also will have the mcd bit set in it and tags are set and referenced the same

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 03:58 PM, Khalid Aziz wrote: >> How does this all work with large pages? > > It works with large pages the same way as normal sized pages. The TTE > for a large page also will have the mcd bit set in it and tags are set > and referenced the same way. But does the user setting the

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 04:49 PM, Dave Hansen wrote: 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

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 03:49 PM, Dave Hansen wrote: 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

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 03:46 PM, Khalid Aziz wrote: >> It would also be really nice to see a high-level breakdown explaining >> what you had to modify, especially since this affects all of the system >> calls that take a PROT_* argument. The sample code is nice, but it's no >> substitute for writing it

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

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

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 04:31 PM, Dave Hansen wrote: One other high-level comment: It would be nice to see the arch-independent and x86 portions broken out and explained in their own right, even if they're small patches. It's a bit cruel to make us scroll through a thousand lines of sparc code to see

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 04:27 PM, Dave Hansen wrote: On 01/04/2017 02:46 PM, Khalid Aziz wrote: This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable MCD (Memory Corruption Detection) on selected memory ranges, enable TTE.mcd in PTEs, return ADI parameters to userspace and save/restore

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

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,

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

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? ptr =

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 03:27 PM, Dave Hansen wrote: On 01/04/2017 02:46 PM, Khalid Aziz wrote: This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable MCD (Memory Corruption Detection) on selected memory ranges, enable TTE.mcd in PTEs, return ADI parameters to userspace and save/restore

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

One other high-level comment: It would be nice to see the arch-independent and x86 portions broken out and explained in their own right, even if they're small patches. It's a bit cruel to make us scroll through a thousand lines of sparc code to see the bits interesting to us. It would also be

Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

On 01/04/2017 02:46 PM, Khalid Aziz wrote: > This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable > MCD (Memory Corruption Detection) on selected memory ranges, enable > TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI > version tags on page swap out/in.

[RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

ADI is a new feature supported on sparc M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data

Re: [PATCH] Documentation: cpufreq: Update supported powernv processors

On Wed, Jan 4, 2017 at 11:20 PM, Jonathan Corbet wrote: > On Wed, 04 Jan 2017 23:11:30 +0100 > "Rafael J. Wysocki" wrote: > >> I'm assuming then, that you're going to handle cpufreq docs changes in the >> future. >> >> Some cpufreq patches update the docs too,

Re: [PATCH] Documentation: cpufreq: Update supported powernv processors

On Wed, 04 Jan 2017 23:11:30 +0100 "Rafael J. Wysocki" wrote: > I'm assuming then, that you're going to handle cpufreq docs changes in the > future. > > Some cpufreq patches update the docs too, though, so there may be changes in > there coming from two sources. I saw it

Re: [PATCH] Documentation: cpufreq: Update supported powernv processors

On Wednesday, January 04, 2017 02:35:27 PM Jonathan Corbet wrote: > On Mon, 2 Jan 2017 12:38:15 +0530 > Viresh Kumar wrote: > > > > +The following POWER processors are supported in powernv mode: > > > +POWER8 > > > +POWER9 > > I've applied this to the docs tree, thanks.

Re: [PATCH 0/5] kernel-doc tweaks and cleanup of rST vs. non-rST backends

On Mon, 2 Jan 2017 16:22:22 +0100 Paolo Bonzini wrote: > these patches are the result of my experiments with using kernel-doc > for QEMU's documentation. Patches 1 and 2 should be relatively > straightforward, as they are simple bugfixes. Patches 3 to 5, instead, > are

Re: [PATCH] Documentation: fix spelling mistakes of "Celcius" -- > "Celsius"

On Wed, 28 Dec 2016 21:51:37 + Colin King wrote: > Documentation/hwmon/ds1621| 8 > Documentation/thermal/nouveau_thermal | 2 +- > 2 files changed, 5 insertions(+), 5 deletions(-) Applied to the docs tree, thanks. jon -- To unsubscribe from

Re: [PATCH] Documentation: cpufreq: Update supported powernv processors

On Mon, 2 Jan 2017 12:38:15 +0530 Viresh Kumar wrote: > > +The following POWER processors are supported in powernv mode: > > +POWER8 > > +POWER9 I've applied this to the docs tree, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in