* Re: Disable tcp MSS option in three way handshake?
From: Vincent Li @ 2012-10-26 22:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1351204948.6537.263.camel@edumazet-glaptop>
On Thu, Oct 25, 2012 at 3:42 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2012-10-25 at 15:27 -0700, Vincent Li wrote:
>> Hi,
>>
>> this sounds crazy, we have a weird situation that an unknown tcp
>> implementation not putting tcp MSS option in the SYN/ACK which caused
>> us some issue. I am tasked to mimic the unknown tcp immplementation on
>> not sending MSS in tcp SYN/ACK, I am wondering if I can achieve that
>> by modifying linux kernel tcp code, there is socket option
>> TCP_MAXSEG, but that seems only affecting the size of MSS, not
>> removing the MSS option. do you have any pointer on how to do that in
>> kernel tcp code?
>
> You'll have to patch the code.
>
> Or else, you could add a new feature to net/netfilter/xt_TCPMSS.c
>
> (We already have
>
> #define XT_TCPMSS_CLAMP_PMTU 0xffff
>
> You could add
>
> #define XT_TCPMSS_REMOVE 0xfffe
>
> and replace MSS option by NOP
>
>
>
for the sake of complete information, net/netfilter/xt_TCPOPTSTRIP.c
already have this feature to strip tcp option
Vincent
^ permalink raw reply
* Re: [PATCH net-next V2 1/1] tcp: Prevent needless syn-ack rexmt during TWHS
From: Julian Anastasov @ 2012-10-26 22:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Vijay Subramanian, netdev, davem, edumazet, ncardwell,
Venkat Venkatsubra, Elliott Hughes
In-Reply-To: <1351287724.30380.35.camel@edumazet-glaptop>
Hello,
On Fri, 26 Oct 2012, Eric Dumazet wrote:
> On Sat, 2012-10-27 at 00:30 +0300, Julian Anastasov wrote:
> >
> > Wait a minute, this can cause problem at least
> > for the TCP_DEFER_ACCEPT mode. It is supposed to timeout
> > in SYN_RECV state if after silence period (no retransmissions)
> > and some final retransmissions (until max_retries) client
> > still does not send data - the request should be expired
> > without notifying the listener.
> >
> > So, the logic in syn_ack_recalc() was tuned to resend
> > after the TCP_DEFER_ACCEPT period. This patch stops such
> > resends after TCP_DEFER_ACCEPT period. May be the change
> > should be in syn_ack_recalc() without hurting TCP_DEFER_ACCEPT?
> >
> > Lets analyze the default case without TCP_DEFER_ACCEPT.
> >
> > Think for protocols like SMTP where server sends
> > welcome message. This patch stops SYN-ACK resends, client
> > sends one ACK (which server drops) and enters EST state.
> > Client is waiting for welcome message in EST state while
> > server is waiting silently for ACK message to create child
> > socket. No progress, may but timeout error in client.
> >
> > Is the patch safe for such case? Is there a logic
> > that creates child socket from request if the dropped ACK
> > was the last message from client? It must not do it for
> > TCP_DEFER_ACCEPT.
>
>
> I see no impact with TCP_DEFER_ACCEPT handling.
>
> TCP_DEFER_ACCEPT is quite different from this stuff
>
> The 3WHS is completed, and the socket is ready.
>
> But its not delivered to the accept() (listener) until we receive a DATA
> frame (or defer timeout elapsed)
>
> We dont resend SYNACK messages for them. We just wait the 4th packet.
We have 3 general cases:
1. HTTP-kind of protocol: client sends first, server without
TCP_DEFER_ACCEPT
Server should retransmit but anyways client will
send packet (ACK) that will move request_sock into child socket.
2. HTTP-kind of protocol: client sends first, server with
TCP_DEFER_ACCEPT
Server retransmits before 3WHS to get ACK from
client. After ACK we keep request_sock because we do not
want to wakeup listener without data. During TCP_DEFER_ACCEPT
period nothing is retransmitted because we have ACK from
client. After TCP_DEFER_ACCEPT period we start retransmissions
because the server needs such request_socks to become
child sockets after the TCP_DEFER_ACCEPT period and because
received ACK is the only way to create child socket.
Server wants to accept() them. If TCP_DEFER_ACCEPT is
above sysctl_tcp_synack_retries there are no such
retransmissions because server does not want to accept()
such request_socks without data. So, servers decide
what they want with the TCP_DEFER_ACCEPT period value.
3. SMTP-kind of protocol: server sends first,
TCP_DEFER_ACCEPT must not be used by server.
3WHS is completed, there is no 4th packet from
client. It is the server side that needs to move request_sock
to child socket, to accept the connection and to send
welcome message. AFAIK, child socket is created only on
ACK. Or I'm missing something? Now the question is:
how request_sock is moved into child socket if ACK is
dropped on syn_recv_sock failure and we do not send SYN-ACK
retransmissions to trigger ACK from client? Client does not
plan to send new packet in short time.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH net-next] net: compute skb->rxhash if nic hash may be 3-tuple
From: Willem de Bruijn @ 2012-10-26 21:52 UTC (permalink / raw)
To: davem; +Cc: edumazet, netdev, Willem de Bruijn
Network device drivers can communicate a Toeplitz hash in skb->rxhash,
but devices differ in their hashing capabilities. All compute a 5-tuple
hash for TCP over IPv4, but for other connection-oriented protocols,
they may compute only a 3-tuple. This breaks RPS load balancing, e.g.,
for TCP over IPv6 flows. Additionally, for GRE and other tunnels,
the kernel computes a 5-tuple hash over the inner packet if possible,
but devices do not.
This patch recomputes the rxhash in software in all cases where it
cannot be certain that a 5-tuple was computed. Device drivers can avoid
recomputation by setting the skb->l4_rxhash flag.
Recomputing adds cycles to each packet when RPS is enabled or the
packet arrives over a tunnel. A comparison of 200x TCP_STREAM between
two servers running unmodified netnext with rxhash computation
in hardware vs software (using ethtool -K eth0 rxhash [on|off]) shows
how much time is spent in __skb_get_rxhash in this worst case:
0.03% swapper [kernel.kallsyms] [k] __skb_get_rxhash
0.03% swapper [kernel.kallsyms] [k] __skb_get_rxhash
0.05% swapper [kernel.kallsyms] [k] __skb_get_rxhash
With 200x TCP_RR it increases to
0.10% netperf [kernel.kallsyms] [k] __skb_get_rxhash
0.10% netperf [kernel.kallsyms] [k] __skb_get_rxhash
0.10% netperf [kernel.kallsyms] [k] __skb_get_rxhash
I considered having the patch explicitly skips recomputation when it knows
that it will not improve the hash (TCP over IPv4), but that conditional
complicates code without saving many cycles in practice, because it has
to take place after flow dissector.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
include/linux/skbuff.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6a2c34e..a2a0bdb 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -643,7 +643,7 @@ extern unsigned int skb_find_text(struct sk_buff *skb, unsigned int from,
extern void __skb_get_rxhash(struct sk_buff *skb);
static inline __u32 skb_get_rxhash(struct sk_buff *skb)
{
- if (!skb->rxhash)
+ if (!skb->l4_rxhash)
__skb_get_rxhash(skb);
return skb->rxhash;
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH net-next V2 1/1] tcp: Prevent needless syn-ack rexmt during TWHS
From: Eric Dumazet @ 2012-10-26 21:42 UTC (permalink / raw)
To: Julian Anastasov
Cc: Vijay Subramanian, netdev, davem, edumazet, ncardwell,
Venkat Venkatsubra, Elliott Hughes
In-Reply-To: <alpine.LFD.2.00.1210262325480.2880@ja.ssi.bg>
On Sat, 2012-10-27 at 00:30 +0300, Julian Anastasov wrote:
> Hello,
>
> On Fri, 26 Oct 2012, Vijay Subramanian wrote:
>
> > Elliott Hughes <enh@google.com> saw strange behavior when server socket was not
> > calling accept(). Client was receiving SYN-ACK back even when socket on server
> > side was not yet available. Eric noted server sockets kept resending SYN_ACKS
> > and further investigation revealed the following problem.
> >
> > If server socket is slow to accept() connections, request_socks can represent
> > connections for which the three-way handshake is already done. From client's
> > point of view, the connection is in ESTABLISHED state but on server side, socket
> > is not in accept_queue or ESTABLISHED state. When the syn-ack timer expires,
> > because of the order in which tests are performed, server can retransmit the
> > synack repeatedly. Following patch prevents the server from retransmitting the
> > synack needlessly (and prevents client from replying with ack). This reduces
> > traffic when server is slow to accept() connections.
> >
> > If the server socket has received the third ack during connection establishment,
> > this is remembered in inet_rsk(req)->acked. The request_sock will expire in
> > around 30 seconds and will be dropped if it does not move into accept_queue.
> >
> > With help from Eric Dumazet.
> >
> > Reported-by: Eric Dumazet <edumazet@google.com>
> > Acked-by: Neal Cardwell <ncardwell@google.com>
> > Tested-by: Neal Cardwell <ncardwell@google.com>
> > Acked-by: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> > ---
> > Changes from V1: Changed Reported-by tag and commit message. Added Acked-by and
> > Tested-by tags.
> >
> > Ignoring "WARNING: line over 80 characters" in the interest of readability.
> >
> > net/ipv4/inet_connection_sock.c | 5 ++---
> > 1 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> > index d34ce29..4e8e52e 100644
> > --- a/net/ipv4/inet_connection_sock.c
> > +++ b/net/ipv4/inet_connection_sock.c
> > @@ -598,9 +598,8 @@ void inet_csk_reqsk_queue_prune(struct sock *parent,
> > &expire, &resend);
> > req->rsk_ops->syn_ack_timeout(parent, req);
> > if (!expire &&
> > - (!resend ||
> > - !req->rsk_ops->rtx_syn_ack(parent, req, NULL) ||
> > - inet_rsk(req)->acked)) {
> > + (!resend || inet_rsk(req)->acked ||
>
> Wait a minute, this can cause problem at least
> for the TCP_DEFER_ACCEPT mode. It is supposed to timeout
> in SYN_RECV state if after silence period (no retransmissions)
> and some final retransmissions (until max_retries) client
> still does not send data - the request should be expired
> without notifying the listener.
>
> So, the logic in syn_ack_recalc() was tuned to resend
> after the TCP_DEFER_ACCEPT period. This patch stops such
> resends after TCP_DEFER_ACCEPT period. May be the change
> should be in syn_ack_recalc() without hurting TCP_DEFER_ACCEPT?
>
> Lets analyze the default case without TCP_DEFER_ACCEPT.
>
> Think for protocols like SMTP where server sends
> welcome message. This patch stops SYN-ACK resends, client
> sends one ACK (which server drops) and enters EST state.
> Client is waiting for welcome message in EST state while
> server is waiting silently for ACK message to create child
> socket. No progress, may but timeout error in client.
>
> Is the patch safe for such case? Is there a logic
> that creates child socket from request if the dropped ACK
> was the last message from client? It must not do it for
> TCP_DEFER_ACCEPT.
I see no impact with TCP_DEFER_ACCEPT handling.
TCP_DEFER_ACCEPT is quite different from this stuff
The 3WHS is completed, and the socket is ready.
But its not delivered to the accept() (listener) until we receive a DATA
frame (or defer timeout elapsed)
We dont resend SYNACK messages for them. We just wait the 4th packet.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-10-26 21:38 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
This is what we usually expect at this stage of the game, lots of
little things, mostly in drivers. With the occaisional "oops didn't
mean to do that" kind of regressions in the core code.
1) Uninitialized data in __ip_vs_get_timeouts(), from Arnd Bergmann
2) Reject invalid ACK sequences in Fast Open sockets, from Jerry Chu.
3) Lost error code on return from _rtl_usb_receive(), from Christian
Lamparter.
4) Fix reset resume on USB rt2x00, from Stanislaw Gruszka.
5) Release resources on error in pch_gbe driver, from Veaceslav Falico.
6) Default hop limit not set correctly in ip6_template_metrics[], fix
from Li RongQing.
7) Gianfar PTP code requests wrong kind of resource during probe,
fix from Wei Yang.
8) Fix VHOST net driver on big-endian, from Michael S. Tsirkin.
9) Mallenox driver bug fixes from Jack Morgenstein, Or Gerlitz,
Moni Shoua, Dotan Barak, and Uri Habusha.
10) usbnet leaks memory on TX path, fix from Hemant Kumar.
11) Use socket state test, rather than presence of FIN bit packet,
to determine FIONREAD/SIOCINQ value. Fix from Eric Dumazet.
12) Fix cxgb4 build failure, from Vipul Pandya.
13) Provide a SYN_DATA_ACKED state to complement SYN_FASTOPEN in socket
info dumps. From Yuchung Cheng.
14) Fix leak of security path in kfree_skb_partial(). Fix from
Eric Dumazet.
15) Handle RX FIFO overflows more resiliently in pch_gbe driver, from
Veaceslav Falico.
16) Fix MAINTAINERS file pattern for networking drivers, from Jean
Delvare.
17) Add iPhone5 IDs to IPHETH driver, from Jay Purohit.
18) VLAN device type change restriction is too strict, and should not
trigger for the automatically generated vlan0 device. Fix from
Jiri Pirko.
19) Make PMTU/redirect flushing work properly again in ipv4, from Steffen
Klassert.
20) Fix memory corruptions by using kfree_rcu() in netlink_release().
From Eric Dumazet.
21) More qmi_wwan device IDs, from Bjørn Mork.
22) Fix unintentional change of SNAT/DNAT hooks in generic NAT
infrastructure, from Elison Niven.
23) Fix 3.6.x regression in xt_TEE netfilter module, from Eric Dumazet.
Please pull, thanks a lot!
The following changes since commit 43c422eda99b894f18d1cca17bcd2401efaf7bd0:
apparmor: fix apparmor OOPS in audit_log_untrustedstring+0x1c/0x40 (2012-10-17 16:29:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 330ee00412bbaefa7d0597a1bed7804e818ba91c:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2012-10-26 10:32:13 -0400)
----------------------------------------------------------------
Arnd Bergmann (1):
ipvs: initialize returned data in do_ip_vs_get_ctl
Bing Zhao (2):
mwifiex: return -EBUSY if specific scan request cannot be honored
mwifiex: clean up scan state on error
Bjørn Mork (1):
net: qmi_wwan: adding more ZTE devices
Chris Metcalf (1):
tilegx: fix some issues in the SW TSO support
Christian Lamparter (1):
rtlwifi: pass rx setup error code to caller
Dan Carpenter (1):
brcmfmac: fix end of loop check (signedness bug)
Dan Williams (1):
qmi_wwan/cdc_ether: move Novatel 551 and E362 to qmi_wwan
David S. Miller (4):
Merge branch 'master' of git://1984.lsi.us.es/nf
Merge tag 'batman-adv-fix-for-davem' of git://git.open-mesh.org/linux-merge
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
Merge branch 'fixes-for-3.7' of git://gitorious.org/linux-can/linux-can
Dotan Barak (1):
net/mlx4_core: Unmap UAR also in the case of error flow
Elison Niven (1):
netfilter: xt_nat: fix incorrect hooks for SNAT and DNAT targets
Eric Dumazet (4):
netfilter: xt_TEE: don't use destination address found in header
netlink: use kfree_rcu() in netlink_release()
tcp: fix FIONREAD/SIOCINQ
net: fix secpath kmemleak
Felix Fietkau (2):
mac80211: use ieee80211_free_txskb in a few more places
Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"
Franky Lin (2):
brcmfmac: use control channel in roamed status reporting
brcmfmac: set dongle mode accordingly when interface up
Hante Meuleman (1):
brcmfmac: handle all exceptions as an error.
Hemant Kumar (1):
net: usb: Fix memory leak on Tx data path
Jack Morgenstein (1):
net/mlx4_en: Fix double-release-range in tx-rings
Jay Purohit (1):
usb/ipheth: Add iPhone 5 support
Jean Delvare (1):
MAINTAINERS: NETWORKING DRIVERS matches too much
Jerry Chu (1):
tcp: Reject invalid ack_seq to Fast Open sockets
Jiri Pirko (1):
vlan: allow to change type when no vlan device is hooked on netdev
Joe Jin (1):
qla3xxx: Ensure request/response queue addr writes to the registers
Johan Hedberg (1):
Bluetooth: SMP: Fix setting unknown auth_req bits
Johannes Berg (3):
Merge remote-tracking branch 'wireless/master' into mac80211
iwlwifi: fix 6000 series channel switch command
mac80211: connect with HT20 if HT40 is not permitted
John W. Linville (4):
Merge branch 'master' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Jouni Malinen (1):
mac80211: Fix FC masking in BIP AAD generation
Larry Finger (1):
b43: Fix oops on unload when firmware not found
Li RongQing (1):
ipv6: Set default hoplimit as zero.
Linus Lüssing (2):
batman-adv: Fix broadcast packet CRC calculation
batman-adv: Fix potential broadcast BLA-duplicate-check race condition
Matus Ujhelyi (1):
phy: add AT803x driver
Michael S. Tsirkin (1):
vhost: fix mergeable bufs on BE hosts
Mohammed Shafi Shajakhan (1):
ath9k_htc: Add PID/VID for a Ubiquiti WiFiStation
Moni Shoua (1):
net/mlx4_en: Don't use vlan tag value as an indication for vlan presence
Pablo Neira Ayuso (2):
netfilter: xt_CT: fix timeout setting with IPv6
Merge branch 'master' of git://git.kernel.org/.../davem/net
Peter Korsgaard (1):
NET_VENDOR_TI: make available for am33xx as well
Piotr Haber (1):
bcma: fix unregistration of cores
Stanislav Yakovlev (1):
net/wireless: ipw2200: Fix panic occurring in ipw_handle_promiscuous_tx()
Stanislaw Gruszka (3):
cfg80211/mac80211: avoid state mishmash on deauth
mac80211: check if key has TKIP type before updating IV
rt2x00: usb: fix reset resume
Steffen Klassert (1):
ipv4: Fix flushing of cached routing informations
Stephane Grosjean (1):
can: sja1000: fix/add miniPCIe/cPCI PC/104Plus PCI/104e PEAK-System boards
Tilman Schmidt (1):
bas_gigaset: fix pre_reset handling
Veaceslav Falico (4):
pch_gbe: create functions for MAC_RX {en,dis}able
pch_gbe: don't re-set RX_FIFO_ERR flag in napi_poll
pch_gbe: don't reset MAC_RX on FIFO overflow
pch_gbe: fix error handling in pch_gbe_up()
Vipul Pandya (1):
cxgb4: Remove unnecessary #ifdef condition
Wei Yang (1):
gianfar_ptp: use iomem, not ioports resource tree in probe
Wolfgang Grandegger (1):
can: flexcan: disable bus error interrupts for the i.MX6q
Yuanhan Liu (1):
brcmfmac: fix potential NULL dereference
Yuchung Cheng (1):
tcp: add SYN/data info to TCP_INFO
MAINTAINERS | 8 ++-
drivers/bcma/main.c | 5 +-
drivers/isdn/gigaset/bas-gigaset.c | 19 +++++--
drivers/net/can/flexcan.c | 19 +++++--
drivers/net/can/sja1000/peak_pci.c | 13 ++++-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 19 +++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 29 ++--------
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 3 ++
drivers/net/ethernet/freescale/gianfar_ptp.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_tx.c | 3 +-
drivers/net/ethernet/mellanox/mlx4/eq.c | 18 +++++--
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 116 +++++++++++++---------------------------
drivers/net/ethernet/qlogic/qla3xxx.c | 9 +++-
drivers/net/ethernet/ti/Kconfig | 2 +-
drivers/net/ethernet/tile/tilegx.c | 35 ++++++------
drivers/net/phy/Kconfig | 5 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/at803x.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/usb/cdc_ether.c | 41 ++++++++------
drivers/net/usb/ipheth.c | 5 ++
drivers/net/usb/qmi_wwan.c | 55 +++++++++++++++++++
drivers/net/usb/usbnet.c | 3 ++
drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 164 ++++++++++++++++++++++++++++----------------------------
drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
drivers/net/wireless/b43/main.c | 4 ++
drivers/net/wireless/brcm80211/brcmfmac/usb.c | 2 +-
drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 70 +++++++++---------------
drivers/net/wireless/ipw2x00/ipw2200.c | 2 +-
drivers/net/wireless/iwlwifi/dvm/devices.c | 39 ++++++++------
drivers/net/wireless/mwifiex/cfg80211.c | 7 ++-
drivers/net/wireless/mwifiex/scan.c | 13 ++---
drivers/net/wireless/rt2x00/rt2500usb.c | 1 +
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
drivers/net/wireless/rt2x00/rt73usb.c | 1 +
drivers/net/wireless/rtlwifi/usb.c | 2 +-
drivers/vhost/net.c | 3 +-
include/linux/tcp.h | 3 +-
include/net/cfg80211.h | 1 +
include/uapi/linux/tcp.h | 1 +
net/8021q/vlan.c | 4 +-
net/batman-adv/bridge_loop_avoidance.c | 27 ++++++----
net/batman-adv/routing.c | 8 ++-
net/batman-adv/types.h | 2 +
net/bluetooth/smp.c | 6 ++-
net/core/skbuff.c | 6 ++-
net/ipv4/route.c | 9 ++--
net/ipv4/tcp.c | 10 ++--
net/ipv4/tcp_input.c | 13 ++++-
net/ipv4/tcp_ipv4.c | 1 +
net/ipv4/tcp_minisocks.c | 1 +
net/ipv4/tcp_timer.c | 4 +-
net/ipv6/route.c | 4 +-
net/mac80211/iface.c | 2 +-
net/mac80211/mlme.c | 35 +++++++-----
net/mac80211/sta_info.c | 4 +-
net/mac80211/util.c | 4 +-
net/mac80211/wpa.c | 14 +++--
net/netfilter/ipvs/ip_vs_ctl.c | 3 +-
net/netfilter/xt_CT.c | 10 ++--
net/netfilter/xt_TEE.c | 1 +
net/netfilter/xt_nat.c | 8 +--
net/netlink/af_netlink.c | 19 +++++--
net/wireless/mlme.c | 12 ++---
63 files changed, 724 insertions(+), 384 deletions(-)
create mode 100644 drivers/net/phy/at803x.c
^ permalink raw reply
* Re: [PATCH net-next V2 1/1] tcp: Prevent needless syn-ack rexmt during TWHS
From: Julian Anastasov @ 2012-10-26 21:30 UTC (permalink / raw)
To: Vijay Subramanian
Cc: netdev, davem, edumazet, ncardwell, Venkat Venkatsubra,
Elliott Hughes
In-Reply-To: <1351238750-13611-1-git-send-email-subramanian.vijay@gmail.com>
Hello,
On Fri, 26 Oct 2012, Vijay Subramanian wrote:
> Elliott Hughes <enh@google.com> saw strange behavior when server socket was not
> calling accept(). Client was receiving SYN-ACK back even when socket on server
> side was not yet available. Eric noted server sockets kept resending SYN_ACKS
> and further investigation revealed the following problem.
>
> If server socket is slow to accept() connections, request_socks can represent
> connections for which the three-way handshake is already done. From client's
> point of view, the connection is in ESTABLISHED state but on server side, socket
> is not in accept_queue or ESTABLISHED state. When the syn-ack timer expires,
> because of the order in which tests are performed, server can retransmit the
> synack repeatedly. Following patch prevents the server from retransmitting the
> synack needlessly (and prevents client from replying with ack). This reduces
> traffic when server is slow to accept() connections.
>
> If the server socket has received the third ack during connection establishment,
> this is remembered in inet_rsk(req)->acked. The request_sock will expire in
> around 30 seconds and will be dropped if it does not move into accept_queue.
>
> With help from Eric Dumazet.
>
> Reported-by: Eric Dumazet <edumazet@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Tested-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Vijay Subramanian <subramanian.vijay@gmail.com>
> ---
> Changes from V1: Changed Reported-by tag and commit message. Added Acked-by and
> Tested-by tags.
>
> Ignoring "WARNING: line over 80 characters" in the interest of readability.
>
> net/ipv4/inet_connection_sock.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index d34ce29..4e8e52e 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -598,9 +598,8 @@ void inet_csk_reqsk_queue_prune(struct sock *parent,
> &expire, &resend);
> req->rsk_ops->syn_ack_timeout(parent, req);
> if (!expire &&
> - (!resend ||
> - !req->rsk_ops->rtx_syn_ack(parent, req, NULL) ||
> - inet_rsk(req)->acked)) {
> + (!resend || inet_rsk(req)->acked ||
Wait a minute, this can cause problem at least
for the TCP_DEFER_ACCEPT mode. It is supposed to timeout
in SYN_RECV state if after silence period (no retransmissions)
and some final retransmissions (until max_retries) client
still does not send data - the request should be expired
without notifying the listener.
So, the logic in syn_ack_recalc() was tuned to resend
after the TCP_DEFER_ACCEPT period. This patch stops such
resends after TCP_DEFER_ACCEPT period. May be the change
should be in syn_ack_recalc() without hurting TCP_DEFER_ACCEPT?
Lets analyze the default case without TCP_DEFER_ACCEPT.
Think for protocols like SMTP where server sends
welcome message. This patch stops SYN-ACK resends, client
sends one ACK (which server drops) and enters EST state.
Client is waiting for welcome message in EST state while
server is waiting silently for ACK message to create child
socket. No progress, may but timeout error in client.
Is the patch safe for such case? Is there a logic
that creates child socket from request if the dropped ACK
was the last message from client? It must not do it for
TCP_DEFER_ACCEPT.
> + !req->rsk_ops->rtx_syn_ack(parent, req, NULL))) {
> unsigned long timeo;
>
> if (req->retrans++ == 0)
> --
> 1.7.0.4
>
> --
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net-next] netxen: explicity handle pause autoneg parameter
From: Ben Hutchings @ 2012-10-26 21:10 UTC (permalink / raw)
To: Flavio Leitner; +Cc: netdev, Sony Chacko, Rajesh Borundia
In-Reply-To: <1351271832-21275-1-git-send-email-fbl@redhat.com>
On Fri, 2012-10-26 at 15:17 -0200, Flavio Leitner wrote:
> The hardware doesn't support controlling pause frames autoneg, so
> report that back correctly to userspace.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
> ---
> drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> I don't have the hardware handy to test this, so I appreciate
> if someone could do it.
>
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
> index 10468e7..b4b46f9 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
> @@ -488,6 +488,8 @@ netxen_nic_get_pauseparam(struct net_device *dev,
> __u32 val;
> int port = adapter->physical_port;
>
> + pause->autoneg = AUTONEG_DISABLE;
AUTONEG_DISABLE is really meant for use in ethtool_cmd::autoneg, not
ethtool_pauseparam::autoneg. (Though they are both really booleans so
this works in practice.)
> if (adapter->ahw.port_type == NETXEN_NIC_GBE) {
> if ((port < 0) || (port >= NETXEN_NIU_MAX_GBE_PORTS))
> return;
> @@ -532,6 +534,10 @@ netxen_nic_set_pauseparam(struct net_device *dev,
> struct netxen_adapter *adapter = netdev_priv(dev);
> __u32 val;
> int port = adapter->physical_port;
> +
> + if (pause->autoneg)
> + return -EOPNOTSUPP;
Should be -EINVAL; the operation (ETHTOOL_SPAUSEPARAM) is supported but
not these particular arguments.
Ben.
> /* read mode */
> if (adapter->ahw.port_type == NETXEN_NIC_GBE) {
> if ((port < 0) || (port >= NETXEN_NIU_MAX_GBE_PORTS))
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] sctp: Clean up type-punning in sctp_cmd_t union
From: David Miller @ 2012-10-26 21:10 UTC (permalink / raw)
To: nhorman; +Cc: vyasevich, netdev, linux-sctp
In-Reply-To: <20121026203504.GD25087@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 26 Oct 2012 16:35:04 -0400
> On Fri, Oct 26, 2012 at 03:12:11PM -0400, Vlad Yasevich wrote:
>> Look at commit 19c7e9ee that introduced this. I don't remember all
>> the details any more, but the problem only occurred on ia64
>> (probably due its speculative load handling).
>>
>> -vlad
>>
> Thanks Vlad, I'll have a look see.
Ok, so this IA64 issue is all about accesses to uninitialized memory.
I think Neil's change is thus the most desirable thing to do. Simple
memset the object to zero.
Let the compiler optimize or not optimize things as it sees fit, to
make sure the object is completely initialized.
memset() expands to __builtin_memset(), and therefore the compiler
can and will eliminate initializations to overlapping areas if such
eliminations are possible.
^ permalink raw reply
* Re: [PATCH] sctp: Clean up type-punning in sctp_cmd_t union
From: Neil Horman @ 2012-10-26 20:35 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <508AE08B.8070303@gmail.com>
On Fri, Oct 26, 2012 at 03:12:11PM -0400, Vlad Yasevich wrote:
> On 10/26/2012 09:24 AM, Neil Horman wrote:
> >On Thu, Oct 25, 2012 at 11:48:16PM -0400, Vlad Yasevich wrote:
> >>On 10/25/2012 07:58 PM, Neil Horman wrote:
> >>>On Thu, Oct 25, 2012 at 05:42:15PM -0400, Vlad Yasevich wrote:
> >>>>On 10/25/2012 04:47 PM, Neil Horman wrote:
> >>>>>Lots of points in the sctp_cmd_interpreter function treat the sctp_cmd_t arg as
> >>>>>a void pointer, even though they are written as various other types. Theres no
> >>>>>need for this as doing so just leads to possible type-punning issues that could
> >>>>>cause crashes, and if we remain type-consistent we can actually just remove the
> >>>>>void * member of the union entirely.
> >>>>>
> >>>>>Signed-off-by: Neil Horman <nhorman@tuxdriver.com
> >>>>>CC: Vlad Yasevich <vyasevich@gmail.com>
> >>>>>CC: "David S. Miller" <davem@davemloft.net>
> >>>>>CC: linux-sctp@vger.kernel.org
> >>>>>---
> >>>>> include/net/sctp/command.h | 7 ++++---
> >>>>> include/net/sctp/ulpqueue.h | 2 +-
> >>>>> net/sctp/sm_sideeffect.c | 45 ++++++++++++++++++++++-----------------------
> >>>>> net/sctp/ulpqueue.c | 3 +--
> >>>>> 4 files changed, 28 insertions(+), 29 deletions(-)
> >>>>>
> >>>>>diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
> >>>>>index 712b3be..7f1b0f3 100644
> >>>>>--- a/include/net/sctp/command.h
> >>>>>+++ b/include/net/sctp/command.h
> >>>>>@@ -131,7 +131,6 @@ typedef union {
> >>>>> sctp_state_t state;
> >>>>> sctp_event_timeout_t to;
> >>>>> unsigned long zero;
> >>>>>- void *ptr;
> >>>>> struct sctp_chunk *chunk;
> >>>>> struct sctp_association *asoc;
> >>>>> struct sctp_transport *transport;
> >>>>>@@ -154,9 +153,12 @@ typedef union {
> >>>>> * which takes an __s32 and returns a sctp_arg_t containing the
> >>>>> * __s32. So, after foo = SCTP_I32(arg), foo.i32 == arg.
> >>>>> */
> >>>>>+#define SCTP_NULL_BYTE 0xAA
> >>>>> static inline sctp_arg_t SCTP_NULL(void)
> >>>>> {
> >>>>>- sctp_arg_t retval; retval.ptr = NULL; return retval;
> >>>>>+ sctp_arg_t retval;
> >>>>>+ memset(&retval, SCTP_NULL_BYTE, sizeof(sctp_arg_t));
> >>>>>+ return retval;
> >>>>
> >>>>What's this for? Can't we just use retval.zero?
> >>>>
> >>>>-vlad
> >>>>
> >>>My intent was to highlight any users of sctp_arg_t when SCTP_NULL was passed.
> >>>My thinking was that the 0xAA byte patern would be a good indicator. Although,
> >>>admittedly I didn't see the zero argument there. Looking at it though, the zero
> >>>member of the union is effectively unused. Strictly speaking its used for
> >>>initalization of sctp_arg_t, but its done somewhat poorly, since theres no
> >>>guarantee that an unsigned long will be the largest member of that union. Doing
> >>>the memset guarantees the whole instance is set to a predefined value.
> >>>
> >>>I could go either way with this, would you rather we just have SCTP_NULL return
> >>>retval = { .zero = 0}; or would you rather remove the zero initialization from
> >>>SCTP_[NO]FORCE, and SCTP_ARG_CONSTRUCTOR and do the memset. I think the memset
> >>>reduces to a single 64 bit assignment as long as the union doesn't exceed that
> >>>size anyway, and it ensures that you initalize the whole union's storage if it
> >>>does in the future. And if we remove the initialization step (I don't see that
> >>>its needed in the three macros above anyway), then we can remove the zero member
> >>>as well.
> >>>
> >>
> >>You need the initialization step, otherwise things might fail (they
> >>did on IA64 a while back). That's why the zero member was added.
> >>You can go with memset if you want, but I was primarily wondering
> >>why the 0xAA pattern was there.
> >>
> >The AA I did was just meant as a pattern marker, so that, should someone use an
> >instance of sctp_arg_t that was passed in as SCTP_NULL(), it would be visually
> >obvious in the stack trace, but I suppose its not really needed given that NULL
> >is equally clear. And since Dave pointed out the lack of optimization
> >opportunity when using a store to an address rather than a register, I think I
> >should probably just revert it and use zero as you initially suggested.
> >
> >The need for the initalization in SCTP_[NO]FORCE and SCTP_ARG_CONSTRUCTOR
> >concerns me though. All its doing is setting part of the storage to zero, and
> >then overwriting it again with whatever type spcific member you're assigning
> >from the corresponding SCTP_* macro. That kind of sounds to me like ia64 might
> >have fallen to some amount of type-punning problem. do you have a link to
> >discussion about that problem?
> >
>
> Look at commit 19c7e9ee that introduced this. I don't remember all
> the details any more, but the problem only occurred on ia64
> (probably due its speculative load handling).
>
> -vlad
>
Thanks Vlad, I'll have a look see.
Regards
Neil
^ permalink raw reply
* huh, entered softirq 3 NET_RX 082db810 preempt_count 00000101, exited with fffefc05?
From: Toralf Förster @ 2012-10-26 20:34 UTC (permalink / raw)
To: netdev
At a user mode linux image (unstable Gentoo) I experienced a hang
(100% CPU of the linux process), no reaction anymore.
The last lines in the syslog of the UML gave:
...
Oct 26 22:18:07 n22_uml kernel: Virtual console 6 assigned device '/dev/pts/5'
Oct 26 22:18:07 n22_uml kernel: Virtual console 4 assigned device '/dev/pts/6'
Oct 26 22:18:07 n22_uml kernel: Virtual console 5 assigned device '/dev/pts/8'
Oct 26 22:18:07 n22_uml kernel: Virtual console 3 assigned device '/dev/pts/9'
Oct 26 22:18:07 n22_uml kernel: Virtual console 2 assigned device '/dev/pts/10'
Oct 26 22:18:07 n22_uml kernel: Virtual console 1 assigned device '/dev/pts/11'
Oct 26 22:19:05 n22_uml kernel: ------------[ cut here ]------------
Oct 26 22:19:05 n22_uml kernel: WARNING: at kernel/softirq.c:160 local_bh_enable+0x8f/0xa0()
Oct 26 22:19:05 n22_uml kernel: 384fa37c: [<0836bc48>] dump_stack+0x22/0x24
Oct 26 22:19:05 n22_uml kernel: 384fa394: [<0807fc2a>] warn_slowpath_common+0x5a/0x80
Oct 26 22:19:05 n22_uml kernel: 384fa3bc: [<0807fd03>] warn_slowpath_null+0x23/0x30
Oct 26 22:19:05 n22_uml kernel: 384fa3cc: [<0808733f>] local_bh_enable+0x8f/0xa0
Oct 26 22:19:05 n22_uml kernel: 384fa3e0: [<082da6f8>] dev_queue_xmit+0xe8/0x270
Oct 26 22:19:05 n22_uml kernel: 384fa410: [<082fd15f>] ip_finish_output+0x1af/0x370
Oct 26 22:19:05 n22_uml kernel: 384fa444: [<082fd373>] ip_output+0x53/0x60
Oct 26 22:19:05 n22_uml kernel: 384fa45c: [<082fc243>] ip_local_out+0x23/0x30
Oct 26 22:19:05 n22_uml kernel: 384fa46c: [<082fc384>] ip_build_and_send_pkt+0x134/0x1f0
Oct 26 22:19:05 n22_uml kernel: 384fa4a8: [<08319dc0>] tcp_v4_conn_request+0x7c0/0xcc0
Oct 26 22:19:05 n22_uml kernel: 384fa5ac: [<08310c9c>] tcp_rcv_state_process+0x1bc/0xd40
Oct 26 22:19:05 n22_uml kernel: 384fa618: [<08317a7d>] tcp_v4_do_rcv+0x8d/0x270
Oct 26 22:19:05 n22_uml kernel: 384fa65c: [<0831ab36>] tcp_v4_rcv+0x746/0x860
Oct 26 22:19:05 n22_uml kernel: 384fa6a4: [<082f8696>] ip_local_deliver+0x76/0x1d0
Oct 26 22:19:05 n22_uml kernel: 384fa6c4: [<082f8a98>] ip_rcv+0x2a8/0x4a0
Oct 26 22:19:05 n22_uml kernel: 384fa6f0: [<082d7a34>] __netif_receive_skb+0x254/0x550
Oct 26 22:19:05 n22_uml kernel: 384fa738: [<082d7d99>] process_backlog+0x69/0x100
Oct 26 22:19:05 n22_uml kernel: 384fa758: [<082db88c>] net_rx_action+0x7c/0x140
Oct 26 22:19:05 n22_uml kernel: 384fa77c: [<08087145>] __do_softirq+0xa5/0x170
Oct 26 22:19:05 n22_uml kernel: 384fa7b8: [<080872a5>] do_softirq+0x55/0x60
Oct 26 22:19:05 n22_uml kernel: 384fa7cc: [<080874f5>] irq_exit+0x85/0x90
Oct 26 22:19:05 n22_uml kernel: 384fa7dc: [<0805ef3a>] do_IRQ+0x2a/0x40
Oct 26 22:19:05 n22_uml kernel: 384fa7ec: [<0805efab>] sigio_handler+0x5b/0x80
Oct 26 22:19:05 n22_uml kernel: 384fa804: [<08073b87>] sig_handler_common+0x57/0xe0
Oct 26 22:19:05 n22_uml kernel: 384faa88: [<08073b10>] unblock_signals+0x50/0x70
Oct 26 22:19:05 n22_uml kernel: 384faa94: [<08073ca0>] set_signals+0x30/0x40
Oct 26 22:19:05 n22_uml kernel: 384faaa0: [<08087296>] do_softirq+0x46/0x60
Oct 26 22:19:05 n22_uml kernel: 384faab4: [<08087329>] local_bh_enable+0x79/0xa0
Oct 26 22:19:05 n22_uml kernel: 384faac8: [<082fd166>] ip_finish_output+0x1b6/0x370
Oct 26 22:19:05 n22_uml kernel: 384faafc: [<082fd373>] ip_output+0x53/0x60
Oct 26 22:19:05 n22_uml kernel: 384fab14: [<082fc243>] ip_local_out+0x23/0x30
Oct 26 22:19:05 n22_uml kernel: 384fab24: [<082fc55f>] ip_queue_xmit+0x11f/0x3a0
Oct 26 22:19:05 n22_uml kernel: 384fab6c: [<08312de8>] tcp_transmit_skb+0x3e8/0x890
Oct 26 22:19:05 n22_uml kernel: 384fabc8: [<0831345d>] tcp_write_xmit+0xfd/0xa60
Oct 26 22:19:05 n22_uml kernel: 384fac28: [<08313e68>] __tcp_push_pending_frames+0x38/0xa0
Oct 26 22:19:05 n22_uml kernel: 384fac40: [<083044c9>] tcp_sendmsg+0x129/0xe30
Oct 26 22:19:05 n22_uml kernel: 384facc4: [<08328fdb>] inet_sendmsg+0x3b/0x60
Oct 26 22:19:05 n22_uml kernel: 384face0: [<082c7dc4>] sock_aio_write+0x114/0x140
Oct 26 22:19:05 n22_uml kernel: 384fad50: [<08103803>] do_sync_readv_writev+0x83/0xc0
Oct 26 22:19:05 n22_uml kernel: 384fadf4: [<08103ab1>] do_readv_writev+0xb1/0x1c0
Oct 26 22:19:05 n22_uml kernel: 384fae6c: [<08103c4c>] vfs_writev+0x3c/0x50
Oct 26 22:19:05 n22_uml kernel: 384fae7c: [<08103d50>] sys_writev+0x50/0xa0
Oct 26 22:19:05 n22_uml kernel: 384faeac: [<08062ec6>] handle_syscall+0xa6/0xb0
Oct 26 22:19:05 n22_uml kernel: 384faef4: [<0807711f>] userspace+0x3ef/0x5a0
Oct 26 22:19:05 n22_uml kernel: 384fafec: [<0805f8ec>] fork_handler+0x6c/0x70
Oct 26 22:19:05 n22_uml kernel: 384faffc: [<00000000>] 0x0
Oct 26 22:19:05 n22_uml kernel:
Oct 26 22:19:05 n22_uml kernel: ---[ end trace bb507477e2c8dbef ]---
Oct 26 22:19:05 n22_uml kernel: ------------[ cut here ]------------
Oct 26 22:19:05 n22_uml kernel: WARNING: at net/core/skbuff.c:573 skb_release_head_state+0x89/0x90()
Oct 26 22:19:05 n22_uml kernel: 384fa314: [<0836bc48>] dump_stack+0x22/0x24
Oct 26 22:19:05 n22_uml kernel: 384fa32c: [<0807fc2a>] warn_slowpath_common+0x5a/0x80
Oct 26 22:19:05 n22_uml kernel: 384fa354: [<0807fd03>] warn_slowpath_null+0x23/0x30
Oct 26 22:19:05 n22_uml kernel: 384fa364: [<082ce839>] skb_release_head_state+0x89/0x90
Oct 26 22:19:05 n22_uml kernel: 384fa37c: [<082cf591>] __kfree_skb+0x11/0xa0
Oct 26 22:19:05 n22_uml kernel: 384fa390: [<082cf640>] consume_skb+0x20/0x40
Oct 26 22:19:05 n22_uml kernel: 384fa39c: [<08068b84>] uml_net_start_xmit+0x84/0x120
Oct 26 22:19:05 n22_uml kernel: 384fa3c0: [<082da1a1>] dev_hard_start_xmit+0x1e1/0x420
Oct 26 22:19:05 n22_uml kernel: 384fa3fc: [<082eeecb>] sch_direct_xmit+0x7b/0x140
Oct 26 22:19:05 n22_uml kernel: 384fa428: [<082da6e0>] dev_queue_xmit+0xd0/0x270
Oct 26 22:19:05 n22_uml kernel: 384fa458: [<082fd15f>] ip_finish_output+0x1af/0x370
Oct 26 22:19:05 n22_uml kernel: 384fa48c: [<082fd373>] ip_output+0x53/0x60
Oct 26 22:19:05 n22_uml kernel: 384fa4a4: [<082fc243>] ip_local_out+0x23/0x30
Oct 26 22:19:05 n22_uml kernel: 384fa4b4: [<082fc55f>] ip_queue_xmit+0x11f/0x3a0
Oct 26 22:19:05 n22_uml kernel: 384fa4fc: [<08312de8>] tcp_transmit_skb+0x3e8/0x890
Oct 26 22:19:05 n22_uml kernel: 384fa558: [<08315d6a>] tcp_send_ack+0xda/0x120
Oct 26 22:19:05 n22_uml kernel: 384fa574: [<0830a7b2>] __tcp_ack_snd_check+0x52/0x90
Oct 26 22:19:05 n22_uml kernel: 384fa588: [<083114ac>] tcp_rcv_state_process+0x9cc/0xd40
Oct 26 22:19:05 n22_uml kernel: 384fa5f4: [<0831bd60>] tcp_child_process+0xa0/0xd0
Oct 26 22:19:05 n22_uml kernel: 384fa618: [<08317ba7>] tcp_v4_do_rcv+0x1b7/0x270
Oct 26 22:19:05 n22_uml kernel: 384fa65c: [<0831ab36>] tcp_v4_rcv+0x746/0x860
Oct 26 22:19:05 n22_uml kernel: 384fa6a4: [<082f8696>] ip_local_deliver+0x76/0x1d0
Oct 26 22:19:05 n22_uml kernel: 384fa6c4: [<082f8a98>] ip_rcv+0x2a8/0x4a0
Oct 26 22:19:05 n22_uml kernel: 384fa6f0: [<082d7a34>] __netif_receive_skb+0x254/0x550
Oct 26 22:19:05 n22_uml kernel: 384fa738: [<082d7d99>] process_backlog+0x69/0x100
Oct 26 22:19:05 n22_uml kernel: 384fa758: [<082db88c>] net_rx_action+0x7c/0x140
Oct 26 22:19:05 n22_uml kernel: 384fa77c: [<08087145>] __do_softirq+0xa5/0x170
Oct 26 22:19:05 n22_uml kernel: 384fa7b8: [<080872a5>] do_softirq+0x55/0x60
Oct 26 22:19:05 n22_uml kernel: 384fa7cc: [<080874f5>] irq_exit+0x85/0x90
Oct 26 22:19:05 n22_uml kernel: 384fa7dc: [<0805ef3a>] do_IRQ+0x2a/0x40
Oct 26 22:19:05 n22_uml kernel: 384fa7ec: [<0805efab>] sigio_handler+0x5b/0x80
Oct 26 22:19:05 n22_uml kernel: 384fa804: [<08073b87>] sig_handler_common+0x57/0xe0
Oct 26 22:19:05 n22_uml kernel: 384faa88: [<08073b10>] unblock_signals+0x50/0x70
Oct 26 22:19:05 n22_uml kernel: 384faa94: [<08073ca0>] set_signals+0x30/0x40
Oct 26 22:19:05 n22_uml kernel: 384faaa0: [<08087296>] do_softirq+0x46/0x60
Oct 26 22:19:05 n22_uml kernel: 384faab4: [<08087329>] local_bh_enable+0x79/0xa0
Oct 26 22:19:05 n22_uml kernel: 384faac8: [<082fd166>] ip_finish_output+0x1b6/0x370
Oct 26 22:19:05 n22_uml kernel: 384faafc: [<082fd373>] ip_output+0x53/0x60
Oct 26 22:19:05 n22_uml kernel: 384fab14: [<082fc243>] ip_local_out+0x23/0x30
Oct 26 22:19:05 n22_uml kernel: 384fab24: [<082fc55f>] ip_queue_xmit+0x11f/0x3a0
Oct 26 22:19:05 n22_uml kernel: 384fab6c: [<08312de8>] tcp_transmit_skb+0x3e8/0x890
Oct 26 22:19:05 n22_uml kernel: 384fabc8: [<0831345d>] tcp_write_xmit+0xfd/0xa60
Oct 26 22:19:05 n22_uml kernel: 384fac28: [<08313e68>] __tcp_push_pending_frames+0x38/0xa0
Oct 26 22:19:05 n22_uml kernel: 384fac40: [<083044c9>] tcp_sendmsg+0x129/0xe30
Oct 26 22:19:05 n22_uml kernel: 384facc4: [<08328fdb>] inet_sendmsg+0x3b/0x60
Oct 26 22:19:05 n22_uml kernel: 384face0: [<082c7dc4>] sock_aio_write+0x114/0x140
Oct 26 22:19:05 n22_uml kernel: 384fad50: [<08103803>] do_sync_readv_writev+0x83/0xc0
Oct 26 22:19:05 n22_uml kernel: 384fadf4: [<08103ab1>] do_readv_writev+0xb1/0x1c0
Oct 26 22:19:05 n22_uml kernel: 384fae6c: [<08103c4c>] vfs_writev+0x3c/0x50
Oct 26 22:19:05 n22_uml kernel: 384fae7c: [<08103d50>] sys_writev+0x50/0xa0
Oct 26 22:19:05 n22_uml kernel: 384faeac: [<08062ec6>] handle_syscall+0xa6/0xb0
Oct 26 22:19:05 n22_uml kernel: 384faef4: [<0807711f>] userspace+0x3ef/0x5a0
Oct 26 22:19:05 n22_uml kernel: 384fafec: [<0805f8ec>] fork_handler+0x6c/0x70
Oct 26 22:19:05 n22_uml kernel: 384faffc: [<00000000>] 0x0
Oct 26 22:19:05 n22_uml kernel:
Oct 26 22:19:05 n22_uml kernel: ---[ end trace bb507477e2c8dbf0 ]---
Oct 26 22:19:05 n22_uml kernel: huh, entered softirq 3 NET_RX 082db810 preempt_count 00000101, exited with fffefc05?
Oct 26 22:20:01 n22_uml cron[1167]: (root) CMD (/usr/lib/sa/sa1 60 5)
Oct 26 22:20:01 n22_uml cron[1170]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)
Oct 26 22:20:02 n22_uml run-crons[1181]: (root) CMD (/etc/cron.daily/logrotate.cron)
Oct 26 22:20:02 n22_uml run-crons[1185]: (root) CMD (/etc/cron.daily/makewhatis)
Oct 26 22:20:21 n22_uml run-crons[1484]: (root) CMD (/etc/cron.daily/mlocate)
I can reproduce it by stressing an apache2 running inside of the UML
process (hostname n22_uml) by this loop from the host:
$ for i in $(seq 1 10000); do echo -en "$i\r"; wget --timeout=10 --tries=1 --quiet --no-check-certificate -O /dev/null https://n22_uml/public/df.php || break; done; echo
From the UML command line I only get this (senseless lines ?) :
[ ok ]
Kernel panic - not syncing: Segfault with no mm
0842c768: [<0836bc48>] dump_stack+0x22/0x24
0842c780: [<0836bcfc>] panic+0x7a/0x181
0842c7a8: [<080624cc>] segv+0x24c/0x2b0
0842c858: [<08062583>] segv_handler+0x53/0x90
0842c880: [<08073b87>] sig_handler_common+0x57/0xe0
0842cb04: [<08073d35>] sig_handler+0x45/0x60
0842cb14: [<0807384b>] hard_handler+0x6b/0xb0
0842cb3c: [<b776540c>] 0xb776540c
EIP: 0000:[<00000000>] CPU: 0 Tainted: G W EFLAGS: 00000000
Tainted: G W
EAX: 00000000 EBX: 00000000 ECX: 00100100 EDX: 00200200
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: ffff ES: 0000
0842c71c: [<0807bb6d>] show_regs+0xed/0x120
0842c738: [<0806292c>] panic_exit+0x2c/0x50
0842c748: [<080a14a1>] notifier_call_chain+0x41/0x60
0842c770: [<080a15e3>] atomic_notifier_call_chain+0x23/0x30
0842c780: [<0836bd24>] panic+0xa2/0x181
0842c7a8: [<080624cc>] segv+0x24c/0x2b0
0842c858: [<08062583>] segv_handler+0x53/0x90
0842c880: [<08073b87>] sig_handler_common+0x57/0xe0
0842cb04: [<08073d35>] sig_handler+0x45/0x60
0842cb14: [<0807384b>] hard_handler+0x6b/0xb0
0842cb3c: [<b776540c>] 0xb776540c
The php file for completeness:
n22_uml ~ # cat /var/www/localhost/htdocs/public/df.php
<?php
$ds = disk_total_space("/home");
echo $ds . " bytes " . '<br />';
?>
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: [RFC PATCH 1/2] net: Add support for hardware-offloaded encapsulation
From: Stephen Hemminger @ 2012-10-26 20:21 UTC (permalink / raw)
To: Gasparakis, Joseph
Cc: Ben Hutchings, davem@davemloft.net, chrisw@sous-sol.org,
netdev@vger.kernel.org, Waskiewicz Jr, Peter P
In-Reply-To: <F9D617782E85934FB0AD6CD1BA0C8EE7324B7663@ORSMSX101.amr.corp.intel.com>
On Fri, 26 Oct 2012 19:54:12 +0000
"Gasparakis, Joseph" <joseph.gasparakis@intel.com> wrote:
> Stephen, are you happy with Ben's comment?
> If that is the case I would prefer to keep the patch as is as I believe it makes sense to group the features that way.
No problem. As long as it's safe which Ben said.
^ permalink raw reply
* Re: [PATCH net-next] sctp: support per-association stats via a new SCTP_GET_ASSOC_STATS call
From: Vlad Yasevich @ 2012-10-26 20:00 UTC (permalink / raw)
To: Michele Baldessari
Cc: linux-sctp, Neil Horman, David S. Miller, netdev, Thomas Graf
In-Reply-To: <1351258973-17227-1-git-send-email-michele@acksyn.org>
On 10/26/2012 09:42 AM, Michele Baldessari wrote:
> The current SCTP stack is lacking an API to have per association
> statistics. This is a kernel implementation modeled after OpenSolaris'
> SCTP_GET_ASSOC_STATS.
>
> Userspace part will follow on lksctp if/when there is a general ACK on this.
>
> Signed-off-by: Michele Baldessari <michele@acksyn.org>
> Acked-by: Thomas Graf <tgraf@suug.ch>
> ---
> include/net/sctp/sctp.h | 3 +++
> include/net/sctp/structs.h | 39 +++++++++++++++++++++++++++
> include/net/sctp/user.h | 26 ++++++++++++++++++
> net/sctp/associola.c | 20 ++++++++++++++
> net/sctp/endpointola.c | 5 +++-
> net/sctp/input.c | 5 ++--
> net/sctp/output.c | 5 ++++
> net/sctp/outqueue.c | 12 +++++++++
> net/sctp/sm_sideeffect.c | 2 ++
> net/sctp/sm_statefuns.c | 12 +++++++--
> net/sctp/socket.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++
> net/sctp/transport.c | 2 ++
> 12 files changed, 193 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 9c6414f..e2248de 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -272,6 +272,9 @@ struct sctp_mib {
> unsigned long mibs[SCTP_MIB_MAX];
> };
>
> +#define SCTP_MAX_RTO(asoc, transport) \
> + (asoc)->max_obs_rto = max((__u64)(transport)->rto, \
> + (asoc)->max_obs_rto);
>
> /* Print debugging messages. */
> #if SCTP_DEBUG
> diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
> index 64158aa..8afcb57 100644
> --- a/include/net/sctp/structs.h
> +++ b/include/net/sctp/structs.h
> @@ -1829,6 +1829,45 @@ struct sctp_association {
>
> __u8 need_ecne:1, /* Need to send an ECNE Chunk? */
> temp:1; /* Is it a temporary association? */
> +
> + /* Total In and Out SACKs received and sent */
> + __u64 isacks;
> + __u64 osacks;
> +
> + /* Total In and Out packets received and sent */
> + __u64 opackets;
> + __u64 ipackets;
> +
> + /* Total retransmitted chunks and packets */
> + __u64 rtxchunks;
> + __u64 rtxpackets;
rtxpackes don't make sense as Neil already pointed out.
> +
> + /* TSN received > next expected */
> + __u64 outseqtsns;
the name is confusing. One could interpret it as outgoing sequential
tsns...
> +
> + /* Duplicate Chunks received */
> + __u64 idupchunks;
Do you need dups sent too? Could be a usefull statistics.
> +
> + /* Gap Ack Blocks received */
> + __u64 gapcnt;
> +
> + /* Unordered data chunks sent and received */
> + __u64 ouodchunks;
> + __u64 iuodchunks;
> +
> + /* Ordered data chunks sent and received */
> + __u64 oodchunks;
> + __u64 iodchunks;
> +
> + /* Control chunks sent and received */
> + __u64 octrlchunks;
> + __u64 ictrlchunks;
> +
> + /* Maximum observed rto in the association. Value is unchanged
> + * when read and the max rto did not change
> + */
> + __u64 max_obs_rto;
> + __u64 max_prev_obs_rto;
One thing I'd say is that this grows an already large structure rather
significantly. Could we perhaps put it in its own structure?
> };
>
>
> diff --git a/include/net/sctp/user.h b/include/net/sctp/user.h
> index 1b02d7a..c1715e2 100644
> --- a/include/net/sctp/user.h
> +++ b/include/net/sctp/user.h
> @@ -94,6 +94,7 @@ typedef __s32 sctp_assoc_t;
> #define SCTP_GET_ASSOC_ID_LIST 29 /* Read only */
> #define SCTP_AUTO_ASCONF 30
> #define SCTP_PEER_ADDR_THLDS 31
> +#define SCTP_GET_ASSOC_STATS 32 /* Read only */
>
> /* Internal Socket Options. Some of the sctp library functions are
> * implemented using these socket options.
> @@ -719,6 +720,31 @@ struct sctp_getaddrs {
> __u8 addrs[0]; /*output, variable size*/
> };
>
> +/* A socket user request obtained via SCTP_GET_ASSOC_STATS that retrieves
> + * local per endpoint association stats. All stats are counts except
> + * sas_maxrto, which is the max value since the last user request for
> + * stats on this endpoint.
> + */
> +struct sctp_assoc_stats {
> + sctp_assoc_t sas_assoc_id; /* Input */
> + __u64 sas_rtxchunks; /* Retransmitted Chunks */
> + __u64 sas_gapcnt; /* Gap Acknowledgements Received */
> + __u64 sas_outseqtsns; /* TSN received > next expected */
> + __u64 sas_osacks; /* SACKs sent */
> + __u64 sas_isacks; /* SACKs received */
> + __u64 sas_octrlchunks; /* Control chunks sent */
> + __u64 sas_ictrlchunks; /* Control chunks received */
> + __u64 sas_oodchunks; /* Ordered data chunks sent */
> + __u64 sas_iodchunks; /* Ordered data chunks received */
> + __u64 sas_ouodchunks; /* Unordered data chunks sent */
> + __u64 sas_iuodchunks; /* Unordered data chunks received */
> + __u64 sas_idupchunks; /* Dups received (ordered+unordered) */
> + __u64 sas_opackets; /* Packets sent */
> + __u64 sas_ipackets; /* Packets received */
> + __u64 sas_rtxpackets; /* Packets retransmitted */
> + __u64 sas_maxrto; /* Maximum Observed RTO for period */
> +};
> +
> /* These are bit fields for msghdr->msg_flags. See section 5.1. */
> /* On user space Linux, these live in <bits/socket.h> as an enum. */
> enum sctp_msg_flags {
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index b1ef3bc..8560048 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -321,6 +321,25 @@ static struct sctp_association *sctp_association_init(struct sctp_association *a
> asoc->default_timetolive = sp->default_timetolive;
> asoc->default_rcv_context = sp->default_rcv_context;
>
> + /* SCTP_GET_ASSOC_STATS COUNTERS */
> + asoc->isacks = 0;
> + asoc->osacks = 0;
> + asoc->opackets = 0;
> + asoc->ipackets = 0;
> + asoc->rtxpackets = 0;
> + asoc->rtxchunks = 0;
> + asoc->outseqtsns = 0;
> + asoc->idupchunks = 0;
> + asoc->gapcnt = 0;
> + asoc->ouodchunks = 0;
> + asoc->iuodchunks = 0;
> + asoc->oodchunks = 0;
> + asoc->iodchunks = 0;
> + asoc->octrlchunks = 0;
> + asoc->ictrlchunks = 0;
> + asoc->max_obs_rto = 0;
> + asoc->max_prev_obs_rto = 0;
> +
> /* AUTH related initializations */
> INIT_LIST_HEAD(&asoc->endpoint_shared_keys);
> err = sctp_auth_asoc_copy_shkeys(ep, asoc, gfp);
> @@ -760,6 +779,7 @@ struct sctp_transport *sctp_assoc_add_peer(struct sctp_association *asoc,
>
> /* Set the transport's RTO.initial value */
> peer->rto = asoc->rto_initial;
> + SCTP_MAX_RTO(asoc, peer);
>
> /* Set the peer's active state. */
> peer->state = peer_state;
> diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
> index 1859e2b..b89731e 100644
> --- a/net/sctp/endpointola.c
> +++ b/net/sctp/endpointola.c
> @@ -480,8 +480,11 @@ normal:
> */
> if (asoc && sctp_chunk_is_data(chunk))
> asoc->peer.last_data_from = chunk->transport;
> - else
> + else {
> SCTP_INC_STATS(sock_net(ep->base.sk), SCTP_MIB_INCTRLCHUNKS);
> + if (asoc)
> + asoc->ictrlchunks++;
> + }
>
> if (chunk->transport)
> chunk->transport->last_time_heard = jiffies;
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index 8bd3c27..3c32ca5 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -285,9 +285,10 @@ int sctp_rcv(struct sk_buff *skb)
> sctp_bh_unlock_sock(sk);
>
> /* Release the asoc/ep ref we took in the lookup calls. */
> - if (asoc)
> + if (asoc) {
> + asoc->ipackets++;
> sctp_association_put(asoc);
This should probably be done under lock. Doing it without a lock will
cause you to potentially miscount.
> - else
> + } else
> sctp_endpoint_put(ep);
>
> return 0;
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 4e90188bf..ca5ce50 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -311,6 +311,8 @@ static sctp_xmit_t __sctp_packet_append_chunk(struct sctp_packet *packet,
>
> case SCTP_CID_SACK:
> packet->has_sack = 1;
> + if (chunk->asoc)
> + chunk->asoc->osacks++;
> break;
>
> case SCTP_CID_AUTH:
> @@ -591,6 +593,9 @@ int sctp_packet_transmit(struct sctp_packet *packet)
> asoc->peer.last_sent_to = tp;
> }
>
> + if (asoc)
> + asoc->opackets++;
> +
Testing for assoc again. Can you fold that into the check just above
that already checks the assoc.
> if (has_data) {
> struct timer_list *timer;
> unsigned long timeout;
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index 1b4a7f8..569ee3a 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -667,6 +667,8 @@ redo:
> chunk->fast_retransmit = SCTP_DONT_FRTX;
>
> q->empty = 0;
> + if (q->asoc)
> + q->asoc->rtxchunks++;
You can't have a queue without association so check for association is
not necessary.
> break;
> }
>
> @@ -678,6 +680,10 @@ redo:
> break;
> }
>
> + if (q->asoc)
> + q->asoc->rtxpackets++;
> +
> +
Ditto.
> /* If we are here due to a retransmit timeout or a fast
> * retransmit and if there are any chunks left in the retransmit
> * queue that could not fit in the PMTU sized packet, they need
> @@ -883,6 +889,7 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
> */
> sctp_transport_reset_timers(transport);
> }
> + asoc->octrlchunks++;
> break;
You will count the chunk even if it was not transmitted. See the
!= SCTP_XMIT_OK code just above this.
>
> default:
> @@ -1055,6 +1062,10 @@ static int sctp_outq_flush(struct sctp_outq *q, int rtx_timeout)
> */
> if (asoc->state == SCTP_STATE_SHUTDOWN_PENDING)
> chunk->chunk_hdr->flags |= SCTP_DATA_SACK_IMM;
> + if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED)
> + asoc->ouodchunks++;
> + else
> + asoc->oodchunks++;
This is inconsistent with how you treat control chunks. You could these
when they are simply queued to the output queue. You could control
chunks when they are taken from the control queue and transmitted.
Please make these consistent.
>
> break;
>
> @@ -1162,6 +1173,7 @@ int sctp_outq_sack(struct sctp_outq *q, struct sctp_chunk *chunk)
>
> sack_ctsn = ntohl(sack->cum_tsn_ack);
> gap_ack_blocks = ntohs(sack->num_gap_ack_blocks);
> + asoc->gapcnt += gap_ack_blocks;
> /*
> * SFR-CACC algorithm:
> * On receipt of a SACK the sender SHOULD execute the
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 6773d78..ed49431 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -542,6 +542,7 @@ static void sctp_do_8_2_transport_strike(sctp_cmd_seq_t *commands,
> */
> if (!is_hb || transport->hb_sent) {
> transport->rto = min((transport->rto * 2), transport->asoc->rto_max);
> + SCTP_MAX_RTO(asoc, transport);
> }
> }
>
> @@ -1330,6 +1331,7 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
>
> case SCTP_CMD_PROCESS_SACK:
> /* Process an inbound SACK. */
> + asoc->isacks++;
You are going to count SHUTDOWNs as SACKs.
> error = sctp_cmd_process_sack(commands, asoc,
> cmd->obj.ptr);
> break;
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index b6adef8..4f94432 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -6127,9 +6127,13 @@ static int sctp_eat_data(const struct sctp_association *asoc,
> /* The TSN is too high--silently discard the chunk and
> * count on it getting retransmitted later.
> */
> + if (chunk->asoc)
> + chunk->asoc->outseqtsns++;
> return SCTP_IERROR_HIGH_TSN;
> } else if (tmp > 0) {
> /* This is a duplicate. Record it. */
> + if (chunk->asoc)
> + chunk->asoc->idupchunks++;
> sctp_add_cmd_sf(commands, SCTP_CMD_REPORT_DUP, SCTP_U32(tsn));
> return SCTP_IERROR_DUP_TSN;
The REPORT_DUP command already records all the dups we got. Why not
simply update the idupchunks whenever we respond with a SACK at the end
of the packet? Dup TSNs force a sack to be sent.
This way you are not constantly updating the value if the packet
contains lots of small duplicate chunks.
> }
> @@ -6226,10 +6230,14 @@ static int sctp_eat_data(const struct sctp_association *asoc,
> /* Note: Some chunks may get overcounted (if we drop) or overcounted
> * if we renege and the chunk arrives again.
> */
> - if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED)
> + if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) {
> SCTP_INC_STATS(net, SCTP_MIB_INUNORDERCHUNKS);
> - else {
> + if (chunk->asoc)
> + chunk->asoc->iuodchunks++;
> + } else {
> SCTP_INC_STATS(net, SCTP_MIB_INORDERCHUNKS);
> + if (chunk->asoc)
> + chunk->asoc->iodchunks++;
> ordered = 1;
> }
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 59d16ea..ca6d0a1 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -610,6 +610,7 @@ static int sctp_send_asconf_add_ip(struct sock *sk,
> 2*asoc->pathmtu, 4380));
> trans->ssthresh = asoc->peer.i.a_rwnd;
> trans->rto = asoc->rto_initial;
> + SCTP_MAX_RTO(asoc, trans);
> trans->rtt = trans->srtt = trans->rttvar = 0;
> sctp_transport_route(trans, NULL,
> sctp_sk(asoc->base.sk));
> @@ -5632,6 +5633,69 @@ static int sctp_getsockopt_paddr_thresholds(struct sock *sk,
> return 0;
> }
>
> +/*
> + * SCTP_GET_ASSOC_STATS
> + *
> + * This option retrieves local per endpoint statistics. It is modeled
> + * after OpenSolaris' implementation
> + */
> +static int sctp_getsockopt_assoc_stats(struct sock *sk, int len,
> + char __user *optval,
> + int __user *optlen)
> +{
> + struct sctp_assoc_stats sas;
> + struct sctp_association *asoc = NULL;
> +
> + if (len < sizeof(struct sctp_assoc_stats))
> + return -EINVAL;
This will make it very hard to grow the structure if there
is a need for more data. We should probably allow partial
retrieval of data.
-vlad
> +
> + len = sizeof(struct sctp_assoc_stats);
> + if (copy_from_user(&sas, optval, len))
> + return -EFAULT;
> +
> + asoc = sctp_id2assoc(sk, sas.sas_assoc_id);
> + if (!asoc)
> + return -EINVAL;
> +
> + sas.sas_rtxchunks = asoc->rtxchunks;
> + sas.sas_gapcnt = asoc->gapcnt;
> + sas.sas_outseqtsns = asoc->outseqtsns;
> + sas.sas_osacks = asoc->osacks;
> + sas.sas_isacks = asoc->isacks;
> + sas.sas_octrlchunks = asoc->octrlchunks;
> + sas.sas_ictrlchunks = asoc->ictrlchunks;
> + sas.sas_oodchunks = asoc->oodchunks;
> + sas.sas_iodchunks = asoc->iodchunks;
> + sas.sas_ouodchunks = asoc->ouodchunks;
> + sas.sas_iuodchunks = asoc->iuodchunks;
> + sas.sas_idupchunks = asoc->idupchunks;
> + sas.sas_opackets = asoc->opackets;
> + sas.sas_ipackets = asoc->ipackets;
> + sas.sas_rtxpackets = asoc->rtxpackets;
> +
> + if (asoc->max_obs_rto == 0) /* unchanged during obervation period */
> + sas.sas_maxrto = asoc->max_prev_obs_rto;
> + else /* record new period maximum */
> + sas.sas_maxrto = asoc->max_obs_rto;
> +
> + /* Record the value sent to the user this period */
> + asoc->max_prev_obs_rto = sas.sas_maxrto;
> +
> + /* Mark beginning of a new observation period */
> + asoc->max_obs_rto = 0;
> +
> + if (put_user(len, optlen))
> + return -EFAULT;
> +
> + SCTP_DEBUG_PRINTK("sctp_getsockopt_assoc_stat(%d): %d\n",
> + len, sas.sas_assoc_id);
> +
> + if (copy_to_user(optval, &sas, len))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> SCTP_STATIC int sctp_getsockopt(struct sock *sk, int level, int optname,
> char __user *optval, int __user *optlen)
> {
> @@ -5773,6 +5837,9 @@ SCTP_STATIC int sctp_getsockopt(struct sock *sk, int level, int optname,
> case SCTP_PEER_ADDR_THLDS:
> retval = sctp_getsockopt_paddr_thresholds(sk, optval, len, optlen);
> break;
> + case SCTP_GET_ASSOC_STATS:
> + retval = sctp_getsockopt_assoc_stats(sk, len, optval, optlen);
> + break;
> default:
> retval = -ENOPROTOOPT;
> break;
> diff --git a/net/sctp/transport.c b/net/sctp/transport.c
> index 953c21e..dd20f6f 100644
> --- a/net/sctp/transport.c
> +++ b/net/sctp/transport.c
> @@ -350,6 +350,7 @@ void sctp_transport_update_rto(struct sctp_transport *tp, __u32 rtt)
>
> /* 6.3.1 C3) After the computation, update RTO <- SRTT + 4 * RTTVAR. */
> tp->rto = tp->srtt + (tp->rttvar << 2);
> + SCTP_MAX_RTO(tp->asoc, tp);
>
> /* 6.3.1 C6) Whenever RTO is computed, if it is less than RTO.Min
> * seconds then it is rounded up to RTO.Min seconds.
> @@ -620,6 +621,7 @@ void sctp_transport_reset(struct sctp_transport *t)
> t->burst_limited = 0;
> t->ssthresh = asoc->peer.i.a_rwnd;
> t->rto = asoc->rto_initial;
> + SCTP_MAX_RTO(asoc, t);
> t->rtt = 0;
> t->srtt = 0;
> t->rttvar = 0;
>
^ permalink raw reply
* RE: [RFC PATCH 1/2] net: Add support for hardware-offloaded encapsulation
From: Gasparakis, Joseph @ 2012-10-26 19:54 UTC (permalink / raw)
To: Ben Hutchings, Stephen Hemminger
Cc: davem@davemloft.net, chrisw@sous-sol.org, netdev@vger.kernel.org,
Waskiewicz Jr, Peter P
In-Reply-To: <1351203635.2662.73.camel@bwh-desktop.uk.solarflarecom.com>
Stephen, are you happy with Ben's comment?
If that is the case I would prefer to keep the patch as is as I believe it makes sense to group the features that way.
-----Original Message-----
From: Ben Hutchings [mailto:bhutchings@solarflare.com]
Sent: Thursday, October 25, 2012 3:21 PM
To: Stephen Hemminger
Cc: Gasparakis, Joseph; davem@davemloft.net; chrisw@sous-sol.org; netdev@vger.kernel.org; Waskiewicz Jr, Peter P
Subject: Re: [RFC PATCH 1/2] net: Add support for hardware-offloaded encapsulation
On Thu, 2012-10-25 at 14:16 -0700, Stephen Hemminger wrote:
> On Thu, 25 Oct 2012 11:29:12 -0700
> Joseph Gasparakis <joseph.gasparakis@intel.com> wrote:
>
> > @@ -19,6 +19,7 @@ enum {
> > NETIF_F_IP_CSUM_BIT, /* Can checksum TCP/UDP over IPv4. */
> > __UNUSED_NETIF_F_1,
> > NETIF_F_HW_CSUM_BIT, /* Can checksum all the packets. */
> > + NETIF_F_HW_CSUM_ENC_BIT, /* Can checksum all inner headers */
> > NETIF_F_IPV6_CSUM_BIT, /* Can checksum TCP/UDP over IPV6 */
> > NETIF_F_HIGHDMA_BIT, /* Can DMA to high memory. */
> > NETIF_F_FRAGLIST_BIT, /* Scatter/gather IO. */
> > @@ -52,6 +53,8 @@ enum {
> > NETIF_F_NTUPLE_BIT, /* N-tuple filters supported */
> > NETIF_F_RXHASH_BIT, /* Receive hashing offload */
> > NETIF_F_RXCSUM_BIT, /* Receive checksumming offload */
> > + NETIF_F_RXCSUM_ENC_BIT, /* Receive checksuming offload */
> > + /* for encapsulation */
> > NETIF_F_NOCACHE_COPY_BIT, /* Use no-cache copyfromuser */
> > NETIF_F_LOOPBACK_BIT, /* Enable loopback */
> > NETIF_F_RXFCS_BIT, /* Append FCS to skb pkt data */
>
> Add new features at the end, or reuse __UNUSED_ bits to avoid any
> issues with binary compatibility. I don't think these bits are in any
> userspace API, maybe ethtool?
There should be no binary compatibility issue here as feature bits are meant to be looked up by name at run-time.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] dlink: dl2k: use the module_pci_driver macro
From: Devendra Naga @ 2012-10-26 19:29 UTC (permalink / raw)
To: Francois Romieu, netdev; +Cc: Devendra Naga
use the module_pci_driver macro to make the code simpler
by eliminating module_init and module_exit calls.
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
drivers/net/ethernet/dlink/dl2k.c | 16 +---------------
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/dlink/dl2k.c b/drivers/net/ethernet/dlink/dl2k.c
index a059f0c..2fb01bf 100644
--- a/drivers/net/ethernet/dlink/dl2k.c
+++ b/drivers/net/ethernet/dlink/dl2k.c
@@ -1758,21 +1758,7 @@ static struct pci_driver rio_driver = {
.remove = __devexit_p(rio_remove1),
};
-static int __init
-rio_init (void)
-{
- return pci_register_driver(&rio_driver);
-}
-
-static void __exit
-rio_exit (void)
-{
- pci_unregister_driver (&rio_driver);
-}
-
-module_init (rio_init);
-module_exit (rio_exit);
-
+module_pci_driver(rio_driver);
/*
Compile command:
--
1.7.9.5
^ permalink raw reply related
* [PATCH] realtek: r8169: use module_pci_driver macro
From: Devendra Naga @ 2012-10-26 19:27 UTC (permalink / raw)
To: Francois Romieu, netdev; +Cc: Devendra Naga
use the module_pci_driver macro to make the code simpler
by eliminating the module_init and module_exit calls
Signed-off-by: Devendra Naga <devendra.aaru@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 2317b8c..123c6a5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7023,15 +7023,4 @@ static struct pci_driver rtl8169_pci_driver = {
.driver.pm = RTL8169_PM_OPS,
};
-static int __init rtl8169_init_module(void)
-{
- return pci_register_driver(&rtl8169_pci_driver);
-}
-
-static void __exit rtl8169_cleanup_module(void)
-{
- pci_unregister_driver(&rtl8169_pci_driver);
-}
-
-module_init(rtl8169_init_module);
-module_exit(rtl8169_cleanup_module);
+module_pci_driver(rtl8169_pci_driver);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next] sctp: support per-association stats via a new SCTP_GET_ASSOC_STATS call
From: Vlad Yasevich @ 2012-10-26 19:16 UTC (permalink / raw)
To: Neil Horman
Cc: Michele Baldessari, linux-sctp, David S. Miller, netdev,
Thomas Graf
In-Reply-To: <20121026143704.GC25087@hmsreliant.think-freely.org>
On 10/26/2012 10:37 AM, Neil Horman wrote:
> On Fri, Oct 26, 2012 at 03:42:53PM +0200, Michele Baldessari wrote:
>> The current SCTP stack is lacking an API to have per association
>> statistics. This is a kernel implementation modeled after OpenSolaris'
>> SCTP_GET_ASSOC_STATS.
>>
>> Userspace part will follow on lksctp if/when there is a general ACK on this.
>>
>> Signed-off-by: Michele Baldessari <michele@acksyn.org>
>> Acked-by: Thomas Graf <tgraf@suug.ch>
>> ---
>> include/net/sctp/sctp.h | 3 +++
>> include/net/sctp/structs.h | 39 +++++++++++++++++++++++++++
>> include/net/sctp/user.h | 26 ++++++++++++++++++
>> net/sctp/associola.c | 20 ++++++++++++++
>> net/sctp/endpointola.c | 5 +++-
>> net/sctp/input.c | 5 ++--
>> net/sctp/output.c | 5 ++++
>> net/sctp/outqueue.c | 12 +++++++++
>> net/sctp/sm_sideeffect.c | 2 ++
>> net/sctp/sm_statefuns.c | 12 +++++++--
>> net/sctp/socket.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++
>> net/sctp/transport.c | 2 ++
>> 12 files changed, 193 insertions(+), 5 deletions(-)
>>
> We already have files in /proc/net/sctp to count snmp system-wide totals,
> per-endpoint totals, and per association totals. Why do these stats differently
> instead of just adding them the per-association file? I get that solaris does
> this, but its not codified in any of the RFC's or other standards. I would
> really rather see something like this go into the interfaces we have, rather
> than creating a new one.
>
> I also am a bit confused regarding the stats themselves. Most are fairly clear,
> but some seem lacking (you count most things sent and received, but only count
> received gap acks). Others seems vague and or confusing (when counting
> retransmitted chunks and packets, how do you count a packet that has both new
> and retransmitted chunks)? And the max observed rto stat is just odd. Each
> transport has an rto value, not each association, and you cal already see the
> individual transport rto values in /proc/net/sctp/remaddr.
>
>
>> +
>> + /* Gap Ack Blocks received */
>> + __u64 gapcnt;
>> +
> No gapcnt for sent gap ack blocks?
>
>> unsigned long timeout;
>> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
>> index 1b4a7f8..569ee3a 100644
>> --- a/net/sctp/outqueue.c
>> +++ b/net/sctp/outqueue.c
>> @@ -667,6 +667,8 @@ redo:
>> chunk->fast_retransmit = SCTP_DONT_FRTX;
>>
>> q->empty = 0;
>> + if (q->asoc)
>> + q->asoc->rtxchunks++;
>> break;
>> }
>>
>> @@ -678,6 +680,10 @@ redo:
>> break;
>> }
>>
>> + if (q->asoc)
>> + q->asoc->rtxpackets++;
>> +
>> +
> This seems incorrect to me. The packet being assembled here may have new chunks
> in it (either control or data). Counting a packet as being retransmitted just
> because it has a retransmitted chunk in it seems wrong. At the very least its a
> misleading/vague statistic.
Agreed
-vlad
>> break;
>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>> index b6adef8..4f94432 100644
>> --- a/net/sctp/sm_statefuns.c
>> +++ b/net/sctp/sm_statefuns.c
>> @@ -6127,9 +6127,13 @@ static int sctp_eat_data(const struct sctp_association *asoc,
>> /* The TSN is too high--silently discard the chunk and
>> * count on it getting retransmitted later.
>> */
>> + if (chunk->asoc)
>> + chunk->asoc->outseqtsns++;
> This just seems wrong. The definition states that this is counting the last TSN
> recevied (despite being name outseqtsns), yet this looks like you're:
> 1) just incrementing a counter, rather than recording the TSN value itself
> (which may or may not be what you meant, but seems to contradict what the
> comments at the definition)
> 2) Only incremanting it if the TSN is out of range, which makes very little
> sense to me.
>
>>
^ permalink raw reply
* Re: [PATCH v2] sctp: Clean up type-punning in sctp_cmd_t union
From: Vlad Yasevich @ 2012-10-26 19:12 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <1351258876-32078-1-git-send-email-nhorman@tuxdriver.com>
On 10/26/2012 09:41 AM, Neil Horman wrote:
> Lots of points in the sctp_cmd_interpreter function treat the sctp_cmd_t arg as
> a void pointer, even though they are written as various other types. Theres no
> need for this as doing so just leads to possible type-punning issues that could
> cause crashes, and if we remain type-consistent we can actually just remove the
> void * member of the union entirely.
>
> Change Notes:
>
> v2)
> * Dropped chunk that modified SCTP_NULL to create a marker pattern
> should anyone try to use a SCTP_NULL() assigned sctp_arg_t, Assigning
> to .zero provides the same effect and should be faster, per Vlad Y.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com
> CC: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> CC: "David S. Miller" <davem@davemloft.net>
> CC: linux-sctp@vger.kernel.org
> ---
> include/net/sctp/command.h | 4 +---
> include/net/sctp/ulpqueue.h | 2 +-
> net/sctp/sm_sideeffect.c | 45 ++++++++++++++++++++++-----------------------
> net/sctp/ulpqueue.c | 3 +--
> 4 files changed, 25 insertions(+), 29 deletions(-)
>
> diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
> index 712b3be..8d52cd7 100644
> --- a/include/net/sctp/command.h
> +++ b/include/net/sctp/command.h
> @@ -131,7 +131,6 @@ typedef union {
> sctp_state_t state;
> sctp_event_timeout_t to;
> unsigned long zero;
> - void *ptr;
> struct sctp_chunk *chunk;
> struct sctp_association *asoc;
> struct sctp_transport *transport;
> @@ -156,7 +155,7 @@ typedef union {
> */
> static inline sctp_arg_t SCTP_NULL(void)
> {
> - sctp_arg_t retval; retval.ptr = NULL; return retval;
> + sctp_arg_t retval = { .zero = 0UL}; return retval;
> }
> static inline sctp_arg_t SCTP_NOFORCE(void)
> {
> @@ -181,7 +180,6 @@ SCTP_ARG_CONSTRUCTOR(ERROR, int, error)
> SCTP_ARG_CONSTRUCTOR(PERR, __be16, err) /* protocol error */
> SCTP_ARG_CONSTRUCTOR(STATE, sctp_state_t, state)
> SCTP_ARG_CONSTRUCTOR(TO, sctp_event_timeout_t, to)
> -SCTP_ARG_CONSTRUCTOR(PTR, void *, ptr)
> SCTP_ARG_CONSTRUCTOR(CHUNK, struct sctp_chunk *, chunk)
> SCTP_ARG_CONSTRUCTOR(ASOC, struct sctp_association *, asoc)
> SCTP_ARG_CONSTRUCTOR(TRANSPORT, struct sctp_transport *, transport)
> diff --git a/include/net/sctp/ulpqueue.h b/include/net/sctp/ulpqueue.h
> index 2e5ee0d..ff1b8ba7 100644
> --- a/include/net/sctp/ulpqueue.h
> +++ b/include/net/sctp/ulpqueue.h
> @@ -72,7 +72,7 @@ int sctp_ulpq_tail_event(struct sctp_ulpq *, struct sctp_ulpevent *ev);
> void sctp_ulpq_renege(struct sctp_ulpq *, struct sctp_chunk *, gfp_t);
>
> /* Perform partial delivery. */
> -void sctp_ulpq_partial_delivery(struct sctp_ulpq *, struct sctp_chunk *, gfp_t);
> +void sctp_ulpq_partial_delivery(struct sctp_ulpq *, gfp_t);
>
> /* Abort the partial delivery. */
> void sctp_ulpq_abort_pd(struct sctp_ulpq *, gfp_t);
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index 6773d78..6eecf7e 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -1268,14 +1268,14 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> sctp_outq_uncork(&asoc->outqueue);
> local_cork = 0;
> }
> - asoc = cmd->obj.ptr;
> + asoc = cmd->obj.asoc;
> /* Register with the endpoint. */
> sctp_endpoint_add_asoc(ep, asoc);
> sctp_hash_established(asoc);
> break;
>
> case SCTP_CMD_UPDATE_ASSOC:
> - sctp_assoc_update(asoc, cmd->obj.ptr);
> + sctp_assoc_update(asoc, cmd->obj.asoc);
> break;
>
> case SCTP_CMD_PURGE_OUTQUEUE:
> @@ -1315,7 +1315,7 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> break;
>
> case SCTP_CMD_PROCESS_FWDTSN:
> - sctp_cmd_process_fwdtsn(&asoc->ulpq, cmd->obj.ptr);
> + sctp_cmd_process_fwdtsn(&asoc->ulpq, cmd->obj.chunk);
> break;
>
> case SCTP_CMD_GEN_SACK:
> @@ -1331,7 +1331,7 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> case SCTP_CMD_PROCESS_SACK:
> /* Process an inbound SACK. */
> error = sctp_cmd_process_sack(commands, asoc,
> - cmd->obj.ptr);
> + cmd->obj.chunk);
> break;
>
> case SCTP_CMD_GEN_INIT_ACK:
> @@ -1352,15 +1352,15 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> * layer which will bail.
> */
> error = sctp_cmd_process_init(commands, asoc, chunk,
> - cmd->obj.ptr, gfp);
> + cmd->obj.init, gfp);
> break;
>
> case SCTP_CMD_GEN_COOKIE_ECHO:
> /* Generate a COOKIE ECHO chunk. */
> new_obj = sctp_make_cookie_echo(asoc, chunk);
> if (!new_obj) {
> - if (cmd->obj.ptr)
> - sctp_chunk_free(cmd->obj.ptr);
> + if (cmd->obj.chunk)
> + sctp_chunk_free(cmd->obj.chunk);
> goto nomem;
> }
> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> @@ -1369,9 +1369,9 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> /* If there is an ERROR chunk to be sent along with
> * the COOKIE_ECHO, send it, too.
> */
> - if (cmd->obj.ptr)
> + if (cmd->obj.chunk)
> sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> - SCTP_CHUNK(cmd->obj.ptr));
> + SCTP_CHUNK(cmd->obj.chunk));
>
> if (new_obj->transport) {
> new_obj->transport->init_sent_count++;
> @@ -1417,18 +1417,18 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> case SCTP_CMD_CHUNK_ULP:
> /* Send a chunk to the sockets layer. */
> SCTP_DEBUG_PRINTK("sm_sideff: %s %p, %s %p.\n",
> - "chunk_up:", cmd->obj.ptr,
> + "chunk_up:", cmd->obj.chunk,
> "ulpq:", &asoc->ulpq);
> - sctp_ulpq_tail_data(&asoc->ulpq, cmd->obj.ptr,
> + sctp_ulpq_tail_data(&asoc->ulpq, cmd->obj.chunk,
> GFP_ATOMIC);
> break;
>
> case SCTP_CMD_EVENT_ULP:
> /* Send a notification to the sockets layer. */
> SCTP_DEBUG_PRINTK("sm_sideff: %s %p, %s %p.\n",
> - "event_up:",cmd->obj.ptr,
> + "event_up:",cmd->obj.ulpevent,
> "ulpq:",&asoc->ulpq);
> - sctp_ulpq_tail_event(&asoc->ulpq, cmd->obj.ptr);
> + sctp_ulpq_tail_event(&asoc->ulpq, cmd->obj.ulpevent);
> break;
>
> case SCTP_CMD_REPLY:
> @@ -1438,12 +1438,12 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> local_cork = 1;
> }
> /* Send a chunk to our peer. */
> - error = sctp_outq_tail(&asoc->outqueue, cmd->obj.ptr);
> + error = sctp_outq_tail(&asoc->outqueue, cmd->obj.chunk);
> break;
>
> case SCTP_CMD_SEND_PKT:
> /* Send a full packet to our peer. */
> - packet = cmd->obj.ptr;
> + packet = cmd->obj.packet;
> sctp_packet_transmit(packet);
> sctp_ootb_pkt_free(packet);
> break;
> @@ -1480,7 +1480,7 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> break;
>
> case SCTP_CMD_SETUP_T2:
> - sctp_cmd_setup_t2(commands, asoc, cmd->obj.ptr);
> + sctp_cmd_setup_t2(commands, asoc, cmd->obj.chunk);
> break;
>
> case SCTP_CMD_TIMER_START_ONCE:
> @@ -1514,7 +1514,7 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> break;
>
> case SCTP_CMD_INIT_CHOOSE_TRANSPORT:
> - chunk = cmd->obj.ptr;
> + chunk = cmd->obj.chunk;
> t = sctp_assoc_choose_alter_transport(asoc,
> asoc->init_last_sent_to);
> asoc->init_last_sent_to = t;
> @@ -1665,17 +1665,16 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> break;
>
> case SCTP_CMD_PART_DELIVER:
> - sctp_ulpq_partial_delivery(&asoc->ulpq, cmd->obj.ptr,
> - GFP_ATOMIC);
> + sctp_ulpq_partial_delivery(&asoc->ulpq, GFP_ATOMIC);
> break;
>
> case SCTP_CMD_RENEGE:
> - sctp_ulpq_renege(&asoc->ulpq, cmd->obj.ptr,
> + sctp_ulpq_renege(&asoc->ulpq, cmd->obj.chunk,
> GFP_ATOMIC);
> break;
>
> case SCTP_CMD_SETUP_T4:
> - sctp_cmd_setup_t4(commands, asoc, cmd->obj.ptr);
> + sctp_cmd_setup_t4(commands, asoc, cmd->obj.chunk);
> break;
>
> case SCTP_CMD_PROCESS_OPERR:
> @@ -1734,8 +1733,8 @@ static int sctp_cmd_interpreter(sctp_event_t event_type,
> break;
>
> default:
> - pr_warn("Impossible command: %u, %p\n",
> - cmd->verb, cmd->obj.ptr);
> + pr_warn("Impossible command: %u\n",
> + cmd->verb);
> break;
> }
>
> diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
> index 360d869..ada1746 100644
> --- a/net/sctp/ulpqueue.c
> +++ b/net/sctp/ulpqueue.c
> @@ -997,7 +997,6 @@ static __u16 sctp_ulpq_renege_frags(struct sctp_ulpq *ulpq, __u16 needed)
>
> /* Partial deliver the first message as there is pressure on rwnd. */
> void sctp_ulpq_partial_delivery(struct sctp_ulpq *ulpq,
> - struct sctp_chunk *chunk,
> gfp_t gfp)
> {
> struct sctp_ulpevent *event;
> @@ -1060,7 +1059,7 @@ void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
> sctp_tsnmap_mark(&asoc->peer.tsn_map, tsn, chunk->transport);
> sctp_ulpq_tail_data(ulpq, chunk, gfp);
>
> - sctp_ulpq_partial_delivery(ulpq, chunk, gfp);
> + sctp_ulpq_partial_delivery(ulpq, gfp);
> }
>
> sk_mem_reclaim(asoc->base.sk);
>
^ permalink raw reply
* Re: [PATCH] sctp: Clean up type-punning in sctp_cmd_t union
From: Vlad Yasevich @ 2012-10-26 19:12 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller, linux-sctp
In-Reply-To: <20121026132422.GA25087@hmsreliant.think-freely.org>
On 10/26/2012 09:24 AM, Neil Horman wrote:
> On Thu, Oct 25, 2012 at 11:48:16PM -0400, Vlad Yasevich wrote:
>> On 10/25/2012 07:58 PM, Neil Horman wrote:
>>> On Thu, Oct 25, 2012 at 05:42:15PM -0400, Vlad Yasevich wrote:
>>>> On 10/25/2012 04:47 PM, Neil Horman wrote:
>>>>> Lots of points in the sctp_cmd_interpreter function treat the sctp_cmd_t arg as
>>>>> a void pointer, even though they are written as various other types. Theres no
>>>>> need for this as doing so just leads to possible type-punning issues that could
>>>>> cause crashes, and if we remain type-consistent we can actually just remove the
>>>>> void * member of the union entirely.
>>>>>
>>>>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com
>>>>> CC: Vlad Yasevich <vyasevich@gmail.com>
>>>>> CC: "David S. Miller" <davem@davemloft.net>
>>>>> CC: linux-sctp@vger.kernel.org
>>>>> ---
>>>>> include/net/sctp/command.h | 7 ++++---
>>>>> include/net/sctp/ulpqueue.h | 2 +-
>>>>> net/sctp/sm_sideeffect.c | 45 ++++++++++++++++++++++-----------------------
>>>>> net/sctp/ulpqueue.c | 3 +--
>>>>> 4 files changed, 28 insertions(+), 29 deletions(-)
>>>>>
>>>>> diff --git a/include/net/sctp/command.h b/include/net/sctp/command.h
>>>>> index 712b3be..7f1b0f3 100644
>>>>> --- a/include/net/sctp/command.h
>>>>> +++ b/include/net/sctp/command.h
>>>>> @@ -131,7 +131,6 @@ typedef union {
>>>>> sctp_state_t state;
>>>>> sctp_event_timeout_t to;
>>>>> unsigned long zero;
>>>>> - void *ptr;
>>>>> struct sctp_chunk *chunk;
>>>>> struct sctp_association *asoc;
>>>>> struct sctp_transport *transport;
>>>>> @@ -154,9 +153,12 @@ typedef union {
>>>>> * which takes an __s32 and returns a sctp_arg_t containing the
>>>>> * __s32. So, after foo = SCTP_I32(arg), foo.i32 == arg.
>>>>> */
>>>>> +#define SCTP_NULL_BYTE 0xAA
>>>>> static inline sctp_arg_t SCTP_NULL(void)
>>>>> {
>>>>> - sctp_arg_t retval; retval.ptr = NULL; return retval;
>>>>> + sctp_arg_t retval;
>>>>> + memset(&retval, SCTP_NULL_BYTE, sizeof(sctp_arg_t));
>>>>> + return retval;
>>>>
>>>> What's this for? Can't we just use retval.zero?
>>>>
>>>> -vlad
>>>>
>>> My intent was to highlight any users of sctp_arg_t when SCTP_NULL was passed.
>>> My thinking was that the 0xAA byte patern would be a good indicator. Although,
>>> admittedly I didn't see the zero argument there. Looking at it though, the zero
>>> member of the union is effectively unused. Strictly speaking its used for
>>> initalization of sctp_arg_t, but its done somewhat poorly, since theres no
>>> guarantee that an unsigned long will be the largest member of that union. Doing
>>> the memset guarantees the whole instance is set to a predefined value.
>>>
>>> I could go either way with this, would you rather we just have SCTP_NULL return
>>> retval = { .zero = 0}; or would you rather remove the zero initialization from
>>> SCTP_[NO]FORCE, and SCTP_ARG_CONSTRUCTOR and do the memset. I think the memset
>>> reduces to a single 64 bit assignment as long as the union doesn't exceed that
>>> size anyway, and it ensures that you initalize the whole union's storage if it
>>> does in the future. And if we remove the initialization step (I don't see that
>>> its needed in the three macros above anyway), then we can remove the zero member
>>> as well.
>>>
>>
>> You need the initialization step, otherwise things might fail (they
>> did on IA64 a while back). That's why the zero member was added.
>> You can go with memset if you want, but I was primarily wondering
>> why the 0xAA pattern was there.
>>
> The AA I did was just meant as a pattern marker, so that, should someone use an
> instance of sctp_arg_t that was passed in as SCTP_NULL(), it would be visually
> obvious in the stack trace, but I suppose its not really needed given that NULL
> is equally clear. And since Dave pointed out the lack of optimization
> opportunity when using a store to an address rather than a register, I think I
> should probably just revert it and use zero as you initially suggested.
>
> The need for the initalization in SCTP_[NO]FORCE and SCTP_ARG_CONSTRUCTOR
> concerns me though. All its doing is setting part of the storage to zero, and
> then overwriting it again with whatever type spcific member you're assigning
> from the corresponding SCTP_* macro. That kind of sounds to me like ia64 might
> have fallen to some amount of type-punning problem. do you have a link to
> discussion about that problem?
>
Look at commit 19c7e9ee that introduced this. I don't remember all the
details any more, but the problem only occurred on ia64 (probably due
its speculative load handling).
-vlad
> Regards
> Neil
>
>> -vlad
>>> Let me know what you want to do here, and I can respin this.
>>> Best
>>> Neil
>>>
>>
>>
^ permalink raw reply
* Re: pull request: wireless 2012-10-26
From: David Miller @ 2012-10-26 19:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20121026152112.GB16104@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 26 Oct 2012 11:21:13 -0400
> This is a batch of fixes intended for the 3.7 stream.
>
> Bing Zhao brings two mwifiex fixes, both continuing to fix some scanning
> failure cases.
>
> Christian Lamparter provides an rtlwifi fix to properly propogate an
> error code.
>
> Felix Fietkau reverts a previous fix that was improperly reducing Tx
> power for some devices. This one looks big, but it is mostly just
> changes to a table of initialization values.
>
> Larry Finger provides a b43 version of an earlier b43legacy fix to
> avoid and oops when removing the modules after failing to load firmware.
>
> Mohammed Shafi Shajakhan provides a new device ID for ath9k_htc.
>
> Stanislaw Gruszka gives us an rt2x00 fix to avoide a WARNING during
> resume, as described in kernel.org bug 48041.
>
> Yuanhan Liu fixes a potential NULL dereference in brcmfmac.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net-next] sk-filter: Add ability to get socket filter program
From: David Miller @ 2012-10-26 19:04 UTC (permalink / raw)
To: danborkmann; +Cc: xemul, netdev
In-Reply-To: <CAD6jFUS9LBtJ20Ty=3LTJNMxb0UhyCxRiAg+T7BUeXGEswpkUQ@mail.gmail.com>
From: Daniel Borkmann <danborkmann@iogearbox.net>
Date: Fri, 26 Oct 2012 20:07:13 +0200
> In your commit message, you address how you implement it, but not
> where it could be useful (or ``why one needs it''). For instance, in a
> simple case, you have a packet sniffer that uses PF_PACKET, sets up a
> socket filter and RX_RING, then you start looking at packets and at
> some point you stop and close everything. In which scenario would I
> (ever) call this getsockopt()? (Is it just for the sake for having a
> missing getter-function?)
Everything Pavel is working on is for checkpoint/restart.
^ permalink raw reply
* Re: [PATCH v2 0/9] net/macb: driver enhancement concerning GEM support, ring logic and cleanup
From: David Miller @ 2012-10-26 18:59 UTC (permalink / raw)
To: nicolas.ferre
Cc: manabian, netdev, havard, bhutchings, linux-arm-kernel, plagnioj,
patrice.vilchez, linux-kernel
In-Reply-To: <508AAB54.9010506@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Fri, 26 Oct 2012 17:25:08 +0200
> David,
>
> On 09/19/2012 01:55 PM, Nicolas Ferre :
>> This is an enhancement work that began several years ago. I try to catchup with
>> some performance improvement that has been implemented then by Havard.
>> The ring index logic and the TX error path modification are the biggest changes
>> but some cleanup/debugging have been added along the way.
>> The GEM revision will benefit from the Gigabit support.
>>
>> The series has been tested on several Atmel AT91 SoC with the two MACB/GEM
>> flavors.
>>
>> v2: - modify the tx error handling: now uses a workqueue
>> - information provided by ethtool -i were not accurate: removed
>
> I am about to re-send this patch series. Should I rebase it on top of
> Joachim's recent modifications? I mean, I plan to rebase them on top of
> net-next, is it the proper thing to do?
You should always base your patch on whatever tree you want your patches
applied to.
If you have a dependency on something not in that tree (for example, you
need something in the 'net' tree) you have to tell me.
^ permalink raw reply
* Re: [PATCH 0/8] IPVS updates for net-next tree
From: David Miller @ 2012-10-26 18:50 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1351243478-4852-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Fri, 26 Oct 2012 11:24:30 +0200
> The following changeset contains updates for IPVS from Jesper Dangaard
> Brouer that did not reach the previous merge window in time.
>
> More specifically, updates to improve IPv6 support in IPVS. More
> relevantly, some of the existing code performed wrong handling of the
> extensions headers and better fragmentation handling.
>
> Jesper promised more follow-up patches to refine this after this batch
> hits net-next. Yet to come.
>
> You can pull these changes from:
>
> git://1984.lsi.us.es/nf-next master
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] tilegx: fix some issues in the SW TSO support
From: Chris Metcalf @ 2012-10-26 18:17 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, linux-kernel
In-Reply-To: <1351194525.2662.21.camel@bwh-desktop.uk.solarflarecom.com>
On 10/25/2012 3:48 PM, Ben Hutchings wrote:
> On Thu, 2012-10-25 at 20:36 +0100, Ben Hutchings wrote:
> [...]
>> There's a simple way to test this - configure the 'attacker' host and
>> interface like this:
>>
>> # ip link set $IFACE mtu 128
>> # sysctl net.ipv4.route.min_adv_mss=88
>>
>> and then use something like netperf to generate a high bandwidth stream
>> of TCP traffic toward it from the tilegx interface.
> Also you would need to run some other traffic in parallel (multiple
> streams to the 'attacker' and some more normal streams) to ensure there
> is real contention.
Thanks! I've filed a bugzilla within Tilera to come back and revisit this
- I think it's not a short-term problem so we'll find some time to look at
it in the future. Or, someone reading this could try it themselves and
submit the patch :-)
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply
* Re: [PATCH net-next] sk-filter: Add ability to get socket filter program
From: Daniel Borkmann @ 2012-10-26 18:07 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Linux Netdev List, David Miller
In-Reply-To: <508AC533.4000809@parallels.com>
On Fri, Oct 26, 2012 at 7:15 PM, Pavel Emelyanov <xemul@parallels.com> wrote:
> The SO_ATTACH_FILTER option is set only. I propose to add the get
> ability by using SO_ATTACH_FILTER in getsockopt. To be less irritating
> to eyes the SO_GET_FILTER alias to it is declared.
>
> There are two issues with getting filter back.
>
> First, kernel modifies the sock_filter->code on filter load, thus in
> order to return the filter element back to user we have to decode it
> into user-visible constants. Fortunately the modification in question
> is interconvertible.
>
> Second, the BPF_S_ALU_DIV_K code modifies the command argument k to
> speed up the run-time division by doing kernel_k = reciprocal(user_k).
> Bad news is that different user_k may result in same kernel_k, so we
> can't get the original user_k back. Good news is that we don't have
> to do it. What we need to is calculate a user2_k so, that
>
> reciprocal(user2_k) == reciprocal(user_k) == kernel_k
>
> i.e. if it's re-loaded back the compiled again value will be exactly
> the same as it was. That said, the user2_k can be calculated like this
>
> user2_k = reciprocal(kernel_k)
>
> with an exception, that if kernel_k == 0, then user2_k == 1.
>
> The optlen argument is treated like this -- when zero, kernel returns
> the amount of sock_fprog elements in filter, otherwise it should be
> large enough for the sock_fprog array.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
In your commit message, you address how you implement it, but not
where it could be useful (or ``why one needs it''). For instance, in a
simple case, you have a packet sniffer that uses PF_PACKET, sets up a
socket filter and RX_RING, then you start looking at packets and at
some point you stop and close everything. In which scenario would I
(ever) call this getsockopt()? (Is it just for the sake for having a
missing getter-function?)
^ permalink raw reply
* [PATCH net-next] netxen: explicity handle pause autoneg parameter
From: Flavio Leitner @ 2012-10-26 17:17 UTC (permalink / raw)
To: netdev; +Cc: Sony Chacko, Rajesh Borundia, Flavio Leitner
The hardware doesn't support controlling pause frames autoneg, so
report that back correctly to userspace.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c | 6 ++++++
1 file changed, 6 insertions(+)
I don't have the hardware handy to test this, so I appreciate
if someone could do it.
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index 10468e7..b4b46f9 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -488,6 +488,8 @@ netxen_nic_get_pauseparam(struct net_device *dev,
__u32 val;
int port = adapter->physical_port;
+ pause->autoneg = AUTONEG_DISABLE;
+
if (adapter->ahw.port_type == NETXEN_NIC_GBE) {
if ((port < 0) || (port >= NETXEN_NIU_MAX_GBE_PORTS))
return;
@@ -532,6 +534,10 @@ netxen_nic_set_pauseparam(struct net_device *dev,
struct netxen_adapter *adapter = netdev_priv(dev);
__u32 val;
int port = adapter->physical_port;
+
+ if (pause->autoneg)
+ return -EOPNOTSUPP;
+
/* read mode */
if (adapter->ahw.port_type == NETXEN_NIC_GBE) {
if ((port < 0) || (port >= NETXEN_NIU_MAX_GBE_PORTS))
--
1.7.11.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox