lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 01 Sep 2014 17:53:02 -0700 (PDT) From: David Miller <davem@...emloft.net> To: erik.hugne@...csson.com Cc: jon.maloy@...csson.com, ying.xue@...driver.com, richard.alpe@...csson.com, netdev@...r.kernel.org, tipc-discussion@...ts.sourceforge.net Subject: Re: [PATCH v4 net-next 2/2] tipc: add name distributor resiliency queue From: <erik.hugne@...csson.com> Date: Thu, 28 Aug 2014 09:08:47 +0200 > TIPC name table updates are distributed asynchronously in a cluster, > entailing a risk of certain race conditions. E.g., if two nodes > simultaneously issue conflicting (overlapping) publications, this may > not be detected until both publications have reached a third node, in > which case one of the publications will be silently dropped on that > node. Hence, we end up with an inconsistent name table. > > In most cases this conflict is just a temporary race, e.g., one > node is issuing a publication under the assumption that a previous, > conflicting, publication has already been withdrawn by the other node. > However, because of the (rtt related) distributed update delay, this > may not yet hold true on all nodes. The symptom of this failure is a > syslog message: "tipc: Cannot publish {%u,%u,%u}, overlap error". > > In this commit we add a resiliency queue at the receiving end of > the name table distributor. When insertion of an arriving publication > fails, we retain it in this queue for a short amount of time, assuming > that another update will arrive very soon and clear the conflict. If so > happens, we insert the publication, otherwise we drop it. > > The (configurable) retention value defaults to 2000 ms. Knowing from > experience that the situation described above is extremely rare, there > is no risk that the queue will accumulate any large number of items. > > Signed-off-by: Erik Hugne <erik.hugne@...csson.com> > Signed-off-by: Jon Maloy <jon.maloy@...csson.com> > Acked-by: Ying Xue <ying.xue@...driver.com> ... > +static void tipc_named_add_backlog(struct distr_item *i, u32 type, u32 node) > +{ > + struct distr_queue_item *e; > + unsigned long now = get_jiffies_64(); > + > + e = kzalloc(sizeof(*e), GFP_ATOMIC); > + if (!e) > + return; I don't like this new (effectively silent) failure mode, but this isn't my code so I don't care that much. Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists