Netdev List
 help / color / mirror / Atom feed
* 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

* [PATCH v3 2/3] Send comm and cmdline in SCM_PROCINFO
From: Jan Kaluza @ 2013-09-04  6:14 UTC (permalink / raw)
  To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
  Cc: Jan Kaluza, rgb-H+wXaHxf7aLQT0dZR+AlfA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
	eparis-H+wXaHxf7aLQT0dZR+AlfA,
	viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, tj-DgEjT+Ai2ygdnm+yROfE0A,
	cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1378275261-4553-1-git-send-email-jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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_PROCINFO to allow the direct
attaching of "comm" and "cmdline" to SCM, which is significantly more
efficient and will reliably avoid the race with the round-trip over
procfs.

To achieve that, new struct called unix_skb_parms_scm had to be created,
because otherwise unix_skb_parms would be too big.

scm_get_current_procinfo is inspired by ./fs/proc/base.c.

Signed-off-by: Jan Kaluza <jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
 include/linux/socket.h |  2 ++
 include/net/af_unix.h  | 11 +++++++--
 include/net/scm.h      | 24 +++++++++++++++++++
 net/core/scm.c         | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++
 net/unix/af_unix.c     | 57 +++++++++++++++++++++++++++++++++++++------
 5 files changed, 150 insertions(+), 9 deletions(-)

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 505047a..6c7ace0 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -131,6 +131,8 @@ static inline struct cmsghdr * cmsg_nxthdr (struct msghdr *__msg, struct cmsghdr
 #define SCM_CREDENTIALS 0x02		/* rw: struct ucred		*/
 #define SCM_SECURITY	0x03		/* rw: security label		*/
 #define SCM_AUDIT	0x04		/* rw: struct uaudit		*/
+#define SCM_PROCINFO	0x05	/* rw: comm + cmdline (NULL terminated
+					   array of char *) */
 
 struct ucred {
 	__u32	pid;
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 3b9d22a..05c7678 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -27,6 +27,13 @@ struct unix_address {
 	struct sockaddr_un name[0];
 };
 
+struct unix_skb_parms_scm {
+	kuid_t loginuid;
+	unsigned int sessionid;
+	char *procinfo;
+	int procinfo_len;
+};
+
 struct unix_skb_parms {
 	struct pid		*pid;		/* Skb credentials	*/
 	kuid_t			uid;
@@ -36,12 +43,12 @@ struct unix_skb_parms {
 	u32			secid;		/* Security ID		*/
 #endif
 	u32			consumed;
-	kuid_t			loginuid;
-	unsigned int		sessionid;
+	struct unix_skb_parms_scm *scm;
 };
 
 #define UNIXCB(skb) 	(*(struct unix_skb_parms *)&((skb)->cb))
 #define UNIXSID(skb)	(&UNIXCB((skb)).secid)
+#define UNIXSCM(skb)	(*(UNIXCB((skb)).scm))
 
 #define unix_state_lock(s)	spin_lock(&unix_sk(s)->lock)
 #define unix_state_unlock(s)	spin_unlock(&unix_sk(s)->lock)
diff --git a/include/net/scm.h b/include/net/scm.h
index e349a25..3346030 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -30,11 +30,17 @@ struct scm_fp_list {
 	struct file		*fp[SCM_MAX_FD];
 };
 
+struct scm_procinfo {
+	char *procinfo;
+	int len;
+};
+
 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	*/
+	struct scm_procinfo	procinfo;	/* Skb procinfo */
 #ifdef CONFIG_SECURITY_NETWORK
 	u32			secid;		/* Passed security ID 	*/
 #endif
@@ -45,6 +51,7 @@ extern void scm_detach_fds_compat(struct msghdr *msg, struct scm_cookie *scm);
 extern int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *scm);
 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);
 
 #ifdef CONFIG_SECURITY_NETWORK
 static __inline__ void unix_get_peersec_dgram(struct socket *sock, struct scm_cookie *scm)
@@ -72,10 +79,20 @@ static inline void scm_set_audit(struct scm_cookie *scm,
 	scm->audit.sessionid = sessionid;
 }
 
+static inline void scm_set_procinfo(struct scm_cookie *scm,
+				    char *procinfo, int len)
+{
+	scm->procinfo.procinfo = procinfo;
+	scm->procinfo.len = len;
+}
+
 static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
 {
 	put_pid(scm->pid);
 	scm->pid  = NULL;
+	kfree(scm->procinfo.procinfo);
+	scm->procinfo.procinfo = NULL;
+	scm->procinfo.len = 0;
 }
 
 static __inline__ void scm_destroy(struct scm_cookie *scm)
@@ -88,6 +105,8 @@ static __inline__ void scm_destroy(struct scm_cookie *scm)
 static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
 			       struct scm_cookie *scm, bool forcecreds)
 {
+	char *procinfo;
+	int len;
 	memset(scm, 0, sizeof(*scm));
 	scm->creds.uid = INVALID_UID;
 	scm->creds.gid = INVALID_GID;
@@ -96,6 +115,9 @@ static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
 			     current_gid());
 		scm_set_audit(scm, audit_get_loginuid(current),
 			      audit_get_sessionid(current));
+		len = scm_get_current_procinfo(&procinfo);
+		if (len > 0)
+			scm_set_procinfo(scm, procinfo, len);
 	}
 	unix_get_peersec_dgram(sock, scm);
 	if (msg->msg_controllen <= 0)
@@ -148,6 +170,8 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
 		};
 		put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(ucreds), &ucreds);
 		put_cmsg(msg, SOL_SOCKET, SCM_AUDIT, sizeof(uaudits), &uaudits);
+		put_cmsg(msg, SOL_SOCKET, SCM_PROCINFO, scm->procinfo.len,
+				 scm->procinfo.procinfo);
 	}
 
 	scm_destroy_cred(scm);
diff --git a/net/core/scm.c b/net/core/scm.c
index 03795d0..09ec044 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -339,3 +339,68 @@ struct scm_fp_list *scm_fp_dup(struct scm_fp_list *fpl)
 	return new_fpl;
 }
 EXPORT_SYMBOL(scm_fp_dup);
+
+int scm_get_current_procinfo(char **procinfo)
+{
+	int res = 0;
+	unsigned int len;
+	char *buffer = NULL;
+	struct mm_struct *mm;
+	int comm_len = strlen(current->comm);
+
+	*procinfo = NULL;
+
+	buffer = kmalloc(PAGE_SIZE, GFP_KERNEL);
+	if (!buffer)
+		return -ENOMEM;
+
+	mm = get_task_mm(current);
+	if (!mm)
+		goto out;
+	if (!mm->arg_end)
+		goto out_mm;    /* Shh! No looking before we're done */
+
+	len = mm->arg_end - mm->arg_start;
+
+	if (len > PAGE_SIZE)
+		len = PAGE_SIZE;
+
+	res = access_process_vm(current, mm->arg_start, buffer, len, 0);
+
+	/* If the nul at the end of args has been overwritten, then
+	 * assume application is using setproctitle(3).
+	 */
+	if (res > 0 && buffer[res-1] != '\0' && len < PAGE_SIZE) {
+		len = strnlen(buffer, res);
+		if (len < res) {
+			res = len;
+		} else {
+			len = mm->env_end - mm->env_start;
+			if (len > PAGE_SIZE - res)
+				len = PAGE_SIZE - res;
+			res += access_process_vm(current, mm->env_start,
+						 buffer+res, len, 0);
+			res = strnlen(buffer, res);
+		}
+	}
+
+	/* strlen(comm) + \0 + len of cmdline */
+	len = comm_len + 1 + res;
+	*procinfo = kmalloc(len, GFP_KERNEL);
+	if (!*procinfo) {
+		res = -ENOMEM;
+		goto out_mm;
+	}
+
+	memcpy(*procinfo, current->comm, comm_len + 1); /* include \0 */
+	if (res > 0)
+		memcpy(*procinfo + comm_len + 1, buffer, res);
+	res = len;
+
+out_mm:
+	mmput(mm);
+out:
+	kfree(buffer);
+	return res;
+}
+EXPORT_SYMBOL(scm_get_current_procinfo);
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index c410f76..ab0be13 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1341,9 +1341,14 @@ static void unix_destruct_scm(struct sk_buff *skb)
 	struct scm_cookie scm;
 	memset(&scm, 0, sizeof(scm));
 	scm.pid  = UNIXCB(skb).pid;
+	if (UNIXCB(skb).scm) {
+		scm.procinfo.procinfo = UNIXSCM(skb).procinfo;
+		scm.procinfo.len = UNIXSCM(skb).procinfo_len;
+	}
 	if (UNIXCB(skb).fp)
 		unix_detach_fds(&scm, skb);
 
+	kfree(UNIXCB(skb).scm);
 	/* Alas, it calls VFS */
 	/* So fscking what? fput() had been SMP-safe since the last Summer */
 	scm_destroy(&scm);
@@ -1390,15 +1395,31 @@ static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool sen
 {
 	int err = 0;
 
+	if (!UNIXCB(skb).scm) {
+		UNIXCB(skb).scm = kmalloc(sizeof(struct unix_skb_parms_scm),
+					  GFP_KERNEL);
+		if (!UNIXCB(skb).scm)
+			return -ENOMEM;
+	}
+
 	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;
+	UNIXSCM(skb).loginuid = scm->audit.loginuid;
+	UNIXSCM(skb).sessionid = scm->audit.sessionid;
 	UNIXCB(skb).fp = NULL;
 	if (scm->fp && send_fds)
 		err = unix_attach_fds(scm, skb);
 
+	UNIXSCM(skb).procinfo = NULL;
+	if (scm->procinfo.procinfo) {
+		UNIXSCM(skb).procinfo_len = scm->procinfo.len;
+		UNIXSCM(skb).procinfo = kmemdup(scm->procinfo.procinfo,
+					scm->procinfo.len, GFP_KERNEL);
+		if (!UNIXSCM(skb).procinfo)
+			return -ENOMEM;
+	}
+
 	skb->destructor = unix_destruct_scm;
 	return err;
 }
@@ -1418,8 +1439,10 @@ 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);
+		UNIXSCM(skb).loginuid = audit_get_loginuid(current);
+		UNIXSCM(skb).sessionid = audit_get_sessionid(current);
+		UNIXSCM(skb).procinfo_len = scm_get_current_procinfo(
+			&UNIXSCM(skb).procinfo);
 	}
 }
 
@@ -1816,7 +1839,17 @@ 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);
+	if (UNIXCB(skb).scm) {
+		scm_set_audit(siocb->scm, UNIXSCM(skb).loginuid,
+			      UNIXSCM(skb).sessionid);
+		if (UNIXSCM(skb).procinfo) {
+			scm_set_procinfo(siocb->scm,
+					 kmemdup(UNIXSCM(skb).procinfo,
+						 UNIXSCM(skb).procinfo_len,
+						 GFP_KERNEL),
+					 UNIXSCM(skb).procinfo_len);
+		}
+	}
 	unix_set_secdata(siocb->scm, skb);
 
 	if (!(flags & MSG_PEEK)) {
@@ -1998,8 +2031,18 @@ 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);
+			if (UNIXCB(skb).scm) {
+				scm_set_audit(siocb->scm,
+					      UNIXSCM(skb).loginuid,
+					      UNIXSCM(skb).sessionid);
+				if (UNIXSCM(skb).procinfo) {
+					scm_set_procinfo(siocb->scm,
+						kmemdup(UNIXSCM(skb).procinfo,
+						UNIXSCM(skb).procinfo_len,
+						GFP_KERNEL),
+						UNIXSCM(skb).procinfo_len);
+				}
+			}
 			check_creds = 1;
 		}
 
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH v3 1/3] Send loginuid and sessionid in SCM_AUDIT
From: Jan Kaluza @ 2013-09-04  6:14 UTC (permalink / raw)
  To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
  Cc: Jan Kaluza, rgb-H+wXaHxf7aLQT0dZR+AlfA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
	eparis-H+wXaHxf7aLQT0dZR+AlfA,
	viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, tj-DgEjT+Ai2ygdnm+yROfE0A,
	cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1378275261-4553-1-git-send-email-jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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.

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;
 		}
 
-- 
1.8.3.1

^ permalink raw reply related

* [PATCH v3 0/3] Send audit/procinfo/cgroup data in socket-level control message
From: Jan Kaluza @ 2013-09-04  6:14 UTC (permalink / raw)
  To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
  Cc: Jan Kaluza, rgb-H+wXaHxf7aLQT0dZR+AlfA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, LKML,
	eparis-H+wXaHxf7aLQT0dZR+AlfA,
	viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, tj-DgEjT+Ai2ygdnm+yROfE0A,
	cgroups-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1377614400-27122-1-git-send-email-jkaluza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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.

Changes in v3:
- Better description of patches (Thanks to Kay Sievers)

Changes in v2:
- use PATH_MAX instead of PAGE_SIZE in SCM_CGROUP patch
- describe each patch individually

Jan Kaluza (3):
  Send loginuid and sessionid in SCM_AUDIT
  Send comm and cmdline in SCM_PROCINFO
  Send cgroup_path in SCM_CGROUP

 include/linux/socket.h |  9 ++++++
 include/net/af_unix.h  | 10 ++++++
 include/net/scm.h      | 67 ++++++++++++++++++++++++++++++++++++++--
 net/core/scm.c         | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++
 net/unix/af_unix.c     | 70 ++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 237 insertions(+), 2 deletions(-)

-- 
1.8.3.1

^ permalink raw reply

* Re: xen-netback: count number required slots for an skb more carefully
From: Matt Wilson @ 2013-09-04  6:04 UTC (permalink / raw)
  To: annie li
  Cc: Wei Liu, David Vrabel, xen-devel, Konrad Rzeszutek Wilk,
	Boris Ostrovsky, Ian Campbell, netdev, msw
In-Reply-To: <52269A37.7030600@oracle.com>

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.

Sorry for the delay. :-(

--msw

^ permalink raw reply

* Re: [PATCH net-next 3/5] driver/net: enic: Try DMA 64 first, then failover to DMA
From: Govindarajulu Varadarajan @ 2013-09-04  6:01 UTC (permalink / raw)
  To: Govindarajulu Varadarajan
  Cc: davem, netdev, linux-kernel, benve, ssujith, nistrive, umalhi
In-Reply-To: <1378273638-7780-4-git-send-email-govindarajulu90@gmail.com>

Hi Dave

The subject for this should be "driver/net: enic: Try DMA 64 first, then
failover to DMA 32"

The "32" got truncated, please add this while committing. Let me know if
you want me to send another patch.

thanks
//govind

On Wed, 4 Sep 2013, Govindarajulu Varadarajan wrote:

> In servers with more than 1.1 TB of RAM, the existing 40/32 bit DMA
> could cause failure as the DMA-able address could go outside the range
> addressable using 40/32 bits.
>
> The following patch first tried 64 bit DMA if possible, failover to 32
> bit.
>
> Signed-off-by: Sujith Sankar <ssujith@cisco.com>
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Govindarajulu Varadarajan <govindarajulu90@gmail.com>

^ permalink raw reply

* Re: [PATCH v2 net-next] pkt_sched: fq: Fair Queue packet scheduler
From: Eric Dumazet @ 2013-09-04  5:59 UTC (permalink / raw)
  To: Jason Wang
  Cc: David Miller, netdev, Yuchung Cheng, Neal Cardwell,
	Michael S. Tsirkin
In-Reply-To: <5226C4A0.6040709@redhat.com>

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.

TCP stack has the ooo_okay thing, I do not think a VM can get it.

nstat >/dev/null ; <your test> ; nstat

And tcpdump would certainly help ;)

^ permalink raw reply

* [PATCH net-next 5/5] driver/net: enic: update enic maintainers and driver
From: Govindarajulu Varadarajan @ 2013-09-04  5:47 UTC (permalink / raw)
  To: davem, netdev, linux-kernel
  Cc: benve, ssujith, nistrive, umalhi, Govindarajulu Varadarajan
In-Reply-To: <1378273638-7780-1-git-send-email-govindarajulu90@gmail.com>

Signed-off-by: Govindarajulu Varadarajan <govindarajulu90@gmail.com>
Signed-off-by: Sujith Sankar <ssujith@cisco.com>
Signed-off-by: Nishank Trivedi <nistrive@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
---
 MAINTAINERS                            | 3 ++-
 drivers/net/ethernet/cisco/enic/enic.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 705bb96..ecb83cd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2076,7 +2076,8 @@ F:	drivers/usb/chipidea/
 
 CISCO VIC ETHERNET NIC DRIVER
 M:	Christian Benvenuti <benve@cisco.com>
-M:	Roopa Prabhu <roprabhu@cisco.com>
+M:	Sujith Sankar <ssujith@cisco.com>
+M:	Govindarajulu Varadarajan <govindarajulu90@gmail.com>
 M:	Neel Patel <neepatel@cisco.com>
 M:	Nishank Trivedi <nistrive@cisco.com>
 S:	Supported
diff --git a/drivers/net/ethernet/cisco/enic/enic.h b/drivers/net/ethernet/cisco/enic/enic.h
index 34b637a..e9f7c65 100644
--- a/drivers/net/ethernet/cisco/enic/enic.h
+++ b/drivers/net/ethernet/cisco/enic/enic.h
@@ -32,7 +32,7 @@
 
 #define DRV_NAME		"enic"
 #define DRV_DESCRIPTION		"Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION		"2.1.1.43"
+#define DRV_VERSION		"2.1.1.50"
 #define DRV_COPYRIGHT		"Copyright 2008-2013 Cisco Systems, Inc"
 
 #define ENIC_BARS_MAX		6
-- 
1.8.4

^ permalink raw reply related

* [PATCH net-next 4/5] driver/net: enic: Exposing symbols for Cisco's low latency driver
From: Govindarajulu Varadarajan @ 2013-09-04  5:47 UTC (permalink / raw)
  To: davem, netdev, linux-kernel
  Cc: benve, ssujith, nistrive, umalhi, Govindarajulu Varadarajan
In-Reply-To: <1378273638-7780-1-git-send-email-govindarajulu90@gmail.com>

This patch exposes symbols for usnic low latency driver that can be used to 
register and unregister vNics as well to traverse the resources on vNics.

Signed-off-by: Upinder Malhi <umalhi@cisco.com>
Signed-off-by: Nishank Trivedi <nistrive@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
---
 drivers/net/ethernet/cisco/enic/vnic_dev.c | 10 ++++++++++
 drivers/net/ethernet/cisco/enic/vnic_dev.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/cisco/enic/vnic_dev.c b/drivers/net/ethernet/cisco/enic/vnic_dev.c
index 97455c5..69dd925 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_dev.c
+++ b/drivers/net/ethernet/cisco/enic/vnic_dev.c
@@ -175,6 +175,7 @@ unsigned int vnic_dev_get_res_count(struct vnic_dev *vdev,
 {
 	return vdev->res[type].count;
 }
+EXPORT_SYMBOL(vnic_dev_get_res_count);
 
 void __iomem *vnic_dev_get_res(struct vnic_dev *vdev, enum vnic_res_type type,
 	unsigned int index)
@@ -193,6 +194,7 @@ void __iomem *vnic_dev_get_res(struct vnic_dev *vdev, enum vnic_res_type type,
 		return (char __iomem *)vdev->res[type].vaddr;
 	}
 }
+EXPORT_SYMBOL(vnic_dev_get_res);
 
 static unsigned int vnic_dev_desc_ring_size(struct vnic_dev_ring *ring,
 	unsigned int desc_count, unsigned int desc_size)
@@ -942,6 +944,7 @@ void vnic_dev_unregister(struct vnic_dev *vdev)
 		kfree(vdev);
 	}
 }
+EXPORT_SYMBOL(vnic_dev_unregister);
 
 struct vnic_dev *vnic_dev_register(struct vnic_dev *vdev,
 	void *priv, struct pci_dev *pdev, struct vnic_dev_bar *bar,
@@ -969,6 +972,13 @@ err_out:
 	vnic_dev_unregister(vdev);
 	return NULL;
 }
+EXPORT_SYMBOL(vnic_dev_register);
+
+struct pci_dev *vnic_dev_get_pdev(struct vnic_dev *vdev)
+{
+	return vdev->pdev;
+}
+EXPORT_SYMBOL(vnic_dev_get_pdev);
 
 int vnic_dev_init_prov2(struct vnic_dev *vdev, u8 *buf, u32 len)
 {
diff --git a/drivers/net/ethernet/cisco/enic/vnic_dev.h b/drivers/net/ethernet/cisco/enic/vnic_dev.h
index f3d9b79..e670029 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_dev.h
+++ b/drivers/net/ethernet/cisco/enic/vnic_dev.h
@@ -127,6 +127,7 @@ int vnic_dev_set_ig_vlan_rewrite_mode(struct vnic_dev *vdev,
 struct vnic_dev *vnic_dev_register(struct vnic_dev *vdev,
 	void *priv, struct pci_dev *pdev, struct vnic_dev_bar *bar,
 	unsigned int num_bars);
+struct pci_dev *vnic_dev_get_pdev(struct vnic_dev *vdev);
 int vnic_dev_init_prov2(struct vnic_dev *vdev, u8 *buf, u32 len);
 int vnic_dev_enable2(struct vnic_dev *vdev, int active);
 int vnic_dev_enable2_done(struct vnic_dev *vdev, int *status);
-- 
1.8.4

^ permalink raw reply related

* [PATCH net-next 3/5] driver/net: enic: Try DMA 64 first, then failover to DMA
From: Govindarajulu Varadarajan @ 2013-09-04  5:47 UTC (permalink / raw)
  To: davem, netdev, linux-kernel
  Cc: benve, ssujith, nistrive, umalhi, Govindarajulu Varadarajan
In-Reply-To: <1378273638-7780-1-git-send-email-govindarajulu90@gmail.com>

In servers with more than 1.1 TB of RAM, the existing 40/32 bit DMA
could cause failure as the DMA-able address could go outside the range
addressable using 40/32 bits.

The following patch first tried 64 bit DMA if possible, failover to 32
bit.

Signed-off-by: Sujith Sankar <ssujith@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Govindarajulu Varadarajan <govindarajulu90@gmail.com>
---
 drivers/net/ethernet/cisco/enic/enic_main.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 93898ba..7b756cf9 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -2080,11 +2080,11 @@ static int enic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	pci_set_master(pdev);
 
 	/* Query PCI controller on system for DMA addressing
-	 * limitation for the device.  Try 40-bit first, and
+	 * limitation for the device.  Try 64-bit first, and
 	 * fail to 32-bit.
 	 */
 
-	err = pci_set_dma_mask(pdev, DMA_BIT_MASK(40));
+	err = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
 	if (err) {
 		err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
 		if (err) {
@@ -2098,10 +2098,10 @@ static int enic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 			goto err_out_release_regions;
 		}
 	} else {
-		err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
+		err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
 		if (err) {
 			dev_err(dev, "Unable to obtain %u-bit DMA "
-				"for consistent allocations, aborting\n", 40);
+				"for consistent allocations, aborting\n", 64);
 			goto err_out_release_regions;
 		}
 		using_dac = 1;
-- 
1.8.4

^ permalink raw reply related

* [PATCH net-next 2/5] driver/net: enic: record q_number and rss_hash for skb
From: Govindarajulu Varadarajan @ 2013-09-04  5:47 UTC (permalink / raw)
  To: davem, netdev, linux-kernel
  Cc: benve, ssujith, nistrive, umalhi, Govindarajulu Varadarajan
In-Reply-To: <1378273638-7780-1-git-send-email-govindarajulu90@gmail.com>

The following patch sets the skb->rxhash and skb->q_number.
This is used by RPS and RFS. Kernel can make use of hw provided hash
instead of calculating the hash.

Signed-off-by: Govindarajulu Varadarajan <govindarajulu90@gmail.com>
Signed-off-by: Nishank Trivedi <nistrive@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
---
 drivers/net/ethernet/cisco/enic/enic_main.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 1ab3f18..93898ba 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -1034,6 +1034,14 @@ static void enic_rq_indicate_buf(struct vnic_rq *rq,
 
 		skb_put(skb, bytes_written);
 		skb->protocol = eth_type_trans(skb, netdev);
+		skb_record_rx_queue(skb, q_number);
+		if (netdev->features & NETIF_F_RXHASH) {
+			skb->rxhash = rss_hash;
+			if (rss_type & (NIC_CFG_RSS_HASH_TYPE_TCP_IPV6_EX |
+					NIC_CFG_RSS_HASH_TYPE_TCP_IPV6 |
+					NIC_CFG_RSS_HASH_TYPE_TCP_IPV4))
+				skb->l4_rxhash = true;
+		}
 
 		if ((netdev->features & NETIF_F_RXCSUM) && !csum_not_calc) {
 			skb->csum = htons(checksum);
@@ -2209,6 +2217,7 @@ static int enic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	}
 
 	netif_set_real_num_tx_queues(netdev, enic->wq_count);
+	netif_set_real_num_rx_queues(netdev, enic->rq_count);
 
 	/* Setup notification timer, HW reset task, and wq locks
 	 */
@@ -2258,6 +2267,8 @@ static int enic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (ENIC_SETTING(enic, TSO))
 		netdev->hw_features |= NETIF_F_TSO |
 			NETIF_F_TSO6 | NETIF_F_TSO_ECN;
+	if (ENIC_SETTING(enic, RSS))
+		netdev->hw_features |= NETIF_F_RXHASH;
 	if (ENIC_SETTING(enic, RXCSUM))
 		netdev->hw_features |= NETIF_F_RXCSUM;
 
-- 
1.8.4

^ permalink raw reply related

* [PATCH net-next 1/5] driver/net: enic: Add multi tx support for enic
From: Govindarajulu Varadarajan @ 2013-09-04  5:47 UTC (permalink / raw)
  To: davem, netdev, linux-kernel
  Cc: benve, ssujith, nistrive, umalhi, Govindarajulu Varadarajan
In-Reply-To: <1378273638-7780-1-git-send-email-govindarajulu90@gmail.com>

The following patch adds multi tx support for enic.

Signed-off-by: Nishank Trivedi <nistrive@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Govindarajulu Varadarajan <govindarajulu90@gmail.com>
---
 drivers/net/ethernet/cisco/enic/enic.h      |  2 +-
 drivers/net/ethernet/cisco/enic/enic_main.c | 36 +++++++++++++++++++----------
 2 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/cisco/enic/enic.h b/drivers/net/ethernet/cisco/enic/enic.h
index be16731..34b637a 100644
--- a/drivers/net/ethernet/cisco/enic/enic.h
+++ b/drivers/net/ethernet/cisco/enic/enic.h
@@ -37,7 +37,7 @@
 
 #define ENIC_BARS_MAX		6
 
-#define ENIC_WQ_MAX		1
+#define ENIC_WQ_MAX		8
 #define ENIC_RQ_MAX		8
 #define ENIC_CQ_MAX		(ENIC_WQ_MAX + ENIC_RQ_MAX)
 #define ENIC_INTR_MAX		(ENIC_CQ_MAX + 2)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index bcf15b1..1ab3f18 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -128,10 +128,10 @@ static int enic_wq_service(struct vnic_dev *vdev, struct cq_desc *cq_desc,
 		completed_index, enic_wq_free_buf,
 		opaque);
 
-	if (netif_queue_stopped(enic->netdev) &&
+	if (netif_tx_queue_stopped(netdev_get_tx_queue(enic->netdev, q_number)) &&
 	    vnic_wq_desc_avail(&enic->wq[q_number]) >=
 	    (MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS))
-		netif_wake_queue(enic->netdev);
+		netif_wake_subqueue(enic->netdev, q_number);
 
 	spin_unlock(&enic->wq_lock[q_number]);
 
@@ -292,10 +292,15 @@ static irqreturn_t enic_isr_msix_rq(int irq, void *data)
 static irqreturn_t enic_isr_msix_wq(int irq, void *data)
 {
 	struct enic *enic = data;
-	unsigned int cq = enic_cq_wq(enic, 0);
-	unsigned int intr = enic_msix_wq_intr(enic, 0);
+	unsigned int cq;
+	unsigned int intr;
 	unsigned int wq_work_to_do = -1; /* no limit */
 	unsigned int wq_work_done;
+	unsigned int wq_irq;
+
+	wq_irq = (u32)irq - enic->msix_entry[enic_msix_wq_intr(enic, 0)].vector;
+	cq = enic_cq_wq(enic, wq_irq);
+	intr = enic_msix_wq_intr(enic, wq_irq);
 
 	wq_work_done = vnic_cq_service(&enic->cq[cq],
 		wq_work_to_do, enic_wq_service, NULL);
@@ -511,14 +516,18 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
 	struct net_device *netdev)
 {
 	struct enic *enic = netdev_priv(netdev);
-	struct vnic_wq *wq = &enic->wq[0];
+	struct vnic_wq *wq;
 	unsigned long flags;
+	unsigned int txq_map;
 
 	if (skb->len <= 0) {
 		dev_kfree_skb(skb);
 		return NETDEV_TX_OK;
 	}
 
+	txq_map = skb_get_queue_mapping(skb) % enic->wq_count;
+	wq = &enic->wq[txq_map];
+
 	/* Non-TSO sends must fit within ENIC_NON_TSO_MAX_DESC descs,
 	 * which is very likely.  In the off chance it's going to take
 	 * more than * ENIC_NON_TSO_MAX_DESC, linearize the skb.
@@ -531,23 +540,23 @@ static netdev_tx_t enic_hard_start_xmit(struct sk_buff *skb,
 		return NETDEV_TX_OK;
 	}
 
-	spin_lock_irqsave(&enic->wq_lock[0], flags);
+	spin_lock_irqsave(&enic->wq_lock[txq_map], flags);
 
 	if (vnic_wq_desc_avail(wq) <
 	    skb_shinfo(skb)->nr_frags + ENIC_DESC_MAX_SPLITS) {
-		netif_stop_queue(netdev);
+		netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
 		/* This is a hard error, log it */
 		netdev_err(netdev, "BUG! Tx ring full when queue awake!\n");
-		spin_unlock_irqrestore(&enic->wq_lock[0], flags);
+		spin_unlock_irqrestore(&enic->wq_lock[txq_map], flags);
 		return NETDEV_TX_BUSY;
 	}
 
 	enic_queue_wq_skb(enic, wq, skb);
 
 	if (vnic_wq_desc_avail(wq) < MAX_SKB_FRAGS + ENIC_DESC_MAX_SPLITS)
-		netif_stop_queue(netdev);
+		netif_tx_stop_queue(netdev_get_tx_queue(netdev, txq_map));
 
-	spin_unlock_irqrestore(&enic->wq_lock[0], flags);
+	spin_unlock_irqrestore(&enic->wq_lock[txq_map], flags);
 
 	return NETDEV_TX_OK;
 }
@@ -1369,7 +1378,7 @@ static int enic_open(struct net_device *netdev)
 
 	enic_set_rx_mode(netdev);
 
-	netif_wake_queue(netdev);
+	netif_tx_wake_all_queues(netdev);
 
 	for (i = 0; i < enic->rq_count; i++)
 		napi_enable(&enic->napi[i]);
@@ -2032,7 +2041,8 @@ static int enic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 	 * instance data is initialized to zero.
 	 */
 
-	netdev = alloc_etherdev(sizeof(struct enic));
+	netdev = alloc_etherdev_mqs(sizeof(struct enic),
+				    ENIC_RQ_MAX, ENIC_WQ_MAX);
 	if (!netdev)
 		return -ENOMEM;
 
@@ -2198,6 +2208,8 @@ static int enic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 		goto err_out_dev_close;
 	}
 
+	netif_set_real_num_tx_queues(netdev, enic->wq_count);
+
 	/* Setup notification timer, HW reset task, and wq locks
 	 */
 
-- 
1.8.4

^ permalink raw reply related

* [PATCH net-next 0/5] driver/net: enic: enic driver updates
From: Govindarajulu Varadarajan @ 2013-09-04  5:47 UTC (permalink / raw)
  To: davem, netdev, linux-kernel
  Cc: benve, ssujith, nistrive, umalhi, Govindarajulu Varadarajan

This series includes support for multi-tx, rss_hash, RPS, RFS, DMA64, 
export symbols for cisco low latency driver and update the driver version and 
driver maintainers.

Govindarajulu Varadarajan (5):
  driver/net: enic: Add multi tx support for enic
  driver/net: enic: record q_number and rss_hash for skb
  driver/net: enic: Try DMA 64 first, then failover to DMA
  driver/net: enic: Exposing symbols for Cisco's low latency driver
  driver/net: enic: update enic maintainers and driver

 MAINTAINERS                                 |  3 +-
 drivers/net/ethernet/cisco/enic/enic.h      |  4 +--
 drivers/net/ethernet/cisco/enic/enic_main.c | 55 ++++++++++++++++++++---------
 drivers/net/ethernet/cisco/enic/vnic_dev.c  | 10 ++++++
 drivers/net/ethernet/cisco/enic/vnic_dev.h  |  1 +
 5 files changed, 54 insertions(+), 19 deletions(-)

-- 
1.8.4

^ permalink raw reply

* Re: [PATCH v2 net-next] pkt_sched: fq: Fair Queue packet scheduler
From: Jason Wang @ 2013-09-04  5:26 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: David Miller, netdev, Yuchung Cheng, Neal Cardwell,
	Michael S. Tsirkin
In-Reply-To: <1377816595.8277.54.camel@edumazet-glaptop>

On 08/30/2013 06:49 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> - Uses perfect flow match (not stochastic hash like SFQ/FQ_codel)
> - Uses the new_flow/old_flow separation from FQ_codel
> - New flows get an initial credit allowing IW10 without added delay.
> - Special FIFO queue for high prio packets (no need for PRIO + FQ)
> - Uses a hash table of RB trees to locate the flows at enqueue() time
> - Smart on demand gc (at enqueue() time, RB tree lookup evicts old
>   unused flows)
> - Dynamic memory allocations.
> - Designed to allow millions of concurrent flows per Qdisc.
> - Small memory footprint : ~8K per Qdisc, and 104 bytes per flow.
> - Single high resolution timer for throttled flows (if any).
> - One RB tree to link throttled flows.
> - Ability to have a max rate per flow. We might add a socket option
>   to add per socket limitation.
>
> Attempts have been made to add TCP pacing in TCP stack, but this
> seems to add complex code to an already complex stack.
>
> TCP pacing is welcomed for flows having idle times, as the cwnd
> permits TCP stack to queue a possibly large number of packets.
>
[...]
>
> FQ gets a bunch of tunables as :
>
>   limit : max number of packets on whole Qdisc (default 10000)
>
>   flow_limit : max number of packets per flow (default 100)
>
>   quantum : the credit per RR round (default is 2 MTU)
>
>   initial_quantum : initial credit for new flows (default is 10 MTU)
>
>   maxrate : max per flow rate (default : unlimited)
>
>   buckets : number of RB trees (default : 1024) in hash table.
>                (consumes 8 bytes per bucket)
>
>   [no]pacing : disable/enable pacing (default is enable)
>
> All of them can be changed on a live qdisc.
>
> $ tc qd add dev eth0 root fq help
> Usage: ... fq [ limit PACKETS ] [ flow_limit PACKETS ]
>               [ quantum BYTES ] [ initial_quantum BYTES ]
>               [ maxrate RATE  ] [ buckets NUMBER ]
>               [ [no]pacing ]
>
> $ tc -s -d qd
> qdisc fq 8002: dev eth0 root refcnt 32 limit 10000p flow_limit 100p buckets 256 quantum 3028 initial_quantum 15140
>  Sent 216532416 bytes 148395 pkt (dropped 0, overlimits 0 requeues 14)
>  backlog 0b 0p requeues 14
>   511 flows, 511 inactive, 0 throttled
>   110 gc, 0 highprio, 0 retrans, 1143 throttled, 0 flows_plimit
>
>
> [1] Except if initial srtt is overestimated, as if using
> cached srtt in tcp metrics. We'll provide a fix for this issue.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> ---
> v2: added initial_quantum support

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?

^ permalink raw reply

* Re: [PATCH net-next v2] tcp: Change return value of tcp_rcv_established()
From: David Miller @ 2013-09-04  4:55 UTC (permalink / raw)
  To: subramanian.vijay; +Cc: netdev
In-Reply-To: <1378236202-27486-1-git-send-email-subramanian.vijay@gmail.com>

From: Vijay Subramanian <subramanian.vijay@gmail.com>
Date: Tue,  3 Sep 2013 12:23:22 -0700

> tcp_rcv_established() returns only one value namely 0. We change the return
> value to void (as suggested by David Miller).
> 
> After commit 0c24604b (tcp: implement RFC 5961 4.2), we no longer send RSTs in
> response to SYNs. We can remove the check and processing on the return value of
> tcp_rcv_established().
> 
> We also fix jtcp_rcv_established() in tcp_probe.c to match that of
> tcp_rcv_established().
> 
> 
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>

Applied.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox