* [PATCH net-next v2 6/6] bonding: use RCU protection for alb xmit path
From: Ding Tianhong @ 2013-09-04 9:44 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico, Netdev, Hideaki YOSHIFUJI
The commit 278b20837511776dc9d5f6ee1c7fabd5479838bb
(bonding: initial RCU conversion) has convert the roundrobin, active-backup,
broadcast and xor xmit path to rcu protection, the performance will be better
for these mode, so this time, convert xmit path for alb mode.
Suggested-by: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Cc: Nikolay Aleksandrov <nikolay@redhat.com>
Cc: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_alb.c | 20 +++++++++-----------
drivers/net/bonding/bonding.h | 2 +-
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index c75d383..c0bfd56 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -229,7 +229,7 @@ static struct slave *tlb_get_least_loaded_slave(struct bonding *bond)
max_gap = LLONG_MIN;
/* Find the slave with the largest gap */
- bond_for_each_slave(bond, slave) {
+ bond_for_each_slave_rcu(bond, slave) {
if (SLAVE_IS_OK(slave)) {
long long gap = compute_gap(slave);
@@ -625,12 +625,14 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
{
struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
struct arp_pkt *arp = arp_pkt(skb);
- struct slave *assigned_slave;
+ struct slave *assigned_slave, *curr_active_slave;
struct rlb_client_info *client_info;
u32 hash_index = 0;
_lock_rx_hashtbl(bond);
+ curr_active_slave = rcu_dereference(bond->curr_active_slave);
+
hash_index = _simple_hash((u8 *)&arp->ip_dst, sizeof(arp->ip_dst));
client_info = &(bond_info->rx_hashtbl[hash_index]);
@@ -654,9 +656,9 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
* move the old client to primary (curr_active_slave) so
* that the new client can be assigned to this entry.
*/
- if (bond->curr_active_slave &&
- client_info->slave != bond->curr_active_slave) {
- client_info->slave = bond->curr_active_slave;
+ if (curr_active_slave &&
+ client_info->slave != curr_active_slave) {
+ client_info->slave = curr_active_slave;
rlb_update_client(client_info);
}
}
@@ -1338,8 +1340,6 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
/* make sure that the curr_active_slave do not change during tx
*/
- read_lock(&bond->lock);
- read_lock(&bond->curr_slave_lock);
switch (ntohs(skb->protocol)) {
case ETH_P_IP: {
@@ -1422,12 +1422,12 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
if (!tx_slave) {
/* unbalanced or unassigned, send through primary */
- tx_slave = bond->curr_active_slave;
+ tx_slave = rcu_dereference(bond->curr_active_slave);
bond_info->unbalanced_load += skb->len;
}
if (tx_slave && SLAVE_IS_OK(tx_slave)) {
- if (tx_slave != bond->curr_active_slave) {
+ if (tx_slave != rcu_dereference(bond->curr_active_slave)) {
memcpy(eth_data->h_source,
tx_slave->dev->dev_addr,
ETH_ALEN);
@@ -1442,8 +1442,6 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
}
}
- read_unlock(&bond->curr_slave_lock);
- read_unlock(&bond->lock);
if (res) {
/* no suitable interface, frame not sent */
kfree_skb(skb);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 80b170a..4282e65 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -536,7 +536,7 @@ static inline struct slave *bond_slave_has_mac(struct bonding *bond,
{
struct slave *tmp;
- bond_for_each_slave(bond, tmp)
+ bond_for_each_slave_rcu(bond, tmp)
if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr))
return tmp;
--
1.8.2.1
^ permalink raw reply related
* [PATCH net-next v2 4/6] bonding: add rtnl lock for bonding_store_xmit_hash
From: Ding Tianhong @ 2013-09-04 9:43 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico, Netdev
the bonding_store_xmit_hash() could update bond's xmit_policy, and
the xmit_policy is used in xmit path for xor mode, maybe it is hard
to occur any problem, but just follow the logic "don't change anything
slave-related without rtnl", so I think the rntl lock is fit here. :)
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Cc: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_sysfs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 0f539de..deb1d8e 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -382,6 +382,9 @@ static ssize_t bonding_store_xmit_hash(struct device *d,
int new_value, ret = count;
struct bonding *bond = to_bond(d);
+ if (!rtnl_trylock())
+ return restart_syscall();
+
new_value = bond_parse_parm(buf, xmit_hashtype_tbl);
if (new_value < 0) {
pr_err("%s: Ignoring invalid xmit hash policy value %.*s.\n",
@@ -396,6 +399,7 @@ static ssize_t bonding_store_xmit_hash(struct device *d,
xmit_hashtype_tbl[new_value].modename, new_value);
}
+ rtnl_unlock();
return ret;
}
static DEVICE_ATTR(xmit_hash_policy, S_IRUGO | S_IWUSR,
--
1.8.2.1
^ permalink raw reply related
* [PATCH net-next v2 0/6] bonding: Patchset for rcu use in bonding
From: Ding Tianhong @ 2013-09-04 9:43 UTC (permalink / raw)
To: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Veaceslav Falico, Netdev
Hi:
The Patch Set convert the xmit of 3ad and alb mode to use rcu lock.
restructure and add more rcu list function.
add rtnl lock to protect bonding_store_xmit_hash().
remove read lock in bond_3ad_lacpdu_recv().
I test the patch well and no problems found till now.
v1: add 1 patch named remove the no effect lock for bond_3ad_lacpdu_recv().
get the advice from Nikolay Aleksandrov, and modify some mistake in the code.
v2: accept the Nikolay Aleksandrov's advise, modify the patch 05/06.
the new bond_for_each_slave_from will not use bond->slave_cnt and int cnt any more,
it test well.
move the rcu_dereference call of curr_active_slave after the lock avoid
a race condition with the slave removal.
Ding Tianhong (4):
Wang Yufen (1):
Yang Yingliang (1):
bonding: simplify and use RCU protection for 3ad xmit path
bonding: remove the no effect lock for bond_3ad_lacpdu_recv()
bonding: replace read_lock to rcu_read_lock for
bond_3ad_get_active_agg_info()
bonding: add rtnl lock for bonding_store_xmit_hash
bonding: restructure and simplify bond_for_each_slave_next()
bonding: use RCU protection for alb xmit path
drivers/net/bonding/bond_3ad.c | 38 +++++++++++++++--------------------
drivers/net/bonding/bond_alb.c | 23 ++++++++++-----------
drivers/net/bonding/bond_main.c | 6 ++----
drivers/net/bonding/bond_sysfs.c | 4 ++++
drivers/net/bonding/bonding.h | 43 +++++++++++++++++++++++++++++++++++-----
5 files changed, 70 insertions(+), 44 deletions(-)
--
1.8.2.1
^ permalink raw reply
* Re: [PATCH 5/7] ixgbe: use pcie_capability_read_word() to simplify code
From: Jeff Kirsher @ 2013-09-04 9:26 UTC (permalink / raw)
To: Yijing Wang
Cc: e1000-devel, Benjamin Herrenschmidt, Hanjun Guo, linux-kernel,
James E.J. Bottomley, netdev, linux-pci, Bjorn Helgaas,
David S. Miller
In-Reply-To: <1378193715-25328-5-git-send-email-wangyijing@huawei.com>
[-- Attachment #1.1: Type: text/plain, Size: 442 bytes --]
On Tue, 2013-09-03 at 15:35 +0800, Yijing Wang wrote:
> use pcie_capability_read_word() to simplify code.
>
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> Cc: e1000-devel@lists.sourceforge.net
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
Thanks Yijing, I will add it to my queue.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 433 bytes --]
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [net-next v4 RFC] ixgbe: Get and display the notifications from changes of the Rx vxlan UDP port
From: Jeff Kirsher @ 2013-09-04 9:13 UTC (permalink / raw)
To: davem
Cc: Joseph Gasparakis, netdev, gospo, sassmann, Don Skidmore,
Jeff Kirsher
In-Reply-To: <1378286019-8719-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Joseph Gasparakis <joseph.gasparakis@intel.com>
This RFC patch showcases how drivers can use the changes in
"vxlan: Notify drivers for listening UDP port changes", and its
sole purpose is to help people test the changes introduced there.
This is not meant to be submitted for inclusion in the kernel.
CC: Don Skidmore <donald.c.skidmore@intel.com>
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7aba452..2d2c9b6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -47,6 +47,9 @@
#include <linux/if_bridge.h>
#include <linux/prefetch.h>
#include <scsi/fc/fc_fcoe.h>
+#ifdef CONFIG_VXLAN_MODULE
+#include <net/vxlan.h>
+#endif
#include "ixgbe.h"
#include "ixgbe_common.h"
@@ -5178,6 +5181,9 @@ static int ixgbe_open(struct net_device *netdev)
ixgbe_up_complete(adapter);
+#ifdef CONFIG_VXLAN_MODULE
+ vxlan_get_rx_port(netdev);
+#endif
return 0;
err_set_queues:
@@ -7290,6 +7296,21 @@ static int ixgbe_ndo_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode);
}
+#ifdef CONFIG_VXLAN_MODULE
+static void ixgbe_add_vxlan_port(struct net_device *netdev,
+ sa_family_t sa_family, __u16 port)
+{
+ netdev_info(netdev, ">>>>> Adding VXLAN port %d / protocol IPv%d\n",
+ port, sa_family == AF_INET ? 4 : 6);
+}
+
+static void ixgbe_del_vxlan_port(struct net_device *netdev,
+ sa_family_t sa_family, __u16 port)
+{
+ netdev_info(netdev, "<<<<< Removing VXLAN port %d / protocol IPv%d\n",
+ port, sa_family == AF_INET ? 4 : 6);
+}
+#endif
static const struct net_device_ops ixgbe_netdev_ops = {
.ndo_open = ixgbe_open,
.ndo_stop = ixgbe_close,
@@ -7334,6 +7355,10 @@ static const struct net_device_ops ixgbe_netdev_ops = {
.ndo_fdb_add = ixgbe_ndo_fdb_add,
.ndo_bridge_setlink = ixgbe_ndo_bridge_setlink,
.ndo_bridge_getlink = ixgbe_ndo_bridge_getlink,
+#ifdef CONFIG_VXLAN_MODULE
+ .ndo_add_vxlan_port = ixgbe_add_vxlan_port,
+ .ndo_del_vxlan_port = ixgbe_del_vxlan_port,
+#endif
};
/**
--
1.8.3.1
^ permalink raw reply related
* [net-next v4] vxlan: Notify drivers for listening UDP port changes
From: Jeff Kirsher @ 2013-09-04 9:13 UTC (permalink / raw)
To: davem
Cc: Joseph Gasparakis, netdev, gospo, sassmann, John Fastabend,
Stephen Hemminger, Jeff Kirsher
From: Joseph Gasparakis <joseph.gasparakis@intel.com>
This patch adds two more ndo ops: ndo_add_rx_vxlan_port() and
ndo_del_rx_vxlan_port().
Drivers can get notifications through the above functions about changes
of the UDP listening port of VXLAN. Also, when physical ports come up,
now they can call vxlan_get_rx_port() in order to obtain the port number(s)
of the existing VXLAN interface in case they already up before them.
This information about the listening UDP port would be used for VXLAN
related offloads.
A big thank you to John Fastabend (john.r.fastabend@intel.com) for his
input and his suggestions on this patch set.
CC: John Fastabend <john.r.fastabend@intel.com>
CC: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/vxlan.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++-
include/linux/netdevice.h | 19 +++++++++++++
include/net/vxlan.h | 1 +
3 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ebda3a1..0b62d82 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -558,6 +558,40 @@ static int vxlan_fdb_append(struct vxlan_fdb *f,
return 1;
}
+/* Notify netdevs that UDP port started listening */
+static void vxlan_notify_add_rx_port(struct sock *sk)
+{
+ struct net_device *dev;
+ struct net *net = sock_net(sk);
+ sa_family_t sa_family = sk->sk_family;
+ u16 port = htons(inet_sk(sk)->inet_sport);
+
+ rcu_read_lock();
+ for_each_netdev_rcu(net, dev) {
+ if (dev->netdev_ops->ndo_add_vxlan_port)
+ dev->netdev_ops->ndo_add_vxlan_port(dev, sa_family,
+ port);
+ }
+ rcu_read_unlock();
+}
+
+/* Notify netdevs that UDP port is no more listening */
+static void vxlan_notify_del_rx_port(struct sock *sk)
+{
+ struct net_device *dev;
+ struct net *net = sock_net(sk);
+ sa_family_t sa_family = sk->sk_family;
+ u16 port = htons(inet_sk(sk)->inet_sport);
+
+ rcu_read_lock();
+ for_each_netdev_rcu(net, dev) {
+ if (dev->netdev_ops->ndo_del_vxlan_port)
+ dev->netdev_ops->ndo_del_vxlan_port(dev, sa_family,
+ port);
+ }
+ rcu_read_unlock();
+}
+
/* Add new entry to forwarding table -- assumes lock held */
static int vxlan_fdb_create(struct vxlan_dev *vxlan,
const u8 *mac, union vxlan_addr *ip,
@@ -909,13 +943,16 @@ static void vxlan_sock_hold(struct vxlan_sock *vs)
void vxlan_sock_release(struct vxlan_sock *vs)
{
- struct vxlan_net *vn = net_generic(sock_net(vs->sock->sk), vxlan_net_id);
+ struct sock *sk = vs->sock->sk;
+ struct net *net = sock_net(sk);
+ struct vxlan_net *vn = net_generic(net, vxlan_net_id);
if (!atomic_dec_and_test(&vs->refcnt))
return;
spin_lock(&vn->sock_lock);
hlist_del_rcu(&vs->hlist);
+ vxlan_notify_del_rx_port(sk);
spin_unlock(&vn->sock_lock);
queue_work(vxlan_wq, &vs->del_work);
@@ -1980,6 +2017,34 @@ static struct device_type vxlan_type = {
.name = "vxlan",
};
+/* Calls the ndo_add_vxlan_port of the caller in order to
+ * supply the listening VXLAN udp ports.
+ */
+void vxlan_get_rx_port(struct net_device *dev)
+{
+ struct vxlan_sock *vs;
+ struct net *net = dev_net(dev);
+ struct vxlan_net *vn = net_generic(net, vxlan_net_id);
+ sa_family_t sa_family;
+ u16 port;
+ int i;
+
+ if (!dev || !dev->netdev_ops || !dev->netdev_ops->ndo_add_vxlan_port)
+ return;
+
+ spin_lock(&vn->sock_lock);
+ for (i = 0; i < PORT_HASH_SIZE; ++i) {
+ hlist_for_each_entry_rcu(vs, vs_head(net, i), hlist) {
+ port = htons(inet_sk(vs->sock->sk)->inet_sport);
+ sa_family = vs->sock->sk->sk_family;
+ dev->netdev_ops->ndo_add_vxlan_port(dev, sa_family,
+ port);
+ }
+ }
+ spin_unlock(&vn->sock_lock);
+}
+EXPORT_SYMBOL_GPL(vxlan_get_rx_port);
+
/* Initialize the device structure. */
static void vxlan_setup(struct net_device *dev)
{
@@ -2239,6 +2304,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
spin_lock(&vn->sock_lock);
hlist_add_head_rcu(&vs->hlist, vs_head(net, port));
+ vxlan_notify_add_rx_port(sk);
spin_unlock(&vn->sock_lock);
/* Mark socket as an encapsulation socket. */
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 3ad49b8..8ed4ae9 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -948,6 +948,19 @@ struct netdev_phys_port_id {
* Called to get ID of physical port of this device. If driver does
* not implement this, it is assumed that the hw is not able to have
* multiple net devices on single physical port.
+ *
+ * void (*ndo_add_vxlan_port)(struct net_device *dev,
+ * sa_family_t sa_family, __u16 port);
+ * Called by vxlan to notiy a driver about the UDP port and socket
+ * address family that vxlan is listnening to. It is called only when
+ * a new port starts listening. The operation is protected by the
+ * vxlan_net->sock_lock.
+ *
+ * void (*ndo_del_vxlan_port)(struct net_device *dev,
+ * sa_family_t sa_family, __u16 port);
+ * Called by vxlan to notify the driver about a UDP port and socket
+ * address family that vxlan is not listening to anymore. The operation
+ * is protected by the vxlan_net->sock_lock.
*/
struct net_device_ops {
int (*ndo_init)(struct net_device *dev);
@@ -1078,6 +1091,12 @@ struct net_device_ops {
bool new_carrier);
int (*ndo_get_phys_port_id)(struct net_device *dev,
struct netdev_phys_port_id *ppid);
+ void (*ndo_add_vxlan_port)(struct net_device *dev,
+ sa_family_t sa_family,
+ __u16 port);
+ void (*ndo_del_vxlan_port)(struct net_device *dev,
+ sa_family_t sa_family,
+ __u16 port);
};
/*
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index e09c40b..2d64d3c 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -36,4 +36,5 @@ int vxlan_xmit_skb(struct vxlan_sock *vs,
__be16 vxlan_src_port(__u16 port_min, __u16 port_max, struct sk_buff *skb);
+void vxlan_get_rx_port(struct net_device *netdev);
#endif
--
1.8.3.1
^ permalink raw reply related
* [RFC Patch net-next] ipv6: do not allow ipv6 module to be removed
From: Cong Wang @ 2013-09-04 9:12 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Hideaki YOSHIFUJI, Stephen Hemminger, Cong Wang
There was some bug report on ipv6 module removal path before.
Also, as Stephen pointed out, after vxlan module gets ipv6 support,
the ipv6 stub it used is not safe against this module removal either.
So, let's just remove inet6_exit() so that ipv6 module will not be
able to be unloaded.
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 136fe55..ad584eb 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -1023,51 +1023,4 @@ out_unregister_tcp_proto:
}
module_init(inet6_init);
-static void __exit inet6_exit(void)
-{
- if (disable_ipv6_mod)
- return;
-
- /* First of all disallow new sockets creation. */
- sock_unregister(PF_INET6);
- /* Disallow any further netlink messages */
- rtnl_unregister_all(PF_INET6);
-
- udpv6_exit();
- udplitev6_exit();
- tcpv6_exit();
-
- /* Cleanup code parts. */
- ipv6_packet_cleanup();
- ipv6_frag_exit();
- ipv6_exthdrs_exit();
- addrconf_cleanup();
- ip6_flowlabel_cleanup();
- ip6_route_cleanup();
-#ifdef CONFIG_PROC_FS
-
- /* Cleanup code parts. */
- if6_proc_exit();
- ipv6_misc_proc_exit();
- udplite6_proc_exit();
- raw6_proc_exit();
-#endif
- ipv6_netfilter_fini();
- ipv6_stub = NULL;
- igmp6_cleanup();
- ndisc_cleanup();
- ip6_mr_cleanup();
- icmpv6_cleanup();
- rawv6_exit();
-
- unregister_pernet_subsys(&inet6_net_ops);
- proto_unregister(&rawv6_prot);
- proto_unregister(&udplitev6_prot);
- proto_unregister(&udpv6_prot);
- proto_unregister(&tcpv6_prot);
-
- rcu_barrier(); /* Wait for completion of call_rcu()'s */
-}
-module_exit(inet6_exit);
-
MODULE_ALIAS_NETPROTO(PF_INET6);
^ permalink raw reply related
* Re: [PATCH v3 1/3] Send loginuid and sessionid in SCM_AUDIT
From: Jan Kaluža @ 2013-09-04 9:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: rgb-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
eparis-H+wXaHxf7aLQT0dZR+AlfA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, tj-DgEjT+Ai2ygdnm+yROfE0A,
cgroups-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <87bo49gifv.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On 09/04/2013 09:22 AM, Eric W. Biederman wrote:
> Jan Kaluza <jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
>
>> Server-like processes in many cases need credentials and other
>> metadata of the peer, to decide if the calling process is allowed to
>> request a specific action, or the server just wants to log away this
>> type of information for auditing tasks.
>>
>> The current practice to retrieve such process metadata is to look that
>> information up in procfs with the $PID received over SCM_CREDENTIALS.
>> This is sufficient for long-running tasks, but introduces a race which
>> cannot be worked around for short-living processes; the calling
>> process and all the information in /proc/$PID/ is gone before the
>> receiver of the socket message can look it up.
>>
>> This introduces a new SCM type called SCM_AUDIT to allow the direct
>> attaching of "loginuid" and "sessionid" to SCM, which is significantly more
>> efficient and will reliably avoid the race with the round-trip over
>> procfs.
>
> Unless I am misreading something this patch will break the build if
> CONFIG_AUDITSYSCALL is not defined.
It does build. In this case, audit_get_loginuid returns INVALID_UID and
audit_get_sessionid returns -1.
Jan Kaluza
> Eric
>
>
>> Signed-off-by: Jan Kaluza <jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> include/linux/socket.h | 6 ++++++
>> include/net/af_unix.h | 2 ++
>> include/net/scm.h | 28 ++++++++++++++++++++++++++--
>> net/unix/af_unix.c | 7 +++++++
>> 4 files changed, 41 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/socket.h b/include/linux/socket.h
>> index 445ef75..505047a 100644
>> --- a/include/linux/socket.h
>> +++ b/include/linux/socket.h
>> @@ -130,6 +130,7 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr *__msg, struct cmsghdr
>> #define SCM_RIGHTS 0x01 /* rw: access rights (array of int) */
>> #define SCM_CREDENTIALS 0x02 /* rw: struct ucred */
>> #define SCM_SECURITY 0x03 /* rw: security label */
>> +#define SCM_AUDIT 0x04 /* rw: struct uaudit */
>>
>> struct ucred {
>> __u32 pid;
>> @@ -137,6 +138,11 @@ struct ucred {
>> __u32 gid;
>> };
>>
>> +struct uaudit {
>> + __u32 loginuid;
>> + __u32 sessionid;
>> +};
>> +
>> /* Supported address families. */
>> #define AF_UNSPEC 0
>> #define AF_UNIX 1 /* Unix domain sockets */
>> diff --git a/include/net/af_unix.h b/include/net/af_unix.h
>> index a175ba4..3b9d22a 100644
>> --- a/include/net/af_unix.h
>> +++ b/include/net/af_unix.h
>> @@ -36,6 +36,8 @@ struct unix_skb_parms {
>> u32 secid; /* Security ID */
>> #endif
>> u32 consumed;
>> + kuid_t loginuid;
>> + unsigned int sessionid;
>> };
>>
>> #define UNIXCB(skb) (*(struct unix_skb_parms *)&((skb)->cb))
>> diff --git a/include/net/scm.h b/include/net/scm.h
>> index 8de2d37..e349a25 100644
>> --- a/include/net/scm.h
>> +++ b/include/net/scm.h
>> @@ -6,6 +6,7 @@
>> #include <linux/security.h>
>> #include <linux/pid.h>
>> #include <linux/nsproxy.h>
>> +#include <linux/audit.h>
>>
>> /* Well, we should have at least one descriptor open
>> * to accept passed FDs 8)
>> @@ -18,6 +19,11 @@ struct scm_creds {
>> kgid_t gid;
>> };
>>
>> +struct scm_audit {
>> + kuid_t loginuid;
>> + unsigned int sessionid;
>> +};
>> +
>> struct scm_fp_list {
>> short count;
>> short max;
>> @@ -28,6 +34,7 @@ struct scm_cookie {
>> struct pid *pid; /* Skb credentials */
>> struct scm_fp_list *fp; /* Passed files */
>> struct scm_creds creds; /* Skb credentials */
>> + struct scm_audit audit; /* Skb audit */
>> #ifdef CONFIG_SECURITY_NETWORK
>> u32 secid; /* Passed security ID */
>> #endif
>> @@ -58,6 +65,13 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
>> scm->creds.gid = gid;
>> }
>>
>> +static inline void scm_set_audit(struct scm_cookie *scm,
>> + kuid_t loginuid, unsigned int sessionid)
>> +{
>> + scm->audit.loginuid = loginuid;
>> + scm->audit.sessionid = sessionid;
>> +}
>> +
>> static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
>> {
>> put_pid(scm->pid);
>> @@ -77,8 +91,12 @@ static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
>> memset(scm, 0, sizeof(*scm));
>> scm->creds.uid = INVALID_UID;
>> scm->creds.gid = INVALID_GID;
>> - if (forcecreds)
>> - scm_set_cred(scm, task_tgid(current), current_uid(), current_gid());
>> + if (forcecreds) {
>> + scm_set_cred(scm, task_tgid(current), current_uid(),
>> + current_gid());
>> + scm_set_audit(scm, audit_get_loginuid(current),
>> + audit_get_sessionid(current));
>> + }
>> unix_get_peersec_dgram(sock, scm);
>> if (msg->msg_controllen <= 0)
>> return 0;
>> @@ -123,7 +141,13 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
>> .uid = from_kuid_munged(current_ns, scm->creds.uid),
>> .gid = from_kgid_munged(current_ns, scm->creds.gid),
>> };
>> + struct uaudit uaudits = {
>> + .loginuid = from_kuid_munged(current_ns,
>> + scm->audit.loginuid),
>> + .sessionid = scm->audit.sessionid,
>> + };
>> put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(ucreds), &ucreds);
>> + put_cmsg(msg, SOL_SOCKET, SCM_AUDIT, sizeof(uaudits), &uaudits);
>> }
>>
>> scm_destroy_cred(scm);
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 86de99a..c410f76 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -1393,6 +1393,8 @@ static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool sen
>> UNIXCB(skb).pid = get_pid(scm->pid);
>> UNIXCB(skb).uid = scm->creds.uid;
>> UNIXCB(skb).gid = scm->creds.gid;
>> + UNIXCB(skb).loginuid = scm->audit.loginuid;
>> + UNIXCB(skb).sessionid = scm->audit.sessionid;
>> UNIXCB(skb).fp = NULL;
>> if (scm->fp && send_fds)
>> err = unix_attach_fds(scm, skb);
>> @@ -1416,6 +1418,8 @@ static void maybe_add_creds(struct sk_buff *skb, const struct socket *sock,
>> test_bit(SOCK_PASSCRED, &other->sk_socket->flags)) {
>> UNIXCB(skb).pid = get_pid(task_tgid(current));
>> current_uid_gid(&UNIXCB(skb).uid, &UNIXCB(skb).gid);
>> + UNIXCB(skb).loginuid = audit_get_loginuid(current);
>> + UNIXCB(skb).sessionid = audit_get_sessionid(current);
>> }
>> }
>>
>> @@ -1812,6 +1816,7 @@ static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock,
>> memset(&tmp_scm, 0, sizeof(tmp_scm));
>> }
>> scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).uid, UNIXCB(skb).gid);
>> + scm_set_audit(siocb->scm, UNIXCB(skb).loginuid, UNIXCB(skb).sessionid);
>> unix_set_secdata(siocb->scm, skb);
>>
>> if (!(flags & MSG_PEEK)) {
>> @@ -1993,6 +1998,8 @@ again:
>> } else if (test_bit(SOCK_PASSCRED, &sock->flags)) {
>> /* Copy credentials */
>> scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).uid, UNIXCB(skb).gid);
>> + scm_set_audit(siocb->scm, UNIXCB(skb).loginuid,
>> + UNIXCB(skb).sessionid);
>> check_creds = 1;
>> }
^ permalink raw reply
* Re: xen-netback: count number required slots for an skb more carefully
From: Wei Liu @ 2013-09-04 8:41 UTC (permalink / raw)
To: Ian Campbell
Cc: Matt Wilson, annie li, Wei Liu, David Vrabel, xen-devel,
Konrad Rzeszutek Wilk, Boris Ostrovsky, netdev, msw
In-Reply-To: <1378283770.17510.52.camel@kazak.uk.xensource.com>
On Wed, Sep 04, 2013 at 09:36:10AM +0100, Ian Campbell wrote:
> On Tue, 2013-09-03 at 23:04 -0700, Matt Wilson wrote:
> > On Wed, Sep 04, 2013 at 10:25:59AM +0800, annie li wrote:
> > > On 2013-9-4 5:53, Wei Liu wrote:
> > [...]
> > > >Matt, do you fancy sending the final version? IIRC the commit message
> > > >needs to be re-written. I personally still prefer Matt's solution as
> > > >it a) make efficient use of the ring, b) uses ring pointers to
> > > >calculate slots which is most accurate, c) removes the dependence on
> > > >MAX_SKB_FRAGS in guest RX path.
> > > >
> > > >Anyway, we should get this fixed ASAP.
>
> Yes. Would there be any harm in just applying David's patch (just
> because it is the one currently in our hands and it is based on a recent
> enough kernel). It looks right from a correctness PoV to me.
>
> > > Totally agree. This issue is easy to be reproduced with large MTU.
> > > It is better to upstream the fix soon in case others hit it and
> > > waste time to fix it.
> >
> > I'd like to go with Xi's proposed patch that I posed earlier.
>
> I don't think I saw that, do you have a message-id?
>
> ("Xi" is a bit too short for a search on my INBOX unfortunately).
>
This one <1373409659-22383-1-git-send-email-msw@amazon.com>
Wei.
> > The main
> > thing that's kept me from sending a final version is lack of time to
> > retest against a newer kernel.
> >
> > Could someone help out with that? I probably can't get to it until the
> > end of the week.
> >
> > Sorry for the delay. :-(
> >
> > --msw
>
^ permalink raw reply
* Re: xen-netback: count number required slots for an skb more carefully
From: Ian Campbell @ 2013-09-04 8:36 UTC (permalink / raw)
To: Matt Wilson
Cc: annie li, Wei Liu, David Vrabel, xen-devel, Konrad Rzeszutek Wilk,
Boris Ostrovsky, netdev, msw
In-Reply-To: <20130904060446.GA25227@u109add4315675089e695.ant.amazon.com>
On Tue, 2013-09-03 at 23:04 -0700, Matt Wilson wrote:
> On Wed, Sep 04, 2013 at 10:25:59AM +0800, annie li wrote:
> > On 2013-9-4 5:53, Wei Liu wrote:
> [...]
> > >Matt, do you fancy sending the final version? IIRC the commit message
> > >needs to be re-written. I personally still prefer Matt's solution as
> > >it a) make efficient use of the ring, b) uses ring pointers to
> > >calculate slots which is most accurate, c) removes the dependence on
> > >MAX_SKB_FRAGS in guest RX path.
> > >
> > >Anyway, we should get this fixed ASAP.
Yes. Would there be any harm in just applying David's patch (just
because it is the one currently in our hands and it is based on a recent
enough kernel). It looks right from a correctness PoV to me.
> > Totally agree. This issue is easy to be reproduced with large MTU.
> > It is better to upstream the fix soon in case others hit it and
> > waste time to fix it.
>
> I'd like to go with Xi's proposed patch that I posed earlier.
I don't think I saw that, do you have a message-id?
("Xi" is a bit too short for a search on my INBOX unfortunately).
> The main
> thing that's kept me from sending a final version is lack of time to
> retest against a newer kernel.
>
> Could someone help out with that? I probably can't get to it until the
> end of the week.
>
> Sorry for the delay. :-(
>
> --msw
^ permalink raw reply
* Re: [Xen-devel] xen-netback: count number required slots for an skb more carefully
From: Wei Liu @ 2013-09-04 8:20 UTC (permalink / raw)
To: annie li
Cc: Wei Liu, Matt Wilson, David Vrabel, xen-devel,
Konrad Rzeszutek Wilk, Boris Ostrovsky, Ian Campbell, netdev, msw
In-Reply-To: <5226EA1B.1030303@oracle.com>
On Wed, Sep 04, 2013 at 04:06:51PM +0800, annie li wrote:
>
> On 2013-9-4 15:38, Wei Liu wrote:
> >On Wed, Sep 04, 2013 at 02:56:20PM +0800, annie li wrote:
> >>On 2013-9-4 14:04, Matt Wilson wrote:
> >>>On Wed, Sep 04, 2013 at 10:25:59AM +0800, annie li wrote:
> >>>>On 2013-9-4 5:53, Wei Liu wrote:
> >>>[...]
> >>>>>Matt, do you fancy sending the final version? IIRC the commit message
> >>>>>needs to be re-written. I personally still prefer Matt's solution as
> >>>>>it a) make efficient use of the ring, b) uses ring pointers to
> >>>>>calculate slots which is most accurate, c) removes the dependence on
> >>>>>MAX_SKB_FRAGS in guest RX path.
> >>>>>
> >>>>>Anyway, we should get this fixed ASAP.
> >>>>Totally agree. This issue is easy to be reproduced with large MTU.
> >>>>It is better to upstream the fix soon in case others hit it and
> >>>>waste time to fix it.
> >>>I'd like to go with Xi's proposed patch that I posed earlier. The main
> >>>thing that's kept me from sending a final version is lack of time to
> >>>retest against a newer kernel.
> >>>
> >>>Could someone help out with that? I probably can't get to it until the
> >>>end of the week.
> >>I can rebase it. Since wei's NAPI &1:1 model patch went into
> >>net-next already, it should not be able to applied directly.
> >>
> >I think this one should go to net then queue up for stable, not
> >net-next.
> If so, that would be easier. It is almost end of the day here, and I
> do not have enough time to test it until tomorrow. Please go ahead
> with it if you have time.
>
Sure, I'm fine with this. I will spend some time rebase it today. But
eventually I would like to get it tested as much as possible. That's to
say, I would need confirmation / acked-by from you, David and Matt.
Wei.
> Thanks
> Annie
> >Wei.
> >
> >>Thanks
> >>Annie
> >>>Sorry for the delay. :-(
> >>>
> >>>--msw
^ permalink raw reply
* Re: [Xen-devel] xen-netback: count number required slots for an skb more carefully
From: annie li @ 2013-09-04 8:06 UTC (permalink / raw)
To: Wei Liu
Cc: Matt Wilson, David Vrabel, xen-devel, Konrad Rzeszutek Wilk,
Boris Ostrovsky, Ian Campbell, netdev, msw
In-Reply-To: <20130904073857.GI14104@zion.uk.xensource.com>
On 2013-9-4 15:38, Wei Liu wrote:
> On Wed, Sep 04, 2013 at 02:56:20PM +0800, annie li wrote:
>> On 2013-9-4 14:04, Matt Wilson wrote:
>>> On Wed, Sep 04, 2013 at 10:25:59AM +0800, annie li wrote:
>>>> On 2013-9-4 5:53, Wei Liu wrote:
>>> [...]
>>>>> Matt, do you fancy sending the final version? IIRC the commit message
>>>>> needs to be re-written. I personally still prefer Matt's solution as
>>>>> it a) make efficient use of the ring, b) uses ring pointers to
>>>>> calculate slots which is most accurate, c) removes the dependence on
>>>>> MAX_SKB_FRAGS in guest RX path.
>>>>>
>>>>> Anyway, we should get this fixed ASAP.
>>>> Totally agree. This issue is easy to be reproduced with large MTU.
>>>> It is better to upstream the fix soon in case others hit it and
>>>> waste time to fix it.
>>> I'd like to go with Xi's proposed patch that I posed earlier. The main
>>> thing that's kept me from sending a final version is lack of time to
>>> retest against a newer kernel.
>>>
>>> Could someone help out with that? I probably can't get to it until the
>>> end of the week.
>> I can rebase it. Since wei's NAPI &1:1 model patch went into
>> net-next already, it should not be able to applied directly.
>>
> I think this one should go to net then queue up for stable, not
> net-next.
If so, that would be easier. It is almost end of the day here, and I do
not have enough time to test it until tomorrow. Please go ahead with it
if you have time.
Thanks
Annie
> Wei.
>
>> Thanks
>> Annie
>>> Sorry for the delay. :-(
>>>
>>> --msw
^ permalink raw reply
* [PATCH RESEND net-next] net: usbnet: update addr_assign_type if appropriate
From: Bjørn Mork @ 2013-09-04 7:42 UTC (permalink / raw)
To: netdev; +Cc: linux-usb, Bjørn Mork
This module generates a common default address on init,
using eth_random_addr. Set addr_assign_type to let
userspace know the address is random unless it was
overridden by the minidriver.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Oliver Neukum <oliver@neukum.org>
---
Sorry this patch missed the "addr_assign_type series" where it should
have been.
drivers/net/usb/usbnet.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index e4811d7..74a8e3c 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1629,6 +1629,10 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)
dev->rx_urb_size = dev->hard_mtu;
dev->maxpacket = usb_maxpacket (dev->udev, dev->out, 1);
+ /* let userspace know we have a random address */
+ if (ether_addr_equal(net->dev_addr, node_id))
+ net->addr_assign_type = NET_ADDR_RANDOM;
+
if ((dev->driver_info->flags & FLAG_WLAN) != 0)
SET_NETDEV_DEVTYPE(net, &wlan_type);
if ((dev->driver_info->flags & FLAG_WWAN) != 0)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v3 0/3] Send audit/procinfo/cgroup data in socket-level control message
From: Eric W. Biederman @ 2013-09-04 7:42 UTC (permalink / raw)
To: Jan Kaluza
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, LKML, netdev-u79uwXL29TY76Z2rM5mHXA,
eparis-H+wXaHxf7aLQT0dZR+AlfA, rgb-H+wXaHxf7aLQT0dZR+AlfA,
tj-DgEjT+Ai2ygdnm+yROfE0A, lizefan-hv44wF8Li93QT0dZR+AlfA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
cgroups-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn
In-Reply-To: <1378275261-4553-1-git-send-email-jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Jan Kaluza <jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> Hi,
>
> this patchset against net-next (applies also to linux-next) adds 3 new types
> of "Socket"-level control message (SCM_AUDIT, SCM_PROCINFO and SCM_CGROUP).
>
> Server-like processes in many cases need credentials and other
> metadata of the peer, to decide if the calling process is allowed to
> request a specific action, or the server just wants to log away this
> type of information for auditing tasks.
>
> The current practice to retrieve such process metadata is to look that
> information up in procfs with the $PID received over SCM_CREDENTIALS.
> This is sufficient for long-running tasks, but introduces a race which
> cannot be worked around for short-living processes; the calling
> process and all the information in /proc/$PID/ is gone before the
> receiver of the socket message can look it up.
> Changes introduced in this patchset can also increase performance
> of such server-like processes, because current way of opening and
> parsing /proc/$PID/* files is much more expensive than receiving these
> metadata using SCM.
Can I just say ick, blech, barf, gag.
You don't require this information to be passed. You are asking people
to suport a lot of new code for the forseeable future. The only advantage
appears to be for short lived racy processes that don't even bother to
make certain their message was acknowleged before exiting.
You sent this during the merge window which is the time for code
integration and testing not new code.
By my count you have overflowed cb in struct sk_buff and are stomping on
_skb_refdest.
If you are going to go crazy and pass things is there a reason you do
not add a patch to pass the bsd SCM_CREDS? That information seems more
relevant in a security context and for making security decisions than
about half the information you are passing.
Eric
^ permalink raw reply
* Re: [Xen-devel] xen-netback: count number required slots for an skb more carefully
From: Wei Liu @ 2013-09-04 7:38 UTC (permalink / raw)
To: annie li
Cc: Matt Wilson, Wei Liu, David Vrabel, xen-devel,
Konrad Rzeszutek Wilk, Boris Ostrovsky, Ian Campbell, netdev, msw
In-Reply-To: <5226D994.9000401@oracle.com>
On Wed, Sep 04, 2013 at 02:56:20PM +0800, annie li wrote:
>
> On 2013-9-4 14:04, Matt Wilson wrote:
> >On Wed, Sep 04, 2013 at 10:25:59AM +0800, annie li wrote:
> >>On 2013-9-4 5:53, Wei Liu wrote:
> >[...]
> >>>Matt, do you fancy sending the final version? IIRC the commit message
> >>>needs to be re-written. I personally still prefer Matt's solution as
> >>>it a) make efficient use of the ring, b) uses ring pointers to
> >>>calculate slots which is most accurate, c) removes the dependence on
> >>>MAX_SKB_FRAGS in guest RX path.
> >>>
> >>>Anyway, we should get this fixed ASAP.
> >>Totally agree. This issue is easy to be reproduced with large MTU.
> >>It is better to upstream the fix soon in case others hit it and
> >>waste time to fix it.
> >I'd like to go with Xi's proposed patch that I posed earlier. The main
> >thing that's kept me from sending a final version is lack of time to
> >retest against a newer kernel.
> >
> >Could someone help out with that? I probably can't get to it until the
> >end of the week.
>
> I can rebase it. Since wei's NAPI &1:1 model patch went into
> net-next already, it should not be able to applied directly.
>
I think this one should go to net then queue up for stable, not
net-next.
Wei.
> Thanks
> Annie
> >
> >Sorry for the delay. :-(
> >
> >--msw
^ permalink raw reply
* Re: [PATCH v3 1/3] Send loginuid and sessionid in SCM_AUDIT
From: Eric W. Biederman @ 2013-09-04 7:22 UTC (permalink / raw)
To: Jan Kaluza
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, LKML, netdev-u79uwXL29TY76Z2rM5mHXA,
eparis-H+wXaHxf7aLQT0dZR+AlfA, rgb-H+wXaHxf7aLQT0dZR+AlfA,
tj-DgEjT+Ai2ygdnm+yROfE0A, lizefan-hv44wF8Li93QT0dZR+AlfA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
cgroups-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn
In-Reply-To: <1378275261-4553-2-git-send-email-jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Jan Kaluza <jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> Server-like processes in many cases need credentials and other
> metadata of the peer, to decide if the calling process is allowed to
> request a specific action, or the server just wants to log away this
> type of information for auditing tasks.
>
> The current practice to retrieve such process metadata is to look that
> information up in procfs with the $PID received over SCM_CREDENTIALS.
> This is sufficient for long-running tasks, but introduces a race which
> cannot be worked around for short-living processes; the calling
> process and all the information in /proc/$PID/ is gone before the
> receiver of the socket message can look it up.
>
> This introduces a new SCM type called SCM_AUDIT to allow the direct
> attaching of "loginuid" and "sessionid" to SCM, which is significantly more
> efficient and will reliably avoid the race with the round-trip over
> procfs.
Unless I am misreading something this patch will break the build if
CONFIG_AUDITSYSCALL is not defined.
Eric
> Signed-off-by: Jan Kaluza <jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> include/linux/socket.h | 6 ++++++
> include/net/af_unix.h | 2 ++
> include/net/scm.h | 28 ++++++++++++++++++++++++++--
> net/unix/af_unix.c | 7 +++++++
> 4 files changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 445ef75..505047a 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -130,6 +130,7 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr *__msg, struct cmsghdr
> #define SCM_RIGHTS 0x01 /* rw: access rights (array of int) */
> #define SCM_CREDENTIALS 0x02 /* rw: struct ucred */
> #define SCM_SECURITY 0x03 /* rw: security label */
> +#define SCM_AUDIT 0x04 /* rw: struct uaudit */
>
> struct ucred {
> __u32 pid;
> @@ -137,6 +138,11 @@ struct ucred {
> __u32 gid;
> };
>
> +struct uaudit {
> + __u32 loginuid;
> + __u32 sessionid;
> +};
> +
> /* Supported address families. */
> #define AF_UNSPEC 0
> #define AF_UNIX 1 /* Unix domain sockets */
> diff --git a/include/net/af_unix.h b/include/net/af_unix.h
> index a175ba4..3b9d22a 100644
> --- a/include/net/af_unix.h
> +++ b/include/net/af_unix.h
> @@ -36,6 +36,8 @@ struct unix_skb_parms {
> u32 secid; /* Security ID */
> #endif
> u32 consumed;
> + kuid_t loginuid;
> + unsigned int sessionid;
> };
>
> #define UNIXCB(skb) (*(struct unix_skb_parms *)&((skb)->cb))
> diff --git a/include/net/scm.h b/include/net/scm.h
> index 8de2d37..e349a25 100644
> --- a/include/net/scm.h
> +++ b/include/net/scm.h
> @@ -6,6 +6,7 @@
> #include <linux/security.h>
> #include <linux/pid.h>
> #include <linux/nsproxy.h>
> +#include <linux/audit.h>
>
> /* Well, we should have at least one descriptor open
> * to accept passed FDs 8)
> @@ -18,6 +19,11 @@ struct scm_creds {
> kgid_t gid;
> };
>
> +struct scm_audit {
> + kuid_t loginuid;
> + unsigned int sessionid;
> +};
> +
> struct scm_fp_list {
> short count;
> short max;
> @@ -28,6 +34,7 @@ struct scm_cookie {
> struct pid *pid; /* Skb credentials */
> struct scm_fp_list *fp; /* Passed files */
> struct scm_creds creds; /* Skb credentials */
> + struct scm_audit audit; /* Skb audit */
> #ifdef CONFIG_SECURITY_NETWORK
> u32 secid; /* Passed security ID */
> #endif
> @@ -58,6 +65,13 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
> scm->creds.gid = gid;
> }
>
> +static inline void scm_set_audit(struct scm_cookie *scm,
> + kuid_t loginuid, unsigned int sessionid)
> +{
> + scm->audit.loginuid = loginuid;
> + scm->audit.sessionid = sessionid;
> +}
> +
> static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
> {
> put_pid(scm->pid);
> @@ -77,8 +91,12 @@ static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
> memset(scm, 0, sizeof(*scm));
> scm->creds.uid = INVALID_UID;
> scm->creds.gid = INVALID_GID;
> - if (forcecreds)
> - scm_set_cred(scm, task_tgid(current), current_uid(), current_gid());
> + if (forcecreds) {
> + scm_set_cred(scm, task_tgid(current), current_uid(),
> + current_gid());
> + scm_set_audit(scm, audit_get_loginuid(current),
> + audit_get_sessionid(current));
> + }
> unix_get_peersec_dgram(sock, scm);
> if (msg->msg_controllen <= 0)
> return 0;
> @@ -123,7 +141,13 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
> .uid = from_kuid_munged(current_ns, scm->creds.uid),
> .gid = from_kgid_munged(current_ns, scm->creds.gid),
> };
> + struct uaudit uaudits = {
> + .loginuid = from_kuid_munged(current_ns,
> + scm->audit.loginuid),
> + .sessionid = scm->audit.sessionid,
> + };
> put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(ucreds), &ucreds);
> + put_cmsg(msg, SOL_SOCKET, SCM_AUDIT, sizeof(uaudits), &uaudits);
> }
>
> scm_destroy_cred(scm);
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 86de99a..c410f76 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1393,6 +1393,8 @@ static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool sen
> UNIXCB(skb).pid = get_pid(scm->pid);
> UNIXCB(skb).uid = scm->creds.uid;
> UNIXCB(skb).gid = scm->creds.gid;
> + UNIXCB(skb).loginuid = scm->audit.loginuid;
> + UNIXCB(skb).sessionid = scm->audit.sessionid;
> UNIXCB(skb).fp = NULL;
> if (scm->fp && send_fds)
> err = unix_attach_fds(scm, skb);
> @@ -1416,6 +1418,8 @@ static void maybe_add_creds(struct sk_buff *skb, const struct socket *sock,
> test_bit(SOCK_PASSCRED, &other->sk_socket->flags)) {
> UNIXCB(skb).pid = get_pid(task_tgid(current));
> current_uid_gid(&UNIXCB(skb).uid, &UNIXCB(skb).gid);
> + UNIXCB(skb).loginuid = audit_get_loginuid(current);
> + UNIXCB(skb).sessionid = audit_get_sessionid(current);
> }
> }
>
> @@ -1812,6 +1816,7 @@ static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock,
> memset(&tmp_scm, 0, sizeof(tmp_scm));
> }
> scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).uid, UNIXCB(skb).gid);
> + scm_set_audit(siocb->scm, UNIXCB(skb).loginuid, UNIXCB(skb).sessionid);
> unix_set_secdata(siocb->scm, skb);
>
> if (!(flags & MSG_PEEK)) {
> @@ -1993,6 +1998,8 @@ again:
> } else if (test_bit(SOCK_PASSCRED, &sock->flags)) {
> /* Copy credentials */
> scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).uid, UNIXCB(skb).gid);
> + scm_set_audit(siocb->scm, UNIXCB(skb).loginuid,
> + UNIXCB(skb).sessionid);
> check_creds = 1;
> }
^ permalink raw reply
* Re: [PATCH] ppc: bpf_jit: support MOD operation
From: Daniel Borkmann @ 2013-09-04 7:04 UTC (permalink / raw)
To: Vladimir Murzin
Cc: Benjamin Herrenschmidt, linuxppc-dev, paulus, davem, Matt Evans,
netdev
In-Reply-To: <52264C0D.3000409@redhat.com>
On 09/03/2013 10:52 PM, Daniel Borkmann wrote:
> On 09/03/2013 09:58 PM, Vladimir Murzin wrote:
[...]
>>> Do you have a test case/suite by any chance ?
>>>
>>> Ben.
>>>
>>
>> Hi Ben!
>>
>> Thanks for your feedback.
>>
>> This patch is only compile tested. I have no real hardware, but I'll
>> probably bring up qemu ppc64 till end of the week...
>> Meanwhile, I've made simple how-to for testing. You can use it if you wish.
>> It is mainly based on the [1] and rechecked on x86-64.
>
> Please also cc netdev on BPF related changes.
>
> Actually, your test plan can be further simplified ...
>
> For retrieving and disassembling the JIT image, we have bpf_jit_disasm [1].
>
> 1) echo 2 > /proc/sys/net/core/bpf_jit_enable
> 2) ... attach filter ...
> 3) bpf_jit_disasm -o
>
> For generating a simple stupid test filter, you can use bpfc [2] (also
> see its man page). E.g. ...
>
> # cat blub
> ldi #10
> mod #8
> ret a
> # bpfc blub
> { 0x0, 0, 0, 0x0000000a },
> { 0x94, 0, 0, 0x00000008 },
> { 0x16, 0, 0, 0x00000000 },
Plus something like ...
ldxi #0
mod x
ret a
For longer-term testing, also trinity has BPF support. ;)
> And load this array e.g. either into a small C program that attaches this
> as BPF filter, or simply do bpfc blub > blub2 and run netsniff-ng -f blub2\
> -s -i eth0, that should also do it.
>
> Then, when attached, the kernel should truncate incoming frames for pf_packet
> into max length of 2, just as an example.
>
> [1] kernel tree, tools/net/bpf_jit_disasm.c
> [2] git clone git://github.com/borkmann/netsniff-ng.git
^ permalink raw reply
* Re: [Xen-devel] xen-netback: count number required slots for an skb more carefully
From: annie li @ 2013-09-04 6:56 UTC (permalink / raw)
To: Matt Wilson
Cc: Wei Liu, David Vrabel, xen-devel, Konrad Rzeszutek Wilk,
Boris Ostrovsky, Ian Campbell, netdev, msw
In-Reply-To: <20130904060446.GA25227@u109add4315675089e695.ant.amazon.com>
On 2013-9-4 14:04, Matt Wilson wrote:
> On Wed, Sep 04, 2013 at 10:25:59AM +0800, annie li wrote:
>> On 2013-9-4 5:53, Wei Liu wrote:
> [...]
>>> Matt, do you fancy sending the final version? IIRC the commit message
>>> needs to be re-written. I personally still prefer Matt's solution as
>>> it a) make efficient use of the ring, b) uses ring pointers to
>>> calculate slots which is most accurate, c) removes the dependence on
>>> MAX_SKB_FRAGS in guest RX path.
>>>
>>> Anyway, we should get this fixed ASAP.
>> Totally agree. This issue is easy to be reproduced with large MTU.
>> It is better to upstream the fix soon in case others hit it and
>> waste time to fix it.
> I'd like to go with Xi's proposed patch that I posed earlier. The main
> thing that's kept me from sending a final version is lack of time to
> retest against a newer kernel.
>
> Could someone help out with that? I probably can't get to it until the
> end of the week.
I can rebase it. Since wei's NAPI &1:1 model patch went into net-next
already, it should not be able to applied directly.
Thanks
Annie
>
> Sorry for the delay. :-(
>
> --msw
^ permalink raw reply
* Re: [-next] openvswitch BUILD_BUG_ON failed
From: Geert Uytterhoeven @ 2013-09-04 6:55 UTC (permalink / raw)
To: Jesse Gross
Cc: David Miller, Andy Zhou, dev@openvswitch.org, netdev,
Linux Kernel Mailing List, Linux-Next
In-Reply-To: <CAEP_g=-BWdWJ5WtNy0=Eq8GJp84i88QbGq-gQcANBhCKajcJsQ@mail.gmail.com>
On Tue, Sep 3, 2013 at 11:44 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Sat, Aug 31, 2013 at 5:11 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Fri, Aug 30, 2013 at 3:11 AM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Thu, Aug 29, 2013 at 3:10 PM, David Miller <davem@davemloft.net> wrote:
>>>> From: Jesse Gross <jesse@nicira.com>
>>>> Date: Thu, 29 Aug 2013 14:42:22 -0700
>>>>
>>>>> On Thu, Aug 29, 2013 at 2:21 PM, Geert Uytterhoeven
>>>>> <geert@linux-m68k.org> wrote:
>>>>>> However, I have some doubts about other alignment "enforcements":
>>>>>>
>>>>>> "__aligned(__alignof__(long))" makes the whole struct aligned to the
>>>>>> alignment rule for "long":
>>>>>> 1. This is only 2 bytes on m68k, i.e. != sizeof(long).
>>>>>> 2. This is 4 bytes on many 32-bit platforms, which may be less than the
>>>>>> default alignment for "__be64" (cfr. some members of struct
>>>>>> ovs_key_ipv4_tunnel), so this may make those 64-bit members unaligned.
>>>>>
>>>>> Do any of those 32-bit architectures actually care about alignment of
>>>>> 64 bit values? On 32-bit x86, a long is 32 bits but the alignment
>>>>> requirement of __be64 is also 32 bit.
>>>>
>>>> All except x86-32 do, it is in fact the odd man out with respect to this
>>>> issue.
>>>
>>> Thanks, good to know.
>>>
>>> Andy, do you want to modify your patch to just drop the alignment
>>> specification as Geert suggested (but definitely keep the new build
>>> assert that you added)? It's probably better to just send the patch to
>>> netdev (against net-next) as well since you'll likely get better
>>> comments there and we can fix this faster if you cut out the
>>> middleman.
>>
>> Why do you want to keep the build asserts?
>> Is this in-memory structure also transfered as-is over the network?
>> If yes, you definitely want the padding.
>
> Well they caught this bug and really don't cost anything.
>
>> Nevertheless, as the struct contains u32 and even __be64 members, the
>> size of the struct will always be a multiple of the alignment unit for
>> 64-bit quantities (and thus also for long), as per the C standard.
>> Hence the check
>>
>> BUILD_BUG_ON(sizeof(struct sw_flow_key) % __alignof__(long));
>>
>> will only catch bad compiler bugs or people adding __packed to the struct.
>
> It's possible that we might want to pack the structure in the future.
> More generally though, the contents of the struct is really
> independent of the alignment requirements here because we're accessing
> it as an array of bytes in long-sized chunks so implicitly depending
> on the size of the members is not that great.
So you're accessing it as an array of bytes in long-sized chunks.
What are you doing with this accessed data?
Transfering over the network?
Storing on disk?
Then it must be portable across machines and architectures, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] sh_eth: check platform data pointer
From: Simon Horman @ 2013-09-04 6:48 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, nobuhiro.iwamatsu.yj, linux-sh
In-Reply-To: <201308310423.30322.sergei.shtylyov@cogentembedded.com>
On Sat, Aug 31, 2013 at 04:23:29AM +0400, Sergei Shtylyov wrote:
> Check the platform data pointer before dereferencing it and error out of the
> probe() method if it's NULL.
>
> This has additional effect of preventing kernel oops with outdated platform data
> containing zero PHY address instead (such as on SolutionEngine7710).
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
>
> ---
> This patch is against Dave's 'net-next.git' repo.
>
> drivers/net/ethernet/renesas/sh_eth.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
> ===================================================================
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
> @@ -2653,6 +2653,12 @@ static int sh_eth_drv_probe(struct platf
> pm_runtime_enable(&pdev->dev);
> pm_runtime_resume(&pdev->dev);
>
> + if (!pd) {
> + dev_err(&pdev->dev, "no platform data\n");
> + ret = -EINVAL;
> + goto out_release;
> + }
> +
> /* get PHY ID */
> mdp->phy_id = pd->phy;
> mdp->phy_interface = pd->phy_interface;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 net-next] pkt_sched: fq: Fair Queue packet scheduler
From: Jason Wang @ 2013-09-04 6:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, Yuchung Cheng, Neal Cardwell,
Michael S. Tsirkin
In-Reply-To: <1378274376.7360.82.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]
On 09/04/2013 01:59 PM, Eric Dumazet wrote:
> On Wed, 2013-09-04 at 13:26 +0800, Jason Wang wrote:
>
>> I see both degradation and jitter when using fq with virtio-net. Guest
>> to guest performance drops from 8Gb/s to 3Gb/s-7Gb/s. Guest to local
>> host drops from 8Gb/s to 4Gb/s-6Gb/s. Guest to external host with ixgbe
>> drops from 9Gb/s to 7Gb/s
>>
>> I didn't meet the issue when using sfq or disabling pacing.
>>
>> So it looks like it was caused by the inaccuracy and jitter of the
>> pacing estimation in a virt guest?
> Well, using virtio-net means you use FQ without pacing.
>
> Make sure you do not have reorders because of a bug in queue selection.
I test with only one queue enabled, so should not have this problem.
>
> TCP stack has the ooo_okay thing, I do not think a VM can get it.
>
> nstat >/dev/null ; <your test> ; nstat
This is result of guest to guest:
using sfq:
nstat > /dev/null; netperf -H 192.168.100.5; nstat
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.100.5 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.01 9155.88
#kernel
IpInReceives 130989 0.0
IpInDelivers 130989 0.0
IpOutRequests 176518 0.0
TcpActiveOpens 2 0.0
TcpInSegs 130989 0.0
TcpOutSegs 7908396 0.0
TcpExtDelayedACKs 1 0.0
TcpExtTCPPureAcks 60997 0.0
TcpExtTCPHPAcks 69985 0.0
IpExtInOctets 6813412 0.0
IpExtOutOctets 11460499000 0.0
IpExtInNoECTPkts 130989 0.0
using fq:
nstat > /dev/null; netperf -H 192.168.100.5; nstat
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.100.5 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 6340.29
#kernel
IpInReceives 121595 0.0
IpInDelivers 121595 0.0
IpOutRequests 121763 0.0
TcpActiveOpens 2 0.0
TcpInSegs 121595 0.0
TcpOutSegs 5474944 0.0
TcpExtTW 2 0.0
TcpExtDelayedACKs 1 0.0
TcpExtTCPPureAcks 50946 0.0
TcpExtTCPHPAcks 70642 0.0
IpExtInOctets 6324924 0.0
IpExtOutOctets 7934016612 0.0
IpExtInNoECTPkts 121595 0.0
>
> And tcpdump would certainly help ;)
See attachment.
Thanks
[-- Attachment #2: fq_out --]
[-- Type: text/plain, Size: 47989 bytes --]
14:09:54.296328 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 268750855, win 16256, options [nop,nop,TS val 222137 ecr 230249], length 0
14:09:54.296378 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 130321:195481, ack 0, win 229, options [nop,nop,TS val 230249 ecr 222137], length 65160
14:09:54.296477 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 195481:260641, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.296493 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 65161, win 16290, options [nop,nop,TS val 222137 ecr 230249], length 0
14:09:54.296560 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 260641:325801, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.296576 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 130321, win 16256, options [nop,nop,TS val 222137 ecr 230249], length 0
14:09:54.296651 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 325801:390961, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.296734 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 390961:456121, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.296748 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 195481, win 16290, options [nop,nop,TS val 222137 ecr 230249], length 0
14:09:54.296753 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 260641, win 16290, options [nop,nop,TS val 222137 ecr 230250], length 0
14:09:54.296755 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 325801, win 16256, options [nop,nop,TS val 222137 ecr 230250], length 0
14:09:54.296819 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 456121:521281, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.296905 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 521281:586441, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.297013 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 586441:651601, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.297029 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 390961, win 16290, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297034 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 456121, win 16256, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297085 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 651601:716761, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.297100 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 521281, win 16256, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297166 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 716761:781921, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.297273 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 781921:847081, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222137], length 65160
14:09:54.297289 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 586441, win 16290, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297345 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 847081:912241, ack 0, win 229, options [nop,nop,TS val 230250 ecr 222138], length 65160
14:09:54.297367 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 651601, win 16290, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297371 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 716761, win 16256, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297420 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 912241:977401, ack 0, win 229, options [nop,nop,TS val 230251 ecr 222138], length 65160
14:09:54.297507 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 977401:1042561, ack 0, win 229, options [nop,nop,TS val 230251 ecr 222138], length 65160
14:09:54.297598 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 1042561:1107721, ack 0, win 229, options [nop,nop,TS val 230251 ecr 222138], length 65160
14:09:54.297613 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 781921, win 16256, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297619 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 847081, win 16290, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297622 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 912241, win 16256, options [nop,nop,TS val 222138 ecr 230250], length 0
14:09:54.297681 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 1107721:1172881, ack 0, win 229, options [nop,nop,TS val 230251 ecr 222138], length 65160
14:09:54.309333 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 9643681:9708841, ack 0, win 229, options [nop,nop,TS val 230262 ecr 222150], length 65160
14:09:54.309504 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 9774001:9839161, ack 0, win 229, options [nop,nop,TS val 230263 ecr 222150], length 65160
14:09:54.309597 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 9839161:9904321, ack 0, win 229, options [nop,nop,TS val 230263 ecr 222150], length 65160
14:09:54.309613 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 9643681, win 16290, options [nop,nop,TS val 222150 ecr 230262], length 0
14:09:54.309709 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 9708841, win 16290, options [nop,nop,TS val 222150 ecr 230262], length 0
14:09:54.309713 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 9774001, win 16256, options [nop,nop,TS val 222150 ecr 230262], length 0
14:09:54.309942 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10099801:10164961, ack 0, win 229, options [nop,nop,TS val 230263 ecr 222150], length 65160
14:09:54.310020 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10034641, win 16256, options [nop,nop,TS val 222151 ecr 230263], length 0
14:09:54.310069 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10099801, win 15997, options [nop,nop,TS val 222151 ecr 230263], length 0
14:09:54.310125 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10230121:10295281, ack 0, win 229, options [nop,nop,TS val 230263 ecr 222150], length 65160
14:09:54.310206 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10295281:10360441, ack 0, win 229, options [nop,nop,TS val 230263 ecr 222151], length 65160
14:09:54.310304 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10360441:10425601, ack 0, win 229, options [nop,nop,TS val 230263 ecr 222151], length 65160
14:09:54.310398 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10425601:10490761, ack 0, win 229, options [nop,nop,TS val 230263 ecr 222151], length 65160
14:09:54.310414 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10164961, win 16290, options [nop,nop,TS val 222151 ecr 230263], length 0
14:09:54.310420 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10230121, win 16256, options [nop,nop,TS val 222151 ecr 230263], length 0
14:09:54.310493 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10490761:10555921, ack 0, win 229, options [nop,nop,TS val 230264 ecr 222151], length 65160
14:09:54.310664 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10621081:10686241, ack 0, win 229, options [nop,nop,TS val 230264 ecr 222151], length 65160
14:09:54.310753 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 10686241:10751401, ack 0, win 229, options [nop,nop,TS val 230264 ecr 222151], length 65160
14:09:54.310769 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10425601, win 16290, options [nop,nop,TS val 222151 ecr 230263], length 0
14:09:54.310964 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10686241, win 16290, options [nop,nop,TS val 222152 ecr 230264], length 0
14:09:54.310968 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10751401, win 16256, options [nop,nop,TS val 222152 ecr 230264], length 0
14:09:54.311289 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11077201:11142361, ack 0, win 229, options [nop,nop,TS val 230264 ecr 222152], length 65160
14:09:54.311374 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11142361:11207521, ack 0, win 229, options [nop,nop,TS val 230264 ecr 222152], length 65160
14:09:54.311390 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 10946881, win 16290, options [nop,nop,TS val 222152 ecr 230264], length 0
14:09:54.311395 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11012041, win 16290, options [nop,nop,TS val 222152 ecr 230264], length 0
14:09:54.311453 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11207521:11272681, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222152], length 65160
14:09:54.311583 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11142361, win 16290, options [nop,nop,TS val 222152 ecr 230264], length 0
14:09:54.311635 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11337841:11403001, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222152], length 65160
14:09:54.311722 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11403001:11468161, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222152], length 65160
14:09:54.311738 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11207521, win 16256, options [nop,nop,TS val 222152 ecr 230264], length 0
14:09:54.311812 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11468161:11533321, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222152], length 65160
14:09:54.311828 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11272681, win 16290, options [nop,nop,TS val 222152 ecr 230265], length 0
14:09:54.311832 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11337841, win 16256, options [nop,nop,TS val 222152 ecr 230265], length 0
14:09:54.311945 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11403001, win 16290, options [nop,nop,TS val 222153 ecr 230265], length 0
14:09:54.311949 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11468161, win 16256, options [nop,nop,TS val 222153 ecr 230265], length 0
14:09:54.311981 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11598481:11663641, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222152], length 65160
14:09:54.312080 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11663641:11728801, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222152], length 65160
14:09:54.312168 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11728801:11793961, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222152], length 65160
14:09:54.312185 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11533321, win 16290, options [nop,nop,TS val 222153 ecr 230265], length 0
14:09:54.312190 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11598481, win 16256, options [nop,nop,TS val 222153 ecr 230265], length 0
14:09:54.312324 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 11859121:11924281, ack 0, win 229, options [nop,nop,TS val 230265 ecr 222153], length 65160
14:09:54.312542 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 11793961, win 16256, options [nop,nop,TS val 222153 ecr 230265], length 0
14:09:54.312708 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 12119761:12184921, ack 0, win 229, options [nop,nop,TS val 230266 ecr 222153], length 65160
14:09:54.312970 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 12315241:12380401, ack 0, win 229, options [nop,nop,TS val 230266 ecr 222153], length 65160
14:09:54.313058 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 12380401:12445561, ack 0, win 229, options [nop,nop,TS val 230266 ecr 222153], length 65160
14:09:54.313072 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12119761, win 16290, options [nop,nop,TS val 222153 ecr 230266], length 0
14:09:54.313077 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12184921, win 16290, options [nop,nop,TS val 222154 ecr 230266], length 0
14:09:54.313374 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12380401, win 16290, options [nop,nop,TS val 222154 ecr 230266], length 0
14:09:54.313536 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12510721, win 16256, options [nop,nop,TS val 222154 ecr 230266], length 0
14:09:54.313540 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12575881, win 16290, options [nop,nop,TS val 222154 ecr 230266], length 0
14:09:54.313584 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 12771361:12836521, ack 0, win 229, options [nop,nop,TS val 230267 ecr 222154], length 65160
14:09:54.313682 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 12836521:12901681, ack 0, win 229, options [nop,nop,TS val 230267 ecr 222154], length 65160
14:09:54.313698 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12641041, win 16290, options [nop,nop,TS val 222154 ecr 230266], length 0
14:09:54.313814 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12771361, win 16290, options [nop,nop,TS val 222154 ecr 230267], length 0
14:09:54.313860 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 12966841:13032001, ack 0, win 229, options [nop,nop,TS val 230267 ecr 222154], length 65160
14:09:54.313943 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13032001:13097161, ack 0, win 229, options [nop,nop,TS val 230267 ecr 222154], length 65160
14:09:54.313960 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12836521, win 16290, options [nop,nop,TS val 222154 ecr 230267], length 0
14:09:54.313983 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12901681, win 16256, options [nop,nop,TS val 222155 ecr 230267], length 0
14:09:54.314133 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13162321:13227481, ack 0, win 229, options [nop,nop,TS val 230267 ecr 222154], length 65160
14:09:54.314225 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13227481:13292641, ack 0, win 229, options [nop,nop,TS val 230267 ecr 222155], length 65160
14:09:54.314236 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 12966841, win 16256, options [nop,nop,TS val 222155 ecr 230267], length 0
14:09:54.314241 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13032001, win 16290, options [nop,nop,TS val 222155 ecr 230267], length 0
14:09:54.314243 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13097161, win 16256, options [nop,nop,TS val 222155 ecr 230267], length 0
14:09:54.314246 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13162321, win 16256, options [nop,nop,TS val 222155 ecr 230267], length 0
14:09:54.314304 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13292641:13357801, ack 0, win 229, options [nop,nop,TS val 230267 ecr 222155], length 65160
14:09:54.314393 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13357801:13422961, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.314482 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13422961:13488121, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.314573 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13488121:13553281, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.314591 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13227481, win 16290, options [nop,nop,TS val 222155 ecr 230267], length 0
14:09:54.314597 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13292641, win 16256, options [nop,nop,TS val 222155 ecr 230267], length 0
14:09:54.314657 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13553281:13618441, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.314748 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13618441:13683601, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.314853 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13683601:13748761, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.314868 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13488121, win 16290, options [nop,nop,TS val 222155 ecr 230268], length 0
14:09:54.314929 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13748761:13813921, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.315094 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13879081:13944241, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.315112 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13618441, win 16256, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315190 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 13944241:14009401, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222155], length 65160
14:09:54.315206 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13683601, win 16256, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315211 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13748761, win 16290, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315213 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13813921, win 16256, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315295 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14009401:14074561, ack 0, win 229, options [nop,nop,TS val 230268 ecr 222156], length 65160
14:09:54.315308 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13879081, win 16256, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315356 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14074561:14139721, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.315451 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14139721:14204881, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.315468 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 13944241, win 16290, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315537 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14204881:14270041, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.315552 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 14009401, win 16290, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315573 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 14074561, win 16256, options [nop,nop,TS val 222156 ecr 230268], length 0
14:09:54.315709 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14335201:14400361, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.315836 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 14204881, win 16290, options [nop,nop,TS val 222156 ecr 230269], length 0
14:09:54.315852 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 14270041, win 16256, options [nop,nop,TS val 222156 ecr 230269], length 0
14:09:54.315858 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 14335201, win 16256, options [nop,nop,TS val 222156 ecr 230269], length 0
14:09:54.315896 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14465521:14530681, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.315982 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14530681:14595841, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.316069 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14595841:14661001, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.316339 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14791321:14856481, ack 0, win 229, options [nop,nop,TS val 230269 ecr 222156], length 65160
14:09:54.316518 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 14921641:14986801, ack 0, win 229, options [nop,nop,TS val 230270 ecr 222157], length 65160
14:09:54.316656 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 14726161, win 16290, options [nop,nop,TS val 222157 ecr 230269], length 0
14:09:54.316660 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 14791321, win 16256, options [nop,nop,TS val 222157 ecr 230269], length 0
14:09:54.316695 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15051961:15117121, ack 0, win 229, options [nop,nop,TS val 230270 ecr 222157], length 65160
14:09:54.316822 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15051961, win 16256, options [nop,nop,TS val 222157 ecr 230270], length 0
14:09:54.317047 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15315633:15331561, ack 0, win 229, options [nop,nop,TS val 230270 ecr 222157], length 15928
14:09:54.317214 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15414097:15430025, ack 0, win 229, options [nop,nop,TS val 230270 ecr 222158], length 15928
14:09:54.317240 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15430025:15445953, ack 0, win 229, options [nop,nop,TS val 230270 ecr 222158], length 15928
14:09:54.317435 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15511329:15528705, ack 0, win 229, options [nop,nop,TS val 230271 ecr 222158], length 17376
14:09:54.317643 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15610089:15626017, ack 0, win 229, options [nop,nop,TS val 230271 ecr 222158], length 15928
14:09:54.317651 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15544633, win 16290, options [nop,nop,TS val 222158 ecr 230271], length 0
14:09:54.317821 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15643393, win 16290, options [nop,nop,TS val 222158 ecr 230271], length 0
14:09:54.317826 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15659321, win 16290, options [nop,nop,TS val 222158 ecr 230271], length 0
14:09:54.317830 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15675249, win 16290, options [nop,nop,TS val 222158 ecr 230271], length 0
14:09:54.317853 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15708849:15724777, ack 0, win 229, options [nop,nop,TS val 230271 ecr 222158], length 15928
14:09:54.318024 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15708849, win 16290, options [nop,nop,TS val 222159 ecr 230271], length 0
14:09:54.318027 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15724777, win 16290, options [nop,nop,TS val 222159 ecr 230271], length 0
14:09:54.318234 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 15905617:15921545, ack 0, win 229, options [nop,nop,TS val 230271 ecr 222159], length 15928
14:09:54.318469 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16003841:16019769, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222159], length 15928
14:09:54.318481 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 15921545, win 16290, options [nop,nop,TS val 222159 ecr 230271], length 0
14:09:54.318676 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16086137:16102065, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222159], length 15928
14:09:54.318701 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16102065:16117993, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222159], length 15928
14:09:54.318711 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16036529, win 16290, options [nop,nop,TS val 222159 ecr 230272], length 0
14:09:54.318822 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16167225:16183153, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222159], length 15928
14:09:54.318858 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16183153:16200529, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222159], length 17376
14:09:54.318867 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16052457, win 16290, options [nop,nop,TS val 222159 ecr 230272], length 0
14:09:54.318871 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16068385, win 16290, options [nop,nop,TS val 222159 ecr 230272], length 0
14:09:54.318919 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16200825:16216753, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222159], length 15928
14:09:54.319045 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16265985:16281913, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222160], length 15928
14:09:54.319128 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16299129:16315057, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222160], length 15928
14:09:54.319277 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16364289:16380217, ack 0, win 229, options [nop,nop,TS val 230272 ecr 222160], length 15928
14:09:54.319372 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16396977:16412905, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319403 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16412905:16428833, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319409 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16364289, win 16290, options [nop,nop,TS val 222160 ecr 230272], length 0
14:09:54.319470 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16446129:16462057, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319496 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16462057:16477985, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319511 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16396977, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319535 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16477985:16495361, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 17376
14:09:54.319544 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16412905, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319607 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16511289:16527217, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319616 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16428833, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319619 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16446129, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319622 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16462057, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319625 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16477985, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319664 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16527217:16544593, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 17376
14:09:54.319677 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 16544593:16544889, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 296
14:09:54.319705 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16544889:16560817, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319734 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16560817:16576745, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319764 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16576745:16592673, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319794 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16592673:16610049, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 17376
14:09:54.319810 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16495361, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319813 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16511289, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319816 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16527217, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319843 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16610049:16625977, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319852 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16544593, win 16290, options [nop,nop,TS val 222160 ecr 230273], length 0
14:09:54.319879 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16625977:16641905, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 15928
14:09:54.319907 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16641905:16659281, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222160], length 17376
14:09:54.319918 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16560817, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.319926 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 16659281:16659577, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 296
14:09:54.319929 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16576745, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.319933 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16592673, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.319957 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16659577:16675505, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 15928
14:09:54.319999 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16675505:16691433, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 15928
14:09:54.320028 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16691433:16707361, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 15928
14:09:54.320042 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16610049, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320046 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16625977, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320063 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16641905, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320089 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16707361:16724737, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 17376
14:09:54.320098 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16659281, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320101 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16675505, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320112 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 16724737:16725113, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 376
14:09:54.320142 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16725113:16741041, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 15928
14:09:54.320155 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16691433, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320159 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16707361, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320189 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16741041:16756969, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 15928
14:09:54.320220 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16756969:16772897, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 15928
14:09:54.320273 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16772897:16790273, ack 0, win 229, options [nop,nop,TS val 230273 ecr 222161], length 17376
14:09:54.320308 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16790273:16806201, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320317 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16724737, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320321 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16741041, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320331 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 16806201:16807033, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 832
14:09:54.320345 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16756969, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320363 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16807033:16822961, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320394 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16822961:16838889, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320432 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16838889:16854817, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320440 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16772897, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320444 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16790273, win 16290, options [nop,nop,TS val 222161 ecr 230273], length 0
14:09:54.320446 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16806201, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320449 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16807033, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320459 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 16854817:16856185, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 1368
14:09:54.320492 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16856185:16872113, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320523 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16872113:16888041, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320557 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16888041:16903969, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320565 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16822961, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320569 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16838889, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320571 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16854817, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320574 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16856185, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320584 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 16903969:16905337, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 1368
14:09:54.320617 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16905337:16921265, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320653 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16921265:16937193, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320689 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16937193:16953121, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320697 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16872113, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320701 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16888041, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320705 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16903969, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320707 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16905337, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320718 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 16953121:16954489, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 1368
14:09:54.320751 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16954489:16970417, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320783 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16970417:16986345, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320818 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 16986345:17002273, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320826 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16921265, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320830 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16937193, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320832 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16953121, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320835 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16954489, win 16290, options [nop,nop,TS val 222161 ecr 230274], length 0
14:09:54.320845 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 17002273:17003641, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 1368
14:09:54.320875 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17003641:17019569, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320907 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17019569:17035497, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320941 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17035497:17051425, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222161], length 15928
14:09:54.320947 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16970417, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.320950 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 16986345, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.320953 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17002273, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.320956 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17003641, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.320967 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 17051425:17052793, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 1368
14:09:54.321010 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17052793:17068721, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 15928
14:09:54.321043 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17068721:17084649, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 15928
14:09:54.321074 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17084649:17100577, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 15928
14:09:54.321106 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17100577:17117953, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 17376
14:09:54.321135 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17117953:17133881, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 15928
14:09:54.321147 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17019569, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321150 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17035497, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321168 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17051425, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321172 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17052793, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321174 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17068721, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321177 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17084649, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321191 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17133881:17149809, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 15928
14:09:54.321219 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17100577, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321228 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 17149809:17151097, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 1288
14:09:54.321304 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17151097:17167025, ack 0, win 229, options [nop,nop,TS val 230274 ecr 222162], length 15928
14:09:54.321313 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17117953, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321318 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17133881, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321397 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17149809, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321401 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17151097, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321452 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17167025, win 16290, options [nop,nop,TS val 222162 ecr 230274], length 0
14:09:54.321492 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 17167025:17167481, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 456
14:09:54.321530 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17167481:17183409, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321559 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17183409:17199337, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321587 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17199337:17215265, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321616 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17215265:17232641, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 17376
14:09:54.321643 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17232641:17248569, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321663 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17167481, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321667 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17183409, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321684 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17248569:17264497, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321698 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 17264497:17265785, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 1288
14:09:54.321726 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17265785:17281713, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321735 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17199337, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321738 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17215265, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321770 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17281713:17297641, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321779 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17232641, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321783 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17248569, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321810 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17297641:17313569, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321844 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17313569:17330945, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 17376
14:09:54.321853 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17264497, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321857 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17265785, win 16290, options [nop,nop,TS val 222162 ecr 230275], length 0
14:09:54.321865 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [P.], seq 17330945:17331321, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 376
14:09:54.321887 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17331321:17347249, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321914 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17347249:17363177, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321942 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17363177:17379105, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 15928
14:09:54.321958 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17281713, win 16290, options [nop,nop,TS val 222163 ecr 230275], length 0
14:09:54.321962 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17297641, win 16290, options [nop,nop,TS val 222163 ecr 230275], length 0
14:09:54.321996 IP 192.168.100.4.47649 > 192.168.100.5.48748: Flags [.], seq 17379105:17396481, ack 0, win 229, options [nop,nop,TS val 230275 ecr 222162], length 17376
14:09:54.322004 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17313569, win 16290, options [nop,nop,TS val 222163 ecr 230275], length 0
14:09:54.322008 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17330945, win 16290, options [nop,nop,TS val 222163 ecr 230275], length 0
14:09:54.322030 IP 192.168.100.5.48748 > 192.168.100.4.47649: Flags [.], ack 17347249, win 16290, options [nop,nop,TS val 222163 ecr 230275], length 0
^ permalink raw reply
* Re: [PATCH net] net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv
From: Jiri Benc @ 2013-09-04 6:26 UTC (permalink / raw)
To: Jean Sacren; +Cc: Eric Dumazet, Daniel Borkmann, davem, netdev, yoshfuji
In-Reply-To: <20130904005157.GG8262@mail.gmail.com>
On Tue, 3 Sep 2013 18:51:57 -0600, Jean Sacren wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 03 Sep 2013 15:29:12 -0700
> >
> > On Tue, 2013-09-03 at 15:59 -0600, Jean Sacren wrote:
> > > From: Eric Dumazet <eric.dumazet@gmail.com>
> > > Date: Tue, 03 Sep 2013 13:35:17 -0700
> > > >
> > > > How did you get your conclusion ?
> > >
> > > If one changes one line of code, doesn't one own that line?
> > >
> >
> > 'Owning' like he is the guy who can sell it ? OK I understand now
> > so many people send 'cleanups' ;)
>
> 'Owning' like he is the guy who is responsible for the change. Whether
> you understand it or not, that's your own business.
>
> The idea was by taking one example to determine who is really to blame
> for: Is the one passing on the bug responsible? Thanks to Daniel
> Borkmann for the answer.
Eric is correct, the bug was introduced by me.
Sorry for it. Daniel, thanks for fixing it.
Acked-by: Jiri Benc <jbenc@redhat.com>
--
Jiri Benc
^ permalink raw reply
* Re: [PATCH net-next 6/6] bonding: use RCU protection for alb xmit path
From: Ding Tianhong @ 2013-09-04 6:24 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller, Veaceslav Falico,
Netdev, Hideaki YOSHIFUJI
In-Reply-To: <5225B855.6080101@redhat.com>
On 2013/9/3 18:22, Nikolay Aleksandrov wrote:
> On 08/30/2013 12:05 PM, Ding Tianhong wrote:
>> The commit 278b20837511776dc9d5f6ee1c7fabd5479838bb
>> (bonding: initial RCU conversion) has convert the roundrobin, active-backup,
>> broadcast and xor xmit path to rcu protection, the performance will be better
>> for these mode, so this time, convert xmit path for alb mode.
>>
>> Suggested-by: Nikolay Aleksandrov <nikolay@redhat.com>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>> Cc: Nikolay Aleksandrov <nikolay@redhat.com>
>> Cc: Veaceslav Falico <vfalico@redhat.com>
>> ---
>> drivers/net/bonding/bond_alb.c | 20 +++++++++-----------
>> drivers/net/bonding/bonding.h | 2 +-
>> 2 files changed, 10 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>> index d266c56..e94a5d0 100644
>> --- a/drivers/net/bonding/bond_alb.c
>> +++ b/drivers/net/bonding/bond_alb.c
>> @@ -229,7 +229,7 @@ static struct slave *tlb_get_least_loaded_slave(struct bonding *bond)
>> max_gap = LLONG_MIN;
>>
>> /* Find the slave with the largest gap */
>> - bond_for_each_slave(bond, slave) {
>> + bond_for_each_slave_rcu(bond, slave) {
>> if (SLAVE_IS_OK(slave)) {
>> long long gap = compute_gap(slave);
>>
>> @@ -625,10 +625,12 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
>> {
>> struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
>> struct arp_pkt *arp = arp_pkt(skb);
>> - struct slave *assigned_slave;
>> + struct slave *assigned_slave, *curr_active_slave;
>> struct rlb_client_info *client_info;
>> u32 hash_index = 0;
>>
>> + curr_active_slave = rcu_dereference(bond->curr_active_slave);
>> +
> I think this code is prone to a race condition with the slave removal, because
> without the lock __bond_release_one() may think that it has done the LB release
> (bond_alb_deinit_slave) and cleared the slave while you may set it after locking.
> I guess you should move the dereference after the lock so to make sure that the
> LB release hasn't passed (or it has and it'll be different).
>
yes, I ignore it, fix it in next version.
>> _lock_rx_hashtbl(bond);
>>
>> hash_index = _simple_hash((u8 *)&arp->ip_dst, sizeof(arp->ip_dst));
>> @@ -654,9 +656,9 @@ static struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bon
>> * move the old client to primary (curr_active_slave) so
>> * that the new client can be assigned to this entry.
>> */
>> - if (bond->curr_active_slave &&
>> - client_info->slave != bond->curr_active_slave) {
>> - client_info->slave = bond->curr_active_slave;
>> + if (curr_active_slave &&
>> + client_info->slave != curr_active_slave) {
>> + client_info->slave = curr_active_slave;
>> rlb_update_client(client_info);
>> }
>> }
>> @@ -1336,8 +1338,6 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
>>
>> /* make sure that the curr_active_slave do not change during tx
>> */
>> - read_lock(&bond->lock);
>> - read_lock(&bond->curr_slave_lock);
>>
>> switch (ntohs(skb->protocol)) {
>> case ETH_P_IP: {
>> @@ -1420,12 +1420,12 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
>>
>> if (!tx_slave) {
>> /* unbalanced or unassigned, send through primary */
>> - tx_slave = bond->curr_active_slave;
>> + tx_slave = rcu_dereference(bond->curr_active_slave);
>> bond_info->unbalanced_load += skb->len;
>> }
>>
>> if (tx_slave && SLAVE_IS_OK(tx_slave)) {
>> - if (tx_slave != bond->curr_active_slave) {
>> + if (tx_slave != rcu_dereference(bond->curr_active_slave)) {
>> memcpy(eth_data->h_source,
>> tx_slave->dev->dev_addr,
>> ETH_ALEN);
>> @@ -1440,8 +1440,6 @@ int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev)
>> }
>> }
>>
>> - read_unlock(&bond->curr_slave_lock);
>> - read_unlock(&bond->lock);
>> if (res) {
>> /* no suitable interface, frame not sent */
>> kfree_skb(skb);
>> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>> index a3ab47f..9bc3af0 100644
>> --- a/drivers/net/bonding/bonding.h
>> +++ b/drivers/net/bonding/bonding.h
>> @@ -536,7 +536,7 @@ static inline struct slave *bond_slave_has_mac(struct bonding *bond,
>> {
>> struct slave *tmp;
>>
>> - bond_for_each_slave(bond, tmp)
>> + bond_for_each_slave_rcu(bond, tmp)
>> if (ether_addr_equal_64bits(mac, tmp->dev->dev_addr))
>> return tmp;
>>
>>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH net-next 5/6] bonding: restructure and simplify bond_for_each_slave_next()
From: Ding Tianhong @ 2013-09-04 6:23 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller, Veaceslav Falico,
Netdev
In-Reply-To: <5225B852.1010601@redhat.com>
On 2013/9/3 18:22, Nikolay Aleksandrov wrote:
> On 08/30/2013 12:05 PM, Ding Tianhong wrote:
>> remove the wordy int and add bond_for_each_slave_next_rcu() for future use.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> Cc: Nikolay Aleksandrov <nikolay@redhat.com>
>> ---
>> drivers/net/bonding/bond_alb.c | 3 +--
>> drivers/net/bonding/bond_main.c | 6 ++----
>> drivers/net/bonding/bonding.h | 19 +++++++++++++++----
>> 3 files changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
>> index 3a5db7b..d266c56 100644
>> --- a/drivers/net/bonding/bond_alb.c
>> +++ b/drivers/net/bonding/bond_alb.c
>> @@ -383,7 +383,6 @@ static struct slave *rlb_next_rx_slave(struct bonding *bond)
>> {
>> struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
>> struct slave *rx_slave, *slave, *start_at;
>> - int i = 0;
>>
>> if (bond_info->next_rx_slave)
>> start_at = bond_info->next_rx_slave;
>> @@ -392,7 +391,7 @@ static struct slave *rlb_next_rx_slave(struct bonding *bond)
>>
>> rx_slave = NULL;
>>
>> - bond_for_each_slave_from(bond, slave, i, start_at) {
>> + bond_for_each_slave_from(bond, slave, start_at) {
>> if (SLAVE_IS_OK(slave)) {
>> if (!rx_slave) {
>> rx_slave = slave;
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 4264a76..8c9902a 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -904,7 +904,6 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
>> struct slave *new_active, *old_active;
>> struct slave *bestslave = NULL;
>> int mintime = bond->params.updelay;
>> - int i;
>>
>> new_active = bond->curr_active_slave;
>>
>> @@ -923,7 +922,7 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
>> /* remember where to stop iterating over the slaves */
>> old_active = new_active;
>>
>> - bond_for_each_slave_from(bond, new_active, i, old_active) {
>> + bond_for_each_slave_from(bond, new_active, old_active) {
>> if (new_active->link == BOND_LINK_UP) {
>> return new_active;
>> } else if (new_active->link == BOND_LINK_BACK &&
>> @@ -2891,7 +2890,6 @@ do_failover:
>> static void bond_ab_arp_probe(struct bonding *bond)
>> {
>> struct slave *slave, *next_slave;
>> - int i;
>>
>> read_lock(&bond->curr_slave_lock);
>>
>> @@ -2923,7 +2921,7 @@ static void bond_ab_arp_probe(struct bonding *bond)
>>
>> /* search for next candidate */
>> next_slave = bond_next_slave(bond, bond->current_arp_slave);
>> - bond_for_each_slave_from(bond, slave, i, next_slave) {
>> + bond_for_each_slave_from(bond, slave, next_slave) {
>> if (IS_UP(slave->dev)) {
>> slave->link = BOND_LINK_BACK;
>> bond_set_slave_active_flags(slave);
>> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
>> index 9898493..a3ab47f 100644
>> --- a/drivers/net/bonding/bonding.h
>> +++ b/drivers/net/bonding/bonding.h
>> @@ -119,14 +119,25 @@
>> * bond_for_each_slave_from - iterate the slaves list from a starting point
>> * @bond: the bond holding this list.
>> * @pos: current slave.
>> - * @cnt: counter for max number of moves
>> * @start: starting point.
>> *
>> * Caller must hold bond->lock
>> */
>> -#define bond_for_each_slave_from(bond, pos, cnt, start) \
>> - for (cnt = 0, pos = start; pos && cnt < (bond)->slave_cnt; \
>> - cnt++, pos = bond_next_slave(bond, pos))
>> +#define bond_for_each_slave_from(bond, pos, start) \
>> + for (int cnt = 0, pos = start; pos && cnt < (bond)->slave_cnt; \
>> + cnt++, pos = bond_next_slave(bond, pos))
>> +
> Please read below the argument against using the nested cnt definition.
>
>> +/**
>> + * bond_for_each_slave_from_rcu - iterate the slaves list from a starting point
>> + * @bond: the bond holding this list.
>> + * @pos: current slave.
>> + * @start: starting point.
>> + *
>> + * Caller must hold rcu_read_lock
>> + */
>> +#define bond_for_each_slave_from_rcu(bond, pos, start) \
>> + for (int cnt = 0, pos = start; pos && cnt < (bond)->slave_cnt; \
>> + cnt++, pos = bond_next_slave_rcu(bond, pos))
>>
> I don't think you can rely on slave_cnt in RCU, you may go overboard and pass
> twice over the same slave if a slave gets removed, or the opposite. Also this
> definition of cnt is troublesome because the name is quite common, I don't know
> if it's accepted, but it if it is at least change the name to something like
> __cnt or anything that is less likely to be defined.
> The cnt argument goes for bond_for_each_slave_from as well.
>
yes, more details need to think about, I modify the function to this:
#define bond_for_each_slave_from(bond, pos, start) \
for (pos = start; (pos == bond_next_slave(bond, start) ? \
&pos->list != &bond->slave_list : \
&pos->list != &start->list); \
pos = bond_next_slave(bond, pos))
I think it is fine here, or I miss something, please tell me, thanks. :)
>> /**
>> * bond_for_each_slave - iterate over all slaves
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
^ permalink raw reply
* [PATCH v3 3/3] Send cgroup_path in SCM_CGROUP
From: Jan Kaluza @ 2013-09-04 6:14 UTC (permalink / raw)
To: davem
Cc: LKML, netdev, eparis, rgb, tj, lizefan, containers, cgroups, viro,
Jan Kaluza
In-Reply-To: <1378275261-4553-1-git-send-email-jkaluza@redhat.com>
Server-like processes in many cases need credentials and other
metadata of the peer, to decide if the calling process is allowed to
request a specific action, or the server just wants to log away this
type of information for auditing tasks.
The current practice to retrieve such process metadata is to look that
information up in procfs with the $PID received over SCM_CREDENTIALS.
This is sufficient for long-running tasks, but introduces a race which
cannot be worked around for short-living processes; the calling
process and all the information in /proc/$PID/ is gone before the
receiver of the socket message can look it up.
This introduces a new SCM type called SCM_CGROUP to allow the direct
attaching of "cgroup_path" to SCM, which is significantly more
efficient and will reliably avoid the race with the round-trip over
procfs.
Signed-off-by: Jan Kaluza <jkaluza@redhat.com>
---
include/linux/socket.h | 1 +
include/net/af_unix.h | 1 +
include/net/scm.h | 15 +++++++++++++++
net/core/scm.c | 18 ++++++++++++++++++
net/unix/af_unix.c | 20 ++++++++++++++++++++
5 files changed, 55 insertions(+)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 6c7ace0..621fff1 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -133,6 +133,7 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr *__msg, struct cmsghdr
#define SCM_AUDIT 0x04 /* rw: struct uaudit */
#define SCM_PROCINFO 0x05 /* rw: comm + cmdline (NULL terminated
array of char *) */
+#define SCM_CGROUP 0x06 /* rw: cgroup path */
struct ucred {
__u32 pid;
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 05c7678..c49bf35 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -32,6 +32,7 @@ struct unix_skb_parms_scm {
unsigned int sessionid;
char *procinfo;
int procinfo_len;
+ char *cgroup_path;
};
struct unix_skb_parms {
diff --git a/include/net/scm.h b/include/net/scm.h
index 3346030..5398826 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -41,6 +41,7 @@ struct scm_cookie {
struct scm_creds creds; /* Skb credentials */
struct scm_audit audit; /* Skb audit */
struct scm_procinfo procinfo; /* Skb procinfo */
+ char *cgroup_path;
#ifdef CONFIG_SECURITY_NETWORK
u32 secid; /* Passed security ID */
#endif
@@ -52,6 +53,7 @@ extern int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie
extern void __scm_destroy(struct scm_cookie *scm);
extern struct scm_fp_list * scm_fp_dup(struct scm_fp_list *fpl);
extern int scm_get_current_procinfo(char **procinfo);
+extern int scm_get_current_cgroup_path(char **cgroup_path);
#ifdef CONFIG_SECURITY_NETWORK
static __inline__ void unix_get_peersec_dgram(struct socket *sock, struct scm_cookie *scm)
@@ -86,6 +88,12 @@ static inline void scm_set_procinfo(struct scm_cookie *scm,
scm->procinfo.len = len;
}
+static inline void scm_set_cgroup_path(struct scm_cookie *scm,
+ char *cgroup_path)
+{
+ scm->cgroup_path = cgroup_path;
+}
+
static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
{
put_pid(scm->pid);
@@ -140,6 +148,9 @@ static inline void scm_passec(struct socket *sock, struct msghdr *msg, struct sc
security_release_secctx(secdata, seclen);
}
}
+
+ kfree(scm->cgroup_path);
+ scm->cgroup_path = NULL;
}
#else
static inline void scm_passec(struct socket *sock, struct msghdr *msg, struct scm_cookie *scm)
@@ -172,6 +183,10 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
put_cmsg(msg, SOL_SOCKET, SCM_AUDIT, sizeof(uaudits), &uaudits);
put_cmsg(msg, SOL_SOCKET, SCM_PROCINFO, scm->procinfo.len,
scm->procinfo.procinfo);
+ if (scm->cgroup_path) {
+ put_cmsg(msg, SOL_SOCKET, SCM_CGROUP,
+ strlen(scm->cgroup_path), scm->cgroup_path);
+ }
}
scm_destroy_cred(scm);
diff --git a/net/core/scm.c b/net/core/scm.c
index 09ec044..2d408b9 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -404,3 +404,21 @@ out:
return res;
}
EXPORT_SYMBOL(scm_get_current_procinfo);
+
+int scm_get_current_cgroup_path(char **cgroup_path)
+{
+ int ret = 0;
+
+ *cgroup_path = kmalloc(PATH_MAX, GFP_KERNEL);
+ if (!(*cgroup_path))
+ return -ENOMEM;
+
+ ret = task_cgroup_path(current, *cgroup_path, PATH_MAX);
+ if (ret < 0) {
+ kfree(*cgroup_path);
+ *cgroup_path = NULL;
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(scm_get_current_cgroup_path);
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ab0be13..b638083 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1344,6 +1344,7 @@ static void unix_destruct_scm(struct sk_buff *skb)
if (UNIXCB(skb).scm) {
scm.procinfo.procinfo = UNIXSCM(skb).procinfo;
scm.procinfo.len = UNIXSCM(skb).procinfo_len;
+ scm.cgroup_path = UNIXSCM(skb).cgroup_path;
}
if (UNIXCB(skb).fp)
unix_detach_fds(&scm, skb);
@@ -1420,6 +1421,14 @@ static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool sen
return -ENOMEM;
}
+ UNIXSCM(skb).cgroup_path = NULL;
+ if (scm->cgroup_path) {
+ UNIXSCM(skb).cgroup_path = kstrdup(scm->cgroup_path,
+ GFP_KERNEL);
+ if (!UNIXSCM(skb).cgroup_path)
+ return -ENOMEM;
+ }
+
skb->destructor = unix_destruct_scm;
return err;
}
@@ -1443,6 +1452,7 @@ static void maybe_add_creds(struct sk_buff *skb, const struct socket *sock,
UNIXSCM(skb).sessionid = audit_get_sessionid(current);
UNIXSCM(skb).procinfo_len = scm_get_current_procinfo(
&UNIXSCM(skb).procinfo);
+ scm_get_current_cgroup_path(&UNIXSCM(skb).cgroup_path);
}
}
@@ -1849,6 +1859,11 @@ static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock,
GFP_KERNEL),
UNIXSCM(skb).procinfo_len);
}
+ if (UNIXSCM(skb).cgroup_path) {
+ scm_set_cgroup_path(siocb->scm,
+ kstrdup(UNIXSCM(skb).cgroup_path,
+ GFP_KERNEL));
+ }
}
unix_set_secdata(siocb->scm, skb);
@@ -2042,6 +2057,11 @@ again:
GFP_KERNEL),
UNIXSCM(skb).procinfo_len);
}
+ if (UNIXSCM(skb).cgroup_path) {
+ scm_set_cgroup_path(siocb->scm,
+ kstrdup(UNIXSCM(skb).cgroup_path,
+ GFP_KERNEL));
+ }
}
check_creds = 1;
}
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox