Re: [PATCH 10/17] prmem: documentation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 30/10/2018 23:02, Andy Lutomirski wrote:


On Oct 30, 2018, at 1:43 PM, Igor Stoppa <igor.stoppa@xxxxxxxxx> wrote:


There is no need to process each of these tens of thousands allocations and initialization as write-rare.

Would it be possible to do the same here?

I don’t see why not, although getting the API right will be a tad complicated.

yes, I have some first-hand experience with this :-/



To subsequently modify q,

    p = rare_modify(q);
    q->a = y;

Do you mean

     p->a = y;

here? I assume the intent is that q isn't writable ever, but that's
the one we have in the structure at rest.
Yes, that was my intent, thanks.
To handle the list case that Igor has pointed out, you might want to
do something like this:
    list_for_each_entry(x, &xs, entry) {
        struct foo *writable = rare_modify(entry);

Would this mapping be impossible to spoof by other cores?


Indeed. Only the core with the special mm loaded could see it.

But I dislike allowing regular writes in the protected region. We really only need four write primitives:

1. Just write one value.  Call at any time (except NMI).

2. Just copy some bytes. Same as (1) but any number of bytes.

3,4: Same as 1 and 2 but must be called inside a special rare write region. This is purely an optimization.

Atomic? RCU?

Yes, they are technically just memory writes, but shouldn't the "normal" operation be executed on the writable mapping?

It is possible to sandwich any call between a rare_modify/rare_protect, however isn't that pretty close to having a write-rare version of these plain function.

--
igor



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux