Re: [Devel] [PATCH 3/3] ploop: fixup FORCE_{FLUSH,FUA} handling

Dima, I agree that the ploop barrier code is broken in many ways, but I don't think the patch actually fixes it. I hope you would agree that completion of REQ_FUA guarantees only landing that particular bio to the disk; it says nothing about flushing previously submitted (and completed)

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

Hi, Vladimir! Thanks for a quick response. I created JIRA issue and uploaded the dumps. All the information is included into JIRA issue: https://bugs.openvz.org/browse/OVZ-6756 On Wed, Jun 15, 2016 at 11:47 AM, Vladimir Davydov wrote: > Hi, > > Thanks for the report.

Re: [Devel] [PATCH 1/3] ploop: skip redundant fsync for REQ_FUA in post_submit

ACK-ed, but see a minor nit below On 06/15/2016 07:49 AM, Dmitry Monakhov wrote: Signed-off-by: Dmitry Monakhov --- drivers/block/ploop/io_direct.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git

Re: [Devel] [PATCH 2/3] ploop: deadcode cleanup

Acked-by: Maxim Patlasov On 06/15/2016 07:49 AM, Dmitry Monakhov wrote: (rw & REQ_FUA) branch is impossible because REQ_FUA was cleared line above. Logic was moved to ploop_req_delay_fua_possible() long time ago. Signed-off-by: Dmitry Monakhov

[Devel] [PATCH 3/3] ploop: fixup FORCE_{FLUSH,FUA} handling

barrier code is broken in many ways: Currently only ->dio_submit() handles PLOOP_REQ_FORCE_{FLUSH,FUA} correctly. But request also can goes though ->dio_submit_alloc()->dio_submit_pad and write_page (for indexes) So in case of grow_dev we have following sequance: E_RELOC_DATA_READ:

[Devel] [PATCH 2/3] ploop: deadcode cleanup

(rw & REQ_FUA) branch is impossible because REQ_FUA was cleared line above. Logic was moved to ploop_req_delay_fua_possible() long time ago. Signed-off-by: Dmitry Monakhov --- drivers/block/ploop/io_direct.c | 9 - 1 file changed, 9 deletions(-) diff --git

[Devel] [PATCH 1/3] ploop: skip redundant fsync for REQ_FUA in post_submit

Signed-off-by: Dmitry Monakhov --- drivers/block/ploop/io_direct.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/drivers/block/ploop/io_direct.c b/drivers/block/ploop/io_direct.c index b844a80..74a554a 100644 ---

[Devel] [NEW KERNEL] 3.10.0-327.18.2.vz7.14.15 (rhel7)

Changelog: OpenVZ kernel rh7-3.10.0-327.18.2.vz7.14.15 * vtty: Container's offline console can be opened before a Container start, survives start/stop/cpt/rst cycles * fs: deny umounting rootfs * sysrq: correct the fix to avoid cpu soft lockups on long print triggered by sysrq * ploop: fix

[Devel] [PATCH RHEL7 COMMIT] ve/vtty: Don't free console mapping until no clients left

The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git after rh7-3.10.0-327.18.2.vz7.14.14 --> commit a9532c96e6a0c64fbb4a128ba6ca99b9081e85cc Author: Cyrill Gorcunov Date: Wed Jun 15 13:32:23

[Devel] [PATCH RHEL7 COMMIT] fs: do not allow rootfs umount

The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git after rh7-3.10.0-327.18.2.vz7.14.14 --> commit 0ae9e4e30b14404b570f62f83220637506be6376 Author: Vasily Averin Date: Wed Jun 15 13:16:38 2016

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

Hi, Thanks for the report. Could 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

Re: [Devel] [PATCH rh7 0/6] ploop: push_backup: implement expiration timeout

Dima, please review the patchset. -- Best regards, Konstantin Khorenko, Virtuozzo Linux Kernel Team On 06/15/2016 03:50 AM, Maxim Patlasov wrote: If a ploop request waits for userspace backup tool attention for more then plo->tune.push_backup_timeout (42 secs by default), the whole

[Devel] [PATCH RHEL7 COMMIT] ms/kernel/sysrq: restore touch_nmi_watchdog() in show_state_filter()

The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git after rh7-3.10.0-327.18.2.vz7.14.14 --> commit 3eada65cb70c5f2c773fcac7aabc72de5f768bac Author: Andrey Ryabinin Date: Wed Jun 15

[Devel] [PATCH RHEL7 COMMIT] ploop: fix gendisk disk_stats to be seen on partition

The commit is pushed to "branch-rh7-3.10.0-327.18.2.vz7.14.x-ovz" and will appear at https://src.openvz.org/scm/ovz/vzkernel.git after rh7-3.10.0-327.18.2.vz7.14.14 --> commit fc4dd8e6d4df14e5e09b6dacac74fe903d95c929 Author: Maxim Patlasov Date: Wed Jun 15 12:38:54

[Devel] [PATCH 3/3] netlink/diag: report flags for netlink sockets

We need to know flags for dumping and restoring netlink sockets. All flags except NDIAG_FLAG_CB_RUNNING can be received with help of getsockopt(), but in this case we need a socket descriptor and we need to call getsockopt() to get each flag. With this chages we will be able to show netlink

[Devel] [PATCH 2/3] netlink: add an ability to restore messages in a receive queue

This patch adds an repair mode for netlink sockets. sendmsg queues messages into a receive queue if a socket is in the repair mode. --- include/uapi/linux/netlink.h | 19 ++--- net/netlink/af_netlink.c | 51 +++- 2 files changed, 47

[Devel] [PATCH net-next 0/3] [RFC] netlink: prepare to dump and restore data from a receive queue

CRIU can dump queued data for unix and tcp sockets, now it's time for netlink sockets. Here are there questions. * How to dump data from a receive queue We can set peeking offset like we do for unix sockets. * How to restore data back to a receive queue I suggest to add a repair mode like we

[Devel] [PATCH 1/3] netlink: allow to set peeking offset for sockets

This allows us to read socket's queue without removing skbs from it. The same logic was implemented for unix and inet sockets and we use this to dump and restore sockets in CRIU. Here is a question whether sk_peek_off has to be protected by locks. Currently it isn't protected and an user who