[Devel] [PATCH criu] libsoccr: ignore data in a sent queue, if a connect is closed
From: Andrei Vagin
If a connection was reseted, it can have some data in a sent queue,
a use can't read this data, so we can ignore them too.
https://jira.sw.ru/browse/PSBM-67026
Signed-off-by: Andrei Vagin
---
soccr/soccr.c | 12
1 file changed, 12 insertions(+)
diff --git a/soccr/soccr.c b/soccr/soccr.c
index 48469aaab..bdf92d721 100644
--- a/soccr/soccr.c
+++ b/soccr/soccr.c
@@ -198,6 +198,18 @@ static int refresh_sk(struct libsoccr_sk *sk, struct
libsoccr_sk_data *data, str
data->unsq_len = size;
+ if (data->state == TCP_CLOSE) {
+ /* A connection could be reseted. In thise case a sent queue
+* may contain some data. A user can't read this data, so let's
+* ignore them. Otherwise we will need to add a logic whether
+* the send queue contains a fin packet or not and decide
whether
+* a fin or reset packet has to be sent to restore a state
+*/
+
+ data->unsq_len = 0;
+ data->outq_len = 0;
+ }
+
/* Don't account the fin packet. It doesn't countain real data. */
if ((1 << data->state) & (SNDQ_FIRST_FIN | SNDQ_SECOND_FIN)) {
if (data->outq_len)
--
2.13.3
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH] venet: do not destroy VE IP on shutdown hook if NFS is allowed
Mounts are destroyed asynchroniously and thus can race with VE IP destruction
leading to dead lock in kernel: NFS can'n be unmounted.
Fix it by skipping VE IP desctruction, is NFS feature is enabled in the
container.
https://jira.sw.ru/browse/PSBM-73614
Signed-off-by: Stanislav Kinsburskiy
---
drivers/net/venetdev.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/venetdev.c b/drivers/net/venetdev.c
index 5710792..7a546cc 100644
--- a/drivers/net/venetdev.c
+++ b/drivers/net/venetdev.c
@@ -744,10 +744,8 @@ static void venet_setup(struct net_device *dev)
SET_ETHTOOL_OPS(dev, &venet_ethtool_ops);
}
-static void veip_shutdown(void *data)
+static void veip_shutdown(struct ve_struct *ve)
{
- struct ve_struct *ve = data;
-
spin_lock(&veip_lock);
if (ve->veip) {
__venet_ext_clean(ve);
@@ -1178,8 +1176,18 @@ static struct rtnl_link_ops venet_link_ops = {
.maxtype= VENET_INFO_MAX,
};
+static void veip_shutdown_fini(void *data)
+{
+ struct ve_struct *ve = data;
+
+ if (ve->features & VE_FEATURE_NFS)
+ return;
+
+ veip_shutdown(ve);
+}
+
static struct ve_hook veip_shutdown_hook = {
- .fini = veip_shutdown,
+ .fini = veip_shutdown_fini,
.priority = HOOK_PRIO_FINISHING,
.owner = THIS_MODULE,
};
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
[Devel] [PATCH rh7] mm: issue panic() on bad page/pte bugs if panic_on_warn is set.
Bad page state bugs is serious issue. It's worth issue panic if
panic_on_warn is set to collect crash dump and catch issue earlier.
https://jira.sw.ru/browse/PSBM-70168
Signed-off-by: Andrey Ryabinin
---
mm/memory.c | 2 ++
mm/page_alloc.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index c30a042cebf5..b1c6968f1746 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -733,6 +733,8 @@ static void print_bad_pte(struct vm_area_struct *vma,
unsigned long addr,
vma->vm_file->f_op->mmap);
dump_stack();
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
+ if (panic_on_warn)
+ panic("panic_on_warn set ...\n");
}
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0ee5e9afd433..137d1d86ddf4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -463,6 +463,8 @@ out:
/* Leave bad fields for debug, except PageBuddy could make trouble */
page_mapcount_reset(page); /* remove PageBuddy */
add_taint(TAINT_BAD_PAGE, LOCKDEP_NOW_UNRELIABLE);
+ if (panic_on_warn)
+ panic("panic_on_warn set ...\n");
}
/*
--
2.13.6
___
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
