From: qiuxishi@huawei.com (Xishi Qiu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Allow vmalloc regions to be set with set_memory_*
Date: Sat, 30 Jan 2016 10:48:02 +0800 [thread overview]
Message-ID: <56AC2462.20506@huawei.com> (raw)
In-Reply-To: <20160129110252.GB17038@leverpostej>
On 2016/1/29 19:02, Mark Rutland wrote:
> On Fri, Jan 29, 2016 at 09:21:40AM +0800, Xishi Qiu wrote:
>> On 2016/1/28 22:27, Mark Rutland wrote:
>>> On Thu, Jan 28, 2016 at 07:47:09PM +0800, Xishi Qiu wrote:
>>>> Hi Mark,
>>>>
>>>> Is it safe in the following path?
>>>>
>>>> alloc the whole linear map section
>>>
>>> I don't understand what you mean by this, you will need to elaborate.
>>> The terms "alloc" and "section" can mean a number of different things in
>>> this context.
>>>
>>>> cpu A write something on it
>>>> cpu B write something on it
>>>> cpu C set read only flag and call flush_tlb_kernel_range()
>>>
>>> If you want to modify a portion of the linear map, this will not work.
>>> Modfiying the linear map in this manner is not safe.
>>>
>>> If you want an alias of the linear map which was mapped using pages, and
>>> you wanted to change that alias, that could work.
>>>
>>
>> Hi Mark,
>>
>> I mean I change the whole section(maybe 1G?) in linear map.
>
> If you mean something that was mapped with a section (i.e. a block entry
> in some level of page table), then no. The linear map is not open to
> this kind of change, as portions of the region may be in use elsewhere
> within Linux.
>
>> In our software, kernel create mapping(linear map) on special memory,
>> and
>> it is separated from buddy system, the service manage the special memory itself.
>
> This is not what the linear map is for. What exactly is this "special
> memory"?
>
> Is it some persistent memory?
>
> Is it normal memory that you wish to use for some communication with
> other agents and/or DMA?
>
> Is it normal memory that you simply have a special use-case for?
>
>> And the service alloc/free the memory based on the physical address, so if
>> the service want to change the prot dynamically, vmalloc doesn't work, and
>> fixmap is a little complex.
>
> Without further explanation of your use-case, this doesn't make sense to
> me. I don't understand why the physical address matters -- that implies
> you have other agents accessing this memory. If that's the case, I don't
> see what changing the permissions buys you.
>
> Regardless, it sounds like either we're missing some infrastructure, or
> you are mis-using existing APIs.
>
>> I think if I create the spacial memory in 4kb, then the service could
>> use set_memory_ro() directly, right?
>
> Perhaps. If it's a vmalloc'd area, then yes (once Ard's patch to allow
> that is in). I have more general concerns with your approach, in that I
> still do not understand the problem you are trying to solve.
>
Hi Mark,
Thanks for your reply. Maybe I didn't express it clearly, sorry for it.
The abstract process is the following:
1. do not create a large block, use 4kb for all of the memory(regardless of performance).
setup_arch->paging_init()->map_mem()->__map_memblock()->create_mapping()
2. alloc a page and get the the linear mapping address.
3. modify judgment condition of the function set_memory_ro(), so it could handle the linear mapping range.
4. use set_memory_ro() to change the prot flag of the page which we get in step 2.
Is it safe?
Thanks,
Xishi Qiu
> Thanks,
> Mark.
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Laura Abbott <labbott@fedoraproject.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Kees Cook <keescook@chromium.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
zhong jiang <zhongjiang@huawei.com>, <steve.capper@arm.com>,
Hanjun Guo <guohanjun@huawei.com>
Subject: Re: [PATCH] arm64: Allow vmalloc regions to be set with set_memory_*
Date: Sat, 30 Jan 2016 10:48:02 +0800 [thread overview]
Message-ID: <56AC2462.20506@huawei.com> (raw)
In-Reply-To: <20160129110252.GB17038@leverpostej>
On 2016/1/29 19:02, Mark Rutland wrote:
> On Fri, Jan 29, 2016 at 09:21:40AM +0800, Xishi Qiu wrote:
>> On 2016/1/28 22:27, Mark Rutland wrote:
>>> On Thu, Jan 28, 2016 at 07:47:09PM +0800, Xishi Qiu wrote:
>>>> Hi Mark,
>>>>
>>>> Is it safe in the following path?
>>>>
>>>> alloc the whole linear map section
>>>
>>> I don't understand what you mean by this, you will need to elaborate.
>>> The terms "alloc" and "section" can mean a number of different things in
>>> this context.
>>>
>>>> cpu A write something on it
>>>> cpu B write something on it
>>>> cpu C set read only flag and call flush_tlb_kernel_range()
>>>
>>> If you want to modify a portion of the linear map, this will not work.
>>> Modfiying the linear map in this manner is not safe.
>>>
>>> If you want an alias of the linear map which was mapped using pages, and
>>> you wanted to change that alias, that could work.
>>>
>>
>> Hi Mark,
>>
>> I mean I change the whole section(maybe 1G?) in linear map.
>
> If you mean something that was mapped with a section (i.e. a block entry
> in some level of page table), then no. The linear map is not open to
> this kind of change, as portions of the region may be in use elsewhere
> within Linux.
>
>> In our software, kernel create mapping(linear map) on special memory,
>> and
>> it is separated from buddy system, the service manage the special memory itself.
>
> This is not what the linear map is for. What exactly is this "special
> memory"?
>
> Is it some persistent memory?
>
> Is it normal memory that you wish to use for some communication with
> other agents and/or DMA?
>
> Is it normal memory that you simply have a special use-case for?
>
>> And the service alloc/free the memory based on the physical address, so if
>> the service want to change the prot dynamically, vmalloc doesn't work, and
>> fixmap is a little complex.
>
> Without further explanation of your use-case, this doesn't make sense to
> me. I don't understand why the physical address matters -- that implies
> you have other agents accessing this memory. If that's the case, I don't
> see what changing the permissions buys you.
>
> Regardless, it sounds like either we're missing some infrastructure, or
> you are mis-using existing APIs.
>
>> I think if I create the spacial memory in 4kb, then the service could
>> use set_memory_ro() directly, right?
>
> Perhaps. If it's a vmalloc'd area, then yes (once Ard's patch to allow
> that is in). I have more general concerns with your approach, in that I
> still do not understand the problem you are trying to solve.
>
Hi Mark,
Thanks for your reply. Maybe I didn't express it clearly, sorry for it.
The abstract process is the following:
1. do not create a large block, use 4kb for all of the memory(regardless of performance).
setup_arch->paging_init()->map_mem()->__map_memblock()->create_mapping()
2. alloc a page and get the the linear mapping address.
3. modify judgment condition of the function set_memory_ro(), so it could handle the linear mapping range.
4. use set_memory_ro() to change the prot flag of the page which we get in step 2.
Is it safe?
Thanks,
Xishi Qiu
> Thanks,
> Mark.
>
> .
>
next prev parent reply other threads:[~2016-01-30 2:48 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 21:46 [PATCH] arm64: Allow vmalloc regions to be set with set_memory_* Laura Abbott
2016-01-12 21:46 ` Laura Abbott
2016-01-13 0:01 ` Alexei Starovoitov
2016-01-13 0:01 ` Alexei Starovoitov
2016-01-13 0:31 ` Daniel Borkmann
2016-01-13 0:31 ` Daniel Borkmann
2016-01-13 14:03 ` Ard Biesheuvel
2016-01-13 14:03 ` Ard Biesheuvel
2016-01-13 16:10 ` Ard Biesheuvel
2016-01-13 16:10 ` Ard Biesheuvel
2016-01-14 23:01 ` Laura Abbott
2016-01-14 23:01 ` Laura Abbott
2016-01-18 11:56 ` Mark Rutland
2016-01-18 11:56 ` Mark Rutland
2016-01-28 1:47 ` Xishi Qiu
2016-01-28 1:47 ` Xishi Qiu
2016-01-28 10:51 ` Mark Rutland
2016-01-28 10:51 ` Mark Rutland
2016-01-28 11:47 ` Xishi Qiu
2016-01-28 11:47 ` Xishi Qiu
2016-01-28 14:27 ` Mark Rutland
2016-01-28 14:27 ` Mark Rutland
2016-01-29 1:21 ` Xishi Qiu
2016-01-29 1:21 ` Xishi Qiu
2016-01-29 11:02 ` Mark Rutland
2016-01-29 11:02 ` Mark Rutland
2016-01-30 2:48 ` Xishi Qiu [this message]
2016-01-30 2:48 ` Xishi Qiu
2016-02-03 13:43 ` Mark Rutland
2016-02-03 13:43 ` Mark Rutland
-- strict thread matches above, loose matches on Subject: below --
2016-01-18 14:01 [PATCH] arm64: allow " Ard Biesheuvel
2016-01-18 15:05 ` Mark Rutland
2016-01-28 15:08 ` Will Deacon
2016-01-28 16:40 ` Ard Biesheuvel
2016-01-28 16:43 ` Ard Biesheuvel
2016-01-28 18:10 ` Will Deacon
2016-01-28 19:07 ` Ard Biesheuvel
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=56AC2462.20506@huawei.com \
--to=qiuxishi@huawei.com \
--cc=linux-arm-kernel@lists.infradead.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 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.