* Re: A new 40G Network driver ready to submit to the kernel tree
From: Ben Hutchings @ 2011-10-07 17:33 UTC (permalink / raw)
To: Joyce Yu - System Software; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <4E8F34A1.5020503@oracle.com>
On Fri, 2011-10-07 at 10:19 -0700, Joyce Yu - System Software wrote:
> >
> > Submit the patches to netdev for review/acceptance.
>
> Shall I just send plain driverxxx.c and driverxxx.h files, or zip or
> tarball?
Please read Documentation/Submitting{Patches,Drivers}; then ask any
further questions that they don't answer.
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
* Re: [PATCH] net: use sock_valbool_flag to set/clear SOCK_RXQ_OVFL
From: David Miller @ 2011-10-07 17:27 UTC (permalink / raw)
To: nhorman; +Cc: johannes, netdev
In-Reply-To: <20111007134023.GC11408@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 7 Oct 2011 09:40:23 -0400
> On Fri, Oct 07, 2011 at 03:30:20PM +0200, Johannes Berg wrote:
>> From: Johannes Berg <johannes.berg@intel.com>
>>
>> There's no point in open-coding sock_valbool_flag().
>>
>> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
...
> Looks good, thanks Johannes!
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] IPv6: DAD from bonding iface is treated as dup address from others
From: Neil Horman @ 2011-10-07 17:29 UTC (permalink / raw)
To: Yinglin Sun; +Cc: netdev
In-Reply-To: <CAN17JHVC-qVst1vw5eOC1Wg8ekBejped5WErVo5wCAWTBF9JSw@mail.gmail.com>
On Fri, Oct 07, 2011 at 09:59:06AM -0700, Yinglin Sun wrote:
> On Thu, Oct 6, 2011 at 11:13 PM, Chuck Anderson <cra@wpi.edu> wrote:
> >
> > On Thu, Oct 06, 2011 at 06:24:36PM -0700, Yinglin Sun wrote:
> > > On Thu, Oct 6, 2011 at 5:59 PM, Jay Vosburgh <fubar@us.ibm.com> wrote:
> > > > Why are you setting up the port channel after configuring the
> > > > bond?
> > > >
> > > > As a possible workaround, if you have control over the setup
> > > > process (perhaps it's some sort of manual process), adding one slave to
> > > > the bond, leaving the other soon-to-be slaves down, then setting up the
> > > > switch, and finally adding the remaining slaves should work around the
> > > > issue, since if the bond has only one slave it won't see any looped
> > > > packets.
> > > >
> > > > Or you could bring the bond up as active-backup, then change the
> > > > mode to balance-xor once the switch is configured.
> > > >
> > > > Ultimately, though, the problem stems from the settings mismatch
> > > > between the switch and the bonding system; balance-xor is meant to
> > > > interoperate with etherchannel, and when the switch is not configured
> > > > properly, correct behavior is difficult to guarantee.
> > > >
> > >
> > > Jay,
> > >
> > > Thanks a lot for the suggestion.
> > >
> > > It's mainly about usability. We would like to provide customers with
> > > consistent IPv6 configuration procedures as IPv4. Such workarounds
> > > could be confusing and generate customer calls.
> >
> > You've created/encouraged your customers to create a broken network
> > configuration by connecting two bonded links to a non-bonded,
> > non-etherchannel switch port pair. This type of misconfiguration,
> > when applied to inter-switch trunks, can cause major network issues,
> > like looping and broadcast storms, taking down the entire network
> > unless something like Spanning Tree is enabled to protect against such
> > accidental loops. It should be avoided at all costs. Luckily, if the
> > Linux host in this case is not being used as a switch/bridge, the
> > impact of this might not be so bad--perhaps limited to the IPv6 DAD
> > issue you report.
> >
> > If you want better usability and plug-n-play bonding, then require
> > LACP/802.3ad to be used. Please don't encourage your customers to
> > connect misconfigured devices to the network, thanks.
>
> You are right. LACP is the good choice. It should be able to solve
> this issue, since all LACP bonding slaves are down before port channel
> is set up on switch. Thanks.
>
> I'm not sure this is kind of broken network configuration. If
> customers happen to add some IPv6 addresses on bonding interface
> before setting up port channel on switch, they have to reconfigure all
Bringing up an interface prior to having it, and the peer interfaces configured
to use an agreed upon mode, is rather by definition broken :)
^ permalink raw reply
* Re: Asserting ECN from userspace?
From: Rick Jones @ 2011-10-07 17:25 UTC (permalink / raw)
To: David Täht; +Cc: netdev, bloat-devel
In-Reply-To: <4E8BF6B2.6030101@gmail.com>
On 10/04/2011 11:18 PM, David Täht wrote:
>
> No sooner had I noted (with pleasure) the kernel's new ability to
> correctly set the dscp bits on IPv6 TCP streams without messing with the
> negotiated ECN status, that I found several use cases where being able
> to assert ECN from userspace (for either ipv4, or ipv6) would be useful.
> ...
> 3) Web Proxies. A web proxy could note when it was experiencing
> congestion on one side of the proxied connection (or another) and signal
> the other side to slow down.
> ...
> As for 3... perhaps a grantable network capability? A proxy could
> acquire privs to twiddle those bits before dropping root privs.
For 3, couldn't/shouldn't the proxy simply stop draining the appropriate
socket buffer to cause TCP's existing flow control to slow down that side?
rick jones
^ permalink raw reply
* Re: A new 40G Network driver ready to submit to the kernel tree
From: Joyce Yu - System Software @ 2011-10-07 17:19 UTC (permalink / raw)
To: netdev, jeffrey.t.kirsher
>
> Submit the patches to netdev for review/acceptance.
Shall I just send plain driverxxx.c and driverxxx.h files, or zip or
tarball?
Thanks,
Joyce
^ permalink raw reply
* [RFC] net: add wireless TX status socket option
From: Johannes Berg @ 2011-10-07 17:19 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, Neil Horman
From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
The 802.1X EAPOL handshake hostapd does requires
knowing whether the frame was ack'ed by the peer.
Currently, we fudge this pretty badly by not even
transmitting the frame as a normal data frame but
injecting it with radiotap and getting the status
out of radiotap monitor as well. This is rather
complex, confuses users (mon.wlan0 presence) and
doesn't work with all hardware.
To get rid of that hack, introduce a real wifi TX
status option for data frame transmissions.
This works similar to the existing TX timestamping
in that it reflects the SKB back to the socket's
error queue with a SCM_WIFI_STATUS cmsg that has
an int indicating ACK status (0/1).
Since it is possible that at some point we will
want to have TX timestamping and wifi status in a
single errqueue SKB (there's little point in not
doing that), redefine SO_EE_ORIGIN_TIMESTAMPING
to SO_EE_ORIGIN_TXSTATUS which can collect more
than just the timestamp; keep the old constant
as an alias of course. Currently the internal APIs
don't make that possible, but it wouldn't be hard
to split them up in a way that makes it possible.
Thanks to Neil Horman for helping me figure out
the functions that add the control messages.
TODO:
* sock_tx_timestamp() function should be renamed,
maybe to sock_tx_status()?
* sock_recv_timestamp() should also be renamed,
I had a hard time figuring out the difference
between that and sock_recv_ts_and_drops(). The
former is generic, while the latter adds RX
information only, maybe that should be reflected
in new names?
Signed-off-by: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
arch/alpha/include/asm/socket.h | 3 +++
arch/arm/include/asm/socket.h | 3 +++
arch/avr32/include/asm/socket.h | 3 +++
arch/cris/include/asm/socket.h | 3 +++
arch/frv/include/asm/socket.h | 3 +++
arch/h8300/include/asm/socket.h | 3 +++
arch/ia64/include/asm/socket.h | 3 +++
arch/m32r/include/asm/socket.h | 3 +++
arch/m68k/include/asm/socket.h | 3 +++
arch/mips/include/asm/socket.h | 3 +++
arch/mn10300/include/asm/socket.h | 3 +++
arch/parisc/include/asm/socket.h | 3 +++
arch/powerpc/include/asm/socket.h | 3 +++
arch/s390/include/asm/socket.h | 3 +++
arch/sparc/include/asm/socket.h | 3 +++
arch/xtensa/include/asm/socket.h | 3 +++
include/asm-generic/socket.h | 3 +++
include/linux/errqueue.h | 3 ++-
include/linux/skbuff.h | 18 ++++++++++++++++--
include/net/sock.h | 7 +++++++
net/core/skbuff.c | 20 ++++++++++++++++++++
net/core/sock.c | 9 +++++++++
net/mac80211/status.c | 35 +++++++++++++++++++++++++++--------
net/mac80211/tx.c | 8 +++++++-
net/socket.c | 19 +++++++++++++++++++
25 files changed, 158 insertions(+), 12 deletions(-)
--- a/include/asm-generic/socket.h 2011-10-07 18:59:12.000000000 +0200
+++ b/include/asm-generic/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -64,4 +64,7 @@
#define SO_DOMAIN 39
#define SO_RXQ_OVFL 40
+
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
#endif /* __ASM_GENERIC_SOCKET_H */
--- a/net/core/sock.c 2011-10-07 18:59:12.000000000 +0200
+++ b/net/core/sock.c 2011-10-07 18:59:12.000000000 +0200
@@ -740,6 +740,11 @@ set_rcvbuf:
case SO_RXQ_OVFL:
sock_valbool_flag(sk, SOCK_RXQ_OVFL, valbool);
break;
+
+ case SO_WIFI_STATUS:
+ sock_valbool_flag(sk, SOCK_WIFI_STATUS, valbool);
+ break;
+
default:
ret = -ENOPROTOOPT;
break;
@@ -961,6 +966,10 @@ int sock_getsockopt(struct socket *sock,
v.val = !!sock_flag(sk, SOCK_RXQ_OVFL);
break;
+ case SO_WIFI_STATUS:
+ v.val = !!sock_flag(sk, SOCK_WIFI_STATUS);
+ break;
+
default:
return -ENOPROTOOPT;
}
--- a/include/net/sock.h 2011-10-07 18:59:12.000000000 +0200
+++ b/include/net/sock.h 2011-10-07 18:59:12.000000000 +0200
@@ -564,6 +564,7 @@ enum sock_flags {
SOCK_FASYNC, /* fasync() active */
SOCK_RXQ_OVFL,
SOCK_ZEROCOPY, /* buffers from userspace */
+ SOCK_WIFI_STATUS, /* push wifi status to userspace */
};
static inline void sock_copy_flags(struct sock *nsk, struct sock *osk)
@@ -1705,7 +1706,10 @@ static inline int sock_intr_errno(long t
extern void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
struct sk_buff *skb);
+extern void __sock_recv_wifi_status(struct msghdr *msg, struct sock *sk,
+ struct sk_buff *skb);
+/* XXX: rename this function now? */
static __inline__ void
sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
{
@@ -1732,6 +1736,9 @@ sock_recv_timestamp(struct msghdr *msg,
__sock_recv_timestamp(msg, sk, skb);
else
sk->sk_stamp = kt;
+
+ if (sock_flag(sk, SOCK_WIFI_STATUS) && skb->wifi_acked_valid)
+ __sock_recv_wifi_status(msg, sk, skb);
}
extern void __sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
--- a/arch/alpha/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/alpha/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -69,6 +69,9 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
/* O_NONBLOCK clashes with the bits used for socket types. Therefore we
* have to define SOCK_NONBLOCK to a different value here.
*/
--- a/arch/arm/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/arm/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -62,4 +62,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_SOCKET_H */
--- a/arch/avr32/include/asm/socket.h 2011-10-07 18:59:10.000000000 +0200
+++ b/arch/avr32/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -62,4 +62,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* __ASM_AVR32_SOCKET_H */
--- a/arch/cris/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/cris/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -64,6 +64,9 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_SOCKET_H */
--- a/arch/frv/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/frv/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -62,5 +62,8 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_SOCKET_H */
--- a/arch/h8300/include/asm/socket.h 2011-10-07 18:59:10.000000000 +0200
+++ b/arch/h8300/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -62,4 +62,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_SOCKET_H */
--- a/arch/ia64/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/ia64/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -71,4 +71,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_IA64_SOCKET_H */
--- a/arch/m32r/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/m32r/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -62,4 +62,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_M32R_SOCKET_H */
--- a/arch/m68k/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/m68k/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -62,4 +62,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_SOCKET_H */
--- a/arch/mips/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/mips/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -82,6 +82,9 @@ To add: #define SO_REUSEPORT 0x0200 /* A
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#ifdef __KERNEL__
/** sock_type - Socket types
--- a/arch/mn10300/include/asm/socket.h 2011-10-07 18:59:10.000000000 +0200
+++ b/arch/mn10300/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -62,4 +62,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_SOCKET_H */
--- a/arch/parisc/include/asm/socket.h 2011-10-07 18:59:10.000000000 +0200
+++ b/arch/parisc/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -61,6 +61,9 @@
#define SO_RXQ_OVFL 0x4021
+#define SO_WIFI_STATUS 0x4022
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
/* O_NONBLOCK clashes with the bits used for socket types. Therefore we
* have to define SOCK_NONBLOCK to a different value here.
*/
--- a/arch/powerpc/include/asm/socket.h 2011-10-07 18:59:11.000000000 +0200
+++ b/arch/powerpc/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -69,4 +69,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_POWERPC_SOCKET_H */
--- a/arch/s390/include/asm/socket.h 2011-10-07 18:59:10.000000000 +0200
+++ b/arch/s390/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -70,4 +70,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _ASM_SOCKET_H */
--- a/arch/sparc/include/asm/socket.h 2011-10-07 18:59:10.000000000 +0200
+++ b/arch/sparc/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -58,6 +58,9 @@
#define SO_RXQ_OVFL 0x0024
+#define SO_WIFI_STATUS 0x0025
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
--- a/arch/xtensa/include/asm/socket.h 2011-10-07 18:59:10.000000000 +0200
+++ b/arch/xtensa/include/asm/socket.h 2011-10-07 18:59:12.000000000 +0200
@@ -73,4 +73,7 @@
#define SO_RXQ_OVFL 40
+#define SO_WIFI_STATUS 41
+#define SCM_WIFI_STATUS SO_WIFI_STATUS
+
#endif /* _XTENSA_SOCKET_H */
--- a/include/linux/errqueue.h 2011-10-07 18:59:11.000000000 +0200
+++ b/include/linux/errqueue.h 2011-10-07 18:59:12.000000000 +0200
@@ -17,7 +17,8 @@ struct sock_extended_err {
#define SO_EE_ORIGIN_LOCAL 1
#define SO_EE_ORIGIN_ICMP 2
#define SO_EE_ORIGIN_ICMP6 3
-#define SO_EE_ORIGIN_TIMESTAMPING 4
+#define SO_EE_ORIGIN_TXSTATUS 4
+#define SO_EE_ORIGIN_TIMESTAMPING SO_EE_ORIGIN_TXSTATUS
#define SO_EE_OFFENDER(ee) ((struct sockaddr*)((ee)+1))
--- a/include/linux/skbuff.h 2011-10-07 18:59:11.000000000 +0200
+++ b/include/linux/skbuff.h 2011-10-07 18:59:12.000000000 +0200
@@ -190,6 +190,9 @@ enum {
/* device driver supports TX zero-copy buffers */
SKBTX_DEV_ZEROCOPY = 1 << 4,
+
+ /* generate wifi status information (where possible) */
+ SKBTX_WIFI_STATUS = 1 << 5,
};
/*
@@ -322,6 +325,8 @@ typedef unsigned char *sk_buff_data_t;
* @queue_mapping: Queue mapping for multiqueue devices
* @ndisc_nodetype: router type (from link layer)
* @ooo_okay: allow the mapping of a socket to a queue to be changed
+ * @wifi_acked_valid: wifi_acked was set
+ * @wifi_acked: whether frame was acked on wifi or not
* @dma_cookie: a cookie to one of several possible DMA operations
* done by skb DMA functions
* @secmark: security marking
@@ -414,10 +419,10 @@ struct sk_buff {
__u8 ndisc_nodetype:2;
#endif
__u8 ooo_okay:1;
+ __u8 wifi_acked_valid:1;
+ __u8 wifi_acked:1;
kmemcheck_bitfield_end(flags2);
- /* 0/13 bit hole */
-
#ifdef CONFIG_NET_DMA
dma_cookie_t dma_cookie;
#endif
@@ -2062,6 +2067,15 @@ static inline void skb_tx_timestamp(stru
sw_tx_timestamp(skb);
}
+/**
+ * skb_complete_wifi_ack - deliver cloned skb with wifi status
+ *
+ * @skb: clone of the the original outgoing packet
+ * @acked: ack status
+ *
+ */
+void skb_complete_wifi_ack(struct sk_buff *skb, bool acked);
+
extern __sum16 __skb_checksum_complete_head(struct sk_buff *skb, int len);
extern __sum16 __skb_checksum_complete(struct sk_buff *skb);
--- a/net/core/skbuff.c 2011-10-07 18:59:12.000000000 +0200
+++ b/net/core/skbuff.c 2011-10-07 18:59:24.000000000 +0200
@@ -3150,6 +3150,26 @@ void skb_tstamp_tx(struct sk_buff *orig_
}
EXPORT_SYMBOL_GPL(skb_tstamp_tx);
+void skb_complete_wifi_ack(struct sk_buff *skb, bool acked)
+{
+ struct sock *sk = skb->sk;
+ struct sock_exterr_skb *serr;
+ int err;
+
+ skb->wifi_acked_valid = 1;
+ skb->wifi_acked = acked;
+
+ serr = SKB_EXT_ERR(skb);
+ memset(serr, 0, sizeof(*serr));
+ serr->ee.ee_errno = ENOMSG;
+ serr->ee.ee_origin = SO_EE_ORIGIN_TXSTATUS;
+
+ err = sock_queue_err_skb(sk, skb);
+ if (err)
+ kfree_skb(skb);
+}
+EXPORT_SYMBOL_GPL(skb_complete_wifi_ack);
+
/**
* skb_partial_csum_set - set up and verify partial csum values for packet
--- a/net/socket.c 2011-10-07 18:59:12.000000000 +0200
+++ b/net/socket.c 2011-10-07 18:59:12.000000000 +0200
@@ -531,6 +531,7 @@ void sock_release(struct socket *sock)
}
EXPORT_SYMBOL(sock_release);
+/* XXX: rename this function now */
int sock_tx_timestamp(struct sock *sk, __u8 *tx_flags)
{
*tx_flags = 0;
@@ -538,6 +539,8 @@ int sock_tx_timestamp(struct sock *sk, _
*tx_flags |= SKBTX_HW_TSTAMP;
if (sock_flag(sk, SOCK_TIMESTAMPING_TX_SOFTWARE))
*tx_flags |= SKBTX_SW_TSTAMP;
+ if (sock_flag(sk, SOCK_WIFI_STATUS))
+ *tx_flags |= SKBTX_WIFI_STATUS;
return 0;
}
EXPORT_SYMBOL(sock_tx_timestamp);
@@ -674,6 +677,22 @@ void __sock_recv_timestamp(struct msghdr
}
EXPORT_SYMBOL_GPL(__sock_recv_timestamp);
+void __sock_recv_wifi_status(struct msghdr *msg, struct sock *sk,
+ struct sk_buff *skb)
+{
+ int ack;
+
+ if (!sock_flag(sk, SOCK_WIFI_STATUS))
+ return;
+ if (!skb->wifi_acked_valid)
+ return;
+
+ ack = skb->wifi_acked;
+
+ put_cmsg(msg, SOL_SOCKET, SCM_WIFI_STATUS, sizeof(ack), &ack);
+}
+EXPORT_SYMBOL_GPL(__sock_recv_wifi_status);
+
static inline void sock_recv_drops(struct msghdr *msg, struct sock *sk,
struct sk_buff *skb)
{
--- a/net/mac80211/status.c 2011-10-07 18:59:12.000000000 +0200
+++ b/net/mac80211/status.c 2011-10-07 19:05:24.000000000 +0200
@@ -252,8 +252,9 @@ void ieee80211_tx_status(struct ieee8021
struct sta_info *sta, *tmp;
int retry_count = -1, i;
int rates_idx = -1;
- bool send_to_cooked;
+ bool send_to_cooked, need_for_monitors;
bool acked;
+ bool multicast;
struct ieee80211_bar *bar;
u16 tid;
@@ -278,6 +279,7 @@ void ieee80211_tx_status(struct ieee8021
sband = local->hw.wiphy->bands[info->band];
fc = hdr->frame_control;
+ multicast = is_multicast_ether_addr(hdr->addr1);
for_each_sta_info(local, hdr->addr1, sta, tmp) {
/* skip wrong virtual interface */
@@ -443,9 +445,6 @@ void ieee80211_tx_status(struct ieee8021
!!(info->flags & IEEE80211_TX_STAT_ACK), GFP_ATOMIC);
}
- /* this was a transmitted frame, but now we want to reuse it */
- skb_orphan(skb);
-
/* Need to make a copy before skb->cb gets cleared */
send_to_cooked = !!(info->flags & IEEE80211_TX_CTL_INJECTED) ||
(type != IEEE80211_FTYPE_DATA);
@@ -454,13 +453,33 @@ void ieee80211_tx_status(struct ieee8021
* This is a bit racy but we can avoid a lot of work
* with this test...
*/
- if (!local->monitors && (!send_to_cooked || !local->cooked_mntrs)) {
- dev_kfree_skb(skb);
- return;
- }
+ need_for_monitors = local->monitors ||
+ (send_to_cooked && local->cooked_mntrs);
/* send frame to monitor interfaces now */
+ if (!multicast && skb->sk &&
+ skb_shinfo(skb)->tx_flags & SKBTX_WIFI_STATUS) {
+ struct sk_buff *mon_skb = NULL;
+
+ if (need_for_monitors)
+ mon_skb = skb_clone(skb, GFP_ATOMIC);
+
+ /* consumes skb */
+ skb_complete_wifi_ack(skb, info->flags & IEEE80211_TX_STAT_ACK);
+
+ if (!mon_skb)
+ return;
+
+ skb = mon_skb;
+ } else if (!need_for_monitors) {
+ dev_kfree_skb(skb);
+ return;
+ } else {
+ /* this was a transmitted frame, but now we want to reuse it */
+ skb_orphan(skb);
+ }
+
if (skb_headroom(skb) < sizeof(*rthdr)) {
printk(KERN_ERR "ieee80211_tx_status: headroom too small\n");
dev_kfree_skb(skb);
--- a/net/mac80211/tx.c 2011-10-07 18:59:12.000000000 +0200
+++ b/net/mac80211/tx.c 2011-10-07 18:59:12.000000000 +0200
@@ -1686,6 +1686,7 @@ netdev_tx_t ieee80211_subif_start_xmit(s
bool wme_sta = false, authorized = false, tdls_auth = false;
struct sk_buff *tmp_skb;
bool tdls_direct = false;
+ bool multicast;
if (unlikely(skb->len < ETH_HLEN)) {
ret = NETDEV_TX_OK;
@@ -1872,7 +1873,8 @@ netdev_tx_t ieee80211_subif_start_xmit(s
* if it is a multicast address (which can only happen
* in AP mode)
*/
- if (!is_multicast_ether_addr(hdr.addr1)) {
+ multicast = is_multicast_ether_addr(hdr.addr1);
+ if (!multicast) {
rcu_read_lock();
sta = sta_info_get(sdata, hdr.addr1);
if (sta) {
@@ -2019,6 +2021,10 @@ netdev_tx_t ieee80211_subif_start_xmit(s
memset(info, 0, sizeof(*info));
dev->trans_start = jiffies;
+
+ if (!multicast && skb_shinfo(skb)->tx_flags & SKBTX_WIFI_STATUS)
+ info->flags = IEEE80211_TX_CTL_REQ_TX_STATUS;
+
ieee80211_xmit(sdata, skb);
return NETDEV_TX_OK;
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC] net: remove erroneous sk null assignment in timestamping
From: Johannes Berg @ 2011-10-07 17:11 UTC (permalink / raw)
To: netdev; +Cc: Richard Cochran
From: Johannes Berg <johannes.berg@intel.com>
skb->sk is obviously required to be non-NULL
when we get into skb_complete_tx_timestamp().
sock_queue_err_skb() will call skb_orphan()
first thing which sets skb->sk = NULL itself.
This may crash if the skb is still charged to
the socket (skb->destructor is sk_wfree).
The assignment here thus seems to not only be
pointless (due to the skb_orphan() call) but
also dangerous (due to the crash).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/core/timestamping.c | 1 -
1 file changed, 1 deletion(-)
--- a/net/core/timestamping.c 2011-10-07 18:59:12.000000000 +0200
+++ b/net/core/timestamping.c 2011-10-07 19:07:06.000000000 +0200
@@ -85,7 +85,6 @@ void skb_complete_tx_timestamp(struct sk
memset(serr, 0, sizeof(*serr));
serr->ee.ee_errno = ENOMSG;
serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
- skb->sk = NULL;
err = sock_queue_err_skb(sk, skb);
if (err)
kfree_skb(skb);
^ permalink raw reply
* Re: [PATCH] IPv6: DAD from bonding iface is treated as dup address from others
From: Yinglin Sun @ 2011-10-07 16:59 UTC (permalink / raw)
To: netdev
In-Reply-To: <20111007061326.GL23845@angus.ind.WPI.EDU>
On Thu, Oct 6, 2011 at 11:13 PM, Chuck Anderson <cra@wpi.edu> wrote:
>
> On Thu, Oct 06, 2011 at 06:24:36PM -0700, Yinglin Sun wrote:
> > On Thu, Oct 6, 2011 at 5:59 PM, Jay Vosburgh <fubar@us.ibm.com> wrote:
> > > Why are you setting up the port channel after configuring the
> > > bond?
> > >
> > > As a possible workaround, if you have control over the setup
> > > process (perhaps it's some sort of manual process), adding one slave to
> > > the bond, leaving the other soon-to-be slaves down, then setting up the
> > > switch, and finally adding the remaining slaves should work around the
> > > issue, since if the bond has only one slave it won't see any looped
> > > packets.
> > >
> > > Or you could bring the bond up as active-backup, then change the
> > > mode to balance-xor once the switch is configured.
> > >
> > > Ultimately, though, the problem stems from the settings mismatch
> > > between the switch and the bonding system; balance-xor is meant to
> > > interoperate with etherchannel, and when the switch is not configured
> > > properly, correct behavior is difficult to guarantee.
> > >
> >
> > Jay,
> >
> > Thanks a lot for the suggestion.
> >
> > It's mainly about usability. We would like to provide customers with
> > consistent IPv6 configuration procedures as IPv4. Such workarounds
> > could be confusing and generate customer calls.
>
> You've created/encouraged your customers to create a broken network
> configuration by connecting two bonded links to a non-bonded,
> non-etherchannel switch port pair. This type of misconfiguration,
> when applied to inter-switch trunks, can cause major network issues,
> like looping and broadcast storms, taking down the entire network
> unless something like Spanning Tree is enabled to protect against such
> accidental loops. It should be avoided at all costs. Luckily, if the
> Linux host in this case is not being used as a switch/bridge, the
> impact of this might not be so bad--perhaps limited to the IPv6 DAD
> issue you report.
>
> If you want better usability and plug-n-play bonding, then require
> LACP/802.3ad to be used. Please don't encourage your customers to
> connect misconfigured devices to the network, thanks.
You are right. LACP is the good choice. It should be able to solve
this issue, since all LACP bonding slaves are down before port channel
is set up on switch. Thanks.
I'm not sure this is kind of broken network configuration. If
customers happen to add some IPv6 addresses on bonding interface
before setting up port channel on switch, they have to reconfigure all
of them again. This is not the good user experience. From my point of
view, a nice product should be able to tolerate this issue.
Thanks.
Yinglin
^ permalink raw reply
* Re: [PATCH net-next] macvlan: handle fragmented multicast frames
From: Ben Greear @ 2011-10-07 16:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1317932911.3457.31.camel@edumazet-laptop>
On 10/06/2011 01:28 PM, Eric Dumazet wrote:
> Le mercredi 05 octobre 2011 à 15:35 -0700, Ben Greear a écrit :
>
>> If someone wants to cook up macvlan-ip-defrag patch I'll be happy
>> to test it. But, as far as I can tell, this problem can happen on
>> any two interfaces. The reason that some of mine work (.1q vlans)
>> and macvlan didn't is probably because those were separated by
>> some virtual network links that imparted extra delay...so the
>> vlan consumed all its fragments and passed the complete pkt up
>> the stack before the mac-vlan ever saw the initial frame.
>>
>> With this in mind, it seems that using multiple udp multicast
>> sockets bound to specific devices is fundamentally broken for
>> fragmented packets.
>>
>> I have no pressing need for this feature, so now that I better understand
>> the problem I can just document it and move on to other things.
>>
>> Thanks for all the help.
>>
>
> Please test following patch (note I had no time to test it, sorry !)
I hope to test this soon, but lots of other things piled up all
at once, so might be a few days.
Thanks,
Ben
>
> Based on net-next tree, might apply on 3.0 kernel...
>
> [PATCH net-next] macvlan: handle fragmented multicast frames
>
> Fragmented multicast frames are delivered to a single macvlan port,
> because ip defrag logic considers other samples are redundant.
>
> Implement a defrag step before trying to send the multicast frame.
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: e1000e might_sleep warnings (3.1-rc9)
From: Allan, Bruce W @ 2011-10-07 16:43 UTC (permalink / raw)
To: Dave Jones, netdev@vger.kernel.org
In-Reply-To: <20111007161430.GA2752@redhat.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Dave Jones
>Sent: Friday, October 07, 2011 9:15 AM
>To: netdev@vger.kernel.org
>Subject: e1000e might_sleep warnings (3.1-rc9)
>
>Just had this reported..
>
> > [20734.109233] Call Trace:
> > [20734.109242] [<ffffffff8104f6b5>] __might_sleep+0x103/0x108
> > [20734.109249] [<ffffffff8150363e>] mutex_lock_nested+0x25/0x45
> > [20734.109260] [<ffffffffa023b8f7>] e1000_acquire_swflag_ich8lan+0x26/0x136
>[e1000e]
> > [20734.109271] [<ffffffffa024a3af>] e1000e_update_stats+0x156/0x73e [e1000e]
> > [20734.109275] [<ffffffff81504561>] ? _raw_spin_lock+0x71/0x79
> > [20734.109285] [<ffffffffa024e658>] ? e1000_watchdog_task+0x3b1/0x5de
>[e1000e]
> > [20734.109294] [<ffffffffa024e660>] e1000_watchdog_task+0x3b9/0x5de [e1000e]
> > [20734.109303] [<ffffffffa024e2a7>] ? e1000_update_mng_vlan+0x68/0x68
>[e1000e]
> > [20734.109307] [<ffffffff81075b21>] process_one_work+0x205/0x3e7
> > [20734.109310] [<ffffffff81075a69>] ? process_one_work+0x14d/0x3e7
> > [20734.109315] [<ffffffff8108cf0f>] ? lock_acquired+0x210/0x243
> > [20734.109320] [<ffffffff810767cf>] worker_thread+0xda/0x15d
> > [20734.109323] [<ffffffff810766f5>] ? manage_workers+0x176/0x176
> > [20734.109327] [<ffffffff8107a195>] kthread+0xa8/0xb0
> > [20734.109332] [<ffffffff8150dec4>] kernel_thread_helper+0x4/0x10
> > [20734.109336] [<ffffffff81505334>] ? retint_restore_args+0x13/0x13
> > [20734.109340] [<ffffffff8107a0ed>] ? __init_kthread_worker+0x5a/0x5a
> > [20734.109344] [<ffffffff8150dec0>] ? gs_change+0x13/0x13
> > [20736.106653] BUG: sleeping function called from invalid context at
>kernel/mutex.c:271
> > [20736.106658] in_atomic(): 1, irqs_disabled(): 0, pid: 18071, name:
>kworker/0:1
> > [20736.106661] INFO: lockdep is turned off.
> > [20736.106664] Pid: 18071, comm: kworker/0:1 Not tainted 3.1.0-
>0.rc9.git0.0.fc17.x86_64 #1
> > [20736.106667] Call Trace:
> > [20736.106675] [<ffffffff8104f6b5>] __might_sleep+0x103/0x108
> > [20736.106682] [<ffffffff8150363e>] mutex_lock_nested+0x25/0x45
> > [20736.106693] [<ffffffffa023b8f7>] e1000_acquire_swflag_ich8lan+0x26/0x136
>[e1000e]
> > [20736.106705] [<ffffffffa024a3af>] e1000e_update_stats+0x156/0x73e [e1000e]
> > [20736.106709] [<ffffffff81504561>] ? _raw_spin_lock+0x71/0x79
> > [20736.106719] [<ffffffffa024e658>] ? e1000_watchdog_task+0x3b1/0x5de
>[e1000e]
> > [20736.106728] [<ffffffffa024e660>] e1000_watchdog_task+0x3b9/0x5de [e1000e]
> > [20736.106737] [<ffffffffa024e2a7>] ? e1000_update_mng_vlan+0x68/0x68
>[e1000e]
> > [20736.106741] [<ffffffff81075b21>] process_one_work+0x205/0x3e7
> > [20736.106744] [<ffffffff81075a69>] ? process_one_work+0x14d/0x3e7
> > [20736.106749] [<ffffffff8108cf0f>] ? lock_acquired+0x210/0x243
> > [20736.106754] [<ffffffff810767cf>] worker_thread+0xda/0x15d
> > [20736.106757] [<ffffffff810766f5>] ? manage_workers+0x176/0x176
> > [20736.106761] [<ffffffff8107a195>] kthread+0xa8/0xb0
> > [20736.106767] [<ffffffff8150dec4>] kernel_thread_helper+0x4/0x10
> > [20736.106771] [<ffffffff81505334>] ? retint_restore_args+0x13/0x13
> > [20736.106775] [<ffffffff8107a0ed>] ? __init_kthread_worker+0x5a/0x5a
> > [20736.106779] [<ffffffff8150dec0>] ? gs_change+0x13/0x13
> > [20738.104064] BUG: sleeping function called from invalid context at
>kernel/mutex.c:271
> > [20738.104070] in_atomic(): 1, irqs_disabled(): 0, pid: 18071, name:
>kworker/0:1
> > [20738.104073] INFO: lockdep is turned off.
> > [20738.104077] Pid: 18071, comm: kworker/0:1 Not tainted 3.1.0-
>0.rc9.git0.0.fc17.x86_64 #1
> > [20738.104079] Call Trace:
> > [20738.104088] [<ffffffff8104f6b5>] __might_sleep+0x103/0x108
> > [20738.104096] [<ffffffff8150363e>] mutex_lock_nested+0x25/0x45
> > [20738.104107] [<ffffffffa023b8f7>] e1000_acquire_swflag_ich8lan+0x26/0x136
>[e1000e]
> > [20738.104118] [<ffffffffa024a3af>] e1000e_update_stats+0x156/0x73e [e1000e]
> > [20738.104123] [<ffffffff81504561>] ? _raw_spin_lock+0x71/0x79
> > [20738.104133] [<ffffffffa024e658>] ? e1000_watchdog_task+0x3b1/0x5de
>[e1000e]
> > [20738.104142] [<ffffffffa024e660>] e1000_watchdog_task+0x3b9/0x5de [e1000e]
> > [20738.104151] [<ffffffffa024e2a7>] ? e1000_update_mng_vlan+0x68/0x68
>[e1000e]
> > [20738.104155] [<ffffffff81075b21>] process_one_work+0x205/0x3e7
> > [20738.104158] [<ffffffff81075a69>] ? process_one_work+0x14d/0x3e7
> > [20738.104162] [<ffffffff8108cf0f>] ? lock_acquired+0x210/0x243
> > [20738.104167] [<ffffffff810767cf>] worker_thread+0xda/0x15d
> > [20738.104170] [<ffffffff810766f5>] ? manage_workers+0x176/0x176
> > [20738.104175] [<ffffffff8107a195>] kthread+0xa8/0xb0
> > [20738.104180] [<ffffffff8150dec4>] kernel_thread_helper+0x4/0x10
> > [20738.104184] [<ffffffff81505334>] ? retint_restore_args+0x13/0x13
> > [20738.104188] [<ffffffff8107a0ed>] ? __init_kthread_worker+0x5a/0x5a
> > [20738.104192] [<ffffffff8150dec0>] ? gs_change+0x13/0x13
> >
> >
> >
> > On my x220 ThinnkPad.
Thanks, this has previously been reported, a fix is already in-house here
at Intel and should be pushed upstream soon.
^ permalink raw reply
* Re: [net-next] cs89x0: Move the driver into the Cirrus dir
From: David Miller @ 2011-10-07 16:42 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann, nelson, akpm
In-Reply-To: <20111007.123936.390761582614065567.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 07 Oct 2011 12:39:36 -0400 (EDT)
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Fri, 7 Oct 2011 00:18:33 -0700
>
>> The cs89x0 driver was initial placed in the apple/ when it
>> should have been placed in the cirrus/. This resolves the
>> issue by moving the dirver and fixing up the respective
>> Kconfig(s) and Makefile(s).
>>
>> Thanks to Sascha for reporting the issue.
>>
>> CC: Russell Nelson <nelson@crynwr.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Applied.
Actually, reverted, you have to fix this:
[davem@ilbolle net-next]$ make oldconfig
scripts/kconfig/conf --oldconfig Kconfig
drivers/net/ethernet/apple/Kconfig:21:error: recursive dependency detected!
drivers/net/ethernet/apple/Kconfig:21: symbol MACE depends on NET_VENDOR_APPLE
drivers/net/ethernet/apple/Kconfig:5: symbol NET_VENDOR_APPLE depends on MACE
^ permalink raw reply
* [PATCH net-next v2] Add ethtool -g support to 8139cp
From: Rick Jones @ 2011-10-07 16:42 UTC (permalink / raw)
To: netdev
From: Rick Jones <rick.jones2@hp.com>
Add support for reporting ring sizes via ethtool -g to the 8139cp driver.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
---
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index c77d5af..5dcd5be 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -1324,6 +1324,15 @@ static void cp_get_drvinfo (struct net_device *dev, struct ethtool_drvinfo *info
strcpy (info->bus_info, pci_name(cp->pdev));
}
+static void cp_get_ringparam(struct net_device *dev,
+ struct ethtool_ringparam *ring)
+{
+ ring->rx_max_pending = CP_RX_RING_SIZE;
+ ring->tx_max_pending = CP_TX_RING_SIZE;
+ ring->rx_pending = CP_RX_RING_SIZE;
+ ring->tx_pending = CP_TX_RING_SIZE;
+}
+
static int cp_get_regs_len(struct net_device *dev)
{
return CP_REGS_SIZE;
@@ -1525,6 +1534,7 @@ static const struct ethtool_ops cp_ethtool_ops = {
.get_eeprom_len = cp_get_eeprom_len,
.get_eeprom = cp_get_eeprom,
.set_eeprom = cp_set_eeprom,
+ .get_ringparam = cp_get_ringparam,
};
static int cp_ioctl (struct net_device *dev, struct ifreq *rq, int cmd)
^ permalink raw reply related
* Re: [net-next] cs89x0: Move the driver into the Cirrus dir
From: David Miller @ 2011-10-07 16:39 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann, nelson, akpm
In-Reply-To: <1317971926-23145-2-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 7 Oct 2011 00:18:33 -0700
> The cs89x0 driver was initial placed in the apple/ when it
> should have been placed in the cirrus/. This resolves the
> issue by moving the dirver and fixing up the respective
> Kconfig(s) and Makefile(s).
>
> Thanks to Sascha for reporting the issue.
>
> CC: Russell Nelson <nelson@crynwr.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next 00/13][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-10-07 16:38 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1317971926-23145-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 7 Oct 2011 00:18:32 -0700
> The following series contains updates to e1000, e1000e, igb and ixgbe. Here
> is a quick summary:
> - e1000: 3 conversions (timers->threads, mdelay->msleep, mutex->rtnl)
> - e1000e: fix jumbo frames on 82579
> - igb: several cleanups to reduce stack space and improve performance
> - ixgbe: bump driver ver
>
> The following are changes since commit e878d78b9a7403fabc89ecc93c56928b74d14f01:
> virtio-net: Verify page list size before fitting into skb
> and are available in the git repository at
> git://github.com/Jkirsher/net-next.git
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH net-next] Add ethtool -g support to 8139cp
From: Rick Jones @ 2011-10-07 16:38 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, netdev
In-Reply-To: <20111005.175329.2143609207723954863.davem@davemloft.net>
On 10/05/2011 02:53 PM, David Miller wrote:
> From: Ben Hutchings<bhutchings@solarflare.com>
> Date: Wed, 05 Oct 2011 19:50:48 +0100
>
>> You generally don't need to set fields to zero in ethtool 'get'
>> operations, as the ethtool core will initialise the entire structure to
>> zero.
>
> Rick, please remove the explicit zero initializations and resubmit,
> thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ben/Dave
Thanks for the feedback. I'll tweak and resend under separate cover.
rick
simply copying what he saw in e1000_get_ringparm :)
^ permalink raw reply
* Re: [PATCH] dev: use name hash for dev_seq_ops.
From: Stephen Hemminger @ 2011-10-07 16:24 UTC (permalink / raw)
To: Mihai Maruseac
Cc: davem, eric.dumazet, mirq-linux, therbert, jpirko, netdev,
linux-kernel, dbaluta, Mihai Maruseac
In-Reply-To: <1318000849-2531-1-git-send-email-mmaruseac@ixiacom.com>
On Fri, 7 Oct 2011 18:20:49 +0300
Mihai Maruseac <mihai.maruseac@gmail.com> wrote:
> Instead of using the dev->next chain and trying to resync at each call to
> dev_seq_start, use this hash and store bucket number and bucket offset in
> seq->private field.
>
> Tests revealed the following results for ifconfig > /dev/null
> * 1000 interfaces:
> * 0.114s without patch
> * 0.020s with patch
> * 3000 interfaces:
> * 0.489s without patch
> * 0.048s with patch
> * 5000 interfaces:
> * 1.363s without patch
> * 0.131s with patch
>
> As one can notice the improvement is of 1 order of magnitude.
Good idea,
This will change the ordering of entries in /proc which may upset
some program, not a critical flaw but worth noting.
Rather than recording the bucket and offset of last entry, another
alternative would be to just record the ifindex.
Also ifconfig is considered deprecated and replaced by ip commands
for general use.
^ permalink raw reply
* e1000e might_sleep warnings (3.1-rc9)
From: Dave Jones @ 2011-10-07 16:14 UTC (permalink / raw)
To: netdev
Just had this reported..
> [20734.109233] Call Trace:
> [20734.109242] [<ffffffff8104f6b5>] __might_sleep+0x103/0x108
> [20734.109249] [<ffffffff8150363e>] mutex_lock_nested+0x25/0x45
> [20734.109260] [<ffffffffa023b8f7>] e1000_acquire_swflag_ich8lan+0x26/0x136 [e1000e]
> [20734.109271] [<ffffffffa024a3af>] e1000e_update_stats+0x156/0x73e [e1000e]
> [20734.109275] [<ffffffff81504561>] ? _raw_spin_lock+0x71/0x79
> [20734.109285] [<ffffffffa024e658>] ? e1000_watchdog_task+0x3b1/0x5de [e1000e]
> [20734.109294] [<ffffffffa024e660>] e1000_watchdog_task+0x3b9/0x5de [e1000e]
> [20734.109303] [<ffffffffa024e2a7>] ? e1000_update_mng_vlan+0x68/0x68 [e1000e]
> [20734.109307] [<ffffffff81075b21>] process_one_work+0x205/0x3e7
> [20734.109310] [<ffffffff81075a69>] ? process_one_work+0x14d/0x3e7
> [20734.109315] [<ffffffff8108cf0f>] ? lock_acquired+0x210/0x243
> [20734.109320] [<ffffffff810767cf>] worker_thread+0xda/0x15d
> [20734.109323] [<ffffffff810766f5>] ? manage_workers+0x176/0x176
> [20734.109327] [<ffffffff8107a195>] kthread+0xa8/0xb0
> [20734.109332] [<ffffffff8150dec4>] kernel_thread_helper+0x4/0x10
> [20734.109336] [<ffffffff81505334>] ? retint_restore_args+0x13/0x13
> [20734.109340] [<ffffffff8107a0ed>] ? __init_kthread_worker+0x5a/0x5a
> [20734.109344] [<ffffffff8150dec0>] ? gs_change+0x13/0x13
> [20736.106653] BUG: sleeping function called from invalid context at kernel/mutex.c:271
> [20736.106658] in_atomic(): 1, irqs_disabled(): 0, pid: 18071, name: kworker/0:1
> [20736.106661] INFO: lockdep is turned off.
> [20736.106664] Pid: 18071, comm: kworker/0:1 Not tainted 3.1.0-0.rc9.git0.0.fc17.x86_64 #1
> [20736.106667] Call Trace:
> [20736.106675] [<ffffffff8104f6b5>] __might_sleep+0x103/0x108
> [20736.106682] [<ffffffff8150363e>] mutex_lock_nested+0x25/0x45
> [20736.106693] [<ffffffffa023b8f7>] e1000_acquire_swflag_ich8lan+0x26/0x136 [e1000e]
> [20736.106705] [<ffffffffa024a3af>] e1000e_update_stats+0x156/0x73e [e1000e]
> [20736.106709] [<ffffffff81504561>] ? _raw_spin_lock+0x71/0x79
> [20736.106719] [<ffffffffa024e658>] ? e1000_watchdog_task+0x3b1/0x5de [e1000e]
> [20736.106728] [<ffffffffa024e660>] e1000_watchdog_task+0x3b9/0x5de [e1000e]
> [20736.106737] [<ffffffffa024e2a7>] ? e1000_update_mng_vlan+0x68/0x68 [e1000e]
> [20736.106741] [<ffffffff81075b21>] process_one_work+0x205/0x3e7
> [20736.106744] [<ffffffff81075a69>] ? process_one_work+0x14d/0x3e7
> [20736.106749] [<ffffffff8108cf0f>] ? lock_acquired+0x210/0x243
> [20736.106754] [<ffffffff810767cf>] worker_thread+0xda/0x15d
> [20736.106757] [<ffffffff810766f5>] ? manage_workers+0x176/0x176
> [20736.106761] [<ffffffff8107a195>] kthread+0xa8/0xb0
> [20736.106767] [<ffffffff8150dec4>] kernel_thread_helper+0x4/0x10
> [20736.106771] [<ffffffff81505334>] ? retint_restore_args+0x13/0x13
> [20736.106775] [<ffffffff8107a0ed>] ? __init_kthread_worker+0x5a/0x5a
> [20736.106779] [<ffffffff8150dec0>] ? gs_change+0x13/0x13
> [20738.104064] BUG: sleeping function called from invalid context at kernel/mutex.c:271
> [20738.104070] in_atomic(): 1, irqs_disabled(): 0, pid: 18071, name: kworker/0:1
> [20738.104073] INFO: lockdep is turned off.
> [20738.104077] Pid: 18071, comm: kworker/0:1 Not tainted 3.1.0-0.rc9.git0.0.fc17.x86_64 #1
> [20738.104079] Call Trace:
> [20738.104088] [<ffffffff8104f6b5>] __might_sleep+0x103/0x108
> [20738.104096] [<ffffffff8150363e>] mutex_lock_nested+0x25/0x45
> [20738.104107] [<ffffffffa023b8f7>] e1000_acquire_swflag_ich8lan+0x26/0x136 [e1000e]
> [20738.104118] [<ffffffffa024a3af>] e1000e_update_stats+0x156/0x73e [e1000e]
> [20738.104123] [<ffffffff81504561>] ? _raw_spin_lock+0x71/0x79
> [20738.104133] [<ffffffffa024e658>] ? e1000_watchdog_task+0x3b1/0x5de [e1000e]
> [20738.104142] [<ffffffffa024e660>] e1000_watchdog_task+0x3b9/0x5de [e1000e]
> [20738.104151] [<ffffffffa024e2a7>] ? e1000_update_mng_vlan+0x68/0x68 [e1000e]
> [20738.104155] [<ffffffff81075b21>] process_one_work+0x205/0x3e7
> [20738.104158] [<ffffffff81075a69>] ? process_one_work+0x14d/0x3e7
> [20738.104162] [<ffffffff8108cf0f>] ? lock_acquired+0x210/0x243
> [20738.104167] [<ffffffff810767cf>] worker_thread+0xda/0x15d
> [20738.104170] [<ffffffff810766f5>] ? manage_workers+0x176/0x176
> [20738.104175] [<ffffffff8107a195>] kthread+0xa8/0xb0
> [20738.104180] [<ffffffff8150dec4>] kernel_thread_helper+0x4/0x10
> [20738.104184] [<ffffffff81505334>] ? retint_restore_args+0x13/0x13
> [20738.104188] [<ffffffff8107a0ed>] ? __init_kthread_worker+0x5a/0x5a
> [20738.104192] [<ffffffff8150dec0>] ? gs_change+0x13/0x13
>
>
>
> On my x220 ThinnkPad.
^ permalink raw reply
* [PATCH net-next] l2tp: give proper headroom in pppol2tp_xmit()
From: Eric Dumazet @ 2011-10-07 15:45 UTC (permalink / raw)
To: David Miller; +Cc: netdev
pppol2tp_xmit() calls skb_cow_head(skb, 2) before calling
l2tp_xmit_skb()
Then l2tp_xmit_skb() calls again skb_cow_head(skb, large_headroom)
This patchs changes the first skb_cow_head() call to supply the needed
headroom to make sure at most one (expensive) pskb_expand_head() is
done.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
Maybe we should add a counter to help diagnose too many
pskb_expand_head() calls...
net/l2tp/l2tp_ppp.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index f42cd09..8a90d75 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -395,6 +395,7 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
struct pppol2tp_session *ps;
int old_headroom;
int new_headroom;
+ int uhlen, headroom;
if (sock_flag(sk, SOCK_DEAD) || !(sk->sk_state & PPPOX_CONNECTED))
goto abort;
@@ -413,7 +414,13 @@ static int pppol2tp_xmit(struct ppp_channel *chan, struct sk_buff *skb)
goto abort_put_sess;
old_headroom = skb_headroom(skb);
- if (skb_cow_head(skb, sizeof(ppph)))
+ uhlen = (tunnel->encap == L2TP_ENCAPTYPE_UDP) ? sizeof(struct udphdr) : 0;
+ headroom = NET_SKB_PAD +
+ sizeof(struct iphdr) + /* IP header */
+ uhlen + /* UDP header (if L2TP_ENCAPTYPE_UDP) */
+ session->hdr_len + /* L2TP header */
+ sizeof(ppph); /* PPP header */
+ if (skb_cow_head(skb, headroom))
goto abort_put_sess_tun;
new_headroom = skb_headroom(skb);
^ permalink raw reply related
* [PATCH] l2tp: fix a potential skb leak in l2tp_xmit_skb()
From: Eric Dumazet @ 2011-10-07 15:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
l2tp_xmit_skb() can leak one skb if skb_cow_head() returns an error.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/l2tp/l2tp_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index ad4ac26..34b2dde 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1045,8 +1045,10 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
headroom = NET_SKB_PAD + sizeof(struct iphdr) +
uhlen + hdr_len;
old_headroom = skb_headroom(skb);
- if (skb_cow_head(skb, headroom))
+ if (skb_cow_head(skb, headroom)) {
+ dev_kfree_skb(skb);
goto abort;
+ }
new_headroom = skb_headroom(skb);
skb_orphan(skb);
^ permalink raw reply related
* [PATCH] dev: use name hash for dev_seq_ops.
From: Mihai Maruseac @ 2011-10-07 15:20 UTC (permalink / raw)
To: davem
Cc: eric.dumazet, mirq-linux, therbert, jpirko, netdev, linux-kernel,
dbaluta, Mihai Maruseac
Instead of using the dev->next chain and trying to resync at each call to
dev_seq_start, use this hash and store bucket number and bucket offset in
seq->private field.
Tests revealed the following results for ifconfig > /dev/null
* 1000 interfaces:
* 0.114s without patch
* 0.020s with patch
* 3000 interfaces:
* 0.489s without patch
* 0.048s with patch
* 5000 interfaces:
* 1.363s without patch
* 0.131s with patch
As one can notice the improvement is of 1 order of magnitude.
Signed-off-by: Mihai Maruseac <mmaruseac@ixiacom.com>
---
net/core/dev.c | 73 +++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index bf49a47..2d0f126 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4034,6 +4034,51 @@ static int dev_ifconf(struct net *net, char __user *arg)
}
#ifdef CONFIG_PROC_FS
+
+struct dev_iter_state {
+ struct seq_net_private p;
+ int bucket;
+ int offset;
+};
+
+static inline struct net_device *dev_from_same_bucket(struct seq_file *seq)
+{
+ struct net_device *dev = NULL;
+ struct net *net = seq_file_net(seq);
+ struct dev_iter_state *state = seq->private;
+ struct hlist_node *p;
+ struct hlist_head *h;
+ int count;
+
+ h = &net->dev_name_head[state->bucket];
+ count = 0;
+ hlist_for_each_entry_rcu(dev, p, h, name_hlist) {
+ if (count++ == state->offset) {
+ state->offset = count;
+ return dev;
+ }
+ }
+
+ return NULL;
+}
+
+static inline struct net_device *dev_from_new_bucket(struct seq_file *seq)
+{
+ struct dev_iter_state *state = seq->private;
+ struct net_device *dev = NULL;
+
+ while (state->bucket < NETDEV_HASHENTRIES) {
+ dev = dev_from_same_bucket(seq);
+ if (dev)
+ return dev;
+
+ state->bucket++;
+ state->offset = 0;
+ }
+
+ return NULL;
+}
+
/*
* This is invoked by the /proc filesystem handler to display a device
* in detail.
@@ -4041,33 +4086,27 @@ static int dev_ifconf(struct net *net, char __user *arg)
void *dev_seq_start(struct seq_file *seq, loff_t *pos)
__acquires(RCU)
{
- struct net *net = seq_file_net(seq);
- loff_t off;
- struct net_device *dev;
-
rcu_read_lock();
if (!*pos)
return SEQ_START_TOKEN;
- off = 1;
- for_each_netdev_rcu(net, dev)
- if (off++ == *pos)
- return dev;
-
- return NULL;
+ return dev_from_new_bucket(seq);
}
void *dev_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
- struct net_device *dev = v;
+ struct net_device *dev = NULL;
+
+ ++*pos;
if (v == SEQ_START_TOKEN)
- dev = first_net_device_rcu(seq_file_net(seq));
- else
- dev = next_net_device_rcu(dev);
+ return dev_from_new_bucket(seq);
- ++*pos;
- return dev;
+ dev = dev_from_same_bucket(seq);
+ if (dev)
+ return dev;
+
+ return dev_from_new_bucket(seq);
}
void dev_seq_stop(struct seq_file *seq, void *v)
@@ -4166,7 +4205,7 @@ static const struct seq_operations dev_seq_ops = {
static int dev_seq_open(struct inode *inode, struct file *file)
{
return seq_open_net(inode, file, &dev_seq_ops,
- sizeof(struct seq_net_private));
+ sizeof(struct dev_iter_state));
}
static const struct file_operations dev_seq_fops = {
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] net: use sock_valbool_flag to set/clear SOCK_RXQ_OVFL
From: Neil Horman @ 2011-10-07 13:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1317994221.3988.12.camel@jlt3.sipsolutions.net>
On Fri, Oct 07, 2011 at 03:30:20PM +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There's no point in open-coding sock_valbool_flag().
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> net/core/sock.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- a/net/core/sock.c 2011-10-07 15:26:30.000000000 +0200
> +++ b/net/core/sock.c 2011-10-07 15:27:46.000000000 +0200
> @@ -738,10 +738,7 @@ set_rcvbuf:
> /* We implement the SO_SNDLOWAT etc to
> not be settable (1003.1g 5.3) */
> case SO_RXQ_OVFL:
> - if (valbool)
> - sock_set_flag(sk, SOCK_RXQ_OVFL);
> - else
> - sock_reset_flag(sk, SOCK_RXQ_OVFL);
> + sock_valbool_flag(sk, SOCK_RXQ_OVFL, valbool);
> break;
> default:
> ret = -ENOPROTOOPT;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Looks good, thanks Johannes!
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [RFC PATCH net 2/2] [BUGFIX] bonding: use flush_delayed_work_sync in bond_close
From: Américo Wang @ 2011-10-07 13:34 UTC (permalink / raw)
To: Mitsuo Hayasaka
Cc: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel,
yrl.pp-manager.tt
In-Reply-To: <20111007125006.7089.9539.stgit@ltc219.sdl.hitachi.co.jp>
On Fri, Oct 7, 2011 at 8:50 PM, Mitsuo Hayasaka
<mitsuo.hayasaka.hu@hitachi.com> wrote:
> The bond_close() calls cancel_delayed_work() to cancel delayed works.
> It, however, cannot cancel works that were already queued in workqueue.
> The bond_open() initializes work->data, and proccess_one_work() refers
> get_work_cwq(work)->wq->flags. The get_work_cwq() returns NULL when
> work->data has been initialized. Thus, a panic occurs.
>
> This patch uses flush_delayed_work_sync() instead of cancel_delayed_work()
> in bond_close(). It cancels delayed timer and waits for work to finish
> execution. So, it can avoid the null pointer dereference due to the
> parallel executions of proccess_one_work() and initializing proccess
> of bond_open().
>
> Signed-off-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: Andy Gospodarek <andy@greyhouse.net>
Makes sense,
Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
Thanks!
^ permalink raw reply
* Old Mobile-IP code and modern Linux
From: Joerg Pommnitz @ 2011-10-07 13:27 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello all,
I'm trying to run the old dynamics Mobile IP implementation (see http://dynamics.sourceforge.net/) on a modern Linux kernel (Fedora 15 2.6.40 aka 3.0).
There seems to be a problem in the communication between a mobile node and the foreign agent. The mobile node sends UDP packets with a source address from its own home network to the discovered address of the FA. Unfortunately the FA never sees these packets. It seems that packets with an unexpected source address will be discarded (ingress filtering?). Is there a way to disable this behavior? What is the right way to implement MobileIP on a recent Linux kernel?
Thanks in advance
Joerg
^ permalink raw reply
* [PATCH] net: use sock_valbool_flag to set/clear SOCK_RXQ_OVFL
From: Johannes Berg @ 2011-10-07 13:30 UTC (permalink / raw)
To: netdev
From: Johannes Berg <johannes.berg@intel.com>
There's no point in open-coding sock_valbool_flag().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/core/sock.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/net/core/sock.c 2011-10-07 15:26:30.000000000 +0200
+++ b/net/core/sock.c 2011-10-07 15:27:46.000000000 +0200
@@ -738,10 +738,7 @@ set_rcvbuf:
/* We implement the SO_SNDLOWAT etc to
not be settable (1003.1g 5.3) */
case SO_RXQ_OVFL:
- if (valbool)
- sock_set_flag(sk, SOCK_RXQ_OVFL);
- else
- sock_reset_flag(sk, SOCK_RXQ_OVFL);
+ sock_valbool_flag(sk, SOCK_RXQ_OVFL, valbool);
break;
default:
ret = -ENOPROTOOPT;
^ permalink raw reply
* Re: [RFC PATCH net 1/2] [BUGFIX] bonding: use local function pointer of bond->recv_probe in bond_handle_frame
From: Américo Wang @ 2011-10-07 13:24 UTC (permalink / raw)
To: Mitsuo Hayasaka
Cc: Jay Vosburgh, Andy Gospodarek, netdev, linux-kernel,
yrl.pp-manager.tt
In-Reply-To: <20111007124954.7089.9776.stgit@ltc219.sdl.hitachi.co.jp>
On Fri, Oct 7, 2011 at 8:49 PM, Mitsuo Hayasaka
<mitsuo.hayasaka.hu@hitachi.com> wrote:
> The bond->recv_probe is called in bond_handle_frame() when
> a packet is received, but bond_close() sets it to NULL. So,
> a panic occurs when both functions work in parallel.
>
> Why this happen:
> After null pointer check of bond->recv_probe, an sk_buff is
> duplicated and bond->recv_probe is called in bond_handle_frame.
> So, a panic occurs when bond_close() is called between the
> check and call of bond->recv_probe.
>
> Patch:
> This patch uses a local function pointer of bond->recv_probe
> in bond_handle_frame(). So, it can avoid the null pointer
> dereference.
>
Hmm, I don't doubt it can fix the problem, I am wondering if
bond->recv_probe should be protected by bond->lock...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox