[Devel] [PATCH] jbd2: fix incorrect unlock on j_list_lock

2016-12-20 Thread Anatoly Stepanov
From: Taesoo Kim When 'jh->b_transaction == transaction' (asserted by below) J_ASSERT_JH(jh, (jh->b_transaction == transaction || ... 'journal->j_list_lock' will be incorrectly unlocked, since the the lock is aquired only at the end of if / else-if statements (missing the else case). Signed-

[Devel] [PATCH] jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path

2016-12-20 Thread Anatoly Stepanov
From: OGAWA Hirofumi On umount path, jbd2_journal_destroy() writes latest transaction ID (->j_tail_sequence) to be used at next mount. The bug is that ->j_tail_sequence is not holding latest transaction ID in some cases. So, at next mount, there is chance to conflict with remaining (not overwrit

[Devel] Important fixes for jbd2

2016-12-20 Thread Anatoly Stepanov
Hi, guys! We've found a couple important fixes for jbd2 in the vanilla kernel, please apply them to OVZ kernel Taesoo Kim (1): jbd2: fix incorrect unlock on j_list_lock fs/jbd2/transaction.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) OGAWA Hirofumi (1): jbd2: fix FS corruptio

[Devel] [PATCH rh7 3/3] net: core: attempt a single high order allocation

2016-11-01 Thread Anatoly Stepanov
) iteration. Signed-off-by: Eric Dumazet Acked-by: David Rientjes Signed-off-by: David S. Miller Signed-off-by: Anatoly Stepanov --- net/core/sock.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 763

[Devel] [PATCH rh7 1/3] net: core: use __GFP_NORETRY for high order allocations

2016-11-01 Thread Anatoly Stepanov
This is a backport of upstream (vanilla) change. Original commit: ed98df3361f059db42786c830ea96e2d18b8d4db sock_alloc_send_pskb() & sk_page_frag_refill() have a loop trying high order allocations to prepare skb with low number of fragments as this increases performance. Problem is that under mem

[Devel] [PATCH rh7 2/3] net: core: use atomic high-order allocations

2016-11-01 Thread Anatoly Stepanov
c Dumazet Cc: Chris Mason Cc: Debabrata Banerjee Signed-off-by: Shaohua Li Acked-by: Eric Dumazet Signed-off-by: David S. Miller [ luis: backported to 3.16: used davem's backport to 3.14 ] Signed-off-by: Luis Henriques Signed-off-by: Anatoly Stepanov --- net/core/sock.c | 9 +

[Devel] [PATCH rh7 0/3] net: core: optimize high-order allocations

2016-11-01 Thread Anatoly Stepanov
This patch set aims to improve high-order allocations in networking subsystem by reducing the impact on buddy allocator. This is a carbon-copy of the recent patch set, i've just set "Subject" field properly. Signed-off-by: Anatoly Stepanov Anatoly Stepanov (3): net: core: us

[Devel] [PATCH rh7] fs: add __GFP_NORETRY in alloc_fdmem

2016-10-21 Thread Anatoly Stepanov
allocate contiguous area, and fallback to vmalloc() as soon as possible. Signed-off-by: Anatoly Stepanov --- fs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/file.c b/fs/file.c index 366d9bb..3f65ba0 100644 --- a/fs/file.c +++ b/fs/file.c @@ -36,7 +36,7 @@ sta

[Devel] [PATCH rh7 0/3] net: core: optimize high-order allocations

2016-10-21 Thread Anatoly Stepanov
This patch set aims to improve high-order allocations in networking subsystem by reducing the impact on buddy allocator. This is a carbon-copy of the recent patch set, i've just set "Subject" field properly. Signed-off-by: Anatoly Stepanov Anatoly Stepanov (3): net: core: us

[Devel] [PATCH rh7 3/3] net: core: attempt a single high order allocation

2016-10-21 Thread Anatoly Stepanov
) iteration. Signed-off-by: Eric Dumazet Acked-by: David Rientjes Signed-off-by: David S. Miller Signed-off-by: Anatoly Stepanov --- net/core/sock.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 763

[Devel] [PATCH rh7 1/3] net: core: use __GFP_NORETRY for high order allocations

2016-10-21 Thread Anatoly Stepanov
This is a backport of upstream (vanilla) change. Original commit: ed98df3361f059db42786c830ea96e2d18b8d4db sock_alloc_send_pskb() & sk_page_frag_refill() have a loop trying high order allocations to prepare skb with low number of fragments as this increases performance. Problem is that under mem

[Devel] [PATCH rh7 2/3] net: core: use atomic high-order allocations

2016-10-21 Thread Anatoly Stepanov
c Dumazet Cc: Chris Mason Cc: Debabrata Banerjee Signed-off-by: Shaohua Li Acked-by: Eric Dumazet Signed-off-by: David S. Miller [ luis: backported to 3.16: used davem's backport to 3.14 ] Signed-off-by: Luis Henriques Signed-off-by: Anatoly Stepanov --- net/core/sock.c | 9 +

[Devel] [PATCH 3/3] net: core: attempt a single high order allocation

2016-10-21 Thread Anatoly Stepanov
) iteration. Signed-off-by: Eric Dumazet Acked-by: David Rientjes Signed-off-by: David S. Miller Signed-off-by: Anatoly Stepanov --- net/core/sock.c | 30 -- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/net/core/sock.c b/net/core/sock.c index 763

[Devel] [PATCH 0/3] net: core: optimize high-order allocations

2016-10-21 Thread Anatoly Stepanov
This patch set aims to improve high-order allocations in networking subsystem by reducing the impact on buddy allocator. Signed-off-by: Anatoly Stepanov Anatoly Stepanov (3): net: core: use __GFP_NORETRY for high order allocations net: core: use atomic high-order allocations net: core

[Devel] [PATCH 2/3] net: core: use atomic high-order allocations

2016-10-21 Thread Anatoly Stepanov
c Dumazet Cc: Chris Mason Cc: Debabrata Banerjee Signed-off-by: Shaohua Li Acked-by: Eric Dumazet Signed-off-by: David S. Miller [ luis: backported to 3.16: used davem's backport to 3.14 ] Signed-off-by: Luis Henriques Signed-off-by: Anatoly Stepanov --- net/core/sock.c | 9 +

[Devel] [PATCH 1/3] net: core: use __GFP_NORETRY for high order allocations

2016-10-21 Thread Anatoly Stepanov
This is a backport of upstream (vanilla) change. Original commit: ed98df3361f059db42786c830ea96e2d18b8d4db sock_alloc_send_pskb() & sk_page_frag_refill() have a loop trying high order allocations to prepare skb with low number of fragments as this increases performance. Problem is that under mem

Re: [Devel] memcg: mem_cgroup_uncharge_page() kernel panic/lockup

2016-06-15 Thread Anatoly Stepanov
ould you please > > - file a bug to bugzilla.openvz.org > > - upload the vmcore at >rsync://fe.sw.ru/f837d67c8e2ade8cee3367cb0f880268/ > > On Mon, Jun 13, 2016 at 09:24:33AM +0300, Anatoly Stepanov wrote: >> Hello everyone! >> >> We encounter an issue with me

[Devel] memcg: mem_cgroup_uncharge_page() kernel panic/lockup

2016-06-12 Thread Anatoly Stepanov
Hello everyone! We encounter an issue with mem_cgroup_uncharge_page() function, it appears quite often on our clients servers. Basically the issue sometimes leads to hard-lockup, sometimes to GP fault. Based on bug reports from clients, the problem shows up when a user process calls "execve" or