* [PATCHv2 NEXT 2/2] netxen: update driver version 4.0.75
From: Amit Kumar Salecha @ 2011-01-03 7:58 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1294041525-15553-1-git-send-email-amit.salecha@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 4e54587..a113805 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -53,8 +53,8 @@
#define _NETXEN_NIC_LINUX_MAJOR 4
#define _NETXEN_NIC_LINUX_MINOR 0
-#define _NETXEN_NIC_LINUX_SUBVERSION 74
-#define NETXEN_NIC_LINUX_VERSIONID "4.0.74"
+#define _NETXEN_NIC_LINUX_SUBVERSION 75
+#define NETXEN_NIC_LINUX_VERSIONID "4.0.75"
#define NETXEN_VERSION_CODE(a, b, c) (((a) << 24) + ((b) << 16) + (c))
#define _major(v) (((v) >> 24) & 0xff)
--
1.7.3.2
^ permalink raw reply related
* [PATCHv2 NEXT 1/2] netxen: enable LRO based on NETIF_F_LRO
From: Amit Kumar Salecha @ 2011-01-03 7:58 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty, Sucheta Chakraborty
In-Reply-To: <1294041525-15553-1-git-send-email-amit.salecha@qlogic.com>
From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
o Enable/disable LRO in device based on NETIF_F_LRO flag, instead of using
driver private flag.
o Disable LRO, if rx csum offloading is off.
David Miller,
You should use netdev_info() instead of dev_info().
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic.h | 1 +
drivers/net/netxen/netxen_nic_ethtool.c | 26 ++++++++++++++++++++++++--
drivers/net/netxen/netxen_nic_hw.c | 5 -----
drivers/net/netxen/netxen_nic_main.c | 4 +---
4 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 8e8a978..4e54587 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -1132,6 +1132,7 @@ typedef struct {
#define NETXEN_NIC_MSI_ENABLED 0x02
#define NETXEN_NIC_MSIX_ENABLED 0x04
#define NETXEN_NIC_LRO_ENABLED 0x08
+#define NETXEN_NIC_LRO_DISABLED 0x00
#define NETXEN_NIC_BRIDGE_ENABLED 0X10
#define NETXEN_NIC_DIAG_ENABLED 0x20
#define NETXEN_IS_MSI_FAMILY(adapter) \
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c b/drivers/net/netxen/netxen_nic_ethtool.c
index b30de24..587498e 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -720,7 +720,21 @@ static u32 netxen_nic_get_rx_csum(struct net_device *dev)
static int netxen_nic_set_rx_csum(struct net_device *dev, u32 data)
{
struct netxen_adapter *adapter = netdev_priv(dev);
- adapter->rx_csum = !!data;
+
+ if (data) {
+ adapter->rx_csum = data;
+ return 0;
+ }
+
+ if (dev->features & NETIF_F_LRO) {
+ if (netxen_config_hw_lro(adapter, NETXEN_NIC_LRO_DISABLED))
+ return -EIO;
+
+ dev->features &= ~NETIF_F_LRO;
+ netxen_send_lro_cleanup(adapter);
+ netdev_info(dev, "disabling LRO as rx_csum is off\n");
+ }
+ adapter->rx_csum = data;
return 0;
}
@@ -893,11 +907,19 @@ static int netxen_nic_set_flags(struct net_device *netdev, u32 data)
if (!(adapter->capabilities & NX_FW_CAPABILITY_HW_LRO))
return -EINVAL;
+ if (!adapter->rx_csum) {
+ netdev_info(netdev, "rx csum is off, cannot toggle LRO\n");
+ return -EINVAL;
+ }
+
+ if (!!(data & ETH_FLAG_LRO) == !!(netdev->features & NETIF_F_LRO))
+ return 0;
+
if (data & ETH_FLAG_LRO) {
hw_lro = NETXEN_NIC_LRO_ENABLED;
netdev->features |= NETIF_F_LRO;
} else {
- hw_lro = 0;
+ hw_lro = NETXEN_NIC_LRO_DISABLED;
netdev->features &= ~NETIF_F_LRO;
}
diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c
index e42d26e..5cef718 100644
--- a/drivers/net/netxen/netxen_nic_hw.c
+++ b/drivers/net/netxen/netxen_nic_hw.c
@@ -809,9 +809,6 @@ int netxen_config_hw_lro(struct netxen_adapter *adapter, int enable)
u64 word;
int rv = 0;
- if ((adapter->flags & NETXEN_NIC_LRO_ENABLED) == enable)
- return 0;
-
memset(&req, 0, sizeof(nx_nic_req_t));
req.qhdr = cpu_to_le64(NX_HOST_REQUEST << 23);
@@ -827,8 +824,6 @@ int netxen_config_hw_lro(struct netxen_adapter *adapter, int enable)
"configure hw lro request\n");
}
- adapter->flags ^= NETXEN_NIC_LRO_ENABLED;
-
return rv;
}
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 58a3643..33fac32 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -762,8 +762,6 @@ netxen_check_options(struct netxen_adapter *adapter)
if (adapter->fw_version >= NETXEN_VERSION_CODE(4, 0, 222))
adapter->capabilities = NXRD32(adapter, CRB_FW_CAPABILITIES_1);
- adapter->flags &= ~NETXEN_NIC_LRO_ENABLED;
-
if (adapter->ahw.port_type == NETXEN_NIC_XGBE) {
adapter->num_rxd = DEFAULT_RCV_DESCRIPTORS_10G;
adapter->num_jumbo_rxd = MAX_JUMBO_RCV_DESCRIPTORS_10G;
@@ -990,7 +988,7 @@ __netxen_nic_up(struct netxen_adapter *adapter, struct net_device *netdev)
if (NX_IS_REVISION_P3(adapter->ahw.revision_id))
netxen_config_intr_coalesce(adapter);
- if (adapter->capabilities & NX_FW_CAPABILITY_HW_LRO)
+ if (netdev->features & NETIF_F_LRO)
netxen_config_hw_lro(adapter, NETXEN_NIC_LRO_ENABLED);
netxen_napi_enable(adapter);
--
1.7.3.2
^ permalink raw reply related
* [PATCHv2 0/2]netxen: updates
From: Amit Kumar Salecha @ 2011-01-03 7:58 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, anirban.chakraborty
Hi,
Series v2 of 2 patches to fix LRO in netxen nic driver. Apply these on
net-next branch.
-Amit
^ permalink raw reply
* [PATCH] trivial: Fix typo fault in netdevice.h
From: Michal Simek @ 2011-01-03 8:54 UTC (permalink / raw)
To: davem; +Cc: linux-kernel, netdev, Michal Simek
Signed-off-by: Michal Simek <monstr@monstr.eu>
---
include/linux/netdevice.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d8fd2c2..c773bc8 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -683,7 +683,7 @@ struct netdev_rx_queue {
* neither operation.
*
* void (*ndo_vlan_rx_register)(struct net_device *dev, struct vlan_group *grp);
- * If device support VLAN receive accleration
+ * If device support VLAN receive acceleration
* (ie. dev->features & NETIF_F_HW_VLAN_RX), then this function is called
* when vlan groups for the device changes. Note: grp is NULL
* if no vlan's groups are being used.
--
1.5.5.6
^ permalink raw reply related
* Re: [PATCH] new UDPCP Communication Protocol
From: Stefani Seibold @ 2011-01-03 9:08 UTC (permalink / raw)
To: Jesper Juhl
Cc: Eric Dumazet, linux-kernel, akpm, davem, netdev, shemminger,
daniel.baluta, jochen
In-Reply-To: <alpine.LNX.2.00.1101022356550.11481@swampdragon.chaosbits.net>
Am Montag, den 03.01.2011, 00:04 +0100 schrieb Jesper Juhl:
> On Sun, 2 Jan 2011, Stefani Seibold wrote:
>
> > Am Sonntag, den 02.01.2011, 23:49 +0100 schrieb Eric Dumazet:
> > > Le dimanche 02 janvier 2011 à 23:39 +0100, stefani@seibold.net a écrit :
> > > > +
> > > > +/*
> > > > + * Create a new destination descriptor for the given IPV4 address and port
> > > > + */
> > > > +static struct udpcp_dest *new_dest(struct sock *sk, __be32 addr, __be16 port)
> > > > +{
> > > > + struct udpcp_dest *dest;
> > > > + struct udpcp_sock *usk = udpcp_sk(sk);
> > > > +
> > > > + if (usk->connections >= udpcp_max_connections)
> > > > + return NULL;
> > > > +
> > > > + dest = kzalloc(sizeof(*dest), sk->sk_allocation);
> > > > +
> > > > + if (dest) {
> > > > + usk->connections++;
> > > > + skb_queue_head_init(&dest->xmit);
> > > > + dest->addr = addr;
> > > > + dest->port = port;
> > > > + dest->ackmode = UDPCP_ACK;
> > > > + list_add_tail(&dest->list, &usk->destlist);
> > > > + }
> > > > +
> > > > + return dest;
> > > > +}
> > > > +
> > >
> > > Hmm, so 'connections' is increased, never decreased.
> > >
> > > This seems a fatal flaw in this protocol, since a malicious user can
> > > easily fill the list with garbage, and block regular communications.
> >
> > You are right, there is now way to detect which connection is no longer
> > needed. I have not designed this protocol, so i cannot fix it.
> >
> > But in our environment this will be used together with an firewall
> > and/or ipsec. In this case it it safe.
> >
>
> Hmm, the first thing that springs into my head as a possible band-aid
> (which is probbaly wrong for many reasons I've not considered, so feel
> free to shoot it down) is; couldn't we use a timer (set to some outrageous
> high value by default and admin tunable) that would decrement
> 'connections' (discount dead connections) when there has not been any
> acctivity for a huge period of time? Kill off connections that have been
> idle for ages.
>
This will not work for two reasons:
- First there is no way to detect a dead connection. A connection can
stay for a very long time without data transfer.
- Second it will not save against a attack where all communication slots
will be eaten by an attacker and then new valid connections will be not
handled.
The only thing what is possible to make an ioctl call which allows the
user land client to cancel connections.
But this will be in my opinion dead code, because white lists of trusted
address must be fostered and this will make the upgrading of a
infrastructure to complicate.
^ permalink raw reply
* Re: [*v3 PATCH 02/22] IPVS: netns to services part 1
From: Hans Schillstrom @ 2011-01-03 9:14 UTC (permalink / raw)
To: Jan Engelhardt
Cc: hans@schillstrom.com, horms@verge.net.au, ja@ssi.bg,
daniel.lezcano@free.fr, wensong@linux-vs.org,
lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org
In-Reply-To: <alpine.LNX.2.01.1101011547040.9065@obet.zrqbmnf.qr>
On Sat, 2011-01-01 at 15:57 +0100, Jan Engelhardt wrote:
> On Thursday 2010-12-30 11:50, hans@schillstrom.com wrote:
> >+/*
> >+ * Get net ptr from skb in traffic cases
> >+ * use skb_sknet when call is from userland (ioctl or netlink)
> >+ */
> >+static inline struct net *skb_net(struct sk_buff *skb) {
> >+#ifdef CONFIG_NET_NS
> >+#ifdef CONFIG_IP_VS_DEBUG
> >+ /*
> >+ * This is used for debug only.
> >+ * Start with the most likely hit
> >+ * End with BUG
> >+ */
> >+ if (likely(skb->dev && skb->dev->nd_net))
> >+ return dev_net(skb->dev);
> >+ if (skb_dst(skb)->dev)
> >+ return dev_net(skb_dst(skb)->dev);
> >+ WARN(skb->sk,"Maybe skb_sknet should be used instead in %s() line:%d\n",
> >+ __func__, __LINE__);
> >+ if (likely(skb->sk && skb->sk->sk_net))
> >+ return sock_net(skb->sk);
> >+ pr_err("There is no net ptr to find in the skb in %s() line:%d\n",
> >+ __func__, __LINE__);
> >+ BUG();
> >+#else
> >+ return dev_net(skb->dev ? : skb_dst(skb)->dev);
> >+#endif
> >+#else
> >+ return &init_net;
> >+#endif
> >+}
>
> Whether NETNS is disabled or not, dev_net(skb->dev) can be used in either case,
> so the extra return &init_net case is not really required AFAICS.
OK, but the debug part will not compile without the ifdef since there is
some symbols that is #ifdef CONFIG_NET_NS.
"&init_net" is faster than the " ? : "
And the rest I guess is obvious.
>
> >@@ -3446,43 +3471,48 @@ static struct pernet_operations ipvs_control_ops = {
> >- smp_wmb();
> >+
> >+ smp_wmb(); /* Do wee really need it now ? */
>
> not "whee" :)
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Eric Dumazet @ 2011-01-03 9:27 UTC (permalink / raw)
To: Stefani Seibold
Cc: Jesper Juhl, linux-kernel, akpm, davem, netdev, shemminger,
daniel.baluta, jochen
In-Reply-To: <1294045732.19666.6.camel@wall-e>
Le lundi 03 janvier 2011 à 10:08 +0100, Stefani Seibold a écrit :
> This will not work for two reasons:
>
> - First there is no way to detect a dead connection. A connection can
> stay for a very long time without data transfer.
>
> - Second it will not save against a attack where all communication slots
> will be eaten by an attacker and then new valid connections will be not
> handled.
>
> The only thing what is possible to make an ioctl call which allows the
> user land client to cancel connections.
>
> But this will be in my opinion dead code, because white lists of trusted
> address must be fostered and this will make the upgrading of a
> infrastructure to complicate.
>
>
Yep, and as UDP messages can easily spoofed, this means you need more
than a list of trusted addresses. You also need to encapsulate the thing
in an secured layer.
Stefani, your implementation has very litle chance being added in
standard kernel, because it is not correctly layered, or documented.
Copying hundred (thousand ?) of lines from existing code only shows
there is a design error in your proposal. It means every time we have to
make a change in this code, we'll have to do it twice.
SUNRPC uses UDP/TCP sockets, and use callbacks to existing UDP/TCP code,
maybe you should take a look to implement an UDPCP stack in kernel.
For instance, a pure socket API seems not the correct choice for UDPCP,
since a transmit should give a report to user, of frame being
delivered/aknowledged or not to/by the remote side ?
With send(), this means you have only one message in transit, no
asynchronous handling.
At least you forgot to document the API, and restrictions.
^ permalink raw reply
* Re: [PATCH V8 08/13] posix clocks: cleanup the CLOCK_DISPTACH macro
From: Peter Zijlstra @ 2011-01-03 9:29 UTC (permalink / raw)
To: Richard Cochran
Cc: linux-kernel, linux-api, netdev, Alan Cox, Arnd Bergmann,
Christoph Lameter, David Miller, John Stultz, Krzysztof Halasa,
Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <503cd1fa268867573001cfc9bb5681ee3b5b32fa.1293820862.git.richard.cochran@omicron.at>
On Fri, 2010-12-31 at 20:15 +0100, Richard Cochran wrote:
> +#define CLOCK_DISPATCH(clock, call, arglist) dispatch_##call arglist
How about you run something like:
:% s/CLOCK_DISPATCH([^,]*, \([^,]*\), \([^)]*)\))/dispatch_\1\2/g
and remove that cruft all together?
^ permalink raw reply
* Re: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
From: Johannes Berg @ 2011-01-03 9:34 UTC (permalink / raw)
To: Tomas Winkler; +Cc: davem, netdev, Stephen Hemminger
In-Reply-To: <1293999538-9298-1-git-send-email-tomas.winkler@intel.com>
On Sun, 2011-01-02 at 22:18 +0200, Tomas Winkler wrote:
> icmp6h = icmp6_hdr(skb2);
>
> switch (icmp6h->icmp6_type) {
> @@ -1516,7 +1517,12 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
> switch (icmp6h->icmp6_type) {
> case ICMPV6_MGM_REPORT:
> {
> - struct mld_msg *mld = (struct mld_msg *)icmp6h;
> + struct mld_msg *mld;
> + if (!pskb_may_pull(skb2, sizeof(*mld))) {
> + err = -EINVAL;
> + goto out;
> + }
> + mld = (struct mld_msg *)icmp6h;
This (and the second instance) is incorrect afaict -- the pointer
"icmp6h" should be reloaded after the pskb_may_pull(), no?
Also, the "out_nopush" thing is pointless since the push is completely
unnecessary as "skb2 != skb" is always true.
johannes
^ permalink raw reply
* RE: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
From: Winkler, Tomas @ 2011-01-03 9:43 UTC (permalink / raw)
To: Johannes Berg
Cc: davem@davemloft.net, netdev@vger.kernel.org, Stephen Hemminger
In-Reply-To: <1294047254.4165.1.camel@jlt3.sipsolutions.net>
> -----Original Message-----
> From: Johannes Berg [mailto:johannes@sipsolutions.net]
> Sent: Monday, January 03, 2011 11:34 AM
> To: Winkler, Tomas
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Stephen Hemminger
> Subject: Re: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
>
> On Sun, 2011-01-02 at 22:18 +0200, Tomas Winkler wrote:
>
> > icmp6h = icmp6_hdr(skb2);
> >
> > switch (icmp6h->icmp6_type) {
> > @@ -1516,7 +1517,12 @@ static int br_multicast_ipv6_rcv(struct net_bridge
> *br,
> > switch (icmp6h->icmp6_type) {
> > case ICMPV6_MGM_REPORT:
> > {
> > - struct mld_msg *mld = (struct mld_msg *)icmp6h;
> > + struct mld_msg *mld;
> > + if (!pskb_may_pull(skb2, sizeof(*mld))) {
> > + err = -EINVAL;
> > + goto out;
> > + }
> > + mld = (struct mld_msg *)icmp6h;
>
> This (and the second instance) is incorrect afaict -- the pointer
> "icmp6h" should be reloaded after the pskb_may_pull(), no?
mld_msg is bigger than icmp6h by sizeof(in6_addr) so we have to try pull again a bigger chunk.
>
> Also, the "out_nopush" thing is pointless since the push is completely
> unnecessary as "skb2 != skb" is always true.
You are right if skb_clone doesn't return the same pointer then yes. Shame, but I'm not a sbk expert. I'm diving into it now.
Thanks
Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Stefani Seibold @ 2011-01-03 9:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Juhl, linux-kernel, akpm, davem, netdev, shemminger,
daniel.baluta, jochen
In-Reply-To: <1294046867.2892.101.camel@edumazet-laptop>
Am Montag, den 03.01.2011, 10:27 +0100 schrieb Eric Dumazet:
> Le lundi 03 janvier 2011 à 10:08 +0100, Stefani Seibold a écrit :
>
> > This will not work for two reasons:
> >
> > - First there is no way to detect a dead connection. A connection can
> > stay for a very long time without data transfer.
> >
> > - Second it will not save against a attack where all communication slots
> > will be eaten by an attacker and then new valid connections will be not
> > handled.
> >
> > The only thing what is possible to make an ioctl call which allows the
> > user land client to cancel connections.
> >
> > But this will be in my opinion dead code, because white lists of trusted
> > address must be fostered and this will make the upgrading of a
> > infrastructure to complicate.
> >
> >
>
> Yep, and as UDP messages can easily spoofed, this means you need more
> than a list of trusted addresses. You also need to encapsulate the thing
> in an secured layer.
>
> Stefani, your implementation has very litle chance being added in
> standard kernel, because it is not correctly layered, or documented.
>
> Copying hundred (thousand ?) of lines from existing code only shows
> there is a design error in your proposal. It means every time we have to
> make a change in this code, we'll have to do it twice.
>
I copied about 400 of 3000 lines with was heavy modified to need my
needs. And i use only document features of the linux IP stack. So it is
normal to have duplicate code for the basics.
How can you do a routing, how can you determinate the MTU of the route.
This are basics. Look into other code how this things will be handled is
in my opinion the right way, since there a no function provide to do
this.
Otherwise you can say the same about all the filesystem or PCI
drvivers , which do also a lot in the same way. But since this is the
way to do it, it is the right way.
> SUNRPC uses UDP/TCP sockets, and use callbacks to existing UDP/TCP code,
> maybe you should take a look to implement an UDPCP stack in kernel.
>
I have looked around the whole LINUX source code, also in the SUNRPC
sockets and i did not found anything which meet my needs.
> For instance, a pure socket API seems not the correct choice for UDPCP,
> since a transmit should give a report to user, of frame being
> delivered/aknowledged or not to/by the remote side ?
>
This will be done through the error queue. The user client will receive
the unhandled packets back.
> With send(), this means you have only one message in transit, no
> asynchronous handling.
>
No, the messages will be queued. You can have more than a messages in
the send queue.
> At least you forgot to document the API, and restrictions.
>
API documentation is still there, i can these provide under
Documentation/udpcp.txt if you like.
Here is the API documentation:
Socket interface programming manual
The socket interface is a derivate of the UDP sockets. All setsockopt(),
getsockopt() and ioctl() kernel system calls which are valid for UDP
sockets should work on UDPCP sockets. There are some extensions to the
sockopt and ioctl interface for the UDPCP sockets.
Include the C header file <net/udpcp.h> to use the UDPCP socket options
and ioctl calls.
A UDPCP can be opened with socket(PF_INET, SOCK_DGRAM, PF_UDPCP). All
operation which are valid for UDP sockets can also performed with UDPCP
sockets.
sockopt
The setsockopt and getsockopt are defined as following:
int getsockopt(int sockfd, int level, int optname, void *optval,
socklen_t *optlen);
int setsockopt(int sockfd, int level, int optname, const void *optval,
socklen_t optlen);
The level parameter for the UDPCP socket is SOL_UDPCP, where the
following options are defined:
UDPCP_OPT_TRANSFER_MODE - set default transfer mode. The optval is one
of the following:
UDPCP_NOACK - no ACK for the transmitted message is requiered
UDPCP_ACK - a ACK for each transmitted message fragment is requiered
UDPCP_SINGLE_ACK - only a ACK for the last transmitted message fragment
is requiered
UDPCP_OPT_CHECKSUM_MODE - set the default checksum mode. The optval is
one of the following:
UDPCP_NOCHECKSUM - no checksum for the transmitted message is required
UDPCP_CHECKSUM - a checksum test for the transmitted message is required
UDPCP_OPT_TX_TIMEOUT - the timeout for a awaited ACK in milliseconds.
The optval should between >= 1 and max. UDPCP_MAX_WAIT_SEC * 1000
UDPCP_OPT_RX_TIMEOUT - timeout for a outstanding incoming message
fragment in milliseconds.
The optval should between >= 1 and max. UDPCP_MAX_WAIT_SEC * 1000
UDPCP_OPT_MAXTRY - the number of tries to send a message fragment.
The optval should between >= 1 and <= 10
UDPCP_OPT_OUTSTANDING_ACKS: the number of outstanding acks.
The optval should between >=1 and <= 255
All optlen parameters are int's. There the optlen should be
sizeof(optlen).
The values UDPCP_NOACK, UDPCP_ACK, UDPCP_SINGLE_ACK, UDPCP_NOCHECKSUM
and
UDPCP_CHECKSUM can also passed as control message with sendmsg(). For
details look at the manual page for sendmsg().
ioctl interface
The ioctl function call is defined as
int ioctl(int d, int request, ...)
For UDPCP sockets there are the following request commands defined:
UDPCP_IOCTL_GET_STATISTICS
This command returns the statistics of the socket in a struct
udpcp_statistics. The address of this struct must be passed as third
argument.
UDPCP_IOCTL_RESET_STATISTICS
This command resets the statistics of the socket
UDPCP_IOCTL_SYNC
This command waits until all message fragments are transmitted. If the
third argument is not zero, this is the max. timeout value in
milliseconds, otherwise this call can block indefinitely.
^ permalink raw reply
* RE: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
From: Johannes Berg @ 2011-01-03 10:04 UTC (permalink / raw)
To: Winkler, Tomas
Cc: davem@davemloft.net, netdev@vger.kernel.org, Stephen Hemminger
In-Reply-To: <6F5C1D715B2DA5498A628E6B9C124F04019BF9E404@hasmsx504.ger.corp.intel.com>
On Mon, 2011-01-03 at 11:43 +0200, Winkler, Tomas wrote:
> > > - struct mld_msg *mld = (struct mld_msg *)icmp6h;
> > > + struct mld_msg *mld;
> > > + if (!pskb_may_pull(skb2, sizeof(*mld))) {
> > > + err = -EINVAL;
> > > + goto out;
> > > + }
> > > + mld = (struct mld_msg *)icmp6h;
> >
> > This (and the second instance) is incorrect afaict -- the pointer
> > "icmp6h" should be reloaded after the pskb_may_pull(), no?
>
> mld_msg is bigger than icmp6h by sizeof(in6_addr) so we have to try pull again a bigger chunk.
Right, I know, the pskb_may_pull() is needed, but I believe you need to
re-calculate icmp6h here.
> > Also, the "out_nopush" thing is pointless since the push is completely
> > unnecessary as "skb2 != skb" is always true.
>
> You are right if skb_clone doesn't return the same pointer then yes.
> Shame, but I'm not a sbk expert. I'm diving into it now.
I'm pretty sure it's guaranteed to return a new pointer.
johannes
^ permalink raw reply
* RE: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
From: Winkler, Tomas @ 2011-01-03 10:17 UTC (permalink / raw)
To: Johannes Berg
Cc: davem@davemloft.net, netdev@vger.kernel.org, Stephen Hemminger
In-Reply-To: <1294049058.4165.3.camel@jlt3.sipsolutions.net>
> -----Original Message-----
> From: Johannes Berg [mailto:johannes@sipsolutions.net]
> Sent: Monday, January 03, 2011 12:04 PM
> To: Winkler, Tomas
> Cc: davem@davemloft.net; netdev@vger.kernel.org; Stephen Hemminger
> Subject: RE: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
>
> On Mon, 2011-01-03 at 11:43 +0200, Winkler, Tomas wrote:
>
> > > > - struct mld_msg *mld = (struct mld_msg *)icmp6h;
> > > > + struct mld_msg *mld;
> > > > + if (!pskb_may_pull(skb2, sizeof(*mld))) {
> > > > + err = -EINVAL;
> > > > + goto out;
> > > > + }
> > > > + mld = (struct mld_msg *)icmp6h;
> > >
> > > This (and the second instance) is incorrect afaict -- the pointer
> > > "icmp6h" should be reloaded after the pskb_may_pull(), no?
> >
> > mld_msg is bigger than icmp6h by sizeof(in6_addr) so we have to try pull
> again a bigger chunk.
>
> Right, I know, the pskb_may_pull() is needed, but I believe you need to
> re-calculate icmp6h here.
You are right, it can be moved to new memory buffer.
Probably something like that will do it:
if (!pskb_may_pull(skb2, sizeof(*mld))) {
err = -EINVAL;
goto out;
}
mld = (struct mld_msg *)skb_transport_header(skb2)
>
> > > Also, the "out_nopush" thing is pointless since the push is completely
> > > unnecessary as "skb2 != skb" is always true.
> >
> > You are right if skb_clone doesn't return the same pointer then yes.
> > Shame, but I'm not a sbk expert. I'm diving into it now.
>
> I'm pretty sure it's guaranteed to return a new pointer.
Right, it either returns skb + 1 or new one from the cache. We can drop the nopush section.
Thanks
Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* [PATCH] ll_temac: Fix section mismatch from the temac_of_probe
From: Michal Simek @ 2011-01-03 10:32 UTC (permalink / raw)
To: grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Replace __init by __devinit.
Warning message:
WARNING: vmlinux.o(.data+0xbc14): Section mismatch in reference from the variable
temac_of_driver to the function .init.text:temac_of_probe()
The variable temac_of_driver references
the function __init temac_of_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
---
drivers/net/ll_temac_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index 9f8e702..beb6ed8 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -952,7 +952,7 @@ static const struct attribute_group temac_attr_group = {
.attrs = temac_device_attrs,
};
-static int __init
+static int __devinit
temac_of_probe(struct platform_device *op, const struct of_device_id *match)
{
struct device_node *np;
--
1.5.5.6
^ permalink raw reply related
* [PATCH V4] bridge: fix br_multicast_ipv6_rcv for paged skbs
From: Tomas Winkler @ 2011-01-03 10:38 UTC (permalink / raw)
To: davem; +Cc: netdev, Tomas Winkler, Johannes Berg, Stephen Hemminger
In-Reply-To: <1294051080-29492-1-git-send-email-tomas.winkler@intel.com>
use pskb_may_pull to access ipv6 header correctly for paged skbs
It was omitted in the bridge code leading to crash in blind
__skb_pull
since the skb is cloned undonditionally we also simplify the
the exit path
this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.122712]
Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01087d8>] ? sched_clock+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0138264>] ? enqueue_entity+0x174/0x440
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e451>] ? sched_clock_cpu+0x131/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0524fc1>] ? nf_iterate+0x71/0x90
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04f7a30>] ? skb_copy_bits+0x110/0x210
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e242>] ? sched_clock_local+0xb2/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c012b688>] ? default_spin_lock_flags+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150d05>] ? tasklet_action+0xc5/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150a07>] ? __do_softirq+0x97/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150970>] ? __do_softirq+0x0/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] <IRQ>
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01508f5>] ? irq_exit+0x65/0x70
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05df062>] ? do_IRQ+0x52/0xc0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01036b0>] ? common_interrupt+0x30/0x38
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c03a1fc2>] ? intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ? cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ? start_secondary+0x1e8/0x1ee
Cc: David Miller <davem@davemloft.net>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
V2: Implement David Miller's suggestion
V3: Fix the mld_msg access:
Length check was wrong and psk_may_pull performs itself the length check
V4: mld_msg pointer need to be recalculated after pull
simplify the exit path
net/bridge/br_multicast.c | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f19e347..67296b7 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1430,7 +1430,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
struct net_bridge_port *port,
struct sk_buff *skb)
{
- struct sk_buff *skb2 = skb;
+ struct sk_buff *skb2;
struct ipv6hdr *ip6h;
struct icmp6hdr *icmp6h;
u8 nexthdr;
@@ -1469,15 +1469,16 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
if (!skb2)
return -ENOMEM;
+
+ err = -EINVAL;
+ if (!pskb_may_pull(skb2, offset + sizeof(struct icmp6hdr)))
+ goto out;
+
len -= offset - skb_network_offset(skb2);
__skb_pull(skb2, offset);
skb_reset_transport_header(skb2);
- err = -EINVAL;
- if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
- goto out;
-
icmp6h = icmp6_hdr(skb2);
switch (icmp6h->icmp6_type) {
@@ -1516,7 +1517,12 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
switch (icmp6h->icmp6_type) {
case ICMPV6_MGM_REPORT:
{
- struct mld_msg *mld = (struct mld_msg *)icmp6h;
+ struct mld_msg *mld;
+ if (!pskb_may_pull(skb2, sizeof(*mld))) {
+ err = -EINVAL;
+ goto out;
+ }
+ mld = (struct mld_msg *)skb_transport_header(skb2);
BR_INPUT_SKB_CB(skb2)->mrouters_only = 1;
err = br_ip6_multicast_add_group(br, port, &mld->mld_mca);
break;
@@ -1529,15 +1535,18 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
break;
case ICMPV6_MGM_REDUCTION:
{
- struct mld_msg *mld = (struct mld_msg *)icmp6h;
+ struct mld_msg *mld;
+ if (!pskb_may_pull(skb2, sizeof(*mld))) {
+ err = -EINVAL;
+ goto out;
+ }
+ mld = (struct mld_msg *)skb_transport_header(skb2);
br_ip6_multicast_leave_group(br, port, &mld->mld_mca);
}
}
out:
- __skb_push(skb2, offset);
- if (skb2 != skb)
- kfree_skb(skb2);
+ kfree_skb(skb2);
return err;
}
#endif
--
1.7.3.4
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [PATCH V4] bridge: fix br_multicast_ipv6_rcv for paged skbs
From: Tomas Winkler @ 2011-01-03 10:37 UTC (permalink / raw)
To: davem; +Cc: netdev, Tomas Winkler, Johannes Berg, Stephen Hemminger
use pskb_may_pull to access ipv6 header correctly for paged skbs
It was omitted in the bridge code leading to crash in blind
__skb_pull
since the skb is cloned undonditionally we also simplify the
the exit path
this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: approvals binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.122712]
Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01087d8>] ? sched_clock+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0138264>] ? enqueue_entity+0x174/0x440
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e451>] ? sched_clock_cpu+0x131/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0524fc1>] ? nf_iterate+0x71/0x90
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04f7a30>] ? skb_copy_bits+0x110/0x210
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e242>] ? sched_clock_local+0xb2/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c012b688>] ? default_spin_lock_flags+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150d05>] ? tasklet_action+0xc5/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150a07>] ? __do_softirq+0x97/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150970>] ? __do_softirq+0x0/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] <IRQ>
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01508f5>] ? irq_exit+0x65/0x70
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05df062>] ? do_IRQ+0x52/0xc0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01036b0>] ? common_interrupt+0x30/0x38
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c03a1fc2>] ? intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ? cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ? start_secondary+0x1e8/0x1ee
Cc: David Miller <davem@davemloft.net>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
V2: Implement David Miller's suggestion
V3: Fix the mld_msg access:
Length check was wrong and psk_may_pull performs itself the length check
V4: mld_msg pointer need to be recalculated after pull
simplify the exit path
net/bridge/br_multicast.c | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f19e347..67296b7 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1430,7 +1430,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
struct net_bridge_port *port,
struct sk_buff *skb)
{
- struct sk_buff *skb2 = skb;
+ struct sk_buff *skb2;
struct ipv6hdr *ip6h;
struct icmp6hdr *icmp6h;
u8 nexthdr;
@@ -1469,15 +1469,16 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
if (!skb2)
return -ENOMEM;
+
+ err = -EINVAL;
+ if (!pskb_may_pull(skb2, offset + sizeof(struct icmp6hdr)))
+ goto out;
+
len -= offset - skb_network_offset(skb2);
__skb_pull(skb2, offset);
skb_reset_transport_header(skb2);
- err = -EINVAL;
- if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
- goto out;
-
icmp6h = icmp6_hdr(skb2);
switch (icmp6h->icmp6_type) {
@@ -1516,7 +1517,12 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
switch (icmp6h->icmp6_type) {
case ICMPV6_MGM_REPORT:
{
- struct mld_msg *mld = (struct mld_msg *)icmp6h;
+ struct mld_msg *mld;
+ if (!pskb_may_pull(skb2, sizeof(*mld))) {
+ err = -EINVAL;
+ goto out;
+ }
+ mld = (struct mld_msg *)skb_transport_header(skb2);
BR_INPUT_SKB_CB(skb2)->mrouters_only = 1;
err = br_ip6_multicast_add_group(br, port, &mld->mld_mca);
break;
@@ -1529,15 +1535,18 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
break;
case ICMPV6_MGM_REDUCTION:
{
- struct mld_msg *mld = (struct mld_msg *)icmp6h;
+ struct mld_msg *mld;
+ if (!pskb_may_pull(skb2, sizeof(*mld))) {
+ err = -EINVAL;
+ goto out;
+ }
+ mld = (struct mld_msg *)skb_transport_header(skb2);
br_ip6_multicast_leave_group(br, port, &mld->mld_mca);
}
}
out:
- __skb_push(skb2, offset);
- if (skb2 != skb)
- kfree_skb(skb2);
+ kfree_skb(skb2);
return err;
}
#endif
--
1.7.3.4
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: [PATCH] new UDPCP Communication Protocol
From: Eric Dumazet @ 2011-01-03 10:39 UTC (permalink / raw)
To: Stefani Seibold
Cc: Jesper Juhl, linux-kernel, akpm, davem, netdev, shemminger,
daniel.baluta, jochen
In-Reply-To: <1294048469.20187.13.camel@wall-e>
Le lundi 03 janvier 2011 à 10:54 +0100, Stefani Seibold a écrit :
> How can you do a routing, how can you determinate the MTU of the route.
> This are basics. Look into other code how this things will be handled is
> in my opinion the right way, since there a no function provide to do
> this.
>
Hmm, how user land can perform this task then ?
Is there an open source implementation of UDPCP ?
What are its problems ? You say its dog slow, I really wonder why.
UDP stack is pretty scalable these days, yet some improvements are
possible.
Why not adding generic helpers if you believe you miss some
infrastructure ? This could benefit to other 'stacks' as well.
> Otherwise you can say the same about all the filesystem or PCI
> drvivers , which do also a lot in the same way. But since this is the
> way to do it, it is the right way.
>
These drivers are here because of high performance on top of high
performance specs.
While UDPCP is only a layer above UDP. If the problem comes from UDP
being too slow, it'll be slow too.
^ permalink raw reply
* RE: [PATCH 1/1 V3] bridge: fix br_multicast_ipv6_rcv for paged skbs
From: Johannes Berg @ 2011-01-03 10:41 UTC (permalink / raw)
To: Winkler, Tomas
Cc: davem@davemloft.net, netdev@vger.kernel.org, Stephen Hemminger
In-Reply-To: <6F5C1D715B2DA5498A628E6B9C124F04019BF9E48E@hasmsx504.ger.corp.intel.com>
On Mon, 2011-01-03 at 12:17 +0200, Winkler, Tomas wrote:
> > > > > - struct mld_msg *mld = (struct mld_msg *)icmp6h;
> > > > > + struct mld_msg *mld;
> > > > > + if (!pskb_may_pull(skb2, sizeof(*mld))) {
> > > > > + err = -EINVAL;
> > > > > + goto out;
> > > > > + }
> > > > > + mld = (struct mld_msg *)icmp6h;
> > > >
> > > > This (and the second instance) is incorrect afaict -- the pointer
> > > > "icmp6h" should be reloaded after the pskb_may_pull(), no?
> > >
> > > mld_msg is bigger than icmp6h by sizeof(in6_addr) so we have to try pull
> > again a bigger chunk.
> >
> > Right, I know, the pskb_may_pull() is needed, but I believe you need to
> > re-calculate icmp6h here.
>
> You are right, it can be moved to new memory buffer.
>
> Probably something like that will do it:
>
> if (!pskb_may_pull(skb2, sizeof(*mld))) {
> err = -EINVAL;
> goto out;
> }
> mld = (struct mld_msg *)skb_transport_header(skb2)
Yeah, that'll do, although I see more callers of icmp6_hdr() here
instead even for mld stuff (which is an inline though doing just this)
johannes
^ permalink raw reply
* Re: [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: Changli Gao @ 2011-01-03 10:44 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, bridge, netdev
In-Reply-To: <20101231.111003.48499853.davem@davemloft.net>
On Sat, Jan 1, 2011 at 3:10 AM, David Miller <davem@davemloft.net> wrote:
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Sat, 25 Dec 2010 21:41:30 +0800
>
>> Since nf_bridge_maybe_copy_header() may change the length of skb,
>> we should check the length of skb after it to handle the ppoe skbs.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> This is really strange.
>
> packet_length() subtracts VLAN_HLEN from the value it returns, so the
> correct fix seems to be to make this function handle the PPPOE case
> too.
>
It is correct. The actual MTU of 802.1q frame is 4 bytes larger. For
example, the MTU of ethernet is normally 1500, however the actual MTU
of the 802.1Q is 1504.
Please see this patch:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=c893b8066c7bf6156e4d760e5acaf4c148e37190;hp=3c0fef0b7d36e5f8d3ea3731a8228102274e3c23
> Otherwise I suspect you have many other functions to fix as well.
>
> I'm not applying this patch.
>
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH V8 08/13] posix clocks: cleanup the CLOCK_DISPTACH macro
From: Richard Cochran @ 2011-01-03 11:51 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Alan Cox, Arnd Bergmann, Christoph Lameter, David Miller,
John Stultz, Krzysztof Halasa, Rodolfo Giometti, Thomas Gleixner
In-Reply-To: <1294046949.2016.36.camel@laptop>
On Mon, Jan 03, 2011 at 10:29:09AM +0100, Peter Zijlstra wrote:
> On Fri, 2010-12-31 at 20:15 +0100, Richard Cochran wrote:
> > +#define CLOCK_DISPATCH(clock, call, arglist) dispatch_##call arglist
>
> How about you run something like:
>
> :% s/CLOCK_DISPATCH([^,]*, \([^,]*\), \([^)]*)\))/dispatch_\1\2/g
>
> and remove that cruft all together?
Gladly ;^)
Richard
^ permalink raw reply
* RE: [net-next-2.6 04/08] r8169: 8168DP specific MII registers access methods.
From: hayeswang @ 2011-01-03 12:30 UTC (permalink / raw)
To: 'Francois Romieu', davem; +Cc: netdev, 'Ben Hutchings'
In-Reply-To: <20110102233704.GE5780@electric-eye.fr.zoreil.com>
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Monday, January 03, 2011 7:37 AM
> To: davem@davemloft.net
> Cc: netdev@vger.kernel.org; Hayeswang; Ben Hutchings
> Subject: [net-next-2.6 04/08] r8169: 8168DP specific MII
> registers access methods.
>
> Adapted from version 8.019.00 of Realtek's r8168 driver.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Hayes <hayeswang@realtek.com>
> ---
> drivers/net/r8169.c | 83
> +++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 81 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c index
> f9d8ff0..7f6fd12 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -277,6 +277,20 @@ enum rtl8168_8101_registers {
> #define EFUSEAR_DATA_MASK 0xff
> };
>
> +enum rtl8168_registers {
> + EPHY_RXER_NUM = 0x7c,
> + OCPDR = 0xb0, /* OCP GPHY access */
> +#define OCPDR_WRITE_CMD 0x80000000
> +#define OCPDR_READ_CMD 0x00000000
> +#define OCPDR_REG_MASK 0xff
> +#define OCPDR_GPHY_REG_SHIFT 12
The source code of realtek makes a mistake. The value of OCPDR_GPHY_REG_SHIFT
must be 16, not 12. The reg should be at bit 16 ~ 22.
> +#define OCPDR_DATA_MASK 0xffff
> + OCPAR = 0xb4,
> +#define OCPAR_FLAG 0x80000000
> +#define OCPAR_GPHY_WRITE_CMD 0x8000f060
> +#define OCPAR_GPHY_READ_CMD 0x0000f060
> +};
> +
^ permalink raw reply
* RE: [net-next-2.6 08/08] r8169: more 8168dp support.
From: hayeswang @ 2011-01-03 12:50 UTC (permalink / raw)
To: 'Francois Romieu', davem; +Cc: netdev, 'Ben Hutchings'
In-Reply-To: <20110102233751.GI5780@electric-eye.fr.zoreil.com>
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Monday, January 03, 2011 7:38 AM
> To: davem@davemloft.net
> Cc: netdev@vger.kernel.org; Hayeswang; Ben Hutchings
> Subject: [net-next-2.6 08/08] r8169: more 8168dp support.
>
> Adapted from version 8.019.00 of Realtek's r8168 driver
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Hayes <hayeswang@realtek.com>
> ---
> @@ -3038,8 +3104,10 @@ static void __devexit
> rtl8169_remove_one(struct pci_dev *pdev)
> struct net_device *dev = pci_get_drvdata(pdev);
> struct rtl8169_private *tp = netdev_priv(dev);
>
> - if (tp->mac_version == RTL_GIGA_MAC_VER_27)
> + if ((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
> + (tp->mac_version == RTL_GIGA_MAC_VER_28)) {
> rtl8168_driver_stop(tp);
> + }
>
> cancel_delayed_work_sync(&tp->task);
>
> @@ -3122,11 +3190,19 @@ err_pm_runtime_put:
> goto out;
> }
>
> -static void rtl8169_hw_reset(void __iomem *ioaddr)
> +static void rtl8169_hw_reset(struct rtl8169_private *tp)
> {
> + void __iomem *ioaddr = tp->mmio_addr;
> +
> /* Disable interrupts */
> rtl8169_irq_mask_and_ack(ioaddr);
>
> + if (tp->mac_version == RTL_GIGA_MAC_VER_28) {
This check should include RTL_GIGA_MAC_VER_27.
> + while (RTL_R8(TxPoll) & NPQ)
> + udelay(20);
> +
> + }
> +
> /* Reset the chipset */
> RTL_W8(ChipCmd, CmdReset);
>
After the reset, there are something to do for RTL_GIGA_MAC_VER_27. You may
check the soure code of realtek. Find "rtl8168_nic_reset".
Best Regards,
Hayes
^ permalink raw reply
* Re: [RFC] net_sched: mark packet staying on queue too long
From: jamal @ 2011-01-03 13:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jarek Poplawski, David Miller, Jesper Dangaard Brouer,
Patrick McHardy, netdev
In-Reply-To: <1294003631.2535.253.camel@edumazet-laptop>
On Sun, 2011-01-02 at 22:27 +0100, Eric Dumazet wrote:
> While playing with SFQ and other AQM, I was bothered to see how easy it
> was for a single tcp flow to 'fill the pipe' and consume lot of memory
> buffers in queues. I know Jesper use more than 50.000 SFQ on his
> routers, and with GRO packets this can consume a lot of memory.
>
> I played a bit adding ECN in SFQ, first by marking packets for a
> particular flow if this flow qlen was above a given threshold, and later
> using another trick : ECN mark packet if it stayed longer than a given
> delay in the queue. This of course could be done on other modules, what
> do you think ?
>
I think for this to be effective, it would require maintaining some
history of the effect (some form of moving window average)
and probably a randomness in marking instead of a deterministic one.
Something like what Stochastic Fair RED/BLUE Queueing does.
Otherwise you get a burst of marked packets then silence then a burst
etc (i.e the classical synchronization effect).
It would probably be more effective to provide feedback to the local tcp
since we can detect this locally instead of waiting to some round trip
(or half roundtrip) effect at the receiver with ECN i.e in the same
spirit as NET_XMIT_CN but for which local TCP does something useful with
that info (instead of "retransmit shortly"). But even that would require
maintaining some state on the scheduler per hash in this case....
cheers,
jamal
^ permalink raw reply
* Re: [RFC] net_sched: mark packet staying on queue too long
From: Eric Dumazet @ 2011-01-03 14:02 UTC (permalink / raw)
To: hadi
Cc: Jarek Poplawski, David Miller, Jesper Dangaard Brouer,
Patrick McHardy, netdev
In-Reply-To: <1294062755.2472.11.camel@mojatatu>
Le lundi 03 janvier 2011 à 08:52 -0500, jamal a écrit :
> On Sun, 2011-01-02 at 22:27 +0100, Eric Dumazet wrote:
> > While playing with SFQ and other AQM, I was bothered to see how easy it
> > was for a single tcp flow to 'fill the pipe' and consume lot of memory
> > buffers in queues. I know Jesper use more than 50.000 SFQ on his
> > routers, and with GRO packets this can consume a lot of memory.
> >
> > I played a bit adding ECN in SFQ, first by marking packets for a
> > particular flow if this flow qlen was above a given threshold, and later
> > using another trick : ECN mark packet if it stayed longer than a given
> > delay in the queue. This of course could be done on other modules, what
> > do you think ?
> >
>
> I think for this to be effective, it would require maintaining some
> history of the effect (some form of moving window average)
> and probably a randomness in marking instead of a deterministic one.
> Something like what Stochastic Fair RED/BLUE Queueing does.
> Otherwise you get a burst of marked packets then silence then a burst
> etc (i.e the classical synchronization effect).
>
I got fairly good results here, but admit-idly on a LAN.
Yep, maybe adding RED on each SFQ slot ;) Should be fairly cheap, and
actually needed in case ECN is not possible and we must earlly drop
instead.
I found BLUE very expensive in term of cache line accesses. Especially
with double hashing.
> It would probably be more effective to provide feedback to the local tcp
> since we can detect this locally instead of waiting to some round trip
> (or half roundtrip) effect at the receiver with ECN i.e in the same
> spirit as NET_XMIT_CN but for which local TCP does something useful with
> that info (instead of "retransmit shortly"). But even that would require
> maintaining some state on the scheduler per hash in this case....
>
local tcp, for a router ? Hmm... But yes I see your point.
Speaking of ECN marking, it seems we (in RED/GRED or tunnels) change skb
data even if it is shared (can happen on ingress path)
Probably harmless, but tcpdump can show ECN bit being marked even on skb
snapshot before ingress (and later, ECN marked) or tunnels, while it
came unset from the wire.
Is it worth fixing this ? maybe using skb_make_writable() [once moved to
core network from netfilter]
^ permalink raw reply
* Re: [PATCH] new UDPCP Communication Protocol
From: Stefani Seibold @ 2011-01-03 14:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesper Juhl, linux-kernel, akpm, davem, netdev, shemminger,
daniel.baluta, jochen
In-Reply-To: <1294051199.2892.198.camel@edumazet-laptop>
Am Montag, den 03.01.2011, 11:39 +0100 schrieb Eric Dumazet:
> Le lundi 03 janvier 2011 à 10:54 +0100, Stefani Seibold a écrit :
>
> > How can you do a routing, how can you determinate the MTU of the route.
> > This are basics. Look into other code how this things will be handled is
> > in my opinion the right way, since there a no function provide to do
> > this.
> >
>
> Hmm, how user land can perform this task then ?
>
Userspace is much more complicate and more overhead than kernel space.
The UDPCP implementation in userspace is about the factor 10 slower.
> Is there an open source implementation of UDPCP ?
>
I don't know any. These is the first one.
> What are its problems ? You say its dog slow, I really wonder why.
> UDP stack is pretty scalable these days, yet some improvements are
> possible.
>
UDP is fast... but UDPCP depends extremely on latency due the missing of
sliding windows.
> Why not adding generic helpers if you believe you miss some
> infrastructure ? This could benefit to other 'stacks' as well.
>
Maybe i don't have the knowledge, maybe i don't have the time. Getting
in new API functions into LINUX is much more complicate than getting new
driver into LINUX. I know what i am talk, it takes me one year to the
new kfifo API (kfifo.c, kfifo.h) into the kernel.
> > Otherwise you can say the same about all the filesystem or PCI
> > drvivers , which do also a lot in the same way. But since this is the
> > way to do it, it is the right way.
> >
>
> These drivers are here because of high performance on top of high
> performance specs.
>
> While UDPCP is only a layer above UDP. If the problem comes from UDP
> being too slow, it'll be slow too.
>
Because of latency. Handling the UDPCP into the data_read() bh function
is much faster:
- No context switch
- Assembly Multi-Fragment Message is very efficient using skb buffer
chaining.
- Immediately handling an ack or data message save a lot of latency
Implementing it in User Space is to slow, due the context switches. Also
the sunrpc approach is not faster due the using of kernel threads which
are not better than user space (okay, a little bit because not switching
the MMU).
The implementation is clean. I did fix all issues what i was asked for.
The protocol has now absolut no side effects. So i ask again for merge
into linux-next.
- Stefani
^ 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