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

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

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-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

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

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

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

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.

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

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

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

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

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

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? >

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

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

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

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

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

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: >> >>

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

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

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

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: >> >>

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

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

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

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

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

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

[PATCH] timekeeping: Remove __current_kernel_time()

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.

[PATCH] timekeeping: Remove __current_kernel_time()

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.

Re: Crashes/hung tasks with z3pool under memory pressure

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.

Re: Crashes/hung tasks with z3pool under memory pressure

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

[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

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

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

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

[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

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

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

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

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,

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[PATCH 03/30] kbuild: remove CONFIG_CROSS_COMPILE support

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

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

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

[PATCH 03/30] kbuild: remove CONFIG_CROSS_COMPILE support

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

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

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

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

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.

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

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

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

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.

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

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.

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

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.

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

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

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

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

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

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

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

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

[PATCH 02/30] kbuild: remove kbuild cache

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

[PATCH 02/30] kbuild: remove kbuild cache

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

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

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

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

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

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

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

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

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

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

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

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

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(-)

Re: KMSAN: uninit-value in __netif_receive_skb_core

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:

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

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

Re: KMSAN: uninit-value in __netif_receive_skb_core

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:

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

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 ---

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

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 ---

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

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

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

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

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

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

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

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

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

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

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

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

[PATCH 24/30] gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT

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

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

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 ---

[PATCH 24/30] gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [RFC v2] virtio: support packed ring

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

Re: [RFC v2] virtio: support packed ring

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

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

> 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

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

> 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

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

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.

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

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

Re: [PATCH] f2fs: enlarge block plug coverage

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: >

Re: [PATCH] f2fs: enlarge block plug coverage

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: >

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

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

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

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

  1   2   3   4   5   6   7   8   9   10   >