Re: [Devel] WARNING at mm/slub.c
On 3/16/17, Denis Kirjanov wrote: > Hi guys, > > with the kernel rh7-3.10.0-327.36.1.vz7.18.7 we're seeing the > following WARNING while running LTP test suite: > > [11796.576981] WARNING: at mm/slub.c:1252 > slab_pre_alloc_hook.isra.42.part.43+0x15/0x17() > > [11796.591008] Call Trace: > [11796.592065] [] dump_stack+0x19/0x1b > [11796.593076] [] warn_slowpath_common+0x70/0xb0 > [11796.594228] [] warn_slowpath_null+0x1a/0x20 > [11796.595442] [] > slab_pre_alloc_hook.isra.42.part.43+0x15/0x17 > [11796.596686] [] kmem_cache_alloc_trace+0x58/0x230 > [11796.597965] [] ? kmapset_new+0x1e/0x50 > [11796.599224] [] kmapset_new+0x1e/0x50 > [11796.600433] [] __sysfs_add_one+0x4a/0xb0 > [11796.601431] [] sysfs_add_one+0x1b/0xd0 > [11796.602451] [] sysfs_add_file_mode+0xb7/0x100 > [11796.603449] [] sysfs_create_file+0x2a/0x30 > [11796.604461] [] kobject_add_internal+0x16c/0x2f0 > [11796.605503] [] kobject_add+0x75/0xd0 > [11796.606627] [] ? kmem_cache_alloc_trace+0x207/0x230 > [11796.607655] [] __link_block_group+0xe1/0x120 [btrfs] > [11796.608634] [] btrfs_make_block_group+0x150/0x270 > [btrfs] > [11796.609701] [] __btrfs_alloc_chunk+0x67f/0x8a0 > [btrfs] > [11796.610756] [] btrfs_alloc_chunk+0x34/0x40 [btrfs] > [11796.611800] [] do_chunk_alloc+0x23f/0x410 [btrfs] > [11796.612954] [] > btrfs_check_data_free_space+0xea/0x280 [btrfs] > [11796.614008] [] __btrfs_buffered_write+0x151/0x5c0 > [btrfs] > [11796.615153] [] btrfs_file_aio_write+0x246/0x560 > [btrfs] > [11796.616141] [] ? > __mem_cgroup_commit_charge+0x152/0x350 > [11796.617220] [] do_sync_write+0x90/0xe0 > [11796.618253] [] vfs_write+0xbd/0x1e0 > [11796.619224] [] SyS_write+0x7f/0xe0 > [11796.620185] [] system_call_fastpath+0x16/0x1b > [11796.621145] ---[ end trace 1437311f89b9e3c6 ]--- > Guys, I've found your commit: commit 149819fef38230c95f4d6c644061bc8b0dcdd51d Author: Vladimir Davydov Date: Fri Jun 5 13:20:02 2015 +0400 mm/fs: Port diff-mm-debug-memallocation-caused-fs-reentrance Enable the debug once again, as the issue it found has been fixed: https://jira.sw.ru/browse/PSBM-34112 Previous commit: 255427905323ac97a3c9b2d5acb2bf21ea2b31f6. Author: Dmitry Monakhov Email: dmonak...@openvz.org Subject: mm: debug memallocation caused fs reentrance Date: Sun, 9 Nov 2014 11:53:14 +0400 But I can't open a link to figure out the original reason for the patch. > Thanks! > ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] WARNING at mm/slub.c
On 03/20/2017 11:11 AM, Denis Kirjanov wrote: On 3/16/17, Denis Kirjanov wrote: Hi guys, with the kernel rh7-3.10.0-327.36.1.vz7.18.7 we're seeing the following WARNING while running LTP test suite: [11796.576981] WARNING: at mm/slub.c:1252 slab_pre_alloc_hook.isra.42.part.43+0x15/0x17() [11796.591008] Call Trace: [11796.592065] [] dump_stack+0x19/0x1b [11796.593076] [] warn_slowpath_common+0x70/0xb0 [11796.594228] [] warn_slowpath_null+0x1a/0x20 [11796.595442] [] slab_pre_alloc_hook.isra.42.part.43+0x15/0x17 [11796.596686] [] kmem_cache_alloc_trace+0x58/0x230 [11796.597965] [] ? kmapset_new+0x1e/0x50 [11796.599224] [] kmapset_new+0x1e/0x50 [11796.600433] [] __sysfs_add_one+0x4a/0xb0 [11796.601431] [] sysfs_add_one+0x1b/0xd0 [11796.602451] [] sysfs_add_file_mode+0xb7/0x100 [11796.603449] [] sysfs_create_file+0x2a/0x30 [11796.604461] [] kobject_add_internal+0x16c/0x2f0 [11796.605503] [] kobject_add+0x75/0xd0 [11796.606627] [] ? kmem_cache_alloc_trace+0x207/0x230 [11796.607655] [] __link_block_group+0xe1/0x120 [btrfs] [11796.608634] [] btrfs_make_block_group+0x150/0x270 [btrfs] [11796.609701] [] __btrfs_alloc_chunk+0x67f/0x8a0 [btrfs] [11796.610756] [] btrfs_alloc_chunk+0x34/0x40 [btrfs] [11796.611800] [] do_chunk_alloc+0x23f/0x410 [btrfs] [11796.612954] [] btrfs_check_data_free_space+0xea/0x280 [btrfs] [11796.614008] [] __btrfs_buffered_write+0x151/0x5c0 [btrfs] [11796.615153] [] btrfs_file_aio_write+0x246/0x560 [btrfs] [11796.616141] [] ? __mem_cgroup_commit_charge+0x152/0x350 [11796.617220] [] do_sync_write+0x90/0xe0 [11796.618253] [] vfs_write+0xbd/0x1e0 [11796.619224] [] SyS_write+0x7f/0xe0 [11796.620185] [] system_call_fastpath+0x16/0x1b [11796.621145] ---[ end trace 1437311f89b9e3c6 ]--- Guys, I've found your commit: commit 149819fef38230c95f4d6c644061bc8b0dcdd51d Author: Vladimir Davydov Date: Fri Jun 5 13:20:02 2015 +0400 mm/fs: Port diff-mm-debug-memallocation-caused-fs-reentrance Enable the debug once again, as the issue it found has been fixed: https://jira.sw.ru/browse/PSBM-34112 Previous commit: 255427905323ac97a3c9b2d5acb2bf21ea2b31f6. Author: Dmitry Monakhov Email: dmonak...@openvz.org Subject: mm: debug memallocation caused fs reentrance Date: Sun, 9 Nov 2014 11:53:14 +0400 But I can't open a link to figure out the original reason for the patch. Did not get your question. If the question is about inability to open a link, then sorry for that but it's an internal jira id. If this is an indirect question about how the issue has been fixed so we could return back the debug, then there were a bunch of patches ported from mainstream, probably the one you needed is: commit 4fdb5543183d027a19805b72025b859af73d0863 Author: Dmitry Monakhov Date: Tue Nov 25 13:08:04 2014 -0500 ext4: cleanup GFP flags inside resize path If the question was "why the debug patch was added at all?", then Dima can explain. -- Best regards, Konstantin Khorenko, Virtuozzo Linux Kernel Team ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
Re: [Devel] WARNING at mm/slub.c
Denis Kirjanov writes: > On 3/16/17, Denis Kirjanov wrote: >> Hi guys, >> >> with the kernel rh7-3.10.0-327.36.1.vz7.18.7 we're seeing the >> following WARNING while running LTP test suite: >> >> [11796.576981] WARNING: at mm/slub.c:1252 >> slab_pre_alloc_hook.isra.42.part.43+0x15/0x17() >> >> [11796.591008] Call Trace: >> [11796.592065] [] dump_stack+0x19/0x1b >> [11796.593076] [] warn_slowpath_common+0x70/0xb0 >> [11796.594228] [] warn_slowpath_null+0x1a/0x20 >> [11796.595442] [] >> slab_pre_alloc_hook.isra.42.part.43+0x15/0x17 >> [11796.596686] [] kmem_cache_alloc_trace+0x58/0x230 >> [11796.597965] [] ? kmapset_new+0x1e/0x50 >> [11796.599224] [] kmapset_new+0x1e/0x50 >> [11796.600433] [] __sysfs_add_one+0x4a/0xb0 >> [11796.601431] [] sysfs_add_one+0x1b/0xd0 >> [11796.602451] [] sysfs_add_file_mode+0xb7/0x100 >> [11796.603449] [] sysfs_create_file+0x2a/0x30 >> [11796.604461] [] kobject_add_internal+0x16c/0x2f0 >> [11796.605503] [] kobject_add+0x75/0xd0 >> [11796.606627] [] ? kmem_cache_alloc_trace+0x207/0x230 >> [11796.607655] [] __link_block_group+0xe1/0x120 [btrfs] >> [11796.608634] [] btrfs_make_block_group+0x150/0x270 >> [btrfs] >> [11796.609701] [] __btrfs_alloc_chunk+0x67f/0x8a0 >> [btrfs] >> [11796.610756] [] btrfs_alloc_chunk+0x34/0x40 [btrfs] >> [11796.611800] [] do_chunk_alloc+0x23f/0x410 [btrfs] >> [11796.612954] [] >> btrfs_check_data_free_space+0xea/0x280 [btrfs] >> [11796.614008] [] __btrfs_buffered_write+0x151/0x5c0 >> [btrfs] >> [11796.615153] [] btrfs_file_aio_write+0x246/0x560 >> [btrfs] >> [11796.616141] [] ? >> __mem_cgroup_commit_charge+0x152/0x350 >> [11796.617220] [] do_sync_write+0x90/0xe0 >> [11796.618253] [] vfs_write+0xbd/0x1e0 >> [11796.619224] [] SyS_write+0x7f/0xe0 >> [11796.620185] [] system_call_fastpath+0x16/0x1b >> [11796.621145] ---[ end trace 1437311f89b9e3c6 ]--- >> > > Guys, I've found your commit: > > commit 149819fef38230c95f4d6c644061bc8b0dcdd51d > Author: Vladimir Davydov > Date: Fri Jun 5 13:20:02 2015 +0400 > > mm/fs: Port diff-mm-debug-memallocation-caused-fs-reentrance > > Enable the debug once again, as the issue it found has been fixed: > https://jira.sw.ru/browse/PSBM-34112 > > Previous commit: 255427905323ac97a3c9b2d5acb2bf21ea2b31f6. > > Author: Dmitry Monakhov > Email: dmonak...@openvz.org > Subject: mm: debug memallocation caused fs reentrance > Date: Sun, 9 Nov 2014 11:53:14 +0400 > > But I can't open a link to figure out the original reason for the patch. Originally we found that [] dump_stack+0x19/0x1b [] warn_slowpath_common+0x61/0x80 [] warn_slowpath_null+0x1a/0x20 [] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17 [] kmem_cache_alloc+0x55/0x210 [] ? ext4_mb_add_groupinfo+0xe1/0x230 [ext4] [] ext4_mb_add_groupinfo+0xe1/0x230 [ext4] [] ext4_flex_group_add+0xba6/0x14b0 [ext4] [] ? ext4_bg_num_gdb+0x79/0x90 [ext4] [] ext4_resize_fs+0x76d/0xe40 [ext4] [] ext4_ioctl+0xded/0x1110 [ext4] [] ? do_filp_open+0x4b/0xb0 [] do_vfs_ioctl+0x255/0x4f0 [] ? __fd_install+0x47/0x60 [] SyS_ioctl+0x54/0xa0 [] system_call_fastpath+0x16/0x1b This is pure bug, which resut in deadlock, or fscorruption. which I've fixed here https://github.com/torvalds/linux/commit/4fdb5543183d027a19805b72025b859af73d0863 I've realized that his is whole class of locking issues which should be detected on runtume that is why I've add this warning, I also send the patch to mainstream http://www.spinics.net/lists/linux-btrfs/msg39034.html which note that btrfs definitely has fs-reentrance issues http://www.spinics.net/lists/linux-btrfs/msg39035.html Dave does not like the way I've do the detection so patch was not committed, but it exists in our tree, It is resonanable to replace WARN_ON with WARN_ON_ONCE to prevent spamming. I'll send a patch > > > >> Thanks! >> ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH] fs: Prevent massive warn spamming
Even if detection spots potential bug, is it not good to bloat kmsg. WARN_ON_ONCE is enought to detect exact calltrace. Signed-off-by: Dmitry Monakhov --- mm/page_alloc.c | 2 +- mm/slab.c | 4 ++-- mm/slub.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b799171..d6a04f5 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3150,7 +3150,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, lockdep_trace_alloc(gfp_mask); might_sleep_if(gfp_mask & __GFP_WAIT); - WARN_ON((gfp_mask & __GFP_FS) && current->journal_info); + WARN_ON_ONCE((gfp_mask & __GFP_FS) && current->journal_info); if (should_fail_alloc_page(gfp_mask, order)) return NULL; diff --git a/mm/slab.c b/mm/slab.c index f0e4b79..4f0c22e 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -3343,7 +3343,7 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags, int nodeid, flags &= gfp_allowed_mask; lockdep_trace_alloc(flags); - WARN_ON((flags & __GFP_FS) && current->journal_info); + WARN_ON_ONCE((flags & __GFP_FS) && current->journal_info); if (slab_should_failslab(cachep, flags)) return NULL; @@ -3433,7 +3433,7 @@ slab_alloc(struct kmem_cache *cachep, gfp_t flags, unsigned long caller) flags &= gfp_allowed_mask; lockdep_trace_alloc(flags); - WARN_ON((flags & __GFP_FS) && current->journal_info); + WARN_ON_ONCE((flags & __GFP_FS) && current->journal_info); if (slab_should_failslab(cachep, flags)) return NULL; diff --git a/mm/slub.c b/mm/slub.c index fcebd14..280adf6 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1266,7 +1266,7 @@ static inline int slab_pre_alloc_hook(struct kmem_cache *s, gfp_t flags) flags &= gfp_allowed_mask; lockdep_trace_alloc(flags); might_sleep_if(flags & __GFP_WAIT); - WARN_ON((flags & __GFP_FS) && current->journal_info); + WARN_ON_ONCE((flags & __GFP_FS) && current->journal_info); return should_failslab(s->object_size, flags, s->flags); } -- 1.8.3.1 ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RHEL7 COMMIT] mm/fs: Prevent massive warn spamming about memallocation caused fs reentrance
The commit is pushed to "branch-rh7-3.10.0-514.10.2.vz7.29.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-514.10.2.vz7.29.5
-->
commit b401c051bc8670f0a465e0d4893972808263622f
Author: Dmitry Monakhov
Date: Mon Mar 20 17:41:36 2017 +0400
mm/fs: Prevent massive warn spamming about memallocation caused fs
reentrance
Even if detection spots potential bug, is it not good to bloat kmsg.
WARN_ON_ONCE is enough to detect exact calltrace.
To be merged with 915bded ("mm/fs: Port
diff-mm-debug-memallocation-caused-fs-reentrance").
Signed-off-by: Dmitry Monakhov
---
mm/page_alloc.c | 2 +-
mm/slab.c | 4 ++--
mm/slub.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ff163b2..afac33e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3155,7 +3155,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order,
lockdep_trace_alloc(gfp_mask);
might_sleep_if(gfp_mask & __GFP_WAIT);
- WARN_ON((gfp_mask & __GFP_FS) && current->journal_info);
+ WARN_ON_ONCE((gfp_mask & __GFP_FS) && current->journal_info);
if (should_fail_alloc_page(gfp_mask, order))
return NULL;
diff --git a/mm/slab.c b/mm/slab.c
index f0e4b79..4f0c22e 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3343,7 +3343,7 @@ slab_alloc_node(struct kmem_cache *cachep, gfp_t flags,
int nodeid,
flags &= gfp_allowed_mask;
lockdep_trace_alloc(flags);
- WARN_ON((flags & __GFP_FS) && current->journal_info);
+ WARN_ON_ONCE((flags & __GFP_FS) && current->journal_info);
if (slab_should_failslab(cachep, flags))
return NULL;
@@ -3433,7 +3433,7 @@ slab_alloc(struct kmem_cache *cachep, gfp_t flags,
unsigned long caller)
flags &= gfp_allowed_mask;
lockdep_trace_alloc(flags);
- WARN_ON((flags & __GFP_FS) && current->journal_info);
+ WARN_ON_ONCE((flags & __GFP_FS) && current->journal_info);
if (slab_should_failslab(cachep, flags))
return NULL;
diff --git a/mm/slub.c b/mm/slub.c
index fcebd14..280adf6 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1266,7 +1266,7 @@ static inline int slab_pre_alloc_hook(struct kmem_cache
*s, gfp_t flags)
flags &= gfp_allowed_mask;
lockdep_trace_alloc(flags);
might_sleep_if(flags & __GFP_WAIT);
- WARN_ON((flags & __GFP_FS) && current->journal_info);
+ WARN_ON_ONCE((flags & __GFP_FS) && current->journal_info);
return should_failslab(s->object_size, flags, s->flags);
}
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RHEL7 COMMIT] kvm: fix RH rebase fallouts: wake up SynIC message waiters
The commit is pushed to "branch-rh7-3.10.0-514.10.2.vz7.29.x-ovz" and will
appear at https://src.openvz.org/scm/ovz/vzkernel.git
after rh7-3.10.0-514.10.2.vz7.29.5
-->
commit b0f4bdc62001156ff1e402676e49cec59df3934f
Author: Roman Kagan
Date: Mon Mar 20 17:45:47 2017 +0400
kvm: fix RH rebase fallouts: wake up SynIC message waiters
When rebasing to a more recent RH upstream, the split nature of
kvm_arch_irq_routing_update / kvm_arch_post_irq_routing_update was lost.
As a result, in current VZ kernels the ACK notifiers aren't attached to
Hyper-V synthetic interrupts, which causes the userspace that observed
contention on the SynIC message page and went to sleep, to never be
woken up again.
Signed-off-by: Roman Kagan
---
arch/x86/kvm/irq_comm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/irq_comm.c b/arch/x86/kvm/irq_comm.c
index c2d61d8..2bfb9a6 100644
--- a/arch/x86/kvm/irq_comm.c
+++ b/arch/x86/kvm/irq_comm.c
@@ -399,11 +399,11 @@ int kvm_arch_set_irq(struct kvm_kernel_irq_routing_entry
*irq, struct kvm *kvm,
}
}
-void kvm_arch_irq_routing_update(struct kvm *kvm)
+void kvm_arch_post_irq_routing_update(struct kvm *kvm)
{
- if (ioapic_in_kernel(kvm) || !irqchip_in_kernel(kvm))
+ if (!irqchip_split(kvm))
return;
- kvm_hv_irq_routing_update(kvm);
+ kvm_make_scan_ioapic_request(kvm);
}
void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64 *eoi_exit_bitmap)
@@ -435,3 +435,8 @@ void kvm_scan_ioapic_routes(struct kvm_vcpu *vcpu, u64
*eoi_exit_bitmap)
}
srcu_read_unlock(&kvm->irq_srcu, idx);
}
+
+void kvm_arch_irq_routing_update(struct kvm *kvm)
+{
+ kvm_hv_irq_routing_update(kvm);
+}
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH RH7 2/2] ve/net: restrict number of net devices for CT
Description from Solar:
"Adding thousands of network interfaces (aliases) in a container causes
moderately slow container stop times (1 minute observed) with many
kernel messages like "stop ploop26375 failed (holders=1)" appearing.
A safety limit on the number of network interfaces in a container
should be introduced by default, especially considering that there
might be (or might be introduced later) ways to add network interfaces
faster (thereby making the attack more powerful and quicker to carry
out)."
In default_device_exit_batch we call dev->rtnl_link_ops->dellink for
each link on cleanup_net. So more links in CT means it's slower stop.
On number of network(veth) interfaces ~1, CT stop time is ~1min.
Make netif_avail_nr/netif_max_nr pair on ve cgroup to restrict number
of interfaces in CT anologious to netns limit. With default 256 network
devices (most of them are veth pairs) containter stop time will be ~3sec
(~1sec for removing network interfaces).
https://jira.sw.ru/browse/PSBM-51354
Signed-off-by: Pavel Tikhomirov
---
include/linux/ve.h | 3 +++
kernel/ve/ve.c | 28
net/core/dev.c | 17 +++--
3 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/include/linux/ve.h b/include/linux/ve.h
index edff7e4..708c6d3 100644
--- a/include/linux/ve.h
+++ b/include/linux/ve.h
@@ -120,6 +120,8 @@ struct ve_struct {
#endif
atomic_tnetns_avail_nr;
int netns_max_nr;
+ atomic_tnetif_avail_nr;
+ int netif_max_nr;
/* Number of mounts. May become unbalanced if VE0 mounts something
* and the VE unmounts it. This is acceptable.
*/
@@ -138,6 +140,7 @@ struct ve_devmnt {
};
#define NETNS_MAX_NR_DEFAULT 256 /* number of net-namespaces per-VE */
+#define NETIF_MAX_NR_DEFAULT 256 /* number of net-interfaces per-VE */
#define VE_MEMINFO_DEFAULT 1 /* default behaviour */
#define VE_MEMINFO_SYSTEM 0 /* disable meminfo virtualization */
diff --git a/kernel/ve/ve.c b/kernel/ve/ve.c
index 67b7882..a17b048 100644
--- a/kernel/ve/ve.c
+++ b/kernel/ve/ve.c
@@ -81,6 +81,8 @@ struct ve_struct ve0 = {
.mnt_nr = 0,
.netns_avail_nr = ATOMIC_INIT(INT_MAX),
.netns_max_nr = INT_MAX,
+ .netif_avail_nr = ATOMIC_INIT(INT_MAX),
+ .netif_max_nr = INT_MAX,
};
EXPORT_SYMBOL(ve0);
@@ -653,6 +655,9 @@ static struct cgroup_subsys_state *ve_create(struct cgroup
*cg)
atomic_set(&ve->netns_avail_nr, NETNS_MAX_NR_DEFAULT);
ve->netns_max_nr = NETNS_MAX_NR_DEFAULT;
+ atomic_set(&ve->netif_avail_nr, NETIF_MAX_NR_DEFAULT);
+ ve->netif_max_nr = NETIF_MAX_NR_DEFAULT;
+
do_init:
init_rwsem(&ve->op_sem);
INIT_LIST_HEAD(&ve->devices);
@@ -1191,6 +1196,8 @@ enum {
VE_CF_PID_MAX,
VE_CF_NETNS_MAX_NR,
VE_CF_NETNS_NR,
+ VE_CF_NETIF_MAX_NR,
+ VE_CF_NETIF_NR,
};
static int ve_ts_read(struct cgroup *cg, struct cftype *cft, struct seq_file
*m)
@@ -1260,6 +1267,10 @@ static u64 ve_read_u64(struct cgroup *cg, struct cftype
*cft)
return cgroup_ve(cg)->netns_max_nr;
else if (cft->private == VE_CF_NETNS_NR)
return atomic_read(&cgroup_ve(cg)->netns_avail_nr);
+ else if (cft->private == VE_CF_NETIF_MAX_NR)
+ return cgroup_ve(cg)->netif_max_nr;
+ else if (cft->private == VE_CF_NETIF_NR)
+ return atomic_read(&cgroup_ve(cg)->netif_avail_nr);
return 0;
}
@@ -1346,6 +1357,11 @@ static int _ve_write_u64(struct cgroup *cg, struct
cftype *cft,
ve->netns_max_nr = value;
atomic_add(delta, &ve->netns_avail_nr);
+ } else if (cft->private == VE_CF_NETIF_MAX_NR) {
+ int delta = value - ve->netif_max_nr;
+
+ ve->netif_max_nr = value;
+ atomic_add(delta, &ve->netif_avail_nr);
}
up_write(&ve->op_sem);
return 0;
@@ -1451,6 +1467,18 @@ static struct cftype ve_cftypes[] = {
.read_u64 = ve_read_u64,
.private= VE_CF_NETNS_NR,
},
+ {
+ .name = "netif_max_nr",
+ .flags = CFTYPE_NOT_ON_ROOT,
+ .read_u64 = ve_read_u64,
+ .write_u64 = ve_write_u64,
+ .private= VE_CF_NETIF_MAX_NR,
+ },
+ {
+ .name = "netif_avail_nr",
+ .read_u64 = ve_read_u64,
+ .private= VE_CF_NETIF_NR,
+ },
{ }
};
diff --git a/net/core/dev.c b/net/core/dev.c
index 40e5a97..12de79c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6605,6 +6605,10 @@ int register_netdevice(struct net_device *
[Devel] [PATCH RH7 1/2] ubc/net: remove excess header
https://jira.sw.ru/browse/PSBM-51354 Signed-off-by: Pavel Tikhomirov --- net/core/dev.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 744179a..40e5a97 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -140,7 +140,6 @@ #include "net-sysfs.h" #include -#include /* Instead of increasing this, you should create a hash table. */ #define MAX_GRO_SKBS 8 -- 2.9.3 ___ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel
