[Devel] [PATCH rh7] config: Add loop to built-in drivers list
CTs want this driver: https://jira.sw.ru/browse/PSBM-41293 while we don't want to add it to autoload list. Signed-off-by: Kirill Tkhai --- configs/kernel-3.10.0-x86_64-debug.config |2 +- configs/kernel-3.10.0-x86_64.config |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/kernel-3.10.0-x86_64-debug.config b/configs/kernel-3.10.0-x86_64-debug.config index 6dcb566..7edceb8 100644 --- a/configs/kernel-3.10.0-x86_64-debug.config +++ b/configs/kernel-3.10.0-x86_64-debug.config @@ -1456,7 +1456,7 @@ CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set -CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=0 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_DRBD is not set diff --git a/configs/kernel-3.10.0-x86_64.config b/configs/kernel-3.10.0-x86_64.config index 7cfaaaf..85d95f8 100644 --- a/configs/kernel-3.10.0-x86_64.config +++ b/configs/kernel-3.10.0-x86_64.config @@ -1455,7 +1455,7 @@ CONFIG_BLK_DEV_PCIESSD_MTIP32XX=m # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set -CONFIG_BLK_DEV_LOOP=m +CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_MIN_COUNT=0 # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_DRBD is not set ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RHEL7 COMMIT] Makefile: properly generate KERNELRELEASE value
The commit is pushed to "branch-rh7-3.10.0-229.7.2.vz7.9.x-ovz" and will appear
at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-229.7.2.vz7.9.10
-->
commit 16857c67c0899f940979a8516bb30aa03b52f273
Author: Konstantin Khorenko
Date: Tue Nov 17 20:24:21 2015 +0400
Makefile: properly generate KERNELRELEASE value
In case kernel is built from the tree (not with help of rpmbuild),
KERNELRELEASE env variable is not provided and should be
constructed from local git tags.
Generated KERNELRELEASE example:
"3.10.0-229.7.2.ovz.9.10-1-g1da4621"
VZVERSION has been also aligned with format used in kernel.spec:
"9.10" instead of "ovz.9.10".
https://jira.sw.ru/browse/PSBM-34957
Signed-off-by: Konstantin Khorenko
Acked-by: Cyrill Gorcunov
---
Makefile | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 02d6a38..aa59447 100644
--- a/Makefile
+++ b/Makefile
@@ -13,7 +13,17 @@ RHEL_DRM_SUBLEVEL = 7
VZVERSION = ovz.custom
ifeq ($(VZVERSION), ovz.custom)
- VZVERSION := $(shell if [ -d ".git" ]; then git describe | sed -r
's/^.*\.vz7\./ovz./'; fi)
+ GIT_DIR := .git
+ ifneq ("$(wildcard $(GIT_DIR) )", "")
+VZVERSION := $(shell git describe --abbrev=0 2>/dev/null | \
+ sed -r 's/^.*\.vz7\.//')
+ else
+VZVERSION := custom
+ endif
+
+ ifeq ($(EXTRAVERSION),)
+EXTRAVERSION := -$(RHEL_RELEASE).ovz.$(VZVERSION)
+ endif
endif
# *DOCUMENTATION*
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RHEL7 COMMIT] config.OpenVZ: enable CONFIG_LOCALVERSION_AUTO
The commit is pushed to "branch-rh7-3.10.0-229.7.2.vz7.9.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git after rh7-3.10.0-229.7.2.vz7.9.10 --> commit a9f715654427d8458a765ab81ceaa6bd950a5b8f Author: Konstantin Khorenko Date: Tue Nov 17 20:20:14 2015 +0400 config.OpenVZ: enable CONFIG_LOCALVERSION_AUTO It's convenient to have some reference point in the kernel version, what git commit it refers to, so +CONFIG_LOCALVERSION_AUTO=y Note: kernel configs used during rpm packages creation do not have this option enabled. So this is the first pecularity of configs committed to the kernel tree for development convenience. https://jira.sw.ru/browse/PSBM-34957 Signed-off-by: Konstantin Khorenko Acked-by: Cyrill Gorcunov --- configs/kernel-3.10.0-x86_64-debug.config | 2 +- configs/kernel-3.10.0-x86_64.config | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/kernel-3.10.0-x86_64-debug.config b/configs/kernel-3.10.0-x86_64-debug.config index 6dcb566..114d610 100644 --- a/configs/kernel-3.10.0-x86_64-debug.config +++ b/configs/kernel-3.10.0-x86_64-debug.config @@ -49,7 +49,7 @@ CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" -# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y diff --git a/configs/kernel-3.10.0-x86_64.config b/configs/kernel-3.10.0-x86_64.config index 7cfaaaf..f4ea4be 100644 --- a/configs/kernel-3.10.0-x86_64.config +++ b/configs/kernel-3.10.0-x86_64.config @@ -49,7 +49,7 @@ CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" -# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH rh7] x86: arch_free_page() introduced
17.11.2015 16:08, Vladimir Davydov пишет:
On Tue, Nov 17, 2015 at 03:42:46PM +0100, Stanislav Kinsburskiy wrote:
17.11.2015 15:20, Vladimir Davydov пишет:
On Thu, Nov 12, 2015 at 10:01:14PM +0400, Stanislav Kinsburskiy wrote:
@@ -0,0 +1,23 @@
+#ifndef _ASM_X86_FREE_PAGE_H
+#define _ASM_X86_FREE_PAGE_H
+
+#ifdef __KERNEL__
+
+#ifndef __ASSEMBLY__
+
+#include
+
+#define HAVE_ARCH_FREE_PAGE
+
+extern struct static_key zero_free_pages;
+extern void do_zero_pages(struct page *page, int order);
+
+static __always_inline void arch_free_page(struct page *page, int order)
+{
+ if (static_key_false(&zero_free_pages))
+ do_zero_pages(page, order);
+}
There is no point in making this feature arch-dependant now, as you use
jump labels, which are arch-independent. The only reason why I had to
overwrite arch_free_page in PCS6 is that I had to write some asm code to
implement functionality close to that provided by jump labels, which are
absent in RH6-based kernels. Please move it to mm/page_alloc.c.
Thanks.
If we will make this function generic, then we have to declare
"zero_free_pages" as generic (which is more or less ok) and define
do_zero_pages for the case, when HAVE_ARCH_FREE_PAGE is not defined. Does
the goal worth it?
If yes, then why?
I don't think I get your point. All I want you to do is something like
this:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f70c5f4da2a2..12126f212f3b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -730,8 +730,11 @@ static bool free_pages_prepare(struct page *page, unsigned
int order)
if (PageAnon(page))
page->mapping = NULL;
- for (i = 0; i < (1 << order); i++)
+ for (i = 0; i < (1 << order); i++) {
bad += free_pages_check(page + i);
+ if (static_key_false(&zero_free_pages))
+ clear_highpage(page + i);
+ }
if (bad)
return false;
IMO this is better than messing around arch code.
Ok, I got your point.
I'm trying to follow a little bit different strategy, which is aimed to
impact generic code as less, as possible. And from this point of view
using already defined arch_free_page callback looks better to me. But I
don't insist and can make it your way.
Should I?
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] protblem building criu on pcs7
On Tue, Nov 17, 2015 at 07:50:20AM -0700, Tycho Andersen wrote: > On Tue, Nov 17, 2015 at 05:12:56PM +0300, Cyrill Gorcunov wrote: > > Guys, recent changes in criu prevented me from continue building it > > on pcs7 kernel (ie on 3.10 higly lifted kernel) because there is > > no SECCOMP_SET_MODE_FILTER and SECCOMP_FILTER_FLAG_TSYNC constants > > defined in headers. That said for sure I can simply comment it out > > (or defined by my own), but such lack of constants means that we > > don't have this functionallity in kernel. > > > > So what would be a safe strategy here: backport kernel patches, > > make this code compile-dependant or something else? Pavel? > > Asking simply because I'm not familiar with seccomp engine > > yet and cant provide a solution. > > We should definitely define the constants in CRIU, it was just an > oversight that I didn't. > > One other problem too is we'll have to make some change in > proc_parse.c as well, since it right now expects to parse Seccomp: > from /proc/self/status. I think the attached patch should work. Acked-by: Cyrill Gorcunov Thank you! ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH rh7] x86: arch_free_page() introduced
On Tue, Nov 17, 2015 at 03:42:46PM +0100, Stanislav Kinsburskiy wrote:
>
>
> 17.11.2015 15:20, Vladimir Davydov пишет:
> >On Thu, Nov 12, 2015 at 10:01:14PM +0400, Stanislav Kinsburskiy wrote:
> >
> >>@@ -0,0 +1,23 @@
> >>+#ifndef _ASM_X86_FREE_PAGE_H
> >>+#define _ASM_X86_FREE_PAGE_H
> >>+
> >>+#ifdef __KERNEL__
> >>+
> >>+#ifndef __ASSEMBLY__
> >>+
> >>+#include
> >>+
> >>+#define HAVE_ARCH_FREE_PAGE
> >>+
> >>+extern struct static_key zero_free_pages;
> >>+extern void do_zero_pages(struct page *page, int order);
> >>+
> >>+static __always_inline void arch_free_page(struct page *page, int order)
> >>+{
> >>+ if (static_key_false(&zero_free_pages))
> >>+ do_zero_pages(page, order);
> >>+}
> >There is no point in making this feature arch-dependant now, as you use
> >jump labels, which are arch-independent. The only reason why I had to
> >overwrite arch_free_page in PCS6 is that I had to write some asm code to
> >implement functionality close to that provided by jump labels, which are
> >absent in RH6-based kernels. Please move it to mm/page_alloc.c.
> >
> >Thanks.
>
> If we will make this function generic, then we have to declare
> "zero_free_pages" as generic (which is more or less ok) and define
> do_zero_pages for the case, when HAVE_ARCH_FREE_PAGE is not defined. Does
> the goal worth it?
> If yes, then why?
>
I don't think I get your point. All I want you to do is something like
this:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f70c5f4da2a2..12126f212f3b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -730,8 +730,11 @@ static bool free_pages_prepare(struct page *page, unsigned
int order)
if (PageAnon(page))
page->mapping = NULL;
- for (i = 0; i < (1 << order); i++)
+ for (i = 0; i < (1 << order); i++) {
bad += free_pages_check(page + i);
+ if (static_key_false(&zero_free_pages))
+ clear_highpage(page + i);
+ }
if (bad)
return false;
IMO this is better than messing around arch code.
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] protblem building criu on pcs7
On Tue, Nov 17, 2015 at 05:12:56PM +0300, Cyrill Gorcunov wrote: > Guys, recent changes in criu prevented me from continue building it > on pcs7 kernel (ie on 3.10 higly lifted kernel) because there is > no SECCOMP_SET_MODE_FILTER and SECCOMP_FILTER_FLAG_TSYNC constants > defined in headers. That said for sure I can simply comment it out > (or defined by my own), but such lack of constants means that we > don't have this functionallity in kernel. > > So what would be a safe strategy here: backport kernel patches, > make this code compile-dependant or something else? Pavel? > Asking simply because I'm not familiar with seccomp engine > yet and cant provide a solution. We should definitely define the constants in CRIU, it was just an oversight that I didn't. One other problem too is we'll have to make some change in proc_parse.c as well, since it right now expects to parse Seccomp: from /proc/self/status. I think the attached patch should work. Tycho ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH rh7] x86: arch_free_page() introduced
17.11.2015 15:20, Vladimir Davydov пишет:
On Thu, Nov 12, 2015 at 10:01:14PM +0400, Stanislav Kinsburskiy wrote:
@@ -0,0 +1,23 @@
+#ifndef _ASM_X86_FREE_PAGE_H
+#define _ASM_X86_FREE_PAGE_H
+
+#ifdef __KERNEL__
+
+#ifndef __ASSEMBLY__
+
+#include
+
+#define HAVE_ARCH_FREE_PAGE
+
+extern struct static_key zero_free_pages;
+extern void do_zero_pages(struct page *page, int order);
+
+static __always_inline void arch_free_page(struct page *page, int order)
+{
+ if (static_key_false(&zero_free_pages))
+ do_zero_pages(page, order);
+}
There is no point in making this feature arch-dependant now, as you use
jump labels, which are arch-independent. The only reason why I had to
overwrite arch_free_page in PCS6 is that I had to write some asm code to
implement functionality close to that provided by jump labels, which are
absent in RH6-based kernels. Please move it to mm/page_alloc.c.
Thanks.
If we will make this function generic, then we have to declare
"zero_free_pages" as generic (which is more or less ok) and define
do_zero_pages for the case, when HAVE_ARCH_FREE_PAGE is not defined.
Does the goal worth it?
If yes, then why?
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RHEL7 COMMIT] ve/vznetstat: fix RCU-protected "info_V{4, 6}" pointers initialization
The commit is pushed to "branch-rh7-3.10.0-229.7.2.vz7.9.x-ovz" and will appear
at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-229.7.2.vz7.9.10
-->
commit c173e3204914acf2002a75002f8b4a768a952bc0
Author: Stanislav Kinsburskiy
Date: Tue Nov 17 18:40:50 2015 +0400
ve/vznetstat: fix RCU-protected "info_V{4, 6}" pointers initialization
This pointers have to be referenced and assigned under rcu_read_lock().
Moreover, there is no need to take tc_lock: it protects stats hash, but not
info pointers.
Fixes the following warning:
[ 31.658913] ===
[ 31.659035] [ INFO: suspicious RCU usage. ]
[ 31.659155] 3.10.0+ #121 Not tainted
[ 31.659258] ---
[ 31.659377] kernel/ve/vznetstat/vznetstat.c:95 suspicious
rcu_dereference_check() usage!
[ 31.659597]
[ 31.659597] other info that might help us debug this:
[ 31.659597]
[ 31.659831]
[ 31.659831] rcu_scheduler_active = 1, debug_locks = 0
[ 31.660026] 1 lock held by vztactl/831:
[ 31.660136] #0: (tc_lock){.+.+..}, at: []
venet_acct_set_classes+0xf4/0x240 [vznetstat]
[ 31.660454]
[ 31.660454] stack backtrace:
[ 31.660584] CPU: 0 PID: 831 Comm: vztactl ve: 0 Not tainted 3.10.0+ #121
ovz.9.8-21-g6c64ed7
[ 31.660823] Hardware name: Parallels Software International Inc.
Parallels
Virtual Platform/Parallels Virtual Platform, BIOS 6.9.23856.1122235
03/18/2015
[ 31.661201] 3e77c710 8800a960bd88
816298fe
[ 31.661436] 8800a960bdb8 810f9667
8801446e2f08
[ 31.661661] 000c 8800a960bdf0
a0052f61
[ 31.661910] Call Trace:
[ 31.661989] [] dump_stack+0x19/0x1b
[ 31.662134] [] lockdep_rcu_suspicious+0xe7/0x120
[ 31.662308] [] venet_acct_set_classes+0x1f1/0x240
[vznetstat]
[ 31.662511] [] venet_acct_ioctl+0x2bb/0xaf0
[vznetstat]
[ 31.662706] [] vzctl_ioctl+0x45/0x60 [vzdev]
[ 31.662875] [] do_vfs_ioctl+0x265/0x540
[ 31.663041] [] ? fget_light+0x377/0x4e0
[ 31.663193] [] SyS_ioctl+0x54/0xa0
[ 31.663334] [] system_call_fastpath+0x16/0x1b
Signed-off-by: Stanislav Kinsburskiy
---
kernel/ve/vznetstat/vznetstat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/ve/vznetstat/vznetstat.c b/kernel/ve/vznetstat/vznetstat.c
index 99feafb..c47865a 100644
--- a/kernel/ve/vznetstat/vznetstat.c
+++ b/kernel/ve/vznetstat/vznetstat.c
@@ -87,7 +87,7 @@ static int venet_acct_set_classes(const void __user
*user_info, int length, int
goto out_free;
}
- write_lock_irq(&tc_lock);
+ rcu_read_lock();
if (v6) {
old = rcu_dereference(info_v6);
rcu_assign_pointer(info_v6, info);
@@ -95,7 +95,7 @@ static int venet_acct_set_classes(const void __user
*user_info, int length, int
old = rcu_dereference(info_v4);
rcu_assign_pointer(info_v4, info);
}
- write_unlock_irq(&tc_lock);
+ rcu_read_unlock();
synchronize_net();
/* IMPORTANT. I think reset of statistics collected should not be
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH rh7] vznetstat: fix RCU-protected "info_V{4, 6}" pointers initialization
Stas, i'm applying this, thank you.
Vasya, as far as i see 2.6.32-x kernel has the same code,
please check and apply the patch if needed.
--
Best regards,
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
On 11/12/2015 04:42 PM, Stanislav Kinsburskiy wrote:
This pointers have to be referenced and assigned under rcu_read_lock().
Moreover, there is no need to take tc_lock: it protects stats hash, but not
info pointers.
Fixes the following warning:
[ 31.658913] ===
[ 31.659035] [ INFO: suspicious RCU usage. ]
[ 31.659155] 3.10.0+ #121 Not tainted
[ 31.659258] ---
[ 31.659377] kernel/ve/vznetstat/vznetstat.c:95 suspicious
rcu_dereference_check() usage!
[ 31.659597]
[ 31.659597] other info that might help us debug this:
[ 31.659597]
[ 31.659831]
[ 31.659831] rcu_scheduler_active = 1, debug_locks = 0
[ 31.660026] 1 lock held by vztactl/831:
[ 31.660136] #0: (tc_lock){.+.+..}, at: []
venet_acct_set_classes+0xf4/0x240 [vznetstat]
[ 31.660454]
[ 31.660454] stack backtrace:
[ 31.660584] CPU: 0 PID: 831 Comm: vztactl ve: 0 Not tainted 3.10.0+ #121
ovz.9.8-21-g6c64ed7
[ 31.660823] Hardware name: Parallels Software International Inc. Parallels
Virtual Platform/Parallels Virtual Platform, BIOS 6.9.23856.1122235 03/18/2015
[ 31.661201] 3e77c710 8800a960bd88
816298fe
[ 31.661436] 8800a960bdb8 810f9667
8801446e2f08
[ 31.661661] 000c 8800a960bdf0
a0052f61
[ 31.661910] Call Trace:
[ 31.661989] [] dump_stack+0x19/0x1b
[ 31.662134] [] lockdep_rcu_suspicious+0xe7/0x120
[ 31.662308] [] venet_acct_set_classes+0x1f1/0x240
[vznetstat]
[ 31.662511] [] venet_acct_ioctl+0x2bb/0xaf0 [vznetstat]
[ 31.662706] [] vzctl_ioctl+0x45/0x60 [vzdev]
[ 31.662875] [] do_vfs_ioctl+0x265/0x540
[ 31.663041] [] ? fget_light+0x377/0x4e0
[ 31.663193] [] SyS_ioctl+0x54/0xa0
[ 31.663334] [] system_call_fastpath+0x16/0x1b
Signed-off-by: Stanislav Kinsburskiy
---
kernel/ve/vznetstat/vznetstat.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/ve/vznetstat/vznetstat.c b/kernel/ve/vznetstat/vznetstat.c
index 99feafb..c47865a 100644
--- a/kernel/ve/vznetstat/vznetstat.c
+++ b/kernel/ve/vznetstat/vznetstat.c
@@ -87,7 +87,7 @@ static int venet_acct_set_classes(const void __user
*user_info, int length, int
goto out_free;
}
- write_lock_irq(&tc_lock);
+ rcu_read_lock();
if (v6) {
old = rcu_dereference(info_v6);
rcu_assign_pointer(info_v6, info);
@@ -95,7 +95,7 @@ static int venet_acct_set_classes(const void __user
*user_info, int length, int
old = rcu_dereference(info_v4);
rcu_assign_pointer(info_v4, info);
}
- write_unlock_irq(&tc_lock);
+ rcu_read_unlock();
synchronize_net();
/* IMPORTANT. I think reset of statistics collected should not be
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH rh7] x86: arch_free_page() introduced
On Thu, Nov 12, 2015 at 10:01:14PM +0400, Stanislav Kinsburskiy wrote:
> @@ -0,0 +1,23 @@
> +#ifndef _ASM_X86_FREE_PAGE_H
> +#define _ASM_X86_FREE_PAGE_H
> +
> +#ifdef __KERNEL__
> +
> +#ifndef __ASSEMBLY__
> +
> +#include
> +
> +#define HAVE_ARCH_FREE_PAGE
> +
> +extern struct static_key zero_free_pages;
> +extern void do_zero_pages(struct page *page, int order);
> +
> +static __always_inline void arch_free_page(struct page *page, int order)
> +{
> + if (static_key_false(&zero_free_pages))
> + do_zero_pages(page, order);
> +}
There is no point in making this feature arch-dependant now, as you use
jump labels, which are arch-independent. The only reason why I had to
overwrite arch_free_page in PCS6 is that I had to write some asm code to
implement functionality close to that provided by jump labels, which are
absent in RH6-based kernels. Please move it to mm/page_alloc.c.
Thanks.
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RHEL7 COMMIT] ve/vtty: Don't zap termios fields on slave peer
The commit is pushed to "branch-rh7-3.10.0-229.7.2.vz7.9.x-ovz" and will appear
at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-229.7.2.vz7.9.10
-->
commit 0eb5cec93f6d06b93c317795d636b68376e366f6
Author: Cyrill Gorcunov
Date: Tue Nov 17 18:18:45 2015 +0400
ve/vtty: Don't zap termios fields on slave peer
These fields are sensitive to userspace so was a copy-paste
bug in first place when I defined driver fields (the pty
as well as vtty devices have same structure in drivers).
Also I defined @chars_in_buffer, @flush_buffer and @resize
methods for driver to be close to former pcs6 driver structure.
Note there is still problem remains: upon vzctl console
call the carrige return (enter press) is still required
for login prompt to appear, I'm investigating it now.
https://jira.sw.ru/browse/PSBM-41057
Signed-off-by: Cyrill Gorcunov
Reviewed-by: Vladimir Davydov
---
drivers/tty/pty.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index 0ab36f9..b312635 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -1217,6 +1217,13 @@ static void vtty_remove(struct tty_driver *driver,
struct tty_struct *tty)
{
}
+static int vtty_resize(struct tty_struct *tty, struct winsize *ws)
+{
+ if (tty->driver == vttym_driver)
+ return pty_resize(tty, ws);
+ return tty_do_resize(tty, ws);
+}
+
static const struct tty_operations vtty_ops = {
.lookup = vtty_lookup,
.install= vtty_install,
@@ -1226,9 +1233,12 @@ static const struct tty_operations vtty_ops = {
.cleanup= pty_cleanup,
.write = vtty_write,
.write_room = vtty_write_room,
+ .chars_in_buffer= pty_chars_in_buffer,
.set_termios= pty_set_termios,
.unthrottle = pty_unthrottle,
+ .flush_buffer = pty_flush_buffer,
.remove = vtty_remove,
+ .resize = vtty_resize,
};
struct tty_driver *vtty_console_driver(int *index)
@@ -1301,8 +1311,6 @@ static int __init vtty_init(void)
/* 38400 boud rate, 8 bit char size, enable receiver */
vttym_driver->init_termios.c_cflag = B38400 | CS8 | CREAD;
vttym_driver->init_termios.c_lflag = 0;
- vttym_driver->init_termios.c_ispeed = 38400;
- vttym_driver->init_termios.c_ospeed = 38400;
tty_set_operations(vttym_driver, &vtty_ops);
vttys_driver->driver_name = "vtty_slave";
@@ -1313,12 +1321,7 @@ static int __init vtty_init(void)
vttys_driver->type = TTY_DRIVER_TYPE_PTY;
vttys_driver->subtype = PTY_TYPE_SLAVE;
vttys_driver->init_termios = tty_std_termios;
- vttys_driver->init_termios.c_iflag = 0;
- vttys_driver->init_termios.c_oflag = 0;
vttys_driver->init_termios.c_cflag = B38400 | CS8 | CREAD;
- vttys_driver->init_termios.c_lflag = 0;
- vttys_driver->init_termios.c_ispeed = 38400;
- vttys_driver->init_termios.c_ospeed = 38400;
tty_set_operations(vttys_driver, &vtty_ops);
if (tty_register_driver(vttym_driver))
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH rh7] tcache: account reclaimed pages to scan_control->nr_reclaimed
Tcache pages might constitute a substantial portion of the total number of pages reclaimed. Since they are freed immediately, we should count them to scan_control->nr_reclaimed to avoid premature scan->priority drops and resulting overreclaim. Signed-off-by: Vladimir Davydov --- mm/tcache.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/tcache.c b/mm/tcache.c index ce5b0edd8253..e8ffa91190e6 100644 --- a/mm/tcache.c +++ b/mm/tcache.c @@ -17,6 +17,7 @@ #include #include #include +#include #include /* cleancache_put_page is called from atomic context */ @@ -808,6 +809,8 @@ static unsigned long tcache_shrink_scan(struct shrinker *shrink, } sc->nr_to_scan--; } + if (current->reclaim_state) + current->reclaim_state->reclaimed_slab += nr_reclaimed; return nr_reclaimed; } -- 2.1.4 ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
[Devel] protblem building criu on pcs7
Guys, recent changes in criu prevented me from continue building it on pcs7 kernel (ie on 3.10 higly lifted kernel) because there is no SECCOMP_SET_MODE_FILTER and SECCOMP_FILTER_FLAG_TSYNC constants defined in headers. That said for sure I can simply comment it out (or defined by my own), but such lack of constants means that we don't have this functionallity in kernel. So what would be a safe strategy here: backport kernel patches, make this code compile-dependant or something else? Pavel? Asking simply because I'm not familiar with seccomp engine yet and cant provide a solution. Cyrill ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH rh7 1/2] ixgbe: cleanup ixgbe_enumerate_functions
JFYI: filed an issue to RedHat
https://bugzilla.redhat.com/show_bug.cgi?id=1282804
--
Best regards,
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
On 11/10/2015 04:48 PM, Konstantin Khorenko wrote:
Andrey,
please file a bug to RedHat about this (and add me to CC there
).
Meanwhile i'm applying those patches in order to unblock debug kernel runs.
--
Best regards,
Konstantin Khorenko,
Virtuozzo Linux Kernel Team
On 11/10/2015 11:21 AM, Vasily Averin wrote:
I think we can just notify Red Hat about this problem
On 10.11.2015 11:06, Andrey Ryabinin wrote:
From: Jacob Keller
This function previously had the same check as used by the
ixgbe_pcie_from_parent. As the hardcode is due to the device having an internal
switch, this function should simply use the call from ixgbe_pcie_from_parent.
This reduces code complexity and makes it less likely a developer will forget
to update the list in the future.
Signed-off-by: Jacob Keller
Tested-by: Phil Schmitt
Signed-off-by: Jeff Kirsher
(cherry picked from commit f1f965793b2bb8a75067e94acbe886a61637cab8)
Signed-off-by: Andrey Ryabinin
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 14f05b8..9fe8787 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7525,19 +7525,16 @@ static const struct net_device_ops ixgbe_netdev_ops = {
**/
static inline int ixgbe_enumerate_functions(struct ixgbe_adapter *adapter)
{
- struct ixgbe_hw *hw = &adapter->hw;
struct list_head *entry;
int physfns = 0;
- /* Some cards can not use the generic count PCIe functions method, and
-* so must be hardcoded to the correct value.
+ /* Some cards can not use the generic count PCIe functions method,
+* because they are behind a parent switch, so we hardcode these with
+* the correct number of functions.
*/
- switch (hw->device_id) {
- case IXGBE_DEV_ID_82599_SFP_SF_QP:
- case IXGBE_DEV_ID_82599_QSFP_SF_QP:
+ if (ixgbe_pcie_from_parent(&adapter->hw)) {
physfns = 4;
- break;
- default:
+ } else {
list_for_each(entry, &adapter->pdev->bus_list) {
struct pci_dev *pdev =
list_entry(entry, struct pci_dev, bus_list);
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH RH7 0/9] Port: fence watchdog feature
Acked-by: Andrew Vagin On Tue, Oct 13, 2015 at 05:52:50PM +0300, Pavel Tikhomirov wrote: > https://jira.sw.ru/browse/PSBM-33648 > > /dev/watchdog "softdog" is really close but it has several problems: > - no shutdown action > - no network blocking action > - can not get timeout and timeleft > - set timeout through ioctl only > - set action in module load parameters only > - our userspace(shaman) is using our interface > > so it is easier to port our watchdog > > Pavel Tikhomirov (9): > Port: diff-fence-watchdog-introduce-fencing-watchdog-for-HA-cluster-3 > Port: diff-fence-watchdog-add-support-of-crash > Port: diff-fence-watchdog-write-log-message-when-timer-elapses > Port: diff-fence-watchdog-rename-action-to-halt > Port: diff-fence-watchdog-schedule-work-in-case-of-halt-action > Port: diff-fence-watchdog-add-netfilter-action > Port: diff-fence-watchdog-add-wdog_tmo-match > Port: diff-fence-watchdog-arptables-add-ability-to-filter-by > -watchdog-timeout-v5 > Port: diff-fence-watchdog-netfilter-add-aliases-for-module-wdog_tmo > > arch/x86/include/asm/vvar.h | 1 + > include/linux/fence-watchdog.h| 7 + > include/uapi/linux/netfilter_arp/arp_tables.h | 7 +- > kernel/Kconfig.openvz | 5 + > kernel/Makefile | 1 + > kernel/fence-watchdog.c | 203 > ++ > net/core/dev.c| 12 ++ > net/ipv4/netfilter/arp_tables.c | 9 ++ > net/netfilter/Kconfig | 6 + > net/netfilter/Makefile| 1 + > net/netfilter/xt_wdog_tmo.c | 53 +++ > 11 files changed, 302 insertions(+), 3 deletions(-) > create mode 100644 include/linux/fence-watchdog.h > create mode 100644 kernel/fence-watchdog.c > create mode 100644 net/netfilter/xt_wdog_tmo.c > > -- > 1.9.3 > ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RHEL7 COMMIT] ms/pvpanic: Set high notifier priority
The commit is pushed to "branch-rh7-3.10.0-229.7.2.vz7.9.x-ovz" and will appear
at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-229.7.2.vz7.9.10
-->
commit 75d66c8784fc1b917ab7430bcedfab8a7a421890
Author: Takashi Iwai
Date: Tue May 6 17:52:26 2014 +0200
ms/pvpanic: Set high notifier priority
ms commit: 7939831eacd81fccbd7a956b30c7bb3abb9079db
https://jira.sw.ru/browse/PSBM-41189
We've observed the missing pvpanic call at panic, and it turned out
that this was blocked by the broken notifier of drm_fb_helper, where
scheduling may be called during switching to the fb console.
It's fairly difficult to fix the drm_fb problem and a quick fix isn't
foreseen, a simpler solution for the missing pvpanic call would be
just to call this earlier.
In order to assure that, this patch sets a higher priority to pvpanic
notifier_block. Once when the issue of drm_fb is resolved, we can
remove this priority again.
Signed-off-by: Takashi Iwai
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/pvpanic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/pvpanic.c b/drivers/platform/x86/pvpanic.c
index 47ae0c4..469e182 100644
--- a/drivers/platform/x86/pvpanic.c
+++ b/drivers/platform/x86/pvpanic.c
@@ -71,6 +71,7 @@ pvpanic_panic_notify(struct notifier_block *nb, unsigned long
code,
static struct notifier_block pvpanic_panic_nb = {
.notifier_call = pvpanic_panic_notify,
+ .priority = 1, /* let this called before broken drm_fb_helper */
};
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH rh7 v3] ve: Attach a ve cgroup from task_work
There are many places where get_exec_env() is used.
Since a task may be attached to a ve not only by
itself, this may lead to a problem, when dereferenced
ve has changed, but a code is operating with the old
ve.
This patch makes task_ve to be changed using task_work,
i.e. in a place where it definitelly is not using
get_exec_env().
Suggested-by: Vladimir Davydov
Suggested-by: Pavel Emelyanov
Signed-off-by: Kirill Tkhai
---
include/linux/ve.h |4
kernel/ve/ve.c | 38 +-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/include/linux/ve.h b/include/linux/ve.h
index 2554337..f4c139a 100644
--- a/include/linux/ve.h
+++ b/include/linux/ve.h
@@ -53,6 +53,10 @@ struct ve_struct {
/* see vzcalluser.h for VE_FEATURE_XXX definitions */
__u64 features;
+ struct callback_headtask_attach_work;
+ struct callback_headtask_wait_work;
+ struct completion task_completion;
+
struct task_struct *ve_kthread_task;
struct kthread_worker ve_kthread_worker;
diff --git a/kernel/ve/ve.c b/kernel/ve/ve.c
index 8f5f905..8b6c12b 100644
--- a/kernel/ve/ve.c
+++ b/kernel/ve/ve.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -61,8 +62,12 @@ struct kmapset_set ve_sysfs_perms;
static DEFINE_PER_CPU(struct kstat_lat_pcpu_snap_struct, ve0_lat_stats);
+static void task_attach_work(struct callback_head *head);
+
struct ve_struct ve0 = {
.ve_name= "0",
+ .task_attach_work.func = task_attach_work,
+ .task_wait_work.func= NULL,
.start_jiffies = INITIAL_JIFFIES,
.jiffies_fixup = 0,
RCU_POINTER_INITIALIZER(ve_ns, &init_nsproxy),
@@ -656,6 +661,8 @@ static struct cgroup_subsys_state *ve_create(struct cgroup
*cg)
INIT_LIST_HEAD(&ve->devmnt_list);
mutex_init(&ve->devmnt_mutex);
kmapset_init_key(&ve->ve_sysfs_perms);
+ init_task_work(&ve->task_attach_work, task_attach_work);
+ init_task_work(&ve->task_wait_work, NULL);
#ifdef CONFIG_AIO
spin_lock_init(&ve->aio_nr_lock);
@@ -745,6 +752,11 @@ static int ve_can_attach(struct cgroup *cg, struct
cgroup_taskset *tset)
} else
return -EINVAL;
+ /* Attaching in process? */
+ if (ve->task_wait_work.func != NULL)
+ return -EBUSY;
+ smp_mb(); /* Pairs with smp_mb() in task_wait_work() */
+
return 0;
}
@@ -753,6 +765,23 @@ static void ve_update_cpuid_faulting(void *dummy)
set_cpuid_faulting(!ve_is_super(get_exec_env()));
}
+static void task_attach_work(struct callback_head *head)
+{
+ struct ve_struct *ve = container_of(head, struct ve_struct,
task_attach_work);
+
+ current->task_ve = ve;
+ complete(&ve->task_completion);
+}
+
+static void task_wait_work(struct callback_head *head)
+{
+ struct ve_struct *ve = container_of(head, struct ve_struct,
task_wait_work);
+
+ wait_for_completion(&ve->task_completion);
+ smp_mb(); /* Pairs with smp_mb() in ve_can_attach() */
+ init_task_work(&ve->task_wait_work, NULL);
+}
+
static void ve_attach(struct cgroup *cg, struct cgroup_taskset *tset)
{
struct ve_struct *ve = cgroup_ve(cg);
@@ -770,7 +799,14 @@ static void ve_attach(struct cgroup *cg, struct
cgroup_taskset *tset)
/* Leave parent exec domain */
task->parent_exec_id--;
- task->task_ve = ve;
+ if (cgroup_taskset_first(tset) == current) {
+ task->task_ve = ve;
+ } else {
+ init_completion(&ve->task_completion);
+ task_work_add(task, &ve->task_attach_work, true);
+ init_task_work(&ve->task_wait_work, task_wait_work);
+ task_work_add(current, &ve->task_wait_work, false);
+ }
}
/* Adjust cpuid faulting */
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] [PATCH RH7 1/9] Port: diff-fence-watchdog-introduce-fencing-watchdog-for-HA-cluster-3
On Tue, Nov 17, 2015 at 10:46:02AM +0300, Pavel Tikhomirov wrote: > >diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h > >index de656ac..1ae9a5c 100644 > >--- a/arch/x86/include/asm/vvar.h > >+++ b/arch/x86/include/asm/vvar.h > >@@ -45,6 +45,7 @@ > > > > DECLARE_VVAR(0, volatile unsigned long, jiffies) > > DECLARE_VVAR(16, int, vgetcpu_mode) > >+DECLARE_VVAR(64, volatile unsigned long, fence_wdog_jiffies64) > > DECLARE_VVAR(128, struct vsyscall_gtod_data, vsyscall_gtod_data) > > > > #undef DECLARE_VVAR > > I couldn't find reason why here are such big offsets between variables in > commit messages, so I asked Andy Lutomirski, who introduced vvar.h, and he > said that there is no good reason now, and he put variables like this to > keep them cacheline-aligned and to avoid worrying about space - "there's 4k > of space, so keeping everything compact serves no purpose." Ok, thanks. > > -- > Best regards, Tikhomirov Pavel > Software Developer, Odin. ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH rh7 2/2] kasan: fix kmemleak false-positive in kasan_module_alloc()
Kmemleak reports the following leak:
unreferenced object 0xfbfff41ea000 (size 20480):
comm "modprobe", pid 65199, jiffies 4298875551 (age 542.568s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
backtrace:
[] kmemleak_alloc+0x4e/0xc0
[] __vmalloc_node_range+0x4b8/0x740
[] kasan_module_alloc+0x72/0xc0
[] module_alloc+0x78/0xb0
[] module_alloc_update_bounds+0x14/0x70
[] layout_and_allocate+0x16f4/0x3c90
[] load_module+0x2ff/0x6690
[] SyS_finit_module+0x136/0x170
[] system_call_fastpath+0x16/0x1b
[] 0x
kasan_module_alloc() allocates shadow memory for module and frees it on module
unloading. But it doesn't store the pointer to allocated shadow memory because
it could be calculated from the shadowed address, i.e.
kasan_mem_to_shadow(addr).
Since kmemleak cannot find pointer to allocated shadow, it thinks that memory
leaked.
Tell kmemleak that this is not a leak.
https://jira.sw.ru/browse/PSBM-41328
Signed-off-by: Andrey Ryabinin
---
mm/kasan/kasan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index d6798bc..8853b7e 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -425,6 +426,7 @@ int kasan_module_alloc(void *addr, size_t size)
if (ret) {
find_vm_area(addr)->flags |= VM_KASAN;
+ kmemleak_not_leak(ret);
return 0;
}
--
2.4.10
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH rh7 1/2] include/linux/kmemleak.h: needs slab.h
From: Andrew Morton include/linux/kmemleak.h: In function 'kmemleak_alloc_recursive': include/linux/kmemleak.h:43: error: 'SLAB_NOLEAKTRACE' undeclared (first use in this function) Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds (cherry picked from commit 66f2ca7e3f59312888131546176b42d6e248558a) Signed-off-by: Andrey Ryabinin --- include/linux/kmemleak.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/kmemleak.h b/include/linux/kmemleak.h index 2a5e554..3345de3 100644 --- a/include/linux/kmemleak.h +++ b/include/linux/kmemleak.h @@ -21,6 +21,8 @@ #ifndef __KMEMLEAK_H #define __KMEMLEAK_H +#include + #ifdef CONFIG_DEBUG_KMEMLEAK extern void kmemleak_init(void) __ref; -- 2.4.10 ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
