* [PATCH net-next 09/14] net: cdc_ncm: export shared symbols and definitions
From: Bjørn Mork @ 2012-10-18 20:41 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum,
Greg Kroah-Hartman, Alexey Orishko, Greg Suarez,
Fangxiaozhi (Franko), Dan Williams, Aleksander Morgado,
Bjørn Mork
In-Reply-To: <1350592867-25651-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
Move symbols and definitons which can be shared with a
MBIM driver in a new header.
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
drivers/net/usb/cdc_ncm.c | 97 ++++-----------------------------
include/linux/usb/cdc_ncm.h | 124 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 135 insertions(+), 86 deletions(-)
create mode 100644 include/linux/usb/cdc_ncm.h
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index aeebf7c..0c941ef 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -51,90 +51,10 @@
#include <linux/atomic.h>
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc.h>
+#include <linux/usb/cdc_ncm.h>
#define DRIVER_VERSION "14-Mar-2012"
-/* CDC NCM subclass 3.2.1 */
-#define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
-
-/* Maximum NTB length */
-#define CDC_NCM_NTB_MAX_SIZE_TX 32768 /* bytes */
-#define CDC_NCM_NTB_MAX_SIZE_RX 32768 /* bytes */
-
-/* Minimum value for MaxDatagramSize, ch. 6.2.9 */
-#define CDC_NCM_MIN_DATAGRAM_SIZE 1514 /* bytes */
-
-/* Minimum value for MaxDatagramSize, ch. 8.1.3 */
-#define CDC_MBIM_MIN_DATAGRAM_SIZE 2048 /* bytes */
-
-#define CDC_NCM_MIN_TX_PKT 512 /* bytes */
-
-/* Default value for MaxDatagramSize */
-#define CDC_NCM_MAX_DATAGRAM_SIZE 8192 /* bytes */
-
-/*
- * Maximum amount of datagrams in NCM Datagram Pointer Table, not counting
- * the last NULL entry.
- */
-#define CDC_NCM_DPT_DATAGRAMS_MAX 40
-
-/* Restart the timer, if amount of datagrams is less than given value */
-#define CDC_NCM_RESTART_TIMER_DATAGRAM_CNT 3
-#define CDC_NCM_TIMER_PENDING_CNT 2
-#define CDC_NCM_TIMER_INTERVAL (400UL * NSEC_PER_USEC)
-
-/* The following macro defines the minimum header space */
-#define CDC_NCM_MIN_HDR_SIZE \
- (sizeof(struct usb_cdc_ncm_nth16) + sizeof(struct usb_cdc_ncm_ndp16) + \
- (CDC_NCM_DPT_DATAGRAMS_MAX + 1) * sizeof(struct usb_cdc_ncm_dpe16))
-
-#define CDC_NCM_NDP_SIZE \
- (sizeof(struct usb_cdc_ncm_ndp16) + \
- (CDC_NCM_DPT_DATAGRAMS_MAX + 1) * sizeof(struct usb_cdc_ncm_dpe16))
-
-struct cdc_ncm_ctx {
- struct usb_cdc_ncm_ntb_parameters ncm_parm;
- struct hrtimer tx_timer;
- struct tasklet_struct bh;
-
- const struct usb_cdc_ncm_desc *func_desc;
- const struct usb_cdc_mbim_desc *mbim_desc;
- const struct usb_cdc_header_desc *header_desc;
- const struct usb_cdc_union_desc *union_desc;
- const struct usb_cdc_ether_desc *ether_desc;
-
- struct net_device *netdev;
- struct usb_device *udev;
- struct usb_host_endpoint *in_ep;
- struct usb_host_endpoint *out_ep;
- struct usb_host_endpoint *status_ep;
- struct usb_interface *intf;
- struct usb_interface *control;
- struct usb_interface *data;
-
- struct sk_buff *tx_curr_skb;
- struct sk_buff *tx_rem_skb;
- __le32 tx_rem_sign;
-
- spinlock_t mtx;
- atomic_t stop;
-
- u32 tx_timer_pending;
- u32 tx_curr_frame_num;
- u32 rx_speed;
- u32 tx_speed;
- u32 rx_max;
- u32 tx_max;
- u32 max_datagram_size;
- u16 tx_max_datagrams;
- u16 tx_remainder;
- u16 tx_modulus;
- u16 tx_ndp_modulus;
- u16 tx_seq;
- u16 rx_seq;
- u16 connected;
-};
-
static void cdc_ncm_txpath_bh(unsigned long param);
static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx);
static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *hr_timer);
@@ -471,7 +391,7 @@ static const struct ethtool_ops cdc_ncm_ethtool_ops = {
.nway_reset = usbnet_nway_reset,
};
-static int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting)
+int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting)
{
struct cdc_ncm_ctx *ctx;
struct usb_driver *driver;
@@ -629,8 +549,9 @@ error:
dev_info(&dev->udev->dev, "bind() failure\n");
return -ENODEV;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_bind_common);
-static void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf)
+void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf)
{
struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
struct usb_driver *driver = driver_of(intf);
@@ -660,6 +581,7 @@ static void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf)
usb_set_intfdata(ctx->intf, NULL);
cdc_ncm_free(ctx);
}
+EXPORT_SYMBOL_GPL(cdc_ncm_unbind);
static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
{
@@ -725,7 +647,7 @@ static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp(struct cdc_ncm_ctx *ctx, struct sk_
return ndp16;
}
-static struct sk_buff *
+struct sk_buff *
cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb, __le32 sign)
{
struct usb_cdc_ncm_nth16 *nth16;
@@ -882,6 +804,7 @@ exit_no_skb:
cdc_ncm_tx_timeout_start(ctx);
return NULL;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_fill_tx_frame);
static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx)
{
@@ -948,7 +871,7 @@ error:
}
/* verify NTB header and return offset of first NDP, or negative error */
-static int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in)
+int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in)
{
struct usb_cdc_ncm_nth16 *nth16;
int len;
@@ -990,9 +913,10 @@ static int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_
error:
return ret;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_nth16);
/* verify NDP header and return number of datagrams, or negative error */
-static int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset)
+int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset)
{
struct usb_cdc_ncm_ndp16 *ndp16;
int ret = -EINVAL;
@@ -1023,6 +947,7 @@ static int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset)
error:
return ret;
}
+EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_ndp16);
static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
{
diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h
new file mode 100644
index 0000000..d1719a7
--- /dev/null
+++ b/include/linux/usb/cdc_ncm.h
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) ST-Ericsson 2010-2012
+ * Contact: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
+ * Original author: Hans Petter Selasky <hans.petter.selasky@stericsson.com>
+ *
+ * USB Host Driver for Network Control Model (NCM)
+ * http://www.usb.org/developers/devclass_docs/NCM10.zip
+ *
+ * The NCM encoding, decoding and initialization logic
+ * derives from FreeBSD 8.x. if_cdce.c and if_cdcereg.h
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose this file to be licensed under the terms
+ * of the GNU General Public License (GPL) Version 2 or the 2-clause
+ * BSD license listed below:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/* CDC NCM subclass 3.2.1 */
+#define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
+
+/* Maximum NTB length */
+#define CDC_NCM_NTB_MAX_SIZE_TX 32768 /* bytes */
+#define CDC_NCM_NTB_MAX_SIZE_RX 32768 /* bytes */
+
+/* Minimum value for MaxDatagramSize, ch. 6.2.9 */
+#define CDC_NCM_MIN_DATAGRAM_SIZE 1514 /* bytes */
+
+/* Minimum value for MaxDatagramSize, ch. 8.1.3 */
+#define CDC_MBIM_MIN_DATAGRAM_SIZE 2048 /* bytes */
+
+#define CDC_NCM_MIN_TX_PKT 512 /* bytes */
+
+/* Default value for MaxDatagramSize */
+#define CDC_NCM_MAX_DATAGRAM_SIZE 8192 /* bytes */
+
+/*
+ * Maximum amount of datagrams in NCM Datagram Pointer Table, not counting
+ * the last NULL entry.
+ */
+#define CDC_NCM_DPT_DATAGRAMS_MAX 40
+
+/* Restart the timer, if amount of datagrams is less than given value */
+#define CDC_NCM_RESTART_TIMER_DATAGRAM_CNT 3
+#define CDC_NCM_TIMER_PENDING_CNT 2
+#define CDC_NCM_TIMER_INTERVAL (400UL * NSEC_PER_USEC)
+
+/* The following macro defines the minimum header space */
+#define CDC_NCM_MIN_HDR_SIZE \
+ (sizeof(struct usb_cdc_ncm_nth16) + sizeof(struct usb_cdc_ncm_ndp16) + \
+ (CDC_NCM_DPT_DATAGRAMS_MAX + 1) * sizeof(struct usb_cdc_ncm_dpe16))
+
+#define CDC_NCM_NDP_SIZE \
+ (sizeof(struct usb_cdc_ncm_ndp16) + \
+ (CDC_NCM_DPT_DATAGRAMS_MAX + 1) * sizeof(struct usb_cdc_ncm_dpe16))
+
+struct cdc_ncm_ctx {
+ struct usb_cdc_ncm_ntb_parameters ncm_parm;
+ struct hrtimer tx_timer;
+ struct tasklet_struct bh;
+
+ const struct usb_cdc_ncm_desc *func_desc;
+ const struct usb_cdc_mbim_desc *mbim_desc;
+ const struct usb_cdc_header_desc *header_desc;
+ const struct usb_cdc_union_desc *union_desc;
+ const struct usb_cdc_ether_desc *ether_desc;
+
+ struct net_device *netdev;
+ struct usb_device *udev;
+ struct usb_host_endpoint *in_ep;
+ struct usb_host_endpoint *out_ep;
+ struct usb_host_endpoint *status_ep;
+ struct usb_interface *intf;
+ struct usb_interface *control;
+ struct usb_interface *data;
+
+ struct sk_buff *tx_curr_skb;
+ struct sk_buff *tx_rem_skb;
+ __le32 tx_rem_sign;
+
+ spinlock_t mtx;
+ atomic_t stop;
+
+ u32 tx_timer_pending;
+ u32 tx_curr_frame_num;
+ u32 rx_speed;
+ u32 tx_speed;
+ u32 rx_max;
+ u32 tx_max;
+ u32 max_datagram_size;
+ u16 tx_max_datagrams;
+ u16 tx_remainder;
+ u16 tx_modulus;
+ u16 tx_ndp_modulus;
+ u16 tx_seq;
+ u16 rx_seq;
+ u16 connected;
+};
+
+extern int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting);
+extern void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf);
+extern struct sk_buff *cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb, __le32 sign);
+extern int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in);
+extern int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* [PATCH net-next 07/14] net: cdc_ncm: splitting rx_fixup for code reuse
From: Bjørn Mork @ 2012-10-18 20:41 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum,
Greg Kroah-Hartman, Alexey Orishko, Greg Suarez,
Fangxiaozhi (Franko), Dan Williams, Aleksander Morgado,
Bjørn Mork
In-Reply-To: <1350592867-25651-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
Verifying and handling received MBIM and NCM frames will need
to be different in three areas:
- verifying the NDP signature
- checking valid datagram length
- datagram header manipulation
This makes it inconvenient to share rx_fixup in whole. But
some verification parts are common. Split these out in separate
functions.
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
drivers/net/usb/cdc_ncm.c | 83 ++++++++++++++++++++++++++++++---------------
1 file changed, 55 insertions(+), 28 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 889969d..07d199a 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -990,19 +990,12 @@ error:
return NULL;
}
-static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
+/* verify NTB header and return offset of first NDP, or negative error */
+static int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in)
{
- struct sk_buff *skb;
- struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
- int len;
- int nframes;
- int x;
- int offset;
struct usb_cdc_ncm_nth16 *nth16;
- struct usb_cdc_ncm_ndp16 *ndp16;
- struct usb_cdc_ncm_dpe16 *dpe16;
- int ndpoffset;
- int loopcount = 50; /* arbitrary max preventing infinite loop */
+ int len;
+ int ret = -EINVAL;
if (ctx == NULL)
goto error;
@@ -1036,40 +1029,74 @@ static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
}
ctx->rx_seq = le16_to_cpu(nth16->wSequence);
- ndpoffset = le16_to_cpu(nth16->wNdpIndex);
-next_ndp:
+ ret = le16_to_cpu(nth16->wNdpIndex);
+error:
+ return ret;
+}
+
+/* verify NDP header and return number of datagrams, or negative error */
+static int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset)
+{
+ struct usb_cdc_ncm_ndp16 *ndp16;
+ int ret = -EINVAL;
+
if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) > skb_in->len) {
pr_debug("invalid NDP offset <%u>\n", ndpoffset);
goto error;
}
ndp16 = (struct usb_cdc_ncm_ndp16 *)(skb_in->data + ndpoffset);
- if (le32_to_cpu(ndp16->dwSignature) != USB_CDC_NCM_NDP16_NOCRC_SIGN) {
- pr_debug("invalid DPT16 signature <%u>\n",
- le32_to_cpu(ndp16->dwSignature));
- goto err_ndp;
- }
-
if (le16_to_cpu(ndp16->wLength) < USB_CDC_NCM_NDP16_LENGTH_MIN) {
pr_debug("invalid DPT16 length <%u>\n",
le32_to_cpu(ndp16->dwSignature));
- goto err_ndp;
+ goto error;
}
- nframes = ((le16_to_cpu(ndp16->wLength) -
+ ret = ((le16_to_cpu(ndp16->wLength) -
sizeof(struct usb_cdc_ncm_ndp16)) /
sizeof(struct usb_cdc_ncm_dpe16));
- nframes--; /* we process NDP entries except for the last one */
-
- ndpoffset += sizeof(struct usb_cdc_ncm_ndp16);
+ ret--; /* we process NDP entries except for the last one */
- if ((ndpoffset + nframes * (sizeof(struct usb_cdc_ncm_dpe16))) >
+ if ((sizeof(struct usb_cdc_ncm_ndp16) + ret * (sizeof(struct usb_cdc_ncm_dpe16))) >
skb_in->len) {
- pr_debug("Invalid nframes = %d\n", nframes);
- goto err_ndp;
+ pr_debug("Invalid nframes = %d\n", ret);
+ ret = -EINVAL;
}
- dpe16 = (struct usb_cdc_ncm_dpe16 *)(skb_in->data + ndpoffset);
+error:
+ return ret;
+}
+
+static int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in)
+{
+ struct sk_buff *skb;
+ struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
+ int len;
+ int nframes;
+ int x;
+ int offset;
+ struct usb_cdc_ncm_ndp16 *ndp16;
+ struct usb_cdc_ncm_dpe16 *dpe16;
+ int ndpoffset;
+ int loopcount = 50; /* arbitrary max preventing infinite loop */
+
+ ndpoffset = cdc_ncm_rx_verify_nth16(ctx, skb_in);
+ if (ndpoffset < 0)
+ goto error;
+
+next_ndp:
+ nframes = cdc_ncm_rx_verify_ndp16(skb_in, ndpoffset);
+ if (nframes < 0)
+ goto error;
+
+ ndp16 = (struct usb_cdc_ncm_ndp16 *)(skb_in->data + ndpoffset);
+
+ if (le32_to_cpu(ndp16->dwSignature) != USB_CDC_NCM_NDP16_NOCRC_SIGN) {
+ pr_debug("invalid DPT16 signature <%u>\n",
+ le32_to_cpu(ndp16->dwSignature));
+ goto err_ndp;
+ }
+ dpe16 = ndp16->dpe16;
for (x = 0; x < nframes; x++, dpe16++) {
offset = le16_to_cpu(dpe16->wDatagramIndex);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* [PATCH net-next 05/14] net: cdc_ncm: refactor bind preparing for MBIM support
From: Bjørn Mork @ 2012-10-18 20:40 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum,
Greg Kroah-Hartman, Alexey Orishko, Greg Suarez,
Fangxiaozhi (Franko), Dan Williams, Aleksander Morgado,
Greg Suarez, Bjørn Mork
In-Reply-To: <1350592867-25651-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Greg Suarez <gsuarez-AKjrjAf1O7qe8kRwQpwjMg@public.gmane.org>
NCM and MBIM can share most of the bind function. Split
out the shareable part and add MBIM functional descriptor
parsing.
Signed-off-by: Greg Suarez <gsuarez-AKjrjAf1O7qe8kRwQpwjMg@public.gmane.org>
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
drivers/net/usb/cdc_ncm.c | 47 +++++++++++++++++++++++++++++++--------------
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index bddb0e4..9d2e344 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -475,7 +475,7 @@ static const struct ethtool_ops cdc_ncm_ethtool_ops = {
.nway_reset = usbnet_nway_reset,
};
-static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
+static int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting)
{
struct cdc_ncm_ctx *ctx;
struct usb_driver *driver;
@@ -549,6 +549,13 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
ctx->func_desc = (const struct usb_cdc_ncm_desc *)buf;
break;
+ case USB_CDC_MBIM_TYPE:
+ if (buf[0] < sizeof(*(ctx->mbim_desc)))
+ break;
+
+ ctx->mbim_desc = (const struct usb_cdc_mbim_desc *)buf;
+ break;
+
default:
break;
}
@@ -561,7 +568,7 @@ advance:
/* check if we got everything */
if ((ctx->control == NULL) || (ctx->data == NULL) ||
- (ctx->ether_desc == NULL) || (ctx->control != intf))
+ ((!ctx->mbim_desc) && ((ctx->ether_desc == NULL) || (ctx->control != intf))))
goto error;
/* claim interfaces, if any */
@@ -581,7 +588,7 @@ advance:
goto error2;
/* configure data interface */
- temp = usb_set_interface(dev->udev, iface_no, 1);
+ temp = usb_set_interface(dev->udev, iface_no, data_altsetting);
if (temp)
goto error2;
@@ -598,11 +605,13 @@ advance:
usb_set_intfdata(ctx->control, dev);
usb_set_intfdata(ctx->intf, dev);
- temp = usbnet_get_ethernet_addr(dev, ctx->ether_desc->iMACAddress);
- if (temp)
- goto error2;
+ if (ctx->ether_desc) {
+ temp = usbnet_get_ethernet_addr(dev, ctx->ether_desc->iMACAddress);
+ if (temp)
+ goto error2;
+ dev_info(&dev->udev->dev, "MAC-Address: %pM\n", dev->net->dev_addr);
+ }
- dev_info(&dev->udev->dev, "MAC-Address: %pM\n", dev->net->dev_addr);
dev->in = usb_rcvbulkpipe(dev->udev,
ctx->in_ep->desc.bEndpointAddress & USB_ENDPOINT_NUMBER_MASK);
@@ -611,13 +620,6 @@ advance:
dev->status = ctx->status_ep;
dev->rx_urb_size = ctx->rx_max;
- /*
- * We should get an event when network connection is "connected" or
- * "disconnected". Set network connection in "disconnected" state
- * (carrier is OFF) during attach, so the IP network stack does not
- * start IPv6 negotiation and more.
- */
- netif_carrier_off(dev->net);
ctx->tx_speed = ctx->rx_speed = 0;
return 0;
@@ -663,6 +665,23 @@ static void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf)
cdc_ncm_free(ctx);
}
+static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+ int ret;
+
+ /* NCM data altsetting is always 1 */
+ ret = cdc_ncm_bind_common(dev, intf, 1);
+
+ /*
+ * We should get an event when network connection is "connected" or
+ * "disconnected". Set network connection in "disconnected" state
+ * (carrier is OFF) during attach, so the IP network stack does not
+ * start IPv6 negotiation and more.
+ */
+ netif_carrier_off(dev->net);
+ return ret;
+}
+
static void cdc_ncm_zero_fill(u8 *ptr, u32 first, u32 end, u32 max)
{
if (first >= max)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* [PATCH net-next 03/14] USB: cdc: add MBIM constants and structures
From: Bjørn Mork @ 2012-10-18 20:40 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum,
Greg Kroah-Hartman, Alexey Orishko, Greg Suarez,
Fangxiaozhi (Franko), Dan Williams, Aleksander Morgado,
Greg Suarez, Bjørn Mork
In-Reply-To: <1350592867-25651-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Greg Suarez <gsuarez-AKjrjAf1O7qe8kRwQpwjMg@public.gmane.org>
Based on revision 1.0 of "Universal Serial Bus Communications
Class Subclass Specification for Mobile Broadband Interface
Model" available from www.usb.org
Signed-off-by: Greg Suarez <gsuarez-AKjrjAf1O7qe8kRwQpwjMg@public.gmane.org>
[bmork: added DSS defines]
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
include/linux/usb/cdc.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/include/linux/usb/cdc.h b/include/linux/usb/cdc.h
index 81a9279..f35aa0a 100644
--- a/include/linux/usb/cdc.h
+++ b/include/linux/usb/cdc.h
@@ -19,6 +19,7 @@
#define USB_CDC_SUBCLASS_OBEX 0x0b
#define USB_CDC_SUBCLASS_EEM 0x0c
#define USB_CDC_SUBCLASS_NCM 0x0d
+#define USB_CDC_SUBCLASS_MBIM 0x0e
#define USB_CDC_PROTO_NONE 0
@@ -33,6 +34,7 @@
#define USB_CDC_PROTO_EEM 7
#define USB_CDC_NCM_PROTO_NTB 1
+#define USB_CDC_MBIM_PROTO_NTB 2
/*-------------------------------------------------------------------------*/
@@ -53,6 +55,7 @@
#define USB_CDC_DMM_TYPE 0x14
#define USB_CDC_OBEX_TYPE 0x15
#define USB_CDC_NCM_TYPE 0x1a
+#define USB_CDC_MBIM_TYPE 0x1b
/* "Header Functional Descriptor" from CDC spec 5.2.3.1 */
struct usb_cdc_header_desc {
@@ -187,6 +190,21 @@ struct usb_cdc_ncm_desc {
__le16 bcdNcmVersion;
__u8 bmNetworkCapabilities;
} __attribute__ ((packed));
+
+/* "MBIM Control Model Functional Descriptor" */
+struct usb_cdc_mbim_desc {
+ __u8 bLength;
+ __u8 bDescriptorType;
+ __u8 bDescriptorSubType;
+
+ __le16 bcdMBIMVersion;
+ __le16 wMaxControlMessage;
+ __u8 bNumberFilters;
+ __u8 bMaxFilterSize;
+ __le16 wMaxSegmentSize;
+ __u8 bmNetworkCapabilities;
+} __attribute__ ((packed));
+
/*-------------------------------------------------------------------------*/
/*
@@ -332,6 +350,11 @@ struct usb_cdc_ncm_nth32 {
#define USB_CDC_NCM_NDP32_CRC_SIGN 0x316D636E /* ncm1 */
#define USB_CDC_NCM_NDP32_NOCRC_SIGN 0x306D636E /* ncm0 */
+#define USB_CDC_MBIM_NDP16_IPS_SIGN 0x00535049 /* IPS<sessionID> : IPS0 for now */
+#define USB_CDC_MBIM_NDP32_IPS_SIGN 0x00737069 /* ips<sessionID> : ips0 for now */
+#define USB_CDC_MBIM_NDP16_DSS_SIGN 0x00535344 /* DSS<sessionID> */
+#define USB_CDC_MBIM_NDP32_DSS_SIGN 0x00737364 /* dss<sessionID> */
+
/* 16-bit NCM Datagram Pointer Entry */
struct usb_cdc_ncm_dpe16 {
__le16 wDatagramIndex;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 related
* [PATCH net-next 00/14] Adding a USB CDC MBIM driver
From: Bjørn Mork @ 2012-10-18 20:40 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Oliver Neukum,
Greg Kroah-Hartman, Alexey Orishko, Greg Suarez,
Fangxiaozhi (Franko), Dan Williams, Aleksander Morgado,
Bjørn Mork
The USB Communications Device Class "Mobile Broadband Interface Model"
(MBIM) is the USB-IFs alternative to the current chipset/vendor
specific solutions to "Mobile Broadband" device management. The
specification, including the management protocol description, can be
downloaded from http://www.usb.org/developers/devclass_docs#approved
This driver implementing most MBIM features with the exception of
32bit NTB and NDP headers.
An important design principle has been reusing as much as possible of
existing kernel code, in particular the cdc_ncm and cdc_wdm drivers.
The CDC MBIM protocol is based on CDC NCM, and much of the setup and
framing logic is very similar.
One important addition in MBIM compared to NCM is the new control
protocol embedded in CDC commands. This protocol is comprehensive and
support a number of policy decisions necessary for modern mobile
broadband devices often having multiple radio interfaces. Based on
early comments and the experiences with the qmi_wwan driver, knowledge
of the control protocol has been kept completely out of the driver.
This is userspace material. Like with qmi_wwan, a control protocol
interface is exported to userspace using the cdc_wdm subdriver API,
associating a /dev/cdc-wdmX character device with the network device
for the management application.
Patch 1 and 2 are independent of the rest and only required to make
test devices with very large buffers work.
Patch 3 adds new MBIM definitions to the cdc.h header file
Patches 4 to 9 refactor the cdc_ncm driver to enable reusing common
parts for MBIM.
Patches 10 and 11 add the new cdc_mbim driver
Patch 12 prevents cdc_ncm from binding to backward compatible MBIM
devices
Patches 13 and 14 extend the MBIM driver to support multiplexed
sessions
The changes to the cdc_ncm driver has been tested and verified to work
with an Ericsson F5521gw device. The new cdc_mbim driver has been
tested with a Huawei E367u-2 device with MBIM firmware, and other
currently undisclosed devices.
Enjoy!
Bjørn Mork (10):
net: usbnet: make sure the queue lenght is at least 1
net: cdc_ncm: use device rx_max value if update failed
net: cdc_ncm: process chained NDPs
net: cdc_ncm: splitting rx_fixup for code reuse
net: cdc_ncm: refactoring for tx multiplexing
net: cdc_ncm: export shared symbols and definitions
net: cdc_mbim: build the MBIM driver
net: cdc_ncm: do not bind to NCM compatible MBIM devices
net: cdc_ncm: map MBIM IPS SessionID to VLAN ID
net: cdc_mbim: Device Service Stream support
Greg Suarez (4):
USB: cdc: add MBIM constants and structures
net: cdc_ncm: adding MBIM support to ncm_setup
net: cdc_ncm: refactor bind preparing for MBIM support
net: cdc_mbim: adding MBIM driver
drivers/net/usb/Kconfig | 18 ++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/cdc_mbim.c | 412 ++++++++++++++++++++++++++++++++
drivers/net/usb/cdc_ncm.c | 546 +++++++++++++++++++++----------------------
drivers/net/usb/usbnet.c | 4 +-
include/linux/usb/cdc.h | 23 ++
include/linux/usb/cdc_ncm.h | 134 +++++++++++
7 files changed, 856 insertions(+), 282 deletions(-)
create mode 100644 drivers/net/usb/cdc_mbim.c
create mode 100644 include/linux/usb/cdc_ncm.h
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* net-next is open
From: David Miller @ 2012-10-18 20:37 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
You can now submit patches for 'net-next', I just sync'd it up with
current 'net'.
As I warned, I have tossed every feature/cleanup patch submitted
before now in patchwork, so you have to resubmit anything you
erroneously submitted over the past few weeks.
Thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2012-10-18
From: David Miller @ 2012-10-18 19:37 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1350588295-22587-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Thu, 18 Oct 2012 21:24:53 +0200
> here are two fixes intended for net. The first one fixes the CRC computation
> used to check for broadcast packet duplicates. The wrong result lead to many
> (more than 80%) broadcast packets being dropped and so making the network very
> slow and mostly unusable. Think about all the ARP or DHCP requests not going
> through.
>
> The second patch fixes a potential race condition, still in the same duplicated
> broadcast check procedure, which can lead to wrong outcomes under certain
> circumstances.
Pulled, thanks.
> I would also like to enqueue patch 1/2 for sending to stable-{3.5/3.6}.
Feel free to submit this to -stable once it hits Linus's tree.
Thanks.
^ permalink raw reply
* Re: [PATCH] tcp: fix FIONREAD/SIOCINQ
From: David Miller @ 2012-10-18 19:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, enh, ncardwell, therbert
In-Reply-To: <1350587652.32642.215.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 18 Oct 2012 21:14:12 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> tcp_ioctl() tries to take into account if tcp socket received a FIN
> to report correct number bytes in receive queue.
>
> But its flaky because if the application ate the last skb,
> we return 1 instead of 0.
>
> Correct way to detect that FIN was received is to test SOCK_DONE.
>
> Reported-by: Elliot Hughes <enh@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net] net: qmi_wwan: adding more ZTE devices
From: David Miller @ 2012-10-18 19:36 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1350573090-9345-1-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 18 Oct 2012 17:11:29 +0200
> Analyzed a few Windows driver description files, supporting
> this long list of devices:
...
> Adding the ones we were missing.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH] netlink: use kfree_rcu() in netlink_release()
From: David Miller @ 2012-10-18 19:36 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, marcheu, kliegs, sleffler
In-Reply-To: <1350566515.26103.1549.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 18 Oct 2012 15:21:55 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> On some suspend/resume operations involving wimax device, we have
> noticed some intermittent memory corruptions in netlink code.
>
> Stéphane Marchesin tracked this corruption in netlink_update_listeners()
> and suggested a patch.
>
> It appears netlink_release() should use kfree_rcu() instead of kfree()
> for the listeners structure as it may be used by other cpus using RCU
> protection.
>
> netlink_release() must set to NULL the listeners pointer when
> it is about to be freed.
>
> Also have to protect netlink_update_listeners() and
> netlink_has_listeners() if listeners is NULL.
>
> Add a nl_deref_protected() lockdep helper to properly document which
> locks protects us.
>
> Reported-by: Jonathan Kliegman <kliegs@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2] ipv4: Fix flushing of cached routing informations
From: David Miller @ 2012-10-18 19:35 UTC (permalink / raw)
To: steffen.klassert; +Cc: ja, netdev
In-Reply-To: <20121018071744.GD27385@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Thu, 18 Oct 2012 09:17:44 +0200
> Currently we can not flush cached pmtu/redirect informations via
> the ipv4_sysctl_rtcache_flush sysctl. We need to check the rt_genid
> of the old route and reset the nh exeption if the old route is
> expired when we bind a new route to a nh exeption.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [patch net] vlan: allow to change type when no vlan device is hooked on netdev
From: David Miller @ 2012-10-18 19:35 UTC (permalink / raw)
To: jiri; +Cc: netdev, fubar, andy, kaber, jstanley
In-Reply-To: <1350473856-29380-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 17 Oct 2012 13:37:36 +0200
> vlan_info might be present but still no vlan devices might be there.
> That is in case of vlan0 automatically added.
>
> So in that case, allow to change netdev type.
>
> Reported-by: Jon Stanley <jstanley@rmrf.net>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* [PATCH 2/2] batman-adv: Fix potential broadcast BLA-duplicate-check race condition
From: Antonio Quartulli @ 2012-10-18 19:24 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1350588295-22587-1-git-send-email-ordex@autistici.org>
From: Linus Lüssing <linus.luessing@web.de>
Threads in the bottom half of batadv_bla_check_bcast_duplist() might
otherwise for instance overwrite variables which other threads might
be using/reading at the same time in the top half, potentially
leading to messing up the bcast_duplist, possibly resulting in false
bridge loop avoidance duplicate check decisions.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---
net/batman-adv/bridge_loop_avoidance.c | 19 ++++++++++++++-----
net/batman-adv/types.h | 2 ++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index eebab20..fd8d5af 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1167,6 +1167,8 @@ int batadv_bla_init(struct batadv_priv *bat_priv)
uint16_t crc;
unsigned long entrytime;
+ spin_lock_init(&bat_priv->bla.bcast_duplist_lock);
+
batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla hash registering\n");
/* setting claim destination address */
@@ -1226,7 +1228,7 @@ int batadv_bla_check_bcast_duplist(struct batadv_priv *bat_priv,
struct batadv_bcast_packet *bcast_packet,
int bcast_packet_len)
{
- int i, length, curr;
+ int i, length, curr, ret = 0;
uint8_t *content;
uint16_t crc;
struct batadv_bcast_duplist_entry *entry;
@@ -1238,6 +1240,8 @@ int batadv_bla_check_bcast_duplist(struct batadv_priv *bat_priv,
/* calculate the crc ... */
crc = crc16(0, content, length);
+ spin_lock_bh(&bat_priv->bla.bcast_duplist_lock);
+
for (i = 0; i < BATADV_DUPLIST_SIZE; i++) {
curr = (bat_priv->bla.bcast_duplist_curr + i);
curr %= BATADV_DUPLIST_SIZE;
@@ -1259,9 +1263,12 @@ int batadv_bla_check_bcast_duplist(struct batadv_priv *bat_priv,
/* this entry seems to match: same crc, not too old,
* and from another gw. therefore return 1 to forbid it.
*/
- return 1;
+ ret = 1;
+ goto out;
}
- /* not found, add a new entry (overwrite the oldest entry) */
+ /* not found, add a new entry (overwrite the oldest entry)
+ * and allow it, its the first occurence.
+ */
curr = (bat_priv->bla.bcast_duplist_curr + BATADV_DUPLIST_SIZE - 1);
curr %= BATADV_DUPLIST_SIZE;
entry = &bat_priv->bla.bcast_duplist[curr];
@@ -1270,8 +1277,10 @@ int batadv_bla_check_bcast_duplist(struct batadv_priv *bat_priv,
memcpy(entry->orig, bcast_packet->orig, ETH_ALEN);
bat_priv->bla.bcast_duplist_curr = curr;
- /* allow it, its the first occurence. */
- return 0;
+out:
+ spin_unlock_bh(&bat_priv->bla.bcast_duplist_lock);
+
+ return ret;
}
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index 2ed82ca..ac1e07a 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -205,6 +205,8 @@ struct batadv_priv_bla {
struct batadv_hashtable *backbone_hash;
struct batadv_bcast_duplist_entry bcast_duplist[BATADV_DUPLIST_SIZE];
int bcast_duplist_curr;
+ /* protects bcast_duplist and bcast_duplist_curr */
+ spinlock_t bcast_duplist_lock;
struct batadv_bla_claim_dst claim_dest;
struct delayed_work work;
};
--
1.7.12.3
^ permalink raw reply related
* [PATCH 1/2] batman-adv: Fix broadcast packet CRC calculation
From: Antonio Quartulli @ 2012-10-18 19:24 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Linus Lüssing, Marek Lindner,
Antonio Quartulli
In-Reply-To: <1350588295-22587-1-git-send-email-ordex@autistici.org>
From: Linus Lüssing <linus.luessing@web.de>
So far the crc16 checksum for a batman-adv broadcast data packet, received
on a batman-adv hard interface, was calculated over zero bytes of its
content leading to many incoming broadcast data packets wrongly being
dropped (60-80% packet loss).
This patch fixes this issue by calculating the crc16 over the actual,
complete broadcast payload.
The issue is a regression introduced by
("batman-adv: add broadcast duplicate check").
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
---
net/batman-adv/bridge_loop_avoidance.c | 8 ++++----
net/batman-adv/routing.c | 8 +++++++-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c
index 0a9084a..eebab20 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1210,8 +1210,8 @@ int batadv_bla_init(struct batadv_priv *bat_priv)
/**
* batadv_bla_check_bcast_duplist
* @bat_priv: the bat priv with all the soft interface information
- * @bcast_packet: originator mac address
- * @hdr_size: maximum length of the frame
+ * @bcast_packet: encapsulated broadcast frame plus batman header
+ * @bcast_packet_len: length of encapsulated broadcast frame plus batman header
*
* check if it is on our broadcast list. Another gateway might
* have sent the same packet because it is connected to the same backbone,
@@ -1224,14 +1224,14 @@ int batadv_bla_init(struct batadv_priv *bat_priv)
*/
int batadv_bla_check_bcast_duplist(struct batadv_priv *bat_priv,
struct batadv_bcast_packet *bcast_packet,
- int hdr_size)
+ int bcast_packet_len)
{
int i, length, curr;
uint8_t *content;
uint16_t crc;
struct batadv_bcast_duplist_entry *entry;
- length = hdr_size - sizeof(*bcast_packet);
+ length = bcast_packet_len - sizeof(*bcast_packet);
content = (uint8_t *)bcast_packet;
content += sizeof(*bcast_packet);
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 939fc01..376b4cc 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -1124,8 +1124,14 @@ int batadv_recv_bcast_packet(struct sk_buff *skb,
spin_unlock_bh(&orig_node->bcast_seqno_lock);
+ /* keep skb linear for crc calculation */
+ if (skb_linearize(skb) < 0)
+ goto out;
+
+ bcast_packet = (struct batadv_bcast_packet *)skb->data;
+
/* check whether this has been sent by another originator before */
- if (batadv_bla_check_bcast_duplist(bat_priv, bcast_packet, hdr_size))
+ if (batadv_bla_check_bcast_duplist(bat_priv, bcast_packet, skb->len))
goto out;
/* rebroadcast packet */
--
1.7.12.3
^ permalink raw reply related
* pull request: batman-adv 2012-10-18
From: Antonio Quartulli @ 2012-10-18 19:24 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Hello David,
here are two fixes intended for net. The first one fixes the CRC computation
used to check for broadcast packet duplicates. The wrong result lead to many
(more than 80%) broadcast packets being dropped and so making the network very
slow and mostly unusable. Think about all the ARP or DHCP requests not going
through.
The second patch fixes a potential race condition, still in the same duplicated
broadcast check procedure, which can lead to wrong outcomes under certain
circumstances.
I would also like to enqueue patch 1/2 for sending to stable-{3.5/3.6}.
Thanks a lot,
Antonio
The following changes since commit 43c422eda99b894f18d1cca17bcd2401efaf7bd0:
apparmor: fix apparmor OOPS in audit_log_untrustedstring+0x1c/0x40 (2012-10-17 16:29:46 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 7dac7b76b8db87fc79857a53a09730fb2148579b:
batman-adv: Fix potential broadcast BLA-duplicate-check race condition (2012-10-18 18:17:31 +0200)
----------------------------------------------------------------
Included fixes:
- Fix broadcast packet CRC calculation which can lead to ~80% broadcast packet
loss
- Fix a race condition in duplicate broadcast packet check
----------------------------------------------------------------
Linus Lüssing (2):
batman-adv: Fix broadcast packet CRC calculation
batman-adv: Fix potential broadcast BLA-duplicate-check race condition
net/batman-adv/bridge_loop_avoidance.c | 27 ++++++++++++++++++---------
net/batman-adv/routing.c | 8 +++++++-
net/batman-adv/types.h | 2 ++
3 files changed, 27 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: [PATCH] Netfilter/IPVS updates for your net tree (3.7)
From: David Miller @ 2012-10-18 19:18 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1350470334-5742-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Wed, 17 Oct 2012 12:38:50 +0200
> The following patchset contains Netfilter/IPVS updates for your
> net tree, they are:
>
> * Fix incorrect hooks for SNAT and DNAT (bug introduced in recent IPv6
> NAT changes), from Elison Niven.
>
> * Fix xt_TEE (got broken with recent rt_gateway semantic change),
> from Eric Dumazet.
>
> * Fix custom conntrack timeout policy attachment for IPv6, from myself.
>
> * Always initialize ip_vs_timeout_user in case that TCP or UDP protocols
> is disabled, from Arnd Bergmann.
Pulled, thanks Pablo.
^ permalink raw reply
* [PATCH] tcp: fix FIONREAD/SIOCINQ
From: Eric Dumazet @ 2012-10-18 19:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Elliot Hughes, Neal Cardwell, Tom Herbert
From: Eric Dumazet <edumazet@google.com>
tcp_ioctl() tries to take into account if tcp socket received a FIN
to report correct number bytes in receive queue.
But its flaky because if the application ate the last skb,
we return 1 instead of 0.
Correct way to detect that FIN was received is to test SOCK_DONE.
Reported-by: Elliot Hughes <enh@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Tom Herbert <therbert@google.com>
---
net/ipv4/tcp.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index f32c02e..b7c2f43 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -549,14 +549,12 @@ int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg)
!tp->urg_data ||
before(tp->urg_seq, tp->copied_seq) ||
!before(tp->urg_seq, tp->rcv_nxt)) {
- struct sk_buff *skb;
answ = tp->rcv_nxt - tp->copied_seq;
- /* Subtract 1, if FIN is in queue. */
- skb = skb_peek_tail(&sk->sk_receive_queue);
- if (answ && skb)
- answ -= tcp_hdr(skb)->fin;
+ /* Subtract 1, if FIN was received */
+ if (answ && sock_flag(sk, SOCK_DONE))
+ answ--;
} else
answ = tp->urg_seq - tp->copied_seq;
release_sock(sk);
^ permalink raw reply related
* Re: [PATCH v1] net/core: support runtime PM on net_device
From: David Miller @ 2012-10-18 19:05 UTC (permalink / raw)
To: ming.lei; +Cc: bjorn, rjw, oneukum, stern, netdev, linux-pm
In-Reply-To: <CACVXFVMmSFHYU-sNHRM7g_8U6mjbdbE+bNPxM-F8iAB=4WudRA@mail.gmail.com>
From: Ming Lei <ming.lei@canonical.com>
Date: Thu, 18 Oct 2012 20:55:58 +0800
> On Thu, Oct 18, 2012 at 7:40 PM, Bjørn Mork <bjorn@mork.no> wrote:
>>
>> Because bugs are supposed to be fixed and not hidden?
>
> OK, now let's discuss solution for the problem which should be
> clear and be solved.
>
> The 1st one is to do it by this patch, or rule out some ioctl cmd
> which needn't wakeup device.
>
> The second one is to fix ioctl one by one in each driver.
>
> Any other solution?
The second is clearly the correct way to handle these issues.
Drivers need to be aware when their drivers ops are called whether
they can safely access the device or not.
I'm not applying this patch.
^ permalink raw reply
* Re: sock_getsockopt() not exported
From: David Miller @ 2012-10-18 19:04 UTC (permalink / raw)
To: David.Laight; +Cc: eric.dumazet, netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7053@saturn3.aculab.com>
From: "David Laight" <David.Laight@ACULAB.COM>
Date: Thu, 18 Oct 2012 13:03:55 +0100
> The problem is that it might be needed by an 'out of tree' driver.
We don't care.
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-18 18:46 UTC (permalink / raw)
To: Hiremath, Vaibhav
Cc: Richard Cochran, netdev@vger.kernel.org, Mohammed, Afzal,
Russell King, Arnd Bergmann, Tony Lindgren, David Miller,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB43DBA@DBDE01.ent.ti.com>
On 10/18/2012 01:39 PM, Hiremath, Vaibhav wrote:
> On Fri, Oct 19, 2012 at 00:00:31, Hunter, Jon wrote:
>>
>> On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
>>> On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
>>
>> ...
>>
>>>> Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
>>>>
>>>> My point is to highlight this and not hide it, so that we can fix it
>>>> now. Otherwise if we wait until we enable the gpmc driver with DT and
>>>> this could hinder the DT migration later.
>>>>
>>>
>>> As I already mentioned in my previous response, your patch is required
>>> irrespective of this patch. I would consider your patch as a cleanup patch.
>>>
>>>
>>> Both the patches are independent, your patch is handling the error path
>>> properly, whereas, my patch makes sure that you don't unnecessarily probe
>>> GPMC if you are booting from DT and GPMC node is not present, as described
>>> above.
>>
>> Your patch hides a bug. That's my point. How do you expect am335x ever
>> to support gpmc devices if this bug is not addressed?
>>
>
> Jon,
> May be my commit description was mis-leading to you.
> I am not commenting anything on your bug-fix, but do not agree that it is
> anything to do with hiding a bug.
So we can agree is disagree on that ;-)
> I only agree with you on one point, if someone wants to change the board-
> file to use GPMC with DT boot mode, then he will not be able to use it.
>
>> So I think that you are over-simplifying it when you say that my patch
>> is just a clean-up patch. I agree that it is adding appropriate error
>> handling, but it also highlights the presence of a bug by allowing the
>> probe to fail.
>>
>> Anyway, I don't care to debate this any further,
>
> Me neither...
>
>> we just need to fix
>> gpmc_mem_init().
>>
>
> Agreed, and that's what your patch rightly doing it.
No. My patch does not fix the _actual_ bug, it is still there. Why do
you think that the probe is still failing for am335x? Without fixing it
am335x will never be able to support gpmc. So gpmc_mem_init() still
needs to be fixed.
Jon
^ permalink raw reply
* RE: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Hiremath, Vaibhav @ 2012-10-18 18:39 UTC (permalink / raw)
To: Hunter, Jon
Cc: Richard Cochran, netdev@vger.kernel.org, Mohammed, Afzal,
Russell King, Arnd Bergmann, Tony Lindgren, David Miller,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
In-Reply-To: <50804AC7.3000309@ti.com>
On Fri, Oct 19, 2012 at 00:00:31, Hunter, Jon wrote:
>
> On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
> > On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
>
> ...
>
> >> Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
> >>
> >> My point is to highlight this and not hide it, so that we can fix it
> >> now. Otherwise if we wait until we enable the gpmc driver with DT and
> >> this could hinder the DT migration later.
> >>
> >
> > As I already mentioned in my previous response, your patch is required
> > irrespective of this patch. I would consider your patch as a cleanup patch.
> >
> >
> > Both the patches are independent, your patch is handling the error path
> > properly, whereas, my patch makes sure that you don't unnecessarily probe
> > GPMC if you are booting from DT and GPMC node is not present, as described
> > above.
>
> Your patch hides a bug. That's my point. How do you expect am335x ever
> to support gpmc devices if this bug is not addressed?
>
Jon,
May be my commit description was mis-leading to you.
I am not commenting anything on your bug-fix, but do not agree that it is
anything to do with hiding a bug.
I only agree with you on one point, if someone wants to change the board-
file to use GPMC with DT boot mode, then he will not be able to use it.
> So I think that you are over-simplifying it when you say that my patch
> is just a clean-up patch. I agree that it is adding appropriate error
> handling, but it also highlights the presence of a bug by allowing the
> probe to fail.
>
> Anyway, I don't care to debate this any further,
Me neither...
> we just need to fix
> gpmc_mem_init().
>
Agreed, and that's what your patch rightly doing it.
Thanks,
Vaibhav
> Jon
>
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-18 18:30 UTC (permalink / raw)
To: Hiremath, Vaibhav
Cc: Richard Cochran, netdev@vger.kernel.org, Mohammed, Afzal,
Russell King, Arnd Bergmann, Tony Lindgren, David Miller,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB43D0F@DBDE01.ent.ti.com>
On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
> On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
...
>> Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
>>
>> My point is to highlight this and not hide it, so that we can fix it
>> now. Otherwise if we wait until we enable the gpmc driver with DT and
>> this could hinder the DT migration later.
>>
>
> As I already mentioned in my previous response, your patch is required
> irrespective of this patch. I would consider your patch as a cleanup patch.
>
>
> Both the patches are independent, your patch is handling the error path
> properly, whereas, my patch makes sure that you don't unnecessarily probe
> GPMC if you are booting from DT and GPMC node is not present, as described
> above.
Your patch hides a bug. That's my point. How do you expect am335x ever
to support gpmc devices if this bug is not addressed?
So I think that you are over-simplifying it when you say that my patch
is just a clean-up patch. I agree that it is adding appropriate error
handling, but it also highlights the presence of a bug by allowing the
probe to fail.
Anyway, I don't care to debate this any further, we just need to fix
gpmc_mem_init().
Jon
^ permalink raw reply
* RE: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Hiremath, Vaibhav @ 2012-10-18 18:04 UTC (permalink / raw)
To: Hunter, Jon
Cc: Richard Cochran, netdev@vger.kernel.org, Mohammed, Afzal,
Russell King, Arnd Bergmann, Tony Lindgren, David Miller,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org
In-Reply-To: <5080315F.8090802@ti.com>
On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
>
> On 10/18/2012 11:16 AM, Hiremath, Vaibhav wrote:
> > On Wed, Oct 17, 2012 at 01:17:56, Hunter, Jon wrote:
> >>
> >> On 10/15/2012 02:16 PM, Richard Cochran wrote:
> >>> From: hvaibhav@ti.com <hvaibhav@ti.com>
> >>>
> >>> With recent changes in omap gpmc driver code, in case of DT
> >>> boot mode, where bootloader does not configure gpmc cs space
> >>> will result into kernel BUG() inside gpmc_mem_init() function,
> >>> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> >>> gpmc_config7[0].baseaddress is set to '0' on reset.
> >>
> >> I am not sure I completely follow the logic here.
> >>
> >> Won't this problem occur if the bootloader does not configure the gpmc
> >> cs space AND we are not using DT?
> >>
> >
> > That's what exactly the above comment describes.
>
> Hmm ... you said "in the case of DT", but I am saying even "in the case
> WITHOUT DT" this can happen. So I think the subject is mis-leading.
>
Ok, may be my above statement was confusing. But the bottom line is,
We should GPMC without any pre-configuration (either at u-boot or ROM) will
have this issue.
> >> Is the csvalid bit set because we are booting from the internal ROM?
> >>
> >
> > As per TRM, the reset value of the CS0_valis bit is set to 0. I have pasted
> > TRM statement below -
> >
> > "Chip-select enable (reset value is 1 for CS[0] and 0 for CS[1-5])."
>
> The above two sentences don't see to agree ...
Oops, it was typo mistake. I meant "is set to '1'"
>
> > And same applies to OMAP3 family of devices.
>
> For which boot-modes? All or just the gpmc boot-modes?
>
That's reset value, and I believe it is applicable for all boot modes.
> My omap3430 beagle has been booting with DT fine for some time and I
> have not encountered this problem even on the latest kernel with the
> gpmc driver present.
>
OMAp3430 beagle board has NAND flash available over GPMC-CS0 interface.
> >> I guess I don't see why csvalid bit being set and a base-address of 0x0
> >> should not be allowed. That should be a valid combination.
> >>
> >
> > Yes, agreed.
> >
> >> One problem I see with gpmc_mem_init() is that it assumes that
> >> BOOT_ROM_SPACE is 1MB for all devices starting at 0x0 apart from the
> >> apollon board. For newer devices such as OMAP4, there is only 48KB of
> >> internal ROM and only mapped to 0x0 when booting from internal ROM. So
> >> this needs to be fixed.
> >>
> >> How much internal ROM does the AM335x have and where is it mapped?
> >>
> >
> > AM33xx memory map is something like,
> >
> > Boot ROM 0x4000_0000 0x4001_FFFF 128KB
> > 0x4002_0000 0x4002_BFFF 48KB 32-bit Ex/R(1) - Public
> > Reserved 0x4002_C000 0x400F_FFFF 848KB Reserved
> > Reserved 0x4010_0000 0x401F_FFFF 1MB Reserved
> > Reserved 0x4020_0000 0x402E_FFFF 960KB Reserved
> > Reserved 0x402f_0000 0x4020_03FF 64KB Reserved
> > SRAM internal 0x402F_0400 0x402F_FFFF 32-bit Ex/R/W(1)
>
> Does the boot ROM get mapped to 0x0, when booting from ROM?
>
I expect, it should be same as OMAP4.
> >>> This use-case is applicable for any board/EVM which doesn't have
> >>> any peripheral connected to gpmc cs0, for example BeagleXM and
> >>> BeagleBone, so DT boot mode fails.
> >>>
> >>> This patch adds of_have_populated_dt() check before creating
> >>> device, so that for DT boot mode, gpmc probe will not be called
> >>> which is expected behavior, as gpmc is not supported yet from DT.
> >>
> >> Yes, but we do actually still allow some platform devices to be probed
> >> (such as dmtimers) when booting with DT that don't support DT yet. So
> >> this change prevents us from using the gpmc on boards when booting with DT.
> >>
> >
> > The idea here was,
> >
> > In order to use GPMC in meaningful way, where some peripheral is connected
> > to the GPMC, you must create platform_device for the probe to happen
> > properly. Now all the devices I know so far, we have gpmc_smsc911x_init(),
> > omap_nand_flash_init(), etc...
> > These api's are getting called only through machine_desc.init_xxx callbacks,
> > And in case of DT, we have centralized machine_desc definition for all
> > platforms (board-generic.c). So even though you want to use GPMC for DT boot
> > mode, you can not make use of peripheral without changing board-files to
> > change to create platform_device.
> >
> > Does it make sense?
>
> Sure, if you are using one of the generic machine configurations for DT.
> However, while this migration happens people may create their own custom
> machine configurations for DT for testing things like smsc911x.
>
If we want to think about all such use-cases, then yes, this patch is not
required.
> >> I am not convinced that this is addressing the underlying problem with
> >> gpmc_mem_init().
> >>
> >
> > The patch you submitted is cleanup patch and is required irrespective of
> > this patch. I believe this patch is just makes sure that, if you are booting
> > from DT and you do not have meaningful DT node for GPMC and peripheral
> > interfaced to it, no point in probing it.
> >
> > Does it make any sense???
>
> Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
>
> My point is to highlight this and not hide it, so that we can fix it
> now. Otherwise if we wait until we enable the gpmc driver with DT and
> this could hinder the DT migration later.
>
As I already mentioned in my previous response, your patch is required
irrespective of this patch. I would consider your patch as a cleanup patch.
Both the patches are independent, your patch is handling the error path
properly, whereas, my patch makes sure that you don't unnecessarily probe
GPMC if you are booting from DT and GPMC node is not present, as described
above.
Thanks,
Vaibhav
> Jon
>
>
^ permalink raw reply
* Re: listen(2) backlog changes in or around Linux 3.1?
From: enh @ 2012-10-18 17:20 UTC (permalink / raw)
To: Venkat Venkatsubra; +Cc: netdev
In-Reply-To: <5080340F.3050207@oracle.com>
On Thu, Oct 18, 2012 at 9:53 AM, Venkat Venkatsubra
<venkat.x.venkatsubra@oracle.com> wrote:
> Correction. I don't see the client side receiving any abort/termination
> notification.
> They all remain on ESTABLISHED state on the client side.
yeah, that's what i see with netstat -t too.
in the meantime i'm working around this by connecting to one of
RFC5737's test networks
(https://android-review.googlesource.com/#/c/44563/), but i'd love to
at least understand what's going on here, even if it's just that i
have a fundamental misunderstanding of what the listen backlog is
supposed to mean.
> In tcpdump I don't see a FIN or RST coming from the server for the aborted
> connections.
>
> Venkat
>
>
> On 10/18/2012 11:00 AM, Venkat Venkatsubra wrote:
>>
>> Hi Elliott,
>>
>> I see the same behavior with your test program.
>> The connect() keeps succeeding even though accept() is not performed.
>> It pauses after 4 connections for a while and then periodically keeps
>> adding few (2 I think).
>>
>> But the server side end points are terminated too. You will see only the
>> first 2 sessions on the server side.
>> If you modify your test program to say read or poll the sockets you should
>> get a termination notification on them I think .
>>
>> The behavior overall looks fine in my opinion. But it could be a change
>> of behavior for your test program.
>>
>> Venkat
>>
>> On 10/16/2012 6:31 PM, enh wrote:
>>>
>>> boiling things down to a short C++ program, i see that i can reproduce
>>> the behavior even on 2.6 kernels. if i run this, i see 4 connections
>>> immediately (3 + 1, as i'd expect)... but then about 10s later i see
>>> another 2. and every few seconds after that, i see another 2. i've let
>>> this run until i have hundreds of connect(2) calls that have returned,
>>> despite my small listen(2) backlog and the fact that i'm not
>>> accept(2)ing.
>>>
>>> so i guess the only thing that's changed with newer kernels is timing
>>> (hell, since i only see newer kernels on newer hardware, it might just
>>> be a hardware thing).
>>>
>>> and clearly i don't understand what the listen(2) backlog means any more.
>>>
>>> #include<netinet/ip.h>
>>> #include<netinet/tcp.h>
>>> #include<sys/types.h>
>>> #include<sys/socket.h>
>>> #include<iostream>
>>> #include<stdlib.h>
>>> #include<string.h>
>>> #include<errno.h>
>>>
>>> void dump_ti(int fd) {
>>> tcp_info ti;
>>> socklen_t tcp_info_length = sizeof(tcp_info);
>>> int rc = getsockopt(fd, SOL_IP, TCP_INFO,&ti,&tcp_info_length);
>>> if (rc == -1) {
>>> std::cout<< "getsockopt rc "<< rc<< ": "<< strerror(errno)<<
>>> "\n";
>>> return;
>>> }
>>>
>>> std::cout<< "ti.tcpi_unacked="<< ti.tcpi_unacked<< "\n";
>>> std::cout<< "ti.tcpi_sacked="<< ti.tcpi_sacked<< "\n";
>>> }
>>>
>>> void connect_to(sockaddr_in& sa) {
>>> int s = socket(AF_INET, SOCK_STREAM, 0);
>>> if (s == -1) {
>>> abort();
>>> }
>>>
>>> int rc = connect(s, (sockaddr*)&sa, sizeof(sockaddr_in));
>>> std::cout<< "connect = "<< rc<< "\n";
>>> }
>>>
>>> int main() {
>>> int ss = socket(AF_INET, SOCK_STREAM, 0);
>>> std::cout<< "socket fd "<< ss<< "\n";
>>>
>>> sockaddr_in sa;
>>> memset(&sa, 0, sizeof(sa));
>>> sa.sin_family = AF_INET;
>>> sa.sin_addr.s_addr = htonl(INADDR_ANY);
>>> sa.sin_port = htons(9877);
>>> int rc = bind(ss, (sockaddr*)&sa, sizeof(sa));
>>> std::cout<< "bind rc "<< rc<< ": "<< strerror(errno)<< "\n";
>>> std::cout<< "bind port "<< sa.sin_port<< "\n";
>>>
>>> rc = listen(ss, 1);
>>> std::cout<< "listen rc "<< rc<< ": "<< strerror(errno)<< "\n";
>>> dump_ti(ss);
>>>
>>> while (true) {
>>> connect_to(sa);
>>> dump_ti(ss);
>>> }
>>>
>>> return 0;
>>> }
>>>
>>>
>>> On Mon, Oct 15, 2012 at 10:26 AM, enh<enh@google.com> wrote:
>>>>
>>>> On Mon, Oct 15, 2012 at 10:12 AM, Venkat Venkatsubra
>>>> <venkat.x.venkatsubra@oracle.com> wrote:
>>>>>
>>>>> On 10/12/2012 6:40 PM, enh wrote:
>>>>>>
>>>>>> i used to use the following hack to unit test connect timeouts: i'd
>>>>>> call listen(2) on a socket and then deliberately connect (backlog + 3)
>>>>>> sockets without accept(2)ing any of the connections. (why 3? because
>>>>>> Stevens told me so, and experiment backed him up. see figure 4.10 in
>>>>>> his UNIX Network Programming.)
>>>>>>
>>>>>> with "old" kernels, 2.6.35-ish to 3.0-ish, this worked great. my next
>>>>>> connect(2) to the same loopback port would hang indefinitely. i could
>>>>>> even unblock the connect by calling accept(2) in another thread. this
>>>>>> was awesome for testing.
>>>>>>
>>>>>> in 3.1 on ARM, 3.2 on x86 (Ubuntu desktop), and 3.4 on ARM, this no
>>>>>> longer works. it doesn't seem to be as simple as "the constant is no
>>>>>> longer 3". my tests are now flaky. sometimes they work like they used
>>>>>> to, and sometimes an extra connect(2) will succeed. (or, if i'm in
>>>>>> non-blocking mode, my poll(2) will return with the non-blocking socket
>>>>>> that's trying to connect now ready.)
>>>>>>
>>>>>> i'm guessing if this changed in 3.1 and is still changed in 3.4,
>>>>>> whatever's changed wasn't an accident. but i haven't been able to find
>>>>>> the right search terms to RTFM. i also finally got around to grepping
>>>>>> the kernel for the "+ 3", but wasn't able to find that. (so i'd be
>>>>>> interested to know where the old behavior came from too.)
>>>>>>
>>>>>> my least worst workaround at the moment is to use one of RFC5737's
>>>>>> test networks, but that requires that the device have a network
>>>>>> connection, otherwise my connect(2)s fail immediately with
>>>>>> ENETUNREACH, which is no use to me. also, unlike my old trick, i've
>>>>>> got no way to suddenly "unblock" a slow connect(2) (this is useful for
>>>>>> unit testing the code that does the poll(2) part of the usual
>>>>>> connect-with-timeout implementation).
>>>>>> https://android-review.googlesource.com/#/c/44563/
>>>>>>
>>>>>> hopefully someone here can shed some light on this? ideally someone
>>>>>> will have a workaround as good as my old trick. i realize i was
>>>>>> relying on undocumented behavior, and i'm happy to have to check
>>>>>> /proc/version and behave appropriately, but i'd really like a way to
>>>>>> keep my unit tests!
>>>>>>
>>>>>> thanks,
>>>>>> elliott
>>>>>> --
>>>>>> 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
>>>>>
>>>>> Hi Elliott,
>>>>>
>>>>> In BSD I think the backlog used to be reset to 3/2 times that passed by
>>>>> the
>>>>> user. So, 2 becomes 3.
>>>>> Probably the 1/2 times increase was to accommodate the ones in
>>>>> partial/incomplete queue.
>>>>> In Linux is it possible you were getting the same behavior before the
>>>>> below
>>>>> commit ?
>>>>> Since the check used to be "backlog+1" a 2 will behave as 3 ?
>>>>
>>>> i don't think so, because with<= 3.0 kernels i used to have a backlog
>>>> of 1 and be able to make _4_ connections before my next connect would
>>>> hang. but this> to>= change is at least something for me to
>>>> investigate...
>>>>
>>>>> commit 8488df894d05d6fa41c2bd298c335f944bb0e401
>>>>> Author: Wei Dong<weid@np.css.fujitsu.com>
>>>>> Date: Fri Mar 2 12:37:26 2007 -0800
>>>>>
>>>>> [NET]: Fix bugs in "Whether sock accept queue is full" checking
>>>>>
>>>>> when I use linux TCP socket, and find there is a bug in
>>>>> function
>>>>> sk_acceptq_is_full().
>>>>>
>>>>> When a new SYN comes, TCP module first checks its validation.
>>>>> If
>>>>> valid,
>>>>> send SYN,ACK to the client and add the sock to the syn hash table.
>>>>> Next
>>>>> time if received the valid ACK for SYN,ACK from the client. server
>>>>> will
>>>>> accept this connection and increase the sk->sk_ack_backlog --
>>>>> which is
>>>>> done in function tcp_check_req().We check wether acceptq is full
>>>>> in
>>>>> function tcp_v4_syn_recv_sock().
>>>>>
>>>>> Consider an example:
>>>>>
>>>>> After listen(sockfd, 1) system call, sk->sk_max_ack_backlog is
>>>>> set to
>>>>> 1. As we know, sk->sk_ack_backlog is initialized to 0. Assuming
>>>>> accept()
>>>>> system call is not invoked now.
>>>>>
>>>>> 1. 1st connection comes. invoke sk_acceptq_is_full().
>>>>> sk->sk_ack_backlog=0 sk->sk_max_ack_backlog=1, function return 0
>>>>> accept
>>>>> this connection.
>>>>> Increase the sk->sk_ack_backlog
>>>>> 2. 2nd connection comes. invoke sk_acceptq_is_full().
>>>>> sk->sk_ack_backlog=1 sk->sk_max_ack_backlog=1, function return 0
>>>>> accept
>>>>> this connection.
>>>>> Increase the sk->sk_ack_backlog
>>>>> 3. 3rd connection comes. invoke sk_acceptq_is_full().
>>>>> sk->sk_ack_backlog=2 sk->sk_max_ack_backlog=1, function return 1.
>>>>> Refuse this connection.
>>>>>
>>>>> I think it has bugs. after listen system call.
>>>>> sk->sk_max_ack_backlog=1
>>>>> but now it can accept 2 connections.
>>>>>
>>>>> Signed-off-by: Wei Dong<weid@np.css.fujitsu.com>
>>>>> Signed-off-by: David S. Miller<davem@davemloft.net>
>>>>>
>>>>> Venkat
>>>
>>> --
>>> 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
>>
>>
>> --
>> 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
>
>
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
NIO, JNI, or bionic questions? Mail me/drop by/add me as a reviewer.
^ permalink raw reply
* RE: [PATCH] qla3xxx: Ensure req_q_phy_addr writes to the register
From: Jitendra Kalsaria @ 2012-10-18 17:10 UTC (permalink / raw)
To: Joe Jin
Cc: Ron Mercer, Dept-Eng Linux Driver, netdev, linux-kernel,
Greg Marsden
In-Reply-To: <507F66DF.4080606@oracle.com>
>>> -----Original Message-----
>>> From: Joe Jin [mailto:joe.jin@oracle.com]
>>> Sent: Tuesday, October 16, 2012 11:32 PM
>>> To: Ron Mercer; Jitendra Kalsaria; Dept-Eng Linux Driver
>>> Cc: netdev; linux-kernel; Greg Marsden
>>> Subject: [PATCH] qla3xxx: Ensure req_q_phy_addr writes to the register
>>>
>>> Make sure req_q_phy_addr write to the register.
>>>
>>> Signed-off-by: Joe Jin <joe.jin@oracle.com>
>>> Cc: Ron Mercer <ron.mercer@qlogic.com>
>>> Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>>> ---
>>> drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++++++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c
>>> index df09b1c..78b4cba 100644
>>> --- a/drivers/net/ethernet/qlogic/qla3xxx.c
>>> +++ b/drivers/net/ethernet/qlogic/qla3xxx.c
>>> @@ -2525,6 +2525,12 @@ static int ql_alloc_net_req_rsp_queues(struct ql3_adapter *qdev)
>>> qdev->req_q_size =
>>> (u32) (NUM_REQ_Q_ENTRIES * sizeof(struct ob_mac_iocb_req));
>>>
>>> + /*
>>> + * The barrier is required to ensure that req_q_phy_addr writes to
>>> + * the memory.
>>> + */
>>> + wmb();
>>> +
>>> qdev->req_q_virt_addr =
>>> pci_alloc_consistent(qdev->pdev,
>>> (size_t) qdev->req_q_size,
>>
>> Your changes only take care of request queue but not response queue which also need barrier.
>
>Jiten,
>
>Thanks for review!
>The barrier to make sure writel() call for req_q_phy_addr and rsp_q_phy_addr in
>ql_adapter_initialize(), so I think call once wmb() is enough but I need to update
>the comment, any idea?
Yes and something like "ensure request/response queue addr writes to the register"
^ 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