Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDLWs8iS_xU0uQHKU1h6HmqP-oqAfK1qAxDpis_JyPSGVGLug@mail.gmail.com>
Date: Tue, 14 Feb 2017 13:34:38 +0530
From: Kaiwan N Billimoria <kaiwan@...wantech.com>
To: Kees Cook <keescook@...omium.org>
Cc: Laura Abbott <labbott@...hat.com>, 
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Merge in PAX_MEMORY_SANITIZE work from grsec
 to linux-next

>> diff --git a/mm/page_poison.c b/mm/page_poison.c
>> index 2e647c6..b45bc0a 100644
>> --- a/mm/page_poison.c
>> +++ b/mm/page_poison.c
>> @@ -49,6 +49,19 @@ struct page_ext_operations page_poisoning_ops = {
>>          .init = init_page_poisoning,
>>  };
>>
>> +#ifdef CONFIG_MEMORY_SANITIZE
>> +static int __init memory_sanitize_init(void)
>> +{
>> +    /* With 'memory sanitize' On, page poisoning Must be turned on */
>> +    if (IS_ENABLED(CONFIG_MEMORY_SANITIZE)) {
>> +        want_page_poisoning = true;
>> +        __page_poisoning_enabled = true;
>> +    }
>> +    return 0;
>> +}
>> +early_initcall(memory_sanitize_init);
>> +#endif
>
> The ifdef and the IS_ENABLED seem redundant to me. I'd drop the ifdef.

An academic question perhaps- am not clear as to why the IS_ENABLED()
is preferable to an #ifdef. I thought eliminating a runtime 'if'
condition (by using an ifdef) is more optimal than the "if
IS_ENABLED(foo)"? Or (probably) does the compiler optimize it out
regardless (assuming that CONFIG_MEMORY_SANITIZE is not selected of
course)?

-Thanks, kaiwan.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.