Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1551486 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-05 00:30 +0100
    Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2017-01-05 00:40 +0100
      Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2017-01-05 00:50 +0100
        Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-05 00:50 +0100
          Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-05 01:00 +0100
            Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-05 01:10 +0100
              Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2017-01-05 01:10 +0100
                Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-05 01:20 +0100
                  Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-05 01:30 +0100
                    Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-05 20:30 +0100
                      Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-05 21:40 +0100
                        Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Michal Hocko <mhocko@kernel.org> - 2017-01-06 10:30 +0100
                          Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-06 16:40 +0100
                            Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-06 17:30 +0100
                              Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) David Miller <davem@redhat.com> - 2017-01-06 17:30 +0100
                              Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-06 18:00 +0100
                                Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) David Miller <davem@davemloft.net> - 2017-01-06 18:10 +0100
                                  Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-06 18:20 +0100
                                    Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2017-01-06 19:00 +0100
                                      Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-06 19:20 +0100
                                        Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2017-01-06 19:40 +0100
                                Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-06 18:20 +0100
                          Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-06 16:40 +0100
          Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Rob Gardner <rob.gardner@oracle.com> - 2017-01-05 01:00 +0100
      Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Dave Hansen <dave.hansen@linux.intel.com> - 2017-01-05 00:50 +0100
    Re: [RFC PATCH v3] sparc64: Add support for Application Data  Integrity (ADI) Khalid Aziz <khalid.aziz@oracle.com> - 2017-01-05 00:50 +0100

Page 1 of 2  [1] 2  Next page →

#1551486 — 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. 

I'm a bit confused why we need all the mechanics with set_swp_pte_at().
For pkeys, for instance, all of the PTEs under a given VMA share a pkey.
 When swapping something in, we just get the pkey out of the VMA and
populate the PTE.

ADI doesn't seem to have a similar restriction.  The feature is turned
on or off at a VMA granularity, but we do not (or can enforce that all
pages under a given VMA must share a tag.

But this leads to an interesting question: is the tag associated with
the (populated?) pte, or the virtual address?  Can you have tags
associated with non-present addresses?  What's the mechanism that clears
the tags at munmap() or MADV_FREE time?

Is the tag storage a precious resource?  Can it be exhausted?

[toc] | [next] | [standalone]

#1551490

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 ADI
>> version tags on page swap out/in.
> I'm a bit confused why we need all the mechanics with set_swp_pte_at().
> For pkeys, for instance, all of the PTEs under a given VMA share a pkey.
>   When swapping something in, we just get the pkey out of the VMA and
> populate the PTE.
>
> ADI doesn't seem to have a similar restriction.  The feature is turned
> on or off at a VMA granularity, but we do not (or can enforce that all
> pages under a given VMA must share a tag.
>
> But this leads to an interesting question: is the tag associated with
> the (populated?) pte, or the virtual address?  Can you have tags
> associated with non-present addresses?  What's the mechanism that clears
> the tags at munmap() or MADV_FREE time?
>
> Is the tag storage a precious resource?  Can it be exhausted?


Tags are stored in physical memory, so there is no "tag storage" that 
can be exhausted.

Tags are not cleared at all when memory is freed, but rather, lazily 
(and automatically) cleared when memory is allocated.


Rob

[toc] | [prev] | [next] | [standalone]

#1551503

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.

Rob


>
> 	ptr = malloc(PAGE_SIZE);
> 	set_tag(ptr, 14);
> 	madvise(ptr, PAGE_SIZE, MADV_FREE);
> 	printf("tag: %d\n", get_tag(ptr));
> 	free(ptr);
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1551505

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?

[toc] | [prev] | [next] | [standalone]

#1551515

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 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.

This can go into the adi.txt doc file.

>
> 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.

--
Khalid

[toc] | [prev] | [next] | [standalone]

#1551520

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 tags need to know what the page size is?

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?

[toc] | [prev] | [next] | [standalone]

#1551521

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 way.
> But does the user setting the tags need to know what the page size is?
>
> 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?

The MCD tags operate at a resolution of cache lines (64 bytes). Page 
sizes don't matter except that each virtual page must have a bit set in 
its TTE to allow MCD to be enabled on the page. Any page can have many 
different tags, one for each cache line.

Rob

[toc] | [prev] | [next] | [standalone]

#1551526

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?
> 
> The MCD tags operate at a resolution of cache lines (64 bytes). Page
> sizes don't matter except that each virtual page must have a bit set in
> its TTE to allow MCD to be enabled on the page. Any page can have many
> different tags, one for each cache line.

Is an "MCD tag" the same thing as a "ADI version tag"?

The thing that confused me here is that we're taking an entire page of
"ADI version tags" and stuffing them into a swap pte (in
set_swp_pte_at()).  Do we somehow have enough space in a swap pte on
sparc to fit PAGE_SIZE/64 "ADI version tag"s in there?

[toc] | [prev] | [next] | [standalone]

#1551529

On 01/04/2017 05:14 PM, Dave Hansen wrote:
> 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?
>>
>> The MCD tags operate at a resolution of cache lines (64 bytes). Page
>> sizes don't matter except that each virtual page must have a bit set in
>> its TTE to allow MCD to be enabled on the page. Any page can have many
>> different tags, one for each cache line.
>
> Is an "MCD tag" the same thing as a "ADI version tag"?
>
> The thing that confused me here is that we're taking an entire page of
> "ADI version tags" and stuffing them into a swap pte (in
> set_swp_pte_at()).  Do we somehow have enough space in a swap pte on
> sparc to fit PAGE_SIZE/64 "ADI version tag"s in there?

No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte. 
There is enough space for just one tag per page. DaveM had suggested 
doing this since the usual case is for a task to set one tag per page 
even though MMU does not require it. I have implemented this as first 
pass to start a discussion and get feedback on whether rest of the 
swapping implementation and other changes look right, hence the patch is 
"RFC". If this all looks good, I can expand swapping support in a 
subsequent patch or iteration of this patch to allocate space in 
mm_context_t possibly to store per cacheline tags. I am open to any 
other ideas on storing this larger number of version tags.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1552267

On 01/04/2017 04:26 PM, Khalid Aziz wrote:
...
> No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte.
> There is enough space for just one tag per page. DaveM had suggested
> doing this since the usual case is for a task to set one tag per page
> even though MMU does not require it. I have implemented this as first
> pass to start a discussion and get feedback on whether rest of the
> swapping implementation and other changes look right, hence the patch is
> "RFC". If this all looks good, I can expand swapping support in a
> subsequent patch or iteration of this patch to allocate space in
> mm_context_t possibly to store per cacheline tags. I am open to any
> other ideas on storing this larger number of version tags.

FWIW, This is the kind of thing that would be really useful to point out
to reviewers instead of requiring them to ferret it out of the code.  It
has huge implications for how applications use this feature.

As for where to store the tags...  It's potentially a *lot* of data, so
I think it'll be a pain any way you do it.

If you, instead, can live with doing things on a PAGE_SIZE granularity
like pkeys does, you could just store it in the VMA and have the kernel
tag the data at the same time it zeroes the pages.

[toc] | [prev] | [next] | [standalone]

#1552317

On 01/05/2017 12:22 PM, Dave Hansen wrote:
> On 01/04/2017 04:26 PM, Khalid Aziz wrote:
> ...
>> No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte.
>> There is enough space for just one tag per page. DaveM had suggested
>> doing this since the usual case is for a task to set one tag per page
>> even though MMU does not require it. I have implemented this as first
>> pass to start a discussion and get feedback on whether rest of the
>> swapping implementation and other changes look right, hence the patch is
>> "RFC". If this all looks good, I can expand swapping support in a
>> subsequent patch or iteration of this patch to allocate space in
>> mm_context_t possibly to store per cacheline tags. I am open to any
>> other ideas on storing this larger number of version tags.
>
> FWIW, This is the kind of thing that would be really useful to point out
> to reviewers instead of requiring them to ferret it out of the code.  It
> has huge implications for how applications use this feature.

Hi Dave,

Thanks for taking the time to review this. I appreciate your patience. I 
will add more details.

>
> As for where to store the tags...  It's potentially a *lot* of data, so
> I think it'll be a pain any way you do it.
>
> If you, instead, can live with doing things on a PAGE_SIZE granularity
> like pkeys does, you could just store it in the VMA and have the kernel
> tag the data at the same time it zeroes the pages.

It is very tempting to restrict tags to PAGE_SIZE granularity since it 
makes code noticeably simpler and that is indeed going to be the 
majority of cases. Sooner or later somebody would want to use multiple 
tags per page though. There can be 128 4-bit tags per 8K page which 
requires 64 bytes of tag storage for each page. This can add up. What I 
am considering doing is store the tag in swp pte if I find only one tag 
on the page. A VMA can cover multiple pages and we have unused bits in 
swp pte. It makes more sense to store the tags in swp pte. If I find 
more than one tag on the page, I can allocate memory, attach it to a 
data structure in mm_context_t and store the tags there. I will need to 
use an rb tree or some other way to keep the data sorted to make it 
quick to retrieve the tags for one of the millions of pages a task might 
have. As I said, it gets complex trying to store tags per cacheline as 
opposed to per page :)

--
Khalid

[toc] | [prev] | [next] | [standalone]

#1552627

On Thu 05-01-17 13:30:10, Khalid Aziz wrote:
[...]
> It is very tempting to restrict tags to PAGE_SIZE granularity since it makes
> code noticeably simpler and that is indeed going to be the majority of
> cases. Sooner or later somebody would want to use multiple tags per page
> though.

I didn't get to read the patch throughly yet but I am really confused by
this statement. The api is mprotect based which makes it ineherently
PAGE_SIZE granular. How do you want to achieve cache line granularity
with this API?

And I would really vote for simplicity first... Subpage granularity
sounds way too tricky...
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1552877

On 01/06/2017 07:32 AM, Khalid Aziz wrote:
> I agree with you on simplicity first. Subpage granularity is complex,
> but the architecture allows for subpage granularity. Maybe the right
> approach is to support this at page granularity first for swappable
> pages and then expand to subpage granularity in a subsequent patch?
> Pages locked in memory can already use subpage granularity with my patch.

What do you mean by "locked in memory"?  mlock()'d memory can still be
migrated around and still requires "swap" ptes, for instance.

[toc] | [prev] | [next] | [standalone]

#1552929

On 01/06/2017 08:36 AM, Dave Hansen wrote:
> On 01/06/2017 07:32 AM, Khalid Aziz wrote:
>> I agree with you on simplicity first. Subpage granularity is complex,
>> but the architecture allows for subpage granularity. Maybe the right
>> approach is to support this at page granularity first for swappable
>> pages and then expand to subpage granularity in a subsequent patch?
>> Pages locked in memory can already use subpage granularity with my patch.
>
> What do you mean by "locked in memory"?  mlock()'d memory can still be
> migrated around and still requires "swap" ptes, for instance.

You are right. Page migration can invalidate subpage granularity even 
for locked pages. Is it possible to use cpusets to keep a task and its 
memory locked on a single node? Just wondering if there are limited 
cases where subpage granularity could work without supporting subpage 
granularity for tags in swap. It still sounds like the right thing to do 
is to get a reliable implementation in place with page size granularity 
and then add the complexity of subpage granularity.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1552933

From: Khalid Aziz <khalid.aziz@oracle.com>
Date: Fri, 6 Jan 2017 09:22:13 -0700

> On 01/06/2017 08:36 AM, Dave Hansen wrote:
>> On 01/06/2017 07:32 AM, Khalid Aziz wrote:
>>> I agree with you on simplicity first. Subpage granularity is complex,
>>> but the architecture allows for subpage granularity. Maybe the right
>>> approach is to support this at page granularity first for swappable
>>> pages and then expand to subpage granularity in a subsequent patch?
>>> Pages locked in memory can already use subpage granularity with my
>>> patch.
>>
>> What do you mean by "locked in memory"?  mlock()'d memory can still be
>> migrated around and still requires "swap" ptes, for instance.
> 
> You are right. Page migration can invalidate subpage granularity even
> for locked pages. Is it possible to use cpusets to keep a task and its
> memory locked on a single node? Just wondering if there are limited
> cases where subpage granularity could work without supporting subpage
> granularity for tags in swap. It still sounds like the right thing to
> do is to get a reliable implementation in place with page size
> granularity and then add the complexity of subpage granularity.

It sounds to me, in all of this, that if the kernel manages the
movement of the pages, it thus must handle making sure the tags move
around with that page as well.

[toc] | [prev] | [next] | [standalone]

#1552960

On 01/06/2017 08:22 AM, Khalid Aziz wrote:
> On 01/06/2017 08:36 AM, Dave Hansen wrote:
>> On 01/06/2017 07:32 AM, Khalid Aziz wrote:
>>> I agree with you on simplicity first. Subpage granularity is complex,
>>> but the architecture allows for subpage granularity. Maybe the right
>>> approach is to support this at page granularity first for swappable
>>> pages and then expand to subpage granularity in a subsequent patch?
>>> Pages locked in memory can already use subpage granularity with my
>>> patch.
>>
>> What do you mean by "locked in memory"?  mlock()'d memory can still be
>> migrated around and still requires "swap" ptes, for instance.
> 
> You are right. Page migration can invalidate subpage granularity even
> for locked pages. Is it possible to use cpusets to keep a task and its
> memory locked on a single node?

It's going to be hard to impossible to guarantee.  mlock() doesn't
guarantee that things won't change physical addresses.  You'd have to
change that guarantee or chase all the things in the kernel that might
change physical addresses (compaction, ksm, etc...).

Actually, that reminds me...  How does your code interface with ksm?  Or
is there no interaction needed since you're always working on virtual
addresses?

[toc] | [prev] | [next] | [standalone]

#1552970

From: Dave Hansen <dave.hansen@linux.intel.com>
Date: Fri, 6 Jan 2017 08:55:03 -0800

> Actually, that reminds me...  How does your code interface with ksm?  Or
> is there no interaction needed since you're always working on virtual
> addresses?

This reminds me, I consider this feature potentially extremely useful for
kernel debugging.  So I would like to make sure we don't implement anything
in a way which would preclude that in the long term.

[toc] | [prev] | [next] | [standalone]

#1552979

On 01/06/2017 10:02 AM, David Miller wrote:
> From: Dave Hansen <dave.hansen@linux.intel.com>
> Date: Fri, 6 Jan 2017 08:55:03 -0800
>
>> Actually, that reminds me...  How does your code interface with ksm?  Or
>> is there no interaction needed since you're always working on virtual
>> addresses?
>
> This reminds me, I consider this feature potentially extremely useful for
> kernel debugging.  So I would like to make sure we don't implement anything
> in a way which would preclude that in the long term.

I agree and please do point out if I have made any implementation 
decisions that could preclude that.

Thanks,
Khalid

[toc] | [prev] | [next] | [standalone]

#1552998

On 01/06/2017 09:10 AM, Khalid Aziz wrote:
> On 01/06/2017 10:02 AM, David Miller wrote:
>> From: Dave Hansen <dave.hansen@linux.intel.com>
>> Date: Fri, 6 Jan 2017 08:55:03 -0800
>>
>>> Actually, that reminds me...  How does your code interface with 
>>> ksm?  Or
>>> is there no interaction needed since you're always working on virtual
>>> addresses?
>>
>> This reminds me, I consider this feature potentially extremely useful 
>> for
>> kernel debugging.  So I would like to make sure we don't implement 
>> anything
>> in a way which would preclude that in the long term.
>
> I agree and please do point out if I have made any implementation 
> decisions that could preclude that.
>
> Thanks,
> Khalid


Khalid, I have already pointed out an implementation decision that 
interferes with the potential for kernel debugging with ADI: lazy 
clearing of version tags.

Details: when memory is "freed" the version tags are left alone, as it 
is an expensive operation to go through the memory and clear the tag for 
each cache line. So this is done lazily whenever memory is "allocated". 
More specifically, the first time a user process touches freshly 
allocated memory, a fault occurs and the kernel then clears the page. In 
the NG4 and M7 variants of clear_user_page, the block init store ASI is 
used to optimize, and it has the side effect of clearing the ADI tag for 
the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set, 
then instead of the ADI tag being cleared, the tag is *checked*, and if 
there is a mismatch between the version in the virtual address and the 
version in memory, then you'll get a trap and panic. Therefore, with 
this design, you cannot have pstate.mcde enabled while in the kernel (in 
general). To solve this you have to check the state of pstate.mcde (or 
just turn it off) before doing any block init store in clear_user_page, 
memset, memcpy, etc.

Rob

[toc] | [prev] | [next] | [standalone]

#1553014

On 01/06/2017 10:54 AM, Rob Gardner wrote:
> On 01/06/2017 09:10 AM, Khalid Aziz wrote:
>> On 01/06/2017 10:02 AM, David Miller wrote:
>>> From: Dave Hansen <dave.hansen@linux.intel.com>
>>> Date: Fri, 6 Jan 2017 08:55:03 -0800
>>>
>>>> Actually, that reminds me...  How does your code interface with
>>>> ksm?  Or
>>>> is there no interaction needed since you're always working on virtual
>>>> addresses?
>>>
>>> This reminds me, I consider this feature potentially extremely useful
>>> for
>>> kernel debugging.  So I would like to make sure we don't implement
>>> anything
>>> in a way which would preclude that in the long term.
>>
>> I agree and please do point out if I have made any implementation
>> decisions that could preclude that.
>>
>> Thanks,
>> Khalid
>
>
> Khalid, I have already pointed out an implementation decision that
> interferes with the potential for kernel debugging with ADI: lazy
> clearing of version tags.

This does not preclude kernel debugging. If kernel debugging ends up 
requiring tags be cleared whenever a page is freed, we can add that code 
as part of kernel debugging support code and enable it conditionally 
only when kernel is being debugged. Forcing every task to incur the 
large cost of clearing tags on every "free" all the time is just not an 
acceptable cost only to support kernel debugging. It should be a dynamic 
switch to be toggled on only when debugging kernel. PSTATE.mcde being 
set is not enough to trigger a trap. It is easy enough to clear TTE.mcd 
before block initialization of a page and avoid a trap due to tag 
mismatch, or just use physical address with block initialization.

We can evaluate all of these options when we get to implementing kernel 
debugging using ADI.

Thanks,
Khalid


>
> Details: when memory is "freed" the version tags are left alone, as it
> is an expensive operation to go through the memory and clear the tag for
> each cache line. So this is done lazily whenever memory is "allocated".
> More specifically, the first time a user process touches freshly
> allocated memory, a fault occurs and the kernel then clears the page. In
> the NG4 and M7 variants of clear_user_page, the block init store ASI is
> used to optimize, and it has the side effect of clearing the ADI tag for
> the cache line. BUT only if pstate.mcde is clear. If pstate.mcde is set,
> then instead of the ADI tag being cleared, the tag is *checked*, and if
> there is a mismatch between the version in the virtual address and the
> version in memory, then you'll get a trap and panic. Therefore, with
> this design, you cannot have pstate.mcde enabled while in the kernel (in
> general). To solve this you have to check the state of pstate.mcde (or
> just turn it off) before doing any block init store in clear_user_page,
> memset, memcpy, etc.
>
> Rob
>
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web