that the patch works correctly.
Eventually, the extra parameter (and the corresponding verification)
could be dropped, in favor of a simplified API.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/genalloc.h | 112 +++
lib/genalloc.c
that the patch works correctly.
Eventually, the extra parameter (and the corresponding verification)
could be dropped, in favor of a simplified API.
Signed-off-by: Igor Stoppa
---
include/linux/genalloc.h | 112 +++
lib/genalloc.c | 742 ++-
2
izes of
allocation is likely to eat up much more memory than the bitmap.
Igor Stoppa (8):
genalloc: track beginning of allocations
Add label to genalloc.rst for cross reference
genalloc: selftest
struct page: add field for vm_struct
Protectable Memory
Pmalloc selftest
lkdtm: c
izes of
allocation is likely to eat up much more memory than the bitmap.
Igor Stoppa (8):
genalloc: track beginning of allocations
Add label to genalloc.rst for cross reference
genalloc: selftest
struct page: add field for vm_struct
Protectable Memory
Pmalloc selftest
lkdtm: c
On 12/03/18 21:13, Matthew Wilcox wrote:
> On Wed, Feb 28, 2018 at 10:06:17PM +0200, Igor Stoppa wrote:
>> struct gen_pool *pmalloc_create_pool(const char *name,
>> int min_alloc_order);
>> int is_pmalloc_object(const void *ptr,
On 12/03/18 21:13, Matthew Wilcox wrote:
> On Wed, Feb 28, 2018 at 10:06:17PM +0200, Igor Stoppa wrote:
>> struct gen_pool *pmalloc_create_pool(const char *name,
>> int min_alloc_order);
>> int is_pmalloc_object(const void *ptr,
On 07/03/18 16:48, Igor Stoppa wrote:
>
>
> On 06/03/18 15:19, Mike Rapoport wrote:
>> On Wed, Feb 28, 2018 at 10:06:14PM +0200, Igor Stoppa wrote:
[...]
>>> + * get_boundary() - verifies address, then measure length.
>>
>> There's some lack of consistency
On 07/03/18 16:48, Igor Stoppa wrote:
>
>
> On 06/03/18 15:19, Mike Rapoport wrote:
>> On Wed, Feb 28, 2018 at 10:06:14PM +0200, Igor Stoppa wrote:
[...]
>>> + * get_boundary() - verifies address, then measure length.
>>
>> There's some lack of consistency
On 06/03/18 15:19, Mike Rapoport wrote:
> On Wed, Feb 28, 2018 at 10:06:14PM +0200, Igor Stoppa wrote:
[...]
> If I'm not mistaken, several kernel-doc descriptions are duplicated now.
> Can you please keep a single copy? ;-)
What's the preferred approach?
Document the functions tha
On 06/03/18 15:19, Mike Rapoport wrote:
> On Wed, Feb 28, 2018 at 10:06:14PM +0200, Igor Stoppa wrote:
[...]
> If I'm not mistaken, several kernel-doc descriptions are duplicated now.
> Can you please keep a single copy? ;-)
What's the preferred approach?
Document the functions tha
On 06/03/18 05:59, J Freyensee wrote:
[...]
>> +config PROTECTABLE_MEMORY
>> +bool
>> +depends on MMU
>
>
> Curious, would you also want to depend on "SECURITY" as well, as this is
> being advertised as a compliment to __read_only_after_init, per the file
> header comments, as I'm
On 06/03/18 05:59, J Freyensee wrote:
[...]
>> +config PROTECTABLE_MEMORY
>> +bool
>> +depends on MMU
>
>
> Curious, would you also want to depend on "SECURITY" as well, as this is
> being advertised as a compliment to __read_only_after_init, per the file
> header comments, as I'm
On 06/03/18 19:20, J Freyensee wrote:
> On 2/28/18 12:06 PM, Igor Stoppa wrote:
[...]
>> void __init lkdtm_perms_init(void);
>> void lkdtm_WRITE_RO(void);
>> void lkdtm_WRITE_RO_AFTER_INIT(void);
>> +void lkdtm_WRITE_RO_PMALLOC(void);
>
> Does
On 06/03/18 19:20, J Freyensee wrote:
> On 2/28/18 12:06 PM, Igor Stoppa wrote:
[...]
>> void __init lkdtm_perms_init(void);
>> void lkdtm_WRITE_RO(void);
>> void lkdtm_WRITE_RO_AFTER_INIT(void);
>> +void lkdtm_WRITE_RO_PMALLOC(void);
>
> Does
On 06/03/18 18:05, Igor Stoppa wrote:
> On 06/03/2018 16:10, Matthew Wilcox wrote:
[...]
>> This seems unnecessarily complicated.
>
> TBH it seemed to me a natural extension of the existing encoding :-)
BTW, to provide some background, this is where it begun:
http://www.ope
On 06/03/18 18:05, Igor Stoppa wrote:
> On 06/03/2018 16:10, Matthew Wilcox wrote:
[...]
>> This seems unnecessarily complicated.
>
> TBH it seemed to me a natural extension of the existing encoding :-)
BTW, to provide some background, this is where it begun:
http://www.ope
On 05/03/2018 21:00, J Freyensee wrote:
> .
> .
>
>
> On 2/28/18 12:06 PM, Igor Stoppa wrote:
>> +
>> +/**
>> + * gen_pool_dma_alloc() - allocate special memory from the pool for DMA
>> usage
>> + * @pool: pool to allocate from
>> +
On 05/03/2018 21:00, J Freyensee wrote:
> .
> .
>
>
> On 2/28/18 12:06 PM, Igor Stoppa wrote:
>> +
>> +/**
>> + * gen_pool_dma_alloc() - allocate special memory from the pool for DMA
>> usage
>> + * @pool: pool to allocate from
>> +
On 06/03/2018 16:10, Matthew Wilcox wrote:
> On Wed, Feb 28, 2018 at 10:06:14PM +0200, Igor Stoppa wrote:
>> + * Encoding of the bitmap tracking the allocations
>> + * ---
>> + *
>> + * The bitmap is composed of units of allo
On 06/03/2018 16:10, Matthew Wilcox wrote:
> On Wed, Feb 28, 2018 at 10:06:14PM +0200, Igor Stoppa wrote:
>> + * Encoding of the bitmap tracking the allocations
>> + * ---
>> + *
>> + * The bitmap is composed of units of allo
Ping?
The kernel test automation seems to confirm my findings:
https://marc.info/?l=linux-mm=151999308428656=2
Is this really a bug?
On 22/02/18 16:13, Igor Stoppa wrote:
> While trying to change the code of find_vm_area, I got an automated
> notification that my code was breaking the t
Ping?
The kernel test automation seems to confirm my findings:
https://marc.info/?l=linux-mm=151999308428656=2
Is this really a bug?
On 22/02/18 16:13, Igor Stoppa wrote:
> While trying to change the code of find_vm_area, I got an automated
> notification that my code was breaking the t
Detailed documentation about the protectable memory allocator.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
Documentation/core-api/index.rst | 1 +
Documentation/core-api/pmalloc.rst | 111 +
2 files changed, 112 insertions(+)
creat
Detailed documentation about the protectable memory allocator.
Signed-off-by: Igor Stoppa
---
Documentation/core-api/index.rst | 1 +
Documentation/core-api/pmalloc.rst | 111 +
2 files changed, 112 insertions(+)
create mode 100644 Documentation/core-api
Verify that pmalloc read-only protection is in place: trying to
overwrite a protected variable will crash the kernel.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
drivers/misc/lkdtm.h | 1 +
drivers/misc/lkdtm_core.c | 3 +++
drivers/misc/lkdtm_perms.
Verify that pmalloc read-only protection is in place: trying to
overwrite a protected variable will crash the kernel.
Signed-off-by: Igor Stoppa
---
drivers/misc/lkdtm.h | 1 +
drivers/misc/lkdtm_core.c | 3 +++
drivers/misc/lkdtm_perms.c | 28
3 files
Add basic self-test functionality for pmalloc.
The testing is introduced as early as possible, right after the main
dependency, genalloc, has passed successfully, so that it can help
diagnosing failures in pmalloc users.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include
Add basic self-test functionality for pmalloc.
The testing is introduced as early as possible, right after the main
dependency, genalloc, has passed successfully, so that it can help
diagnosing failures in pmalloc users.
Signed-off-by: Igor Stoppa
---
include/linux/test_pmalloc.h | 24
.
At the same time, being also based on genalloc, pmalloc does not
generate as much trashing of the TLB as it would be caused by using
directly only vmalloc.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/genalloc.h | 13 ++
include/linux/pmalloc.h
.
At the same time, being also based on genalloc, pmalloc does not
generate as much trashing of the TLB as it would be caused by using
directly only vmalloc.
Signed-off-by: Igor Stoppa
---
include/linux/genalloc.h | 13 ++
include/linux/pmalloc.h | 242
include/linux/vmalloc.h
arent area.
This will avoid more expensive searches, later on.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/mm_types.h | 1 +
mm/vmalloc.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
in
arent area.
This will avoid more expensive searches, later on.
Signed-off-by: Igor Stoppa
---
include/linux/mm_types.h | 1 +
mm/vmalloc.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index fd1af6b9591d..c3a4825e10c0 100644
---
that the patch works correctly.
Eventually, the extra parameter (and the corresponding verification)
could be dropped, in favor of a simplified API.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/genalloc.h | 354 ---
lib/genalloc.c
it as module.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/test_genalloc.h | 26 +++
init/main.c | 2 +
lib/Kconfig | 15 ++
lib/Makefile | 1 +
lib/test_genalloc.c
that the patch works correctly.
Eventually, the extra parameter (and the corresponding verification)
could be dropped, in favor of a simplified API.
Signed-off-by: Igor Stoppa
---
include/linux/genalloc.h | 354 ---
lib/genalloc.c | 721
it as module.
Signed-off-by: Igor Stoppa
---
include/linux/test_genalloc.h | 26 +++
init/main.c | 2 +
lib/Kconfig | 15 ++
lib/Makefile | 1 +
lib/test_genalloc.c | 410 ++
5 files changed
case of allocating memory from protected pool
* fixed kerneldoc description also for genalloc.h
* added missing Kconfig dependency for pmalloc, on MMU
* fixed location of initialization of link page struct -> vm_area
Igor Stoppa (7):
genalloc: track beginning of allocations
genalloc: selft
case of allocating memory from protected pool
* fixed kerneldoc description also for genalloc.h
* added missing Kconfig dependency for pmalloc, on MMU
* fixed location of initialization of link page struct -> vm_area
Igor Stoppa (7):
genalloc: track beginning of allocations
genalloc: selft
On 26/02/18 21:12, Matthew Wilcox wrote:
[...]
> panic() halts the kernel
> BUG_ON() kills the thread
> WARN_ON() just prints messages
>
> Now, if we're at boot time and we're still executing code from the init
> thread, killing init is equivalent to halting the kernel.
>
> The question is,
On 26/02/18 21:12, Matthew Wilcox wrote:
[...]
> panic() halts the kernel
> BUG_ON() kills the thread
> WARN_ON() just prints messages
>
> Now, if we're at boot time and we're still executing code from the init
> thread, killing init is equivalent to halting the kernel.
>
> The question is,
On 26/02/18 19:32, J Freyensee wrote:
> My replies also inlined.
>
> On 2/26/18 4:09 AM, Igor Stoppa wrote:
[...]
> But some of the code looks API'like to me, partly because of
> all the function header documentation, which thank you for that, but I
> wasn't sure where
On 26/02/18 19:32, J Freyensee wrote:
> My replies also inlined.
>
> On 2/26/18 4:09 AM, Igor Stoppa wrote:
[...]
> But some of the code looks API'like to me, partly because of
> all the function header documentation, which thank you for that, but I
> wasn't sure where
On 26/02/18 19:46, J Freyensee wrote:
>
>
> On 2/26/18 4:11 AM, Igor Stoppa wrote:
>>
>> On 24/02/18 00:42, J Freyensee wrote:
>>>> + locations[action->location] = gen_pool_alloc(pool, action->size);
>>>> + BUG_ON(!locations[action->loc
On 26/02/18 19:46, J Freyensee wrote:
>
>
> On 2/26/18 4:11 AM, Igor Stoppa wrote:
>>
>> On 24/02/18 00:42, J Freyensee wrote:
>>>> + locations[action->location] = gen_pool_alloc(pool, action->size);
>>>> + BUG_ON(!locations[action->loc
On 25/02/18 05:38, Matthew Wilcox wrote:
> On Fri, Feb 23, 2018 at 04:48:03PM +0200, Igor Stoppa wrote:
>> @@ -1769,6 +1771,9 @@ void *__vmalloc_node_range(unsigned long size,
>> unsigned long align,
>>
>> kmemleak_vmalloc(area, size, gfp_mask);
>&g
On 25/02/18 05:38, Matthew Wilcox wrote:
> On Fri, Feb 23, 2018 at 04:48:03PM +0200, Igor Stoppa wrote:
>> @@ -1769,6 +1771,9 @@ void *__vmalloc_node_range(unsigned long size,
>> unsigned long align,
>>
>> kmemleak_vmalloc(area, size, gfp_mask);
>&g
On 24/02/18 02:26, J Freyensee wrote:
>
>
> On 2/23/18 6:48 AM, Igor Stoppa wrote:
[...]
>> +- Before destroying a pool, all the memory allocated from it must be
>> + released.
>
> Is that true? pmalloc_destroy_pool() has:
>
> .
> .
> +
On 24/02/18 02:26, J Freyensee wrote:
>
>
> On 2/23/18 6:48 AM, Igor Stoppa wrote:
[...]
>> +- Before destroying a pool, all the memory allocated from it must be
>> + released.
>
> Is that true? pmalloc_destroy_pool() has:
>
> .
> .
> +
On 24/02/18 02:10, J Freyensee wrote:
> On 2/23/18 6:48 AM, Igor Stoppa wrote:
[...]
>> +struct gen_pool *pmalloc_create_pool(const char *name,
>> + int min_alloc_order);
>
> Same comments as earlier. If this is new API with new cod
On 24/02/18 02:10, J Freyensee wrote:
> On 2/23/18 6:48 AM, Igor Stoppa wrote:
[...]
>> +struct gen_pool *pmalloc_create_pool(const char *name,
>> + int min_alloc_order);
>
> Same comments as earlier. If this is new API with new cod
On 24/02/18 00:42, J Freyensee wrote:
>
>> +locations[action->location] = gen_pool_alloc(pool, action->size);
>> +BUG_ON(!locations[action->location]);
>
> Again, I'd think it through if you really want to use BUG_ON() or not:
>
> https://lwn.net/Articles/13183/
>
On 24/02/18 00:42, J Freyensee wrote:
>
>> +locations[action->location] = gen_pool_alloc(pool, action->size);
>> +BUG_ON(!locations[action->location]);
>
> Again, I'd think it through if you really want to use BUG_ON() or not:
>
> https://lwn.net/Articles/13183/
>
Hello,
and thanks for the reviews, my replies inlined below.
On 24/02/18 00:28, J Freyensee wrote:
> some code snipping
> .
> .
> .
>> +/**
>> + * get_bitmap_entry() - extracts the specified entry from the bitmap
>> + * @map: pointer to a bitmap
>> + * @entry_index: the index of the desired entry
Hello,
and thanks for the reviews, my replies inlined below.
On 24/02/18 00:28, J Freyensee wrote:
> some code snipping
> .
> .
> .
>> +/**
>> + * get_bitmap_entry() - extracts the specified entry from the bitmap
>> + * @map: pointer to a bitmap
>> + * @entry_index: the index of the desired entry
Detailed documentation about the protectable memory allocator.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
Documentation/core-api/index.rst | 1 +
Documentation/core-api/pmalloc.rst | 114 +
2 files changed, 115 insertions(+)
creat
Detailed documentation about the protectable memory allocator.
Signed-off-by: Igor Stoppa
---
Documentation/core-api/index.rst | 1 +
Documentation/core-api/pmalloc.rst | 114 +
2 files changed, 115 insertions(+)
create mode 100644 Documentation/core-api
Verify that pmalloc read-only protection is in place: trying to
overwrite a protected variable will crash the kernel.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
drivers/misc/lkdtm.h | 1 +
drivers/misc/lkdtm_core.c | 3 +++
drivers/misc/lkdtm_perms.
Verify that pmalloc read-only protection is in place: trying to
overwrite a protected variable will crash the kernel.
Signed-off-by: Igor Stoppa
---
drivers/misc/lkdtm.h | 1 +
drivers/misc/lkdtm_core.c | 3 +++
drivers/misc/lkdtm_perms.c | 28
3 files
Add basic self-test functionality for pmalloc.
The testing is introduced as early as possible, right after the main
dependency, genalloc, has passed successfully, so that it can help
diagnosing failures in pmalloc users.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include
Add basic self-test functionality for pmalloc.
The testing is introduced as early as possible, right after the main
dependency, genalloc, has passed successfully, so that it can help
diagnosing failures in pmalloc users.
Signed-off-by: Igor Stoppa
---
include/linux/test_pmalloc.h | 24
.
At the same time, being also based on genalloc, pmalloc does not
generate as much trashing of the TLB as it would be caused by using
directly only vmalloc.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/genalloc.h | 3 +
include/linux/pmalloc.h
.
At the same time, being also based on genalloc, pmalloc does not
generate as much trashing of the TLB as it would be caused by using
directly only vmalloc.
Signed-off-by: Igor Stoppa
---
include/linux/genalloc.h | 3 +
include/linux/pmalloc.h | 242 +++
include/linux/vmalloc.h
arent area.
This will avoid more expensive searches, later on.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/mm_types.h | 1 +
mm/vmalloc.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
in
arent area.
This will avoid more expensive searches, later on.
Signed-off-by: Igor Stoppa
---
include/linux/mm_types.h | 1 +
mm/vmalloc.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index fd1af6b9591d..c3a4825e1
it as module.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/test_genalloc.h | 26 +++
init/main.c | 2 +
lib/Kconfig | 15 ++
lib/Makefile | 1 +
lib/test_genalloc.c
it as module.
Signed-off-by: Igor Stoppa
---
include/linux/test_genalloc.h | 26 +++
init/main.c | 2 +
lib/Kconfig | 15 ++
lib/Makefile | 1 +
lib/test_genalloc.c | 410 ++
5 files changed
confirmation that the patch works correctly.
Eventually, the extra parameter (and the corresponding verification) could
be dropped, in favor of a simplified API.
Signed-off-by: Igor Stoppa <igor.sto...@huawei.com>
---
include/linux/genalloc.h | 4 +-
lib/genalloc.c
confirmation that the patch works correctly.
Eventually, the extra parameter (and the corresponding verification) could
be dropped, in favor of a simplified API.
Signed-off-by: Igor Stoppa
---
include/linux/genalloc.h | 4 +-
lib/genalloc.c | 631
nux-kernel@vger.kernel.org/msg1617030.html]
Igor Stoppa (7):
genalloc: track beginning of allocations
genalloc: selftest
struct page: add field for vm_struct
Protectable Memory
Pmalloc selftest
lkdtm: crash on overwriting protected pmalloc var
Documentation for Pmalloc
Documentation/core-api
nux-kernel@vger.kernel.org/msg1617030.html]
Igor Stoppa (7):
genalloc: track beginning of allocations
genalloc: selftest
struct page: add field for vm_struct
Protectable Memory
Pmalloc selftest
lkdtm: crash on overwriting protected pmalloc var
Documentation for Pmalloc
Documentation/core-api
On 22/02/18 11:14, Igor Stoppa wrote:
>
>
> On 22/02/18 00:28, Kees Cook wrote:
>> On Tue, Feb 20, 2018 at 8:59 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
>>>
>>>
>>> On 13/02/18 01:50, Kees Cook wrote:
>>>> On Mon, Feb 12, 2018
On 22/02/18 11:14, Igor Stoppa wrote:
>
>
> On 22/02/18 00:28, Kees Cook wrote:
>> On Tue, Feb 20, 2018 at 8:59 AM, Igor Stoppa wrote:
>>>
>>>
>>> On 13/02/18 01:50, Kees Cook wrote:
>>>> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa
>
On 21/02/18 14:01, Igor Stoppa wrote:
> it seems to return garbage also without this patch, but I need to clean
> up the code, try it again and possibly come up with a demo patch for
> triggering the problem.
>
> I'll investigate it more. However it doesn't see
On 21/02/18 14:01, Igor Stoppa wrote:
> it seems to return garbage also without this patch, but I need to clean
> up the code, try it again and possibly come up with a demo patch for
> triggering the problem.
>
> I'll investigate it more. However it doesn't see
this patch, when used with the config file for 0day kernel test for
i386, against 4.16-rc2, causes the following:
...
[8.686470] [TTM] Initializing DMA pool allocator
[8.691148] WARNING: CPU: 0 PID: 1 at mm/vmalloc.c:301
vmalloc_to_page+0x360/0x370
[8.692185] Modules linked in:
[
this patch, when used with the config file for 0day kernel test for
i386, against 4.16-rc2, causes the following:
...
[8.686470] [TTM] Initializing DMA pool allocator
[8.691148] WARNING: CPU: 0 PID: 1 at mm/vmalloc.c:301
vmalloc_to_page+0x360/0x370
[8.692185] Modules linked in:
[
any of my patches.
I'm still not 100% sure that I'm doing something sane, but I thought it
might be good to share the finding.
The patch contains both a minimal change, to trigger the crash, and a
snippet of the log of the crash i get.
Igor Stoppa (1):
crash vmalloc_to_page()
mm/vmalloc.c | 5
any of my patches.
I'm still not 100% sure that I'm doing something sane, but I thought it
might be good to share the finding.
The patch contains both a minimal change, to trigger the crash, and a
snippet of the log of the crash i get.
Igor Stoppa (1):
crash vmalloc_to_page()
mm/vmalloc.c | 5
On 22/02/18 00:28, Kees Cook wrote:
> On Tue, Feb 20, 2018 at 8:59 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
>>
>>
>> On 13/02/18 01:50, Kees Cook wrote:
>>> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
[...]
&
On 22/02/18 00:28, Kees Cook wrote:
> On Tue, Feb 20, 2018 at 8:59 AM, Igor Stoppa wrote:
>>
>>
>> On 13/02/18 01:50, Kees Cook wrote:
>>> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote:
[...]
>>>> + genalloc_selftest();
>>>
On 22/02/18 00:24, Kees Cook wrote:
> On Tue, Feb 20, 2018 at 8:40 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
[...]
>> sorry for being dense ... are you proposing that I do something to
>> lkdtm_rodata.c ? An example would probably help me understand.
>
On 22/02/18 00:24, Kees Cook wrote:
> On Tue, Feb 20, 2018 at 8:40 AM, Igor Stoppa wrote:
[...]
>> sorry for being dense ... are you proposing that I do something to
>> lkdtm_rodata.c ? An example would probably help me understand.
>
> It would likely live in lk
On 21/02/18 23:36, Dave Chinner wrote:
> On Wed, Feb 21, 2018 at 11:56:22AM +0200, Igor Stoppa wrote:
[...]
> It seems lots of people get confused when discussing concepts vs
> implementation... :)
IMHO, if possible, it's better to use unambiguous terms at every point.
__ro_a
On 21/02/18 23:36, Dave Chinner wrote:
> On Wed, Feb 21, 2018 at 11:56:22AM +0200, Igor Stoppa wrote:
[...]
> It seems lots of people get confused when discussing concepts vs
> implementation... :)
IMHO, if possible, it's better to use unambiguous terms at every point.
__ro_a
On 20/02/18 22:54, Matthew Wilcox wrote:
> On Tue, Feb 20, 2018 at 09:53:30PM +0200, Igor Stoppa wrote:
[...]
>> It was found while testing on a configuration with framebuffer.
>
> ... ah. You tried to use vmalloc_to_page() on something which wasn't
> backed by a st
On 20/02/18 22:54, Matthew Wilcox wrote:
> On Tue, Feb 20, 2018 at 09:53:30PM +0200, Igor Stoppa wrote:
[...]
>> It was found while testing on a configuration with framebuffer.
>
> ... ah. You tried to use vmalloc_to_page() on something which wasn't
> backed by a st
On 21/02/18 03:36, Dave Chinner wrote:
> On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote:
>> On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:
>>> FWIW, I'm not wanting to use it to replace static variables. All the
>>> structures are dynamically allocated right now, and
On 21/02/18 03:36, Dave Chinner wrote:
> On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote:
>> On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:
>>> FWIW, I'm not wanting to use it to replace static variables. All the
>>> structures are dynamically allocated right now, and
On 12/02/18 18:24, Igor Stoppa wrote:
>
>
> On 11/02/18 23:16, Matthew Wilcox wrote:
>> On Sun, Feb 11, 2018 at 05:19:17AM +0200, Igor Stoppa wrote:
>>> The struct page has a "mapping" field, which can be re-used, to store a
>>> pointer to the
On 12/02/18 18:24, Igor Stoppa wrote:
>
>
> On 11/02/18 23:16, Matthew Wilcox wrote:
>> On Sun, Feb 11, 2018 at 05:19:17AM +0200, Igor Stoppa wrote:
>>> The struct page has a "mapping" field, which can be re-used, to store a
>>> pointer to the
On 20/02/18 03:21, Dave Chinner wrote:
> On Mon, Feb 12, 2018 at 03:32:36PM -0800, Kees Cook wrote:
>> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
>>> This patch-set introduces the possibility of protecting memory that has
>&g
On 20/02/18 03:21, Dave Chinner wrote:
> On Mon, Feb 12, 2018 at 03:32:36PM -0800, Kees Cook wrote:
>> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote:
>>> This patch-set introduces the possibility of protecting memory that has
>>> been allocated dynamically.
&g
On 13/02/18 20:10, Laura Abbott wrote:
> On 02/13/2018 07:20 AM, Igor Stoppa wrote:
>> Why alterations of page properties are not considered a risk and the physmap
>> is?
>> And how would it be easier (i suppose) to attack the latter?
>
> Alterations are certainly
On 13/02/18 20:10, Laura Abbott wrote:
> On 02/13/2018 07:20 AM, Igor Stoppa wrote:
>> Why alterations of page properties are not considered a risk and the physmap
>> is?
>> And how would it be easier (i suppose) to attack the latter?
>
> Alterations are certainly
On 13/02/18 01:52, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
>> @@ -738,14 +1031,16 @@ EXPORT_SYMBOL(devm_gen_pool_create);
>>
>> #ifdef CONFIG_OF
>> /**
>> - * of_gen_pool_get - find a pool by phandle p
On 13/02/18 01:52, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote:
>> @@ -738,14 +1031,16 @@ EXPORT_SYMBOL(devm_gen_pool_create);
>>
>> #ifdef CONFIG_OF
>> /**
>> - * of_gen_pool_get - find a pool by phandle property
>> + * of_
On 13/02/18 01:50, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
[...]
>> lib/genalloc-selftest.c | 400
>> ++
>
> Nit: make this test_genalloc.c instead.
ok
[...]
&
On 13/02/18 01:50, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote:
[...]
>> lib/genalloc-selftest.c | 400
>> ++
>
> Nit: make this test_genalloc.c instead.
ok
[...]
>> + genalloc_selfte
On 13/02/18 01:43, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 8:53 AM, Igor Stoppa <igor.sto...@huawei.com> wrote:
[...]
>> +obj-$(CONFIG_PROTECTABLE_MEMORY_SELFTEST) += pmalloc-selftest.o
>
> Nit: self-test modules are traditionally named "test_$thing.o"
>
On 13/02/18 01:43, Kees Cook wrote:
> On Mon, Feb 12, 2018 at 8:53 AM, Igor Stoppa wrote:
[...]
>> +obj-$(CONFIG_PROTECTABLE_MEMORY_SELFTEST) += pmalloc-selftest.o
>
> Nit: self-test modules are traditionally named "test_$thing.o"
> (outside of the tools/ direct
401 - 500 of 850 matches
Mail list logo
