On 04/05/18 01:55, Dave Hansen wrote:
On 05/03/2018 02:52 PM, Igor Stoppa wrote:
At the end of the summit, we agreed that I would go through the physmap.
Do you mean the kernel linear map?
Apparently I did mean it. It was confusing, because I couldn't find a
single place stating it
On 04/05/18 01:55, Dave Hansen wrote:
On 05/03/2018 02:52 PM, Igor Stoppa wrote:
At the end of the summit, we agreed that I would go through the physmap.
Do you mean the kernel linear map?
Apparently I did mean it. It was confusing, because I couldn't find a
single place stating it
On 05/03/2018 02:52 PM, Igor Stoppa wrote:
> At the end of the summit, we agreed that I would go through the physmap.
Do you mean the kernel linear map? That's just another name for the
virtual address that you get back from page_to_virt():
int *j = page_to_virt(vmalloc_to_page(i));
On 05/03/2018 02:52 PM, Igor Stoppa wrote:
> At the end of the summit, we agreed that I would go through the physmap.
Do you mean the kernel linear map? That's just another name for the
virtual address that you get back from page_to_virt():
int *j = page_to_virt(vmalloc_to_page(i));
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data,
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data,
On 24/04/18 18:44, Matthew Wilcox wrote:
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d and destroy the old pool.
With the
On 24/04/18 18:44, Matthew Wilcox wrote:
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d and destroy the old pool.
With the
On 24/04/18 16:33, Igor Stoppa wrote:
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to
On 24/04/18 16:33, Igor Stoppa wrote:
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to
On 24/04/18 19:03, lazytyped wrote:
On 4/24/18 4:44 PM, Matthew Wilcox wrote:
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d
On 24/04/18 19:03, lazytyped wrote:
On 4/24/18 4:44 PM, Matthew Wilcox wrote:
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d
On 4/24/18 4:44 PM, Matthew Wilcox wrote:
> On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
>> On 4/24/18 1:50 PM, Matthew Wilcox wrote:
>>> struct modifiable_data {
>>> struct immutable_data *d;
>>> ...
>>> };
>>>
>>> Then allocate a new pool, change d and destroy the old
On 4/24/18 4:44 PM, Matthew Wilcox wrote:
> On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
>> On 4/24/18 1:50 PM, Matthew Wilcox wrote:
>>> struct modifiable_data {
>>> struct immutable_data *d;
>>> ...
>>> };
>>>
>>> Then allocate a new pool, change d and destroy the old
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
> On 4/24/18 1:50 PM, Matthew Wilcox wrote:
> > struct modifiable_data {
> > struct immutable_data *d;
> > ...
> > };
> >
> > Then allocate a new pool, change d and destroy the old pool.
>
> With the above, you have just shifted
On Tue, Apr 24, 2018 at 02:32:36PM +0200, lazytyped wrote:
> On 4/24/18 1:50 PM, Matthew Wilcox wrote:
> > struct modifiable_data {
> > struct immutable_data *d;
> > ...
> > };
> >
> > Then allocate a new pool, change d and destroy the old pool.
>
> With the above, you have just shifted
On 24/04/18 16:32, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d and destroy the old pool.
With the above, you have just shifted the target of the arbitrary write
On 24/04/18 16:32, lazytyped wrote:
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
struct modifiable_data {
struct immutable_data *d;
...
};
Then allocate a new pool, change d and destroy the old pool.
With the above, you have just shifted the target of the arbitrary write
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data,
On 24/04/18 15:50, Matthew Wilcox wrote:
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data,
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
> struct modifiable_data {
> struct immutable_data *d;
> ...
> };
>
> Then allocate a new pool, change d and destroy the old pool.
With the above, you have just shifted the target of the arbitrary write
from the immutable data itself to the
On 4/24/18 1:50 PM, Matthew Wilcox wrote:
> struct modifiable_data {
> struct immutable_data *d;
> ...
> };
>
> Then allocate a new pool, change d and destroy the old pool.
With the above, you have just shifted the target of the arbitrary write
from the immutable data itself to the
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
> While the vanilla version of pmalloc provides support for permanently
> transitioning between writable and read-only of a memory pool, this
> patch seeks to support a separate class of data, which would still
> benefit from write
On Mon, Apr 23, 2018 at 04:54:56PM +0400, Igor Stoppa wrote:
> While the vanilla version of pmalloc provides support for permanently
> transitioning between writable and read-only of a memory pool, this
> patch seeks to support a separate class of data, which would still
> benefit from write
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data, which would still
benefit from write protection, most of the time, but it still needs to
be modifiable. Maybe
While the vanilla version of pmalloc provides support for permanently
transitioning between writable and read-only of a memory pool, this
patch seeks to support a separate class of data, which would still
benefit from write protection, most of the time, but it still needs to
be modifiable. Maybe
26 matches
Mail list logo
