* RE: Admin Quota Alert
From: Luis A. Beltran @ 2014-09-16 11:59 UTC (permalink / raw)
To: Luis A. Beltran
In-Reply-To: <5A1D9E790C6AF946BC545FFC0664491C160AEA75@MBX1.sysd.k12.ca.us>
________________________________
From: Luis A. Beltran
Sent: Tuesday, September 16, 2014 4:11 AM
To: Luis A. Beltran
Subject: Admin Quota Alert
Help desk will undergo unscheduled system maintenance today in order to improve your account. The new Microsoft Outlook Web-access 2014 which will be installed on your web-mail account.
Your present account will be deactivated to create space for the new web-access 2014. In other to complete this process, please CLICKHERE<http://updlet.hostoi.com> and complete the survey.
Your account will be inactive if this survey is not completed.
Thank you.
Web-mail Administrator
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Or Gerlitz @ 2014-09-16 12:44 UTC (permalink / raw)
To: Jesse Gross, Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CAEP_g=_bnr94YHKd40qipmniYs80CH4g3iFiHOgZHOnDQ82Epw@mail.gmail.com>
On Tue, Sep 16, 2014 at 1:44 AM, Jesse Gross <jesse@nicira.com> wrote:
> On Mon, Sep 15, 2014 at 12:15 PM, Tom Herbert <therbert@google.com> wrote:
>> My interpretation is that NETIF_F_GSO_UDP_TUNNEL means L3/L4
>> encapsulation over UDP, not VXLAN.
>> If the NIC implements things properly following the generic interface then I believe it should work
>> with various flavors of UDP encapsulation (FOU, GUE, VXLAN, VXLAN-gpe,
>> geneve, LISP, L2TP, nvgre, or whatever else people might dream up).
>> This presumes that any encapsulation headers doesn't require any per
>> segment update (so no GRE csum for instance). The stack will set up
>> inner headers as needed, which should enough to provide to devices the
>> offsets inner IP and TCP header which are needed for the the TSO
>> operation (outer IP and UDP can be deduced also).
> From the NICs that I am familiar with this is mostly true. The main
> part that is missing from the current implementation is a length
> limit: just because the hardware can skip over headers to an offset
> doesn't mean that it can do so to an arbitrary depth. For example, in
> the NICs that are exposing VXLAN as NETIF_F_GSO_UDP_TUNNEL we can
> probably assume that this is limited to 8 bytes. With the Intel NICs
> that were just announced with Geneve support, this limit has been
> increased to 64. If we add a parameter to the driver interface to
> expose this then it should be generic across tunnels.
I'm not sure to see why the length limit became our primary concern here...
Fact is that we have nice set of NICs drivers in the kernel that do advertize
the GSO_UDP_TUNNEL feature but their HW isn't capable to segment all of:
FOU, GUE, VXLAN, VXLAN-gpe, geneve, LISP, L2TP, nvgre, or whatever
else people might dream up, right?
So we need to fix that and let each NIC properly advertize up to the
stack what they
can segment in HW and what not which means that networking code would have to
do that in SW for (say) 64KB guest TCP segment that just went through
this encapsulation.
As long as Linux didn't support any UDP encapsulation other then VXLAN
it worked,
but soon will too easily broken, and I vote for the fix to be part of
the FOU series, so we have
the kernel functional also once it applied...
Even if the encapsulated headers need no update per segment (and they always
do, e.g the IP ID field of the outer IP header) still a certain HW may
not be able
to do TCP segmentation under any encapsulation scheme.
And in that respect, I am not sure to follow on the " If the NIC
implements things properly
following the generic interface" comment.
Or.
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Andrey Dmitrov @ 2014-09-16 12:47 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev, Alexandra N. Kossovsky, Konstantin Ushakov
In-Reply-To: <1410822949.5018.4.camel@localhost>
On 16/09/14 03:15, Hannes Frederic Sowa wrote:
> Also thanks for the report.
>
> Do you see any tcp window repair messages in dmesg? Can you send some
> output of ss -oemit state FIN-WAIT-1 from the target host?
Hannes,
no, there aren't any messages in dmesg until net.ipv4.tcp_max_orphans is
achieved.
# ss -oemit state FIN-WAIT-1
0 1 10.0.5.2:http 10.0.5.1:35973 timer:(persist,23sec,0) ino:0
sk:ffff880226756140 ---
skmem:(r0,rb374400,t0,tb46080,f4294966016,w1280,o0,bl0) cubic
mss:536 cwnd:10 retrans:0/1 rcv_space:29200
0 1 10.0.5.2:http 10.0.5.1:35320 timer:(persist,26sec,0) ino:0
sk:ffff88020b5cf180 ---
skmem:(r0,rb374400,t0,tb46080,f4294966016,w1280,o0,bl0) cubic
rto:2964 rtt:988/494 mss:536 cwnd:10 send 43.4Kbps rcv_space:29200
0 1 10.0.5.2:http 10.0.5.1:56784 timer:(persist,20sec,0) ino:0
sk:ffff88022543e800 ---
skmem:(r0,rb374400,t0,tb46080,f4294966016,w1280,o0,bl0) cubic
rto:2964 rtt:988/494 mss:536 cwnd:10 send 43.4Kbps rcv_space:29200
0 1 10.0.5.2:http 10.0.5.1:45866 timer:(persist,22sec,0) ino:0
sk:ffff88020b9d3140 ---
skmem:(r0,rb374400,t0,tb46080,f4294966016,w1280,o0,bl0) cubic
rto:2952 rtt:984/492 mss:536 cwnd:10 send 43.6Kbps rcv_space:29200
Thanks,
Andrey
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Andrey Dmitrov @ 2014-09-16 12:49 UTC (permalink / raw)
To: Yuchung Cheng, Hannes Frederic Sowa
Cc: netdev, Alexandra N. Kossovsky, Konstantin Ushakov
In-Reply-To: <CAK6E8=fQOA7Mav=a0NJxozAv-AHUV8vcsy+uMJVcH+6zcOE5=A@mail.gmail.com>
On 16/09/14 03:37, Yuchung Cheng wrote:
> I think the vulnerability comes from the peer/attacker actually
> responds to the probes to evade the orphan counts or memory checks in
> tcp_probe_timer(). This is a gray area of being legit but suspiciously
> mis-behaving?
> maybe have socket option TCP_USER_TIMEOUT for apps to cover conditions
> like these.
Yuchung,
I've tried to use socket option TCP_USER_TIMEOUT, but unfortunately it
does not help here. I think it is because all packets get their
acknowledges.
To everybody,
As I understand there is a sensitive difference in the connection
behavior when the zero window is advertised. In this case there is no
warranty that after socket closing the connection will be actually
closed in a finite time. And probably this cannot be regulated at the
moment. On the other hand if the zero window was not advertised, user
can be sure that the connection is closed in a finite time despite on
any peer actions. Moreover user can configure this time with the
corresponding timeouts. I.e. a user has a lot of options to configure
different timeouts, but in fact despite on his actions he has no
guarantee that the connection will be closed at all.
Thanks,
Andrey
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Eric Dumazet @ 2014-09-16 13:09 UTC (permalink / raw)
To: Andrey Dmitrov
Cc: Hannes Frederic Sowa, netdev, Alexandra N. Kossovsky,
Konstantin Ushakov
In-Reply-To: <54183150.5030400@oktetlabs.ru>
On Tue, 2014-09-16 at 16:47 +0400, Andrey Dmitrov wrote:
> On 16/09/14 03:15, Hannes Frederic Sowa wrote:
> > Also thanks for the report.
> >
> > Do you see any tcp window repair messages in dmesg? Can you send some
> > output of ss -oemit state FIN-WAIT-1 from the target host?
> Hannes,
> no, there aren't any messages in dmesg until net.ipv4.tcp_max_orphans is
> achieved.
Andrey, you should take a look at Labrea Tarpit,
http://www.sans.org/reading-room/whitepapers/casestudies/smart-ids-hybrid-labrea-tarpit-33254
What happens is the following :
A normal TCP session is established, traffic is sent from server to
client.
Client sends a zero window.
1) This can be normal, because application reading client queue no
longer can. (For example its a ssh session, and output to the terminal
is blocked by CTRL S). There are valid cases when you block this for
many hours.
2) This can be faked by malicious peer, willing to make server enter
this mode (inability to send more data, data stack in output queue, one
probe sent every RTO). This is a very well known way to let servers
consume a lot of kernel memory and eventually OOM.
Then server sends a probe every RTO, and client responds with a ACK with
win=0
TCP specs say : This can last forever, even if socket is eventually
closed by the server (because he gave up) and enters FIN_WAIT
Supposedly, if a server is about to give up, it might tell the TCP
stack : Oh, do not bother absolutely sending the remaining bytes you
have in output queue (I, the application, already waited for a very
reasonable time)
Normally SO_LINGER could be used, or TCP_USER_TIMEOUT. This requires a
system call before doing the close().
1) TCP_USER_TIMEOUT would be the fit for this, but its current
implementation do not take care of the probes sent, even in FIN_WAIT
state when in this zero window mode. A patch would be needed.
2) SO_LINGER, timeout=0 might work.
^ permalink raw reply
* Re: [PATCH 5/5] rhashtable: Per bucket locks & expansion/shrinking in work queue
From: Thomas Graf @ 2014-09-16 13:22 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, paulmck, john.r.fastabend, kaber, netdev, linux-kernel
In-Reply-To: <1410794580.7106.168.camel@edumazet-glaptop2.roam.corp.google.com>
On 09/15/14 at 08:23am, Eric Dumazet wrote:
> You need to roundup to next power of two.
Fixed, thanks!
^ permalink raw reply
* Re: Qdisc: Measuring Head-of-Line blocking with netperf-wrapper
From: Jesper Dangaard Brouer @ 2014-09-16 13:22 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, netdev@vger.kernel.org, Stephen Hemminger,
Tom Herbert, David Miller, Hannes Frederic Sowa, Daniel Borkmann,
Florian Westphal, Toke Høiland-Jørgensen, Dave Taht
In-Reply-To: <20140915184517.6c5474e5@redhat.com>
On Mon, 15 Sep 2014 18:45:17 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> I've constructed a "netperf-wrapper" test for measuring Head-of-Line
> blocking, called "tcp_upload_prio", that I hope you will approve of?
>
> https://github.com/tohojo/netperf-wrapper/commit/1e6b755e8051b6
>
> The basic idea is to have ping packets with TOS bit 0x10, which end-up
> in the high-prio band of pfifo_fast. While two TCP uploads utilize
> all the bandwidth.
>
> These high-prio ping packet should then demonstrate the Head-of-Line
> blocking occurring due to 1) packets in the HW TX ring buffer, or
> 2) in the qdisc layers requeue mechanism. Disgusting these two case
> might be a little difficult.
Let me demonstrate some the results with some graphs. I'm comparing
same kernel (net-next at c0d1379a) with different TSO, GSO and
disabled-TSO+GSO:
Test TYPES are:
- TSO == ethtool -K eth4 gro on gso on tso on
- GSO == ethtool -K eth4 gro on gso on tso off
- NoneXSO == ethtool -K eth4 gro off gso off tso off
A ping graph for with TSO enabled looks like:
http://people.netfilter.org/hawk/qdisc/measure01/tcp_upload_prio__ping--TSO_net_next.png
- It clearly shows that we can measure the difference between the
best-effort and high-priority ping packets.
Zooming in on high-prio ping only, and comparing TSO vs GSO:
http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO__ping_hiprio.png
http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO__ping_cdf.png
- It clearly shows that GSO have lower/better ping values that TSO,
e.g. smaller HoL blocking
When adding the NoneXSO to the high-prio compare:
http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO_vs_NoneXSO__ping_hiprio.png
http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO_vs_NoneXSO__ping_cdf.png
- Then it look a little strange, because the none-GSO/TSO setting looks
like it have larger Head-of-Line blocking delays. Something I was
not expecting.
Do notice that the NoneXSO case have a lower overall/average latency,
likely due to 1) TSO and GSO can put more "bytes" into the qdisc's 1000
packet limit, 2) NoneXSO have more difficulties exausting all
bandwidth, see graph:
http://people.netfilter.org/hawk/qdisc/measure01/tcp_upload_prio__totals--NoneXSO_net_next.png
vs a more stable TCP speeds with GSO:
http://people.netfilter.org/hawk/qdisc/measure01/tcp_upload_prio__totals--GSO_net_next.png
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 2/3] bridge: Add filtering support for default_pvid
From: Vlad Yasevich @ 2014-09-16 13:23 UTC (permalink / raw)
To: Toshiaki Makita, Toshiaki Makita, Vladislav Yasevich, netdev
Cc: shemminger, bridge
In-Reply-To: <54181A93.2070604@lab.ntt.co.jp>
On 09/16/2014 07:10 AM, Toshiaki Makita wrote:
> On 2014/09/16 0:09, Vlad Yasevich wrote:
>> On 09/14/2014 11:21 AM, Toshiaki Makita wrote:
>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>> Currently when vlan filtering is turned on on the bridge, the bridge
>>>> will drop all traffic untill the user configures the filter. This
>>>> isn't very nice for ports that don't care about vlans and just
>>>> want untagged traffic.
>>>>
>>>> A concept of a default_pvid was recently introduced. This patch
>>>> adds filtering support for default_pvid. Now, ports that don't
>>>> care about vlans and don't define there own filter will belong
>>>> to the VLAN of the default_pvid and continue to receive untagged
>>>> traffic.
>>>
>>> If user sets pvid, then vid 1 (default_pvid) will become non-pvid but
>>> still not be filtered, right?
>>
>> Right.
>>
>>> vlan_bitmap of default_pvid shouldn't be cleared on setting pvid?
>>
>> I can see arguments for both. Just because the user wishes to set a
>> different pvid may not always mean that vlan associated with default pvid
>> shouldn't be filtered. I think it's at user's discretion. I hesitate
>> to do too many things automatically.
>
> On second thought, I agree with you.
> It's reasonable that what default_pvid should do is only to set pvid on
> adding a bridge/port.
>
> My another concern is how we can disable default_pvid, since this
> feature is originally non-existent.
My knee-jerk reaction is to disable it with a value of 0, but I am trying
to think of a way to address Stephen's comment.
The other alternative might be to use any invalid vlan id to disable it.
-vlad
>
> Thanks,
> Toshiaki Makita
>
^ permalink raw reply
* Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge
From: Vlad Yasevich @ 2014-09-16 13:31 UTC (permalink / raw)
To: Toshiaki Makita, Toshiaki Makita, Vladislav Yasevich, netdev
Cc: shemminger, bridge
In-Reply-To: <54181EC1.2010608@lab.ntt.co.jp>
On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
> On 2014/09/16 0:19, Vlad Yasevich wrote:
>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>> If the user configures vlan devices on top of the bridge,
>>>> automatically set up filter entries for it as long as
>>>> bridge vlan protocol matches that of the vlan.
>>>> This allows the user to atomatically receive vlan traffic
>>>> for the vlans that are convifgured.
>>>
>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>> interfaces and filter settings.
>>> Can we automatically change filters when setting vlan_proto?
>>>
>>
>> I thought we already do that in br_vlan_set_proto()? Nothing
>> here introduces any new kinds of issue with that code.
>
> I'm referring to a case like this:
> 1. create br0.10 (802.1ad)
> 2. change br->vlan_proto into 88a8
>
> When creating br0.10 (1), br->vlan_proto is 8100 and different from
> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
> After changing br->vlan_proto (2), we might expect vlan 10 is not
> filtered on br0, but it will be filtered.
Ok, I see what you mean. This one is a bit tough. Our options are:
1) Return an error when configuring br0.10. This might break user-space. Not good.
2) Ignore protocol when crating the filter. This is not good either as the user
may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
3) Re-implement .1ad support per-vlan instead of per-bridge.
You see another other alternatives?
-vlad
>
> Thanks,
> Toshiaki Makita
>
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Or Gerlitz @ 2014-09-16 13:35 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx_+JxUn4zT+XN8DpQcCoz5Du+QtF1xzLno2m1yCwbr6ow@mail.gmail.com>
On Mon, Sep 15, 2014 at 10:15 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@google.com> wrote:
>>> - I really don't expect/want devices to have special support for any
>>> of this. Generic checksum offload mechanisms (NETIF_HW_CSUM
>>> and use of CHECKSUM_COMPLETE) should be sufficient. RSS and flow
>>> steering is provided by commonly implemented UDP hashing. GRO/GSO
>>> seem fairly comparable with LRO/TSO already.
>> Again, today NICs are advertizing checksum offloads capability in
>> enc_hw_features but aren't capable to compute (say) the TCP checksum
>> of the inner packet regardless of which actual tunneling is used (e.g VXLAN vs
>> GRE), a bit inconsistent?
> I doubt this is true of all NICs! For instance, a NIC that implements
> NETIF_F_HW_CSUM should have no problem computing an encapsulated
> checksums in just about any scenario.
The comment for NETIF_F_HW_CSUM says "Can checksum all the packets" --
so your interpretation is that NICs supporting that will always report
CHECKSUM_COMPLETE, OK. But there are bunch of 10/40Gbs NIC drivers
that don't report the HW_CSUM bit in neither of the ->features and
->hw_enc_features, the system should act in a manner that supports them.
> Both, checksum offload and TSO
> can be supported for arbitrary flavors of UDP encapsulation if NICs
> use protocol agnostic means as opposed to protocol specific means that
> require a lot of parsing the packets themselves. Look at the long
> standing comments in sk_buff about why protocol specific methods like
> CHECKSUM_UNNECESSARY and NETIF_F_IP_CSUM are bad ideas. With the
> emergence of encapsulation these are now *really* bad ideas!
So we go and throw away the HW?
Or.
^ permalink raw reply
* Re: [PATCH v3 2/3] net: Add Keystone NetCP ethernet driver
From: Sandeep Nair @ 2014-09-16 13:44 UTC (permalink / raw)
To: David Miller, santosh.shilimkar
Cc: netdev, linux-arm-kernel, linux-kernel, robh+dt, grant.likely,
devicetree, jhs
In-Reply-To: <20140915.123755.1868053059646672094.davem@davemloft.net>
On 9/15/2014 12:37 PM, David Miller wrote:
> From: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Date: Sat, 13 Sep 2014 16:07:18 -0400
>
>> + /* Find this module in the sub-tree for this device */
>> + devices = of_get_child_by_name(node, "netcp-devices");
>> + if (!devices) {
>> + dev_err(dev, "could not find netcp-devices node\n");
>> + return NETCP_MOD_PROBE_SKIPPED;
>> + }
>> +
>> + for_each_available_child_of_node(devices, child) {
>> + const char *name = netcp_node_name(child);
>> +
>> + if (!strcasecmp(module->name, name))
>> + break;
>> + }
>> +
>> + /* If module not used for this device, skip it */
>> + if (child == NULL) {
>> + dev_warn(dev, "module(%s) not used for device\n", module->name);
>> + return NETCP_MOD_PROBE_SKIPPED;
>> + }
>
> of_get_child_by_name() takes a reference to an OF node, you must release
> it in the error path.
>
Will fix this.
>> + inst_modpriv = devm_kzalloc(dev, sizeof(*inst_modpriv), GFP_KERNEL);
>> + if (!inst_modpriv) {
>> + dev_err(dev, "Failed to allocate instance for %s\n",
>> + module->name);
>> + return -ENOMEM;
>> + }
>
> Likewise, but here you have to release both "devices" and "child".
>
> You're going to have to fix this OF node refcount problem for this
> entire probe routine.
>
Will do.
Thanks for the review David!
Regards
Sandeep
^ permalink raw reply
* Re: Qdisc: Measuring Head-of-Line blocking with netperf-wrapper
From: Eric Dumazet @ 2014-09-16 13:59 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev@vger.kernel.org, Stephen Hemminger, Tom Herbert,
David Miller, Hannes Frederic Sowa, Daniel Borkmann,
Florian Westphal, Toke Høiland-Jørgensen, Dave Taht
In-Reply-To: <20140916152221.41811287@redhat.com>
On Tue, 2014-09-16 at 15:22 +0200, Jesper Dangaard Brouer wrote:
> Zooming in on high-prio ping only, and comparing TSO vs GSO:
> http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO__ping_hiprio.png
> http://people.netfilter.org/hawk/qdisc/measure01/compare_TSO_vs_GSO__ping_cdf.png
>
> - It clearly shows that GSO have lower/better ping values that TSO,
> e.g. smaller HoL blocking
If you use a single TX queue on the NIC (no prio aware), this makes no
sense....
GSO is exactly sending the same packet train on the wire, it only uses
more cpu on the host to segment packets. While doing the segmentation,
no packet can be sent to the NIC, so this should be _adding_ some
latencies, unless the TSO engine on your NIC is brain damaged.
The high prio ping packet cannot be inserted in the middle of a GSO
train.
ping is not very good to measure very small rtt actually.
With the TCP usec rtt work I did lately, you'll get more precise results
from a TCP_RR flow, as Tom and I explained.
Proof :
lpaa23:~# ping -n -c 10 10.246.7.152
PING 10.246.7.152 (10.246.7.152) 56(84) bytes of data.
64 bytes from 10.246.7.152: icmp_req=1 ttl=64 time=0.196 ms
64 bytes from 10.246.7.152: icmp_req=2 ttl=64 time=0.161 ms
64 bytes from 10.246.7.152: icmp_req=3 ttl=64 time=0.183 ms
64 bytes from 10.246.7.152: icmp_req=4 ttl=64 time=0.070 ms
64 bytes from 10.246.7.152: icmp_req=5 ttl=64 time=0.195 ms
64 bytes from 10.246.7.152: icmp_req=6 ttl=64 time=0.163 ms
64 bytes from 10.246.7.152: icmp_req=7 ttl=64 time=0.169 ms
64 bytes from 10.246.7.152: icmp_req=8 ttl=64 time=0.183 ms
64 bytes from 10.246.7.152: icmp_req=9 ttl=64 time=0.150 ms
64 bytes from 10.246.7.152: icmp_req=10 ttl=64 time=0.208 ms
--- 10.246.7.152 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 8999ms
rtt min/avg/max/mdev = 0.070/0.167/0.208/0.040 ms
While with TCP_RR, you'll get the ~20 usec rtt we really have on this
link :
netperf -H 10.246.7.152 -t TCP_RR -l 100 &
ss -temoi dst 10.246.7.152
...
ESTAB 0 1
10.246.7.151:59804
10.246.7.152:45623 timer:(on,201ms,0) ino:14821 sk:ffff881fcb48a740
<->
skmem:(r0,rb357120,t2304,tb46080,f1792,w2304,o0,bl0) ts sack cubic
wscale:6,6 rto:201 rtt:0.019/0.003 ato:40 mss:1448 cwnd:10 send
6096.8Mbps pacing_rate 11656.9Mbps unacked:1 rcv_rtt:572 rcv_space:29470
And if you take a look at tcpdump, you'll see that 20 usec is the
reality.
lpaa23:~# tcpdump -p -n -s 128 -i eth0 -c 10 host 10.246.7.152
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 128 bytes
06:53:59.278218 IP 10.246.7.152.43699 > 10.246.7.151.49454: P 1088080991:1088080992(1) ack 811259668 win 453 <nop,nop,timestamp 1151215 1152060>
06:53:59.278260 IP 10.246.7.151.49454 > 10.246.7.152.43699: P 1:2(1) ack 1 win 457 <nop,nop,timestamp 1152060 1151215>
06:53:59.278268 IP 10.246.7.152.43699 > 10.246.7.151.49454: P 1:2(1) ack 2 win 453 <nop,nop,timestamp 1151215 1152060>
06:53:59.278220 IP 10.246.7.151.49454 > 10.246.7.152.43699: P 2:3(1) ack 2 win 457 <nop,nop,timestamp 1152060 1151215>
06:53:59.278232 IP 10.246.7.152.43699 > 10.246.7.151.49454: P 2:3(1) ack 3 win 453 <nop,nop,timestamp 1151215 1152060>
06:53:59.278240 IP 10.246.7.151.49454 > 10.246.7.152.43699: P 3:4(1) ack 3 win 457 <nop,nop,timestamp 1152060 1151215>
06:53:59.278252 IP 10.246.7.152.43699 > 10.246.7.151.49454: P 3:4(1) ack 4 win 453 <nop,nop,timestamp 1151215 1152060>
06:53:59.278259 IP 10.246.7.151.49454 > 10.246.7.152.43699: P 4:5(1) ack 4 win 457 <nop,nop,timestamp 1152060 1151215>
06:53:59.278282 IP 10.246.7.152.43699 > 10.246.7.151.49454: P 4:5(1) ack 5 win 453 <nop,nop,timestamp 1151215 1152060>
06:53:59.278289 IP 10.246.7.151.49454 > 10.246.7.152.43699: P 5:6(1) ack 5 win 457 <nop,nop,timestamp 1152060 1151215>
ping is slower :
lpaa23:~# tcpdump -p -n -s 128 -i eth0 -c 10 host 10.246.7.152
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 128 bytes
06:57:29.666168 IP 10.246.7.151 > 10.246.7.152: ICMP echo request, id 11062, seq 4, length 64
06:57:29.666355 IP 10.246.7.152 > 10.246.7.151: ICMP echo reply, id 11062, seq 4, length 64
06:57:30.666220 IP 10.246.7.151 > 10.246.7.152: ICMP echo request, id 11062, seq 5, length 64
06:57:30.666408 IP 10.246.7.152 > 10.246.7.151: ICMP echo reply, id 11062, seq 5, length 64
06:57:31.666147 IP 10.246.7.151 > 10.246.7.152: ICMP echo request, id 11062, seq 6, length 64
06:57:31.666333 IP 10.246.7.152 > 10.246.7.151: ICMP echo reply, id 11062, seq 6, length 64
06:57:32.666164 IP 10.246.7.151 > 10.246.7.152: ICMP echo request, id 11062, seq 7, length 64
06:57:32.666359 IP 10.246.7.152 > 10.246.7.151: ICMP echo reply, id 11062, seq 7, length 64
Really, do not rely too much on ping.
If you do, we cant really trust your results.
^ permalink raw reply
* Re: [PATCH] bridge: Fix br_should_learn to check vlan_enabled
From: Toshiaki Makita @ 2014-09-16 14:02 UTC (permalink / raw)
To: Toshiaki Makita, David Miller, vyasevich; +Cc: netdev, vyasevic
In-Reply-To: <541813AB.2060301@lab.ntt.co.jp>
(14/09/16 (火) 19:40), Toshiaki Makita wrote:
> On 2014/09/16 6:38, David Miller wrote:
>> From: Vladislav Yasevich <vyasevich@gmail.com>
>> Date: Mon, 15 Sep 2014 15:24:26 -0400
>>
>>> As Toshiaki Makita pointed out, the BRIDGE_INPUT_SKB_CB will
>>> not be initialized in br_should_learn() as that function
>>> is called only from br_handle_local_finish(). That is
>>> an input handler for link-local ethernet traffic so it perfectly
>>> correct to check br->vlan_enabled here.
>>>
>>> Reported-by: Toshiaki Makita<toshiaki.makita1@gmail.com>
>>> Fixes: 20adfa1 bridge: Check if vlan filtering is enabled only once.
>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>>
>> Applied, thanks Vlad.
>
> Hi David,
>
> Could you queue this for -stable as well?
> Without this, FDB can be poisoned by disallowed ports.
> (the same problem as stated in e0d7968ab6c8 "bridge: Prevent insertion
> of FDB entry with disallowed vlan")
I'm sorry, I was confusued.
This doesn't cause that problem, because if vlan_filtered is 0, fdb is
always updated with vid 0. Such an entry is never used as long as
vlan_filtering is enabled.
Please ignore my previous mail.
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Andrey Dmitrov @ 2014-09-16 14:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, netdev, Alexandra N. Kossovsky,
Konstantin Ushakov
In-Reply-To: <1410872966.7106.187.camel@edumazet-glaptop2.roam.corp.google.com>
On 16/09/14 17:09, Eric Dumazet wrote:
> 1) TCP_USER_TIMEOUT would be the fit for this, but its current
> implementation do not take care of the probes sent, even in FIN_WAIT
> state when in this zero window mode. A patch would be needed.
>
> 2) SO_LINGER, timeout=0 might work.
I tried to set SO_LINGER with non-zero timeout before reporting the bug,
it did not help. But I've just tried again with the zero timeout
(l_linger=0) and it works, the connection has been interrupted
immediately after socket closing, RST packet has been sent. It seems
like a bug, SO_LINGER with non-zero timeout does not interrupt the
connection.
Thanks,
Andrey
^ permalink raw reply
* Re: [PATCH] net: can: usb: peak_usb: pcan_usb_core.c: Cleaning up missing null-terminate in conjunction with strncpy
From: Marc Kleine-Budde @ 2014-09-16 14:09 UTC (permalink / raw)
To: Rickard Strandqvist, Wolfgang Grandegger
Cc: Oliver Hartkopp, Stephane Grosjean, Alexey Khoroshilov,
Christopher R. Baker, linux-can, netdev, linux-kernel
In-Reply-To: <1410715898-15904-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On 09/14/2014 07:31 PM, Rickard Strandqvist wrote:
> Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
> drivers/net/can/usb/peak_usb/pcan_usb_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/usb/peak_usb/pcan_usb_core.c b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> index 644e6ab..d4fe8ac 100644
> --- a/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> +++ b/drivers/net/can/usb/peak_usb/pcan_usb_core.c
> @@ -830,7 +830,7 @@ static void peak_usb_disconnect(struct usb_interface *intf)
> char name[IFNAMSIZ];
>
> dev->state &= ~PCAN_USB_STATE_CONNECTED;
> - strncpy(name, netdev->name, IFNAMSIZ);
> + strlcpy(name, netdev->name, IFNAMSIZ);
>
> unregister_netdev(netdev);
> free_candev(netdev);
>
What about removing the dev_info(), the name array and the str?cpy()
completely?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] can: c_can_platform: Fix c_can_hw_raminit_ti() and add timeout
From: Marc Kleine-Budde @ 2014-09-16 14:13 UTC (permalink / raw)
To: Roger Quadros, wg
Cc: tony, tglx, mugunthanvnm, george.cherian, balbi, nsekhar, nm,
sergei.shtylyov, linux-omap, linux-can, netdev
In-Reply-To: <540F1138.3090502@ti.com>
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
On 09/09/2014 04:39 PM, Roger Quadros wrote:
> On 09/09/2014 05:34 PM, Marc Kleine-Budde wrote:
>> On 09/09/2014 04:31 PM, Roger Quadros wrote:
>>> Pass the correct 'mask' and 'value' bits to c_can_hw_raminit_wait_ti().
>>> They seem to have been swapped in the usage instances.
>>
>> Can you split this fix into a seperate patch, please.
>
> OK.
I've added this fix only to the can-tree.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: bisected regression: 3c59x corrupts packets in 3.17-rc5
From: Neil Horman @ 2014-09-16 14:31 UTC (permalink / raw)
To: Meelis Roos; +Cc: Steffen Klassert, netdev, Linux Kernel list
In-Reply-To: <alpine.LRH.2.11.1409161327110.24403@adalberg.ut.ee>
On Tue, Sep 16, 2014 at 01:32:31PM +0300, Meelis Roos wrote:
> [ Fixed Steffen Klasserts bouncing email address as per the bounce message ]
>
> > > Somewhere between 3.17.0-rc3 and 3.17.0-rc5 I started seeing dropped ssh
> > > connections to a couple of test servers with dual AthlonMP (32-bit) and
> > > 3C90x family of NICs (3Com Corporation 3c980-C 10/100baseTX NIC
> > > [Python-T] (rev 78) in one server and 3Com Corporation 3c905C-TX/TX-M
> > > [Tornado] (rev 78) in the other server). Bisect leads to the following
> > > commit:
> > >
> > > 98ea232cf63961fad734cc8c5e07e8915ec73073 is the first bad commit
> > > commit 98ea232cf63961fad734cc8c5e07e8915ec73073
> > > Author: Neil Horman <nhorman@tuxdriver.com>
> > > Date: Thu Sep 4 06:13:38 2014 -0400
> > >
> > > 3c59x: avoid panic in boomerang_start_xmit when finding page address:
> > > ...
> > >
> > I'm guessing the above change has uncovered another bug, mostly likely an
> > exhaustion of dma space on your system. Nothing in the transmit path there does
> > any error checking for successful dma mapping, which it really should. I'd be
> > willing to be that any dma mapping error leads to a leak in the mapping table.
> > Does your system have an iommu, or does it use swiotlb? If its the latter, can
> > you increase the swiotlb table space and see if that relieves the problem? In
> > the interim, I'll start adding some error checking to the transmit path.
>
> # CONFIG_IOMMU_SUPPORT is not set
>
> nothing matching iommu or iotlb in dmesg. I thought the system does not
> have any - K7 CPUs and AMD 760MP chipset with normal AGP gart.
>
> [ 3.763519] agpgart-amdk7 0000:00:00.0: AMD 760MP chipset
> [ 3.782995] agpgart-amdk7 0000:00:00.0: AGP aperture is 64M @ 0xf8000000
>
Then I think you are likely very lmiited in how much DMA memory you can map (may
be limited to ZONE_DMA), which is likely from where this problem is stemming.
Try adding swiotlb= setup to the kernel command line and play with the size to
see if you can avoid the problem. I also have a patch I'm sending you to test.
Neil
> --
> Meelis Roos (mroos@linux.ee)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [RFC PATCH] 3c59x: Add dma error checking and recovery
From: Neil Horman @ 2014-09-16 14:32 UTC (permalink / raw)
To: netdev; +Cc: Meelis Roos, linux-kernel, Neil Horman
In-Reply-To: <20140916101704.GA3792@hmsreliant.think-freely.org>
Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
ability to unmap fragments when a single map fails in the middle of a transmit.
This patch provides error checking to ensure that dma mappings work properly,
and unrolls an skb mapping if a fragmented skb transmission has a mapping
failure to prevent leaks.
Please test this patch out. It may fix the problem your experiencing, and, if
you enable dynamic debug in the driver, it will certainly confirm that is the
problem you are experiencing.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
---
drivers/net/ethernet/3com/3c59x.c | 50 ++++++++++++++++++++++++++++++++-------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/3com/3c59x.c b/drivers/net/ethernet/3com/3c59x.c
index 3fe45c7..5621dab 100644
--- a/drivers/net/ethernet/3com/3c59x.c
+++ b/drivers/net/ethernet/3com/3c59x.c
@@ -2129,6 +2129,7 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
int entry = vp->cur_tx % TX_RING_SIZE;
struct boom_tx_desc *prev_entry = &vp->tx_ring[(vp->cur_tx-1) % TX_RING_SIZE];
unsigned long flags;
+ dma_addr_t dma_addr;
if (vortex_debug > 6) {
pr_debug("boomerang_start_xmit()\n");
@@ -2163,24 +2164,48 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
vp->tx_ring[entry].status = cpu_to_le32(skb->len | TxIntrUploaded | AddTCPChksum | AddUDPChksum);
if (!skb_shinfo(skb)->nr_frags) {
- vp->tx_ring[entry].frag[0].addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data,
- skb->len, PCI_DMA_TODEVICE));
+ dma_addr = pci_map_single(VORTEX_PCI(vp), skb->data, skb->len,
+ PCI_DMA_TODEVICE);
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr))
+ goto out_dma_err;
+
+ vp->tx_ring[entry].frag[0].addr = cpu_to_le32(dma_addr);
vp->tx_ring[entry].frag[0].length = cpu_to_le32(skb->len | LAST_FRAG);
} else {
int i;
- vp->tx_ring[entry].frag[0].addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data,
- skb_headlen(skb), PCI_DMA_TODEVICE));
+ dma_addr = pci_map_single(VORTEX_PCI(vp), skb->data,
+ skb_headlen(skb), PCI_DMA_TODEVICE);
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr))
+ goto out_dma_err;
+
+ vp->tx_ring[entry].frag[0].addr = cpu_to_le32(dma_addr);
vp->tx_ring[entry].frag[0].length = cpu_to_le32(skb_headlen(skb));
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ dma_addr = skb_frag_dma_map(&VORTEX_PCI(vp)->dev, frag,
+ frag->page_offset,
+ frag->size,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr)) {
+ for(i = i-1; i >= 0; i--)
+ dma_unmap_page(&VORTEX_PCI(vp)->dev,
+ le32_to_cpu(vp->tx_ring[entry].frag[i+1].addr),
+ le32_to_cpu(vp->tx_ring[entry].frag[i+1].length),
+ DMA_TO_DEVICE);
+
+ pci_unmap_single(VORTEX_PCI(vp),
+ le32_to_cpu(vp->tx_ring[entry].frag[0].addr),
+ le32_to_cpu(vp->tx_ring[entry].frag[0].length),
+ PCI_DMA_TODEVICE);
+
+ goto out_dma_err;
+ }
+
vp->tx_ring[entry].frag[i+1].addr =
- cpu_to_le32(skb_frag_dma_map(
- &VORTEX_PCI(vp)->dev,
- frag,
- frag->page_offset, frag->size, DMA_TO_DEVICE));
+ cpu_to_le32(dma_addr);
if (i == skb_shinfo(skb)->nr_frags-1)
vp->tx_ring[entry].frag[i+1].length = cpu_to_le32(skb_frag_size(frag)|LAST_FRAG);
@@ -2189,7 +2214,10 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
}
#else
- vp->tx_ring[entry].addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data, skb->len, PCI_DMA_TODEVICE));
+ dma_addr = cpu_to_le32(pci_map_single(VORTEX_PCI(vp), skb->data, skb->len, PCI_DMA_TODEVICE));
+ if (dma_mapping_error(&VORTEX_PCI(vp)->dev, dma_addr))
+ goto out_dma_err;
+ vp->tx_ring[entry].addr = cpu_to_le32(dma_addr);
vp->tx_ring[entry].length = cpu_to_le32(skb->len | LAST_FRAG);
vp->tx_ring[entry].status = cpu_to_le32(skb->len | TxIntrUploaded);
#endif
@@ -2217,7 +2245,11 @@ boomerang_start_xmit(struct sk_buff *skb, struct net_device *dev)
skb_tx_timestamp(skb);
iowrite16(DownUnstall, ioaddr + EL3_CMD);
spin_unlock_irqrestore(&vp->lock, flags);
+out:
return NETDEV_TX_OK;
+out_dma_err:
+ dev_err(&VORTEX_PCI(vp)->dev, "Error mapping dma buffer\n");
+ goto out;
}
/* The interrupt handler does all of the Rx thread work and cleans up
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge
From: Toshiaki Makita @ 2014-09-16 14:39 UTC (permalink / raw)
To: vyasevic, Toshiaki Makita, Vladislav Yasevich, netdev; +Cc: shemminger, bridge
In-Reply-To: <54183BCF.8070506@redhat.com>
(14/09/16 (火) 22:31), Vlad Yasevich wrote:
> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>> If the user configures vlan devices on top of the bridge,
>>>>> automatically set up filter entries for it as long as
>>>>> bridge vlan protocol matches that of the vlan.
>>>>> This allows the user to atomatically receive vlan traffic
>>>>> for the vlans that are convifgured.
>>>>
>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>> interfaces and filter settings.
>>>> Can we automatically change filters when setting vlan_proto?
>>>>
>>>
>>> I thought we already do that in br_vlan_set_proto()? Nothing
>>> here introduces any new kinds of issue with that code.
>>
>> I'm referring to a case like this:
>> 1. create br0.10 (802.1ad)
>> 2. change br->vlan_proto into 88a8
>>
>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>> filtered on br0, but it will be filtered.
>
> Ok, I see what you mean. This one is a bit tough. Our options are:
> 1) Return an error when configuring br0.10. This might break user-space. Not good.
> 2) Ignore protocol when crating the filter. This is not good either as the user
> may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
> 3) Re-implement .1ad support per-vlan instead of per-bridge.
>
> You see another other alternatives?
We might be able to configure filterings on changing vlan_proto.
4) Memorize different protocol's filtering requests in
br_vlan_rx_add_vid() and use them when switching vlan_proto.
5) Scan vlan devices on bridge device when changing vlan_proto.
Thanks,
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH -net] scsi: fix users of SCSI_FC_ATTRS to depend on NET
From: Steffen Maier @ 2014-09-16 14:56 UTC (permalink / raw)
To: Randy Dunlap, netdev@vger.kernel.org, linux-scsi, James Bottomley,
David Miller
Cc: Fengguang Wu
In-Reply-To: <5417DA29.4060205@infradead.org>
On 09/16/2014 08:35 AM, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> There are other kconfig symbols which select SCSI_FC_ATTRS,
> so they also need to depend on NET to fix kconfig warnings and
> build errors:
>
> warning: (LIBFC && SCSI_IBMVFC && SCSI_QLA_FC && SCSI_LPFC && ZFCP && SCSI_BFA_FC && SCSI_CHELSIO_FCOE && FUSION_FC) selects SCSI_FC_ATTRS which has unmet direct dependencies (SCSI && NET)
> drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_event':
> drivers/scsi/scsi_transport_fc.c:543:7: error: 'scsi_nl_sock' undeclared (first use in this function)
> drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_vendor_event':
> drivers/scsi/scsi_transport_fc.c:611:7: error: 'scsi_nl_sock' undeclared (first use in this function)
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com> [0-day test robot]
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> drivers/message/fusion/Kconfig | 2 +-
> drivers/scsi/Kconfig | 9 +++++----
> drivers/scsi/csiostor/Kconfig | 2 +-
> drivers/scsi/qla2xxx/Kconfig | 2 +-
> 4 files changed, 8 insertions(+), 7 deletions(-)
> --- lnx-317-rc5.orig/drivers/scsi/Kconfig
> +++ lnx-317-rc5/drivers/scsi/Kconfig
> @@ -1675,7 +1676,7 @@ config SCSI_SUNESP
>
> config ZFCP
> tristate "FCP host bus adapter driver for IBM eServer zSeries"
> - depends on S390 && QDIO && SCSI
> + depends on S390 && QDIO && SCSI && NET
> select SCSI_FC_ATTRS
> help
> If you want to access SCSI devices attached to your IBM eServer
I think zfcp does not have any (direct) dependency on NET.
It looks like SCSI_FC_ATTRS selects SCSI_NETLINK (declaring
scsi_nl_sock) and only depends on SCSI but not on NET.
SCSI_NETLINK itself only selects NET but does not model its direct
depencency on NET?
Do I understand correctly, that the only solution is to make all
INdirect (transitive) dependencies explicit with the LLDDs instead of
making the direct exploiter SCSI_NETLINK(?) depend on NET?
--
Mit freundlichen Grüßen / Kind regards
Steffen Maier
Linux on System z Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)
From: Tom Herbert @ 2014-09-16 15:00 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CAJ3xEMjUKRCOodKs0XF_8xc0WY6=1UH=5STmeLS-a0=ofnSA9w@mail.gmail.com>
On Tue, Sep 16, 2014 at 6:35 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Mon, Sep 15, 2014 at 10:15 PM, Tom Herbert <therbert@google.com> wrote:
>> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@google.com> wrote:
>
>>>> - I really don't expect/want devices to have special support for any
>>>> of this. Generic checksum offload mechanisms (NETIF_HW_CSUM
>>>> and use of CHECKSUM_COMPLETE) should be sufficient. RSS and flow
>>>> steering is provided by commonly implemented UDP hashing. GRO/GSO
>>>> seem fairly comparable with LRO/TSO already.
>
>>> Again, today NICs are advertizing checksum offloads capability in
>>> enc_hw_features but aren't capable to compute (say) the TCP checksum
>>> of the inner packet regardless of which actual tunneling is used (e.g VXLAN vs
>>> GRE), a bit inconsistent?
>
>> I doubt this is true of all NICs! For instance, a NIC that implements
>> NETIF_F_HW_CSUM should have no problem computing an encapsulated
>> checksums in just about any scenario.
>
> The comment for NETIF_F_HW_CSUM says "Can checksum all the packets" --
> so your interpretation is that NICs supporting that will always report
> CHECKSUM_COMPLETE, OK. But there are bunch of 10/40Gbs NIC drivers
> that don't report the HW_CSUM bit in neither of the ->features and
> ->hw_enc_features, the system should act in a manner that supports them.
>
>> Both, checksum offload and TSO
>> can be supported for arbitrary flavors of UDP encapsulation if NICs
>> use protocol agnostic means as opposed to protocol specific means that
>> require a lot of parsing the packets themselves. Look at the long
>> standing comments in sk_buff about why protocol specific methods like
>> CHECKSUM_UNNECESSARY and NETIF_F_IP_CSUM are bad ideas. With the
>> emergence of encapsulation these are now *really* bad ideas!
>
> So we go and throw away the HW?
>
No, and this is exactly the point! I shouldn't have to throw away all
my deployed hardware to just to get support for the latest
encapsulation protocol du jour. Fortunately, we'll be able to code
around mosts of the limitations of deployed NICs that don't implement
generic mechanisms (with UDP RSS, checksum conversions, remote
checksum offload). But if you're contemplating a new NIC, *please*
consider implementing generic, protocol agnostic mechanisms.
> Or.
^ permalink raw reply
* Re: [PATCH 3/3] bridge; Automatically filter vlans configured on top of bridge
From: Vlad Yasevich @ 2014-09-16 15:00 UTC (permalink / raw)
To: Toshiaki Makita, Toshiaki Makita, Vladislav Yasevich, netdev
Cc: shemminger, bridge
In-Reply-To: <54184BB9.8010802@gmail.com>
On 09/16/2014 10:39 AM, Toshiaki Makita wrote:
> (14/09/16 (火) 22:31), Vlad Yasevich wrote:
>> On 09/16/2014 07:28 AM, Toshiaki Makita wrote:
>>> On 2014/09/16 0:19, Vlad Yasevich wrote:
>>>> On 09/14/2014 11:39 AM, Toshiaki Makita wrote:
>>>>> (14/09/13 (土) 5:44), Vladislav Yasevich wrote:
>>>>>> If the user configures vlan devices on top of the bridge,
>>>>>> automatically set up filter entries for it as long as
>>>>>> bridge vlan protocol matches that of the vlan.
>>>>>> This allows the user to atomatically receive vlan traffic
>>>>>> for the vlans that are convifgured.
>>>>>
>>>>> Changing br->vlan_proto seems to cause inconsistency between vlan
>>>>> interfaces and filter settings.
>>>>> Can we automatically change filters when setting vlan_proto?
>>>>>
>>>>
>>>> I thought we already do that in br_vlan_set_proto()? Nothing
>>>> here introduces any new kinds of issue with that code.
>>>
>>> I'm referring to a case like this:
>>> 1. create br0.10 (802.1ad)
>>> 2. change br->vlan_proto into 88a8
>>>
>>> When creating br0.10 (1), br->vlan_proto is 8100 and different from
>>> protocol of br0.10, so it is ignored by br_vlan_rx_add_vid().
>>> After changing br->vlan_proto (2), we might expect vlan 10 is not
>>> filtered on br0, but it will be filtered.
>>
>> Ok, I see what you mean. This one is a bit tough. Our options are:
>> 1) Return an error when configuring br0.10. This might break user-space. Not good.
>> 2) Ignore protocol when crating the filter. This is not good either as the user
>> may not switch the bridge vlan_proto value and we'd end up with a wrong filter.
>> 3) Re-implement .1ad support per-vlan instead of per-bridge.
>>
>> You see another other alternatives?
>
> We might be able to configure filterings on changing vlan_proto.
> 4) Memorize different protocol's filtering requests in
> br_vlan_rx_add_vid() and use them when switching vlan_proto.
If we do this, we might as well take it one small step further and make per-vlan protocol
support.
> 5) Scan vlan devices on bridge device when changing vlan_proto.
>
The scan could work... walk the upper devices looking for vlans and add/delete filters
based on the protocol of the vlan devices.
Seems kind of hacky, but let me give this one a try...
-vlad
> Thanks,
> Toshiaki Makita
>
^ permalink raw reply
* Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised
From: Yuchung Cheng @ 2014-09-16 15:11 UTC (permalink / raw)
To: Eric Dumazet
Cc: Andrey Dmitrov, Hannes Frederic Sowa, netdev,
Alexandra N. Kossovsky, Konstantin Ushakov
In-Reply-To: <1410872966.7106.187.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 16, 2014 at 6:09 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-09-16 at 16:47 +0400, Andrey Dmitrov wrote:
>> On 16/09/14 03:15, Hannes Frederic Sowa wrote:
>> > Also thanks for the report.
>> >
>> > Do you see any tcp window repair messages in dmesg? Can you send some
>> > output of ss -oemit state FIN-WAIT-1 from the target host?
>> Hannes,
>> no, there aren't any messages in dmesg until net.ipv4.tcp_max_orphans is
>> achieved.
>
>
> Andrey, you should take a look at Labrea Tarpit,
>
> http://www.sans.org/reading-room/whitepapers/casestudies/smart-ids-hybrid-labrea-tarpit-33254
>
> What happens is the following :
>
> A normal TCP session is established, traffic is sent from server to
> client.
>
> Client sends a zero window.
>
> 1) This can be normal, because application reading client queue no
> longer can. (For example its a ssh session, and output to the terminal
> is blocked by CTRL S). There are valid cases when you block this for
> many hours.
>
> 2) This can be faked by malicious peer, willing to make server enter
> this mode (inability to send more data, data stack in output queue, one
> probe sent every RTO). This is a very well known way to let servers
> consume a lot of kernel memory and eventually OOM.
>
>
> Then server sends a probe every RTO, and client responds with a ACK with
> win=0
>
> TCP specs say : This can last forever, even if socket is eventually
> closed by the server (because he gave up) and enters FIN_WAIT
>
> Supposedly, if a server is about to give up, it might tell the TCP
> stack : Oh, do not bother absolutely sending the remaining bytes you
> have in output queue (I, the application, already waited for a very
> reasonable time)
>
> Normally SO_LINGER could be used, or TCP_USER_TIMEOUT. This requires a
> system call before doing the close().
>
> 1) TCP_USER_TIMEOUT would be the fit for this, but its current
> implementation do not take care of the probes sent, even in FIN_WAIT
> state when in this zero window mode. A patch would be needed.
Yes that's what I meant. I am proposing we should patch
TCP_USER_TIMEOUT to do this.
>
> 2) SO_LINGER, timeout=0 might work.
>
>
>
> --
> 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
* Re: [PATCH net] sfc: fix addr_list_lock spinlock use before init
From: Edward Cree @ 2014-09-16 15:05 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev, davem, Ben Hutchings, Shradha Shah,
Solarflare linux maintainers
In-Reply-To: <1410785727-659-1-git-send-email-nikolay@redhat.com>
On Mon, 15 Sep 2014, Nikolay Aleksandrov wrote:
> When the module is initializing the ports it may call a function that
> uses addr_list_lock before register_netdevice() has been called for that
> port i.e. addr_list_lock is still uninitialized. The function in
> question is efx_farch_filter_sync_rx_mode(), now it looks pointless to call
> it before the port has been registered so alter the reconfigure_mac
> callbacks to check if the port has been registered using the existing
> efx_dev_registered() macro.
Weak NAK as this should really be done in efx_farch_filter_sync_rx_mode()
rather than its callers. In fact it seems our out-of-tree driver has done
this for a while but we forgot to upstream it, though curiously we did
upstream the corresponding fix for EF10.
Will follow up with a patch after sanity testing it.
--
-Edward Cree
^ permalink raw reply
* Re: [PATCH net] sfc: fix addr_list_lock spinlock use before init
From: Nikolay Aleksandrov @ 2014-09-16 15:20 UTC (permalink / raw)
To: Edward Cree
Cc: netdev, davem, Ben Hutchings, Shradha Shah,
Solarflare linux maintainers
In-Reply-To: <alpine.LFD.2.03.1409161540490.25290@solarflare.com>
On 16/09/14 17:05, Edward Cree wrote:
> On Mon, 15 Sep 2014, Nikolay Aleksandrov wrote:
>> When the module is initializing the ports it may call a function that
>> uses addr_list_lock before register_netdevice() has been called for that
>> port i.e. addr_list_lock is still uninitialized. The function in
>> question is efx_farch_filter_sync_rx_mode(), now it looks pointless to call
>> it before the port has been registered so alter the reconfigure_mac
>> callbacks to check if the port has been registered using the existing
>> efx_dev_registered() macro.
>
> Weak NAK as this should really be done in efx_farch_filter_sync_rx_mode()
Indeed, seems like the best place.
> rather than its callers. In fact it seems our out-of-tree driver has done
> this for a while but we forgot to upstream it, though curiously we did
> upstream the corresponding fix for EF10.
Ah yes, I saw it in the ef10 code. I should've checked with the out-of-tree
driver first, will note for future submissions :-)
> Will follow up with a patch after sanity testing it.
>
> --
> -Edward Cree
Okay, fair enough.
Thanks,
Nik
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox