Re: [PATCH 00/30] kconfig: move compiler capability tests to Kconfig

2018-04-12 Thread Kees Cook
On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada
 wrote:
> [Major Changes in V3]

Awesome work! I don't see this pushed to your git tree? I'd like to
test it, but I'd rather "git fetch" instead of "git am" :)

-Kees

-- 
Kees Cook
Pixel Security


Re: [PATCH 00/30] kconfig: move compiler capability tests to Kconfig

2018-04-12 Thread Kees Cook
On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada
 wrote:
> [Major Changes in V3]

Awesome work! I don't see this pushed to your git tree? I'd like to
test it, but I'd rather "git fetch" instead of "git am" :)

-Kees

-- 
Kees Cook
Pixel Security


Re: [PATCH v2 09/21] kconfig: add 'macro' keyword to support user-defined function

2018-04-12 Thread Masahiro Yamada
2018-04-01 15:05 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
>  wrote:
>> Now, we got a basic ability to test compiler capability in Kconfig.
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null 
>> -o /dev/null) && echo y) || echo n)
>>
>> This works, but it is ugly to repeat this long boilerplate.
>>
>> We want to describe like this:
>>
>> config CC_HAS_STACKPROTECTOR
>> bool
>> default $(cc-option -fstack-protector)
>>
>> It is straight-forward to add a new function, but I do not like to
>> hard-code specialized functions like this.  Hence, here is another
>> feature to add functions from Kconfig files.
>>
>> A user-defined function is defined with a special keyword 'macro'.
>> It can be referenced in the same way as built-in functions.  This
>> feature was also inspired by Makefile where user-defined functions
>> are referenced by $(call func-name, args...), but I omitted the 'call'
>> to makes it shorter.
>>
>> The macro definition can contain $(1), $(2), ... which will be replaced
>> with arguments from the caller.  The macro works just as a textual
>> shorthand, which is also expanded in the lexer phase.
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   config TRUE
>>   bool "true"
>>   default $(success true)
>>
>>   config FALSE
>>   bool "false"
>>   default $(success false)
>>
>> [Result]
>>
>>   $ make -s alldefconfig
>>   $ tail -n 2 .config
>>   CONFIG_TRUE=y
>>   # CONFIG_FALSE is not set
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
>>
>>   config CC_HAS_STACKPROTECTOR
>>   def_bool $(cc-option -fstack-protector)
>>
>> [Result]
>>   $ make -s alldefconfig
>>   $ tail -n 1 .config
>>   CONFIG_CC_HAS_STACKPROTECTOR=y
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>> Changes in v2:
>>   - Use 'macro' directly instead of inside the string type symbol.
>>
>>  scripts/kconfig/function.c  | 59 
>> +++--
>>  scripts/kconfig/lkc_proto.h |  1 +
>>  scripts/kconfig/zconf.l | 31 
>>  3 files changed, 89 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> index 913685f..389bb44 100644
>> --- a/scripts/kconfig/function.c
>> +++ b/scripts/kconfig/function.c
>> @@ -15,6 +15,7 @@ static LIST_HEAD(function_list);
>>  struct function {
>> char *name;
>> char *(*func)(struct function *f, int argc, char *argv[]);
>> +   char *macro;
>> struct list_head node;
>>  };
>>
>> @@ -31,7 +32,8 @@ static struct function *func_lookup(const char *name)
>>  }
>>
>>  static void func_add(const char *name,
>> -char *(*func)(struct function *f, int argc, char 
>> *argv[]))
>> +char *(*func)(struct function *f, int argc, char 
>> *argv[]),
>> +const char *macro)
>>  {
>> struct function *f;
>>
>> @@ -44,6 +46,7 @@ static void func_add(const char *name,
>> f = xmalloc(sizeof(*f));
>> f->name = xstrdup(name);
>> f->func = func;
>> +   f->macro = macro ? xstrdup(macro) : NULL;
>>
>> list_add_tail(>node, _list);
>>  }
>> @@ -51,6 +54,7 @@ static void func_add(const char *name,
>>  static void func_del(struct function *f)
>>  {
>> list_del(>node);
>> +   free(f->macro);
>> free(f->name);
>> free(f);
>>  }
>> @@ -108,6 +112,57 @@ char *func_eval_n(const char *func, size_t n)
>> return res;
>>  }
>>
>> +/* run user-defined function */
>> +static char *do_macro(struct function *f, int argc, char *argv[])
>> +{
>> +   char *new;
>> +   char *src, *p, *res;
>> +   size_t newlen;
>> +   int n;
>> +
>> +   new = xmalloc(1);
>> +   *new = 0;
>
> new = '\0' would be consistent with the rest of the code.
>
>> +
>> +   /*
>> +* This is a format string. $(1), $(2), ... must be replaced with
>> +* function arguments.
>> +*/
>> +   src = f->macro;
>> +   p = src;
>> +
>> +   while ((p = strstr(p, "$("))) {
>> +   if (isdigit(p[2]) && p[3] == ')') {
>> +   n = p[2] - '0';
>> +   if (n < argc) {
>> +   newlen = strlen(new) + (p - src) +
>> +   strlen(argv[n]) + 1;
>> +   new = xrealloc(new, newlen);
>> +   strncat(new, src, p - src);
>> +   strcat(new, argv[n]);
>> +   src = p + 4;
>> + 

Re: [PATCH v2 09/21] kconfig: add 'macro' keyword to support user-defined function

2018-04-12 Thread Masahiro Yamada
2018-04-01 15:05 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
>  wrote:
>> Now, we got a basic ability to test compiler capability in Kconfig.
>>
>> config CC_HAS_STACKPROTECTOR
>> def_bool $(shell (($CC -Werror -fstack-protector -c -x c /dev/null 
>> -o /dev/null) && echo y) || echo n)
>>
>> This works, but it is ugly to repeat this long boilerplate.
>>
>> We want to describe like this:
>>
>> config CC_HAS_STACKPROTECTOR
>> bool
>> default $(cc-option -fstack-protector)
>>
>> It is straight-forward to add a new function, but I do not like to
>> hard-code specialized functions like this.  Hence, here is another
>> feature to add functions from Kconfig files.
>>
>> A user-defined function is defined with a special keyword 'macro'.
>> It can be referenced in the same way as built-in functions.  This
>> feature was also inspired by Makefile where user-defined functions
>> are referenced by $(call func-name, args...), but I omitted the 'call'
>> to makes it shorter.
>>
>> The macro definition can contain $(1), $(2), ... which will be replaced
>> with arguments from the caller.  The macro works just as a textual
>> shorthand, which is also expanded in the lexer phase.
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   config TRUE
>>   bool "true"
>>   default $(success true)
>>
>>   config FALSE
>>   bool "false"
>>   default $(success false)
>>
>> [Result]
>>
>>   $ make -s alldefconfig
>>   $ tail -n 2 .config
>>   CONFIG_TRUE=y
>>   # CONFIG_FALSE is not set
>>
>> [Example Code]
>>
>>   macro success $(shell ($(1) && echo y) || echo n)
>>
>>   macro cc-option $(success $CC -Werror $(1) -c -x c /dev/null -o /dev/null)
>>
>>   config CC_HAS_STACKPROTECTOR
>>   def_bool $(cc-option -fstack-protector)
>>
>> [Result]
>>   $ make -s alldefconfig
>>   $ tail -n 1 .config
>>   CONFIG_CC_HAS_STACKPROTECTOR=y
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>> Changes in v2:
>>   - Use 'macro' directly instead of inside the string type symbol.
>>
>>  scripts/kconfig/function.c  | 59 
>> +++--
>>  scripts/kconfig/lkc_proto.h |  1 +
>>  scripts/kconfig/zconf.l | 31 
>>  3 files changed, 89 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> index 913685f..389bb44 100644
>> --- a/scripts/kconfig/function.c
>> +++ b/scripts/kconfig/function.c
>> @@ -15,6 +15,7 @@ static LIST_HEAD(function_list);
>>  struct function {
>> char *name;
>> char *(*func)(struct function *f, int argc, char *argv[]);
>> +   char *macro;
>> struct list_head node;
>>  };
>>
>> @@ -31,7 +32,8 @@ static struct function *func_lookup(const char *name)
>>  }
>>
>>  static void func_add(const char *name,
>> -char *(*func)(struct function *f, int argc, char 
>> *argv[]))
>> +char *(*func)(struct function *f, int argc, char 
>> *argv[]),
>> +const char *macro)
>>  {
>> struct function *f;
>>
>> @@ -44,6 +46,7 @@ static void func_add(const char *name,
>> f = xmalloc(sizeof(*f));
>> f->name = xstrdup(name);
>> f->func = func;
>> +   f->macro = macro ? xstrdup(macro) : NULL;
>>
>> list_add_tail(>node, _list);
>>  }
>> @@ -51,6 +54,7 @@ static void func_add(const char *name,
>>  static void func_del(struct function *f)
>>  {
>> list_del(>node);
>> +   free(f->macro);
>> free(f->name);
>> free(f);
>>  }
>> @@ -108,6 +112,57 @@ char *func_eval_n(const char *func, size_t n)
>> return res;
>>  }
>>
>> +/* run user-defined function */
>> +static char *do_macro(struct function *f, int argc, char *argv[])
>> +{
>> +   char *new;
>> +   char *src, *p, *res;
>> +   size_t newlen;
>> +   int n;
>> +
>> +   new = xmalloc(1);
>> +   *new = 0;
>
> new = '\0' would be consistent with the rest of the code.
>
>> +
>> +   /*
>> +* This is a format string. $(1), $(2), ... must be replaced with
>> +* function arguments.
>> +*/
>> +   src = f->macro;
>> +   p = src;
>> +
>> +   while ((p = strstr(p, "$("))) {
>> +   if (isdigit(p[2]) && p[3] == ')') {
>> +   n = p[2] - '0';
>> +   if (n < argc) {
>> +   newlen = strlen(new) + (p - src) +
>> +   strlen(argv[n]) + 1;
>> +   new = xrealloc(new, newlen);
>> +   strncat(new, src, p - src);
>> +   strcat(new, argv[n]);
>> +   src = p + 4;
>> +   }
>
> Might be nice to warn when a macro call has missing arguments.


I 

Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration

2018-04-12 Thread Baolin Wang
On 13 April 2018 at 11:39, Vinod Koul  wrote:
> On Thu, Apr 12, 2018 at 07:30:01PM +0800, Baolin Wang wrote:
>
>> >> > what does block and transaction len refer to here
>> >>
>> >>  Our DMA has 3 transfer mode: transaction transfer, block transfer and
>> >> fragment transfer. One transaction transfer can contain several blocks
>> >> transfer, and each block can be set proper block step. One block can
>> >> contain several fragments transfer with proper fragment step. It can
>> >> generate interrupts when one transaction transfer or block transfer or
>> >> fragment transfer is completed if user set the interrupt type. So here
>> >> we should set the length for transaction transfer, block transfer and
>> >> fragment transfer.
>> >
>> > what are the max size these types support?
>>
>> These types max size definition:
>>
>> #define SPRD_DMA_FRG_LEN_MASK GENMASK(16, 0)
>>
>> #define SPRD_DMA_BLK_LEN_MASK GENMASK(16, 0)
>>
>> #define SPRD_DMA_TRSC_LEN_MASK GENMASK(27, 0)
>
> They are register defines. How many items or bytes do each type of txn
> support?

These macros are the max size definitions, for example one fragment
length can support to 0x1 bytes, one transaction transfer can
support to 0xfff.

-- 
Baolin.wang
Best Regards


Re: [PATCH 4/5] dmaengine: sprd: Add Spreadtrum DMA configuration

2018-04-12 Thread Baolin Wang
On 13 April 2018 at 11:39, Vinod Koul  wrote:
> On Thu, Apr 12, 2018 at 07:30:01PM +0800, Baolin Wang wrote:
>
>> >> > what does block and transaction len refer to here
>> >>
>> >>  Our DMA has 3 transfer mode: transaction transfer, block transfer and
>> >> fragment transfer. One transaction transfer can contain several blocks
>> >> transfer, and each block can be set proper block step. One block can
>> >> contain several fragments transfer with proper fragment step. It can
>> >> generate interrupts when one transaction transfer or block transfer or
>> >> fragment transfer is completed if user set the interrupt type. So here
>> >> we should set the length for transaction transfer, block transfer and
>> >> fragment transfer.
>> >
>> > what are the max size these types support?
>>
>> These types max size definition:
>>
>> #define SPRD_DMA_FRG_LEN_MASK GENMASK(16, 0)
>>
>> #define SPRD_DMA_BLK_LEN_MASK GENMASK(16, 0)
>>
>> #define SPRD_DMA_TRSC_LEN_MASK GENMASK(27, 0)
>
> They are register defines. How many items or bytes do each type of txn
> support?

These macros are the max size definitions, for example one fragment
length can support to 0x1 bytes, one transaction transfer can
support to 0xfff.

-- 
Baolin.wang
Best Regards


Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Zhang Rui
Hi, Eduardo,

On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > 
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > wrote:
> > > 
> > > 
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make allmodconfig" and the warning is about a uninitialized
> > variable.
> > 
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > history
> > is to be believed.
> > 
> > Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
> 
> Anyways, given that the conversion functions are written to cover
> for unexpected cal_type, the right way of fixing this is to rewrite
> the conversion functions to allow for returning error codes and
> adjusting the callers as expected.
> 
> Rui, bzolnier, please consider the following fix:
> 
as it is late in this merge window, I'd prefer to
1. drop all the thermal-soc material in the first pull request which I
will send out soon.
2. you can prepare another pull request containing the thermal-soc
materials except the exynos fixes
3. exynos fixes with the problem solved can be queued for -rc2 or
later.

thanks,
rui

> From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00
> 2001
> From: Eduardo Valentin 
> Date: Thu, 12 Apr 2018 21:00:48 -0700
> Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
>  conversion functions
> 
> In order to fix the warns:
> drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may
> be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> the conversion functions should allow return error codes
> and the not mix the converted value with error code.
> 
> This patch change the conversion functions to return
> error code or success and adjusts the callers accordingly.
> 
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 120 -
> --
>  1 file changed, 84 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 2ec8548..b3f0704 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -282,52 +282,54 @@ static void exynos_report_trigger(struct
> exynos_tmu_data *p)
>   * TMU treats temperature as a mapped temperature code.
>   * The temperature is converted differently depending on the
> calibration type.
>   */
> -static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
> +static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int
> *temp_code)
>  {
> - int temp_code;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
> + *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
>   (data->temp_error2 - data->temp_error1) /
>   (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) +
>   data->temp_error1;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
> + *temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
>   break;
>   default:
>   WARN_ON(1);
> + ret = -EINVAL;
>   break;
>   }
>  
> - return temp_code;
> + return ret;
>  }
>  
>  /*
>   * Calculate a temperature value from a temperature code.
>   * The unit of the temperature is degree Celsius.
>   */
> -static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
> +static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code,
> int *temp)
>  {
> - int temp;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp = (temp_code - data->temp_error1) *
> + *temp = (temp_code - data->temp_error1) *
>   (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) /
>   (data->temp_error2 - data->temp_error1) +
>   EXYNOS_FIRST_POINT_TRIM;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp = temp_code - data->temp_error1 +
> EXYNOS_FIRST_POINT_TRIM;
> + *temp = temp_code - data->temp_error1 +
> EXYNOS_FIRST_POINT_TRIM;
>   break;
>   default:
>   WARN_ON(1);
> + ret = -EINVAL;
>   break;
>   }
>  
> - return temp;
> + return ret;
>  }
>  
>  static void sanitize_temp_error(struct exynos_tmu_data *data, u32
> trim_info)
> @@ -352,7 +354,7 

Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Zhang Rui
Hi, Eduardo,

On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > 
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > wrote:
> > > 
> > > 
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make allmodconfig" and the warning is about a uninitialized
> > variable.
> > 
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > history
> > is to be believed.
> > 
> > Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
> 
> Anyways, given that the conversion functions are written to cover
> for unexpected cal_type, the right way of fixing this is to rewrite
> the conversion functions to allow for returning error codes and
> adjusting the callers as expected.
> 
> Rui, bzolnier, please consider the following fix:
> 
as it is late in this merge window, I'd prefer to
1. drop all the thermal-soc material in the first pull request which I
will send out soon.
2. you can prepare another pull request containing the thermal-soc
materials except the exynos fixes
3. exynos fixes with the problem solved can be queued for -rc2 or
later.

thanks,
rui

> From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00
> 2001
> From: Eduardo Valentin 
> Date: Thu, 12 Apr 2018 21:00:48 -0700
> Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
>  conversion functions
> 
> In order to fix the warns:
> drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may
> be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> the conversion functions should allow return error codes
> and the not mix the converted value with error code.
> 
> This patch change the conversion functions to return
> error code or success and adjusts the callers accordingly.
> 
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 120 -
> --
>  1 file changed, 84 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 2ec8548..b3f0704 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -282,52 +282,54 @@ static void exynos_report_trigger(struct
> exynos_tmu_data *p)
>   * TMU treats temperature as a mapped temperature code.
>   * The temperature is converted differently depending on the
> calibration type.
>   */
> -static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
> +static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int
> *temp_code)
>  {
> - int temp_code;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
> + *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
>   (data->temp_error2 - data->temp_error1) /
>   (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) +
>   data->temp_error1;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
> + *temp_code = temp + data->temp_error1 -
> EXYNOS_FIRST_POINT_TRIM;
>   break;
>   default:
>   WARN_ON(1);
> + ret = -EINVAL;
>   break;
>   }
>  
> - return temp_code;
> + return ret;
>  }
>  
>  /*
>   * Calculate a temperature value from a temperature code.
>   * The unit of the temperature is degree Celsius.
>   */
> -static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
> +static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code,
> int *temp)
>  {
> - int temp;
> + int ret = 0;
>  
>   switch (data->cal_type) {
>   case TYPE_TWO_POINT_TRIMMING:
> - temp = (temp_code - data->temp_error1) *
> + *temp = (temp_code - data->temp_error1) *
>   (EXYNOS_SECOND_POINT_TRIM -
> EXYNOS_FIRST_POINT_TRIM) /
>   (data->temp_error2 - data->temp_error1) +
>   EXYNOS_FIRST_POINT_TRIM;
>   break;
>   case TYPE_ONE_POINT_TRIMMING:
> - temp = temp_code - data->temp_error1 +
> EXYNOS_FIRST_POINT_TRIM;
> + *temp = temp_code - data->temp_error1 +
> EXYNOS_FIRST_POINT_TRIM;
>   break;
>   default:
>   WARN_ON(1);
> + ret = -EINVAL;
>   break;
>   }
>  
> - return temp;
> + return ret;
>  }
>  
>  static void sanitize_temp_error(struct exynos_tmu_data *data, u32
> trim_info)
> @@ -352,7 +354,7 @@ static u32 get_th_reg(struct exynos_tmu_data
> *data, u32 

Re: [PATCH 1/5] random: fix crng_ready() test

2018-04-12 Thread Stephan Mueller
Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o:

Hi Theodore,

> The crng_init variable has three states:
> 
> 0: The CRNG is not initialized at all
> 1: The CRNG has a small amount of entropy, hopefully good enough for
>early-boot, non-cryptographical use cases
> 2: The CRNG is fully initialized and we are sure it is safe for
>cryptographic use cases.
> 
> The crng_ready() function should only return true once we are in the
> last state.
> 
Do I see that correctly that getrandom(2) will now unblock after the 
input_pool has obtained 128 bits of entropy? Similarly for 
get_random_bytes_wait.

As this seems to be the only real use case for crng_ready (apart from 
logging), what is the purpose of crng_init == 1?

Ciao
Stephan




Re: [PATCH 1/5] random: fix crng_ready() test

2018-04-12 Thread Stephan Mueller
Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o:

Hi Theodore,

> The crng_init variable has three states:
> 
> 0: The CRNG is not initialized at all
> 1: The CRNG has a small amount of entropy, hopefully good enough for
>early-boot, non-cryptographical use cases
> 2: The CRNG is fully initialized and we are sure it is safe for
>cryptographic use cases.
> 
> The crng_ready() function should only return true once we are in the
> last state.
> 
Do I see that correctly that getrandom(2) will now unblock after the 
input_pool has obtained 128 bits of entropy? Similarly for 
get_random_bytes_wait.

As this seems to be the only real use case for crng_ready (apart from 
logging), what is the purpose of crng_init == 1?

Ciao
Stephan




Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

2018-04-12 Thread Masahiro Yamada
2018-04-01 13:19 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
>  wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>>   $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this syntax was inspired by make.)
>>
>> Real examples will look like this:
>>
>>   $(shell echo hello world)
>>   $(cc-option -fstackprotector)
>>
>> This commit adds the basic infrastructure to add, delete, evaluate
>> functions, and also the first built-in function $(shell ...).  This
>> accepts a single command to execute.  It returns the standard output
>> from it.
>>
>> [Example code]
>>
>>   config HELLO
>>   string
>>   default "$(shell echo hello world)"
>>
>>   config Y
>>   def_bool $(shell echo y)
>>
>> [Result]
>>
>>   $ make -s alldefconfig && tail -n 2 .config
>>   CONFIG_HELLO="hello world"
>>   CONFIG_Y=y
>>
>> Caveat:
>> Like environments, functions are expanded in the lexer.  You cannot
>> pass symbols to function arguments.  This is a limitation to simplify
>> the implementation.  I want to avoid the dynamic function evaluation,
>> which would introduce much more complexity.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>>
>> Changes in v2:
>>   - Use 'shell' for getting stdout from the comment.
>> It was 'shell-stdout' in the previous version.
>>   - Symplify the implementation since the expansion has been moved to
>> lexer.
>>
>>  scripts/kconfig/function.c  | 170 
>> 
>>  scripts/kconfig/lkc_proto.h |   5 ++
>>  scripts/kconfig/util.c  |  46 +---
>>  scripts/kconfig/zconf.y |   9 +++
>>  4 files changed, 222 insertions(+), 8 deletions(-)
>>  create mode 100644 scripts/kconfig/function.c
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> new file mode 100644
>> index 000..913685f
>> --- /dev/null
>> +++ b/scripts/kconfig/function.c
>> @@ -0,0 +1,170 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +//
>> +// Copyright (C) 2018 Masahiro Yamada 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "list.h"
>> +
>> +#define FUNCTION_MAX_ARGS  10
>> +
>> +static LIST_HEAD(function_list);
>> +
>> +struct function {
>> +   char *name;
>> +   char *(*func)(struct function *f, int argc, char *argv[]);
>> +   struct list_head node;
>> +};
>> +
>> +static struct function *func_lookup(const char *name)
>> +{
>> +   struct function *f;
>> +
>> +   list_for_each_entry(f, _list, node) {
>> +   if (!strcmp(name, f->name))
>> +   return f;
>> +   }
>> +
>> +   return NULL;
>> +}
>> +
>> +static void func_add(const char *name,
>> +char *(*func)(struct function *f, int argc, char 
>> *argv[]))
>> +{
>> +   struct function *f;
>> +
>> +   f = func_lookup(name);
>> +   if (f) {
>> +   fprintf(stderr, "%s: function already exists. ignored.\n", 
>> name);
>> +   return;
>> +   }
>> +
>> +   f = xmalloc(sizeof(*f));
>> +   f->name = xstrdup(name);
>> +   f->func = func;
>> +
>> +   list_add_tail(>node, _list);
>> +}
>> +
>> +static void func_del(struct function *f)
>> +{
>> +   list_del(>node);
>> +   free(f->name);
>> +   free(f);
>> +}
>> +
>> +static char *func_call(int argc, char *argv[])
>> +{
>> +   struct function *f;
>> +
>> +   f = func_lookup(argv[0]);
>> +   if (!f) {
>> +   fprintf(stderr, "%s: function not found\n", argv[0]);
>> +   return NULL;
>> +   }
>> +
>> +   return f->func(f, argc, argv);
>> +}
>> +
>> +static char *func_eval(const char *func)
>> +{
>> +   char *expanded, *saveptr, *str, *token, *res;
>> +   const char *delim;
>> +   int argc = 0;
>> +   char *argv[FUNCTION_MAX_ARGS];
>> +
>> +   expanded = expand_string_value(func);
>> +
>> +   str = expanded;
>> +   delim = " ";
>> +
>> +   while ((token = strtok_r(str, delim, ))) {
>> +   argv[argc++] = token;
>
> Would be nice to error out if the array is overstepped.

In V3, I made this a feature.


>> +   str = NULL;
>> +   delim = ",";
>> +   }
>> +
>> +   res = func_call(argc, argv);
>> +
>> +   free(expanded);
>> +
>> +   return res ?: xstrdup("");
>> +}
>
> Since only 'macro' will take multiple parameters, I wonder if it might
> be better to implement the argument parsing there, and simply pass the
> string (minus the function name) as-is to functions.

I may add more built-in functions in the future.
For example, I want to add 'if' function, which takes two or three arguments.


> You would then be able to have ',' in shell commands, 

Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

2018-04-12 Thread Masahiro Yamada
2018-04-01 13:19 GMT+09:00 Ulf Magnusson :
> On Tue, Mar 27, 2018 at 7:29 AM, Masahiro Yamada
>  wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>>   $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this syntax was inspired by make.)
>>
>> Real examples will look like this:
>>
>>   $(shell echo hello world)
>>   $(cc-option -fstackprotector)
>>
>> This commit adds the basic infrastructure to add, delete, evaluate
>> functions, and also the first built-in function $(shell ...).  This
>> accepts a single command to execute.  It returns the standard output
>> from it.
>>
>> [Example code]
>>
>>   config HELLO
>>   string
>>   default "$(shell echo hello world)"
>>
>>   config Y
>>   def_bool $(shell echo y)
>>
>> [Result]
>>
>>   $ make -s alldefconfig && tail -n 2 .config
>>   CONFIG_HELLO="hello world"
>>   CONFIG_Y=y
>>
>> Caveat:
>> Like environments, functions are expanded in the lexer.  You cannot
>> pass symbols to function arguments.  This is a limitation to simplify
>> the implementation.  I want to avoid the dynamic function evaluation,
>> which would introduce much more complexity.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>>
>>
>> Changes in v2:
>>   - Use 'shell' for getting stdout from the comment.
>> It was 'shell-stdout' in the previous version.
>>   - Symplify the implementation since the expansion has been moved to
>> lexer.
>>
>>  scripts/kconfig/function.c  | 170 
>> 
>>  scripts/kconfig/lkc_proto.h |   5 ++
>>  scripts/kconfig/util.c  |  46 +---
>>  scripts/kconfig/zconf.y |   9 +++
>>  4 files changed, 222 insertions(+), 8 deletions(-)
>>  create mode 100644 scripts/kconfig/function.c
>>
>> diff --git a/scripts/kconfig/function.c b/scripts/kconfig/function.c
>> new file mode 100644
>> index 000..913685f
>> --- /dev/null
>> +++ b/scripts/kconfig/function.c
>> @@ -0,0 +1,170 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +//
>> +// Copyright (C) 2018 Masahiro Yamada 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "list.h"
>> +
>> +#define FUNCTION_MAX_ARGS  10
>> +
>> +static LIST_HEAD(function_list);
>> +
>> +struct function {
>> +   char *name;
>> +   char *(*func)(struct function *f, int argc, char *argv[]);
>> +   struct list_head node;
>> +};
>> +
>> +static struct function *func_lookup(const char *name)
>> +{
>> +   struct function *f;
>> +
>> +   list_for_each_entry(f, _list, node) {
>> +   if (!strcmp(name, f->name))
>> +   return f;
>> +   }
>> +
>> +   return NULL;
>> +}
>> +
>> +static void func_add(const char *name,
>> +char *(*func)(struct function *f, int argc, char 
>> *argv[]))
>> +{
>> +   struct function *f;
>> +
>> +   f = func_lookup(name);
>> +   if (f) {
>> +   fprintf(stderr, "%s: function already exists. ignored.\n", 
>> name);
>> +   return;
>> +   }
>> +
>> +   f = xmalloc(sizeof(*f));
>> +   f->name = xstrdup(name);
>> +   f->func = func;
>> +
>> +   list_add_tail(>node, _list);
>> +}
>> +
>> +static void func_del(struct function *f)
>> +{
>> +   list_del(>node);
>> +   free(f->name);
>> +   free(f);
>> +}
>> +
>> +static char *func_call(int argc, char *argv[])
>> +{
>> +   struct function *f;
>> +
>> +   f = func_lookup(argv[0]);
>> +   if (!f) {
>> +   fprintf(stderr, "%s: function not found\n", argv[0]);
>> +   return NULL;
>> +   }
>> +
>> +   return f->func(f, argc, argv);
>> +}
>> +
>> +static char *func_eval(const char *func)
>> +{
>> +   char *expanded, *saveptr, *str, *token, *res;
>> +   const char *delim;
>> +   int argc = 0;
>> +   char *argv[FUNCTION_MAX_ARGS];
>> +
>> +   expanded = expand_string_value(func);
>> +
>> +   str = expanded;
>> +   delim = " ";
>> +
>> +   while ((token = strtok_r(str, delim, ))) {
>> +   argv[argc++] = token;
>
> Would be nice to error out if the array is overstepped.

In V3, I made this a feature.


>> +   str = NULL;
>> +   delim = ",";
>> +   }
>> +
>> +   res = func_call(argc, argv);
>> +
>> +   free(expanded);
>> +
>> +   return res ?: xstrdup("");
>> +}
>
> Since only 'macro' will take multiple parameters, I wonder if it might
> be better to implement the argument parsing there, and simply pass the
> string (minus the function name) as-is to functions.

I may add more built-in functions in the future.
For example, I want to add 'if' function, which takes two or three arguments.


> You would then be able to have ',' in shell commands, which might be
> required -- think gcc -Wl,option and the like.

I fixed 'shell' function in v3.


>> +
>> +char 

Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

2018-04-12 Thread Masahiro Yamada
2018-03-28 12:41 GMT+09:00 Kees Cook :
> On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
>  wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>>   $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this syntax was inspired by make.)
>>
>> Real examples will look like this:
>>
>>   $(shell echo hello world)
>>   $(cc-option -fstackprotector)
>>
>> This commit adds the basic infrastructure to add, delete, evaluate
>> functions, and also the first built-in function $(shell ...).  This
>> accepts a single command to execute.  It returns the standard output
>> from it.
>>
>> [Example code]
>>
>>   config HELLO
>>   string
>>   default "$(shell echo hello world)"
>>
>>   config Y
>>   def_bool $(shell echo y)
>>
>> [Result]
>>
>>   $ make -s alldefconfig && tail -n 2 .config
>>   CONFIG_HELLO="hello world"
>>   CONFIG_Y=y
>>
>> Caveat:
>> Like environments, functions are expanded in the lexer.  You cannot
>> pass symbols to function arguments.  This is a limitation to simplify
>> the implementation.  I want to avoid the dynamic function evaluation,
>> which would introduce much more complexity.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>
> Yeah, this needs to be included here, especially given the "cannot
> pass symbols" aspect which might surprise people.
>
>> [...]
>> +/* built-in functions */
>> +static char *do_shell(struct function *f, int argc, char *argv[])
>> +{
>> +   static const char *pre = "(";
>> +   static const char *post = ") 2>/dev/null";
>
> Right now the search and help screens in menuconfig just show the line
> a config is defined and nothing more. I think it would be extremely
> handy to include shell output here in some way.


The current implementation cannot do this.

The $(shell ...) has already expanded
before the parser receives tokens.

There is no way to know whether a token came from a source file as-is,
or it was derived from textual substitution.




> Especially when trying
> to answer questions like "why aren't GCC plugins available?" it's got
> quite a bit harder to debug.
> Could we capture the output (especially stderr) for these kinds of hints?


For example, it would be possible to dump the result of $(shell ...)
evaluation into the console in debug mode.



> Beyond that, looks good!
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada


Re: [PATCH v2 07/21] kconfig: add function support and implement 'shell' function

2018-04-12 Thread Masahiro Yamada
2018-03-28 12:41 GMT+09:00 Kees Cook :
> On Mon, Mar 26, 2018 at 10:29 PM, Masahiro Yamada
>  wrote:
>> This commit adds a new concept 'function' to do more text processing
>> in Kconfig.
>>
>> A function call looks like this:
>>
>>   $(function arg1, arg2, arg3, ...)
>>
>> (Actually, this syntax was inspired by make.)
>>
>> Real examples will look like this:
>>
>>   $(shell echo hello world)
>>   $(cc-option -fstackprotector)
>>
>> This commit adds the basic infrastructure to add, delete, evaluate
>> functions, and also the first built-in function $(shell ...).  This
>> accepts a single command to execute.  It returns the standard output
>> from it.
>>
>> [Example code]
>>
>>   config HELLO
>>   string
>>   default "$(shell echo hello world)"
>>
>>   config Y
>>   def_bool $(shell echo y)
>>
>> [Result]
>>
>>   $ make -s alldefconfig && tail -n 2 .config
>>   CONFIG_HELLO="hello world"
>>   CONFIG_Y=y
>>
>> Caveat:
>> Like environments, functions are expanded in the lexer.  You cannot
>> pass symbols to function arguments.  This is a limitation to simplify
>> the implementation.  I want to avoid the dynamic function evaluation,
>> which would introduce much more complexity.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Reminder for myself:
>> Update Documentation/kbuild/kconfig-language.txt
>
> Yeah, this needs to be included here, especially given the "cannot
> pass symbols" aspect which might surprise people.
>
>> [...]
>> +/* built-in functions */
>> +static char *do_shell(struct function *f, int argc, char *argv[])
>> +{
>> +   static const char *pre = "(";
>> +   static const char *post = ") 2>/dev/null";
>
> Right now the search and help screens in menuconfig just show the line
> a config is defined and nothing more. I think it would be extremely
> handy to include shell output here in some way.


The current implementation cannot do this.

The $(shell ...) has already expanded
before the parser receives tokens.

There is no way to know whether a token came from a source file as-is,
or it was derived from textual substitution.




> Especially when trying
> to answer questions like "why aren't GCC plugins available?" it's got
> quite a bit harder to debug.
> Could we capture the output (especially stderr) for these kinds of hints?


For example, it would be possible to dump the result of $(shell ...)
evaluation into the console in debug mode.



> Beyond that, looks good!
>
> -Kees
>
> --
> Kees Cook
> Pixel Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada


Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Zhang Rui
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > 
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > wrote:
> > > 
> > > 
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make allmodconfig" and the warning is about a uninitialized
> > variable.
> > 
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > history
> > is to be believed.
> > 
> > Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
> 

I think there are two problems here

1. Actually, this error has been raised by 0-day earlier.
https://marc.info/?l=linux-pm=152107340117077=2
Don't know why it still goes into thermal-soc tree.

2. After pulled the thermal-soc changes, I also asked 0-day to run
build test, but I didn't get any warning report (email attached), CC
Philip and Shun to look at this issue.

thanks,
rui

bin_6r1piPKmQ.bin
Description: application/mbox


Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Zhang Rui
On 四, 2018-04-12 at 21:08 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> > 
> > On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui 
> > wrote:
> > > 
> > > 
> > > could you please illustrate me what the kconfig & warning is?
> > Just "make allmodconfig" and the warning is about a uninitialized
> > variable.
> > 
> > Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell
> > history
> > is to be believed.
> > 
> > Linus
> Yeah, this has also passed my local compilation error. Somehow my
> gcc4.9
> is not catching it. Using an older gcc (gcc4.6) does catch it.
> 

I think there are two problems here

1. Actually, this error has been raised by 0-day earlier.
https://marc.info/?l=linux-pm=152107340117077=2
Don't know why it still goes into thermal-soc tree.

2. After pulled the thermal-soc changes, I also asked 0-day to run
build test, but I didn't get any warning report (email attached), CC
Philip and Shun to look at this issue.

thanks,
rui

bin_6r1piPKmQ.bin
Description: application/mbox


[PATCH] timekeeping: Remove __current_kernel_time()

2018-04-12 Thread Baolin Wang
The __current_kernel_time() function based on 'struct timespec' is no
longer recommended for new code, and the only user of this function
has been replaced by commit 6909e29fdefb ("kdb: use
__ktime_get_real_seconds instead of __current_kernel_time"). So now we
can remove this obsolete interface.

Signed-off-by: Baolin Wang 
---
 include/linux/timekeeping32.h |3 ---
 kernel/time/timekeeping.c |7 ---
 2 files changed, 10 deletions(-)

diff --git a/include/linux/timekeeping32.h b/include/linux/timekeeping32.h
index af4114d..3616b4b 100644
--- a/include/linux/timekeeping32.h
+++ b/include/linux/timekeeping32.h
@@ -9,9 +9,6 @@
 extern void do_gettimeofday(struct timeval *tv);
 unsigned long get_seconds(void);
 
-/* does not take xtime_lock */
-struct timespec __current_kernel_time(void);
-
 static inline struct timespec current_kernel_time(void)
 {
struct timespec64 now = current_kernel_time64();
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index ca90219..dcf7f20 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2139,13 +2139,6 @@ unsigned long get_seconds(void)
 }
 EXPORT_SYMBOL(get_seconds);
 
-struct timespec __current_kernel_time(void)
-{
-   struct timekeeper *tk = _core.timekeeper;
-
-   return timespec64_to_timespec(tk_xtime(tk));
-}
-
 struct timespec64 current_kernel_time64(void)
 {
struct timekeeper *tk = _core.timekeeper;
-- 
1.7.9.5



[PATCH] timekeeping: Remove __current_kernel_time()

2018-04-12 Thread Baolin Wang
The __current_kernel_time() function based on 'struct timespec' is no
longer recommended for new code, and the only user of this function
has been replaced by commit 6909e29fdefb ("kdb: use
__ktime_get_real_seconds instead of __current_kernel_time"). So now we
can remove this obsolete interface.

Signed-off-by: Baolin Wang 
---
 include/linux/timekeeping32.h |3 ---
 kernel/time/timekeeping.c |7 ---
 2 files changed, 10 deletions(-)

diff --git a/include/linux/timekeeping32.h b/include/linux/timekeeping32.h
index af4114d..3616b4b 100644
--- a/include/linux/timekeeping32.h
+++ b/include/linux/timekeeping32.h
@@ -9,9 +9,6 @@
 extern void do_gettimeofday(struct timeval *tv);
 unsigned long get_seconds(void);
 
-/* does not take xtime_lock */
-struct timespec __current_kernel_time(void);
-
 static inline struct timespec current_kernel_time(void)
 {
struct timespec64 now = current_kernel_time64();
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index ca90219..dcf7f20 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2139,13 +2139,6 @@ unsigned long get_seconds(void)
 }
 EXPORT_SYMBOL(get_seconds);
 
-struct timespec __current_kernel_time(void)
-{
-   struct timekeeper *tk = _core.timekeeper;
-
-   return timespec64_to_timespec(tk_xtime(tk));
-}
-
 struct timespec64 current_kernel_time64(void)
 {
struct timekeeper *tk = _core.timekeeper;
-- 
1.7.9.5



Re: Crashes/hung tasks with z3pool under memory pressure

2018-04-12 Thread Vitaly Wool
Hi Guenter,


Den fre 13 apr. 2018 kl 00:01 skrev Guenter Roeck :

> Hi all,

> we are observing crashes with z3pool under memory pressure. The kernel
version
> used to reproduce the problem is v4.16-11827-g5d1365940a68, but the
problem was
> also seen with v4.14 based kernels.


just before I dig into this, could you please try reproducing the errors
you see with https://patchwork.kernel.org/patch/10210459/ applied?

Thanks,
Vitaly

> For simplicity, here is a set of shortened logs. A more complete log is
> available at [1].

> [ cut here ]
> DEBUG_LOCKS_WARN_ON((preempt_count() & PREEMPT_MASK) >= PREEMPT_MASK - 10)
> WARNING: CPU: 2 PID: 594 at kernel/sched/core.c:3212
preempt_count_add+0x90/0xa0
> Modules linked in:
> CPU: 2 PID: 594 Comm: memory-eater Not tainted 4.16.0-yocto-standard+ #8
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1
04/01/2014
> RIP: 0010:preempt_count_add+0x90/0xa0
> RSP: :b12740db7750 EFLAGS: 00010286
> RAX:  RBX: 0001 RCX: 00f6
> RDX: 00f6 RSI: 0082 RDI: 
> RBP: f00480f357a0 R08: 004a R09: 01ad
> R10: b12740db77e0 R11:  R12: 9cbc7e265d10
> R13: 9cbc7cd5e000 R14: 9cbc7a7000d8 R15: f00480f35780
> FS:  7f5140791700() GS:9cbc7fd0()
knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f513260f000 CR3: 32086000 CR4: 06e0
> Call Trace:
>   _raw_spin_trylock+0x13/0x30
>   z3fold_zpool_shrink+0xab/0x3a0
>   zswap_frontswap_store+0x10b/0x610
> ...
> WARNING: CPU: 1 PID: 92 at mm/z3fold.c:278
release_z3fold_page_locked+0x25/0x40
> Modules linked in:
> ...
> INFO: rcu_preempt self-detected stall on CPU
>  2-...!: (20958 ticks this GP) idle=5da/1/4611686018427387906
>  softirq=4104/4113 fqs=11
> ...
> RIP: 0010:queued_spin_lock_slowpath+0x132/0x190
> RSP: :b12740db7750 EFLAGS: 0202 ORIG_RAX: ff13
> RAX: 00100101 RBX: 9cbc7a7000c8 RCX: 0001
> RDX: 0101 RSI: 0001 RDI: 0101
> RBP:  R08: 9cbc7fc21240 R09: af19c900
> R10: b12740db75a0 R11: 0010 R12: f00480522d20
> R13: 9cbc548b4000 R14: 9cbc7a7000d8 R15: f00480522d00
>   ? __zswap_pool_current+0x80/0x90
>   z3fold_zpool_shrink+0x1d3/0x3a0
>   zswap_frontswap_store+0x10b/0x610
> ...

> With lock debugging enabled, the log is a bit different, but similar.

> BUG: MAX_LOCK_DEPTH too low!
> turning off the locking correctness validator.
> depth: 48  max: 48!
> 48 locks held by memory-eater/619:
>   #0: 2da807ce (>mmap_sem){}, at:
__do_page_fault+0x122/0x5a0
>   #1: 12fa6629 (&(>lock)->rlock#3){+.+.}, at:
z3fold_zpool_shrink+0x47/0x3e0
>   #2: c85f45dd (&(>page_lock)->rlock){+.+.}, at:
z3fold_zpool_shrink+0xb7/0x3e0
>   #3: 876f5fdc (&(>page_lock)->rlock){+.+.}, at:
z3fold_zpool_shrink+0xb7/0x3e0
> ...
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [memory-eater:613]
> Modules linked in:
> irq event stamp: 1435394
> hardirqs last  enabled at (1435393): []
> _raw_spin_unlock_irqrestore+0x51/0x60
> hardirqs last disabled at (1435394): []
__schedule+0xba/0xbb0
> softirqs last  enabled at (1434508): []
__do_softirq+0x27c/0x516
> softirqs last disabled at (1434323): []
irq_exit+0xa9/0xc0
> CPU: 0 PID: 613 Comm: memory-eater Tainted: GW
> 4.16.0-yocto-standard+ #9
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1
04/01/2014
> RIP: 0010:queued_spin_lock_slowpath+0x177/0x1a0
> RSP: :a61f80e074e0 EFLAGS: 0246 ORIG_RAX: ff13
> RAX:  RBX: 9704379cba08 RCX: 97043fc22080
> RDX: 0001 RSI: 9c05f6a0 RDI: 0004
> RBP:  R08: 9b1f2215 R09: 
> R10: a61f80e07490 R11: 9704379cba20 R12: 97043fc22080
> R13: de77404e0920 R14: 970413824000 R15: 9704379cba00
> FS:  7f8c6317f700() GS:97043fc0()
knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f8c43f3d010 CR3: 3aba CR4: 06f0
> Call Trace:
>   do_raw_spin_lock+0xad/0xb0
>   z3fold_zpool_malloc+0x595/0x790
> ...

> The problem is easy to reproduce. Please see [2] and the other files
> at [3] for details. Various additional crash logs, observed with
> chromeos-4.14, are available at [4].

> Please let me know if there is anything else I can do to help solving
> or debugging the problem. I had a look into the code, but I must admit
> that its locking is a mystery to me.

> Thanks,
> Guenter

> ---
> [1] http://server.roeck-us.net/qemu/z3pool/crashdump
> [2] http://server.roeck-us.net/qemu/z3pool/README
> [3] http://server.roeck-us.net/qemu/z3pool/
> [4] 

Re: Crashes/hung tasks with z3pool under memory pressure

2018-04-12 Thread Vitaly Wool
Hi Guenter,


Den fre 13 apr. 2018 kl 00:01 skrev Guenter Roeck :

> Hi all,

> we are observing crashes with z3pool under memory pressure. The kernel
version
> used to reproduce the problem is v4.16-11827-g5d1365940a68, but the
problem was
> also seen with v4.14 based kernels.


just before I dig into this, could you please try reproducing the errors
you see with https://patchwork.kernel.org/patch/10210459/ applied?

Thanks,
Vitaly

> For simplicity, here is a set of shortened logs. A more complete log is
> available at [1].

> [ cut here ]
> DEBUG_LOCKS_WARN_ON((preempt_count() & PREEMPT_MASK) >= PREEMPT_MASK - 10)
> WARNING: CPU: 2 PID: 594 at kernel/sched/core.c:3212
preempt_count_add+0x90/0xa0
> Modules linked in:
> CPU: 2 PID: 594 Comm: memory-eater Not tainted 4.16.0-yocto-standard+ #8
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1
04/01/2014
> RIP: 0010:preempt_count_add+0x90/0xa0
> RSP: :b12740db7750 EFLAGS: 00010286
> RAX:  RBX: 0001 RCX: 00f6
> RDX: 00f6 RSI: 0082 RDI: 
> RBP: f00480f357a0 R08: 004a R09: 01ad
> R10: b12740db77e0 R11:  R12: 9cbc7e265d10
> R13: 9cbc7cd5e000 R14: 9cbc7a7000d8 R15: f00480f35780
> FS:  7f5140791700() GS:9cbc7fd0()
knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f513260f000 CR3: 32086000 CR4: 06e0
> Call Trace:
>   _raw_spin_trylock+0x13/0x30
>   z3fold_zpool_shrink+0xab/0x3a0
>   zswap_frontswap_store+0x10b/0x610
> ...
> WARNING: CPU: 1 PID: 92 at mm/z3fold.c:278
release_z3fold_page_locked+0x25/0x40
> Modules linked in:
> ...
> INFO: rcu_preempt self-detected stall on CPU
>  2-...!: (20958 ticks this GP) idle=5da/1/4611686018427387906
>  softirq=4104/4113 fqs=11
> ...
> RIP: 0010:queued_spin_lock_slowpath+0x132/0x190
> RSP: :b12740db7750 EFLAGS: 0202 ORIG_RAX: ff13
> RAX: 00100101 RBX: 9cbc7a7000c8 RCX: 0001
> RDX: 0101 RSI: 0001 RDI: 0101
> RBP:  R08: 9cbc7fc21240 R09: af19c900
> R10: b12740db75a0 R11: 0010 R12: f00480522d20
> R13: 9cbc548b4000 R14: 9cbc7a7000d8 R15: f00480522d00
>   ? __zswap_pool_current+0x80/0x90
>   z3fold_zpool_shrink+0x1d3/0x3a0
>   zswap_frontswap_store+0x10b/0x610
> ...

> With lock debugging enabled, the log is a bit different, but similar.

> BUG: MAX_LOCK_DEPTH too low!
> turning off the locking correctness validator.
> depth: 48  max: 48!
> 48 locks held by memory-eater/619:
>   #0: 2da807ce (>mmap_sem){}, at:
__do_page_fault+0x122/0x5a0
>   #1: 12fa6629 (&(>lock)->rlock#3){+.+.}, at:
z3fold_zpool_shrink+0x47/0x3e0
>   #2: c85f45dd (&(>page_lock)->rlock){+.+.}, at:
z3fold_zpool_shrink+0xb7/0x3e0
>   #3: 876f5fdc (&(>page_lock)->rlock){+.+.}, at:
z3fold_zpool_shrink+0xb7/0x3e0
> ...
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [memory-eater:613]
> Modules linked in:
> irq event stamp: 1435394
> hardirqs last  enabled at (1435393): []
> _raw_spin_unlock_irqrestore+0x51/0x60
> hardirqs last disabled at (1435394): []
__schedule+0xba/0xbb0
> softirqs last  enabled at (1434508): []
__do_softirq+0x27c/0x516
> softirqs last disabled at (1434323): []
irq_exit+0xa9/0xc0
> CPU: 0 PID: 613 Comm: memory-eater Tainted: GW
> 4.16.0-yocto-standard+ #9
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1
04/01/2014
> RIP: 0010:queued_spin_lock_slowpath+0x177/0x1a0
> RSP: :a61f80e074e0 EFLAGS: 0246 ORIG_RAX: ff13
> RAX:  RBX: 9704379cba08 RCX: 97043fc22080
> RDX: 0001 RSI: 9c05f6a0 RDI: 0004
> RBP:  R08: 9b1f2215 R09: 
> R10: a61f80e07490 R11: 9704379cba20 R12: 97043fc22080
> R13: de77404e0920 R14: 970413824000 R15: 9704379cba00
> FS:  7f8c6317f700() GS:97043fc0()
knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7f8c43f3d010 CR3: 3aba CR4: 06f0
> Call Trace:
>   do_raw_spin_lock+0xad/0xb0
>   z3fold_zpool_malloc+0x595/0x790
> ...

> The problem is easy to reproduce. Please see [2] and the other files
> at [3] for details. Various additional crash logs, observed with
> chromeos-4.14, are available at [4].

> Please let me know if there is anything else I can do to help solving
> or debugging the problem. I had a look into the code, but I must admit
> that its locking is a mystery to me.

> Thanks,
> Guenter

> ---
> [1] http://server.roeck-us.net/qemu/z3pool/crashdump
> [2] http://server.roeck-us.net/qemu/z3pool/README
> [3] http://server.roeck-us.net/qemu/z3pool/
> [4] https://bugs.chromium.org/p/chromium/issues/detail?id=822360


Re: [PATCH 00/30] kconfig: move compiler capability tests to Kconfig

2018-04-12 Thread Masahiro Yamada
2018-04-13 14:06 GMT+09:00 Masahiro Yamada :



I forgot to prefix the patch subjects with the version.

This series is V3.







> [Introduction]
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile.  A number of kernel features require the
> compiler support.  Enabling such features blindly in Kconfig ends up
> with a lot of nasty build-time testing in Makefiles.  If a chosen
> feature turns out unsupported by the compiler, what the build system
> can do is either to disable it (silently!) or to forcibly break the
> build, despite Kconfig has let the user to enable it.
>
> [Major Changes in V3]
>
> This version looks more like Make.
>
>   - Use = operator instead of 'macro' keyword
> to define a user-defined function.
>
>   - 'Recursively expanded variable' is implemented as a side-effect.
>  A variable is a function with zero argument.
>
>   - Support simply expanded variable which is defined by := operator
>
>   - Support += operator.
> Probably, this feature will be useful to accumulate compiler flags.
> At least, Clang needs some prerequisite flags such as triplet
> to test other compiler flags.
>
>   - Support $(info ...) and $(warning ...) built-in functions,
> which were useful while I was debugging this.
>
>   - Add documentation
>
>   - Add unit tests
>
>   - Collect helpers to scripts/Kconfig.include
>
> [TODO items]
>
> I have not been able to finish this.  Maybe aiming for v4.18-rc1.
>
>   - The text expansion should be able to defer argument expansion.
> This is necessary if we want to implement $(if ...) built-in function.
>
>   - Error out recursive expansion of itself.
> For example,
> X = $(X)
> refers itself.
> If referenced, the expansion continues eternally.  This must be 
> terminated.
>
>   - More compatible behavior?
> Kconfig works mostly like Make, but there are naive cases
> where the behavior is different.
>
> [Old Versions]
>
> V2:  https://lkml.org/lkml/2018/2/16/610
> V1:  https://lkml.org/lkml/2018/2/16/610
> RFC: https://lkml.org/lkml/2018/2/8/429
>
>
>
> Masahiro Yamada (30):
>   gcc-plugins: fix build condition of SANCOV plugin
>   kbuild: remove kbuild cache
>   kbuild: remove CONFIG_CROSS_COMPILE support
>   kconfig: reference environment variables directly and remove 'option
> env='
>   kconfig: remove string expansion in file_lookup()
>   kconfig: remove string expansion for mainmenu after yyparse()
>   kconfig: remove sym_expand_string_value()
>   kconfig: add built-in function support
>   kconfig: add 'shell' built-in function
>   kconfig: replace $(UNAME_RELEASE) with function call
>   kconfig: begin PARAM state only when seeing a command keyword
>   kconfig: support variable and user-defined function
>   kconfig: support simply expanded variable
>   kconfig: support append assignment operator
>   kconfig: expand lefthand side of assignment statement
>   kconfig: add 'info' and 'warning' built-in functions
>   Documentation: kconfig: document a new Kconfig macro language
>   kconfig: test: test text expansion
>   kconfig: show compiler version text in the top comment
>   kconfig: add basic helper macros to scripts/Kconfig.include
>   stack-protector: test compiler capability in Kconfig and drop AUTO
> mode
>   kconfig: add CC_IS_GCC and GCC_VERSION
>   kconfig: add CC_IS_CLANG and CLANG_VERSION
>   gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT
>   kcov: test compiler capability in Kconfig and correct dependency
>   gcc-plugins: move GCC version check for PowerPC to Kconfig
>   gcc-plugins: test plugin support in Kconfig and clean up Makefile
>   gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
>   arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
>   kbuild: test dead code/data elimination support in Kconfig
>
>  Documentation/kbuild/kconfig-language.txt  |   8 -
>  Documentation/kbuild/kconfig-macro-language.txt| 179 +++
>  Kconfig|  10 +-
>  MAINTAINERS|   3 +-
>  Makefile   | 113 +---
>  arch/Kconfig   |  53 +-
>  arch/arm64/Kconfig |   1 +
>  arch/arm64/Makefile|   2 -
>  arch/powerpc/Kconfig   |   2 +-
>  arch/sh/Kconfig|   4 +-
>  arch/sparc/Kconfig |   4 +-
>  arch/um/Kconfig.common |   4 -
>  arch/x86/Kconfig   |  15 +-
>  arch/x86/um/Kconfig|   6 +-
>  init/Kconfig   |  40 +-
>  kernel/gcov/Kconfig|  17 +-
>  kernel/gcov/Makefile   |   2 -
>  lib/Kconfig.debug

Re: [PATCH 00/30] kconfig: move compiler capability tests to Kconfig

2018-04-12 Thread Masahiro Yamada
2018-04-13 14:06 GMT+09:00 Masahiro Yamada :



I forgot to prefix the patch subjects with the version.

This series is V3.







> [Introduction]
>
> The motivation of this work is to move the compiler option tests to
> Kconfig from Makefile.  A number of kernel features require the
> compiler support.  Enabling such features blindly in Kconfig ends up
> with a lot of nasty build-time testing in Makefiles.  If a chosen
> feature turns out unsupported by the compiler, what the build system
> can do is either to disable it (silently!) or to forcibly break the
> build, despite Kconfig has let the user to enable it.
>
> [Major Changes in V3]
>
> This version looks more like Make.
>
>   - Use = operator instead of 'macro' keyword
> to define a user-defined function.
>
>   - 'Recursively expanded variable' is implemented as a side-effect.
>  A variable is a function with zero argument.
>
>   - Support simply expanded variable which is defined by := operator
>
>   - Support += operator.
> Probably, this feature will be useful to accumulate compiler flags.
> At least, Clang needs some prerequisite flags such as triplet
> to test other compiler flags.
>
>   - Support $(info ...) and $(warning ...) built-in functions,
> which were useful while I was debugging this.
>
>   - Add documentation
>
>   - Add unit tests
>
>   - Collect helpers to scripts/Kconfig.include
>
> [TODO items]
>
> I have not been able to finish this.  Maybe aiming for v4.18-rc1.
>
>   - The text expansion should be able to defer argument expansion.
> This is necessary if we want to implement $(if ...) built-in function.
>
>   - Error out recursive expansion of itself.
> For example,
> X = $(X)
> refers itself.
> If referenced, the expansion continues eternally.  This must be 
> terminated.
>
>   - More compatible behavior?
> Kconfig works mostly like Make, but there are naive cases
> where the behavior is different.
>
> [Old Versions]
>
> V2:  https://lkml.org/lkml/2018/2/16/610
> V1:  https://lkml.org/lkml/2018/2/16/610
> RFC: https://lkml.org/lkml/2018/2/8/429
>
>
>
> Masahiro Yamada (30):
>   gcc-plugins: fix build condition of SANCOV plugin
>   kbuild: remove kbuild cache
>   kbuild: remove CONFIG_CROSS_COMPILE support
>   kconfig: reference environment variables directly and remove 'option
> env='
>   kconfig: remove string expansion in file_lookup()
>   kconfig: remove string expansion for mainmenu after yyparse()
>   kconfig: remove sym_expand_string_value()
>   kconfig: add built-in function support
>   kconfig: add 'shell' built-in function
>   kconfig: replace $(UNAME_RELEASE) with function call
>   kconfig: begin PARAM state only when seeing a command keyword
>   kconfig: support variable and user-defined function
>   kconfig: support simply expanded variable
>   kconfig: support append assignment operator
>   kconfig: expand lefthand side of assignment statement
>   kconfig: add 'info' and 'warning' built-in functions
>   Documentation: kconfig: document a new Kconfig macro language
>   kconfig: test: test text expansion
>   kconfig: show compiler version text in the top comment
>   kconfig: add basic helper macros to scripts/Kconfig.include
>   stack-protector: test compiler capability in Kconfig and drop AUTO
> mode
>   kconfig: add CC_IS_GCC and GCC_VERSION
>   kconfig: add CC_IS_CLANG and CLANG_VERSION
>   gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT
>   kcov: test compiler capability in Kconfig and correct dependency
>   gcc-plugins: move GCC version check for PowerPC to Kconfig
>   gcc-plugins: test plugin support in Kconfig and clean up Makefile
>   gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
>   arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
>   kbuild: test dead code/data elimination support in Kconfig
>
>  Documentation/kbuild/kconfig-language.txt  |   8 -
>  Documentation/kbuild/kconfig-macro-language.txt| 179 +++
>  Kconfig|  10 +-
>  MAINTAINERS|   3 +-
>  Makefile   | 113 +---
>  arch/Kconfig   |  53 +-
>  arch/arm64/Kconfig |   1 +
>  arch/arm64/Makefile|   2 -
>  arch/powerpc/Kconfig   |   2 +-
>  arch/sh/Kconfig|   4 +-
>  arch/sparc/Kconfig |   4 +-
>  arch/um/Kconfig.common |   4 -
>  arch/x86/Kconfig   |  15 +-
>  arch/x86/um/Kconfig|   6 +-
>  init/Kconfig   |  40 +-
>  kernel/gcov/Kconfig|  17 +-
>  kernel/gcov/Makefile   |   2 -
>  lib/Kconfig.debug  |  11 +-
>  

[PATCH v2] staging: Android: Add 'vsoc' driver for cuttlefish.

2018-04-12 Thread Alistair Strachan
From: Greg Hartman 

The cuttlefish system is a virtual SoC architecture based on QEMU. It
uses the QEMU ivshmem feature to share memory regions between guest and
host with a custom protocol.

Cc: Greg Kroah-Hartman 
Cc: Arve Hjønnevåg 
Cc: Todd Kjos 
Cc: Martijn Coenen 
Cc: Dan Carpenter 
Cc: de...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Greg Hartman 
[astrachan: rebased against 4.16, added TODO, fixed checkpatch issues]
Signed-off-by: Alistair Strachan 
---
v2: addressed issues with class_create() failure handling and redundant
null pointer checks noticed by Dan Carpenter

 drivers/staging/android/Kconfig |9 +
 drivers/staging/android/Makefile|1 +
 drivers/staging/android/TODO|   10 +
 drivers/staging/android/uapi/vsoc_shm.h |  303 ++
 drivers/staging/android/vsoc.c  | 1169 +++
 5 files changed, 1492 insertions(+)
 create mode 100644 drivers/staging/android/uapi/vsoc_shm.h
 create mode 100644 drivers/staging/android/vsoc.c

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 71a50b99caff..29d891355f7a 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -14,6 +14,15 @@ config ASHMEM
  It is, in theory, a good memory allocator for low-memory devices,
  because it can discard shared memory units when under memory pressure.
 
+config ANDROID_VSOC
+   tristate "Android Virtual SoC support"
+   default n
+   depends on PCI_MSI
+   ---help---
+ This option adds support for the Virtual SoC driver needed to boot
+ a 'cuttlefish' Android image inside QEmu. The driver interacts with
+ a QEmu ivshmem device. If built as a module, it will be called vsoc.
+
 source "drivers/staging/android/ion/Kconfig"
 
 endif # if ANDROID
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 7cf1564a49a5..90e6154f11a4 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)   # needed for trace 
events
 obj-y  += ion/
 
 obj-$(CONFIG_ASHMEM)   += ashmem.o
+obj-$(CONFIG_ANDROID_VSOC) += vsoc.o
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 687e0eac85bf..6aab759efa48 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -11,5 +11,15 @@ ion/
  - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
  - Better test framework (integration with VGEM was suggested)
 
+vsoc.c, uapi/vsoc_shm.h
+ - The current driver uses the same wait queue for all of the futexes in a
+   region. This will cause false wakeups in regions with a large number of
+   waiting threads. We should eventually use multiple queues and select the
+   queue based on the region.
+ - Add debugfs support for examining the permissions of regions.
+ - Use ioremap_wc instead of ioremap_nocache.
+ - Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been
+   superseded by the futex and is there for legacy reasons.
+
 Please send patches to Greg Kroah-Hartman  and Cc:
 Arve Hjønnevåg  and Riley Andrews 
diff --git a/drivers/staging/android/uapi/vsoc_shm.h 
b/drivers/staging/android/uapi/vsoc_shm.h
new file mode 100644
index ..741b1387c25b
--- /dev/null
+++ b/drivers/staging/android/uapi/vsoc_shm.h
@@ -0,0 +1,303 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _UAPI_LINUX_VSOC_SHM_H
+#define _UAPI_LINUX_VSOC_SHM_H
+
+#include 
+
+/**
+ * A permission is a token that permits a receiver to read and/or write an area
+ * of memory within a Vsoc region.
+ *
+ * An fd_scoped permission grants both read and write access, and can be
+ * attached to a file description (see open(2)).
+ * Ownership of the area can then be shared by passing a file descriptor
+ * among processes.
+ *
+ * begin_offset and end_offset define the area of memory that is controlled by
+ * the permission. owner_offset points to a word, also in shared memory, that
+ * controls ownership of the area.
+ *
+ * ownership of the region expires when the associated file description is
+ * released.
+ *
+ * At most one permission can be attached 

[PATCH v2] staging: Android: Add 'vsoc' driver for cuttlefish.

2018-04-12 Thread Alistair Strachan
From: Greg Hartman 

The cuttlefish system is a virtual SoC architecture based on QEMU. It
uses the QEMU ivshmem feature to share memory regions between guest and
host with a custom protocol.

Cc: Greg Kroah-Hartman 
Cc: Arve Hjønnevåg 
Cc: Todd Kjos 
Cc: Martijn Coenen 
Cc: Dan Carpenter 
Cc: de...@driverdev.osuosl.org
Cc: kernel-t...@android.com
Signed-off-by: Greg Hartman 
[astrachan: rebased against 4.16, added TODO, fixed checkpatch issues]
Signed-off-by: Alistair Strachan 
---
v2: addressed issues with class_create() failure handling and redundant
null pointer checks noticed by Dan Carpenter

 drivers/staging/android/Kconfig |9 +
 drivers/staging/android/Makefile|1 +
 drivers/staging/android/TODO|   10 +
 drivers/staging/android/uapi/vsoc_shm.h |  303 ++
 drivers/staging/android/vsoc.c  | 1169 +++
 5 files changed, 1492 insertions(+)
 create mode 100644 drivers/staging/android/uapi/vsoc_shm.h
 create mode 100644 drivers/staging/android/vsoc.c

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 71a50b99caff..29d891355f7a 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -14,6 +14,15 @@ config ASHMEM
  It is, in theory, a good memory allocator for low-memory devices,
  because it can discard shared memory units when under memory pressure.
 
+config ANDROID_VSOC
+   tristate "Android Virtual SoC support"
+   default n
+   depends on PCI_MSI
+   ---help---
+ This option adds support for the Virtual SoC driver needed to boot
+ a 'cuttlefish' Android image inside QEmu. The driver interacts with
+ a QEmu ivshmem device. If built as a module, it will be called vsoc.
+
 source "drivers/staging/android/ion/Kconfig"
 
 endif # if ANDROID
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 7cf1564a49a5..90e6154f11a4 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)   # needed for trace 
events
 obj-y  += ion/
 
 obj-$(CONFIG_ASHMEM)   += ashmem.o
+obj-$(CONFIG_ANDROID_VSOC) += vsoc.o
diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 687e0eac85bf..6aab759efa48 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -11,5 +11,15 @@ ion/
  - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
  - Better test framework (integration with VGEM was suggested)
 
+vsoc.c, uapi/vsoc_shm.h
+ - The current driver uses the same wait queue for all of the futexes in a
+   region. This will cause false wakeups in regions with a large number of
+   waiting threads. We should eventually use multiple queues and select the
+   queue based on the region.
+ - Add debugfs support for examining the permissions of regions.
+ - Use ioremap_wc instead of ioremap_nocache.
+ - Remove VSOC_WAIT_FOR_INCOMING_INTERRUPT ioctl. This functionality has been
+   superseded by the futex and is there for legacy reasons.
+
 Please send patches to Greg Kroah-Hartman  and Cc:
 Arve Hjønnevåg  and Riley Andrews 
diff --git a/drivers/staging/android/uapi/vsoc_shm.h 
b/drivers/staging/android/uapi/vsoc_shm.h
new file mode 100644
index ..741b1387c25b
--- /dev/null
+++ b/drivers/staging/android/uapi/vsoc_shm.h
@@ -0,0 +1,303 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _UAPI_LINUX_VSOC_SHM_H
+#define _UAPI_LINUX_VSOC_SHM_H
+
+#include 
+
+/**
+ * A permission is a token that permits a receiver to read and/or write an area
+ * of memory within a Vsoc region.
+ *
+ * An fd_scoped permission grants both read and write access, and can be
+ * attached to a file description (see open(2)).
+ * Ownership of the area can then be shared by passing a file descriptor
+ * among processes.
+ *
+ * begin_offset and end_offset define the area of memory that is controlled by
+ * the permission. owner_offset points to a word, also in shared memory, that
+ * controls ownership of the area.
+ *
+ * ownership of the region expires when the associated file description is
+ * released.
+ *
+ * At most one permission can be attached to each file description.
+ *
+ * This is useful when implementing HALs like gralloc that scope and pass
+ * ownership of shared resources via file descriptors.
+ *
+ * The caller is responsibe for doing any fencing.
+ *
+ * The 

[PATCH 09/30] kconfig: add 'shell' built-in function

2018-04-12 Thread Masahiro Yamada
This accepts a single command to execute.  It returns the standard
output from it.

[Example code]

  config HELLO
  string
  default "$(shell echo hello world)"

  config Y
  def_bool $(shell echo y)

[Result]

  $ make -s alldefconfig && tail -n 2 .config
  CONFIG_HELLO="hello world"
  CONFIG_Y=y

Caveat:
Like environments, functions are expanded in the lexer.  You cannot
pass symbols to function arguments.  This is a limitation to simplify
the implementation.  I want to avoid the dynamic function evaluation,
which would introduce much more complexity.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/preprocess.c | 66 
 1 file changed, 66 insertions(+)

diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index e77cf7c..f4c606f 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -86,7 +86,73 @@ struct function {
char *(*func)(int argc, char *argv[]);
 };
 
+/*
+ * Some commands treats commas verbatim.  Concatenate arguments to get
+ * back the original input.  The returned string must be freed when done.
+ */
+static char *join_args(int argc, char *argv[])
+{
+   size_t len = 0;
+   char *out;
+   int i;
+
+   for (i = 0; i < argc; i++)
+   len += strlen(argv[i]) + 1;
+
+   out = xmalloc(len);
+   out[0] = 0;
+   for (i = 0; i < argc; i++) {
+   strcat(out, argv[i]);
+   if (i != argc - 1)
+   strcat(out, ",");
+   }
+
+   return out;
+}
+
+static char *do_shell(int argc, char *argv[])
+{
+   FILE *p;
+   char buf[256];
+   char *cmd;
+   size_t nread;
+   int i;
+
+   cmd = join_args(argc, argv);
+
+   p = popen(cmd, "r");
+   if (!p) {
+   perror(cmd);
+   goto free;
+   }
+
+   nread = fread(buf, 1, sizeof(buf), p);
+   if (nread == sizeof(buf))
+   nread--;
+
+   /* remove trailing new lines */
+   while (buf[nread - 1] == '\n')
+   nread--;
+
+   buf[nread] = 0;
+
+   /* replace a new line with a space */
+   for (i = 0; i < nread; i++) {
+   if (buf[i] == '\n')
+   buf[i] = ' ';
+   }
+
+   if (pclose(p) == -1)
+   perror(cmd);
+
+free:
+   free(cmd);
+
+   return xstrdup(buf);
+}
+
 static const struct function function_table[] = {
+   { .name = "shell", .func = do_shell },
 };
 
 static char *function_call(const char *name, int argc, char *argv[])
-- 
2.7.4



[PATCH 09/30] kconfig: add 'shell' built-in function

2018-04-12 Thread Masahiro Yamada
This accepts a single command to execute.  It returns the standard
output from it.

[Example code]

  config HELLO
  string
  default "$(shell echo hello world)"

  config Y
  def_bool $(shell echo y)

[Result]

  $ make -s alldefconfig && tail -n 2 .config
  CONFIG_HELLO="hello world"
  CONFIG_Y=y

Caveat:
Like environments, functions are expanded in the lexer.  You cannot
pass symbols to function arguments.  This is a limitation to simplify
the implementation.  I want to avoid the dynamic function evaluation,
which would introduce much more complexity.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/preprocess.c | 66 
 1 file changed, 66 insertions(+)

diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index e77cf7c..f4c606f 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -86,7 +86,73 @@ struct function {
char *(*func)(int argc, char *argv[]);
 };
 
+/*
+ * Some commands treats commas verbatim.  Concatenate arguments to get
+ * back the original input.  The returned string must be freed when done.
+ */
+static char *join_args(int argc, char *argv[])
+{
+   size_t len = 0;
+   char *out;
+   int i;
+
+   for (i = 0; i < argc; i++)
+   len += strlen(argv[i]) + 1;
+
+   out = xmalloc(len);
+   out[0] = 0;
+   for (i = 0; i < argc; i++) {
+   strcat(out, argv[i]);
+   if (i != argc - 1)
+   strcat(out, ",");
+   }
+
+   return out;
+}
+
+static char *do_shell(int argc, char *argv[])
+{
+   FILE *p;
+   char buf[256];
+   char *cmd;
+   size_t nread;
+   int i;
+
+   cmd = join_args(argc, argv);
+
+   p = popen(cmd, "r");
+   if (!p) {
+   perror(cmd);
+   goto free;
+   }
+
+   nread = fread(buf, 1, sizeof(buf), p);
+   if (nread == sizeof(buf))
+   nread--;
+
+   /* remove trailing new lines */
+   while (buf[nread - 1] == '\n')
+   nread--;
+
+   buf[nread] = 0;
+
+   /* replace a new line with a space */
+   for (i = 0; i < nread; i++) {
+   if (buf[i] == '\n')
+   buf[i] = ' ';
+   }
+
+   if (pclose(p) == -1)
+   perror(cmd);
+
+free:
+   free(cmd);
+
+   return xstrdup(buf);
+}
+
 static const struct function function_table[] = {
+   { .name = "shell", .func = do_shell },
 };
 
 static char *function_call(const char *name, int argc, char *argv[])
-- 
2.7.4



[PATCH 18/30] kconfig: test: test text expansion

2018-04-12 Thread Masahiro Yamada
Here are the test cases I used for developing the text expansion
feature.

I implemented a similar language as you see in Make.  The implementation
is different (the source code in GNU Make is much longer, so I did not
want to pull it in), but the behavior is hopefully almost the same.

I intentionally changed some behavior and syntax, but I tried to stick
to the make-like behavior where possible.

It might be interesting to compare the behavior between Make and
Kconfig.

[1] Variable test

You can directly run scripts/kconfig/tests/preprocess/variable/Kconfig
by make.

Make and Kconfig produce the exactly the same output for the variable
test.  The output from Make:

  $ cd scripts/kconfig/tests/preprocess/variable && make -f Kconfig
  Kconfig:5: SIMPLE = 1
  Kconfig:11: RECURSIVE = 2
  Kconfig:17: SIMPLE = 1 3
  Kconfig:23: RECURSIVE = 2 4
  Kconfig:30: UNDEFINED_VARIABLE = 4
  Kconfig:36: AB = 5
  Kconfig:39: X = A
  make: *** No targets.  Stop.

[2] Built-in function test

The output from Make:

  $ cd scripts/kconfig/tests/preprocess/builtin_func && make -f Kconfig
  hello,world 0
  Kconfig:7: hello,world 1
  Kconfig:11: hello,  world 2
  Kconfig:15: hello,world 3
  Kconfig:19: hello, world  4
  make: *** No targets.  Stop.

The output from "$(warning   hello,  world 2)" is different.
"Kconfig:11: hello,  world 2" vs "Kconfig:11:   hello,  world 2"

Make strips all leading spaces from the first argument, but does not
touch the other arguments.  I thought this was inconsistent.  So, I
changed the behavior to not touch any arguments at all.

[3] User-defined function test

I changed the syntax for calling a user-defined function.  In
Make, it is invoked by using the 'call' built-in function as in
$(call greeting,Hello,John) but in Kconfig it is invoked without
'call' as in $(greeting Hello,John).  Except the syntax difference,
the test case works exactly in the same way for Make and Kconfig.

[4] Escape sequence test

Except the syntax of user-defined function, Make and Kconfig work
in the same way.  The behavior of a standalone '$' is different
among Make versions.

By fixing the user-defined function syntax, Make 4.1 or older
works like this:

  Kconfig:5: arg0= arg1=
  Kconfig:9: arg0=, arg1=,
  Kconfig:13: ' " '"   ' ''' "'"
  Kconfig:16: $
  Kconfig:20: $X
  Kconfig:26: nasty
  Kconfig:32: super_nasty
  Kconfig:41:
  Kconfig:46: X
  Kconfig:49:
  make: *** No targets.  Stop.

Make 4.2 or newer is like this:

  Kconfig:5: arg0= arg1=
  Kconfig:9: arg0=, arg1=,
  Kconfig:13: ' " '"   ' ''' "'"
  Kconfig:16: $
  Kconfig:20: $X
  Kconfig:26: nasty
  Kconfig:32: super_nasty
  Kconfig:41: $
  Kconfig:46: $X
  Kconfig:49: nasty
  make: *** No targets.  Stop.

The last three lines are different.  I adopted the behavior of the
newer Make versions.  Of course, you should not write such code.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 .../kconfig/tests/preprocess/builtin_func/Kconfig  | 19 +
 .../tests/preprocess/builtin_func/__init__.py  |  8 
 .../tests/preprocess/builtin_func/expected_stderr  |  4 ++
 .../tests/preprocess/builtin_func/expected_stdout  |  1 +
 scripts/kconfig/tests/preprocess/escape/Kconfig| 49 ++
 .../kconfig/tests/preprocess/escape/__init__.py|  9 
 .../tests/preprocess/escape/expected_stderr| 10 +
 scripts/kconfig/tests/preprocess/user_func/Kconfig | 19 +
 .../kconfig/tests/preprocess/user_func/__init__.py |  7 
 .../tests/preprocess/user_func/expected_stderr |  5 +++
 scripts/kconfig/tests/preprocess/variable/Kconfig  | 39 +
 .../kconfig/tests/preprocess/variable/__init__.py  |  7 
 .../tests/preprocess/variable/expected_stderr  |  7 
 13 files changed, 184 insertions(+)
 create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/__init__.py
 create mode 100644 
scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
 create mode 100644 
scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
 create mode 100644 scripts/kconfig/tests/preprocess/escape/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/escape/__init__.py
 create mode 100644 scripts/kconfig/tests/preprocess/escape/expected_stderr
 create mode 100644 scripts/kconfig/tests/preprocess/user_func/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/user_func/__init__.py
 create mode 100644 scripts/kconfig/tests/preprocess/user_func/expected_stderr
 create mode 100644 scripts/kconfig/tests/preprocess/variable/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/variable/__init__.py
 create mode 100644 scripts/kconfig/tests/preprocess/variable/expected_stderr

diff --git a/scripts/kconfig/tests/preprocess/builtin_func/Kconfig 
b/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
new file mode 100644
index 000..5dc454e
--- /dev/null
+++ 

[PATCH 18/30] kconfig: test: test text expansion

2018-04-12 Thread Masahiro Yamada
Here are the test cases I used for developing the text expansion
feature.

I implemented a similar language as you see in Make.  The implementation
is different (the source code in GNU Make is much longer, so I did not
want to pull it in), but the behavior is hopefully almost the same.

I intentionally changed some behavior and syntax, but I tried to stick
to the make-like behavior where possible.

It might be interesting to compare the behavior between Make and
Kconfig.

[1] Variable test

You can directly run scripts/kconfig/tests/preprocess/variable/Kconfig
by make.

Make and Kconfig produce the exactly the same output for the variable
test.  The output from Make:

  $ cd scripts/kconfig/tests/preprocess/variable && make -f Kconfig
  Kconfig:5: SIMPLE = 1
  Kconfig:11: RECURSIVE = 2
  Kconfig:17: SIMPLE = 1 3
  Kconfig:23: RECURSIVE = 2 4
  Kconfig:30: UNDEFINED_VARIABLE = 4
  Kconfig:36: AB = 5
  Kconfig:39: X = A
  make: *** No targets.  Stop.

[2] Built-in function test

The output from Make:

  $ cd scripts/kconfig/tests/preprocess/builtin_func && make -f Kconfig
  hello,world 0
  Kconfig:7: hello,world 1
  Kconfig:11: hello,  world 2
  Kconfig:15: hello,world 3
  Kconfig:19: hello, world  4
  make: *** No targets.  Stop.

The output from "$(warning   hello,  world 2)" is different.
"Kconfig:11: hello,  world 2" vs "Kconfig:11:   hello,  world 2"

Make strips all leading spaces from the first argument, but does not
touch the other arguments.  I thought this was inconsistent.  So, I
changed the behavior to not touch any arguments at all.

[3] User-defined function test

I changed the syntax for calling a user-defined function.  In
Make, it is invoked by using the 'call' built-in function as in
$(call greeting,Hello,John) but in Kconfig it is invoked without
'call' as in $(greeting Hello,John).  Except the syntax difference,
the test case works exactly in the same way for Make and Kconfig.

[4] Escape sequence test

Except the syntax of user-defined function, Make and Kconfig work
in the same way.  The behavior of a standalone '$' is different
among Make versions.

By fixing the user-defined function syntax, Make 4.1 or older
works like this:

  Kconfig:5: arg0= arg1=
  Kconfig:9: arg0=, arg1=,
  Kconfig:13: ' " '"   ' ''' "'"
  Kconfig:16: $
  Kconfig:20: $X
  Kconfig:26: nasty
  Kconfig:32: super_nasty
  Kconfig:41:
  Kconfig:46: X
  Kconfig:49:
  make: *** No targets.  Stop.

Make 4.2 or newer is like this:

  Kconfig:5: arg0= arg1=
  Kconfig:9: arg0=, arg1=,
  Kconfig:13: ' " '"   ' ''' "'"
  Kconfig:16: $
  Kconfig:20: $X
  Kconfig:26: nasty
  Kconfig:32: super_nasty
  Kconfig:41: $
  Kconfig:46: $X
  Kconfig:49: nasty
  make: *** No targets.  Stop.

The last three lines are different.  I adopted the behavior of the
newer Make versions.  Of course, you should not write such code.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 .../kconfig/tests/preprocess/builtin_func/Kconfig  | 19 +
 .../tests/preprocess/builtin_func/__init__.py  |  8 
 .../tests/preprocess/builtin_func/expected_stderr  |  4 ++
 .../tests/preprocess/builtin_func/expected_stdout  |  1 +
 scripts/kconfig/tests/preprocess/escape/Kconfig| 49 ++
 .../kconfig/tests/preprocess/escape/__init__.py|  9 
 .../tests/preprocess/escape/expected_stderr| 10 +
 scripts/kconfig/tests/preprocess/user_func/Kconfig | 19 +
 .../kconfig/tests/preprocess/user_func/__init__.py |  7 
 .../tests/preprocess/user_func/expected_stderr |  5 +++
 scripts/kconfig/tests/preprocess/variable/Kconfig  | 39 +
 .../kconfig/tests/preprocess/variable/__init__.py  |  7 
 .../tests/preprocess/variable/expected_stderr  |  7 
 13 files changed, 184 insertions(+)
 create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/builtin_func/__init__.py
 create mode 100644 
scripts/kconfig/tests/preprocess/builtin_func/expected_stderr
 create mode 100644 
scripts/kconfig/tests/preprocess/builtin_func/expected_stdout
 create mode 100644 scripts/kconfig/tests/preprocess/escape/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/escape/__init__.py
 create mode 100644 scripts/kconfig/tests/preprocess/escape/expected_stderr
 create mode 100644 scripts/kconfig/tests/preprocess/user_func/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/user_func/__init__.py
 create mode 100644 scripts/kconfig/tests/preprocess/user_func/expected_stderr
 create mode 100644 scripts/kconfig/tests/preprocess/variable/Kconfig
 create mode 100644 scripts/kconfig/tests/preprocess/variable/__init__.py
 create mode 100644 scripts/kconfig/tests/preprocess/variable/expected_stderr

diff --git a/scripts/kconfig/tests/preprocess/builtin_func/Kconfig 
b/scripts/kconfig/tests/preprocess/builtin_func/Kconfig
new file mode 100644
index 000..5dc454e
--- /dev/null
+++ 

[PATCH 00/30] kconfig: move compiler capability tests to Kconfig

2018-04-12 Thread Masahiro Yamada

[Introduction]

The motivation of this work is to move the compiler option tests to
Kconfig from Makefile.  A number of kernel features require the
compiler support.  Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles.  If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it.

[Major Changes in V3]

This version looks more like Make.

  - Use = operator instead of 'macro' keyword
to define a user-defined function.

  - 'Recursively expanded variable' is implemented as a side-effect.
 A variable is a function with zero argument.

  - Support simply expanded variable which is defined by := operator

  - Support += operator.
Probably, this feature will be useful to accumulate compiler flags.
At least, Clang needs some prerequisite flags such as triplet
to test other compiler flags.

  - Support $(info ...) and $(warning ...) built-in functions,
which were useful while I was debugging this.

  - Add documentation

  - Add unit tests

  - Collect helpers to scripts/Kconfig.include

[TODO items]

I have not been able to finish this.  Maybe aiming for v4.18-rc1.

  - The text expansion should be able to defer argument expansion.
This is necessary if we want to implement $(if ...) built-in function.

  - Error out recursive expansion of itself.
For example,
X = $(X)
refers itself.
If referenced, the expansion continues eternally.  This must be terminated.

  - More compatible behavior?
Kconfig works mostly like Make, but there are naive cases
where the behavior is different.

[Old Versions]

V2:  https://lkml.org/lkml/2018/2/16/610
V1:  https://lkml.org/lkml/2018/2/16/610
RFC: https://lkml.org/lkml/2018/2/8/429



Masahiro Yamada (30):
  gcc-plugins: fix build condition of SANCOV plugin
  kbuild: remove kbuild cache
  kbuild: remove CONFIG_CROSS_COMPILE support
  kconfig: reference environment variables directly and remove 'option
env='
  kconfig: remove string expansion in file_lookup()
  kconfig: remove string expansion for mainmenu after yyparse()
  kconfig: remove sym_expand_string_value()
  kconfig: add built-in function support
  kconfig: add 'shell' built-in function
  kconfig: replace $(UNAME_RELEASE) with function call
  kconfig: begin PARAM state only when seeing a command keyword
  kconfig: support variable and user-defined function
  kconfig: support simply expanded variable
  kconfig: support append assignment operator
  kconfig: expand lefthand side of assignment statement
  kconfig: add 'info' and 'warning' built-in functions
  Documentation: kconfig: document a new Kconfig macro language
  kconfig: test: test text expansion
  kconfig: show compiler version text in the top comment
  kconfig: add basic helper macros to scripts/Kconfig.include
  stack-protector: test compiler capability in Kconfig and drop AUTO
mode
  kconfig: add CC_IS_GCC and GCC_VERSION
  kconfig: add CC_IS_CLANG and CLANG_VERSION
  gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT
  kcov: test compiler capability in Kconfig and correct dependency
  gcc-plugins: move GCC version check for PowerPC to Kconfig
  gcc-plugins: test plugin support in Kconfig and clean up Makefile
  gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
  arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
  kbuild: test dead code/data elimination support in Kconfig

 Documentation/kbuild/kconfig-language.txt  |   8 -
 Documentation/kbuild/kconfig-macro-language.txt| 179 +++
 Kconfig|  10 +-
 MAINTAINERS|   3 +-
 Makefile   | 113 +---
 arch/Kconfig   |  53 +-
 arch/arm64/Kconfig |   1 +
 arch/arm64/Makefile|   2 -
 arch/powerpc/Kconfig   |   2 +-
 arch/sh/Kconfig|   4 +-
 arch/sparc/Kconfig |   4 +-
 arch/um/Kconfig.common |   4 -
 arch/x86/Kconfig   |  15 +-
 arch/x86/um/Kconfig|   6 +-
 init/Kconfig   |  40 +-
 kernel/gcov/Kconfig|  17 +-
 kernel/gcov/Makefile   |   2 -
 lib/Kconfig.debug  |  11 +-
 scripts/Kbuild.include | 101 +---
 scripts/Kconfig.include|  20 +
 scripts/Makefile.gcc-plugins   |  91 +---
 scripts/Makefile.kcov  |  10 +-
 scripts/clang-version.sh   |  18 +-
 scripts/gcc-plugins/Makefile

[PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

2018-04-12 Thread Masahiro Yamada
Add a document for the macro language introduced to Kconfig.

The motivation of this work is to move the compiler option tests to
Kconfig from Makefile.  A number of kernel features require the
compiler support.  Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles.  If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it.

This change was strongly prompted by Linus Torvalds.  You can find
his suggestions [1] [2] in ML.  The original idea was to add a new
'option', but I found generalized text expansion would make Kconfig
more powerful and lovely.  While polishing up the implementation, I
noticed sort of similarity between Make and Kconfig.  This might be
too immature to be called 'language', but anyway here it is.  All
ideas are from Make (you can even say it is addicted), so people
will easily understand how it works.

[1]: https://lkml.org/lkml/2016/12/9/577
[2]: https://lkml.org/lkml/2018/2/7/527

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Documentation/kbuild/kconfig-macro-language.txt | 179 
 MAINTAINERS |   2 +-
 2 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/kbuild/kconfig-macro-language.txt

diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
b/Documentation/kbuild/kconfig-macro-language.txt
new file mode 100644
index 000..1f6281b
--- /dev/null
+++ b/Documentation/kbuild/kconfig-macro-language.txt
@@ -0,0 +1,179 @@
+Concept
+---
+
+The basic idea was inspired by Make. When we look at Make, we notice sort of
+two languages in one. One language describes dependency graphs consisting of
+targets and prerequisites. The other is a macro language for performing textual
+substitution.
+
+There is clear distinction between the two language stages. For example, you
+can write a makefile like follows:
+
+APP := foo
+SRC := foo.c
+CC := gcc
+
+$(APP): $(SRC)
+$(CC) -o $(APP) $(SRC)
+
+The macro language replaces the variable references with their expanded form,
+and handles as if the source file were input like follows:
+
+foo: foo.c
+gcc -o foo foo.c
+
+Then, Make analyzes the dependency graph and determines the targets to be
+updated.
+
+The idea is quite similar in Kconfig - it is possible to describe a Kconfig
+file like this:
+
+CC := gcc
+
+config CC_HAS_FOO
+def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
+
+The macro language in Kconfig processes the source file into the following
+intermediate:
+
+config CC_HAS_FOO
+def_bool y
+
+Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
+dependency, which is explained in kconfig-language.txt.
+
+
+Variables
+-
+
+Like in Make, a variable in Kconfig works as a macro variable.  A macro
+variable is expanded "in place" to yield a text string that may then expanded
+further. To get the value of a variable, enclose the variable name in $( ).
+As a special case, single-letter variable names can omit the parentheses and is
+simply referenced like $X. Unlike Make, Kconfig does not support curly braces
+as in ${CC}.
+
+There are two types of variables: simply expanded variables and recursively
+expanded variables.
+
+A simply expanded variable is defined using the := assignment operator. Its
+righthand side is expanded immediately upon reading the line from the Kconfig
+file.
+
+A recursively expanded variable is defined using the = assignment operator.
+Its righthand side is simply stored as the value of the variable without
+expanding it in any way. Instead, the expansion is performed when the variable
+is used.
+
+There is another type of assignment operator; += is used to append text to a
+variable. The righthand side of += is expanded immediately if the lefthand
+side was originally defined as a simple variable. Otherwise, its evaluation is
+deferred.
+
+
+Functions
+-
+
+Like Make, Kconfig supports both built-in and user-defined functions. A
+function invocation looks much like a variable reference, but includes one or
+more parameters separated by commas:
+
+  $(function-name arg1, arg2, arg3)
+
+Some functions are implemented as a built-in function. Currently, Kconfig
+supports the following:
+
+ - $(shell command)
+
+  The 'shell' function accepts a single argument that is expanded and passed
+  to a subshell for execution. The standard output of the command is then read
+  and returned as the value of the function. Every newline in the output is
+  replaced with a space. Any trailing newlines are deleted. The standard error
+  is not returned, nor is any program exit status.
+
+ - $(warning text)
+
+  The 'warning' function prints its arguments to stderr. The 

[PATCH 00/30] kconfig: move compiler capability tests to Kconfig

2018-04-12 Thread Masahiro Yamada

[Introduction]

The motivation of this work is to move the compiler option tests to
Kconfig from Makefile.  A number of kernel features require the
compiler support.  Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles.  If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it.

[Major Changes in V3]

This version looks more like Make.

  - Use = operator instead of 'macro' keyword
to define a user-defined function.

  - 'Recursively expanded variable' is implemented as a side-effect.
 A variable is a function with zero argument.

  - Support simply expanded variable which is defined by := operator

  - Support += operator.
Probably, this feature will be useful to accumulate compiler flags.
At least, Clang needs some prerequisite flags such as triplet
to test other compiler flags.

  - Support $(info ...) and $(warning ...) built-in functions,
which were useful while I was debugging this.

  - Add documentation

  - Add unit tests

  - Collect helpers to scripts/Kconfig.include

[TODO items]

I have not been able to finish this.  Maybe aiming for v4.18-rc1.

  - The text expansion should be able to defer argument expansion.
This is necessary if we want to implement $(if ...) built-in function.

  - Error out recursive expansion of itself.
For example,
X = $(X)
refers itself.
If referenced, the expansion continues eternally.  This must be terminated.

  - More compatible behavior?
Kconfig works mostly like Make, but there are naive cases
where the behavior is different.

[Old Versions]

V2:  https://lkml.org/lkml/2018/2/16/610
V1:  https://lkml.org/lkml/2018/2/16/610
RFC: https://lkml.org/lkml/2018/2/8/429



Masahiro Yamada (30):
  gcc-plugins: fix build condition of SANCOV plugin
  kbuild: remove kbuild cache
  kbuild: remove CONFIG_CROSS_COMPILE support
  kconfig: reference environment variables directly and remove 'option
env='
  kconfig: remove string expansion in file_lookup()
  kconfig: remove string expansion for mainmenu after yyparse()
  kconfig: remove sym_expand_string_value()
  kconfig: add built-in function support
  kconfig: add 'shell' built-in function
  kconfig: replace $(UNAME_RELEASE) with function call
  kconfig: begin PARAM state only when seeing a command keyword
  kconfig: support variable and user-defined function
  kconfig: support simply expanded variable
  kconfig: support append assignment operator
  kconfig: expand lefthand side of assignment statement
  kconfig: add 'info' and 'warning' built-in functions
  Documentation: kconfig: document a new Kconfig macro language
  kconfig: test: test text expansion
  kconfig: show compiler version text in the top comment
  kconfig: add basic helper macros to scripts/Kconfig.include
  stack-protector: test compiler capability in Kconfig and drop AUTO
mode
  kconfig: add CC_IS_GCC and GCC_VERSION
  kconfig: add CC_IS_CLANG and CLANG_VERSION
  gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT
  kcov: test compiler capability in Kconfig and correct dependency
  gcc-plugins: move GCC version check for PowerPC to Kconfig
  gcc-plugins: test plugin support in Kconfig and clean up Makefile
  gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
  arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
  kbuild: test dead code/data elimination support in Kconfig

 Documentation/kbuild/kconfig-language.txt  |   8 -
 Documentation/kbuild/kconfig-macro-language.txt| 179 +++
 Kconfig|  10 +-
 MAINTAINERS|   3 +-
 Makefile   | 113 +---
 arch/Kconfig   |  53 +-
 arch/arm64/Kconfig |   1 +
 arch/arm64/Makefile|   2 -
 arch/powerpc/Kconfig   |   2 +-
 arch/sh/Kconfig|   4 +-
 arch/sparc/Kconfig |   4 +-
 arch/um/Kconfig.common |   4 -
 arch/x86/Kconfig   |  15 +-
 arch/x86/um/Kconfig|   6 +-
 init/Kconfig   |  40 +-
 kernel/gcov/Kconfig|  17 +-
 kernel/gcov/Makefile   |   2 -
 lib/Kconfig.debug  |  11 +-
 scripts/Kbuild.include | 101 +---
 scripts/Kconfig.include|  20 +
 scripts/Makefile.gcc-plugins   |  91 +---
 scripts/Makefile.kcov  |  10 +-
 scripts/clang-version.sh   |  18 +-
 scripts/gcc-plugins/Makefile

[PATCH 17/30] Documentation: kconfig: document a new Kconfig macro language

2018-04-12 Thread Masahiro Yamada
Add a document for the macro language introduced to Kconfig.

The motivation of this work is to move the compiler option tests to
Kconfig from Makefile.  A number of kernel features require the
compiler support.  Enabling such features blindly in Kconfig ends up
with a lot of nasty build-time testing in Makefiles.  If a chosen
feature turns out unsupported by the compiler, what the build system
can do is either to disable it (silently!) or to forcibly break the
build, despite Kconfig has let the user to enable it.

This change was strongly prompted by Linus Torvalds.  You can find
his suggestions [1] [2] in ML.  The original idea was to add a new
'option', but I found generalized text expansion would make Kconfig
more powerful and lovely.  While polishing up the implementation, I
noticed sort of similarity between Make and Kconfig.  This might be
too immature to be called 'language', but anyway here it is.  All
ideas are from Make (you can even say it is addicted), so people
will easily understand how it works.

[1]: https://lkml.org/lkml/2016/12/9/577
[2]: https://lkml.org/lkml/2018/2/7/527

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Documentation/kbuild/kconfig-macro-language.txt | 179 
 MAINTAINERS |   2 +-
 2 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/kbuild/kconfig-macro-language.txt

diff --git a/Documentation/kbuild/kconfig-macro-language.txt 
b/Documentation/kbuild/kconfig-macro-language.txt
new file mode 100644
index 000..1f6281b
--- /dev/null
+++ b/Documentation/kbuild/kconfig-macro-language.txt
@@ -0,0 +1,179 @@
+Concept
+---
+
+The basic idea was inspired by Make. When we look at Make, we notice sort of
+two languages in one. One language describes dependency graphs consisting of
+targets and prerequisites. The other is a macro language for performing textual
+substitution.
+
+There is clear distinction between the two language stages. For example, you
+can write a makefile like follows:
+
+APP := foo
+SRC := foo.c
+CC := gcc
+
+$(APP): $(SRC)
+$(CC) -o $(APP) $(SRC)
+
+The macro language replaces the variable references with their expanded form,
+and handles as if the source file were input like follows:
+
+foo: foo.c
+gcc -o foo foo.c
+
+Then, Make analyzes the dependency graph and determines the targets to be
+updated.
+
+The idea is quite similar in Kconfig - it is possible to describe a Kconfig
+file like this:
+
+CC := gcc
+
+config CC_HAS_FOO
+def_bool $(shell $(srctree)/scripts/gcc-check-foo.sh $(CC))
+
+The macro language in Kconfig processes the source file into the following
+intermediate:
+
+config CC_HAS_FOO
+def_bool y
+
+Then, Kconfig moves onto the evaluation stage to resolve inter-symbol
+dependency, which is explained in kconfig-language.txt.
+
+
+Variables
+-
+
+Like in Make, a variable in Kconfig works as a macro variable.  A macro
+variable is expanded "in place" to yield a text string that may then expanded
+further. To get the value of a variable, enclose the variable name in $( ).
+As a special case, single-letter variable names can omit the parentheses and is
+simply referenced like $X. Unlike Make, Kconfig does not support curly braces
+as in ${CC}.
+
+There are two types of variables: simply expanded variables and recursively
+expanded variables.
+
+A simply expanded variable is defined using the := assignment operator. Its
+righthand side is expanded immediately upon reading the line from the Kconfig
+file.
+
+A recursively expanded variable is defined using the = assignment operator.
+Its righthand side is simply stored as the value of the variable without
+expanding it in any way. Instead, the expansion is performed when the variable
+is used.
+
+There is another type of assignment operator; += is used to append text to a
+variable. The righthand side of += is expanded immediately if the lefthand
+side was originally defined as a simple variable. Otherwise, its evaluation is
+deferred.
+
+
+Functions
+-
+
+Like Make, Kconfig supports both built-in and user-defined functions. A
+function invocation looks much like a variable reference, but includes one or
+more parameters separated by commas:
+
+  $(function-name arg1, arg2, arg3)
+
+Some functions are implemented as a built-in function. Currently, Kconfig
+supports the following:
+
+ - $(shell command)
+
+  The 'shell' function accepts a single argument that is expanded and passed
+  to a subshell for execution. The standard output of the command is then read
+  and returned as the value of the function. Every newline in the output is
+  replaced with a space. Any trailing newlines are deleted. The standard error
+  is not returned, nor is any program exit status.
+
+ - $(warning text)
+
+  The 'warning' function prints its arguments to stderr. The output is prefixed
+  with the 

[PATCH 13/30] kconfig: support simply expanded variable

2018-04-12 Thread Masahiro Yamada
The previous commit added variable and user-defined function.  They
work similarly in the sense that the evaluation is deferred until
they are used.

This commit adds another type of variable, simply expanded variable,
as we see in Make.

The := operator defines a simply expanded variable, expanding the
righthand side immediately.  This works like traditional programming
language variables.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/kconfig/lkc_proto.h  | 7 ++-
 scripts/kconfig/preprocess.c | 6 --
 scripts/kconfig/zconf.l  | 3 ++-
 scripts/kconfig/zconf.y  | 5 +++--
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 2b16d6e..6303193 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -49,8 +49,13 @@ const char * sym_get_string_value(struct symbol *sym);
 const char * prop_get_type_name(enum prop_type type);
 
 /* preprocess.c */
+enum variable_flavor {
+   VAR_SIMPLE,
+   VAR_RECURSIVE,
+};
 void env_write_dep(FILE *f, const char *auto_conf_name);
-void variable_add(const char *name, const char *value);
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor);
 void variable_all_del(void);
 char *expand_string(const char *in);
 char *expand_dollar(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 1b746e0..a835c94 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -112,7 +112,8 @@ static char *variable_expand(const char *name, int argc, 
char *argv[])
return expand_string_with_args(v->value, argc, argv);
 }
 
-void variable_add(const char *name, const char *value)
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor)
 {
struct variable *v;
 
@@ -125,7 +126,8 @@ void variable_add(const char *name, const char *value)
list_add_tail(>node, _list);
}
 
-   v->value = xstrdup(value);
+   v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+   xstrdup(value);
 }
 
 static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 19e5ebf..aa76942 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,7 +114,8 @@ n   [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
-   "=" { BEGIN(ASSIGN_VAL); return T_ASSIGN; }
+   "=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return 
T_ASSIGN; }
+   ":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return 
T_ASSIGN; }
[[:blank:]]+
.   warn_ignored_character(*yytext);
\n  {
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 493388c..1ebbf9e 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -41,6 +41,7 @@ static struct menu *current_menu, *current_entry;
struct expr *expr;
struct menu *menu;
const struct kconf_id *id;
+   enum variable_flavor flavor;
 }
 
 %token T_MAINMENU
@@ -78,7 +79,7 @@ static struct menu *current_menu, *current_entry;
 %token T_OPEN_PAREN
 %token T_EOL
 %token  T_VARIABLE
-%token T_ASSIGN
+%token  T_ASSIGN
 %token  T_ASSIGN_VAL
 
 %left T_OR
@@ -517,7 +518,7 @@ word_opt: /* empty */   { $$ = NULL; }
 
 /* assignment statement */
 
-assignment_stmt:  T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3); 
free($1); free($3); }
+assignment_stmt:  T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3, 
$2); free($1); free($3); }
 
 assign_val:
/* empty */ { $$ = xstrdup(""); };
-- 
2.7.4



[PATCH 13/30] kconfig: support simply expanded variable

2018-04-12 Thread Masahiro Yamada
The previous commit added variable and user-defined function.  They
work similarly in the sense that the evaluation is deferred until
they are used.

This commit adds another type of variable, simply expanded variable,
as we see in Make.

The := operator defines a simply expanded variable, expanding the
righthand side immediately.  This works like traditional programming
language variables.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/kconfig/lkc_proto.h  | 7 ++-
 scripts/kconfig/preprocess.c | 6 --
 scripts/kconfig/zconf.l  | 3 ++-
 scripts/kconfig/zconf.y  | 5 +++--
 4 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 2b16d6e..6303193 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -49,8 +49,13 @@ const char * sym_get_string_value(struct symbol *sym);
 const char * prop_get_type_name(enum prop_type type);
 
 /* preprocess.c */
+enum variable_flavor {
+   VAR_SIMPLE,
+   VAR_RECURSIVE,
+};
 void env_write_dep(FILE *f, const char *auto_conf_name);
-void variable_add(const char *name, const char *value);
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor);
 void variable_all_del(void);
 char *expand_string(const char *in);
 char *expand_dollar(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 1b746e0..a835c94 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -112,7 +112,8 @@ static char *variable_expand(const char *name, int argc, 
char *argv[])
return expand_string_with_args(v->value, argc, argv);
 }
 
-void variable_add(const char *name, const char *value)
+void variable_add(const char *name, const char *value,
+ enum variable_flavor flavor)
 {
struct variable *v;
 
@@ -125,7 +126,8 @@ void variable_add(const char *name, const char *value)
list_add_tail(>node, _list);
}
 
-   v->value = xstrdup(value);
+   v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+   xstrdup(value);
 }
 
 static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 19e5ebf..aa76942 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,7 +114,8 @@ n   [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
-   "=" { BEGIN(ASSIGN_VAL); return T_ASSIGN; }
+   "=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return 
T_ASSIGN; }
+   ":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return 
T_ASSIGN; }
[[:blank:]]+
.   warn_ignored_character(*yytext);
\n  {
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 493388c..1ebbf9e 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -41,6 +41,7 @@ static struct menu *current_menu, *current_entry;
struct expr *expr;
struct menu *menu;
const struct kconf_id *id;
+   enum variable_flavor flavor;
 }
 
 %token T_MAINMENU
@@ -78,7 +79,7 @@ static struct menu *current_menu, *current_entry;
 %token T_OPEN_PAREN
 %token T_EOL
 %token  T_VARIABLE
-%token T_ASSIGN
+%token  T_ASSIGN
 %token  T_ASSIGN_VAL
 
 %left T_OR
@@ -517,7 +518,7 @@ word_opt: /* empty */   { $$ = NULL; }
 
 /* assignment statement */
 
-assignment_stmt:  T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3); 
free($1); free($3); }
+assignment_stmt:  T_VARIABLE T_ASSIGN assign_val T_EOL { variable_add($1, $3, 
$2); free($1); free($3); }
 
 assign_val:
/* empty */ { $$ = xstrdup(""); };
-- 
2.7.4



[PATCH 19/30] kconfig: show compiler version text in the top comment

2018-04-12 Thread Masahiro Yamada
The kernel configuration phase is now tightly coupled with the compiler
in use.  It will be nice to show the compiler information in Kconfig.

The compiler information will be displayed like this:

  $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
  scripts/kconfig/conf  --oldaskconfig Kconfig
  *
  * Linux/arm64 4.16.0-rc1 Kernel Configuration
  *
  *
  * Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
  *
  *
  * General setup
  *
  Compile also drivers which will not load (COMPILE_TEST) [N/y/?]

If you use GUI methods such as menuconfig, it will be displayed in the
top menu.

This is simply implemented by using the 'comment' statement.  So, it
will be saved into the .config file as well.

This commit has a very important meaning.  If the compiler is upgraded,
Kconfig must be re-run since different compilers have different sets
of supported options.

All referenced environments are written to include/config/auto.conf.cmd
so that any environment change triggers syncconfig, and prompt the user
to input new values if needed.

With this commit, something like follows will be added to
include/config/auto.conf.cmd

  ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 
7.2.1 20171011"
  include/config/auto.conf: FORCE
  endif

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 Kconfig  | 2 ++
 Makefile | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Kconfig b/Kconfig
index 4af1b42..5b55d87 100644
--- a/Kconfig
+++ b/Kconfig
@@ -5,4 +5,6 @@
 #
 mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
 
+comment "Compiler: $(CC_VERSION_TEXT)"
+
 source "arch/$(SRCARCH)/Kconfig"
diff --git a/Makefile b/Makefile
index ca3e3e8..4b36329 100644
--- a/Makefile
+++ b/Makefile
@@ -442,6 +442,8 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE 
KBUILD_LDFLAGS_MODULE
 export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
 export KBUILD_ARFLAGS
 
+export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1)
+
 # When compiling out-of-tree modules, put MODVERDIR in the module
 # tree rather than in the kernel tree. The kernel tree might
 # even be read-only.
-- 
2.7.4



[PATCH 19/30] kconfig: show compiler version text in the top comment

2018-04-12 Thread Masahiro Yamada
The kernel configuration phase is now tightly coupled with the compiler
in use.  It will be nice to show the compiler information in Kconfig.

The compiler information will be displayed like this:

  $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
  scripts/kconfig/conf  --oldaskconfig Kconfig
  *
  * Linux/arm64 4.16.0-rc1 Kernel Configuration
  *
  *
  * Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
  *
  *
  * General setup
  *
  Compile also drivers which will not load (COMPILE_TEST) [N/y/?]

If you use GUI methods such as menuconfig, it will be displayed in the
top menu.

This is simply implemented by using the 'comment' statement.  So, it
will be saved into the .config file as well.

This commit has a very important meaning.  If the compiler is upgraded,
Kconfig must be re-run since different compilers have different sets
of supported options.

All referenced environments are written to include/config/auto.conf.cmd
so that any environment change triggers syncconfig, and prompt the user
to input new values if needed.

With this commit, something like follows will be added to
include/config/auto.conf.cmd

  ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 
7.2.1 20171011"
  include/config/auto.conf: FORCE
  endif

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 Kconfig  | 2 ++
 Makefile | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Kconfig b/Kconfig
index 4af1b42..5b55d87 100644
--- a/Kconfig
+++ b/Kconfig
@@ -5,4 +5,6 @@
 #
 mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
 
+comment "Compiler: $(CC_VERSION_TEXT)"
+
 source "arch/$(SRCARCH)/Kconfig"
diff --git a/Makefile b/Makefile
index ca3e3e8..4b36329 100644
--- a/Makefile
+++ b/Makefile
@@ -442,6 +442,8 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE 
KBUILD_LDFLAGS_MODULE
 export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
 export KBUILD_ARFLAGS
 
+export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1)
+
 # When compiling out-of-tree modules, put MODVERDIR in the module
 # tree rather than in the kernel tree. The kernel tree might
 # even be read-only.
-- 
2.7.4



[PATCH 22/30] kconfig: add CC_IS_GCC and GCC_VERSION

2018-04-12 Thread Masahiro Yamada
This will be useful to specify the required compiler version,
like this:

config FOO
bool "Use Foo"
depends on GCC_VERSION >= 408000
help
  This feature requires GCC 4.8 or newer.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 init/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 4b0b636..145a534 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -8,6 +8,14 @@ config DEFCONFIG_LIST
default ARCH_DEFCONFIG
default "arch/$(ARCH)/defconfig"
 
+config CC_IS_GCC
+   def_bool $(success $(CC) --version | grep -q gcc)
+
+config GCC_VERSION
+   int
+   default $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 
's/^0*//') if CC_IS_GCC
+   default 0
+
 config CONSTRUCTORS
bool
depends on !UML
-- 
2.7.4



[PATCH 20/30] kconfig: add basic helper macros to scripts/Kconfig.include

2018-04-12 Thread Masahiro Yamada
Kconfig got text processing tools like we see in Make.  Add Kconfig
helper macros to scripts/Kconfig.include like we collect Makefile
macros in scripts/Kbuild.include.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3:
  - Move helpers to scripts/Kconfig.include

Changes in v2: None

 Kconfig |  2 ++
 MAINTAINERS |  1 +
 scripts/Kconfig.include | 17 +
 3 files changed, 20 insertions(+)
 create mode 100644 scripts/Kconfig.include

diff --git a/Kconfig b/Kconfig
index 5b55d87..a90d9f9 100644
--- a/Kconfig
+++ b/Kconfig
@@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
 
 comment "Compiler: $(CC_VERSION_TEXT)"
 
+source "scripts/Kconfig.include"
+
 source "arch/$(SRCARCH)/Kconfig"
diff --git a/MAINTAINERS b/MAINTAINERS
index b9dab38..d962f4a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7624,6 +7624,7 @@ L:linux-kbu...@vger.kernel.org
 S: Maintained
 F: Documentation/kbuild/kconfig*
 F: scripts/kconfig/
+F: scripts/Kconfig.include
 
 KDUMP
 M: Dave Young 
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
new file mode 100644
index 000..cac7a81
--- /dev/null
+++ b/scripts/Kconfig.include
@@ -0,0 +1,17 @@
+# Kconfig helper macros
+
+# Convenient variables
+comma   := ,
+quote   := "
+squote  := '
+empty   :=
+space   := $(empty) $(empty)
+
+# y if the command exits with 0, n otherwise
+success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)
+
+# y if the given compiler flag is supported, n otherwise
+cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)
+
+# y if the given linker flag is supported, n otherwise
+ld-option = $(success $(LD) -v $(1))
-- 
2.7.4



[PATCH 22/30] kconfig: add CC_IS_GCC and GCC_VERSION

2018-04-12 Thread Masahiro Yamada
This will be useful to specify the required compiler version,
like this:

config FOO
bool "Use Foo"
depends on GCC_VERSION >= 408000
help
  This feature requires GCC 4.8 or newer.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 init/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/init/Kconfig b/init/Kconfig
index 4b0b636..145a534 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -8,6 +8,14 @@ config DEFCONFIG_LIST
default ARCH_DEFCONFIG
default "arch/$(ARCH)/defconfig"
 
+config CC_IS_GCC
+   def_bool $(success $(CC) --version | grep -q gcc)
+
+config GCC_VERSION
+   int
+   default $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 
's/^0*//') if CC_IS_GCC
+   default 0
+
 config CONSTRUCTORS
bool
depends on !UML
-- 
2.7.4



[PATCH 20/30] kconfig: add basic helper macros to scripts/Kconfig.include

2018-04-12 Thread Masahiro Yamada
Kconfig got text processing tools like we see in Make.  Add Kconfig
helper macros to scripts/Kconfig.include like we collect Makefile
macros in scripts/Kbuild.include.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3:
  - Move helpers to scripts/Kconfig.include

Changes in v2: None

 Kconfig |  2 ++
 MAINTAINERS |  1 +
 scripts/Kconfig.include | 17 +
 3 files changed, 20 insertions(+)
 create mode 100644 scripts/Kconfig.include

diff --git a/Kconfig b/Kconfig
index 5b55d87..a90d9f9 100644
--- a/Kconfig
+++ b/Kconfig
@@ -7,4 +7,6 @@ mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
 
 comment "Compiler: $(CC_VERSION_TEXT)"
 
+source "scripts/Kconfig.include"
+
 source "arch/$(SRCARCH)/Kconfig"
diff --git a/MAINTAINERS b/MAINTAINERS
index b9dab38..d962f4a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7624,6 +7624,7 @@ L:linux-kbu...@vger.kernel.org
 S: Maintained
 F: Documentation/kbuild/kconfig*
 F: scripts/kconfig/
+F: scripts/Kconfig.include
 
 KDUMP
 M: Dave Young 
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
new file mode 100644
index 000..cac7a81
--- /dev/null
+++ b/scripts/Kconfig.include
@@ -0,0 +1,17 @@
+# Kconfig helper macros
+
+# Convenient variables
+comma   := ,
+quote   := "
+squote  := '
+empty   :=
+space   := $(empty) $(empty)
+
+# y if the command exits with 0, n otherwise
+success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)
+
+# y if the given compiler flag is supported, n otherwise
+cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)
+
+# y if the given linker flag is supported, n otherwise
+ld-option = $(success $(LD) -v $(1))
-- 
2.7.4



[PATCH 23/30] kconfig: add CC_IS_CLANG and CLANG_VERSION

2018-04-12 Thread Masahiro Yamada
This will be useful to describe the clang version dependency.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 init/Kconfig |  7 +++
 scripts/clang-version.sh | 18 --
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 145a534..c8f4ba3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -16,6 +16,13 @@ config GCC_VERSION
default $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 
's/^0*//') if CC_IS_GCC
default 0
 
+config CC_IS_CLANG
+   def_bool $(success $(CC) --version | grep -q clang)
+
+config CLANG_VERSION
+   int
+   default $(shell $(srctree)/scripts/clang-version.sh $(CC))
+
 config CONSTRUCTORS
bool
depends on !UML
diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh
index 9780efa..dbf0a31 100755
--- a/scripts/clang-version.sh
+++ b/scripts/clang-version.sh
@@ -10,24 +10,14 @@
 # clang-5.0.1 etc.
 #
 
-if [ "$1" = "-p" ] ; then
-   with_patchlevel=1;
-   shift;
-fi
-
 compiler="$*"
 
-if [ ${#compiler} -eq 0 ]; then
-   echo "Error: No compiler specified."
-   printf "Usage:\n\t$0 \n"
+if !( $compiler --version | grep -q clang) ; then
+   echo 0
exit 1
 fi
 
 MAJOR=$(echo __clang_major__ | $compiler -E -x c - | tail -n 1)
 MINOR=$(echo __clang_minor__ | $compiler -E -x c - | tail -n 1)
-if [ "x$with_patchlevel" != "x" ] ; then
-   PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 
1)
-   printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-else
-   printf "%02d%02d\\n" $MAJOR $MINOR
-fi
+PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 1)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-- 
2.7.4



[PATCH 23/30] kconfig: add CC_IS_CLANG and CLANG_VERSION

2018-04-12 Thread Masahiro Yamada
This will be useful to describe the clang version dependency.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 init/Kconfig |  7 +++
 scripts/clang-version.sh | 18 --
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 145a534..c8f4ba3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -16,6 +16,13 @@ config GCC_VERSION
default $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 
's/^0*//') if CC_IS_GCC
default 0
 
+config CC_IS_CLANG
+   def_bool $(success $(CC) --version | grep -q clang)
+
+config CLANG_VERSION
+   int
+   default $(shell $(srctree)/scripts/clang-version.sh $(CC))
+
 config CONSTRUCTORS
bool
depends on !UML
diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh
index 9780efa..dbf0a31 100755
--- a/scripts/clang-version.sh
+++ b/scripts/clang-version.sh
@@ -10,24 +10,14 @@
 # clang-5.0.1 etc.
 #
 
-if [ "$1" = "-p" ] ; then
-   with_patchlevel=1;
-   shift;
-fi
-
 compiler="$*"
 
-if [ ${#compiler} -eq 0 ]; then
-   echo "Error: No compiler specified."
-   printf "Usage:\n\t$0 \n"
+if !( $compiler --version | grep -q clang) ; then
+   echo 0
exit 1
 fi
 
 MAJOR=$(echo __clang_major__ | $compiler -E -x c - | tail -n 1)
 MINOR=$(echo __clang_minor__ | $compiler -E -x c - | tail -n 1)
-if [ "x$with_patchlevel" != "x" ] ; then
-   PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 
1)
-   printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-else
-   printf "%02d%02d\\n" $MAJOR $MINOR
-fi
+PATCHLEVEL=$(echo __clang_patchlevel__ | $compiler -E -x c - | tail -n 1)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-- 
2.7.4



[PATCH 16/30] kconfig: add 'info' and 'warning' built-in functions

2018-04-12 Thread Masahiro Yamada
Add 'info' and 'warning' functions as in Make.

They print messages during parsing Kconfig files, which is useful
when debugging Kconfig at least.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/preprocess.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 85972fb..f8d06d9 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -203,6 +203,19 @@ static char *join_args(int argc, char *argv[])
return out;
 }
 
+static char *do_info(int argc, char *argv[])
+{
+   char *msg;
+
+   msg = join_args(argc, argv);
+
+   printf("%s\n", msg);
+
+   free(msg);
+
+   return xstrdup("");
+}
+
 static char *do_shell(int argc, char *argv[])
 {
FILE *p;
@@ -244,8 +257,23 @@ static char *do_shell(int argc, char *argv[])
return xstrdup(buf);
 }
 
+static char *do_warning(int argc, char *argv[])
+{
+   char *msg;
+
+   msg = join_args(argc, argv);
+
+   fprintf(stderr, "%s:%d: %s\n", current_file->name, yylineno, msg);
+
+   free(msg);
+
+   return xstrdup("");
+}
+
 static const struct function function_table[] = {
+   { .name = "info", .func = do_info },
{ .name = "shell", .func = do_shell },
+   { .name = "warning", .func = do_warning },
 };
 
 static char *function_call(const char *name, int argc, char *argv[])
-- 
2.7.4



[PATCH 03/30] kbuild: remove CONFIG_CROSS_COMPILE support

2018-04-12 Thread Masahiro Yamada
Kbuild provides a couple of ways to specify CROSS_COMPILE:

[1] Command line
[2] Environment
[3] arch/*/Makefile (only some architectures)
[4] CONFIG_CROSS_COMPILE

[4] is problematic for the compiler capability tests in Kconfig.
CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
'make menuconfig', etc.  It means, the compiler options would have
to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed.

To avoid complexity and performance issues, I'd like to evaluate
the shell commands statically, i.e. only parsing Kconfig files.

I guess the majority is [1] or [2].  Currently, there are only
5 defconfig files that specify CONFIG_CROSS_COMPILE.
  arch/arm/configs/lpc18xx_defconfig
  arch/hexagon/configs/comet_defconfig
  arch/nds32/configs/defconfig
  arch/openrisc/configs/or1ksim_defconfig
  arch/openrisc/configs/simple_smp_defconfig

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 Makefile | 3 ---
 init/Kconfig | 9 -
 2 files changed, 12 deletions(-)

diff --git a/Makefile b/Makefile
index d85cee0..ca3e3e8 100644
--- a/Makefile
+++ b/Makefile
@@ -316,12 +316,9 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e 
s/x86_64/x86/ \
 # CROSS_COMPILE can be set on the command line
 # make CROSS_COMPILE=ia64-linux-
 # Alternatively CROSS_COMPILE can be set in the environment.
-# A third alternative is to store a setting in .config so that plain
-# "make" in the configured kernel build directory always uses that.
 # Default value for CROSS_COMPILE is not to prefix executables
 # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
 ARCH   ?= $(SUBARCH)
-CROSS_COMPILE  ?= $(CONFIG_CROSS_COMPILE:"%"=%)
 
 # Architecture as present in compile.h
 UTS_MACHINE:= $(ARCH)
diff --git a/init/Kconfig b/init/Kconfig
index 9d167a5..c1ca920 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -54,15 +54,6 @@ config INIT_ENV_ARG_LIMIT
  Maximum of each of the number of arguments and environment
  variables passed to init from the kernel command line.
 
-
-config CROSS_COMPILE
-   string "Cross-compiler tool prefix"
-   help
- Same as running 'make CROSS_COMPILE=prefix-' but stored for
- default make runs in this kernel build directory.  You don't
- need to set this unless you want the configured kernel build
- directory to select the cross-compiler automatically.
-
 config COMPILE_TEST
bool "Compile also drivers which will not load"
depends on !UML
-- 
2.7.4



[PATCH 16/30] kconfig: add 'info' and 'warning' built-in functions

2018-04-12 Thread Masahiro Yamada
Add 'info' and 'warning' functions as in Make.

They print messages during parsing Kconfig files, which is useful
when debugging Kconfig at least.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/preprocess.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index 85972fb..f8d06d9 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -203,6 +203,19 @@ static char *join_args(int argc, char *argv[])
return out;
 }
 
+static char *do_info(int argc, char *argv[])
+{
+   char *msg;
+
+   msg = join_args(argc, argv);
+
+   printf("%s\n", msg);
+
+   free(msg);
+
+   return xstrdup("");
+}
+
 static char *do_shell(int argc, char *argv[])
 {
FILE *p;
@@ -244,8 +257,23 @@ static char *do_shell(int argc, char *argv[])
return xstrdup(buf);
 }
 
+static char *do_warning(int argc, char *argv[])
+{
+   char *msg;
+
+   msg = join_args(argc, argv);
+
+   fprintf(stderr, "%s:%d: %s\n", current_file->name, yylineno, msg);
+
+   free(msg);
+
+   return xstrdup("");
+}
+
 static const struct function function_table[] = {
+   { .name = "info", .func = do_info },
{ .name = "shell", .func = do_shell },
+   { .name = "warning", .func = do_warning },
 };
 
 static char *function_call(const char *name, int argc, char *argv[])
-- 
2.7.4



[PATCH 03/30] kbuild: remove CONFIG_CROSS_COMPILE support

2018-04-12 Thread Masahiro Yamada
Kbuild provides a couple of ways to specify CROSS_COMPILE:

[1] Command line
[2] Environment
[3] arch/*/Makefile (only some architectures)
[4] CONFIG_CROSS_COMPILE

[4] is problematic for the compiler capability tests in Kconfig.
CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
'make menuconfig', etc.  It means, the compiler options would have
to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed.

To avoid complexity and performance issues, I'd like to evaluate
the shell commands statically, i.e. only parsing Kconfig files.

I guess the majority is [1] or [2].  Currently, there are only
5 defconfig files that specify CONFIG_CROSS_COMPILE.
  arch/arm/configs/lpc18xx_defconfig
  arch/hexagon/configs/comet_defconfig
  arch/nds32/configs/defconfig
  arch/openrisc/configs/or1ksim_defconfig
  arch/openrisc/configs/simple_smp_defconfig

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 Makefile | 3 ---
 init/Kconfig | 9 -
 2 files changed, 12 deletions(-)

diff --git a/Makefile b/Makefile
index d85cee0..ca3e3e8 100644
--- a/Makefile
+++ b/Makefile
@@ -316,12 +316,9 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e 
s/x86_64/x86/ \
 # CROSS_COMPILE can be set on the command line
 # make CROSS_COMPILE=ia64-linux-
 # Alternatively CROSS_COMPILE can be set in the environment.
-# A third alternative is to store a setting in .config so that plain
-# "make" in the configured kernel build directory always uses that.
 # Default value for CROSS_COMPILE is not to prefix executables
 # Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
 ARCH   ?= $(SUBARCH)
-CROSS_COMPILE  ?= $(CONFIG_CROSS_COMPILE:"%"=%)
 
 # Architecture as present in compile.h
 UTS_MACHINE:= $(ARCH)
diff --git a/init/Kconfig b/init/Kconfig
index 9d167a5..c1ca920 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -54,15 +54,6 @@ config INIT_ENV_ARG_LIMIT
  Maximum of each of the number of arguments and environment
  variables passed to init from the kernel command line.
 
-
-config CROSS_COMPILE
-   string "Cross-compiler tool prefix"
-   help
- Same as running 'make CROSS_COMPILE=prefix-' but stored for
- default make runs in this kernel build directory.  You don't
- need to set this unless you want the configured kernel build
- directory to select the cross-compiler automatically.
-
 config COMPILE_TEST
bool "Compile also drivers which will not load"
depends on !UML
-- 
2.7.4



[PATCH 08/30] kconfig: add built-in function support

2018-04-12 Thread Masahiro Yamada
This commit adds a new concept 'function' to do more text processing
in Kconfig.

A function call looks like this:

  $(function arg1, arg2, arg3, ...)

This commit adds the basic infrastructure to expand functions.
Change the text expansion helpers to take arguments.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Split base infrastructure and 'shell' function
into separate patches.

Changes in v2:
  - Use 'shell' for getting stdout from the comment.
It was 'shell-stdout' in the previous version.
  - Symplify the implementation since the expansion has been moved to
lexer.

 scripts/kconfig/preprocess.c | 142 +++
 1 file changed, 130 insertions(+), 12 deletions(-)

diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index fa4abc8..e77cf7c 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -8,6 +8,10 @@
 
 #include "list.h"
 
+#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
+
+static char *expand_string_with_args(const char *in, int argc, char *argv[]);
+
 /*
  * Environment variables
  */
@@ -74,9 +78,47 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
}
 }
 
-static char *eval_clause(const char *in)
+/*
+ * Built-in Functions
+ */
+struct function {
+   char *name;
+   char *(*func)(int argc, char *argv[]);
+};
+
+static const struct function function_table[] = {
+};
+
+static char *function_call(const char *name, int argc, char *argv[])
 {
-   char *res, *name;
+   const struct function *f;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(function_table); i++) {
+   f = _table[i];
+   if (!strcmp(f->name, name))
+   return f->func(argc, argv);
+   }
+
+   return NULL;
+}
+
+#define FUNCTION_MAX_ARGS  16
+
+/*
+ * Evaluate a clause with arguments.  argc/argv are arguments from the upper
+ * function call.
+ *
+ * Returned string must be freed when done
+ */
+static char *eval_clause(const char *in, int argc, char *argv[])
+{
+   char *tmp, *prev, *p, *res, *name;
+   char delim = ' ';
+   int new_argc = 0;
+   char *new_argv[FUNCTION_MAX_ARGS];
+   int nest = 0;
+   int i;
 
/*
 * Returns an empty string because '$()' should be evaluated
@@ -85,10 +127,73 @@ static char *eval_clause(const char *in)
if (!*in)
return xstrdup("");
 
-   name = expand_string(in);
+   tmp = xstrdup(in);
+
+   prev = p = tmp;
 
-   res = env_expand(name);
+   /*
+* Split into tokens
+* The function name and the first argument are separated by a space.
+* Arguments are separated by a comma.
+* For example, if the function call is like this:
+*   $(foo abc,$(x),$(y))
+*
+* The input string for this helper should be:
+*   foo abc,$(x),$(y)
+*
+* and split into:
+*   new_argv[0]: foo
+*   new_argv[1]: abc
+*   new_argv[2]: $(x)
+*   new_argv[3]: $(y)
+*/
+   while (*p) {
+   if (nest == 0 && *p == delim) {
+   *p = 0;
+   new_argv[new_argc++] = prev;
+   prev = p + 1;
+   delim = ',';
+   } else if (*p == '(') {
+   nest++;
+   } else if (*p == ')') {
+   nest--;
+   }
+
+   p++;
+   }
+   new_argv[new_argc++] = prev;
+
+   /*
+* Shift arguments
+* new_argv[0] represents a function name or a variable name.  Put it
+* into 'name', then shift the rest of the arguments.  This simplifies
+* 'const' handling.
+*/
+   name = expand_string_with_args(new_argv[0], argc, argv);
+   new_argc--;
+   for (i = 0; i < new_argc; i++)
+   new_argv[i] = expand_string_with_args(new_argv[i + 1],
+ argc, argv);
+
+   free(tmp);
+
+   /* Look for built-in functions */
+   res = function_call(name, new_argc, new_argv);
+   if (res)
+   goto out;
+
+   /* Last, try environment variable */
+   if (new_argc == 0) {
+   res = env_expand(name);
+   if (res)
+   goto out;
+   }
+
+   res = xstrdup("");
+out:
free(name);
+   for (i = 0; i < new_argc; i++)
+   free(new_argv[i]);
 
return res;
 }
@@ -115,7 +220,7 @@ static char *eval_clause(const char *in)
  * This is because $ABC is equivalent to $(A)BC.  (Like Make, you can omit
  * parentheses if the variable name consists of a single character.
  */
-char *expand_dollar(const char **str)
+static char *expand_dollar_with_args(const char **str, int argc, char *argv[])
 {
const char *p = *str;
const char *q;

[PATCH 27/30] gcc-plugins: test plugin support in Kconfig and clean up Makefile

2018-04-12 Thread Masahiro Yamada
Run scripts/gcc-plugin.sh from Kconfig so that users can enable
GCC_PLUGINS only when the compiler supports building plugins.

Kconfig defines a new symbol, PLUGIN_HOSTCC.  This will contain
the compiler (g++ or gcc) used for building plugins, or empty
if the plugin can not be supported at all.

This allows us to remove all ugly testing in Makefile.gcc-plugins.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Respin to keep scripts/gcc-plugin.sh as-is.

Changes in v2: None

 arch/Kconfig | 10 ++
 scripts/Kconfig.include  |  3 ++
 scripts/Makefile.gcc-plugins | 79 
 scripts/gcc-plugins/Makefile |  1 +
 4 files changed, 36 insertions(+), 57 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index b0582f2..9166157 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -401,6 +401,15 @@ config SECCOMP_FILTER
 
  See Documentation/prctl/seccomp_filter.txt for details.
 
+preferred-plugin-hostcc := $(shell [ $(gcc-version) -ge 40800 ] && echo 
$(HOSTCXX) || echo $(HOSTCC))
+
+config PLUGIN_HOSTCC
+   string
+   default "$(shell $(srctree)/scripts/gcc-plugin.sh 
$(preferred-plugin-hostcc) $(HOSTCXX) $(CC))"
+   help
+ Host compiler used to build GCC plugins.  This can be $(HOSTCXX),
+ $(HOSTCC), or a null string if GCC plugin is unsupported.
+
 config HAVE_GCC_PLUGINS
bool
help
@@ -410,6 +419,7 @@ config HAVE_GCC_PLUGINS
 menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
+   depends on PLUGIN_HOSTCC != ""
depends on !COMPILE_TEST
help
  GCC plugins are loadable modules that provide extra features to the
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index cac7a81..0864a19 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -15,3 +15,6 @@ cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o 
/dev/null)
 
 # y if the given linker flag is supported, n otherwise
 ld-option = $(success $(LD) -v $(1))
+
+# gcc version including patch level
+gcc-version := $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 
's/^0*//')
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 1e92353..da5d38d 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -1,72 +1,37 @@
 # SPDX-License-Identifier: GPL-2.0
-ifdef CONFIG_GCC_PLUGINS
-  __PLUGINCC := $(call cc-ifversion, -ge, 0408, $(HOSTCXX), $(HOSTCC))
-  PLUGINCC := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-plugin.sh 
"$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)")
-
-  SANCOV_PLUGIN := -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so
-
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY)   += 
cyc_complexity_plugin.so
+gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) += cyc_complexity_plugin.so
 
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)   += 
latent_entropy_plugin.so
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)+= 
-DLATENT_ENTROPY_PLUGIN
-  ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY
+gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += latent_entropy_plugin.so
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)  += 
-DLATENT_ENTROPY_PLUGIN
+ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY
 DISABLE_LATENT_ENTROPY_PLUGIN  += 
-fplugin-arg-latent_entropy_plugin-disable
-  endif
-
-  ifdef CONFIG_GCC_PLUGIN_SANCOV
-  # It is needed because of the gcc-plugin.sh and gcc version checks.
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
-
-  ifeq ($(PLUGINCC),)
-$(warning warning: cannot use CONFIG_KCOV: 
-fsanitize-coverage=trace-pc is not supported by compiler)
-  endif
-  endif
-
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)   += structleak_plugin.so
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE)+= 
-fplugin-arg-structleak_plugin-verbose
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)  += 
-fplugin-arg-structleak_plugin-byref-all
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)+= -DSTRUCTLEAK_PLUGIN
+endif
 
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_RANDSTRUCT)   += randomize_layout_plugin.so
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT)+= -DRANDSTRUCT_PLUGIN
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE)+= 
-fplugin-arg-randomize_layout_plugin-performance-mode
+gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
+gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE)  += 
-fplugin-arg-structleak_plugin-verbose
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)+= 
-fplugin-arg-structleak_plugin-byref-all
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)  += -DSTRUCTLEAK_PLUGIN
 
-  GCC_PLUGINS_CFLAGS := $(strip $(addprefix 
-fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) 

[PATCH 08/30] kconfig: add built-in function support

2018-04-12 Thread Masahiro Yamada
This commit adds a new concept 'function' to do more text processing
in Kconfig.

A function call looks like this:

  $(function arg1, arg2, arg3, ...)

This commit adds the basic infrastructure to expand functions.
Change the text expansion helpers to take arguments.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Split base infrastructure and 'shell' function
into separate patches.

Changes in v2:
  - Use 'shell' for getting stdout from the comment.
It was 'shell-stdout' in the previous version.
  - Symplify the implementation since the expansion has been moved to
lexer.

 scripts/kconfig/preprocess.c | 142 +++
 1 file changed, 130 insertions(+), 12 deletions(-)

diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index fa4abc8..e77cf7c 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -8,6 +8,10 @@
 
 #include "list.h"
 
+#define ARRAY_SIZE(arr)(sizeof(arr) / sizeof((arr)[0]))
+
+static char *expand_string_with_args(const char *in, int argc, char *argv[]);
+
 /*
  * Environment variables
  */
@@ -74,9 +78,47 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
}
 }
 
-static char *eval_clause(const char *in)
+/*
+ * Built-in Functions
+ */
+struct function {
+   char *name;
+   char *(*func)(int argc, char *argv[]);
+};
+
+static const struct function function_table[] = {
+};
+
+static char *function_call(const char *name, int argc, char *argv[])
 {
-   char *res, *name;
+   const struct function *f;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(function_table); i++) {
+   f = _table[i];
+   if (!strcmp(f->name, name))
+   return f->func(argc, argv);
+   }
+
+   return NULL;
+}
+
+#define FUNCTION_MAX_ARGS  16
+
+/*
+ * Evaluate a clause with arguments.  argc/argv are arguments from the upper
+ * function call.
+ *
+ * Returned string must be freed when done
+ */
+static char *eval_clause(const char *in, int argc, char *argv[])
+{
+   char *tmp, *prev, *p, *res, *name;
+   char delim = ' ';
+   int new_argc = 0;
+   char *new_argv[FUNCTION_MAX_ARGS];
+   int nest = 0;
+   int i;
 
/*
 * Returns an empty string because '$()' should be evaluated
@@ -85,10 +127,73 @@ static char *eval_clause(const char *in)
if (!*in)
return xstrdup("");
 
-   name = expand_string(in);
+   tmp = xstrdup(in);
+
+   prev = p = tmp;
 
-   res = env_expand(name);
+   /*
+* Split into tokens
+* The function name and the first argument are separated by a space.
+* Arguments are separated by a comma.
+* For example, if the function call is like this:
+*   $(foo abc,$(x),$(y))
+*
+* The input string for this helper should be:
+*   foo abc,$(x),$(y)
+*
+* and split into:
+*   new_argv[0]: foo
+*   new_argv[1]: abc
+*   new_argv[2]: $(x)
+*   new_argv[3]: $(y)
+*/
+   while (*p) {
+   if (nest == 0 && *p == delim) {
+   *p = 0;
+   new_argv[new_argc++] = prev;
+   prev = p + 1;
+   delim = ',';
+   } else if (*p == '(') {
+   nest++;
+   } else if (*p == ')') {
+   nest--;
+   }
+
+   p++;
+   }
+   new_argv[new_argc++] = prev;
+
+   /*
+* Shift arguments
+* new_argv[0] represents a function name or a variable name.  Put it
+* into 'name', then shift the rest of the arguments.  This simplifies
+* 'const' handling.
+*/
+   name = expand_string_with_args(new_argv[0], argc, argv);
+   new_argc--;
+   for (i = 0; i < new_argc; i++)
+   new_argv[i] = expand_string_with_args(new_argv[i + 1],
+ argc, argv);
+
+   free(tmp);
+
+   /* Look for built-in functions */
+   res = function_call(name, new_argc, new_argv);
+   if (res)
+   goto out;
+
+   /* Last, try environment variable */
+   if (new_argc == 0) {
+   res = env_expand(name);
+   if (res)
+   goto out;
+   }
+
+   res = xstrdup("");
+out:
free(name);
+   for (i = 0; i < new_argc; i++)
+   free(new_argv[i]);
 
return res;
 }
@@ -115,7 +220,7 @@ static char *eval_clause(const char *in)
  * This is because $ABC is equivalent to $(A)BC.  (Like Make, you can omit
  * parentheses if the variable name consists of a single character.
  */
-char *expand_dollar(const char **str)
+static char *expand_dollar_with_args(const char **str, int argc, char *argv[])
 {
const char *p = *str;
const char *q;
@@ -124,6 +229,9 @@ char 

[PATCH 27/30] gcc-plugins: test plugin support in Kconfig and clean up Makefile

2018-04-12 Thread Masahiro Yamada
Run scripts/gcc-plugin.sh from Kconfig so that users can enable
GCC_PLUGINS only when the compiler supports building plugins.

Kconfig defines a new symbol, PLUGIN_HOSTCC.  This will contain
the compiler (g++ or gcc) used for building plugins, or empty
if the plugin can not be supported at all.

This allows us to remove all ugly testing in Makefile.gcc-plugins.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Respin to keep scripts/gcc-plugin.sh as-is.

Changes in v2: None

 arch/Kconfig | 10 ++
 scripts/Kconfig.include  |  3 ++
 scripts/Makefile.gcc-plugins | 79 
 scripts/gcc-plugins/Makefile |  1 +
 4 files changed, 36 insertions(+), 57 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index b0582f2..9166157 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -401,6 +401,15 @@ config SECCOMP_FILTER
 
  See Documentation/prctl/seccomp_filter.txt for details.
 
+preferred-plugin-hostcc := $(shell [ $(gcc-version) -ge 40800 ] && echo 
$(HOSTCXX) || echo $(HOSTCC))
+
+config PLUGIN_HOSTCC
+   string
+   default "$(shell $(srctree)/scripts/gcc-plugin.sh 
$(preferred-plugin-hostcc) $(HOSTCXX) $(CC))"
+   help
+ Host compiler used to build GCC plugins.  This can be $(HOSTCXX),
+ $(HOSTCC), or a null string if GCC plugin is unsupported.
+
 config HAVE_GCC_PLUGINS
bool
help
@@ -410,6 +419,7 @@ config HAVE_GCC_PLUGINS
 menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
+   depends on PLUGIN_HOSTCC != ""
depends on !COMPILE_TEST
help
  GCC plugins are loadable modules that provide extra features to the
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index cac7a81..0864a19 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -15,3 +15,6 @@ cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o 
/dev/null)
 
 # y if the given linker flag is supported, n otherwise
 ld-option = $(success $(LD) -v $(1))
+
+# gcc version including patch level
+gcc-version := $(shell $(srctree)/scripts/gcc-version.sh -p $(CC) | sed 
's/^0*//')
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 1e92353..da5d38d 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -1,72 +1,37 @@
 # SPDX-License-Identifier: GPL-2.0
-ifdef CONFIG_GCC_PLUGINS
-  __PLUGINCC := $(call cc-ifversion, -ge, 0408, $(HOSTCXX), $(HOSTCC))
-  PLUGINCC := $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-plugin.sh 
"$(__PLUGINCC)" "$(HOSTCXX)" "$(CC)")
-
-  SANCOV_PLUGIN := -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so
-
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY)   += 
cyc_complexity_plugin.so
+gcc-plugin-$(CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) += cyc_complexity_plugin.so
 
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)   += 
latent_entropy_plugin.so
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)+= 
-DLATENT_ENTROPY_PLUGIN
-  ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY
+gcc-plugin-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY) += latent_entropy_plugin.so
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_LATENT_ENTROPY)  += 
-DLATENT_ENTROPY_PLUGIN
+ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY
 DISABLE_LATENT_ENTROPY_PLUGIN  += 
-fplugin-arg-latent_entropy_plugin-disable
-  endif
-
-  ifdef CONFIG_GCC_PLUGIN_SANCOV
-  # It is needed because of the gcc-plugin.sh and gcc version checks.
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
-
-  ifeq ($(PLUGINCC),)
-$(warning warning: cannot use CONFIG_KCOV: 
-fsanitize-coverage=trace-pc is not supported by compiler)
-  endif
-  endif
-
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)   += structleak_plugin.so
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE)+= 
-fplugin-arg-structleak_plugin-verbose
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)  += 
-fplugin-arg-structleak_plugin-byref-all
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)+= -DSTRUCTLEAK_PLUGIN
+endif
 
-  gcc-plugin-$(CONFIG_GCC_PLUGIN_RANDSTRUCT)   += randomize_layout_plugin.so
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT)+= -DRANDSTRUCT_PLUGIN
-  gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE)+= 
-fplugin-arg-randomize_layout_plugin-performance-mode
+gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
+gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE)  += 
-fplugin-arg-structleak_plugin-verbose
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL)+= 
-fplugin-arg-structleak_plugin-byref-all
+gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)  += -DSTRUCTLEAK_PLUGIN
 
-  GCC_PLUGINS_CFLAGS := $(strip $(addprefix 
-fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) 
$(gcc-plugin-cflags-y))

[PATCH 14/30] kconfig: support append assignment operator

2018-04-12 Thread Masahiro Yamada
Support += operator.  This appends a space and the text on the
righthand side to a variable.

The timing of the evaluation of the righthand side depends on the
flavor of the variable.  If the lefthand side was originally defined
as a simple variable, the righthand side is expanded immediately.
Otherwise, the expansion is deferred.  Appending something to an
undefined variable results in a recursive variable.

To implement this, we need to remember the flavor of variables.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/kconfig/lkc_proto.h  |  1 +
 scripts/kconfig/preprocess.c | 29 +++--
 scripts/kconfig/zconf.l  |  1 +
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 6303193..a8b7a33 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -52,6 +52,7 @@ const char * prop_get_type_name(enum prop_type type);
 enum variable_flavor {
VAR_SIMPLE,
VAR_RECURSIVE,
+   VAR_APPEND,
 };
 void env_write_dep(FILE *f, const char *auto_conf_name);
 void variable_add(const char *name, const char *value,
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index a835c94..85972fb 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -86,6 +86,7 @@ static LIST_HEAD(variable_list);
 struct variable {
char *name;
char *value;
+   enum variable_flavor flavor;
struct list_head node;
 };
 
@@ -116,18 +117,42 @@ void variable_add(const char *name, const char *value,
  enum variable_flavor flavor)
 {
struct variable *v;
+   char *new_value;
+   bool append = false;
 
v = variable_lookup(name);
if (v) {
-   free(v->value);
+   /* For defined variables, += inherits the existing flavor */
+   if (flavor == VAR_APPEND) {
+   flavor = v->flavor;
+   append = true;
+   } else {
+   free(v->value);
+   }
} else {
+   /* For undefined variables, += assumes the recursive flavor */
+   if (flavor == VAR_APPEND)
+   flavor = VAR_RECURSIVE;
+
v = xmalloc(sizeof(*v));
v->name = xstrdup(name);
list_add_tail(>node, _list);
}
 
-   v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+   v->flavor = flavor;
+
+   new_value = (flavor == VAR_SIMPLE) ? expand_string(value) :
xstrdup(value);
+
+   if (append) {
+   v->value = xrealloc(v->value,
+   strlen(v->value) + strlen(new_value) + 2);
+   strcat(v->value, " ");
+   strcat(v->value, new_value);
+   free(new_value);
+   } else {
+   v->value = new_value;
+   }
 }
 
 static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index aa76942..c68ca56b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -116,6 +116,7 @@ n   [A-Za-z0-9_-]
}
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return 
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return 
T_ASSIGN; }
+   "+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return 
T_ASSIGN; }
[[:blank:]]+
.   warn_ignored_character(*yytext);
\n  {
-- 
2.7.4



[PATCH 14/30] kconfig: support append assignment operator

2018-04-12 Thread Masahiro Yamada
Support += operator.  This appends a space and the text on the
righthand side to a variable.

The timing of the evaluation of the righthand side depends on the
flavor of the variable.  If the lefthand side was originally defined
as a simple variable, the righthand side is expanded immediately.
Otherwise, the expansion is deferred.  Appending something to an
undefined variable results in a recursive variable.

To implement this, we need to remember the flavor of variables.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/kconfig/lkc_proto.h  |  1 +
 scripts/kconfig/preprocess.c | 29 +++--
 scripts/kconfig/zconf.l  |  1 +
 3 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 6303193..a8b7a33 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -52,6 +52,7 @@ const char * prop_get_type_name(enum prop_type type);
 enum variable_flavor {
VAR_SIMPLE,
VAR_RECURSIVE,
+   VAR_APPEND,
 };
 void env_write_dep(FILE *f, const char *auto_conf_name);
 void variable_add(const char *name, const char *value,
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index a835c94..85972fb 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -86,6 +86,7 @@ static LIST_HEAD(variable_list);
 struct variable {
char *name;
char *value;
+   enum variable_flavor flavor;
struct list_head node;
 };
 
@@ -116,18 +117,42 @@ void variable_add(const char *name, const char *value,
  enum variable_flavor flavor)
 {
struct variable *v;
+   char *new_value;
+   bool append = false;
 
v = variable_lookup(name);
if (v) {
-   free(v->value);
+   /* For defined variables, += inherits the existing flavor */
+   if (flavor == VAR_APPEND) {
+   flavor = v->flavor;
+   append = true;
+   } else {
+   free(v->value);
+   }
} else {
+   /* For undefined variables, += assumes the recursive flavor */
+   if (flavor == VAR_APPEND)
+   flavor = VAR_RECURSIVE;
+
v = xmalloc(sizeof(*v));
v->name = xstrdup(name);
list_add_tail(>node, _list);
}
 
-   v->value = (flavor == VAR_SIMPLE) ? expand_string(value) :
+   v->flavor = flavor;
+
+   new_value = (flavor == VAR_SIMPLE) ? expand_string(value) :
xstrdup(value);
+
+   if (append) {
+   v->value = xrealloc(v->value,
+   strlen(v->value) + strlen(new_value) + 2);
+   strcat(v->value, " ");
+   strcat(v->value, new_value);
+   free(new_value);
+   } else {
+   v->value = new_value;
+   }
 }
 
 static void variable_del(struct variable *v)
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index aa76942..c68ca56b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -116,6 +116,7 @@ n   [A-Za-z0-9_-]
}
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return 
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return 
T_ASSIGN; }
+   "+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return 
T_ASSIGN; }
[[:blank:]]+
.   warn_ignored_character(*yytext);
\n  {
-- 
2.7.4



[PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

2018-04-12 Thread Masahiro Yamada
Move the test for -fstack-protector(-strong) option to Kconfig.

If the compiler does not support the option, the corresponding menu
is automatically hidden.  If STRONG is not supported, it will fall
back to REGULAR.  If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly handled by the dependency solver of
Kconfig, hence removed.

I also turned the 'choice' into only two boolean symbols.  The use of
'choice' is not a good idea here, because all of all{yes,mod,no}config
would choose the first visible value, while we want allnoconfig to
disable as many features as possible.

X86 has additional shell scripts in case the compiler supports those
options, but generates broken code.  I added CC_HAS_SANE_STACKPROTECTOR
to test this.  I had to add -m32 to gcc-x86_32-has-stack-protector.sh
to make it work correctly.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Makefile  | 93 ++-
 arch/Kconfig  | 32 ---
 arch/x86/Kconfig  | 11 +++-
 scripts/gcc-x86_32-has-stack-protector.sh |  7 +--
 scripts/gcc-x86_64-has-stack-protector.sh |  5 --
 5 files changed, 28 insertions(+), 120 deletions(-)

diff --git a/Makefile b/Makefile
index 4b36329..889d002 100644
--- a/Makefile
+++ b/Makefile
@@ -672,55 +672,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
 endif
 
-# This selects the stack protector compiler flag. Testing it is delayed
-# until after .config has been reprocessed, in the prepare-compiler-check
-# target.
-ifdef CONFIG_CC_STACKPROTECTOR_AUTO
-  stackp-flag := $(call cc-option,-fstack-protector-strong,$(call 
cc-option,-fstack-protector))
-  stackp-name := AUTO
-else
-ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
-  stackp-flag := -fstack-protector
-  stackp-name := REGULAR
-else
-ifdef CONFIG_CC_STACKPROTECTOR_STRONG
-  stackp-flag := -fstack-protector-strong
-  stackp-name := STRONG
-else
-  # If either there is no stack protector for this architecture or
-  # CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name)
-  # is empty, skipping all remaining stack protector tests.
-  #
-  # Force off for distro compilers that enable stack protector by default.
-  KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
-endif
-endif
-endif
-# Find arch-specific stack protector compiler sanity-checking script.
-ifdef stackp-name
-ifneq ($(stackp-flag),)
-  stackp-path := 
$(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh
-  stackp-check := $(wildcard $(stackp-path))
-  # If the wildcard test matches a test script, run it to check functionality.
-  ifdef stackp-check
-ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS) 
$(biarch)),y)
-  stackp-broken := y
-endif
-  endif
-  ifndef stackp-broken
-# If the stack protector is functional, enable code that depends on it.
-KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR
-# Either we've already detected the flag (for AUTO) or we'll fail the
-# build in the prepare-compiler-check rule (for specific flag).
-KBUILD_CFLAGS += $(stackp-flag)
-  else
-# We have to make sure stack protector is unconditionally disabled if
-# the compiler is broken (in case we're going to continue the build in
-# AUTO mode).
-KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
-  endif
-endif
-endif
+stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR)  := -fstack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG)   := -fstack-protector-strong
+
+KBUILD_CFLAGS += $(stackp-flags-y)
 
 ifeq ($(cc-name),clang)
 KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
@@ -1096,7 +1052,7 @@ endif
 # prepare2 creates a makefile if using a separate output directory.
 # From this point forward, .config has been reprocessed, so any rules
 # that need to depend on updated CONFIG_* values can be checked here.
-prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic
+prepare2: prepare3 outputmakefile asm-generic
 
 prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
include/config/auto.conf
@@ -1122,43 +1078,6 @@ uapi-asm-generic:
 PHONY += prepare-objtool
 prepare-objtool: $(objtool_target)
 
-# Check for CONFIG flags that require compiler support. Abort the build
-# after .config has been processed, but before the kernel build starts.
-#
-# For security-sensitive CONFIG options, we don't want to fallback and/or
-# silently change which compiler flags will be used, since that leads to
-# producing kernels with different security feature characteristics
-# depending on the compiler used. (For example, "But I selected
-# CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!")
-PHONY += prepare-compiler-check

[PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

2018-04-12 Thread Masahiro Yamada
Move the test for -fstack-protector(-strong) option to Kconfig.

If the compiler does not support the option, the corresponding menu
is automatically hidden.  If STRONG is not supported, it will fall
back to REGULAR.  If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly handled by the dependency solver of
Kconfig, hence removed.

I also turned the 'choice' into only two boolean symbols.  The use of
'choice' is not a good idea here, because all of all{yes,mod,no}config
would choose the first visible value, while we want allnoconfig to
disable as many features as possible.

X86 has additional shell scripts in case the compiler supports those
options, but generates broken code.  I added CC_HAS_SANE_STACKPROTECTOR
to test this.  I had to add -m32 to gcc-x86_32-has-stack-protector.sh
to make it work correctly.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Makefile  | 93 ++-
 arch/Kconfig  | 32 ---
 arch/x86/Kconfig  | 11 +++-
 scripts/gcc-x86_32-has-stack-protector.sh |  7 +--
 scripts/gcc-x86_64-has-stack-protector.sh |  5 --
 5 files changed, 28 insertions(+), 120 deletions(-)

diff --git a/Makefile b/Makefile
index 4b36329..889d002 100644
--- a/Makefile
+++ b/Makefile
@@ -672,55 +672,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
 endif
 
-# This selects the stack protector compiler flag. Testing it is delayed
-# until after .config has been reprocessed, in the prepare-compiler-check
-# target.
-ifdef CONFIG_CC_STACKPROTECTOR_AUTO
-  stackp-flag := $(call cc-option,-fstack-protector-strong,$(call 
cc-option,-fstack-protector))
-  stackp-name := AUTO
-else
-ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
-  stackp-flag := -fstack-protector
-  stackp-name := REGULAR
-else
-ifdef CONFIG_CC_STACKPROTECTOR_STRONG
-  stackp-flag := -fstack-protector-strong
-  stackp-name := STRONG
-else
-  # If either there is no stack protector for this architecture or
-  # CONFIG_CC_STACKPROTECTOR_NONE is selected, we're done, and $(stackp-name)
-  # is empty, skipping all remaining stack protector tests.
-  #
-  # Force off for distro compilers that enable stack protector by default.
-  KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
-endif
-endif
-endif
-# Find arch-specific stack protector compiler sanity-checking script.
-ifdef stackp-name
-ifneq ($(stackp-flag),)
-  stackp-path := 
$(srctree)/scripts/gcc-$(SRCARCH)_$(BITS)-has-stack-protector.sh
-  stackp-check := $(wildcard $(stackp-path))
-  # If the wildcard test matches a test script, run it to check functionality.
-  ifdef stackp-check
-ifneq ($(shell $(CONFIG_SHELL) $(stackp-check) $(CC) $(KBUILD_CPPFLAGS) 
$(biarch)),y)
-  stackp-broken := y
-endif
-  endif
-  ifndef stackp-broken
-# If the stack protector is functional, enable code that depends on it.
-KBUILD_CPPFLAGS += -DCONFIG_CC_STACKPROTECTOR
-# Either we've already detected the flag (for AUTO) or we'll fail the
-# build in the prepare-compiler-check rule (for specific flag).
-KBUILD_CFLAGS += $(stackp-flag)
-  else
-# We have to make sure stack protector is unconditionally disabled if
-# the compiler is broken (in case we're going to continue the build in
-# AUTO mode).
-KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
-  endif
-endif
-endif
+stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR)  := -fstack-protector
+stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG)   := -fstack-protector-strong
+
+KBUILD_CFLAGS += $(stackp-flags-y)
 
 ifeq ($(cc-name),clang)
 KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
@@ -1096,7 +1052,7 @@ endif
 # prepare2 creates a makefile if using a separate output directory.
 # From this point forward, .config has been reprocessed, so any rules
 # that need to depend on updated CONFIG_* values can be checked here.
-prepare2: prepare3 prepare-compiler-check outputmakefile asm-generic
+prepare2: prepare3 outputmakefile asm-generic
 
 prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \
include/config/auto.conf
@@ -1122,43 +1078,6 @@ uapi-asm-generic:
 PHONY += prepare-objtool
 prepare-objtool: $(objtool_target)
 
-# Check for CONFIG flags that require compiler support. Abort the build
-# after .config has been processed, but before the kernel build starts.
-#
-# For security-sensitive CONFIG options, we don't want to fallback and/or
-# silently change which compiler flags will be used, since that leads to
-# producing kernels with different security feature characteristics
-# depending on the compiler used. (For example, "But I selected
-# CC_STACKPROTECTOR_STRONG! Why did it build with _REGULAR?!")
-PHONY += prepare-compiler-check
-prepare-compiler-check: FORCE

[PATCH 01/30] gcc-plugins: fix build condition of SANCOV plugin

2018-04-12 Thread Masahiro Yamada
Since commit d677a4d60193 ("Makefile: support flag
-fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV
plugin under some circumstances.

  CONFIG_KCOV=y
  CONFIG_KCOV_ENABLE_COMPARISONS=y
  Your compiler does not support -fsanitize-coverage=trace-pc
  Your compiler does not support -fsanitize-coverage=trace-cmp

Under this condition, $(CFLAGS_KCOV) is not empty but contains a
space, so the following ifeq-conditional is false.

ifeq ($(CFLAGS_KCOV),)

Then, scripts/Makefile.gcc-plugins misses to add sancov_plugin.so to
gcc-plugin-y while the SANCOV plugin is necessary as an alternative
means.

Fixes: d677a4d60193 ("Makefile: support flag -fsanitizer-coverage=trace-cmp")
Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/Makefile.gcc-plugins | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index b2a95af..7f5c862 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,7 +14,7 @@ ifdef CONFIG_GCC_PLUGINS
   endif
 
   ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(CFLAGS_KCOV),)
+ifeq ($(strip $(CFLAGS_KCOV)),)
   # It is needed because of the gcc-plugin.sh and gcc version checks.
   gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
 
-- 
2.7.4



[PATCH 01/30] gcc-plugins: fix build condition of SANCOV plugin

2018-04-12 Thread Masahiro Yamada
Since commit d677a4d60193 ("Makefile: support flag
-fsanitizer-coverage=trace-cmp"), you miss to build the SANCOV
plugin under some circumstances.

  CONFIG_KCOV=y
  CONFIG_KCOV_ENABLE_COMPARISONS=y
  Your compiler does not support -fsanitize-coverage=trace-pc
  Your compiler does not support -fsanitize-coverage=trace-cmp

Under this condition, $(CFLAGS_KCOV) is not empty but contains a
space, so the following ifeq-conditional is false.

ifeq ($(CFLAGS_KCOV),)

Then, scripts/Makefile.gcc-plugins misses to add sancov_plugin.so to
gcc-plugin-y while the SANCOV plugin is necessary as an alternative
means.

Fixes: d677a4d60193 ("Makefile: support flag -fsanitizer-coverage=trace-cmp")
Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/Makefile.gcc-plugins | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index b2a95af..7f5c862 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,7 +14,7 @@ ifdef CONFIG_GCC_PLUGINS
   endif
 
   ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(CFLAGS_KCOV),)
+ifeq ($(strip $(CFLAGS_KCOV)),)
   # It is needed because of the gcc-plugin.sh and gcc version checks.
   gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
 
-- 
2.7.4



[PATCH 02/30] kbuild: remove kbuild cache

2018-04-12 Thread Masahiro Yamada
The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).

However, this turned out not so clever as I had first expected.
Actually, it is problematic.  For example, "$(CC) -print-file-name"
is cached.  If the compiler is updated, the stale search path causes
build error, which is difficult to figure out.  Another problem
scenario is cache files could be touched while install targets are
running under the root permission.  We can patch them if desired,
but the build infrastructure is getting uglier and uglier.

Now, we are going to move compiler flag tests to the configuration
phase.  If this is completed, the result of compiler tests will be
naturally cached in the .config file.  We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.

To start this work with a cleaner code base, remove the kbuild
cache first.

Revert the following commits:
Commit 9a234a2e3843 ("kbuild: create directory for make cache only when 
necessary")
Commit e17c400ae194 ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e56207130ed ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690b21c ("kbuild: Add a cache for generated variables")

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 Makefile   |   5 +--
 scripts/Kbuild.include | 101 +++--
 2 files changed, 16 insertions(+), 90 deletions(-)

diff --git a/Makefile b/Makefile
index c1a608a..d85cee0 100644
--- a/Makefile
+++ b/Makefile
@@ -501,7 +501,7 @@ RETPOLINE_CFLAGS := $(call 
cc-option,$(RETPOLINE_CFLAGS_GCC),$(call cc-option,$(
 export RETPOLINE_CFLAGS
 
 # check for 'asm goto'
-ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) 
$(KBUILD_CFLAGS)), y)
+ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) 
$(KBUILD_CFLAGS)), y)
   CC_HAVE_ASM_GOTO := 1
   KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
   KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
@@ -804,7 +804,7 @@ KBUILD_CFLAGS   += $(call cc-option,-fdata-sections,)
 endif
 
 # arch Makefile may override CC so keep this after arch Makefile is included
-NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC) 
-print-file-name=include)
+NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS += $(NOSTDINC_FLAGS)
 
 # warn about C99 declaration after statement
@@ -1617,7 +1617,6 @@ clean: $(clean-dirs)
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.symtypes' -o -name 'modules.order' \
-o -name modules.builtin -o -name '.tmp_*.o.*' \
-   -o -name .cache.mk \
-o -name '*.c.[012]*.*' \
-o -name '*.ll' \
-o -name '*.gcno' \) -type f -print | xargs rm -f
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index cce31ee..9f7eb10 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -8,8 +8,6 @@ squote  := '
 empty   :=
 space   := $(empty) $(empty)
 space_escape := _-_SPACE_-_
-right_paren := )
-left_paren := (
 
 ###
 # Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
@@ -82,71 +80,6 @@ cc-cross-prefix =  \
echo $(c);\
fi)))
 
-# Tools for caching Makefile variables that are "expensive" to compute.
-#
-# Here we want to help deal with variables that take a long time to compute
-# by making it easy to store these variables in a cache.
-#
-# The canonical example here is testing for compiler flags.  On a simple system
-# each call to the compiler takes 10 ms, but on a system with a compiler that's
-# called through various wrappers it can take upwards of 100 ms.  If we have
-# 100 calls to the compiler this can take 1 second (on a simple system) or 10
-# seconds (on a complicated system).
-#
-# The "cache" will be in Makefile syntax and can be directly included.
-# Any time we try to reference a variable that's not in the cache we'll
-# calculate it and store it in the cache for next time.
-
-# Include values from last time
-make-cache := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/,$(if 
$(obj),$(obj)/)).cache.mk
-$(make-cache): ;
--include $(make-cache)
-
-cached-data := $(filter __cached_%, $(.VARIABLES))
-
-# If cache exceeds 1000 lines, shrink it down to 500.
-ifneq ($(word 1000,$(cached-data)),)
-$(shell tail -n 500 $(make-cache) > $(make-cache).tmp; \
-   mv $(make-cache).tmp $(make-cache))
-endif
-
-create-cache-dir := $(if $(KBUILD_SRC),$(if $(cache-data),,1))
-
-# Usage: $(call __sanitize-opt,Hello=Hola$(comma)Goodbye Adios)
-#
-# Convert all '$', ')', '(', '\', '=', ' ', ',', ':' to '_'
-__sanitize-opt = $(subst $$,_,$(subst $(right_paren),_,$(subst 
$(left_paren),_,$(subst \,_,$(subst 

[PATCH 02/30] kbuild: remove kbuild cache

2018-04-12 Thread Masahiro Yamada
The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).

However, this turned out not so clever as I had first expected.
Actually, it is problematic.  For example, "$(CC) -print-file-name"
is cached.  If the compiler is updated, the stale search path causes
build error, which is difficult to figure out.  Another problem
scenario is cache files could be touched while install targets are
running under the root permission.  We can patch them if desired,
but the build infrastructure is getting uglier and uglier.

Now, we are going to move compiler flag tests to the configuration
phase.  If this is completed, the result of compiler tests will be
naturally cached in the .config file.  We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.

To start this work with a cleaner code base, remove the kbuild
cache first.

Revert the following commits:
Commit 9a234a2e3843 ("kbuild: create directory for make cache only when 
necessary")
Commit e17c400ae194 ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e56207130ed ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690b21c ("kbuild: Add a cache for generated variables")

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 Makefile   |   5 +--
 scripts/Kbuild.include | 101 +++--
 2 files changed, 16 insertions(+), 90 deletions(-)

diff --git a/Makefile b/Makefile
index c1a608a..d85cee0 100644
--- a/Makefile
+++ b/Makefile
@@ -501,7 +501,7 @@ RETPOLINE_CFLAGS := $(call 
cc-option,$(RETPOLINE_CFLAGS_GCC),$(call cc-option,$(
 export RETPOLINE_CFLAGS
 
 # check for 'asm goto'
-ifeq ($(call shell-cached,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) 
$(KBUILD_CFLAGS)), y)
+ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC) 
$(KBUILD_CFLAGS)), y)
   CC_HAVE_ASM_GOTO := 1
   KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
   KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
@@ -804,7 +804,7 @@ KBUILD_CFLAGS   += $(call cc-option,-fdata-sections,)
 endif
 
 # arch Makefile may override CC so keep this after arch Makefile is included
-NOSTDINC_FLAGS += -nostdinc -isystem $(call shell-cached,$(CC) 
-print-file-name=include)
+NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 CHECKFLAGS += $(NOSTDINC_FLAGS)
 
 # warn about C99 declaration after statement
@@ -1617,7 +1617,6 @@ clean: $(clean-dirs)
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.symtypes' -o -name 'modules.order' \
-o -name modules.builtin -o -name '.tmp_*.o.*' \
-   -o -name .cache.mk \
-o -name '*.c.[012]*.*' \
-o -name '*.ll' \
-o -name '*.gcno' \) -type f -print | xargs rm -f
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index cce31ee..9f7eb10 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -8,8 +8,6 @@ squote  := '
 empty   :=
 space   := $(empty) $(empty)
 space_escape := _-_SPACE_-_
-right_paren := )
-left_paren := (
 
 ###
 # Name of target with a '.' as filename prefix. foo/bar.o => foo/.bar.o
@@ -82,71 +80,6 @@ cc-cross-prefix =  \
echo $(c);\
fi)))
 
-# Tools for caching Makefile variables that are "expensive" to compute.
-#
-# Here we want to help deal with variables that take a long time to compute
-# by making it easy to store these variables in a cache.
-#
-# The canonical example here is testing for compiler flags.  On a simple system
-# each call to the compiler takes 10 ms, but on a system with a compiler that's
-# called through various wrappers it can take upwards of 100 ms.  If we have
-# 100 calls to the compiler this can take 1 second (on a simple system) or 10
-# seconds (on a complicated system).
-#
-# The "cache" will be in Makefile syntax and can be directly included.
-# Any time we try to reference a variable that's not in the cache we'll
-# calculate it and store it in the cache for next time.
-
-# Include values from last time
-make-cache := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/,$(if 
$(obj),$(obj)/)).cache.mk
-$(make-cache): ;
--include $(make-cache)
-
-cached-data := $(filter __cached_%, $(.VARIABLES))
-
-# If cache exceeds 1000 lines, shrink it down to 500.
-ifneq ($(word 1000,$(cached-data)),)
-$(shell tail -n 500 $(make-cache) > $(make-cache).tmp; \
-   mv $(make-cache).tmp $(make-cache))
-endif
-
-create-cache-dir := $(if $(KBUILD_SRC),$(if $(cache-data),,1))
-
-# Usage: $(call __sanitize-opt,Hello=Hola$(comma)Goodbye Adios)
-#
-# Convert all '$', ')', '(', '\', '=', ' ', ',', ':' to '_'
-__sanitize-opt = $(subst $$,_,$(subst $(right_paren),_,$(subst 
$(left_paren),_,$(subst \,_,$(subst =,_,$(subst $(space),_,$(subst 
$(comma),_,$(subst 

[PATCH 12/30] kconfig: support variable and user-defined function

2018-04-12 Thread Masahiro Yamada
Now, we got a basic ability to test compiler capability in Kconfig.

config CC_HAS_STACKPROTECTOR
def_bool $(shell (($(CC) -Werror -fstack-protector -c -x c /dev/null -o 
/dev/null 2>/dev/null) && echo y) || echo n)

This works, but it is ugly to repeat this long boilerplate.

We want to describe like this:

config CC_HAS_STACKPROTECTOR
bool
default $(cc-option -fstack-protector)

It is straight-forward to add a new function, but I do not like to
hard-code specialized functions like this.  Hence, here is another
feature, user-defined function.  This works as a textual shorthand
with parameterization.

A user-defined function is defined by using the = operator, and can
be referenced in the same way as built-in functions.  A user-defined
function in Make is referenced like $(call func-name, arg1, arg2),
but I omitted the 'call' to make the syntax shorter.

The definition of a user-defined function contains $(1), $(2), etc.
in its body to reference the parameters.  It is grammatically valid
to pass more or fewer arguments when calling it.  We already exploit
this feature in our makefiles; scripts/Kbuild.include defines cc-option
which takes two arguments at most, but most of the callers pass only
one argument.

By the way, a variable is supported at a subset of this feature since
a variable is "a user-defined function with zero argument".  In this
context, I mean "variable" as recursively expanded variable.  I will
add a different flavored variable later on.

The code above can be written as follows:

[Example Code]

  success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)
  cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)

  config CC_HAS_STACKPROTECTOR
  def_bool $(cc-option -fstack-protector)

[Result]
  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_CC_HAS_STACKPROTECTOR=y

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Re-implement the parse logic
  - Use = operator to define a user-defined function

Changes in v2:
  - Use 'macro' directly instead of inside the string type symbol.

 scripts/kconfig/lkc_proto.h  |  2 +
 scripts/kconfig/preprocess.c | 96 +++-
 scripts/kconfig/zconf.l  | 17 +++-
 scripts/kconfig/zconf.y  | 21 +-
 4 files changed, 132 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index c46929f..2b16d6e 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -50,6 +50,8 @@ const char * prop_get_type_name(enum prop_type type);
 
 /* preprocess.c */
 void env_write_dep(FILE *f, const char *auto_conf_name);
+void variable_add(const char *name, const char *value);
+void variable_all_del(void);
 char *expand_string(const char *in);
 char *expand_dollar(const char **str);
 char *expand_one_token(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index f4c606f..1b746e0 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -79,6 +79,72 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
 }
 
 /*
+ * Variables and User-defined Functions
+ */
+static LIST_HEAD(variable_list);
+
+struct variable {
+   char *name;
+   char *value;
+   struct list_head node;
+};
+
+static struct variable *variable_lookup(const char *name)
+{
+   struct variable *v;
+
+   list_for_each_entry(v, _list, node) {
+   if (!strcmp(name, v->name))
+   return v;
+   }
+
+   return NULL;
+}
+
+static char *variable_expand(const char *name, int argc, char *argv[])
+{
+   struct variable *v;
+
+   v = variable_lookup(name);
+   if (!v)
+   return NULL;
+
+   return expand_string_with_args(v->value, argc, argv);
+}
+
+void variable_add(const char *name, const char *value)
+{
+   struct variable *v;
+
+   v = variable_lookup(name);
+   if (v) {
+   free(v->value);
+   } else {
+   v = xmalloc(sizeof(*v));
+   v->name = xstrdup(name);
+   list_add_tail(>node, _list);
+   }
+
+   v->value = xstrdup(value);
+}
+
+static void variable_del(struct variable *v)
+{
+   list_del(>node);
+   free(v->name);
+   free(v->value);
+   free(v);
+}
+
+void variable_all_del(void)
+{
+   struct variable *v, *tmp;
+
+   list_for_each_entry_safe(v, tmp, _list, node)
+   variable_del(v);
+}
+
+/*
  * Built-in Functions
  */
 struct function {
@@ -175,16 +241,30 @@ static char *function_call(const char *name, int argc, 
char *argv[])
  * Evaluate a clause with arguments.  argc/argv are arguments from the upper
  * function call.
  *
+ * Let's say 'foo' is defined as:
+ *   foo = ABC$(1)PQR(2)XYZ
+ * and you want to evaluate $(foo x,y)
+ *
+ * First, this helper is called with:
+ *   in  :foo x,y
+ *   argc:0
+ * and then, recursively called 

[PATCH 05/30] kconfig: remove string expansion in file_lookup()

2018-04-12 Thread Masahiro Yamada
There are two callers of file_lookup(), but there is no more reason
to expand the given path.

[1] zconf_initscan()
This is used to open the first Kconfig.  sym_expand_string_value()
has never been used in a useful way here; before opening the first
Kconfig file, obviously there is no symbol to expand.  If you use
expand_string_value() instead, environments in KBUILD_KCONFIG would
be expanded, but I do not see practical benefits for that.

[2] zconf_nextfile()
This is used to open the next file from 'source' statement.
Symbols in the path like "arch/$SRCARCH/Kconfig" needed expanding,
but it was replaced with the direct environment expansion.  The
environment has already been expanded before the token is passed
to the parser.

By the way, file_lookup() was already buggy; it expanded a given path,
but it used the path before expansion for look-up:
if (!strcmp(name, file->name)) {

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3: None
Changes in v2:
  - Simplify the patch.  Just remove text expansion.

 scripts/kconfig/util.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/kconfig/util.c b/scripts/kconfig/util.c
index 807147e..790967df 100644
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -14,18 +14,16 @@
 struct file *file_lookup(const char *name)
 {
struct file *file;
-   char *file_name = sym_expand_string_value(name);
 
for (file = file_list; file; file = file->next) {
if (!strcmp(name, file->name)) {
-   free(file_name);
return file;
}
}
 
file = xmalloc(sizeof(*file));
memset(file, 0, sizeof(*file));
-   file->name = file_name;
+   file->name = xstrdup(name);
file->next = file_list;
file_list = file;
return file;
-- 
2.7.4



[PATCH 12/30] kconfig: support variable and user-defined function

2018-04-12 Thread Masahiro Yamada
Now, we got a basic ability to test compiler capability in Kconfig.

config CC_HAS_STACKPROTECTOR
def_bool $(shell (($(CC) -Werror -fstack-protector -c -x c /dev/null -o 
/dev/null 2>/dev/null) && echo y) || echo n)

This works, but it is ugly to repeat this long boilerplate.

We want to describe like this:

config CC_HAS_STACKPROTECTOR
bool
default $(cc-option -fstack-protector)

It is straight-forward to add a new function, but I do not like to
hard-code specialized functions like this.  Hence, here is another
feature, user-defined function.  This works as a textual shorthand
with parameterization.

A user-defined function is defined by using the = operator, and can
be referenced in the same way as built-in functions.  A user-defined
function in Make is referenced like $(call func-name, arg1, arg2),
but I omitted the 'call' to make the syntax shorter.

The definition of a user-defined function contains $(1), $(2), etc.
in its body to reference the parameters.  It is grammatically valid
to pass more or fewer arguments when calling it.  We already exploit
this feature in our makefiles; scripts/Kbuild.include defines cc-option
which takes two arguments at most, but most of the callers pass only
one argument.

By the way, a variable is supported at a subset of this feature since
a variable is "a user-defined function with zero argument".  In this
context, I mean "variable" as recursively expanded variable.  I will
add a different flavored variable later on.

The code above can be written as follows:

[Example Code]

  success = $(shell ($(1)) >/dev/null 2>&1 && echo y || echo n)
  cc-option = $(success $(CC) -Werror $(1) -c -x c /dev/null -o /dev/null)

  config CC_HAS_STACKPROTECTOR
  def_bool $(cc-option -fstack-protector)

[Result]
  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_CC_HAS_STACKPROTECTOR=y

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Re-implement the parse logic
  - Use = operator to define a user-defined function

Changes in v2:
  - Use 'macro' directly instead of inside the string type symbol.

 scripts/kconfig/lkc_proto.h  |  2 +
 scripts/kconfig/preprocess.c | 96 +++-
 scripts/kconfig/zconf.l  | 17 +++-
 scripts/kconfig/zconf.y  | 21 +-
 4 files changed, 132 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index c46929f..2b16d6e 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -50,6 +50,8 @@ const char * prop_get_type_name(enum prop_type type);
 
 /* preprocess.c */
 void env_write_dep(FILE *f, const char *auto_conf_name);
+void variable_add(const char *name, const char *value);
+void variable_all_del(void);
 char *expand_string(const char *in);
 char *expand_dollar(const char **str);
 char *expand_one_token(const char **str);
diff --git a/scripts/kconfig/preprocess.c b/scripts/kconfig/preprocess.c
index f4c606f..1b746e0 100644
--- a/scripts/kconfig/preprocess.c
+++ b/scripts/kconfig/preprocess.c
@@ -79,6 +79,72 @@ void env_write_dep(FILE *f, const char *autoconfig_name)
 }
 
 /*
+ * Variables and User-defined Functions
+ */
+static LIST_HEAD(variable_list);
+
+struct variable {
+   char *name;
+   char *value;
+   struct list_head node;
+};
+
+static struct variable *variable_lookup(const char *name)
+{
+   struct variable *v;
+
+   list_for_each_entry(v, _list, node) {
+   if (!strcmp(name, v->name))
+   return v;
+   }
+
+   return NULL;
+}
+
+static char *variable_expand(const char *name, int argc, char *argv[])
+{
+   struct variable *v;
+
+   v = variable_lookup(name);
+   if (!v)
+   return NULL;
+
+   return expand_string_with_args(v->value, argc, argv);
+}
+
+void variable_add(const char *name, const char *value)
+{
+   struct variable *v;
+
+   v = variable_lookup(name);
+   if (v) {
+   free(v->value);
+   } else {
+   v = xmalloc(sizeof(*v));
+   v->name = xstrdup(name);
+   list_add_tail(>node, _list);
+   }
+
+   v->value = xstrdup(value);
+}
+
+static void variable_del(struct variable *v)
+{
+   list_del(>node);
+   free(v->name);
+   free(v->value);
+   free(v);
+}
+
+void variable_all_del(void)
+{
+   struct variable *v, *tmp;
+
+   list_for_each_entry_safe(v, tmp, _list, node)
+   variable_del(v);
+}
+
+/*
  * Built-in Functions
  */
 struct function {
@@ -175,16 +241,30 @@ static char *function_call(const char *name, int argc, 
char *argv[])
  * Evaluate a clause with arguments.  argc/argv are arguments from the upper
  * function call.
  *
+ * Let's say 'foo' is defined as:
+ *   foo = ABC$(1)PQR(2)XYZ
+ * and you want to evaluate $(foo x,y)
+ *
+ * First, this helper is called with:
+ *   in  :foo x,y
+ *   argc:0
+ * and then, recursively called with:
+ *   in:  

[PATCH 05/30] kconfig: remove string expansion in file_lookup()

2018-04-12 Thread Masahiro Yamada
There are two callers of file_lookup(), but there is no more reason
to expand the given path.

[1] zconf_initscan()
This is used to open the first Kconfig.  sym_expand_string_value()
has never been used in a useful way here; before opening the first
Kconfig file, obviously there is no symbol to expand.  If you use
expand_string_value() instead, environments in KBUILD_KCONFIG would
be expanded, but I do not see practical benefits for that.

[2] zconf_nextfile()
This is used to open the next file from 'source' statement.
Symbols in the path like "arch/$SRCARCH/Kconfig" needed expanding,
but it was replaced with the direct environment expansion.  The
environment has already been expanded before the token is passed
to the parser.

By the way, file_lookup() was already buggy; it expanded a given path,
but it used the path before expansion for look-up:
if (!strcmp(name, file->name)) {

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3: None
Changes in v2:
  - Simplify the patch.  Just remove text expansion.

 scripts/kconfig/util.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/kconfig/util.c b/scripts/kconfig/util.c
index 807147e..790967df 100644
--- a/scripts/kconfig/util.c
+++ b/scripts/kconfig/util.c
@@ -14,18 +14,16 @@
 struct file *file_lookup(const char *name)
 {
struct file *file;
-   char *file_name = sym_expand_string_value(name);
 
for (file = file_list; file; file = file->next) {
if (!strcmp(name, file->name)) {
-   free(file_name);
return file;
}
}
 
file = xmalloc(sizeof(*file));
memset(file, 0, sizeof(*file));
-   file->name = file_name;
+   file->name = xstrdup(name);
file->next = file_list;
file_list = file;
return file;
-- 
2.7.4



[PATCH 07/30] kconfig: remove sym_expand_string_value()

2018-04-12 Thread Masahiro Yamada
There is no more caller of sym_expand_string_value().

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/kconfig/lkc_proto.h |  1 -
 scripts/kconfig/symbol.c| 53 -
 2 files changed, 54 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 9f465fe..c46929f 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -31,7 +31,6 @@ extern struct symbol * symbol_hash[SYMBOL_HASHSIZE];
 
 struct symbol * sym_lookup(const char *name, int flags);
 struct symbol * sym_find(const char *name);
-char *sym_expand_string_value(const char *in);
 const char * sym_escape_string_value(const char *in);
 struct symbol ** sym_re_search(const char *pattern);
 const char * sym_type_name(enum symbol_type type);
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 2460648..7c9a88e 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -879,59 +879,6 @@ struct symbol *sym_find(const char *name)
return symbol;
 }
 
-/*
- * Expand symbol's names embedded in the string given in argument. Symbols'
- * name to be expanded shall be prefixed by a '$'. Unknown symbol expands to
- * the empty string.
- */
-char *sym_expand_string_value(const char *in)
-{
-   const char *src;
-   char *res;
-   size_t reslen;
-
-   /*
-* Note: 'in' might come from a token that's about to be
-* freed, so make sure to always allocate a new string
-*/
-   reslen = strlen(in) + 1;
-   res = xmalloc(reslen);
-   res[0] = '\0';
-
-   while ((src = strchr(in, '$'))) {
-   char *p, name[SYMBOL_MAXLENGTH];
-   const char *symval = "";
-   struct symbol *sym;
-   size_t newlen;
-
-   strncat(res, in, src - in);
-   src++;
-
-   p = name;
-   while (isalnum(*src) || *src == '_')
-   *p++ = *src++;
-   *p = '\0';
-
-   sym = sym_find(name);
-   if (sym != NULL) {
-   sym_calc_value(sym);
-   symval = sym_get_string_value(sym);
-   }
-
-   newlen = strlen(res) + strlen(symval) + strlen(src) + 1;
-   if (newlen > reslen) {
-   reslen = newlen;
-   res = xrealloc(res, reslen);
-   }
-
-   strcat(res, symval);
-   in = src;
-   }
-   strcat(res, in);
-
-   return res;
-}
-
 const char *sym_escape_string_value(const char *in)
 {
const char *p;
-- 
2.7.4



[PATCH 07/30] kconfig: remove sym_expand_string_value()

2018-04-12 Thread Masahiro Yamada
There is no more caller of sym_expand_string_value().

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - newly added

Changes in v2: None

 scripts/kconfig/lkc_proto.h |  1 -
 scripts/kconfig/symbol.c| 53 -
 2 files changed, 54 deletions(-)

diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 9f465fe..c46929f 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -31,7 +31,6 @@ extern struct symbol * symbol_hash[SYMBOL_HASHSIZE];
 
 struct symbol * sym_lookup(const char *name, int flags);
 struct symbol * sym_find(const char *name);
-char *sym_expand_string_value(const char *in);
 const char * sym_escape_string_value(const char *in);
 struct symbol ** sym_re_search(const char *pattern);
 const char * sym_type_name(enum symbol_type type);
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 2460648..7c9a88e 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -879,59 +879,6 @@ struct symbol *sym_find(const char *name)
return symbol;
 }
 
-/*
- * Expand symbol's names embedded in the string given in argument. Symbols'
- * name to be expanded shall be prefixed by a '$'. Unknown symbol expands to
- * the empty string.
- */
-char *sym_expand_string_value(const char *in)
-{
-   const char *src;
-   char *res;
-   size_t reslen;
-
-   /*
-* Note: 'in' might come from a token that's about to be
-* freed, so make sure to always allocate a new string
-*/
-   reslen = strlen(in) + 1;
-   res = xmalloc(reslen);
-   res[0] = '\0';
-
-   while ((src = strchr(in, '$'))) {
-   char *p, name[SYMBOL_MAXLENGTH];
-   const char *symval = "";
-   struct symbol *sym;
-   size_t newlen;
-
-   strncat(res, in, src - in);
-   src++;
-
-   p = name;
-   while (isalnum(*src) || *src == '_')
-   *p++ = *src++;
-   *p = '\0';
-
-   sym = sym_find(name);
-   if (sym != NULL) {
-   sym_calc_value(sym);
-   symval = sym_get_string_value(sym);
-   }
-
-   newlen = strlen(res) + strlen(symval) + strlen(src) + 1;
-   if (newlen > reslen) {
-   reslen = newlen;
-   res = xrealloc(res, reslen);
-   }
-
-   strcat(res, symval);
-   in = src;
-   }
-   strcat(res, in);
-
-   return res;
-}
-
 const char *sym_escape_string_value(const char *in)
 {
const char *p;
-- 
2.7.4



Re: KMSAN: uninit-value in __netif_receive_skb_core

2018-04-12 Thread syzbot
syzbot has found reproducer for the following crash on  
https://github.com/google/kmsan.git/master commit

35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa


So far this crash happened 3 times on  
https://github.com/google/kmsan.git/master.

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=455991623680
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=4590273065648128
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=4631921027973120
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b202b720866414295...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

==
BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197  
[inline]
BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908  
[inline]
BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80  
net/core/dev.c:4545

CPU: 0 PID: 3514 Comm: syzkaller031167 Not tainted 4.16.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
 __read_once_size include/linux/compiler.h:197 [inline]
 deliver_ptype_list_skb net/core/dev.c:1908 [inline]
 __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545
 __netif_receive_skb net/core/dev.c:4627 [inline]
 process_backlog+0x62d/0xe20 net/core/dev.c:5307
 napi_poll net/core/dev.c:5705 [inline]
 net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
 __do_softirq+0x56d/0x93d kernel/softirq.c:285
 do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
 
 do_softirq kernel/softirq.c:329 [inline]
 __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
 local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
 rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
 __dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584
 dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
 packet_snd net/packet/af_packet.c:2944 [inline]
 packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
 sock_sendmsg_nosec net/socket.c:630 [inline]
 sock_sendmsg net/socket.c:640 [inline]
 sock_write_iter+0x3b9/0x470 net/socket.c:909
 do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
 do_iter_write+0x30d/0xd40 fs/read_write.c:932
 vfs_writev fs/read_write.c:977 [inline]
 do_writev+0x3c9/0x830 fs/read_write.c:1012
 SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
 SyS_writev+0x56/0x80 fs/read_write.c:1082
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43ffb9
RSP: 002b:7ffd42187708 EFLAGS: 0217 ORIG_RAX: 0014
RAX: ffda RBX: 004002c8 RCX: 0043ffb9
RDX: 0001 RSI: 200010c0 RDI: 0003
RBP: 006ca018 R08: 004002c8 R09: 004002c8
R10: 004002c8 R11: 0217 R12: 004018e0
R13: 00401970 R14:  R15: 

Uninit was stored to memory at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
 kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
 __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
 skb_vlan_untag+0x950/0xee0 include/linux/if_vlan.h:597
 __netif_receive_skb_core+0x70a/0x4a80 net/core/dev.c:4460
 __netif_receive_skb net/core/dev.c:4627 [inline]
 process_backlog+0x62d/0xe20 net/core/dev.c:5307
 napi_poll net/core/dev.c:5705 [inline]
 net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
 __do_softirq+0x56d/0x93d kernel/softirq.c:285
Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
 slab_post_alloc_hook mm/slab.h:445 [inline]
 slab_alloc_node mm/slub.c:2737 [inline]
 __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
 __kmalloc_reserve net/core/skbuff.c:138 [inline]
 __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
 alloc_skb include/linux/skbuff.h:984 [inline]
 alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
 packet_alloc_skb net/packet/af_packet.c:2803 [inline]
 packet_snd net/packet/af_packet.c:2894 [inline]
 packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
 sock_sendmsg_nosec net/socket.c:630 [inline]
 sock_sendmsg net/socket.c:640 [inline]
 sock_write_iter+0x3b9/0x470 

[PATCH 06/30] kconfig: remove string expansion for mainmenu after yyparse()

2018-04-12 Thread Masahiro Yamada
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.

The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3: None
Changes in v2:
  - Simplify the patch.  Just remove the text expansion.

 scripts/kconfig/zconf.y | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 3a4a0fa..22e318c 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -109,7 +109,7 @@ static struct menu *current_menu, *current_entry;
 %%
 input: nl start | start;
 
-start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+start: mainmenu_stmt stmt_list | stmt_list;
 
 /* mainmenu entry */
 
@@ -118,19 +118,6 @@ mainmenu_stmt: T_MAINMENU prompt nl
menu_add_prompt(P_MENU, $2, NULL);
 };
 
-/* Default main menu, if there's no mainmenu entry */
-
-no_mainmenu_stmt: /* empty */
-{
-   /*
-* Hack: Keep the main menu title on the heap so we can safely free it
-* later regardless of whether it comes from the 'prompt' in
-* mainmenu_stmt or here
-*/
-   menu_add_prompt(P_MENU, xstrdup("Linux Kernel Configuration"), NULL);
-};
-
-
 stmt_list:
  /* empty */
| stmt_list common_stmt
@@ -528,7 +515,6 @@ word_opt: /* empty */   { $$ = NULL; }
 
 void conf_parse(const char *name)
 {
-   const char *tmp;
struct symbol *sym;
int i;
 
@@ -544,10 +530,10 @@ void conf_parse(const char *name)
if (!modules_sym)
modules_sym = sym_find( "n" );
 
-   tmp = rootmenu.prompt->text;
-   rootmenu.prompt->text = _(rootmenu.prompt->text);
-   rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
-   free((char*)tmp);
+   if (!menu_has_prompt()) {
+   current_entry = 
+   menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
+   }
 
menu_finalize();
for_all_symbols(i, sym) {
-- 
2.7.4



Re: KMSAN: uninit-value in __netif_receive_skb_core

2018-04-12 Thread syzbot
syzbot has found reproducer for the following crash on  
https://github.com/google/kmsan.git/master commit

35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=b202b7208664142954fa


So far this crash happened 3 times on  
https://github.com/google/kmsan.git/master.

C reproducer: https://syzkaller.appspot.com/x/repro.c?id=455991623680
syzkaller reproducer:  
https://syzkaller.appspot.com/x/repro.syz?id=4590273065648128
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=4631921027973120
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=6627248707860932248

compiler: clang version 7.0.0 (trunk 329391)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b202b720866414295...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

==
BUG: KMSAN: uninit-value in __read_once_size include/linux/compiler.h:197  
[inline]
BUG: KMSAN: uninit-value in deliver_ptype_list_skb net/core/dev.c:1908  
[inline]
BUG: KMSAN: uninit-value in __netif_receive_skb_core+0x4630/0x4a80  
net/core/dev.c:4545

CPU: 0 PID: 3514 Comm: syzkaller031167 Not tainted 4.16.0+ #83
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:17 [inline]
 dump_stack+0x185/0x1d0 lib/dump_stack.c:53
 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:676
 __read_once_size include/linux/compiler.h:197 [inline]
 deliver_ptype_list_skb net/core/dev.c:1908 [inline]
 __netif_receive_skb_core+0x4630/0x4a80 net/core/dev.c:4545
 __netif_receive_skb net/core/dev.c:4627 [inline]
 process_backlog+0x62d/0xe20 net/core/dev.c:5307
 napi_poll net/core/dev.c:5705 [inline]
 net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
 __do_softirq+0x56d/0x93d kernel/softirq.c:285
 do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1040
 
 do_softirq kernel/softirq.c:329 [inline]
 __local_bh_enable_ip+0x114/0x140 kernel/softirq.c:182
 local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32
 rcu_read_unlock_bh include/linux/rcupdate.h:726 [inline]
 __dev_queue_xmit+0x2a31/0x2b60 net/core/dev.c:3584
 dev_queue_xmit+0x4b/0x60 net/core/dev.c:3590
 packet_snd net/packet/af_packet.c:2944 [inline]
 packet_sendmsg+0x7c57/0x8a10 net/packet/af_packet.c:2969
 sock_sendmsg_nosec net/socket.c:630 [inline]
 sock_sendmsg net/socket.c:640 [inline]
 sock_write_iter+0x3b9/0x470 net/socket.c:909
 do_iter_readv_writev+0x7bb/0x970 include/linux/fs.h:1776
 do_iter_write+0x30d/0xd40 fs/read_write.c:932
 vfs_writev fs/read_write.c:977 [inline]
 do_writev+0x3c9/0x830 fs/read_write.c:1012
 SYSC_writev+0x9b/0xb0 fs/read_write.c:1085
 SyS_writev+0x56/0x80 fs/read_write.c:1082
 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x43ffb9
RSP: 002b:7ffd42187708 EFLAGS: 0217 ORIG_RAX: 0014
RAX: ffda RBX: 004002c8 RCX: 0043ffb9
RDX: 0001 RSI: 200010c0 RDI: 0003
RBP: 006ca018 R08: 004002c8 R09: 004002c8
R10: 004002c8 R11: 0217 R12: 004018e0
R13: 00401970 R14:  R15: 

Uninit was stored to memory at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_save_stack mm/kmsan/kmsan.c:293 [inline]
 kmsan_internal_chain_origin+0x12b/0x210 mm/kmsan/kmsan.c:684
 __msan_chain_origin+0x69/0xc0 mm/kmsan/kmsan_instr.c:521
 skb_vlan_untag+0x950/0xee0 include/linux/if_vlan.h:597
 __netif_receive_skb_core+0x70a/0x4a80 net/core/dev.c:4460
 __netif_receive_skb net/core/dev.c:4627 [inline]
 process_backlog+0x62d/0xe20 net/core/dev.c:5307
 napi_poll net/core/dev.c:5705 [inline]
 net_rx_action+0x7c1/0x1a70 net/core/dev.c:5771
 __do_softirq+0x56d/0x93d kernel/softirq.c:285
Uninit was created at:
 kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline]
 kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188
 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314
 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321
 slab_post_alloc_hook mm/slab.h:445 [inline]
 slab_alloc_node mm/slub.c:2737 [inline]
 __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369
 __kmalloc_reserve net/core/skbuff.c:138 [inline]
 __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206
 alloc_skb include/linux/skbuff.h:984 [inline]
 alloc_skb_with_frags+0x1d4/0xb20 net/core/skbuff.c:5234
 sock_alloc_send_pskb+0xb56/0x1190 net/core/sock.c:2085
 packet_alloc_skb net/packet/af_packet.c:2803 [inline]
 packet_snd net/packet/af_packet.c:2894 [inline]
 packet_sendmsg+0x6444/0x8a10 net/packet/af_packet.c:2969
 sock_sendmsg_nosec net/socket.c:630 [inline]
 sock_sendmsg net/socket.c:640 [inline]
 sock_write_iter+0x3b9/0x470 

[PATCH 06/30] kconfig: remove string expansion for mainmenu after yyparse()

2018-04-12 Thread Masahiro Yamada
Now that environments are expanded in the lexer, conf_parse() does
not need to expand them explicitly.

The hack introduced by commit 0724a7c32a54 ("kconfig: Don't leak
main menus during parsing") can go away.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3: None
Changes in v2:
  - Simplify the patch.  Just remove the text expansion.

 scripts/kconfig/zconf.y | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 3a4a0fa..22e318c 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -109,7 +109,7 @@ static struct menu *current_menu, *current_entry;
 %%
 input: nl start | start;
 
-start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+start: mainmenu_stmt stmt_list | stmt_list;
 
 /* mainmenu entry */
 
@@ -118,19 +118,6 @@ mainmenu_stmt: T_MAINMENU prompt nl
menu_add_prompt(P_MENU, $2, NULL);
 };
 
-/* Default main menu, if there's no mainmenu entry */
-
-no_mainmenu_stmt: /* empty */
-{
-   /*
-* Hack: Keep the main menu title on the heap so we can safely free it
-* later regardless of whether it comes from the 'prompt' in
-* mainmenu_stmt or here
-*/
-   menu_add_prompt(P_MENU, xstrdup("Linux Kernel Configuration"), NULL);
-};
-
-
 stmt_list:
  /* empty */
| stmt_list common_stmt
@@ -528,7 +515,6 @@ word_opt: /* empty */   { $$ = NULL; }
 
 void conf_parse(const char *name)
 {
-   const char *tmp;
struct symbol *sym;
int i;
 
@@ -544,10 +530,10 @@ void conf_parse(const char *name)
if (!modules_sym)
modules_sym = sym_find( "n" );
 
-   tmp = rootmenu.prompt->text;
-   rootmenu.prompt->text = _(rootmenu.prompt->text);
-   rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
-   free((char*)tmp);
+   if (!menu_has_prompt()) {
+   current_entry = 
+   menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
+   }
 
menu_finalize();
for_all_symbols(i, sym) {
-- 
2.7.4



[PATCH 26/30] gcc-plugins: move GCC version check for PowerPC to Kconfig

2018-04-12 Thread Masahiro Yamada
For PowerPC, GCC 5.2 is the requirement for GCC plugins.  Move the
version check to Kconfig so that the GCC plugin menus will be hidden
if an older compiler is in use.

Signed-off-by: Masahiro Yamada 
Acked-by: Andrew Donnellan 
---

Changes in v3:
  - Move comment to Kconfig as well

Changes in v2: None

 arch/powerpc/Kconfig | 2 +-
 scripts/Makefile.gcc-plugins | 8 
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd..512fcc1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -195,7 +195,7 @@ config PPC
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
-   select HAVE_GCC_PLUGINS
+   select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200   # 
plugin support on gcc <= 5.1 is buggy on PPC
select HAVE_GENERIC_GUP
select HAVE_HW_BREAKPOINT   if PERF_EVENTS && (PPC_BOOK3S 
|| PPC_8xx)
select HAVE_IDE
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 0ce3802..1e92353 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -53,14 +53,6 @@ gcc-plugins-check: FORCE
 ifdef CONFIG_GCC_PLUGINS
   ifeq ($(PLUGINCC),)
 ifneq ($(GCC_PLUGINS_CFLAGS),)
-  # Various gccs between 4.5 and 5.1 have bugs on powerpc due to missing
-  # header files. gcc <= 4.6 doesn't work at all, gccs from 4.8 to 5.1 have
-  # issues with 64-bit targets.
-  ifeq ($(ARCH),powerpc)
-ifeq ($(call cc-ifversion, -le, 0501, y), y)
- @echo "Cannot use CONFIG_GCC_PLUGINS: plugin support on gcc <= 5.1 is 
buggy on powerpc, please upgrade to gcc 5.2 or newer" >&2 && exit 1
-endif
-  endif
   ifeq ($(call cc-ifversion, -ge, 0405, y), y)
$(Q)$(srctree)/scripts/gcc-plugin.sh --show-error "$(__PLUGINCC)" 
"$(HOSTCXX)" "$(CC)" || true
@echo "Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not 
support plugins, perhaps the necessary headers are missing?" >&2 && exit 1
-- 
2.7.4



[PATCH 26/30] gcc-plugins: move GCC version check for PowerPC to Kconfig

2018-04-12 Thread Masahiro Yamada
For PowerPC, GCC 5.2 is the requirement for GCC plugins.  Move the
version check to Kconfig so that the GCC plugin menus will be hidden
if an older compiler is in use.

Signed-off-by: Masahiro Yamada 
Acked-by: Andrew Donnellan 
---

Changes in v3:
  - Move comment to Kconfig as well

Changes in v2: None

 arch/powerpc/Kconfig | 2 +-
 scripts/Makefile.gcc-plugins | 8 
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 73ce5dd..512fcc1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -195,7 +195,7 @@ config PPC
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
-   select HAVE_GCC_PLUGINS
+   select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200   # 
plugin support on gcc <= 5.1 is buggy on PPC
select HAVE_GENERIC_GUP
select HAVE_HW_BREAKPOINT   if PERF_EVENTS && (PPC_BOOK3S 
|| PPC_8xx)
select HAVE_IDE
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 0ce3802..1e92353 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -53,14 +53,6 @@ gcc-plugins-check: FORCE
 ifdef CONFIG_GCC_PLUGINS
   ifeq ($(PLUGINCC),)
 ifneq ($(GCC_PLUGINS_CFLAGS),)
-  # Various gccs between 4.5 and 5.1 have bugs on powerpc due to missing
-  # header files. gcc <= 4.6 doesn't work at all, gccs from 4.8 to 5.1 have
-  # issues with 64-bit targets.
-  ifeq ($(ARCH),powerpc)
-ifeq ($(call cc-ifversion, -le, 0501, y), y)
- @echo "Cannot use CONFIG_GCC_PLUGINS: plugin support on gcc <= 5.1 is 
buggy on powerpc, please upgrade to gcc 5.2 or newer" >&2 && exit 1
-endif
-  endif
   ifeq ($(call cc-ifversion, -ge, 0405, y), y)
$(Q)$(srctree)/scripts/gcc-plugin.sh --show-error "$(__PLUGINCC)" 
"$(HOSTCXX)" "$(CC)" || true
@echo "Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not 
support plugins, perhaps the necessary headers are missing?" >&2 && exit 1
-- 
2.7.4



[PATCH 28/30] gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST

2018-04-12 Thread Masahiro Yamada
Now that the compiler's plugin support is checked in Kconfig,
all{yes,mod}config will not be bothered.

Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.

'depends on !COMPILE_TEST' for the following three are still kept:
  GCC_PLUGIN_CYC_COMPLEXITY
  GCC_PLUGIN_STRUCTLEAK_VERBOSE
  GCC_PLUGIN_RANDSTRUCT_PERFORMANCE

Kees said to do so because the first two are too noisy, and the last
one would reduce the compile test coverage.  I commented the reasons
in arch/Kconfig.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 arch/Kconfig | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 9166157..95b9b2e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -420,7 +420,6 @@ menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
depends on PLUGIN_HOSTCC != ""
-   depends on !COMPILE_TEST
help
  GCC plugins are loadable modules that provide extra features to the
  compiler. They are useful for runtime instrumentation and static 
analysis.
@@ -430,7 +429,7 @@ menuconfig GCC_PLUGINS
 config GCC_PLUGIN_CYC_COMPLEXITY
bool "Compute the cyclomatic complexity of a function" if EXPERT
depends on GCC_PLUGINS
-   depends on !COMPILE_TEST
+   depends on !COMPILE_TEST# too noisy
help
  The complexity M of a function's control flow graph is defined as:
   M = E - N + 2P
@@ -493,7 +492,7 @@ config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
 config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
-   depends on !COMPILE_TEST
+   depends on !COMPILE_TEST# too noisy
help
  This option will cause a warning to be printed each time the
  structleak plugin finds a variable it thinks needs to be
@@ -533,7 +532,7 @@ config GCC_PLUGIN_RANDSTRUCT
 config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
bool "Use cacheline-aware structure randomization"
depends on GCC_PLUGIN_RANDSTRUCT
-   depends on !COMPILE_TEST
+   depends on !COMPILE_TEST# do not reduce test coverage
help
  If you say Y here, the RANDSTRUCT randomization will make a
  best effort at restricting randomization to cacheline-sized
-- 
2.7.4



[PATCH 25/30] kcov: test compiler capability in Kconfig and correct dependency

2018-04-12 Thread Masahiro Yamada
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency.  Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS.  This could cause the unmet direct
dependency.

Now that Kconfig can test compiler capability, let's handle this in a
more sophisticated way.

There are two ways to enable KCOV; use the compiler that natively
supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
the compiler has ability to build GCC plugins.  Hence, the correct
dependency for KCOV is:

  depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS

You do not need to build the SANCOV plugin if the compiler already
supports -fsanitize-coverage=trace-pc.  Hence, the select should be:

  select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC

With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
scripts/Makefile.gcc-plugins can be cleaner.

I also cleaned up Kconfig and scripts/Makefile.kcov as well.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Replace the previous 'select -> imply' patch with
a new approach

Changes in v2:
  - Drop depends on GCC_VERSION

 Makefile |  2 +-
 lib/Kconfig.debug| 11 +++
 scripts/Makefile.gcc-plugins |  6 +-
 scripts/Makefile.kcov| 10 ++
 4 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/Makefile b/Makefile
index 889d002..88733b7 100644
--- a/Makefile
+++ b/Makefile
@@ -623,7 +623,7 @@ all: vmlinux
 KBUILD_CFLAGS  += $(call cc-option,-fno-PIE)
 KBUILD_AFLAGS  += $(call cc-option,-fno-PIE)
 CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call 
cc-disable-warning,maybe-uninitialized,)
-export CFLAGS_GCOV CFLAGS_KCOV
+export CFLAGS_GCOV
 
 # The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
 # values of the respective KBUILD_* variables
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..1335717 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -736,12 +736,15 @@ config ARCH_HAS_KCOV
  only for x86_64. KCOV requires testing on other archs, and most likely
  disabling of instrumentation for some early boot code.
 
+config CC_HAS_SANCOV_TRACE_PC
+   def_bool $(cc-option -fsanitize-coverage=trace-pc)
+
 config KCOV
bool "Code coverage for fuzzing"
depends on ARCH_HAS_KCOV
+   depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
select DEBUG_FS
-   select GCC_PLUGINS if !COMPILE_TEST
-   select GCC_PLUGIN_SANCOV if !COMPILE_TEST
+   select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
help
  KCOV exposes kernel code coverage information in a form suitable
  for coverage-guided fuzzing (randomized testing).
@@ -755,7 +758,7 @@ config KCOV
 config KCOV_ENABLE_COMPARISONS
bool "Enable comparison operands collection by KCOV"
depends on KCOV
-   default n
+   depends on $(cc-option -fsanitize-coverage=trace-cmp)
help
  KCOV also exposes operands of every comparison in the instrumented
  code along with operand sizes and PCs of the comparison instructions.
@@ -765,7 +768,7 @@ config KCOV_ENABLE_COMPARISONS
 config KCOV_INSTRUMENT_ALL
bool "Instrument all code by default"
depends on KCOV
-   default y if KCOV
+   default y
help
  If you are doing generic system call fuzzing (like e.g. syzkaller),
  then you will want to instrument the whole kernel and you should
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 7f5c862..0ce3802 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,16 +14,12 @@ ifdef CONFIG_GCC_PLUGINS
   endif
 
   ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(strip $(CFLAGS_KCOV)),)
   # It is needed because of the gcc-plugin.sh and gcc version checks.
   gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
 
-  ifneq ($(PLUGINCC),)
-CFLAGS_KCOV := $(SANCOV_PLUGIN)
-  else
+  ifeq ($(PLUGINCC),)
 $(warning warning: cannot use CONFIG_KCOV: 
-fsanitize-coverage=trace-pc is not supported by compiler)
   endif
-endif
   endif
 
   gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)   += structleak_plugin.so
diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov
index 5cc7203..d71ba73 100644
--- a/scripts/Makefile.kcov
+++ b/scripts/Makefile.kcov
@@ -1,7 +1,9 @@
 ifdef CONFIG_KCOV
-CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
-ifeq ($(CONFIG_KCOV_ENABLE_COMPARISONS),y)
-CFLAGS_KCOV += $(call cc-option,-fsanitize-coverage=trace-cmp,)
-endif
+
+kcov-flags-$(CONFIG_CC_HAS_SANCOV_TRACE_PC)+= -fsanitize-coverage=trace-pc
+kcov-flags-$(CONFIG_KCOV_ENABLE_COMPARISONS)   += -fsanitize-coverage=trace-cmp
+kcov-flags-$(CONFIG_GCC_PLUGIN_SANKOV) += 

[PATCH 28/30] gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST

2018-04-12 Thread Masahiro Yamada
Now that the compiler's plugin support is checked in Kconfig,
all{yes,mod}config will not be bothered.

Remove 'depends on !COMPILE_TEST' for GCC_PLUGINS.

'depends on !COMPILE_TEST' for the following three are still kept:
  GCC_PLUGIN_CYC_COMPLEXITY
  GCC_PLUGIN_STRUCTLEAK_VERBOSE
  GCC_PLUGIN_RANDSTRUCT_PERFORMANCE

Kees said to do so because the first two are too noisy, and the last
one would reduce the compile test coverage.  I commented the reasons
in arch/Kconfig.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 arch/Kconfig | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 9166157..95b9b2e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -420,7 +420,6 @@ menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
depends on PLUGIN_HOSTCC != ""
-   depends on !COMPILE_TEST
help
  GCC plugins are loadable modules that provide extra features to the
  compiler. They are useful for runtime instrumentation and static 
analysis.
@@ -430,7 +429,7 @@ menuconfig GCC_PLUGINS
 config GCC_PLUGIN_CYC_COMPLEXITY
bool "Compute the cyclomatic complexity of a function" if EXPERT
depends on GCC_PLUGINS
-   depends on !COMPILE_TEST
+   depends on !COMPILE_TEST# too noisy
help
  The complexity M of a function's control flow graph is defined as:
   M = E - N + 2P
@@ -493,7 +492,7 @@ config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
 config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
-   depends on !COMPILE_TEST
+   depends on !COMPILE_TEST# too noisy
help
  This option will cause a warning to be printed each time the
  structleak plugin finds a variable it thinks needs to be
@@ -533,7 +532,7 @@ config GCC_PLUGIN_RANDSTRUCT
 config GCC_PLUGIN_RANDSTRUCT_PERFORMANCE
bool "Use cacheline-aware structure randomization"
depends on GCC_PLUGIN_RANDSTRUCT
-   depends on !COMPILE_TEST
+   depends on !COMPILE_TEST# do not reduce test coverage
help
  If you say Y here, the RANDSTRUCT randomization will make a
  best effort at restricting randomization to cacheline-sized
-- 
2.7.4



[PATCH 25/30] kcov: test compiler capability in Kconfig and correct dependency

2018-04-12 Thread Masahiro Yamada
As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency.  Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS.  This could cause the unmet direct
dependency.

Now that Kconfig can test compiler capability, let's handle this in a
more sophisticated way.

There are two ways to enable KCOV; use the compiler that natively
supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
the compiler has ability to build GCC plugins.  Hence, the correct
dependency for KCOV is:

  depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS

You do not need to build the SANCOV plugin if the compiler already
supports -fsanitize-coverage=trace-pc.  Hence, the select should be:

  select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC

With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
scripts/Makefile.gcc-plugins can be cleaner.

I also cleaned up Kconfig and scripts/Makefile.kcov as well.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Replace the previous 'select -> imply' patch with
a new approach

Changes in v2:
  - Drop depends on GCC_VERSION

 Makefile |  2 +-
 lib/Kconfig.debug| 11 +++
 scripts/Makefile.gcc-plugins |  6 +-
 scripts/Makefile.kcov| 10 ++
 4 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/Makefile b/Makefile
index 889d002..88733b7 100644
--- a/Makefile
+++ b/Makefile
@@ -623,7 +623,7 @@ all: vmlinux
 KBUILD_CFLAGS  += $(call cc-option,-fno-PIE)
 KBUILD_AFLAGS  += $(call cc-option,-fno-PIE)
 CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage -fno-tree-loop-im $(call 
cc-disable-warning,maybe-uninitialized,)
-export CFLAGS_GCOV CFLAGS_KCOV
+export CFLAGS_GCOV
 
 # The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
 # values of the respective KBUILD_* variables
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..1335717 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -736,12 +736,15 @@ config ARCH_HAS_KCOV
  only for x86_64. KCOV requires testing on other archs, and most likely
  disabling of instrumentation for some early boot code.
 
+config CC_HAS_SANCOV_TRACE_PC
+   def_bool $(cc-option -fsanitize-coverage=trace-pc)
+
 config KCOV
bool "Code coverage for fuzzing"
depends on ARCH_HAS_KCOV
+   depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
select DEBUG_FS
-   select GCC_PLUGINS if !COMPILE_TEST
-   select GCC_PLUGIN_SANCOV if !COMPILE_TEST
+   select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
help
  KCOV exposes kernel code coverage information in a form suitable
  for coverage-guided fuzzing (randomized testing).
@@ -755,7 +758,7 @@ config KCOV
 config KCOV_ENABLE_COMPARISONS
bool "Enable comparison operands collection by KCOV"
depends on KCOV
-   default n
+   depends on $(cc-option -fsanitize-coverage=trace-cmp)
help
  KCOV also exposes operands of every comparison in the instrumented
  code along with operand sizes and PCs of the comparison instructions.
@@ -765,7 +768,7 @@ config KCOV_ENABLE_COMPARISONS
 config KCOV_INSTRUMENT_ALL
bool "Instrument all code by default"
depends on KCOV
-   default y if KCOV
+   default y
help
  If you are doing generic system call fuzzing (like e.g. syzkaller),
  then you will want to instrument the whole kernel and you should
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 7f5c862..0ce3802 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -14,16 +14,12 @@ ifdef CONFIG_GCC_PLUGINS
   endif
 
   ifdef CONFIG_GCC_PLUGIN_SANCOV
-ifeq ($(strip $(CFLAGS_KCOV)),)
   # It is needed because of the gcc-plugin.sh and gcc version checks.
   gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV)   += sancov_plugin.so
 
-  ifneq ($(PLUGINCC),)
-CFLAGS_KCOV := $(SANCOV_PLUGIN)
-  else
+  ifeq ($(PLUGINCC),)
 $(warning warning: cannot use CONFIG_KCOV: 
-fsanitize-coverage=trace-pc is not supported by compiler)
   endif
-endif
   endif
 
   gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK)   += structleak_plugin.so
diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov
index 5cc7203..d71ba73 100644
--- a/scripts/Makefile.kcov
+++ b/scripts/Makefile.kcov
@@ -1,7 +1,9 @@
 ifdef CONFIG_KCOV
-CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
-ifeq ($(CONFIG_KCOV_ENABLE_COMPARISONS),y)
-CFLAGS_KCOV += $(call cc-option,-fsanitize-coverage=trace-cmp,)
-endif
+
+kcov-flags-$(CONFIG_CC_HAS_SANCOV_TRACE_PC)+= -fsanitize-coverage=trace-pc
+kcov-flags-$(CONFIG_KCOV_ENABLE_COMPARISONS)   += -fsanitize-coverage=trace-cmp
+kcov-flags-$(CONFIG_GCC_PLUGIN_SANKOV) += 
-fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so
+

[PATCH 30/30] kbuild: test dead code/data elimination support in Kconfig

2018-04-12 Thread Masahiro Yamada
This config option should be enabled only when both the compiler and
the linker support necessary flags.  Add proper dependencies to Kconfig.

Unlike 'select', 'imply' is modest enough to observe those dependencies.
I suggested this in the help message.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Makefile | 8 ++--
 arch/Kconfig | 4 +++-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index 88733b7..92db767 100644
--- a/Makefile
+++ b/Makefile
@@ -754,8 +754,8 @@ KBUILD_CFLAGS += $(call cc-option, 
-fno-inline-functions-called-once)
 endif
 
 ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
-KBUILD_CFLAGS  += $(call cc-option,-ffunction-sections,)
-KBUILD_CFLAGS  += $(call cc-option,-fdata-sections,)
+KBUILD_CFLAGS  += -ffunction-sections -fdata-sections
+LDFLAGS_vmlinux+= --gc-sections
 endif
 
 # arch Makefile may override CC so keep this after arch Makefile is included
@@ -819,10 +819,6 @@ LDFLAGS_BUILD_ID := $(call ld-option, --build-id)
 KBUILD_LDFLAGS_MODULE += $(LDFLAGS_BUILD_ID)
 LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID)
 
-ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
-LDFLAGS_vmlinux+= $(call ld-option, --gc-sections,)
-endif
-
 ifeq ($(CONFIG_STRIP_ASM_SYMS),y)
 LDFLAGS_vmlinux+= $(call ld-option, -X,)
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index 95b9b2e..e88f1ba 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -597,8 +597,10 @@ config CC_STACKPROTECTOR_STRONG
 
 config LD_DEAD_CODE_DATA_ELIMINATION
bool
+   depends on $(cc-option -ffunction-sections -fdata-sections)
+   depends on $(ld-option --gc-sections)
help
- Select this if the architecture wants to do dead code and
+ Imply this if the architecture wants to do dead code and
  data elimination with the linker by compiling with
  -ffunction-sections -fdata-sections and linking with
  --gc-sections.
-- 
2.7.4



[PATCH 24/30] gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT

2018-04-12 Thread Masahiro Yamada
CONFIG_GCOV_FORMAT_AUTODETECT compiles either gcc_3_4.c or gcc_4_7.c
according to your GCC version.

We can achieve the equivalent behavior by setting reasonable dependency
with the knowledge of the compiler version.

If GCC older than 4.7 is used, GCOV_FORMAT_3_4 is the default, but users
are still allowed to select GCOV_FORMAT_4_7 in case the newer format is
back-ported.

On the other hand, If GCC 4.7 or newer is used, there is no reason to
use GCOV_FORMAT_3_4, so it should be hidden.

If you downgrade the compiler to GCC 4.7 or older, oldconfig/syncconfig
will display a prompt for the choice because GCOV_FORMAT_3_4 becomes
visible as a new symbol.

Signed-off-by: Masahiro Yamada 
Acked-by: Peter Oberparleiter 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 kernel/gcov/Kconfig  | 17 +
 kernel/gcov/Makefile |  2 --
 2 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
index 1276aab..1e3823f 100644
--- a/kernel/gcov/Kconfig
+++ b/kernel/gcov/Kconfig
@@ -53,23 +53,16 @@ config GCOV_PROFILE_ALL
 choice
prompt "Specify GCOV format"
depends on GCOV_KERNEL
-   default GCOV_FORMAT_AUTODETECT
---help---
-   The gcov format is usually determined by the GCC version, but there are
+   The gcov format is usually determined by the GCC version, and the
+   default is chosen according to your GCC version. However, there are
exceptions where format changes are integrated in lower-version GCCs.
-   In such a case use this option to adjust the format used in the kernel
-   accordingly.
-
-   If unsure, choose "Autodetect".
-
-config GCOV_FORMAT_AUTODETECT
-   bool "Autodetect"
-   ---help---
-   Select this option to use the format that corresponds to your GCC
-   version.
+   In such a case, change this option to adjust the format used in the
+   kernel accordingly.
 
 config GCOV_FORMAT_3_4
bool "GCC 3.4 format"
+   depends on CC_IS_GCC && GCC_VERSION < 40700
---help---
Select this option to use the format defined by GCC 3.4.
 
diff --git a/kernel/gcov/Makefile b/kernel/gcov/Makefile
index c6c50e5..ff06d64 100644
--- a/kernel/gcov/Makefile
+++ b/kernel/gcov/Makefile
@@ -4,5 +4,3 @@ ccflags-y := -DSRCTREE='"$(srctree)"' -DOBJTREE='"$(objtree)"'
 obj-y := base.o fs.o
 obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
 obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
-obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call cc-ifversion, -lt, 0407, \
-   gcc_3_4.o, gcc_4_7.o)
-- 
2.7.4



[PATCH 30/30] kbuild: test dead code/data elimination support in Kconfig

2018-04-12 Thread Masahiro Yamada
This config option should be enabled only when both the compiler and
the linker support necessary flags.  Add proper dependencies to Kconfig.

Unlike 'select', 'imply' is modest enough to observe those dependencies.
I suggested this in the help message.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Makefile | 8 ++--
 arch/Kconfig | 4 +++-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index 88733b7..92db767 100644
--- a/Makefile
+++ b/Makefile
@@ -754,8 +754,8 @@ KBUILD_CFLAGS += $(call cc-option, 
-fno-inline-functions-called-once)
 endif
 
 ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
-KBUILD_CFLAGS  += $(call cc-option,-ffunction-sections,)
-KBUILD_CFLAGS  += $(call cc-option,-fdata-sections,)
+KBUILD_CFLAGS  += -ffunction-sections -fdata-sections
+LDFLAGS_vmlinux+= --gc-sections
 endif
 
 # arch Makefile may override CC so keep this after arch Makefile is included
@@ -819,10 +819,6 @@ LDFLAGS_BUILD_ID := $(call ld-option, --build-id)
 KBUILD_LDFLAGS_MODULE += $(LDFLAGS_BUILD_ID)
 LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID)
 
-ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
-LDFLAGS_vmlinux+= $(call ld-option, --gc-sections,)
-endif
-
 ifeq ($(CONFIG_STRIP_ASM_SYMS),y)
 LDFLAGS_vmlinux+= $(call ld-option, -X,)
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index 95b9b2e..e88f1ba 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -597,8 +597,10 @@ config CC_STACKPROTECTOR_STRONG
 
 config LD_DEAD_CODE_DATA_ELIMINATION
bool
+   depends on $(cc-option -ffunction-sections -fdata-sections)
+   depends on $(ld-option --gc-sections)
help
- Select this if the architecture wants to do dead code and
+ Imply this if the architecture wants to do dead code and
  data elimination with the linker by compiling with
  -ffunction-sections -fdata-sections and linking with
  --gc-sections.
-- 
2.7.4



[PATCH 24/30] gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT

2018-04-12 Thread Masahiro Yamada
CONFIG_GCOV_FORMAT_AUTODETECT compiles either gcc_3_4.c or gcc_4_7.c
according to your GCC version.

We can achieve the equivalent behavior by setting reasonable dependency
with the knowledge of the compiler version.

If GCC older than 4.7 is used, GCOV_FORMAT_3_4 is the default, but users
are still allowed to select GCOV_FORMAT_4_7 in case the newer format is
back-ported.

On the other hand, If GCC 4.7 or newer is used, there is no reason to
use GCOV_FORMAT_3_4, so it should be hidden.

If you downgrade the compiler to GCC 4.7 or older, oldconfig/syncconfig
will display a prompt for the choice because GCOV_FORMAT_3_4 becomes
visible as a new symbol.

Signed-off-by: Masahiro Yamada 
Acked-by: Peter Oberparleiter 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 kernel/gcov/Kconfig  | 17 +
 kernel/gcov/Makefile |  2 --
 2 files changed, 5 insertions(+), 14 deletions(-)

diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig
index 1276aab..1e3823f 100644
--- a/kernel/gcov/Kconfig
+++ b/kernel/gcov/Kconfig
@@ -53,23 +53,16 @@ config GCOV_PROFILE_ALL
 choice
prompt "Specify GCOV format"
depends on GCOV_KERNEL
-   default GCOV_FORMAT_AUTODETECT
---help---
-   The gcov format is usually determined by the GCC version, but there are
+   The gcov format is usually determined by the GCC version, and the
+   default is chosen according to your GCC version. However, there are
exceptions where format changes are integrated in lower-version GCCs.
-   In such a case use this option to adjust the format used in the kernel
-   accordingly.
-
-   If unsure, choose "Autodetect".
-
-config GCOV_FORMAT_AUTODETECT
-   bool "Autodetect"
-   ---help---
-   Select this option to use the format that corresponds to your GCC
-   version.
+   In such a case, change this option to adjust the format used in the
+   kernel accordingly.
 
 config GCOV_FORMAT_3_4
bool "GCC 3.4 format"
+   depends on CC_IS_GCC && GCC_VERSION < 40700
---help---
Select this option to use the format defined by GCC 3.4.
 
diff --git a/kernel/gcov/Makefile b/kernel/gcov/Makefile
index c6c50e5..ff06d64 100644
--- a/kernel/gcov/Makefile
+++ b/kernel/gcov/Makefile
@@ -4,5 +4,3 @@ ccflags-y := -DSRCTREE='"$(srctree)"' -DOBJTREE='"$(objtree)"'
 obj-y := base.o fs.o
 obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
 obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
-obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call cc-ifversion, -lt, 0407, \
-   gcc_3_4.o, gcc_4_7.o)
-- 
2.7.4



[PATCH 04/30] kconfig: reference environment variables directly and remove 'option env='

2018-04-12 Thread Masahiro Yamada
To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax.  It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.

Adding '$' for symbol references is grammatically weird.  Looking at
the code, the symbols prefixed with 'S' are expanded by:
 - conf_expand_value()
   This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
 - sym_expand_string_value()
   This is used to expand strings in 'source' and 'mainmenu'

All of them are fixed values independent of user configuration.  So,
they can be changed into the direct expansion instead of symbols.

This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
should be replaced with an environment variable.

ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.

The new syntax is addicted by Make.  The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F.  Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.

At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.

The variables are expanded in the lexer so we can simplify the token
handling on the parser side.

For example, the following code works.

[Example code]

  config MY_TOOLCHAIN_LIST
  string
  default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

[Result]

  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3:
  - Reimplement
  - Variable reference need parentheses except single-letter variable

Changes in v2:
  - Move the string expansion to the lexer phase.
  - Split environment helpers to env.c

 Documentation/kbuild/kconfig-language.txt |   8 -
 Kconfig   |   8 +-
 Makefile  |   3 +-
 arch/sh/Kconfig   |   4 +-
 arch/sparc/Kconfig|   4 +-
 arch/um/Kconfig.common|   4 -
 arch/x86/Kconfig  |   4 +-
 arch/x86/um/Kconfig   |   6 +-
 init/Kconfig  |  16 +-
 scripts/kconfig/confdata.c|  31 +---
 scripts/kconfig/kconf_id.c|   1 -
 scripts/kconfig/lkc.h |   4 -
 scripts/kconfig/lkc_proto.h   |   6 +
 scripts/kconfig/menu.c|   3 -
 scripts/kconfig/preprocess.c  | 261 ++
 scripts/kconfig/symbol.c  |  56 ---
 scripts/kconfig/util.c|  18 +--
 scripts/kconfig/zconf.l   |  67 +++-
 scripts/kconfig/zconf.y   |   2 +-
 19 files changed, 353 insertions(+), 153 deletions(-)
 create mode 100644 scripts/kconfig/preprocess.c

diff --git a/Documentation/kbuild/kconfig-language.txt 
b/Documentation/kbuild/kconfig-language.txt
index f5b9493..0e966e8 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -198,14 +198,6 @@ applicable everywhere (see syntax).
 enables the third modular state for all config symbols.
 At most one symbol may have the "modules" option set.
 
-  - "env"=
-This imports the environment variable into Kconfig. It behaves like
-a default, except that the value comes from the environment, this
-also means that the behaviour when mixing it with normal defaults is
-undefined at this point. The symbol is currently not exported back
-to the build environment (if this is desired, it can be done via
-another symbol).
-
   - "allnoconfig_y"
 This declares the symbol as one that should have the value y when
 using "allnoconfig". Used for symbols that hide other symbols.
diff --git a/Kconfig b/Kconfig
index 8c4c1cb..4af1b42 100644
--- a/Kconfig
+++ b/Kconfig
@@ -3,10 +3,6 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/kconfig-language.txt.
 #
-mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
+mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
 
-config SRCARCH
-   string
-   option env="SRCARCH"
-
-source "arch/$SRCARCH/Kconfig"
+source "arch/$(SRCARCH)/Kconfig"
diff --git a/Makefile b/Makefile
index ca3e3e8..5298ad7 100644
--- a/Makefile
+++ b/Makefile
@@ -284,7 +284,8 @@ include scripts/Kbuild.include
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 

[PATCH 29/30] arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig

2018-04-12 Thread Masahiro Yamada
This becomes much neater in Kconfig.

Signed-off-by: Masahiro Yamada 
Acked-by: Will Deacon 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/Kconfig  | 1 +
 arch/arm64/Makefile | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index eb2cf49..09d1aee 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -43,6 +43,7 @@ config ARM64
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_SUPPORTS_MEMORY_FAILURE
select ARCH_SUPPORTS_ATOMIC_RMW
+   select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5
select ARCH_SUPPORTS_NUMA_BALANCING
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 1540286..cefd1e9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -56,8 +56,6 @@ KBUILD_AFLAGS += $(lseinstr) $(brokengasinst)
 KBUILD_CFLAGS  += $(call cc-option,-mabi=lp64)
 KBUILD_AFLAGS  += $(call cc-option,-mabi=lp64)
 
-KBUILD_CFLAGS  += $(call cc-ifversion, -ge, 0500, 
-DCONFIG_ARCH_SUPPORTS_INT128)
-
 ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
 KBUILD_CPPFLAGS+= -mbig-endian
 CHECKFLAGS += -D__AARCH64EB__
-- 
2.7.4



[PATCH 04/30] kconfig: reference environment variables directly and remove 'option env='

2018-04-12 Thread Masahiro Yamada
To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax.  It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.

Adding '$' for symbol references is grammatically weird.  Looking at
the code, the symbols prefixed with 'S' are expanded by:
 - conf_expand_value()
   This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
 - sym_expand_string_value()
   This is used to expand strings in 'source' and 'mainmenu'

All of them are fixed values independent of user configuration.  So,
they can be changed into the direct expansion instead of symbols.

This change makes the code much cleaner.  The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

sym_init() hard-coding 'UNAME_RELEASE' is also gone.  'UNAME_RELEASE'
should be replaced with an environment variable.

ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.

The new syntax is addicted by Make.  The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F.  Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.

At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.

The variables are expanded in the lexer so we can simplify the token
handling on the parser side.

For example, the following code works.

[Example code]

  config MY_TOOLCHAIN_LIST
  string
  default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

[Result]

  $ make -s alldefconfig && tail -n 1 .config
  CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
---

Changes in v3:
  - Reimplement
  - Variable reference need parentheses except single-letter variable

Changes in v2:
  - Move the string expansion to the lexer phase.
  - Split environment helpers to env.c

 Documentation/kbuild/kconfig-language.txt |   8 -
 Kconfig   |   8 +-
 Makefile  |   3 +-
 arch/sh/Kconfig   |   4 +-
 arch/sparc/Kconfig|   4 +-
 arch/um/Kconfig.common|   4 -
 arch/x86/Kconfig  |   4 +-
 arch/x86/um/Kconfig   |   6 +-
 init/Kconfig  |  16 +-
 scripts/kconfig/confdata.c|  31 +---
 scripts/kconfig/kconf_id.c|   1 -
 scripts/kconfig/lkc.h |   4 -
 scripts/kconfig/lkc_proto.h   |   6 +
 scripts/kconfig/menu.c|   3 -
 scripts/kconfig/preprocess.c  | 261 ++
 scripts/kconfig/symbol.c  |  56 ---
 scripts/kconfig/util.c|  18 +--
 scripts/kconfig/zconf.l   |  67 +++-
 scripts/kconfig/zconf.y   |   2 +-
 19 files changed, 353 insertions(+), 153 deletions(-)
 create mode 100644 scripts/kconfig/preprocess.c

diff --git a/Documentation/kbuild/kconfig-language.txt 
b/Documentation/kbuild/kconfig-language.txt
index f5b9493..0e966e8 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -198,14 +198,6 @@ applicable everywhere (see syntax).
 enables the third modular state for all config symbols.
 At most one symbol may have the "modules" option set.
 
-  - "env"=
-This imports the environment variable into Kconfig. It behaves like
-a default, except that the value comes from the environment, this
-also means that the behaviour when mixing it with normal defaults is
-undefined at this point. The symbol is currently not exported back
-to the build environment (if this is desired, it can be done via
-another symbol).
-
   - "allnoconfig_y"
 This declares the symbol as one that should have the value y when
 using "allnoconfig". Used for symbols that hide other symbols.
diff --git a/Kconfig b/Kconfig
index 8c4c1cb..4af1b42 100644
--- a/Kconfig
+++ b/Kconfig
@@ -3,10 +3,6 @@
 # For a description of the syntax of this configuration file,
 # see Documentation/kbuild/kconfig-language.txt.
 #
-mainmenu "Linux/$ARCH $KERNELVERSION Kernel Configuration"
+mainmenu "Linux/$(ARCH) $(KERNELVERSION) Kernel Configuration"
 
-config SRCARCH
-   string
-   option env="SRCARCH"
-
-source "arch/$SRCARCH/Kconfig"
+source "arch/$(SRCARCH)/Kconfig"
diff --git a/Makefile b/Makefile
index ca3e3e8..5298ad7 100644
--- a/Makefile
+++ b/Makefile
@@ -284,7 +284,8 @@ include scripts/Kbuild.include
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 

[PATCH 29/30] arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig

2018-04-12 Thread Masahiro Yamada
This becomes much neater in Kconfig.

Signed-off-by: Masahiro Yamada 
Acked-by: Will Deacon 
Reviewed-by: Kees Cook 
---

Changes in v3: None
Changes in v2: None

 arch/arm64/Kconfig  | 1 +
 arch/arm64/Makefile | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index eb2cf49..09d1aee 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -43,6 +43,7 @@ config ARM64
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_SUPPORTS_MEMORY_FAILURE
select ARCH_SUPPORTS_ATOMIC_RMW
+   select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 5
select ARCH_SUPPORTS_NUMA_BALANCING
select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
select ARCH_WANT_FRAME_POINTERS
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 1540286..cefd1e9 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -56,8 +56,6 @@ KBUILD_AFLAGS += $(lseinstr) $(brokengasinst)
 KBUILD_CFLAGS  += $(call cc-option,-mabi=lp64)
 KBUILD_AFLAGS  += $(call cc-option,-mabi=lp64)
 
-KBUILD_CFLAGS  += $(call cc-ifversion, -ge, 0500, 
-DCONFIG_ARCH_SUPPORTS_INT128)
-
 ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
 KBUILD_CPPFLAGS+= -mbig-endian
 CHECKFLAGS += -D__AARCH64EB__
-- 
2.7.4



[PATCH 11/30] kconfig: begin PARAM state only when seeing a command keyword

2018-04-12 Thread Masahiro Yamada
Currently, any statement line starts with a keyword with TF_COMMAND
flag.  So, the following three lines are dead code.

alloc_string(yytext, yyleng);
zconflval.string = text;
return T_WORD;

If a T_WORD token is returned in this context, it will cause syntax
error in the parser anyway.

The next commit will support the assignment statement where a line
starts with an arbitrary identifier.  So, I want the lexer to switch
to the PARAM state only when it sees a command keyword.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/zconf.l | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 9dc5fe3..5e53348 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -102,10 +102,10 @@ n [A-Za-z0-9_-]
 {
{n}+{
const struct kconf_id *id = kconf_id_lookup(yytext, yyleng);
-   BEGIN(PARAM);
current_pos.file = current_file;
current_pos.lineno = yylineno;
if (id && id->flags & TF_COMMAND) {
+   BEGIN(PARAM);
yylval.id = id;
return id->token;
}
-- 
2.7.4



[PATCH 15/30] kconfig: expand lefthand side of assignment statement

2018-04-12 Thread Masahiro Yamada
Make allows variable references in the lefthand side of assignment.

  X = A
  Y = B
  $(X)$(Y) = 1

This does 'AB = 1'  Do likewise in Kconfig as well.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/zconf.l | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index c68ca56b..ae33e9b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,6 +114,13 @@ n  [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
+   ({n}|$)+{
+   /* this token includes at least one '$' */
+   yylval.string = expand_token(yytext, yyleng);
+   if (strlen(yylval.string))
+   return T_VARIABLE;
+   free(yylval.string);
+   }
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return 
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return 
T_ASSIGN; }
"+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return 
T_ASSIGN; }
-- 
2.7.4



[PATCH 10/30] kconfig: replace $(UNAME_RELEASE) with function call

2018-04-12 Thread Masahiro Yamada
Now that 'shell' function is supported, this can be self-contained in
Kconfig.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3: None
Changes in v2: None

 Makefile | 3 +--
 init/Kconfig | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 5298ad7..ca3e3e8 100644
--- a/Makefile
+++ b/Makefile
@@ -284,8 +284,7 @@ include scripts/Kbuild.include
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
-UNAME_RELEASE := $(shell uname --release)
-export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION UNAME_RELEASE
+export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
 
 # SUBARCH tells the usermode build what the underlying arch is.  That is set
 # first, and if a usermode build is happening, the "ARCH=um" on the command
diff --git a/init/Kconfig b/init/Kconfig
index e6dafed5..4b0b636 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2,9 +2,9 @@ config DEFCONFIG_LIST
string
depends on !UML
option defconfig_list
-   default "/lib/modules/$(UNAME_RELEASE)/.config"
+   default "/lib/modules/$(shell uname --release)/.config"
default "/etc/kernel-config"
-   default "/boot/config-$(UNAME_RELEASE)"
+   default "/boot/config-$(shell uname --release)"
default ARCH_DEFCONFIG
default "arch/$(ARCH)/defconfig"
 
-- 
2.7.4



[PATCH 11/30] kconfig: begin PARAM state only when seeing a command keyword

2018-04-12 Thread Masahiro Yamada
Currently, any statement line starts with a keyword with TF_COMMAND
flag.  So, the following three lines are dead code.

alloc_string(yytext, yyleng);
zconflval.string = text;
return T_WORD;

If a T_WORD token is returned in this context, it will cause syntax
error in the parser anyway.

The next commit will support the assignment statement where a line
starts with an arbitrary identifier.  So, I want the lexer to switch
to the PARAM state only when it sees a command keyword.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/zconf.l | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 9dc5fe3..5e53348 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -102,10 +102,10 @@ n [A-Za-z0-9_-]
 {
{n}+{
const struct kconf_id *id = kconf_id_lookup(yytext, yyleng);
-   BEGIN(PARAM);
current_pos.file = current_file;
current_pos.lineno = yylineno;
if (id && id->flags & TF_COMMAND) {
+   BEGIN(PARAM);
yylval.id = id;
return id->token;
}
-- 
2.7.4



[PATCH 15/30] kconfig: expand lefthand side of assignment statement

2018-04-12 Thread Masahiro Yamada
Make allows variable references in the lefthand side of assignment.

  X = A
  Y = B
  $(X)$(Y) = 1

This does 'AB = 1'  Do likewise in Kconfig as well.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/kconfig/zconf.l | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index c68ca56b..ae33e9b 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -114,6 +114,13 @@ n  [A-Za-z0-9_-]
yylval.string = text;
return T_VARIABLE;
}
+   ({n}|$)+{
+   /* this token includes at least one '$' */
+   yylval.string = expand_token(yytext, yyleng);
+   if (strlen(yylval.string))
+   return T_VARIABLE;
+   free(yylval.string);
+   }
"=" { BEGIN(ASSIGN_VAL); yylval.flavor = VAR_RECURSIVE; return 
T_ASSIGN; }
":="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_SIMPLE; return 
T_ASSIGN; }
"+="{ BEGIN(ASSIGN_VAL); yylval.flavor = VAR_APPEND; return 
T_ASSIGN; }
-- 
2.7.4



[PATCH 10/30] kconfig: replace $(UNAME_RELEASE) with function call

2018-04-12 Thread Masahiro Yamada
Now that 'shell' function is supported, this can be self-contained in
Kconfig.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Kees Cook 
Reviewed-by: Ulf Magnusson 
---

Changes in v3: None
Changes in v2: None

 Makefile | 3 +--
 init/Kconfig | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 5298ad7..ca3e3e8 100644
--- a/Makefile
+++ b/Makefile
@@ -284,8 +284,7 @@ include scripts/Kbuild.include
 # Read KERNELRELEASE from include/config/kernel.release (if it exists)
 KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
 KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if 
$(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
-UNAME_RELEASE := $(shell uname --release)
-export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION UNAME_RELEASE
+export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
 
 # SUBARCH tells the usermode build what the underlying arch is.  That is set
 # first, and if a usermode build is happening, the "ARCH=um" on the command
diff --git a/init/Kconfig b/init/Kconfig
index e6dafed5..4b0b636 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2,9 +2,9 @@ config DEFCONFIG_LIST
string
depends on !UML
option defconfig_list
-   default "/lib/modules/$(UNAME_RELEASE)/.config"
+   default "/lib/modules/$(shell uname --release)/.config"
default "/etc/kernel-config"
-   default "/boot/config-$(UNAME_RELEASE)"
+   default "/boot/config-$(shell uname --release)"
default ARCH_DEFCONFIG
default "arch/$(ARCH)/defconfig"
 
-- 
2.7.4



Re: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited

2018-04-12 Thread Jakub Kicinski
On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> + if (bw_avail >= bw_cap)
> + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> +  bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> + else
> + pci_info(dev, "%d Mb/s available bandwidth, limited by %s x%d 
> link at %s (capable of %d Mb/s with %s x%d link)\n",
> +  bw_avail, PCIE_SPEED2STR(speed), width,
> +  limiting_dev ? pci_name(limiting_dev) : "",
> +  bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);

I was just looking at using this new function to print PCIe BW for a
NIC, but I'm slightly worried that there is nothing in the message that
says PCIe...  For a NIC some people may interpret the bandwidth as NIC
bandwidth:

[   39.839989] nfp :04:00.0: Netronome Flow Processor NFP4000/NFP6000 PCIe 
Card Probe
[   39.848943] nfp :04:00.0: 63.008 Gb/s available bandwidth (8 GT/s x8 
link)
[   39.857146] nfp :04:00.0: RESERVED BARs: 0.0: General/MSI-X SRAM, 0.1: 
PCIe XPB/MSI-X PBA, 0.4: Explicit0, 0.5: Explicit1, fre4

It's not a 63Gbps NIC...  I'm sorry if this was discussed before and I
didn't find it.  Would it make sense to add the "PCIe: " prefix to the
message like bnx2x used to do?  Like:

nfp :04:00.0: PCIe: 63.008 Gb/s available bandwidth (8 GT/s x8 link)

Sorry for a very late comment.


Re: [PATCH v5 05/14] PCI: Add pcie_print_link_status() to log link speed and whether it's limited

2018-04-12 Thread Jakub Kicinski
On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> + if (bw_avail >= bw_cap)
> + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> +  bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> + else
> + pci_info(dev, "%d Mb/s available bandwidth, limited by %s x%d 
> link at %s (capable of %d Mb/s with %s x%d link)\n",
> +  bw_avail, PCIE_SPEED2STR(speed), width,
> +  limiting_dev ? pci_name(limiting_dev) : "",
> +  bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);

I was just looking at using this new function to print PCIe BW for a
NIC, but I'm slightly worried that there is nothing in the message that
says PCIe...  For a NIC some people may interpret the bandwidth as NIC
bandwidth:

[   39.839989] nfp :04:00.0: Netronome Flow Processor NFP4000/NFP6000 PCIe 
Card Probe
[   39.848943] nfp :04:00.0: 63.008 Gb/s available bandwidth (8 GT/s x8 
link)
[   39.857146] nfp :04:00.0: RESERVED BARs: 0.0: General/MSI-X SRAM, 0.1: 
PCIe XPB/MSI-X PBA, 0.4: Explicit0, 0.5: Explicit1, fre4

It's not a 63Gbps NIC...  I'm sorry if this was discussed before and I
didn't find it.  Would it make sense to add the "PCIe: " prefix to the
message like bnx2x used to do?  Like:

nfp :04:00.0: PCIe: 63.008 Gb/s available bandwidth (8 GT/s x8 link)

Sorry for a very late comment.


Re: [RFC v2] virtio: support packed ring

2018-04-12 Thread Jason Wang



On 2018年04月01日 22:12, Tiwei Bie wrote:

Hello everyone,

This RFC implements packed ring support for virtio driver.

The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
Minor changes are needed for the vhost code, e.g. to kick the guest.

TODO:
- Refinements and bug fixes;
- Split into small patches;
- Test indirect descriptor support;
- Test/fix event suppression support;
- Test devices other than net;

RFC v1 -> RFC v2:
- Add indirect descriptor support - compile test only;
- Add event suppression supprt - compile test only;
- Move vring_packed_init() out of uapi (Jason, MST);
- Merge two loops into one in virtqueue_add_packed() (Jason);
- Split vring_unmap_one() for packed ring and split ring (Jason);
- Avoid using '%' operator (Jason);
- Rename free_head -> next_avail_idx (Jason);
- Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
- Some other refinements and bug fixes;

Thanks!

Signed-off-by: Tiwei Bie 
---
  drivers/virtio/virtio_ring.c   | 1094 +---
  include/linux/virtio_ring.h|8 +-
  include/uapi/linux/virtio_config.h |   12 +-
  include/uapi/linux/virtio_ring.h   |   61 ++
  4 files changed, 980 insertions(+), 195 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 71458f493cf8..0515dca34d77 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -58,14 +58,15 @@
  
  struct vring_desc_state {

void *data; /* Data for callback. */
-   struct vring_desc *indir_desc;  /* Indirect descriptor, if any. */
+   void *indir_desc;   /* Indirect descriptor, if any. */
+   int num;/* Descriptor list length. */
  };
  
  struct vring_virtqueue {

struct virtqueue vq;
  
-	/* Actual memory layout for this queue */

-   struct vring vring;
+   /* Is this a packed ring? */
+   bool packed;
  
  	/* Can we use weak barriers? */

bool weak_barriers;
@@ -79,19 +80,45 @@ struct vring_virtqueue {
/* Host publishes avail event idx */
bool event;
  
-	/* Head of free buffer list. */

-   unsigned int free_head;
/* Number we've added since last sync. */
unsigned int num_added;
  
  	/* Last used index we've seen. */

u16 last_used_idx;
  
-	/* Last written value to avail->flags */

-   u16 avail_flags_shadow;
+   union {
+   /* Available for split ring */
+   struct {
+   /* Actual memory layout for this queue. */
+   struct vring vring;
  
-	/* Last written value to avail->idx in guest byte order */

-   u16 avail_idx_shadow;
+   /* Head of free buffer list. */
+   unsigned int free_head;
+
+   /* Last written value to avail->flags */
+   u16 avail_flags_shadow;
+
+   /* Last written value to avail->idx in
+* guest byte order. */
+   u16 avail_idx_shadow;
+   };
+
+   /* Available for packed ring */
+   struct {
+   /* Actual memory layout for this queue. */
+   struct vring_packed vring_packed;
+
+   /* Driver ring wrap counter. */
+   u8 wrap_counter;
+
+   /* Index of the next avail descriptor. */
+   unsigned int next_avail_idx;
+
+   /* Last written value to driver->flags in
+* guest byte order. */
+   u16 event_flags_shadow;
+   };
+   };
  
  	/* How to notify other side. FIXME: commonalize hcalls! */

bool (*notify)(struct virtqueue *vq);
@@ -201,8 +228,33 @@ static dma_addr_t vring_map_single(const struct 
vring_virtqueue *vq,
  cpu_addr, size, direction);
  }
  
-static void vring_unmap_one(const struct vring_virtqueue *vq,

-   struct vring_desc *desc)
+static void vring_unmap_one_split(const struct vring_virtqueue *vq,
+ struct vring_desc *desc)
+{
+   u16 flags;
+
+   if (!vring_use_dma_api(vq->vq.vdev))
+   return;
+
+   flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
+
+   if (flags & VRING_DESC_F_INDIRECT) {
+   dma_unmap_single(vring_dma_dev(vq),
+virtio64_to_cpu(vq->vq.vdev, desc->addr),
+virtio32_to_cpu(vq->vq.vdev, desc->len),
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+   } else {
+   dma_unmap_page(vring_dma_dev(vq),
+  

Re: [RFC v2] virtio: support packed ring

2018-04-12 Thread Jason Wang



On 2018年04月01日 22:12, Tiwei Bie wrote:

Hello everyone,

This RFC implements packed ring support for virtio driver.

The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
Minor changes are needed for the vhost code, e.g. to kick the guest.

TODO:
- Refinements and bug fixes;
- Split into small patches;
- Test indirect descriptor support;
- Test/fix event suppression support;
- Test devices other than net;

RFC v1 -> RFC v2:
- Add indirect descriptor support - compile test only;
- Add event suppression supprt - compile test only;
- Move vring_packed_init() out of uapi (Jason, MST);
- Merge two loops into one in virtqueue_add_packed() (Jason);
- Split vring_unmap_one() for packed ring and split ring (Jason);
- Avoid using '%' operator (Jason);
- Rename free_head -> next_avail_idx (Jason);
- Add comments for virtio_wmb() in virtqueue_add_packed() (Jason);
- Some other refinements and bug fixes;

Thanks!

Signed-off-by: Tiwei Bie 
---
  drivers/virtio/virtio_ring.c   | 1094 +---
  include/linux/virtio_ring.h|8 +-
  include/uapi/linux/virtio_config.h |   12 +-
  include/uapi/linux/virtio_ring.h   |   61 ++
  4 files changed, 980 insertions(+), 195 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 71458f493cf8..0515dca34d77 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -58,14 +58,15 @@
  
  struct vring_desc_state {

void *data; /* Data for callback. */
-   struct vring_desc *indir_desc;  /* Indirect descriptor, if any. */
+   void *indir_desc;   /* Indirect descriptor, if any. */
+   int num;/* Descriptor list length. */
  };
  
  struct vring_virtqueue {

struct virtqueue vq;
  
-	/* Actual memory layout for this queue */

-   struct vring vring;
+   /* Is this a packed ring? */
+   bool packed;
  
  	/* Can we use weak barriers? */

bool weak_barriers;
@@ -79,19 +80,45 @@ struct vring_virtqueue {
/* Host publishes avail event idx */
bool event;
  
-	/* Head of free buffer list. */

-   unsigned int free_head;
/* Number we've added since last sync. */
unsigned int num_added;
  
  	/* Last used index we've seen. */

u16 last_used_idx;
  
-	/* Last written value to avail->flags */

-   u16 avail_flags_shadow;
+   union {
+   /* Available for split ring */
+   struct {
+   /* Actual memory layout for this queue. */
+   struct vring vring;
  
-	/* Last written value to avail->idx in guest byte order */

-   u16 avail_idx_shadow;
+   /* Head of free buffer list. */
+   unsigned int free_head;
+
+   /* Last written value to avail->flags */
+   u16 avail_flags_shadow;
+
+   /* Last written value to avail->idx in
+* guest byte order. */
+   u16 avail_idx_shadow;
+   };
+
+   /* Available for packed ring */
+   struct {
+   /* Actual memory layout for this queue. */
+   struct vring_packed vring_packed;
+
+   /* Driver ring wrap counter. */
+   u8 wrap_counter;
+
+   /* Index of the next avail descriptor. */
+   unsigned int next_avail_idx;
+
+   /* Last written value to driver->flags in
+* guest byte order. */
+   u16 event_flags_shadow;
+   };
+   };
  
  	/* How to notify other side. FIXME: commonalize hcalls! */

bool (*notify)(struct virtqueue *vq);
@@ -201,8 +228,33 @@ static dma_addr_t vring_map_single(const struct 
vring_virtqueue *vq,
  cpu_addr, size, direction);
  }
  
-static void vring_unmap_one(const struct vring_virtqueue *vq,

-   struct vring_desc *desc)
+static void vring_unmap_one_split(const struct vring_virtqueue *vq,
+ struct vring_desc *desc)
+{
+   u16 flags;
+
+   if (!vring_use_dma_api(vq->vq.vdev))
+   return;
+
+   flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
+
+   if (flags & VRING_DESC_F_INDIRECT) {
+   dma_unmap_single(vring_dma_dev(vq),
+virtio64_to_cpu(vq->vq.vdev, desc->addr),
+virtio32_to_cpu(vq->vq.vdev, desc->len),
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+   } else {
+   dma_unmap_page(vring_dma_dev(vq),
+  virtio64_to_cpu(vq->vq.vdev, desc->addr),
+

RE: [RFC v3 0/2] WhiteEgret LSM module

2018-04-12 Thread shinya1.takumi
> Do you have a target date for posting that?
Yes, we have the target date. We will submit WhiteEgret v4 by September.

> So you have a design for being able to differentiate the interpreters 
> reading versus reading with the intent to execute?
> With or without their help?
We will provide WEUA sample to be able to control a script program with 
WhiteEgret v4.
Our WEUA sample does not identify whether to read or to read with the intent to 
execute. 
The sample has some restrictions.

We consider that the restrictions can be resolved by implementing additional 
functions for WEUA.
It is an implementation-dependent matter.

Howerver, we are sure that the restrictions are acceptable for many 
applications.
We would like to discuss about them with WhiteEgret v4 patch!

-Original Message-
> I am one of developers of WhiteEgret.
> 
> > regardling the last one, do you have a plan for handling it?
> Yes, we have a plan to release WhiteEgret v4 patch with a WEUA sample of 
> access control for script programs.

Do you have a target date for posting that?

> The latest WhiteEgret cannot control script programs since script files read 
> by an interpreter are not hooked by the execve system call.
> We consider that script programs can be controlled by controlling the files 
> inputted by interpreters, accordingly. 
> We consider that the control can be realized using the read system call 
> hooking.

So you have a design for being able to differentiate the interpreters reading 
versus reading with the intent to execute?  With or without their help?

> Now, we are developing WhiteEgret with the read system call hooking and WEUA 
> which controls the script files to be read to interpreters using information 
> from the read system call hooking and white list.

-serge




RE: [RFC v3 0/2] WhiteEgret LSM module

2018-04-12 Thread shinya1.takumi
> Do you have a target date for posting that?
Yes, we have the target date. We will submit WhiteEgret v4 by September.

> So you have a design for being able to differentiate the interpreters 
> reading versus reading with the intent to execute?
> With or without their help?
We will provide WEUA sample to be able to control a script program with 
WhiteEgret v4.
Our WEUA sample does not identify whether to read or to read with the intent to 
execute. 
The sample has some restrictions.

We consider that the restrictions can be resolved by implementing additional 
functions for WEUA.
It is an implementation-dependent matter.

Howerver, we are sure that the restrictions are acceptable for many 
applications.
We would like to discuss about them with WhiteEgret v4 patch!

-Original Message-
> I am one of developers of WhiteEgret.
> 
> > regardling the last one, do you have a plan for handling it?
> Yes, we have a plan to release WhiteEgret v4 patch with a WEUA sample of 
> access control for script programs.

Do you have a target date for posting that?

> The latest WhiteEgret cannot control script programs since script files read 
> by an interpreter are not hooked by the execve system call.
> We consider that script programs can be controlled by controlling the files 
> inputted by interpreters, accordingly. 
> We consider that the control can be realized using the read system call 
> hooking.

So you have a design for being able to differentiate the interpreters reading 
versus reading with the intent to execute?  With or without their help?

> Now, we are developing WhiteEgret with the read system call hooking and WEUA 
> which controls the script files to be read to interpreters using information 
> from the read system call hooking and white list.

-serge




Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Eduardo Valentin
Hello,

On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui  wrote:
> >
> > could you please illustrate me what the kconfig & warning is?
> 
> Just "make allmodconfig" and the warning is about a uninitialized variable.
> 
> Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell history
> is to be believed.
> 
> Linus

Yeah, this has also passed my local compilation error. Somehow my gcc4.9
is not catching it. Using an older gcc (gcc4.6) does catch it.

Anyways, given that the conversion functions are written to cover
for unexpected cal_type, the right way of fixing this is to rewrite
the conversion functions to allow for returning error codes and
adjusting the callers as expected.

Rui, bzolnier, please consider the following fix:

>From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin 
Date: Thu, 12 Apr 2018 21:00:48 -0700
Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
 conversion functions

In order to fix the warns:
drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may be used 
uninitialized in this function [-Wmaybe-uninitialized]

the conversion functions should allow return error codes
and the not mix the converted value with error code.

This patch change the conversion functions to return
error code or success and adjusts the callers accordingly.

Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/samsung/exynos_tmu.c | 120 ---
 1 file changed, 84 insertions(+), 36 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 2ec8548..b3f0704 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -282,52 +282,54 @@ static void exynos_report_trigger(struct exynos_tmu_data 
*p)
  * TMU treats temperature as a mapped temperature code.
  * The temperature is converted differently depending on the calibration type.
  */
-static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
+static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int *temp_code)
 {
-   int temp_code;
+   int ret = 0;
 
switch (data->cal_type) {
case TYPE_TWO_POINT_TRIMMING:
-   temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
+   *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
(data->temp_error2 - data->temp_error1) /
(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) +
data->temp_error1;
break;
case TYPE_ONE_POINT_TRIMMING:
-   temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
+   *temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
break;
default:
WARN_ON(1);
+   ret = -EINVAL;
break;
}
 
-   return temp_code;
+   return ret;
 }
 
 /*
  * Calculate a temperature value from a temperature code.
  * The unit of the temperature is degree Celsius.
  */
-static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code, int *temp)
 {
-   int temp;
+   int ret = 0;
 
switch (data->cal_type) {
case TYPE_TWO_POINT_TRIMMING:
-   temp = (temp_code - data->temp_error1) *
+   *temp = (temp_code - data->temp_error1) *
(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) /
(data->temp_error2 - data->temp_error1) +
EXYNOS_FIRST_POINT_TRIM;
break;
case TYPE_ONE_POINT_TRIMMING:
-   temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
+   *temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
break;
default:
WARN_ON(1);
+   ret = -EINVAL;
break;
}
 
-   return temp;
+   return ret;
 }
 
 static void sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
@@ -352,7 +354,7 @@ static u32 get_th_reg(struct exynos_tmu_data *data, u32 
threshold, bool falling)
struct thermal_zone_device *tz = data->tzd;
const struct thermal_trip * const trips =
of_thermal_get_trip_points(tz);
-   unsigned long temp;
+   int temp;
int i;
 
if (!trips) {
@@ -362,6 +364,8 @@ static u32 get_th_reg(struct exynos_tmu_data *data, u32 
threshold, bool falling)
}
 
for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
+   int val, ret;
+
if (trips[i].type == THERMAL_TRIP_CRITICAL)
  

Re: [GIT PULL] Thermal management updates for v4.17-rc1

2018-04-12 Thread Eduardo Valentin
Hello,

On Thu, Apr 12, 2018 at 09:55:19AM -0700, Linus Torvalds wrote:
> On Wed, Apr 11, 2018 at 10:08 PM, Zhang Rui  wrote:
> >
> > could you please illustrate me what the kconfig & warning is?
> 
> Just "make allmodconfig" and the warning is about a uninitialized variable.
> 
> Line 304 in drivers/thermal/samsung/exynos_tmu.c if my shell history
> is to be believed.
> 
> Linus

Yeah, this has also passed my local compilation error. Somehow my gcc4.9
is not catching it. Using an older gcc (gcc4.6) does catch it.

Anyways, given that the conversion functions are written to cover
for unexpected cal_type, the right way of fixing this is to rewrite
the conversion functions to allow for returning error codes and
adjusting the callers as expected.

Rui, bzolnier, please consider the following fix:

>From 2aaf94f80c0021a21b4122c9f4197acff08ea398 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin 
Date: Thu, 12 Apr 2018 21:00:48 -0700
Subject: [PATCH 1/1] thermal: exynos: fix compilation warning around
 conversion functions

In order to fix the warns:
drivers/thermal/samsung/exynos_tmu.c:931:37: warning: 'temp' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/thermal/samsung/exynos_tmu.c:304:9: warning: 'temp_code' may be used 
uninitialized in this function [-Wmaybe-uninitialized]

the conversion functions should allow return error codes
and the not mix the converted value with error code.

This patch change the conversion functions to return
error code or success and adjusts the callers accordingly.

Signed-off-by: Eduardo Valentin 
---
 drivers/thermal/samsung/exynos_tmu.c | 120 ---
 1 file changed, 84 insertions(+), 36 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 2ec8548..b3f0704 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -282,52 +282,54 @@ static void exynos_report_trigger(struct exynos_tmu_data 
*p)
  * TMU treats temperature as a mapped temperature code.
  * The temperature is converted differently depending on the calibration type.
  */
-static int temp_to_code(struct exynos_tmu_data *data, u8 temp)
+static int temp_to_code(struct exynos_tmu_data *data, u8 temp, int *temp_code)
 {
-   int temp_code;
+   int ret = 0;
 
switch (data->cal_type) {
case TYPE_TWO_POINT_TRIMMING:
-   temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
+   *temp_code = (temp - EXYNOS_FIRST_POINT_TRIM) *
(data->temp_error2 - data->temp_error1) /
(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) +
data->temp_error1;
break;
case TYPE_ONE_POINT_TRIMMING:
-   temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
+   *temp_code = temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
break;
default:
WARN_ON(1);
+   ret = -EINVAL;
break;
}
 
-   return temp_code;
+   return ret;
 }
 
 /*
  * Calculate a temperature value from a temperature code.
  * The unit of the temperature is degree Celsius.
  */
-static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
+static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code, int *temp)
 {
-   int temp;
+   int ret = 0;
 
switch (data->cal_type) {
case TYPE_TWO_POINT_TRIMMING:
-   temp = (temp_code - data->temp_error1) *
+   *temp = (temp_code - data->temp_error1) *
(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) /
(data->temp_error2 - data->temp_error1) +
EXYNOS_FIRST_POINT_TRIM;
break;
case TYPE_ONE_POINT_TRIMMING:
-   temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
+   *temp = temp_code - data->temp_error1 + EXYNOS_FIRST_POINT_TRIM;
break;
default:
WARN_ON(1);
+   ret = -EINVAL;
break;
}
 
-   return temp;
+   return ret;
 }
 
 static void sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
@@ -352,7 +354,7 @@ static u32 get_th_reg(struct exynos_tmu_data *data, u32 
threshold, bool falling)
struct thermal_zone_device *tz = data->tzd;
const struct thermal_trip * const trips =
of_thermal_get_trip_points(tz);
-   unsigned long temp;
+   int temp;
int i;
 
if (!trips) {
@@ -362,6 +364,8 @@ static u32 get_th_reg(struct exynos_tmu_data *data, u32 
threshold, bool falling)
}
 
for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
+   int val, ret;
+
if (trips[i].type == THERMAL_TRIP_CRITICAL)
continue;
 
@@ -371,7 +375,14 @@ static u32 

Re: [PATCH] f2fs: enlarge block plug coverage

2018-04-12 Thread Jaegeuk Kim
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:06, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> On 2018/4/10 12:10, Jaegeuk Kim wrote:
> >>> On 04/10, Chao Yu wrote:
>  On 2018/4/10 2:02, Jaegeuk Kim wrote:
> > On 04/08, Chao Yu wrote:
> >> On 2018/4/5 11:51, Jaegeuk Kim wrote:
> >>> On 04/04, Chao Yu wrote:
>  This patch enlarges block plug coverage in __issue_discard_cmd, in
>  order to collect more pending bios before issuing them, to avoid
>  being disturbed by previous discard I/O in IO aware discard mode.
> >>>
> >>> Hmm, then we need to wait for huge discard IO for over 10 secs, which
> >>
> >> We found that total discard latency is rely on total discard number we 
> >> issued
> >> last time instead of range or length discard covered. IMO, if we don't 
> >> change
> >> .max_requests value, we will not suffer longer latency.
> >>
> >>> will affect following read/write IOs accordingly. In order to avoid 
> >>> that,
> >>> we actually need to limit the discard size.
> 
>  Do you mean limit discard count or discard length?
> >>>
> >>> Both of them.
> >>>
> 
> >>
> >> If you are worry about I/O interference in between discard and rw, I 
> >> suggest to
> >> decrease .max_requests value.
> >
> > What do you mean? This will produce more pending requests in the queue?
> 
>  I mean after applying this patch, we can queue more discard IOs in plug 
>  inside
>  task, otherwise, previous issued discard in block layer can make 
>  is_idle() be false,
>  then it can stop IO awared user to issue pending discard command.
> >>>
> >>> Then, unplug will issue lots of discard commands, which affects the 
> >>> following rw
> >>> latencies. My preference would be issuing discard commands one by one as 
> >>> much as
> >>> possible.
> >>
> >> Hmm.. for you concern, we can turn down IO priority of discard from 
> >> background?
> > 
> > That makes much more sense to me. :P
> 
> Then, this patch which enlarge plug coverage will not still a problem, right? 
> ;)

This is different one.

> 
> Thanks,
> 
> > 
> >>
> >> Thanks,
> >>
> >>>
> 
>  Thanks,
> 
> >
> >>
> >> Thanks,
> >>
> >>>
> >>> Thanks,
> >>>
> 
>  Signed-off-by: Chao Yu 
>  ---
>   fs/f2fs/segment.c | 7 +--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
>  diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>  index 8f0b5ba46315..4287e208c040 100644
>  --- a/fs/f2fs/segment.c
>  +++ b/fs/f2fs/segment.c
>  @@ -1208,10 +1208,12 @@ static int __issue_discard_cmd(struct 
>  f2fs_sb_info *sbi,
>   pend_list = >pend_list[i];
>   
>   mutex_lock(>cmd_lock);
>  +
>  +blk_start_plug();
>  +
>   if (list_empty(pend_list))
>   goto next;
>   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, 
>  >root));
>  -blk_start_plug();
>   list_for_each_entry_safe(dc, tmp, pend_list, list) {
>   f2fs_bug_on(sbi, dc->state != D_PREP);
>   
>  @@ -1227,8 +1229,9 @@ static int __issue_discard_cmd(struct 
>  f2fs_sb_info *sbi,
>   if (++iter >= dpolicy->max_requests)
>   break;
>   }
>  -blk_finish_plug();
>   next:
>  +blk_finish_plug();
>  +
>   mutex_unlock(>cmd_lock);
>   
>   if (iter >= dpolicy->max_requests)
>  -- 
>  2.15.0.55.gc2ece9dc4de6
> >>>
> >>> .
> >>>
> >
> > .
> >
> >>>
> >>> .
> >>>
> > 
> > .
> > 


Re: [PATCH] f2fs: enlarge block plug coverage

2018-04-12 Thread Jaegeuk Kim
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:06, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> On 2018/4/10 12:10, Jaegeuk Kim wrote:
> >>> On 04/10, Chao Yu wrote:
>  On 2018/4/10 2:02, Jaegeuk Kim wrote:
> > On 04/08, Chao Yu wrote:
> >> On 2018/4/5 11:51, Jaegeuk Kim wrote:
> >>> On 04/04, Chao Yu wrote:
>  This patch enlarges block plug coverage in __issue_discard_cmd, in
>  order to collect more pending bios before issuing them, to avoid
>  being disturbed by previous discard I/O in IO aware discard mode.
> >>>
> >>> Hmm, then we need to wait for huge discard IO for over 10 secs, which
> >>
> >> We found that total discard latency is rely on total discard number we 
> >> issued
> >> last time instead of range or length discard covered. IMO, if we don't 
> >> change
> >> .max_requests value, we will not suffer longer latency.
> >>
> >>> will affect following read/write IOs accordingly. In order to avoid 
> >>> that,
> >>> we actually need to limit the discard size.
> 
>  Do you mean limit discard count or discard length?
> >>>
> >>> Both of them.
> >>>
> 
> >>
> >> If you are worry about I/O interference in between discard and rw, I 
> >> suggest to
> >> decrease .max_requests value.
> >
> > What do you mean? This will produce more pending requests in the queue?
> 
>  I mean after applying this patch, we can queue more discard IOs in plug 
>  inside
>  task, otherwise, previous issued discard in block layer can make 
>  is_idle() be false,
>  then it can stop IO awared user to issue pending discard command.
> >>>
> >>> Then, unplug will issue lots of discard commands, which affects the 
> >>> following rw
> >>> latencies. My preference would be issuing discard commands one by one as 
> >>> much as
> >>> possible.
> >>
> >> Hmm.. for you concern, we can turn down IO priority of discard from 
> >> background?
> > 
> > That makes much more sense to me. :P
> 
> Then, this patch which enlarge plug coverage will not still a problem, right? 
> ;)

This is different one.

> 
> Thanks,
> 
> > 
> >>
> >> Thanks,
> >>
> >>>
> 
>  Thanks,
> 
> >
> >>
> >> Thanks,
> >>
> >>>
> >>> Thanks,
> >>>
> 
>  Signed-off-by: Chao Yu 
>  ---
>   fs/f2fs/segment.c | 7 +--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
>  diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>  index 8f0b5ba46315..4287e208c040 100644
>  --- a/fs/f2fs/segment.c
>  +++ b/fs/f2fs/segment.c
>  @@ -1208,10 +1208,12 @@ static int __issue_discard_cmd(struct 
>  f2fs_sb_info *sbi,
>   pend_list = >pend_list[i];
>   
>   mutex_lock(>cmd_lock);
>  +
>  +blk_start_plug();
>  +
>   if (list_empty(pend_list))
>   goto next;
>   f2fs_bug_on(sbi, !__check_rb_tree_consistence(sbi, 
>  >root));
>  -blk_start_plug();
>   list_for_each_entry_safe(dc, tmp, pend_list, list) {
>   f2fs_bug_on(sbi, dc->state != D_PREP);
>   
>  @@ -1227,8 +1229,9 @@ static int __issue_discard_cmd(struct 
>  f2fs_sb_info *sbi,
>   if (++iter >= dpolicy->max_requests)
>   break;
>   }
>  -blk_finish_plug();
>   next:
>  +blk_finish_plug();
>  +
>   mutex_unlock(>cmd_lock);
>   
>   if (iter >= dpolicy->max_requests)
>  -- 
>  2.15.0.55.gc2ece9dc4de6
> >>>
> >>> .
> >>>
> >
> > .
> >
> >>>
> >>> .
> >>>
> > 
> > .
> > 


Re: [PATCH] f2fs: set deadline to drop expired inmem pages

2018-04-12 Thread Jaegeuk Kim
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:04, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2018/4/8 16:13, Chao Yu wrote:
> >>> f2fs doesn't allow abuse on atomic write class interface, so except
> >>> limiting in-mem pages' total memory usage capacity, we need to limit
> >>> start-commit time as well, otherwise we may run into infinite loop
> >>> during foreground GC because target blocks in victim segment are
> >>> belong to atomic opened file for long time.
> >>>
> >>> Now, we will check the condition with f2fs_balance_fs_bg in
> >>> background threads, once if user doesn't commit data exceeding 30
> >>> seconds, we will drop all cached data, so I expect it can keep our
> >>> system running safely to prevent Dos attack.
> >>
> >> Is it worth to add this patch to avoid abuse on atomic write interface by 
> >> user?
> > 
> > Hmm, hope to see a real problem first in this case.
> 
> I think this can be a more critical security leak instead of a potential issue
> which we can wait for someone reporting that can be too late.
> 
> For example, user can simply write a huge file whose data spread in all f2fs
> segments, once user open that file as atomic, foreground GC will suffer
> deadloop, causing denying any further service of f2fs.

How can you guarantee it won't happen within 30sec? If you want to avoid that,
you have to take a look at foreground gc.

> 
> Thanks,
> 
> > 
> >> Thanks,
> > 
> > .
> > 


Re: [PATCH] f2fs: set deadline to drop expired inmem pages

2018-04-12 Thread Jaegeuk Kim
On 04/13, Chao Yu wrote:
> On 2018/4/13 9:04, Jaegeuk Kim wrote:
> > On 04/10, Chao Yu wrote:
> >> Hi Jaegeuk,
> >>
> >> On 2018/4/8 16:13, Chao Yu wrote:
> >>> f2fs doesn't allow abuse on atomic write class interface, so except
> >>> limiting in-mem pages' total memory usage capacity, we need to limit
> >>> start-commit time as well, otherwise we may run into infinite loop
> >>> during foreground GC because target blocks in victim segment are
> >>> belong to atomic opened file for long time.
> >>>
> >>> Now, we will check the condition with f2fs_balance_fs_bg in
> >>> background threads, once if user doesn't commit data exceeding 30
> >>> seconds, we will drop all cached data, so I expect it can keep our
> >>> system running safely to prevent Dos attack.
> >>
> >> Is it worth to add this patch to avoid abuse on atomic write interface by 
> >> user?
> > 
> > Hmm, hope to see a real problem first in this case.
> 
> I think this can be a more critical security leak instead of a potential issue
> which we can wait for someone reporting that can be too late.
> 
> For example, user can simply write a huge file whose data spread in all f2fs
> segments, once user open that file as atomic, foreground GC will suffer
> deadloop, causing denying any further service of f2fs.

How can you guarantee it won't happen within 30sec? If you want to avoid that,
you have to take a look at foreground gc.

> 
> Thanks,
> 
> > 
> >> Thanks,
> > 
> > .
> > 


  1   2   3   4   5   6   7   8   9   10   >