* Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
From: Sedat Dilek @ 2016-06-13 8:40 UTC (permalink / raw)
To: Kees Cook
Cc: Michal Marek, Stephen Rothwell, Emese Revfy, Paul Gortmaker,
Sudip Mukherjee, Linux-Next, LKML, kernel-hardening
In-Reply-To: <20160611161212.GA29370@www.outflux.net>
On Sat, Jun 11, 2016 at 6:12 PM, Kees Cook <keescook@chromium.org> wrote:
> Since adding the gcc plugin development headers is required for the
> gcc plugin support, we should ease into this new kernel build dependency
> more slowly. For now, disable the gcc plugins under COMPILE_TEST so that
> all*config builds will skip it.
>
[ This might be a bit off-topic - Feel free to answer ]
Hi,
I want to try that new "GCC-plugin" feature.
Do you have a Git repo for "easy-testing"?
Does the kernel's build-system check for installed "gcc-plugin
development headers"?
Which GCC versions support "gcc-plugin" feature?
I am here on Ubuntu/precise AMD64 and have gcc-4.6.4 and gcc-4.9.2.
[ Optional ]
What about the topic and support for "LLVM/Clang and hardening" of the
Linux-kernel?
Regards,
- Sedat -
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/Kconfig | 1 +
> lib/Kconfig.debug | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 83aa2a3c470d..3f06d678b1d7 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -366,6 +366,7 @@ config HAVE_GCC_PLUGINS
> menuconfig GCC_PLUGINS
> bool "GCC plugins"
> depends on HAVE_GCC_PLUGINS
> + 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.
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d40833b9b7f4..0f9981999a27 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -713,8 +713,8 @@ config KCOV
> bool "Code coverage for fuzzing"
> depends on ARCH_HAS_KCOV
> select DEBUG_FS
> - select GCC_PLUGINS
> - select GCC_PLUGIN_SANCOV
> + select GCC_PLUGINS if !COMPILE_TEST
> + select GCC_PLUGIN_SANCOV if !COMPILE_TEST
> help
> KCOV exposes kernel code coverage information in a form suitable
> for coverage-guided fuzzing (randomized testing).
> --
> 2.7.4
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
From: Sudip Mukherjee @ 2016-06-13 7:52 UTC (permalink / raw)
To: Kees Cook
Cc: Michal Marek, Stephen Rothwell, Emese Revfy, Paul Gortmaker,
Linux-Next, linux-kernel, kernel-hardening
In-Reply-To: <20160611161212.GA29370@www.outflux.net>
On Sat, Jun 11, 2016 at 09:12:12AM -0700, Kees Cook wrote:
> Since adding the gcc plugin development headers is required for the
> gcc plugin support, we should ease into this new kernel build dependency
> more slowly. For now, disable the gcc plugins under COMPILE_TEST so that
> all*config builds will skip it.
But don't you think that people who are actually building the kernel
with allmodconfig or allyesconfig and/or with COMPILE_TEST enabled are
just doing that to build test the kernel. Atleast for me, when I am
testing i will always do allmodconfig but when I am building which is
to be deployed somewhere then I am building with a particular config.
Regards
Sudip
^ permalink raw reply
* Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
From: Emese Revfy @ 2016-06-13 0:18 UTC (permalink / raw)
To: Kees Cook
Cc: Paul Gortmaker, Michal Marek, Stephen Rothwell, Sudip Mukherjee,
Linux-Next, LKML, kernel-hardening@lists.openwall.com
In-Reply-To: <CAGXu5jJ_+azG6H0tB7W0mJTUzXp18Y7qN7dx7EEKng+0nO-dig@mail.gmail.com>
On Sun, 12 Jun 2016 15:25:39 -0700
Kees Cook <keescook@chromium.org> wrote:
> I don't like this because it means if someone specifically selects
> some plugins in their .config, and the headers are missing, the kernel
> will successfully compile. For many plugins, this results in a kernel
> that lacks the requested security features, and that I really do not
> want to have happening. I'm okay leaving these disabled for compile
> tests for now. We can revisit this once more distros have plugins
> enabled by default.
You are right. Your patch is safer.
--
Emese
^ permalink raw reply
* Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
From: Kees Cook @ 2016-06-12 22:25 UTC (permalink / raw)
To: Emese Revfy
Cc: Paul Gortmaker, Michal Marek, Stephen Rothwell, Sudip Mukherjee,
Linux-Next, LKML, kernel-hardening@lists.openwall.com
In-Reply-To: <20160613001244.b4b3c675d59e3ad3d8d656a4@gmail.com>
On Sun, Jun 12, 2016 at 3:12 PM, Emese Revfy <re.emese@gmail.com> wrote:
> On Sat, 11 Jun 2016 12:29:26 -0400
> Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
>
>> [[PATCH] gcc-plugins: disable under COMPILE_TEST] On 11/06/2016 (Sat 09:12) Kees Cook wrote:
>>
>> > Since adding the gcc plugin development headers is required for the
>> > gcc plugin support, we should ease into this new kernel build dependency
>> > more slowly. For now, disable the gcc plugins under COMPILE_TEST so that
>> > all*config builds will skip it.
>>
>> Wouldn't it be better to test compile a one line program that tries to
>> source the header(s) and then react accordingly?
>
> The scripts/gcc-plugin.sh script does exactly that.
>
>> Then at least you would get the test coverage from people who have the
>> headers installed who are doing all[yes|mod]config. This "for now"
>> solution doesn't really have a path forward other than assuming all
>> distros install the plugin headers sometime in the future.
>>
>> Either way, this is an improvement over the current situation, so thanks
>> for that.
>
> If it is not too late I think this patch would be better:
I don't like this because it means if someone specifically selects
some plugins in their .config, and the headers are missing, the kernel
will successfully compile. For many plugins, this results in a kernel
that lacks the requested security features, and that I really do not
want to have happening. I'm okay leaving these disabled for compile
tests for now. We can revisit this once more distros have plugins
enabled by default.
-Kees
>
>
> When there is no gcc plugin support then don't compile the plugins
> (but still print a warning). This allows building allyes/allmod configs
> until the gcc plugin headers get installed.
>
> Signed-off-by: Emese Revfy <re.emese@gmail.com>
> ---
> Makefile | 6 +++---
> scripts/Makefile.gcc-plugins | 8 ++++----
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index a49c075..715210c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -623,15 +623,15 @@ endif
> # Tell gcc to never replace conditional load with a non-conditional one
> KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
>
> +include scripts/Makefile.gcc-plugins
> +
> PHONY += gcc-plugins
> gcc-plugins: scripts_basic
> -ifdef CONFIG_GCC_PLUGINS
> +ifneq ($(GCC_PLUGINS_CFLAGS),)
> $(Q)$(MAKE) $(build)=scripts/gcc-plugins
> endif
> @:
>
> -include scripts/Makefile.gcc-plugins
> -
> ifdef CONFIG_READABLE_ASM
> # Disable optimizations that make assembler listings hard to read.
> # reorder blocks reorders the control in the function
> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
> index c7372cb..2f101ea 100644
> --- a/scripts/Makefile.gcc-plugins
> +++ b/scripts/Makefile.gcc-plugins
> @@ -21,6 +21,7 @@ ifdef CONFIG_GCC_PLUGINS
> CFLAGS_KCOV := $(SANCOV_PLUGIN)
> else
> $(warning warning: cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler)
> + CFLAGS_KCOV =
> endif
> endif
> endif
> @@ -37,13 +38,12 @@ ifdef CONFIG_GCC_PLUGINS
> else
> $(warning warning: your gcc version does not support plugins, you should upgrade it to gcc 4.5 at least)
> endif
> + GCC_PLUGINS_CFLAGS =
> endif
> - else
> - # SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
> - GCC_PLUGINS_CFLAGS := $(filter-out $(SANCOV_PLUGIN), $(GCC_PLUGINS_CFLAGS))
> endif
>
> - KBUILD_CFLAGS += $(GCC_PLUGINS_CFLAGS)
> + # SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
> + KBUILD_CFLAGS += $(filter-out $(SANCOV_PLUGIN), $(GCC_PLUGINS_CFLAGS))
> GCC_PLUGIN := $(gcc-plugin-y)
>
> endif
>
> --
> 2.8.1
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply
* Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
From: Emese Revfy @ 2016-06-12 22:12 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Kees Cook, Michal Marek, Stephen Rothwell, Sudip Mukherjee,
Linux-Next, linux-kernel, kernel-hardening
In-Reply-To: <20160611162926.GL12567@windriver.com>
On Sat, 11 Jun 2016 12:29:26 -0400
Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> [[PATCH] gcc-plugins: disable under COMPILE_TEST] On 11/06/2016 (Sat 09:12) Kees Cook wrote:
>
> > Since adding the gcc plugin development headers is required for the
> > gcc plugin support, we should ease into this new kernel build dependency
> > more slowly. For now, disable the gcc plugins under COMPILE_TEST so that
> > all*config builds will skip it.
>
> Wouldn't it be better to test compile a one line program that tries to
> source the header(s) and then react accordingly?
The scripts/gcc-plugin.sh script does exactly that.
> Then at least you would get the test coverage from people who have the
> headers installed who are doing all[yes|mod]config. This "for now"
> solution doesn't really have a path forward other than assuming all
> distros install the plugin headers sometime in the future.
>
> Either way, this is an improvement over the current situation, so thanks
> for that.
If it is not too late I think this patch would be better:
When there is no gcc plugin support then don't compile the plugins
(but still print a warning). This allows building allyes/allmod configs
until the gcc plugin headers get installed.
Signed-off-by: Emese Revfy <re.emese@gmail.com>
---
Makefile | 6 +++---
scripts/Makefile.gcc-plugins | 8 ++++----
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index a49c075..715210c 100644
--- a/Makefile
+++ b/Makefile
@@ -623,15 +623,15 @@ endif
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
+include scripts/Makefile.gcc-plugins
+
PHONY += gcc-plugins
gcc-plugins: scripts_basic
-ifdef CONFIG_GCC_PLUGINS
+ifneq ($(GCC_PLUGINS_CFLAGS),)
$(Q)$(MAKE) $(build)=scripts/gcc-plugins
endif
@:
-include scripts/Makefile.gcc-plugins
-
ifdef CONFIG_READABLE_ASM
# Disable optimizations that make assembler listings hard to read.
# reorder blocks reorders the control in the function
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index c7372cb..2f101ea 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -21,6 +21,7 @@ ifdef CONFIG_GCC_PLUGINS
CFLAGS_KCOV := $(SANCOV_PLUGIN)
else
$(warning warning: cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler)
+ CFLAGS_KCOV =
endif
endif
endif
@@ -37,13 +38,12 @@ ifdef CONFIG_GCC_PLUGINS
else
$(warning warning: your gcc version does not support plugins, you should upgrade it to gcc 4.5 at least)
endif
+ GCC_PLUGINS_CFLAGS =
endif
- else
- # SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
- GCC_PLUGINS_CFLAGS := $(filter-out $(SANCOV_PLUGIN), $(GCC_PLUGINS_CFLAGS))
endif
- KBUILD_CFLAGS += $(GCC_PLUGINS_CFLAGS)
+ # SANCOV_PLUGIN can be only in CFLAGS_KCOV because avoid duplication.
+ KBUILD_CFLAGS += $(filter-out $(SANCOV_PLUGIN), $(GCC_PLUGINS_CFLAGS))
GCC_PLUGIN := $(gcc-plugin-y)
endif
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] Fix reported kmemleak
From: Xiong Zhou @ 2016-06-12 10:29 UTC (permalink / raw)
To: Shaun Tancheff
Cc: linux-block, Christoph Hellwig, axboe, David Drysdale, Xiong Zhou,
Stephen Rothwell, linux-next, linux-nvdimm, Larry Finger,
Catalin Marinas, LKML, Jens Axboe, bart.vanassche
In-Reply-To: <1465316612-9649-1-git-send-email-shaun@tancheff.com>
Hi,
On Tue, Jun 07, 2016 at 11:23:30AM -0500, Shaun Tancheff wrote:
> This fixes a memory leak reported by a few people in 4.7-rc1
>
> kmemleak report after 9082e87bfbf8 ("block: remove struct bio_batch")
>
> This patch just formalizes the one in this discussion here:
> https://lkml.kernel.org/r/20160606112620.GA29910@e104818-lin.cambridge.arm.com
>
> The same issue appears here:
> https://lkml.kernel.org/r/20160607102651.GA6480@dhcp12-144.nay.redhat.com
>
> Patch is also available at:
>
> https://github.com/stancheff/linux.git
> branch: v4.7-rc2+bio_put
>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: axboe@kernel.dk
> cc: David Drysdale <drysdale@google.com>
> Cc: Xiong Zhou <xzhou@redhat.com>
Thanks for the information!
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: linux-next@vger.kernel.org
> Cc: linux-nvdimm@ml01.01.org
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: LKML <linux-kernel@vger.kernel.org>,
> Cc: Jens Axboe <axboe@fb.com>,
> Cc: bart.vanassche@sandisk.com
>
> Shaun Tancheff (1):
> Missing bio_put following submit_bio_wait
>
> block/blk-lib.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> --
> 2.8.1
>
^ permalink raw reply
* Re: [PATCH] Add .set_antenna callback in ath6kl driver to remove wireless core warns
From: kbuild test robot @ 2016-06-11 20:35 UTC (permalink / raw)
To: Prasun Maiti
Cc: kbuild-all, Linux Kernel, Kalle Valo, ath6kl@lists.infradead.org,
Linux Next, Linux Wireless, Linux Kernel
In-Reply-To: <1465388474-20503-1-git-send-email-prasunmaiti87@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
Hi,
[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.7-rc2 next-20160609]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Prasun-Maiti/Add-set_antenna-callback-in-ath6kl-driver-to-remove-wireless-core-warns/20160608-202420
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/wireless/ath/ath6kl/wmi.c: In function 'ath6kl_wmi_set_antenna':
>> drivers/net/wireless/ath/ath6kl/wmi.c:1618:6: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types]
cmd = (struct wmi_set_antenna_cmd *) skb->data;
^
drivers/net/wireless/ath/ath6kl/wmi.c:1619:5: error: 'struct wmi_txe_notify_cmd' has no member named 'tx_ant'
cmd->tx_ant = cpu_to_le32(tx_ant);
^~
drivers/net/wireless/ath/ath6kl/wmi.c:1620:5: error: 'struct wmi_txe_notify_cmd' has no member named 'rx_ant'
cmd->rx_ant = cpu_to_le32(rx_ant);
^~
cc1: some warnings being treated as errors
vim +1618 drivers/net/wireless/ath/ath6kl/wmi.c
1612 struct wmi_txe_notify_cmd *cmd;
1613
1614 skb = ath6kl_wmi_get_new_buf(sizeof(*cmd));
1615 if (!skb)
1616 return -ENOMEM;
1617
> 1618 cmd = (struct wmi_set_antenna_cmd *) skb->data;
1619 cmd->tx_ant = cpu_to_le32(tx_ant);
1620 cmd->rx_ant = cpu_to_le32(rx_ant);
1621
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 54116 bytes --]
^ permalink raw reply
* Re: [PATCH] Add .set_antenna callback in ath6kl driver to remove wireless core warns
From: kbuild test robot @ 2016-06-11 20:33 UTC (permalink / raw)
To: Prasun Maiti
Cc: kbuild-all, Linux Kernel, Kalle Valo, ath6kl@lists.infradead.org,
Linux Next, Linux Wireless, Linux Kernel
In-Reply-To: <1465388474-20503-1-git-send-email-prasunmaiti87@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1916 bytes --]
Hi,
[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.7-rc2 next-20160609]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Prasun-Maiti/Add-set_antenna-callback-in-ath6kl-driver-to-remove-wireless-core-warns/20160608-202420
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc
All errors (new ones prefixed by >>):
drivers/net/wireless/ath/ath6kl/cfg80211.c: In function 'ath6kl_set_antenna':
>> drivers/net/wireless/ath/ath6kl/cfg80211.c:3253:2: error: implicit declaration of function 'ath6kl_wmi_set_antenna'
--
drivers/net/wireless/ath/ath6kl/wmi.c: In function 'ath6kl_wmi_set_antenna':
drivers/net/wireless/ath/ath6kl/wmi.c:1618:6: warning: assignment from incompatible pointer type
>> drivers/net/wireless/ath/ath6kl/wmi.c:1619:5: error: 'struct wmi_txe_notify_cmd' has no member named 'tx_ant'
>> drivers/net/wireless/ath/ath6kl/wmi.c:1620:5: error: 'struct wmi_txe_notify_cmd' has no member named 'rx_ant'
vim +/ath6kl_wmi_set_antenna +3253 drivers/net/wireless/ath/ath6kl/cfg80211.c
3247 if (!tx_ant || !rx_ant)
3248 return -EINVAL;
3249
3250 ar->hw.tx_ant = tx_ant;
3251 ar->hw.rx_ant = rx_ant;
3252
> 3253 return ath6kl_wmi_set_antenna(ar->wmi, vif->fw_vif_idx,
3254 tx_ant, rx_ant);
3255 }
3256
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 37375 bytes --]
^ permalink raw reply
* Re: [PATCH] gcc-plugins: disable under COMPILE_TEST
From: Paul Gortmaker @ 2016-06-11 16:29 UTC (permalink / raw)
To: Kees Cook
Cc: Michal Marek, Stephen Rothwell, Emese Revfy, Sudip Mukherjee,
Linux-Next, linux-kernel, kernel-hardening
In-Reply-To: <20160611161212.GA29370@www.outflux.net>
[[PATCH] gcc-plugins: disable under COMPILE_TEST] On 11/06/2016 (Sat 09:12) Kees Cook wrote:
> Since adding the gcc plugin development headers is required for the
> gcc plugin support, we should ease into this new kernel build dependency
> more slowly. For now, disable the gcc plugins under COMPILE_TEST so that
> all*config builds will skip it.
Wouldn't it be better to test compile a one line program that tries to
source the header(s) and then react accordingly?
Then at least you would get the test coverage from people who have the
headers installed who are doing all[yes|mod]config. This "for now"
solution doesn't really have a path forward other than assuming all
distros install the plugin headers sometime in the future.
Either way, this is an improvement over the current situation, so thanks
for that.
Paul.
--
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/Kconfig | 1 +
> lib/Kconfig.debug | 4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 83aa2a3c470d..3f06d678b1d7 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -366,6 +366,7 @@ config HAVE_GCC_PLUGINS
> menuconfig GCC_PLUGINS
> bool "GCC plugins"
> depends on HAVE_GCC_PLUGINS
> + 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.
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d40833b9b7f4..0f9981999a27 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -713,8 +713,8 @@ config KCOV
> bool "Code coverage for fuzzing"
> depends on ARCH_HAS_KCOV
> select DEBUG_FS
> - select GCC_PLUGINS
> - select GCC_PLUGIN_SANCOV
> + select GCC_PLUGINS if !COMPILE_TEST
> + select GCC_PLUGIN_SANCOV if !COMPILE_TEST
> help
> KCOV exposes kernel code coverage information in a form suitable
> for coverage-guided fuzzing (randomized testing).
> --
> 2.7.4
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security
^ permalink raw reply
* [PATCH] gcc-plugins: disable under COMPILE_TEST
From: Kees Cook @ 2016-06-11 16:12 UTC (permalink / raw)
To: Michal Marek
Cc: Stephen Rothwell, Emese Revfy, Paul Gortmaker, Sudip Mukherjee,
Linux-Next, linux-kernel, kernel-hardening
Since adding the gcc plugin development headers is required for the
gcc plugin support, we should ease into this new kernel build dependency
more slowly. For now, disable the gcc plugins under COMPILE_TEST so that
all*config builds will skip it.
Signed-off-by: Kees Cook <keescook@chromium.org>
---
arch/Kconfig | 1 +
lib/Kconfig.debug | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 83aa2a3c470d..3f06d678b1d7 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -366,6 +366,7 @@ config HAVE_GCC_PLUGINS
menuconfig GCC_PLUGINS
bool "GCC plugins"
depends on HAVE_GCC_PLUGINS
+ 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.
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d40833b9b7f4..0f9981999a27 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -713,8 +713,8 @@ config KCOV
bool "Code coverage for fuzzing"
depends on ARCH_HAS_KCOV
select DEBUG_FS
- select GCC_PLUGINS
- select GCC_PLUGIN_SANCOV
+ select GCC_PLUGINS if !COMPILE_TEST
+ select GCC_PLUGIN_SANCOV if !COMPILE_TEST
help
KCOV exposes kernel code coverage information in a form suitable
for coverage-guided fuzzing (randomized testing).
--
2.7.4
--
Kees Cook
Chrome OS & Brillo Security
^ permalink raw reply related
* Re: linux-next: Tree for Jun 9
From: Paul Gortmaker @ 2016-06-11 1:05 UTC (permalink / raw)
To: Kees Cook
Cc: Sudip Mukherjee, Stephen Rothwell, Linux-Next, LKML, Emese Revfy,
kernel-hardening@lists.openwall.com
In-Reply-To: <CAGXu5jJbzUueFvrBJvP3qhprKQ95fZqfgo08VvyG5HETL0a4Sw@mail.gmail.com>
On Thu, Jun 9, 2016 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jun 9, 2016 at 3:06 PM, Sudip Mukherjee
> <sudipm.mukherjee@gmail.com> wrote:
[...]
>> While trying to build x86_64 allmodconfig I am getting:
>> ++ dirname ../scripts/gcc-plugin.sh
>> + srctree=../scripts
>> ++ gcc -print-file-name=plugin
>> + gccplugins_dir=plugin
>> ++ g++ -E -x c++ - -o /dev/null -I../scripts/gcc-plugins -Iplugin/include
>> + plugincc='In file included from <stdin>:1:0:
>> ../scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such
>> file or directory
>> #include "bversion.h"
>> ^
>> compilation terminated.'
>> + '[' 1 -ne 0 ']'
>> + exit 1
>>
>> build log is at:
>> https://travis-ci.org/sudipm-mukherjee/parport/jobs/136350824
>>
>> Looks like 6b90bd4ba40b ("GCC plugin infrastructure") is the problem.
I also ran into this and immediately came to look in the linux-next
e-mail discussions, since I was sure this had to be widespread...
> Hi, yes, if you want to be testing the GCC plugins, you'll need the
> gcc plugin headers installed. On Debian and Ubuntu, they can be found
> like this:
...but I think this misses the point completely. I have my queue of patches
that I regularly test against the daily linux-next. I have no interest at this
point in time about the gcc plugins. I just want to fetch linux-next, apply
my patches and for a set of architectures, do an "allmodconfig" and build.
After the plugin commits, I can't even build the native (i386 and x86_64)
allmodconfig arch to build test my work. And this is on a generic common
distro install. People may not have admin access on their build machines
so you can't just say ...
> $ apt-cache search gcc | grep plugin-dev
> gcc-5-plugin-dev - Files for GNU GCC plugin development.
> gcc-4.7-plugin-dev - Files for GNU GCC plugin development.
> gcc-4.8-plugin-dev - Files for GNU GCC plugin development.
> gcc-4.9-plugin-dev - Files for GNU GCC plugin development.
...install the above packages. Just like some of the other features with
dependencies, this needs to warn and self-disable, It can't be breaking
existing work flows that people rely on. An example of warn and continue:
Makefile:689: Cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is
not supported by compiler
I have locally reverted the three gcc-plugin commits so I can continue to
test my pending work on linux-next, but please do give the above some
consideration vs. forcing everyone else to do the same 3 reverts.
Thanks,
Paul.
--
>
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
From: Andrew Morton @ 2016-06-10 21:59 UTC (permalink / raw)
To: mhocko
Cc: Sergey Senozhatsky, Christoph Lameter, Michal Hocko,
Vlastimil Babka, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Sergey Senozhatsky, linux-kernel-owner
In-Reply-To: <477de582bf99ba64be662a42bf023b54@suse.de>
On Fri, 10 Jun 2016 11:55:54 +0200 mhocko <mhocko@suse.de> wrote:
> On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > Hello,
> >
> > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> >
> > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > context: local IRQs disabled in slab_alloc().
>
> I have sent a patch to drop the BUG() from that path today. It
> is just too aggressive way to react to a non-critical bug.
> See
> http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
Doesn't this simply mean that Sergey's workload will blurt a pr_warn()
rather than a BUG()? That still needs fixing. Confused.
^ permalink raw reply
* Re: linux-next: manual merge of the device-mapper tree with the block tree
From: Mike Snitzer @ 2016-06-10 17:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Alasdair G Kergon, Jens Axboe, linux-next, linux-kernel
In-Reply-To: <20160609140253.183a1428@canb.auug.org.au>
On Thu, Jun 09 2016 at 12:02am -0400,
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Thu, 9 Jun 2016 13:59:32 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > 50d14ab0130a ("dm: move request-based code out to dm-rq.[hc]")
>
> By the way, resolving these conflicts would have been easier if this
> commit had been split into "move with no changes" followed by "small
> changes" commits.
Yeap, I understand. I've folded your fix into the appropriate commit
and rebased DM's for-next (and dm-4.8) ontop of block's for-4.8/core.
Thanks,
Mike
^ permalink raw reply
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
From: Sergey Senozhatsky @ 2016-06-10 9:58 UTC (permalink / raw)
To: mhocko
Cc: Sergey Senozhatsky, Christoph Lameter, Michal Hocko,
Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky, linux-kernel-owner
In-Reply-To: <477de582bf99ba64be662a42bf023b54@suse.de>
On (06/10/16 11:55), mhocko wrote:
> On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> > Hello,
> >
> > forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
> >
> > new_slab()->BUG->die()->exit_signals() can be called from atomic
> > context: local IRQs disabled in slab_alloc().
>
> I have sent a patch to drop the BUG() from that path today. It
> is just too aggressive way to react to a non-critical bug.
> See
> http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
ah, ok. didn't see that one.
thanks.
-ss
^ permalink raw reply
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
From: mhocko @ 2016-06-10 9:55 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Christoph Lameter, Michal Hocko, Andrew Morton, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky, linux-kernel-owner
In-Reply-To: <20160610095048.GA655@swordfish>
On 2016-06-10 11:50, Sergey Senozhatsky wrote:
> Hello,
>
> forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
>
> new_slab()->BUG->die()->exit_signals() can be called from atomic
> context: local IRQs disabled in slab_alloc().
I have sent a patch to drop the BUG() from that path today. It
is just too aggressive way to react to a non-critical bug.
See
http://lkml.kernel.org/r/1465548200-11384-2-git-send-email-mhocko@kernel.org
--
Michal Hocko
^ permalink raw reply
* Re: [mmots-2016-06-09-16-49] sleeping function called from slab_alloc()
From: Sergey Senozhatsky @ 2016-06-10 9:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: Michal Hocko, Andrew Morton, Vlastimil Babka, Stephen Rothwell,
linux-mm, linux-next, linux-kernel, Sergey Senozhatsky,
Sergey Senozhatsky
In-Reply-To: <20160610061139.GA374@swordfish>
Hello,
forked from http://marc.info/?l=linux-mm&m=146553910928716&w=2
new_slab()->BUG->die()->exit_signals() can be called from atomic
context: local IRQs disabled in slab_alloc().
[ 429.232059] BUG: sleeping function called from invalid context at include/linux/sched.h:2960
[ 429.232719] in_atomic(): 0, irqs_disabled(): 1, pid: 562, name: gzip
[ 429.233376] INFO: lockdep is turned off.
[ 429.234034] irq event stamp: 1994762
[ 429.234697] hardirqs last enabled at (1994761): [<ffffffff8113f360>] __find_get_block+0xd9/0x117
[ 429.235360] hardirqs last disabled at (1994762): [<ffffffff81105516>] __slab_alloc.isra.18.constprop.22+0x20/0x6d
[ 429.236026] softirqs last enabled at (1994554): [<ffffffff81040285>] __do_softirq+0x1bc/0x217
[ 429.236694] softirqs last disabled at (1994535): [<ffffffff810404ba>] irq_exit+0x3b/0x8f
[ 429.237360] CPU: 0 PID: 562 Comm: gzip Tainted: G D 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.238708] 0000000000000000 ffff88009434f520 ffffffff811e632c 0000000000000000
[ 429.239397] ffff8800bf8e3a80 ffff88009434f548 ffffffff810598c8 ffffffff8174b8c3
[ 429.240077] 0000000000000b90 0000000000000000 ffff88009434f570 ffffffff8105993f
[ 429.240757] Call Trace:
[ 429.241433] [<ffffffff811e632c>] dump_stack+0x68/0x92
[ 429.242113] [<ffffffff810598c8>] ___might_sleep+0x1fb/0x202
[ 429.242816] [<ffffffff8105993f>] __might_sleep+0x70/0x77
[ 429.243493] [<ffffffff810487a0>] exit_signals+0x1e/0x119
[ 429.244168] [<ffffffff8103eec3>] do_exit+0x111/0x8f8
[ 429.244844] [<ffffffff8107da75>] ? kmsg_dump+0x149/0x154
[ 429.245525] [<ffffffff81014a03>] oops_end+0x9d/0xa4
[ 429.246200] [<ffffffff81014b27>] die+0x55/0x5e
[ 429.246868] [<ffffffff81012450>] do_trap+0x67/0x11d
[ 429.247538] [<ffffffff8101272d>] do_error_trap+0x100/0x10f
[ 429.248212] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.248878] [<ffffffff8107c870>] ? wake_up_klogd+0x4e/0x61
[ 429.249544] [<ffffffff8107ccda>] ? console_unlock+0x457/0x4a2
[ 429.250202] [<ffffffff81001036>] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 429.250856] [<ffffffff81012889>] do_invalid_op+0x1b/0x1d
[ 429.251508] [<ffffffff814a5e25>] invalid_op+0x15/0x20
[ 429.252158] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.252803] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.253451] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.254102] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.254740] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.255376] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.256012] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.256657] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.257292] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.257959] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.258592] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.259226] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.259849] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.260432] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.261024] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.261614] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.262185] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.262753] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.263320] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.263887] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.264447] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.265017] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.265575] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.266135] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.266691] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.267240] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.267798] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.268345] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.268896] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.269438] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.269976] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.270518] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.271057] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
-ss
^ permalink raw reply
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
From: Michal Hocko @ 2016-06-10 7:42 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky
In-Reply-To: <20160610072459.GA585@swordfish>
On Fri 10-06-16 16:24:59, Sergey Senozhatsky wrote:
> that was fast!
>
> On (06/10/16 08:34), Michal Hocko wrote:
> [..]
> > OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> > ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> > I think we need the following. Andrew could you fold it into
> > mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> > it as a separate patch?
> >
> > [1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
> >
> > Thanks for the report Sergey!
>
> after quick tests -- works for me. please see below.
[...]
> so the first bio_alloc() is ok now. what about the second bio_alloc()
> in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?
Sure, early morning for me... Thanks for catching that.
---
>From a2712312c0a36506ba003747c593dfbdf8eaa8be Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Fri, 10 Jun 2016 08:27:33 +0200
Subject: [PATCH] mm: restrict gfp mask in mpage_alloc
Sergey has reported that we might hit BUG_ON in new_slab() because
unrestricted gfp mask used for the readahead purposes contains
incompatible flags (__GFP_HIGHMEM in his case):
[ 429.191962] gfp: 2
[ 429.192634] ------------[ cut here ]------------
[ 429.193281] kernel BUG at mm/slub.c:1616!
[...]
[ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
Make sure that mpage_alloc always restricts the mask to GFP_KERNEL subset.
This is what was done before "mm, memcg: use consistent gfp flags during
readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
mpage_readpages.
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
fs/mpage.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/mpage.c b/fs/mpage.c
index 9c11255b0797..c8a05901a37b 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -71,6 +71,8 @@ mpage_alloc(struct block_device *bdev,
{
struct bio *bio;
+ /* Restrict the given (page cache) mask for slab allocations */
+ gfp_flags &= GFP_KERNEL;
bio = bio_alloc(gfp_flags, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
--
2.8.1
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
From: Sergey Senozhatsky @ 2016-06-10 7:24 UTC (permalink / raw)
To: Michal Hocko
Cc: Sergey Senozhatsky, Andrew Morton, Vlastimil Babka,
Stephen Rothwell, linux-mm, linux-next, linux-kernel,
Sergey Senozhatsky
In-Reply-To: <20160610063419.GB32285@dhcp22.suse.cz>
that was fast!
On (06/10/16 08:34), Michal Hocko wrote:
[..]
> OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
> ___GFP_HIGHMEM. It is my [1] patch which has introduced it.
> I think we need the following. Andrew could you fold it into
> mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
> it as a separate patch?
>
> [1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
>
> Thanks for the report Sergey!
after quick tests -- works for me. please see below.
> Sergey has reported that we might hit BUG_ON in new_slab() because
> unrestricted gfp mask used for the readahead purposes contains
> incompatible flags (__GFP_HIGHMEM in his case):
> [ 429.191962] gfp: 2
> [ 429.192634] ------------[ cut here ]------------
> [ 429.193281] kernel BUG at mm/slub.c:1616!
> [...]
> [ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
> [ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
> [ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
> [ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
>
> Make sure that mpage_alloc always restricts the mask GFP_KERNEL subset.
> This is what was done before "mm, memcg: use consistent gfp flags during
> readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
> mpage_readpages.
>
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
> fs/mpage.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/mpage.c b/fs/mpage.c
> index 9c11255b0797..5ce75b2e60d1 100644
> --- a/fs/mpage.c
> +++ b/fs/mpage.c
> @@ -71,7 +71,7 @@ mpage_alloc(struct block_device *bdev,
> {
> struct bio *bio;
>
> - bio = bio_alloc(gfp_flags, nr_vecs);
> + bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
>
> if (bio == NULL && (current->flags & PF_MEMALLOC)) {
> while (!bio && (nr_vecs /= 2))
so the first bio_alloc() is ok now. what about the second bio_alloc()
in mpage_alloc()? it'll still see the ___GFP_HIGHMEM?
may be something like this (composed in mail client)
static struct bio *
mpage_alloc(struct block_device *bdev,
sector_t first_sector, int nr_vecs,
gfp_t gfp_flags)
{
struct bio *bio;
+ gfp_flags &= GFP_KERNEL;
- bio = bio_alloc(gfp_flags, nr_vecs);
+ bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
while (!bio && (nr_vecs /= 2))
bio = bio_alloc(gfp_flags, nr_vecs);
^^^^^^^^^^^^^^^^^^^^ BUG?
}
if (bio) {
bio->bi_bdev = bdev;
bio->bi_iter.bi_sector = first_sector;
}
return bio;
}
=====
the second part of the original report (sleeping function called from
invalid context at include/linux/sched.h:2960) is unrelated, I'll fork
a new thread; seems that it's coming from a380a3c755, Christoph Lameter,
2015-11-20.
-ss
^ permalink raw reply
* Re: [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
From: Michal Hocko @ 2016-06-10 6:34 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Andrew Morton, Vlastimil Babka, Stephen Rothwell, linux-mm,
linux-next, linux-kernel, Sergey Senozhatsky
In-Reply-To: <20160610061139.GA374@swordfish>
On Fri 10-06-16 15:11:39, Sergey Senozhatsky wrote:
> Hello,
>
> [ 429.191962] gfp: 2
> [ 429.192634] ------------[ cut here ]------------
> [ 429.193281] kernel BUG at mm/slub.c:1616!
[...]
> [ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
> [ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
> [ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
> [ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
OK, so this is flags & GFP_SLAB_BUG_MASK BUG_ON because gfp is
___GFP_HIGHMEM. It is my [1] patch which has introduced it.
I think we need the following. Andrew could you fold it into
mm-memcg-use-consistent-gfp-flags-during-readahead.patch or maybe keep
it as a separate patch?
[1] http://lkml.kernel.org/r/1465301556-26431-1-git-send-email-mhocko@kernel.org
Thanks for the report Sergey!
---
>From 89cfc9bf27b9b5af47fece7eab36deb2fb04516d Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Fri, 10 Jun 2016 08:27:33 +0200
Subject: [PATCH] mm: restrict gfp mask in mpage_alloc
Sergey has reported that we might hit BUG_ON in new_slab() because
unrestricted gfp mask used for the readahead purposes contains
incompatible flags (__GFP_HIGHMEM in his case):
[ 429.191962] gfp: 2
[ 429.192634] ------------[ cut here ]------------
[ 429.193281] kernel BUG at mm/slub.c:1616!
[...]
[ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
Make sure that mpage_alloc always restricts the mask GFP_KERNEL subset.
This is what was done before "mm, memcg: use consistent gfp flags during
readahead" explicitly by mapping_gfp_constraint(mapping, GFP_KERNEL) in
mpage_readpages.
Reported-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
fs/mpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/mpage.c b/fs/mpage.c
index 9c11255b0797..5ce75b2e60d1 100644
--- a/fs/mpage.c
+++ b/fs/mpage.c
@@ -71,7 +71,7 @@ mpage_alloc(struct block_device *bdev,
{
struct bio *bio;
- bio = bio_alloc(gfp_flags, nr_vecs);
+ bio = bio_alloc(gfp_flags & GFP_KERNEL, nr_vecs);
if (bio == NULL && (current->flags & PF_MEMALLOC)) {
while (!bio && (nr_vecs /= 2))
--
2.8.1
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* [mmots-2016-06-09-16-49] kernel BUG at mm/slub.c:1616
From: Sergey Senozhatsky @ 2016-06-10 6:11 UTC (permalink / raw)
To: Michal Hocko, Andrew Morton
Cc: Vlastimil Babka, Stephen Rothwell, linux-mm, linux-next,
linux-kernel, Sergey Senozhatsky, Sergey Senozhatsky
Hello,
[ 429.191962] gfp: 2
[ 429.192634] ------------[ cut here ]------------
[ 429.193281] kernel BUG at mm/slub.c:1616!
[ 429.193920] invalid opcode: 0000 [#1] PREEMPT SMP
[ 429.194556] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_pcm snd_timer snd soundcore coretemp hwmon mousedev r8169 i2c_i801 crc32c_intel mii lpc_ich mfd_core acpi_cpufreq processor sch_fq_codel uas usb_storage hid_generi
c usbhid hid sd_mod ahci libahci libata scsi_mod ehci_pci ehci_hcd usbcore usb_common
[ 429.196008] CPU: 0 PID: 562 Comm: gzip Not tainted 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.197385] task: ffff8800bf8e3a80 ti: ffff88009434c000 task.ti: ffff88009434c000
[ 429.198082] RIP: 0010:[<ffffffff811036a5>] [<ffffffff811036a5>] new_slab+0x25/0x2be
[ 429.198782] RSP: 0018:ffff88009434f820 EFLAGS: 00010082
[ 429.199475] RAX: 0000000000000006 RBX: 0000000000000000 RCX: 0000000000000001
[ 429.200173] RDX: ffff880137c10401 RSI: ffffffff81796bf9 RDI: 00000000ffffffff
[ 429.200871] RBP: ffff88009434f850 R08: 0000000000000001 R09: 0000000000000000
[ 429.201568] R10: ffff88009434f860 R11: 00000000ffffffff R12: 000000000203138a
[ 429.202272] R13: ffff880133001800 R14: 0000000000000000 R15: 0000000000000000
[ 429.202969] FS: 00007fa79ea77700(0000) GS:ffff880137c00000(0000) knlGS:0000000000000000
[ 429.203665] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 429.204363] CR2: 00000000015ec1c0 CR3: 00000000940a6000 CR4: 00000000000006f0
[ 429.205063] Stack:
[ 429.205760] 000000000203138a 0000000000000000 ffff880137c17e50 ffff880133001800
[ 429.206474] 0000000000000000 0000000000000000 ffff88009434f930 ffffffff81105467
[ 429.207197] ffffffff8105993f ffffffff810c7582 0000000100150015 0203138a00000001
[ 429.207914] Call Trace:
[ 429.208618] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.209328] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.210034] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.210739] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.211423] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.212102] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.212781] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.213446] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.214110] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.214771] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.215426] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.216078] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.216724] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.217369] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.218013] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.218650] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.219282] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.219914] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.220544] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.221170] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.221825] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.222456] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.223087] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.223718] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.224349] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.224979] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.225614] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.226236] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.226852] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.227464] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.228093] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.228699] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
[ 429.229308] Code: 5a 5b 41 5c 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 41 89 f4 81 e6 06 00 00 fc 53 51 74 0e 48 c7 c7 66 9a 75 81 e8 39 fe fb ff <0f> 0b 44 23 25 56 39 78 00 49 89 ff 4c 8b 6f 28 41 81 e4 e0 3e
[ 429.230077] RIP [<ffffffff811036a5>] new_slab+0x25/0x2be
[ 429.230739] RSP <ffff88009434f820>
[ 429.231392] ---[ end trace ddce043dc10fc3d2 ]---
[ 429.232059] BUG: sleeping function called from invalid context at include/linux/sched.h:2960
[ 429.232719] in_atomic(): 0, irqs_disabled(): 1, pid: 562, name: gzip
[ 429.233376] INFO: lockdep is turned off.
[ 429.234034] irq event stamp: 1994762
[ 429.234697] hardirqs last enabled at (1994761): [<ffffffff8113f360>] __find_get_block+0xd9/0x117
[ 429.235360] hardirqs last disabled at (1994762): [<ffffffff81105516>] __slab_alloc.isra.18.constprop.22+0x20/0x6d
[ 429.236026] softirqs last enabled at (1994554): [<ffffffff81040285>] __do_softirq+0x1bc/0x217
[ 429.236694] softirqs last disabled at (1994535): [<ffffffff810404ba>] irq_exit+0x3b/0x8f
[ 429.237360] CPU: 0 PID: 562 Comm: gzip Tainted: G D 4.7.0-rc2-mm1-dbg-00231-g201dcbd-dirty #141
[ 429.238708] 0000000000000000 ffff88009434f520 ffffffff811e632c 0000000000000000
[ 429.239397] ffff8800bf8e3a80 ffff88009434f548 ffffffff810598c8 ffffffff8174b8c3
[ 429.240077] 0000000000000b90 0000000000000000 ffff88009434f570 ffffffff8105993f
[ 429.240757] Call Trace:
[ 429.241433] [<ffffffff811e632c>] dump_stack+0x68/0x92
[ 429.242113] [<ffffffff810598c8>] ___might_sleep+0x1fb/0x202
[ 429.242816] [<ffffffff8105993f>] __might_sleep+0x70/0x77
[ 429.243493] [<ffffffff810487a0>] exit_signals+0x1e/0x119
[ 429.244168] [<ffffffff8103eec3>] do_exit+0x111/0x8f8
[ 429.244844] [<ffffffff8107da75>] ? kmsg_dump+0x149/0x154
[ 429.245525] [<ffffffff81014a03>] oops_end+0x9d/0xa4
[ 429.246200] [<ffffffff81014b27>] die+0x55/0x5e
[ 429.246868] [<ffffffff81012450>] do_trap+0x67/0x11d
[ 429.247538] [<ffffffff8101272d>] do_error_trap+0x100/0x10f
[ 429.248212] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.248878] [<ffffffff8107c870>] ? wake_up_klogd+0x4e/0x61
[ 429.249544] [<ffffffff8107ccda>] ? console_unlock+0x457/0x4a2
[ 429.250202] [<ffffffff81001036>] ? trace_hardirqs_off_thunk+0x1a/0x1c
[ 429.250856] [<ffffffff81012889>] do_invalid_op+0x1b/0x1d
[ 429.251508] [<ffffffff814a5e25>] invalid_op+0x15/0x20
[ 429.252158] [<ffffffff811036a5>] ? new_slab+0x25/0x2be
[ 429.252803] [<ffffffff81105467>] ___slab_alloc.constprop.23+0x2f8/0x387
[ 429.253451] [<ffffffff8105993f>] ? __might_sleep+0x70/0x77
[ 429.254102] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.254740] [<ffffffff810767fa>] ? lock_acquire+0x46/0x60
[ 429.255376] [<ffffffffa01ba17d>] ? fat_cache_add.part.1+0x135/0x140 [fat]
[ 429.256012] [<ffffffff8110553b>] __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.256657] [<ffffffff8110553b>] ? __slab_alloc.isra.18.constprop.22+0x45/0x6d
[ 429.257292] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.257959] [<ffffffff810c7582>] ? mempool_alloc_slab+0x10/0x12
[ 429.258592] [<ffffffff811055d9>] kmem_cache_alloc+0x76/0xc7
[ 429.259226] [<ffffffff810c7582>] mempool_alloc_slab+0x10/0x12
[ 429.259849] [<ffffffff810c7636>] mempool_alloc+0x7e/0x147
[ 429.260432] [<ffffffffa01ba53f>] ? fat_get_mapped_cluster+0x5a/0xeb [fat]
[ 429.261024] [<ffffffff811ca221>] bio_alloc_bioset+0xbd/0x1b1
[ 429.261614] [<ffffffff81148078>] mpage_alloc+0x28/0x7b
[ 429.262185] [<ffffffff8114856a>] do_mpage_readpage+0x43d/0x545
[ 429.262753] [<ffffffff81148767>] mpage_readpages+0xf5/0x152
[ 429.263320] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.263887] [<ffffffffa01c0d1a>] ? fat_add_cluster+0x48/0x48 [fat]
[ 429.264447] [<ffffffff811ea19f>] ? __radix_tree_lookup+0x70/0xa3
[ 429.265017] [<ffffffffa01befc6>] fat_readpages+0x18/0x1a [fat]
[ 429.265575] [<ffffffff810d0477>] __do_page_cache_readahead+0x215/0x2d6
[ 429.266135] [<ffffffff810d0883>] ondemand_readahead+0x34b/0x360
[ 429.266691] [<ffffffff810d0883>] ? ondemand_readahead+0x34b/0x360
[ 429.267240] [<ffffffff810d0a3a>] page_cache_async_readahead+0xae/0xb9
[ 429.267798] [<ffffffff810c546d>] generic_file_read_iter+0x1d1/0x6cf
[ 429.268345] [<ffffffff81071351>] ? update_fast_ctr+0x49/0x63
[ 429.268896] [<ffffffff8111b183>] ? pipe_write+0x3c7/0x3d9
[ 429.269438] [<ffffffff81114418>] __vfs_read+0xc4/0xe8
[ 429.269976] [<ffffffff811144da>] vfs_read+0x9e/0x109
[ 429.270518] [<ffffffff81114892>] SyS_read+0x4c/0x89
[ 429.271057] [<ffffffff814a4ba5>] entry_SYSCALL_64_fastpath+0x18/0xa8
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] mm: fix build warnings in <linux/compaction.h>
From: Minchan Kim @ 2016-06-10 0:33 UTC (permalink / raw)
To: Andrew Morton
Cc: Randy Dunlap, Linux MM, linux-next@vger.kernel.org,
Stephen Rothwell, Gioh Kim, Konstantin Khlebnikov, Rafael Aquini,
Vlastimil Babka
In-Reply-To: <20160609235141.GD29779@bbox>
On Fri, Jun 10, 2016 at 08:51:41AM +0900, Minchan Kim wrote:
> On Thu, Jun 09, 2016 at 04:37:19PM -0700, Andrew Morton wrote:
> > On Fri, 10 Jun 2016 08:31:43 +0900 Minchan Kim <minchan@kernel.org> wrote:
> >
> > > Hi Andrew,
> > >
> > > On Thu, Jun 09, 2016 at 03:27:16PM -0700, Andrew Morton wrote:
> > > > On Thu, 9 Jun 2016 10:06:01 -0700 Randy Dunlap <rdunlap@infradead.org> wrote:
> > > >
> > > > > From: Randy Dunlap <rdunlap@infradead.org>
> > > > >
> > > > > Fix build warnings when struct node is not defined:
> > > > >
> > > > > In file included from ../include/linux/balloon_compaction.h:48:0,
> > > > > from ../mm/balloon_compaction.c:11:
> > > > > ../include/linux/compaction.h:237:51: warning: 'struct node' declared inside parameter list [enabled by default]
> > > > > static inline int compaction_register_node(struct node *node)
> > > > > ../include/linux/compaction.h:237:51: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > > > > ../include/linux/compaction.h:242:54: warning: 'struct node' declared inside parameter list [enabled by default]
> > > > > static inline void compaction_unregister_node(struct node *node)
> > > > >
> > > > > ...
> > > > >
> > > > > --- linux-next-20160609.orig/include/linux/compaction.h
> > > > > +++ linux-next-20160609/include/linux/compaction.h
> > > > > @@ -233,6 +233,7 @@ extern int compaction_register_node(stru
> > > > > extern void compaction_unregister_node(struct node *node);
> > > > >
> > > > > #else
> > > > > +struct node;
> > > > >
> > > > > static inline int compaction_register_node(struct node *node)
> > > > > {
> > > >
> > > > Well compaction.h has no #includes at all and obviously depends on its
> > > > including file(s) to bring in the definitions which it needs.
> > > >
> > > > So if we want to keep that (odd) model then we should fix
> > > > mm-balloon-use-general-non-lru-movable-page-feature.patch thusly:
> > >
> > > How about fixing such odd model in this chance?
> > > Otherwise, every non-lru page migration driver should include
> > > both compaction.h and node.h which is weired to me. :(
> > >
> > > I think there are two ways.
> > >
> > > 1. compaction.h include node.h directly so user of compaction.h don't
> > > need to take care about node.h
> > >
> > > 2. Randy's fix
> > >
> > > I looked up who use compaction_[un]register_node and found it's used
> > > only drivers/base/node.c which already include node.h so no problem.
> > >
> > > 1) I believe it's rare those functions to be needed by other files.
> > > 2) Those functions works if CONFIG_NUMA as well as CONFIG_COMPACTION
> > > which is rare configuration for many not-server system.
> >
> > If we're going to convert compaction.h to be standalone then it will
> > need to include a whole bunch of things - what's special about node.h?
>
> Fair enough.
> I realize it would be better to relocate non-lru page migration functions to
> new separate header but I don't have an good idea to name that file. :(
> Anyway, I will work for it.
>
Andrew, it's quick fix. How about this?
>From ef5fb1b2ecfd2143700977c8cf089ee6ca6cdd17 Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Fri, 10 Jun 2016 09:12:08 +0900
Subject: [PATCH] mm: fix build warnings in <linux/compaction.h>
Randy reported below build error.
> In file included from ../include/linux/balloon_compaction.h:48:0,
> from ../mm/balloon_compaction.c:11:
> ../include/linux/compaction.h:237:51: warning: 'struct node' declared inside parameter list [enabled by default]
> static inline int compaction_register_node(struct node *node)
> ../include/linux/compaction.h:237:51: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> ../include/linux/compaction.h:242:54: warning: 'struct node' declared inside parameter list [enabled by default]
> static inline void compaction_unregister_node(struct node *node)
>
It was caused by non-lru page migration which needs compaction.h but
compaction.h doesn't include any header to be standalone.
I think proper header for non-lru page migration is migrate.h rather
than compaction.h because migrate.h has already headers needed to work
non-lru page migration indirectly like isolate_mode_t, migrate_mode
MIGRATEPAGE_SUCCESS.
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
Documentation/vm/page_migration | 11 ++++++-----
drivers/virtio/virtio_balloon.c | 2 +-
include/linux/balloon_compaction.h | 2 +-
include/linux/compaction.h | 16 ----------------
include/linux/migrate.h | 15 +++++++++++++++
mm/zsmalloc.c | 4 ++--
6 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/Documentation/vm/page_migration b/Documentation/vm/page_migration
index 18d37c7ac50b..94bd9c11c4e0 100644
--- a/Documentation/vm/page_migration
+++ b/Documentation/vm/page_migration
@@ -181,11 +181,12 @@ After isolation, VM calls migratepage of driver with isolated page.
The function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via __ClearPageMovable()
-under page_lock if you migrated the oldpage successfully and returns 0.
-If driver cannot migrate the page at the moment, driver can return -EAGAIN.
-On -EAGAIN, VM will retry page migration in a short time because VM interprets
--EAGAIN as "temporal migration failure". On returning any error except -EAGAIN,
-VM will give up the page migration without retrying in this time.
+under page_lock if you migrated the oldpage successfully and returns
+MIGRATEPAGE_SUCCESS. If driver cannot migrate the page at the moment, driver
+can return -EAGAIN. On -EAGAIN, VM will retry page migration in a short time
+because VM interprets -EAGAIN as "temporal migration failure". On returning
+any error except -EAGAIN, VM will give up the page migration without retrying
+in this time.
Driver shouldn't touch page.lru field VM using in the functions.
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 88d5609375de..888d5f8322ce 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -493,7 +493,7 @@ static int virtballoon_migratepage(struct balloon_dev_info *vb_dev_info,
put_page(page); /* balloon reference */
- return 0;
+ return MIGRATEPAGE_SUCCESS;
}
static struct dentry *balloon_mount(struct file_system_type *fs_type,
diff --git a/include/linux/balloon_compaction.h b/include/linux/balloon_compaction.h
index c0c430d06a9b..79542b2698ec 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -45,7 +45,7 @@
#define _LINUX_BALLOON_COMPACTION_H
#include <linux/pagemap.h>
#include <linux/page-flags.h>
-#include <linux/compaction.h>
+#include <linux/migrate.h>
#include <linux/gfp.h>
#include <linux/err.h>
#include <linux/fs.h>
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index c6b47c861cea..1a02dab16646 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -54,9 +54,6 @@ enum compact_result {
struct alloc_context; /* in mm/internal.h */
#ifdef CONFIG_COMPACTION
-extern int PageMovable(struct page *page);
-extern void __SetPageMovable(struct page *page, struct address_space *mapping);
-extern void __ClearPageMovable(struct page *page);
extern int sysctl_compact_memory;
extern int sysctl_compaction_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos);
@@ -154,19 +151,6 @@ extern void kcompactd_stop(int nid);
extern void wakeup_kcompactd(pg_data_t *pgdat, int order, int classzone_idx);
#else
-static inline int PageMovable(struct page *page)
-{
- return 0;
-}
-static inline void __SetPageMovable(struct page *page,
- struct address_space *mapping)
-{
-}
-
-static inline void __ClearPageMovable(struct page *page)
-{
-}
-
static inline enum compact_result try_to_compact_pages(gfp_t gfp_mask,
unsigned int order, int alloc_flags,
const struct alloc_context *ac,
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 404fbfefeb33..ae8d475a9385 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -71,6 +71,21 @@ static inline int migrate_huge_page_move_mapping(struct address_space *mapping,
#endif /* CONFIG_MIGRATION */
+#ifdef CONFIG_COMPACTION
+extern int PageMovable(struct page *page);
+extern void __SetPageMovable(struct page *page, struct address_space *mapping);
+extern void __ClearPageMovable(struct page *page);
+#else
+static inline int PageMovable(struct page *page) { return 0; };
+static inline void __SetPageMovable(struct page *page,
+ struct address_space *mapping)
+{
+}
+static inline void __ClearPageMovable(struct page *page)
+{
+}
+#endif
+
#ifdef CONFIG_NUMA_BALANCING
extern bool pmd_trans_migrating(pmd_t pmd);
extern int migrate_misplaced_page(struct page *page,
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 213d0e12fe82..502db584237b 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -50,7 +50,7 @@
#include <linux/zsmalloc.h>
#include <linux/zpool.h>
#include <linux/mount.h>
-#include <linux/compaction.h>
+#include <linux/migrate.h>
#include <linux/pagemap.h>
#define ZSPAGE_MAGIC 0x58
@@ -2119,7 +2119,7 @@ int zs_page_migrate(struct address_space *mapping, struct page *newpage,
put_page(page);
page = newpage;
- ret = 0;
+ ret = MIGRATEPAGE_SUCCESS;
unpin_objects:
for (addr = s_addr + offset; addr < s_addr + pos;
addr += class->size) {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] mm: fix build warnings in <linux/compaction.h>
From: Minchan Kim @ 2016-06-09 23:51 UTC (permalink / raw)
To: Andrew Morton
Cc: Randy Dunlap, Linux MM, linux-next@vger.kernel.org,
Stephen Rothwell
In-Reply-To: <20160609163719.5af286badfa9b5314700fece@linux-foundation.org>
On Thu, Jun 09, 2016 at 04:37:19PM -0700, Andrew Morton wrote:
> On Fri, 10 Jun 2016 08:31:43 +0900 Minchan Kim <minchan@kernel.org> wrote:
>
> > Hi Andrew,
> >
> > On Thu, Jun 09, 2016 at 03:27:16PM -0700, Andrew Morton wrote:
> > > On Thu, 9 Jun 2016 10:06:01 -0700 Randy Dunlap <rdunlap@infradead.org> wrote:
> > >
> > > > From: Randy Dunlap <rdunlap@infradead.org>
> > > >
> > > > Fix build warnings when struct node is not defined:
> > > >
> > > > In file included from ../include/linux/balloon_compaction.h:48:0,
> > > > from ../mm/balloon_compaction.c:11:
> > > > ../include/linux/compaction.h:237:51: warning: 'struct node' declared inside parameter list [enabled by default]
> > > > static inline int compaction_register_node(struct node *node)
> > > > ../include/linux/compaction.h:237:51: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > > > ../include/linux/compaction.h:242:54: warning: 'struct node' declared inside parameter list [enabled by default]
> > > > static inline void compaction_unregister_node(struct node *node)
> > > >
> > > > ...
> > > >
> > > > --- linux-next-20160609.orig/include/linux/compaction.h
> > > > +++ linux-next-20160609/include/linux/compaction.h
> > > > @@ -233,6 +233,7 @@ extern int compaction_register_node(stru
> > > > extern void compaction_unregister_node(struct node *node);
> > > >
> > > > #else
> > > > +struct node;
> > > >
> > > > static inline int compaction_register_node(struct node *node)
> > > > {
> > >
> > > Well compaction.h has no #includes at all and obviously depends on its
> > > including file(s) to bring in the definitions which it needs.
> > >
> > > So if we want to keep that (odd) model then we should fix
> > > mm-balloon-use-general-non-lru-movable-page-feature.patch thusly:
> >
> > How about fixing such odd model in this chance?
> > Otherwise, every non-lru page migration driver should include
> > both compaction.h and node.h which is weired to me. :(
> >
> > I think there are two ways.
> >
> > 1. compaction.h include node.h directly so user of compaction.h don't
> > need to take care about node.h
> >
> > 2. Randy's fix
> >
> > I looked up who use compaction_[un]register_node and found it's used
> > only drivers/base/node.c which already include node.h so no problem.
> >
> > 1) I believe it's rare those functions to be needed by other files.
> > 2) Those functions works if CONFIG_NUMA as well as CONFIG_COMPACTION
> > which is rare configuration for many not-server system.
>
> If we're going to convert compaction.h to be standalone then it will
> need to include a whole bunch of things - what's special about node.h?
Fair enough.
I realize it would be better to relocate non-lru page migration functions to
new separate header but I don't have an good idea to name that file. :(
Anyway, I will work for it.
>
> > So, I prefer Randy's fix.
>
> Doesn't matter much. But note that Randy's patch declared struct node
> at line 233. It should be sone at approximatley line 1, to prevent
> future duplicated declarations.
with removing 218 forward declaration 'struct node;' by me. ;(
I'm okay either approach until I fix the problem by introducing new header
for non-lru page migration.
Thanks!
^ permalink raw reply
* Re: [PATCH] mm: fix build warnings in <linux/compaction.h>
From: Andrew Morton @ 2016-06-09 23:37 UTC (permalink / raw)
To: Minchan Kim
Cc: Randy Dunlap, Linux MM, linux-next@vger.kernel.org,
Stephen Rothwell
In-Reply-To: <20160609233143.GC29779@bbox>
On Fri, 10 Jun 2016 08:31:43 +0900 Minchan Kim <minchan@kernel.org> wrote:
> Hi Andrew,
>
> On Thu, Jun 09, 2016 at 03:27:16PM -0700, Andrew Morton wrote:
> > On Thu, 9 Jun 2016 10:06:01 -0700 Randy Dunlap <rdunlap@infradead.org> wrote:
> >
> > > From: Randy Dunlap <rdunlap@infradead.org>
> > >
> > > Fix build warnings when struct node is not defined:
> > >
> > > In file included from ../include/linux/balloon_compaction.h:48:0,
> > > from ../mm/balloon_compaction.c:11:
> > > ../include/linux/compaction.h:237:51: warning: 'struct node' declared inside parameter list [enabled by default]
> > > static inline int compaction_register_node(struct node *node)
> > > ../include/linux/compaction.h:237:51: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > > ../include/linux/compaction.h:242:54: warning: 'struct node' declared inside parameter list [enabled by default]
> > > static inline void compaction_unregister_node(struct node *node)
> > >
> > > ...
> > >
> > > --- linux-next-20160609.orig/include/linux/compaction.h
> > > +++ linux-next-20160609/include/linux/compaction.h
> > > @@ -233,6 +233,7 @@ extern int compaction_register_node(stru
> > > extern void compaction_unregister_node(struct node *node);
> > >
> > > #else
> > > +struct node;
> > >
> > > static inline int compaction_register_node(struct node *node)
> > > {
> >
> > Well compaction.h has no #includes at all and obviously depends on its
> > including file(s) to bring in the definitions which it needs.
> >
> > So if we want to keep that (odd) model then we should fix
> > mm-balloon-use-general-non-lru-movable-page-feature.patch thusly:
>
> How about fixing such odd model in this chance?
> Otherwise, every non-lru page migration driver should include
> both compaction.h and node.h which is weired to me. :(
>
> I think there are two ways.
>
> 1. compaction.h include node.h directly so user of compaction.h don't
> need to take care about node.h
>
> 2. Randy's fix
>
> I looked up who use compaction_[un]register_node and found it's used
> only drivers/base/node.c which already include node.h so no problem.
>
> 1) I believe it's rare those functions to be needed by other files.
> 2) Those functions works if CONFIG_NUMA as well as CONFIG_COMPACTION
> which is rare configuration for many not-server system.
If we're going to convert compaction.h to be standalone then it will
need to include a whole bunch of things - what's special about node.h?
> So, I prefer Randy's fix.
Doesn't matter much. But note that Randy's patch declared struct node
at line 233. It should be sone at approximatley line 1, to prevent
future duplicated declarations.
^ permalink raw reply
* Re: [PATCH] mm: fix build warnings in <linux/compaction.h>
From: Minchan Kim @ 2016-06-09 23:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Randy Dunlap, Linux MM, linux-next@vger.kernel.org,
Stephen Rothwell
In-Reply-To: <20160609152716.1093ada2f52bbcc426e6ddb6@linux-foundation.org>
Hi Andrew,
On Thu, Jun 09, 2016 at 03:27:16PM -0700, Andrew Morton wrote:
> On Thu, 9 Jun 2016 10:06:01 -0700 Randy Dunlap <rdunlap@infradead.org> wrote:
>
> > From: Randy Dunlap <rdunlap@infradead.org>
> >
> > Fix build warnings when struct node is not defined:
> >
> > In file included from ../include/linux/balloon_compaction.h:48:0,
> > from ../mm/balloon_compaction.c:11:
> > ../include/linux/compaction.h:237:51: warning: 'struct node' declared inside parameter list [enabled by default]
> > static inline int compaction_register_node(struct node *node)
> > ../include/linux/compaction.h:237:51: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
> > ../include/linux/compaction.h:242:54: warning: 'struct node' declared inside parameter list [enabled by default]
> > static inline void compaction_unregister_node(struct node *node)
> >
> > ...
> >
> > --- linux-next-20160609.orig/include/linux/compaction.h
> > +++ linux-next-20160609/include/linux/compaction.h
> > @@ -233,6 +233,7 @@ extern int compaction_register_node(stru
> > extern void compaction_unregister_node(struct node *node);
> >
> > #else
> > +struct node;
> >
> > static inline int compaction_register_node(struct node *node)
> > {
>
> Well compaction.h has no #includes at all and obviously depends on its
> including file(s) to bring in the definitions which it needs.
>
> So if we want to keep that (odd) model then we should fix
> mm-balloon-use-general-non-lru-movable-page-feature.patch thusly:
How about fixing such odd model in this chance?
Otherwise, every non-lru page migration driver should include
both compaction.h and node.h which is weired to me. :(
I think there are two ways.
1. compaction.h include node.h directly so user of compaction.h don't
need to take care about node.h
2. Randy's fix
I looked up who use compaction_[un]register_node and found it's used
only drivers/base/node.c which already include node.h so no problem.
1) I believe it's rare those functions to be needed by other files.
2) Those functions works if CONFIG_NUMA as well as CONFIG_COMPACTION
which is rare configuration for many not-server system.
So, I prefer Randy's fix.
^ permalink raw reply
* Re: linux-next: build failure after merge of the amlogic tree
From: Kevin Hilman @ 2016-06-09 22:43 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, lkml, Neil Armstrong, Philipp Zabel
In-Reply-To: <20160606140231.394f5db7@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Kevin,
>
> On Sun, 5 Jun 2016 20:40:28 -0700 Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Not forgotten, but merged through Philip's reset tree, which I thought
>> was already in linux-next. Sorry about that.
>
> It may well be, but we dislike implicit dependencies between trees ...
> it makes the merge order matter :-( What you should have is a common
> non-rebasing branch that both trees merge.
Yup, I'll work this out with Philipp.
Kevin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox