* Re: [PATCH 01/10] net: introduce time stamping wrapper for netif_rx.
From: Richard Cochran @ 2011-06-12 12:04 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20110611.161025.317157517912316585.davem@davemloft.net>
On Sat, Jun 11, 2011 at 04:10:25PM -0700, David Miller wrote:
>
> Also, it makes no sense to add this for obsolete RX processing such
> that netif_rx() is.
>
> If drivers want to add fancy features like this timestamping stuff,
> they better move on to NAPI, GRO, etc. first. Putting support for
> new features into deprecating things like netif_rx() makes no
> sense at all.
Okay, I see your point. I won't bother trying to improve the "academy
of ancient drivers," and I'll repost without the netif_rx wrapper.
However, I do want to support the coldfire fec driver, since Freescale
is selling two coldfire development boards with the dp83640 phy. But I
don't think it makes sense to try and upgrade the fec driver to napi,
when a simple "if !skb_defer_rx_timestamp" will do there.
Thanks,
Richard
^ permalink raw reply
* [PATCH V3 00/10] net: expand time stamping, batch #1
From: Richard Cochran @ 2011-06-12 12:18 UTC (permalink / raw)
To: netdev; +Cc: David Miller
This patch series represents the start of an effort to get better
coverage of the SO_TIMESTAMPING socket API in the Ethernet drivers.
Adding time stamping support to a given driver solves two separate
issues, namely software transmit time stamping and hardware time
stamping in PHY devices.
The SO_TIMESTAMPING socket API has been around since 2.6.30, but it
turned out that getting software transmit time stamps could not be
done in one central place in the stack. Instead, a work around was
introduced whereby each MAC driver must call a skb_tx_timestamp() hook
in order to support SW Tx time stamps.
Full PTP Hardware Clock (PHC) support has been merged for Linux 3.0,
including a driver for a PHY that does HW stamping. In the receive
path, the PHY based time stamping is handled by the stack for NAPI
based MAC drivers. But for transmit time stamps, support is needed in
the Ethernet MAC driver by calling the skb_tx_timestamp() hook.
The first patch exports a time stamping function for use in modules.
The next three patches enable PHY time stamping for two MACs which
have been paired with a PHC PHY on real life boards.
The remaining patches are for MACs that I chose because they (1) use
phylib and (2) compile for x86. However, I only compiled these, not
tested, since I do not have the hardware.
The larger goal is to eventually get the skb_tx_timestamp hook into as
many Ethernet MAC drivers as possible, so that SO_TIMESTAMPING using
SW time stamps will be supported across on most modern hardware. I
have started by picking those drivers in which adding the hook will
bring the greatest benefit, namely those using phylib, since adding
hooks provides both SW and PHY HW time stamping.
If people approve of this effort, I will follow with another patch
series adding SW Tx time stamping to yet more MACs. Adding SW Tx
support is just a single line, but still, perhaps compile testing only
is too risky. I would appreciate feedback on this issue.
Richard Cochran (10):
net: export time stamp utility function for Ethernet MAC drivers
fec: enable transmit and receive time stamping.
davinci_emac: pass ioctls through to phy device.
davinci_emac: enable transmit time stamping.
tg3: enable transmit time stamping.
dnet: enable transmit time stamping.
ethoc: enable transmit time stamping.
r6040: enable transmit time stamping.
stmmac: enable transmit time stamping.
smsc9420: enable transmit time stamping.
drivers/net/davinci_emac.c | 5 +++--
drivers/net/dnet.c | 2 ++
drivers/net/ethoc.c | 1 +
drivers/net/fec.c | 5 ++++-
drivers/net/r6040.c | 2 ++
drivers/net/smsc9420.c | 2 ++
drivers/net/stmmac/stmmac_main.c | 2 ++
drivers/net/tg3.c | 2 ++
net/core/timestamping.c | 1 +
9 files changed, 19 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH V3 01/10] net: export time stamp utility function for Ethernet MAC drivers
From: Richard Cochran @ 2011-06-12 12:18 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
The network stack provides the function, skb_clone_tx_timestamp().
Ethernet MAC drivers can call this via the transmit time stamping
hook, skb_tx_timestamp(). This commit exports the clone function so
that drivers using it can be compiled as modules.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
net/core/timestamping.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/timestamping.c b/net/core/timestamping.c
index 7e7ca37..3b00a6b 100644
--- a/net/core/timestamping.c
+++ b/net/core/timestamping.c
@@ -68,6 +68,7 @@ void skb_clone_tx_timestamp(struct sk_buff *skb)
break;
}
}
+EXPORT_SYMBOL_GPL(skb_clone_tx_timestamp);
void skb_complete_tx_timestamp(struct sk_buff *skb,
struct skb_shared_hwtstamps *hwtstamps)
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 02/10] fec: enable transmit and receive time stamping.
From: Richard Cochran @ 2011-06-12 12:18 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Greg Ungerer, Uwe Kleine-König, Shawn Guo
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch has been tested on the Freescale M5234BCC, which includes the
National Semiconductor DP83640 with IEEE 1588 support.
Cc: Greg Ungerer <gerg@uclinux.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/fec.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 885d8ba..965fe90 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -326,6 +326,8 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
spin_unlock_irqrestore(&fep->hw_lock, flags);
+ skb_tx_timestamp(skb);
+
return NETDEV_TX_OK;
}
@@ -650,7 +652,8 @@ fec_enet_rx(struct net_device *ndev)
skb_put(skb, pkt_len - 4); /* Make room */
skb_copy_to_linear_data(skb, data, pkt_len - 4);
skb->protocol = eth_type_trans(skb, ndev);
- netif_rx(skb);
+ if (!skb_defer_rx_timestamp(skb))
+ netif_rx(skb);
}
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, data,
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 03/10] davinci_emac: pass ioctls through to phy device.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Anant Gole, Kevin Hilman
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
The DaVinci EMAC driver does not implement any ioctls, but still it can
pass them through to the phy device. This makes it possible for a phy
to offer PHC capabilities.
Cc: Anant Gole <anantgole@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/davinci_emac.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index dcc4a17..5c2baa4 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1489,14 +1489,14 @@ static void emac_adjust_link(struct net_device *ndev)
*/
static int emac_devioctl(struct net_device *ndev, struct ifreq *ifrq, int cmd)
{
- dev_warn(&ndev->dev, "DaVinci EMAC: ioctl not supported\n");
+ struct emac_priv *priv = netdev_priv(ndev);
if (!(netif_running(ndev)))
return -EINVAL;
/* TODO: Add phy read and write and private statistics get feature */
- return -EOPNOTSUPP;
+ return phy_mii_ioctl(priv->phydev, ifrq, cmd);
}
static int match_first_device(struct device *dev, void *data)
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 04/10] davinci_emac: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Anant Gole, Kevin Hilman
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the DaVinci EMAC driver. Tested together with the dp83640 PHY.
Cc: Anant Gole <anantgole@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/davinci_emac.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 5c2baa4..f5688ff 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1090,6 +1090,7 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
dev_err(emac_dev, "DaVinci EMAC: desc submit failed");
goto fail_tx;
}
+ skb_tx_timestamp(skb);
return NETDEV_TX_OK;
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 05/10] tg3: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Matt Carlson, Michael Chan
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the TIGON3 driver. Compile tested only.
Cc: Matt Carlson <mcarlson@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/tg3.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a1f9f9e..743d997 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6091,6 +6091,8 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Packets are ready, update Tx producer idx local and on card. */
tw32_tx_mbox(tnapi->prodmbox, entry);
+ skb_tx_timestamp(skb);
+
tnapi->tx_prod = entry;
if (unlikely(tg3_tx_avail(tnapi) <= (MAX_SKB_FRAGS + 1))) {
netif_tx_stop_queue(txq);
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 06/10] dnet: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ilya Yanok
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
in the "Dave ethernet interface." Compile tested only.
Cc: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/dnet.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/dnet.c b/drivers/net/dnet.c
index 8318ea0..c36763c 100644
--- a/drivers/net/dnet.c
+++ b/drivers/net/dnet.c
@@ -587,6 +587,8 @@ static netdev_tx_t dnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
dnet_writel(bp, irq_enable, INTR_ENB);
}
+ skb_tx_timestamp(skb);
+
/* free the buffer */
dev_kfree_skb(skb);
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 07/10] ethoc: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Thierry Reding
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the OpenCores 10/100 MAC driver. Compile tested only.
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/ethoc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c
index a83dd31..8645ec8 100644
--- a/drivers/net/ethoc.c
+++ b/drivers/net/ethoc.c
@@ -874,6 +874,7 @@ static netdev_tx_t ethoc_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
spin_unlock_irq(&priv->lock);
+ skb_tx_timestamp(skb);
out:
dev_kfree_skb(skb);
return NETDEV_TX_OK;
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 08/10] r6040: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Florian Fainelli
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the RDC R6040 Fast Ethernet MAC. Compile tested only.
Cc: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/r6040.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 200a363..5ee5f8f 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -846,6 +846,8 @@ static netdev_tx_t r6040_start_xmit(struct sk_buff *skb,
spin_unlock_irqrestore(&lp->lock, flags);
+ skb_tx_timestamp(skb);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 09/10] stmmac: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Giuseppe Cavallaro
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the STMicroelectronics Ethernet driver. Compile tested only.
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/stmmac/stmmac_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index e25e44a..5b85f4c 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -1081,6 +1081,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
priv->hw->dma->enable_dma_transmission(priv->ioaddr);
+ skb_tx_timestamp(skb);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 10/10] smsc9420: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Steve Glendinning
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the smsc9420. Compile tested only.
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/smsc9420.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smsc9420.c b/drivers/net/smsc9420.c
index 4c92ad8..2d84f92 100644
--- a/drivers/net/smsc9420.c
+++ b/drivers/net/smsc9420.c
@@ -1034,6 +1034,8 @@ static netdev_tx_t smsc9420_hard_start_xmit(struct sk_buff *skb,
smsc9420_reg_write(pd, TX_POLL_DEMAND, 1);
smsc9420_pci_flush_write(pd);
+ skb_tx_timestamp(skb);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius B. Kotsbak @ 2011-06-12 12:35 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius B. Kotsbak
In-Reply-To: <20110611.162942.1706711069327005315.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
It has also an ACM interface that previous patches associates with the "option"
module. To access those interfaces, the modem must first be switched from modem
mode using a tool like usb_modeswitch.
As the proprietary protocol has been discovered by watching the MS Windows driver
behavior, there might be errors in the protocol handling, but stable and fast
connection has been established for hours with Norwegian operator NetCom that
distributes this modem with their LTE/4G subscription.
More and updated information about how to use this driver is available here:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
Signed-off-by: Marius B. Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/Kconfig | 10 ++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/kalmia.c | 384 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 395 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/usb/kalmia.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 9d4f911..84d4608 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -385,6 +385,16 @@ config USB_NET_CX82310_ETH
router with USB ethernet port. This driver is for routers only,
it will not work with ADSL modems (use cxacru driver instead).
+config USB_NET_KALMIA
+ tristate "Samsung Kalmia based LTE USB modem"
+ depends on USB_USBNET
+ help
+ Choose this option if you have a Samsung Kalmia based USB modem
+ as Samsung GT-B3730.
+
+ To compile this driver as a module, choose M here: the
+ module will be called kalmia.
+
config USB_HSO
tristate "Option USB High Speed Mobile Devices"
depends on USB && RFKILL
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index c7ec8a5..c203fa2 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_USB_NET_MCS7830) += mcs7830.o
obj-$(CONFIG_USB_USBNET) += usbnet.o
obj-$(CONFIG_USB_NET_INT51X1) += int51x1.o
obj-$(CONFIG_USB_CDC_PHONET) += cdc-phonet.o
+obj-$(CONFIG_USB_NET_KALMIA) += kalmia.o
obj-$(CONFIG_USB_IPHETH) += ipheth.o
obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
obj-$(CONFIG_USB_NET_CX82310_ETH) += cx82310_eth.o
diff --git a/drivers/net/usb/kalmia.c b/drivers/net/usb/kalmia.c
new file mode 100644
index 0000000..d965fb1
--- /dev/null
+++ b/drivers/net/usb/kalmia.c
@@ -0,0 +1,384 @@
+/*
+ * USB network interface driver for Samsung Kalmia based LTE USB modem like the
+ * Samsung GT-B3730 and GT-B3710.
+ *
+ * Copyright (C) 2011 Marius Bjoernstad Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
+ *
+ * Sponsored by Quicklink Video Distribution Services Ltd.
+ *
+ * Based on the cdc_eem module.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ctype.h>
+#include <linux/ethtool.h>
+#include <linux/workqueue.h>
+#include <linux/mii.h>
+#include <linux/usb.h>
+#include <linux/crc32.h>
+#include <linux/usb/cdc.h>
+#include <linux/usb/usbnet.h>
+#include <linux/gfp.h>
+
+/*
+ * The Samsung Kalmia based LTE USB modems have a CDC ACM port for modem control
+ * handled by the "option" module and an ethernet data port handled by this
+ * module.
+ *
+ * The stick must first be switched into modem mode by usb_modeswitch
+ * or similar tool. Then the modem gets sent two initialization packets by
+ * this module, which gives the MAC address of the device. User space can then
+ * connect the modem using AT commands through the ACM port and then use
+ * DHCP on the network interface exposed by this module. Network packets are
+ * sent to and from the modem in a proprietary format discovered after watching
+ * the behavior of the windows driver for the modem.
+ *
+ * More information about the use of the modem is available in usb_modeswitch
+ * forum and the project page:
+ *
+ * http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
+ * https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
+ */
+
+/* #define DEBUG */
+/* #define VERBOSE */
+
+#define KALMIA_HEADER_LENGTH 6
+#define KALMIA_ALIGN_SIZE 4
+#define KALMIA_USB_TIMEOUT 10000
+
+/*-------------------------------------------------------------------------*/
+
+static int
+kalmia_send_init_packet(struct usbnet *dev, u8 *init_msg, u8 init_msg_len,
+ u8 *buffer, u8 expected_len)
+{
+ int act_len;
+ int status;
+
+ netdev_dbg(dev->net, "Sending init packet");
+
+ status = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 0x02),
+ init_msg, init_msg_len, &act_len, KALMIA_USB_TIMEOUT);
+ if (status != 0) {
+ netdev_err(dev->net,
+ "Error sending init packet. Status %i, length %i\n",
+ status, act_len);
+ return status;
+ }
+ else if (act_len != init_msg_len) {
+ netdev_err(dev->net,
+ "Did not send all of init packet. Bytes sent: %i",
+ act_len);
+ }
+ else {
+ netdev_dbg(dev->net, "Successfully sent init packet.");
+ }
+
+ status = usb_bulk_msg(dev->udev, usb_rcvbulkpipe(dev->udev, 0x81),
+ buffer, expected_len, &act_len, KALMIA_USB_TIMEOUT);
+
+ if (status != 0)
+ netdev_err(dev->net,
+ "Error receiving init result. Status %i, length %i\n",
+ status, act_len);
+ else if (act_len != expected_len)
+ netdev_err(dev->net, "Unexpected init result length: %i\n",
+ act_len);
+
+ return status;
+}
+
+static int
+kalmia_init_and_get_ethernet_addr(struct usbnet *dev, u8 *ethernet_addr)
+{
+ char init_msg_1[] =
+ { 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00,
+ 0x00, 0x00 };
+ char init_msg_2[] =
+ { 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0xf4,
+ 0x00, 0x00 };
+ char receive_buf[28];
+ int status;
+
+ status = kalmia_send_init_packet(dev, init_msg_1, sizeof(init_msg_1)
+ / sizeof(init_msg_1[0]), receive_buf, 24);
+ if (status != 0)
+ return status;
+
+ status = kalmia_send_init_packet(dev, init_msg_2, sizeof(init_msg_2)
+ / sizeof(init_msg_2[0]), receive_buf, 28);
+ if (status != 0)
+ return status;
+
+ memcpy(ethernet_addr, receive_buf + 10, ETH_ALEN);
+
+ return status;
+}
+
+static int
+kalmia_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+ u8 status;
+ u8 ethernet_addr[ETH_ALEN];
+
+ /* Don't bind to AT command interface */
+ if (intf->cur_altsetting->desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC)
+ return -EINVAL;
+
+ dev->in = usb_rcvbulkpipe(dev->udev, 0x81 & USB_ENDPOINT_NUMBER_MASK);
+ dev->out = usb_sndbulkpipe(dev->udev, 0x02 & USB_ENDPOINT_NUMBER_MASK);
+ dev->status = NULL;
+
+ dev->net->hard_header_len += KALMIA_HEADER_LENGTH;
+ dev->hard_mtu = 1400;
+ dev->rx_urb_size = dev->hard_mtu * 10; // Found as optimal after testing
+
+ status = kalmia_init_and_get_ethernet_addr(dev, ethernet_addr);
+
+ if (status < 0) {
+ usb_set_intfdata(intf, NULL);
+ usb_driver_release_interface(driver_of(intf), intf);
+ return status;
+ }
+
+ memcpy(dev->net->dev_addr, ethernet_addr, ETH_ALEN);
+ memcpy(dev->net->perm_addr, ethernet_addr, ETH_ALEN);
+
+ return status;
+}
+
+static struct sk_buff *
+kalmia_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
+{
+ struct sk_buff *skb2 = NULL;
+ u16 content_len;
+ unsigned char *header_start;
+ unsigned char ether_type_1, ether_type_2;
+ u8 remainder, padlen = 0;
+
+ if (!skb_cloned(skb)) {
+ int headroom = skb_headroom(skb);
+ int tailroom = skb_tailroom(skb);
+
+ if ((tailroom >= KALMIA_ALIGN_SIZE) && (headroom
+ >= KALMIA_HEADER_LENGTH))
+ goto done;
+
+ if ((headroom + tailroom) > (KALMIA_HEADER_LENGTH
+ + KALMIA_ALIGN_SIZE)) {
+ skb->data = memmove(skb->head + KALMIA_HEADER_LENGTH,
+ skb->data, skb->len);
+ skb_set_tail_pointer(skb, skb->len);
+ goto done;
+ }
+ }
+
+ skb2 = skb_copy_expand(skb, KALMIA_HEADER_LENGTH,
+ KALMIA_ALIGN_SIZE, flags);
+ if (!skb2)
+ return NULL;
+
+ dev_kfree_skb_any(skb);
+ skb = skb2;
+
+ done: header_start = skb_push(skb, KALMIA_HEADER_LENGTH);
+ ether_type_1 = header_start[KALMIA_HEADER_LENGTH + 12];
+ ether_type_2 = header_start[KALMIA_HEADER_LENGTH + 13];
+
+ netdev_dbg(dev->net, "Sending etherType: %02x%02x", ether_type_1,
+ ether_type_2);
+
+ /* According to empiric data for data packages */
+ header_start[0] = 0x57;
+ header_start[1] = 0x44;
+ content_len = skb->len - KALMIA_HEADER_LENGTH;
+ header_start[2] = (content_len & 0xff); /* low byte */
+ header_start[3] = (content_len >> 8); /* high byte */
+
+ header_start[4] = ether_type_1;
+ header_start[5] = ether_type_2;
+
+ /* Align to 4 bytes by padding with zeros */
+ remainder = skb->len % KALMIA_ALIGN_SIZE;
+ if (remainder > 0) {
+ padlen = KALMIA_ALIGN_SIZE - remainder;
+ memset(skb_put(skb, padlen), 0, padlen);
+ }
+
+ netdev_dbg(
+ dev->net,
+ "Sending package with length %i and padding %i. Header: %02x:%02x:%02x:%02x:%02x:%02x.",
+ content_len, padlen, header_start[0], header_start[1],
+ header_start[2], header_start[3], header_start[4],
+ header_start[5]);
+
+ return skb;
+}
+
+static int
+kalmia_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+ /*
+ * Our task here is to strip off framing, leaving skb with one
+ * data frame for the usbnet framework code to process.
+ */
+ const u8 HEADER_END_OF_USB_PACKET[] =
+ { 0x57, 0x5a, 0x00, 0x00, 0x08, 0x00 };
+ const u8 EXPECTED_UNKNOWN_HEADER_1[] =
+ { 0x57, 0x43, 0x1e, 0x00, 0x15, 0x02 };
+ const u8 EXPECTED_UNKNOWN_HEADER_2[] =
+ { 0x57, 0x50, 0x0e, 0x00, 0x00, 0x00 };
+ u8 i = 0;
+
+ /* incomplete header? */
+ if (skb->len < KALMIA_HEADER_LENGTH)
+ return 0;
+
+ do {
+ struct sk_buff *skb2 = NULL;
+ u8 *header_start;
+ u16 usb_packet_length, ether_packet_length;
+ int is_last;
+
+ header_start = skb->data;
+
+ if (unlikely(header_start[0] != 0x57 || header_start[1] != 0x44)) {
+ if (!memcmp(header_start, EXPECTED_UNKNOWN_HEADER_1,
+ sizeof(EXPECTED_UNKNOWN_HEADER_1)) || !memcmp(
+ header_start, EXPECTED_UNKNOWN_HEADER_2,
+ sizeof(EXPECTED_UNKNOWN_HEADER_2))) {
+ netdev_dbg(
+ dev->net,
+ "Received expected unknown frame header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ }
+ else {
+ netdev_err(
+ dev->net,
+ "Received unknown frame header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ return 0;
+ }
+ }
+ else
+ netdev_dbg(
+ dev->net,
+ "Received header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1], header_start[2],
+ header_start[3], header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+
+ /* subtract start header and end header */
+ usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH);
+ ether_packet_length = header_start[2] + (header_start[3] << 8);
+ skb_pull(skb, KALMIA_HEADER_LENGTH);
+
+ /* Some small packets misses end marker */
+ if (usb_packet_length < ether_packet_length) {
+ ether_packet_length = usb_packet_length
+ + KALMIA_HEADER_LENGTH;
+ is_last = true;
+ }
+ else {
+ netdev_dbg(dev->net, "Correct package length #%i", i
+ + 1);
+
+ is_last = (memcmp(skb->data + ether_packet_length,
+ HEADER_END_OF_USB_PACKET,
+ sizeof(HEADER_END_OF_USB_PACKET)) == 0);
+ if (!is_last) {
+ header_start = skb->data + ether_packet_length;
+ netdev_dbg(
+ dev->net,
+ "End header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ }
+ }
+
+ if (is_last) {
+ skb2 = skb;
+ }
+ else {
+ skb2 = skb_clone(skb, GFP_ATOMIC);
+ if (unlikely(!skb2))
+ return 0;
+ }
+
+ skb_trim(skb2, ether_packet_length);
+
+ if (is_last) {
+ return 1;
+ }
+ else {
+ usbnet_skb_return(dev, skb2);
+ skb_pull(skb, ether_packet_length);
+ }
+
+ i++;
+ }
+ while (skb->len);
+
+ return 1;
+}
+
+static const struct driver_info kalmia_info = {
+ .description = "Samsung Kalmia LTE USB dongle",
+ .flags = FLAG_WWAN,
+ .bind = kalmia_bind,
+ .rx_fixup = kalmia_rx_fixup,
+ .tx_fixup = kalmia_tx_fixup
+};
+
+/*-------------------------------------------------------------------------*/
+
+static const struct usb_device_id products[] = {
+ /* The unswitched USB ID, to get the module auto loaded: */
+ { USB_DEVICE(0x04e8, 0x689a) },
+ /* The stick swithed into modem (by e.g. usb_modeswitch): */
+ { USB_DEVICE(0x04e8, 0x6889),
+ .driver_info = (unsigned long) &kalmia_info, },
+ { /* EMPTY == end of list */} };
+MODULE_DEVICE_TABLE( usb, products);
+
+static struct usb_driver kalmia_driver = {
+ .name = "kalmia",
+ .id_table = products,
+ .probe = usbnet_probe,
+ .disconnect = usbnet_disconnect,
+ .suspend = usbnet_suspend,
+ .resume = usbnet_resume
+};
+
+static int __init kalmia_init(void)
+{
+ return usb_register(&kalmia_driver);
+}
+module_init( kalmia_init);
+
+static void __exit kalmia_exit(void)
+{
+ usb_deregister(&kalmia_driver);
+}
+module_exit( kalmia_exit);
+
+MODULE_AUTHOR("Marius Bjoernstad Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("Samsung Kalmia USB network driver");
+MODULE_LICENSE("GPL");
--
1.7.4.1
--
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
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius Kotsbak @ 2011-06-12 12:36 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110611.162942.1706711069327005315.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 12. juni 2011 01:29, David Miller wrote:
> From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Date: Sat, 11 Jun 2011 16:27:11 -0700 (PDT)
>
>> From: "Marius B. Kotsbak" <marius.kotsbak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Sat, 11 Jun 2011 23:55:18 +0200
>>
>>> Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
>>> It has also an ACM interface that previous patches associates with the "option"
>>> module. To access those interfaces, the modem must first be switched from modem
>>> mode using a tool like usb_modeswitch.
>>>
>>> As the proprietary protocol has been discovered by watching the MS Windows driver
>>> behavior, there might be errors in the protocol handling, but stable and fast
>>> connection has been established for hours with Norwegian operator NetCom that
>>> distributes this modem with their LTE/4G subscription.
>>>
>>> More and updated information about how to use this driver is available here:
>>>
>>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
>>> https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
>>>
>>> Signed-off-by: Marius B. Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
>> Applied, thanks.
> Actually, reverted.
>
> There's a typo in your Makefile patch, and because of this it
> won't even build the new driver.
Oh sorry, I did make on the actual kalmia.ko to avoid building all
modules, so I did not notice. Sending a fixed patch. Ben, thanks for
pointing out.
> People are so damn anxious to get this backported into stable
> and various distributions,
Japp, people keeps asking for a version that compiles with kernel 2.6.32
for the Ubuntu LTS...
> yet this patch wasn't even tested
> properly.
We were compiling it out of the kernel tree until now.
--
Marius
--
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
* Re: [RFC] procfs: add hidepid and hidenet modes
From: Vasiliy Kulikov @ 2011-06-12 12:43 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-kernel, David S. Miller, Andrew Morton, Linus Torvalds,
Nikanth Karthikesan, David Rientjes, Greg Kroah-Hartman, Al Viro,
Eric Dumazet, netdev, kernel-hardening
In-Reply-To: <20110612111222.GA23467@p183.telecom.by>
On Sun, Jun 12, 2011 at 14:12 +0300, Alexey Dobriyan wrote:
> On Sun, Jun 12, 2011 at 11:51:01AM +0400, Vasiliy Kulikov wrote:
> > hidenet means /proc/PID/net will be accessible to processes with
> > CAP_NET_ADMIN capability or to members of a special group.
> >
> > gid=XXX defines a group that will be able to gather all processes' info
> > and network connections info.
> >
> > Similar features are implemented for old kernels in -ow patches (for
> > Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity (but both of them
> > are implemented as configure options, not cofigurable in runtime).
> >
> >
> > In current version hidenet works for CONFIG_NET_NS=y via creating a
> > "fake" net namespace and slipping it to nonauthorized users, resulting
> > in users observing blank net files (like nobody use the network). If
> > CONFIG_NET_NS=n I don't see anything better than just fully denying
> > access to /proc/<pid>/net. More elegant ideas are welcome.
>
> This fake netns concept is ugly.
> If you wan't deny something, why don't you return -E?
Sorry, I should have mentioned it. It's a workaround. The thing is
that /proc/net/* is so core and existed for a long time that some
programs might be confused if these files are missing or if open()
returns -EXXX. netstat handles this and outputs smth like "Networking
was disabled in your kernel", which is a bit confusing. Also I saw some
programs didn't handle missing files at all, I recall brctl sigfaulted
when he couldn't access some sysfs file.
As fake_net doesn't break something, but instead keeps some
compatibility with old programs, why don't use it?
BTW, there is no fake_net in -ow or -grsecurity. I thought it might be
helpful for upstream in sense of compatibility.
> Regardless, these should be separate patch from PID stuff.
No problem.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* [PATCH] ieee802154: Don't leak memory in ieee802154_nl_fill_phy
From: Jesper Juhl @ 2011-06-12 14:28 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, linux-zigbee-devel, David S. Miller, Sergey Lapin,
Dmitry Eremin-Solenikov, Maxim Osipov
In net/ieee802154/nl-phy.c::ieee802154_nl_fill_phy() I see two small
issues.
1) If the allocation of 'buf' fails we may just as well return -EMSGSIZE
directly rather than jumping to 'out:' and do a pointless kfree(0).
2) We do not free 'buf' unless we jump to one of the error labels and this
leaks memory.
This patch should address both.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
nl-phy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
I have no way to properly test this patch, so it's compile tested only.
diff --git a/net/ieee802154/nl-phy.c b/net/ieee802154/nl-phy.c
index ed0eab3..02548b2 100644
--- a/net/ieee802154/nl-phy.c
+++ b/net/ieee802154/nl-phy.c
@@ -44,7 +44,7 @@ static int ieee802154_nl_fill_phy(struct sk_buff *msg, u32 pid,
pr_debug("%s\n", __func__);
if (!buf)
- goto out;
+ return -EMSGSIZE;
hdr = genlmsg_put(msg, 0, seq, &nl802154_family, flags,
IEEE802154_LIST_PHY);
@@ -65,6 +65,7 @@ static int ieee802154_nl_fill_phy(struct sk_buff *msg, u32 pid,
pages * sizeof(uint32_t), buf);
mutex_unlock(&phy->pib_lock);
+ kfree(buf);
return genlmsg_end(msg, hdr);
nla_put_failure:
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [RFC v2 01/04] net: make net_create() globally visible
From: Vasiliy Kulikov @ 2011-06-12 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-hardening, Andrew Morton, Greg Kroah-Hartman,
David S. Miller, Eric Dumazet, netdev
Make net_create() visible outside of net/core/net_namespace.c to be able
to create additional network namespaces inside of fs/proc/proc_net.c.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
include/net/net_namespace.h | 2 ++
net/core/net_namespace.c | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 1bf812b..d40c61c 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -113,6 +113,8 @@ static inline struct net *copy_net_ns(unsigned long flags, struct net *net_ns)
}
#endif /* CONFIG_NET */
+extern struct net *net_create(void);
+
extern struct list_head net_namespace_list;
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 3f86026..c7c7310 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -216,7 +216,7 @@ static void net_free(struct net *net)
kmem_cache_free(net_cachep, net);
}
-static struct net *net_create(void)
+struct net *net_create(void)
{
struct net *net;
int rv;
^ permalink raw reply related
* Re: Question about LRO/GRO and TCP acknowledgements
From: Eric Dumazet @ 2011-06-12 14:57 UTC (permalink / raw)
To: Joris van Rantwijk; +Cc: netdev
In-Reply-To: <20110612132428.3e1a4593@konijn>
Le dimanche 12 juin 2011 à 13:24 +0200, Joris van Rantwijk a écrit :
> On 2011-06-12, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > So your concern is more a Sender side implementation missing this
> > recommendation, not GRO per se...
>
> Not really. The same RFC says:
> Specifically, an ACK SHOULD be generated for at least every
> second full-sized segment, ...
>
Well, SHOULD is not MUST.
> I can see how the world may have been a better place if every sender
> implemented Appropriate Byte Counting and TCP receivers were allowed to
> send fewer ACKs. However, current reality is that ABC is optional,
> disabled by default in Linux, and receivers are recommended to send one
> ACK per two segments.
>
ABC might be nice for stacks that use byte counters for cwnd. We use
segments.
> I suspect that GRO currently hurts throughput of isolated TCP
> connections. This is based on a purely theoretic argument. I may be
> wrong and I have absolutely no data to confirm my suspicion.
>
> If you can point out the flaw in my reasoning, I would be greatly
> relieved. Until then, I remain concerned that there may be something
> wrong with GRO and TCP ACKs.
Think of GRO being a receiver facility against stress/load, typically in
datacenter.
Only when receiver is overloaded, GRO kicks in and can coalesce several
frames before being handled in TCP stack in one run.
If receiver is so loaded that more than 2 frames are coalesced in a NAPI
run, it certainly helps to not allow sender to increase its cwnd more
than one SMSS. We probably are right before packet drops anyway.
^ permalink raw reply
* Re: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Avi Kivity @ 2011-06-12 15:38 UTC (permalink / raw)
To: Simon Horman
Cc: Brad Campbell, Eric Dumazet, Patrick McHardy, Bart De Schuymer,
kvm, linux-mm, linux-kernel, netdev, netfilter-devel
In-Reply-To: <20110610025249.GD643@verge.net.au>
On 06/10/2011 05:52 AM, Simon Horman wrote:
> At one point I would have need an 8000km long wire to the reset switch :-)
Even more off-topic, there has been a case when a 200,000,000 km long
wire to the reset button was needed. IIRC they got away with a watchdog.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Linus Torvalds @ 2011-06-12 17:59 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Al Viro, linux-fsdevel, netdev, Linux Containers
In-Reply-To: <m1y617wmeb.fsf@fess.ebiederm.org>
On Sun, Jun 12, 2011 at 12:15 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> I honestly hate the pattern that is being used here. Holding a
> reference count because we can't be bothered to free things reliably
> when we actually stop using them.
WHAT?
That's what a reference count *is*. It's all about "free things
reliably when we actually stop using them".
Your comment makes zero sense.
EVERY SINGLE kernel data structure should be reference counted. Read
Documentation/CodingStyle, or look at any of the good code in the
kernel (ie core process or VFS code). A non-refcounted data structure
that is used by more than one entity IS A BUG!
Quite frankly, your objection sounds moronic. If there is more than
one user, then a reference count is _always_ the right thing. Nothing
else ever works, and trust me, people have tried. They've tried
locking, they've tried luck, they've tried crazy things. Nothing but
refcounts works.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Al Viro @ 2011-06-12 18:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, linux-fsdevel, netdev, Linux Containers
In-Reply-To: <BANLkTi=AfYH1eg_O1N2M9BfcF=UmBFPy6w@mail.gmail.com>
On Sun, Jun 12, 2011 at 10:59:42AM -0700, Linus Torvalds wrote:
> On Sun, Jun 12, 2011 at 12:15 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> >
> > I honestly hate the pattern that is being used here. ?Holding a
> > reference count because we can't be bothered to free things reliably
> > when we actually stop using them.
>
> WHAT?
>
> That's what a reference count *is*. It's all about "free things
> reliably when we actually stop using them".
>
> Your comment makes zero sense.
>
> EVERY SINGLE kernel data structure should be reference counted. Read
> Documentation/CodingStyle, or look at any of the good code in the
> kernel (ie core process or VFS code). A non-refcounted data structure
> that is used by more than one entity IS A BUG!
>
> Quite frankly, your objection sounds moronic. If there is more than
> one user, then a reference count is _always_ the right thing. Nothing
> else ever works, and trust me, people have tried. They've tried
> locking, they've tried luck, they've tried crazy things. Nothing but
> refcounts works.
No, what the current code is trying to do is to have two kinds of references -
contributing to refcount (they do have one, all right) and non-contributing.
*AND* it attempts to hunt non-contributing ones down and replace them with
NULL when refcount hits zero. And fscks up in dealing with the results.
What this patch does is pretty much the same thing we do for mm_struct and
superblocks - two refcounts, one controlling the shutdown of object and another
controlling the actual freeing of memory. The second kind of references
contributes to the "memory" refcount and so does having non-zero "active"
refcount. No games with replacing references with NULL, no races around those,
etc.
Eric's objection is that sysfs superblock would pin the memory occupied by
struct net down until it's unmounted. Frankly, I think it's a BS -
aforementioned 2.5K are trivial to pin down *anyway*. Just chdir deep
enough into that instance of sysfs tree and inodes/dentries you've pinned
down by that will easily eat this much.
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Al Viro @ 2011-06-12 18:35 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-fsdevel, Linus Torvalds, netdev, Linux Containers
In-Reply-To: <m1y617wmeb.fsf@fess.ebiederm.org>
On Sun, Jun 12, 2011 at 12:15:40AM -0700, Eric W. Biederman wrote:
> I honestly hate the pattern that is being used here. Holding a
> reference count because we can't be bothered to free things reliably
> when we actually stop using them. It does look less error prone than
> what I am doing today, and 2.5KiB for struct net isn't that much memory
> to pin.
What pattern? Dual refcounts, one for tearing the contents down and another
for keeping the structure allocated (and it address not reused)? We are
using that kind of stuff for many things. Sure, we have cases when there
are pointers to object not contributing to refcount, to be removed on
object destruction. But if you look at those you'll see that normally
it's done for something like "this object can be found in cyclic list/hash
chain/etc.; those references are not affecting refcount and we simply remove
the object from those lists when refcount hits zero". The thing is, those
references are trivially found starting at the object. In case of non-counting
references from sysfs superblocks it's nowhere near that. And in cases of
that kind the use of dual refcounts is normal.
BTW, speaking of refcounts - I have a pending patch fixing a pid_namespace
leak in proc_set_super(); will be in the next pull request. anon_set_super()
can fail...
> Will pinning an extra 2.5KiB be a problem when we get to the point where
> unprivileged mounts are safe? I expect there are easier ways to pin more
> memory so I doubt this is worth worrying about.
*snort*
chdir deep enough into sysfs tree and you've got it.
> It isn't clear what is taking or putting what kind of refcount from the
> names. If we don't correct the bad naming your patch will be worse for
> maintenance than what we already have.
Agreed. Suggestions of better names are welcome. In particular, I considered
s/count/active/ and calling new refcount "count".
> We need to rename kobj_ns_current so it is clear we get a ref count.
Agreed. Suggestions?
> > + for (type = KOBJ_NS_TYPE_NONE; type < KOBJ_NS_TYPES; type++)
> > + kobj_ns_put(type, info->ns[type]);
>
> This loop and the kfree probably deserve a small function of their own.
OK.
> I really don't like removing const here. It made it very clear that
> what we are messing with is a token and not something that we ever will
> deference.
But we will - when we drop the reference, refcount is going to change...
> > +static void *net_current_ns(void)
> > {
> > - return current->nsproxy->net_ns;
> > + struct net *ns = current->nsproxy->net_ns;
> > +#ifdef CONFIG_NET_NS
> > + if (ns)
> > + atomic_inc(&ns->passive);
> > +#endif
> This code doesn't need to be #ifdef'd
> > + return ns;
> > }
It does, unless we want to make net_put_ns() non-NULL in !NET_NS case...
> > +void net_put_ns(void *p)
> > +{
> There has got to be a better name. We already have put and get net
> methods.
Um... Suggestions? hold_current_ns/drop_ns?
^ permalink raw reply
* Re: Question about LRO/GRO and TCP acknowledgements
From: Joris van Rantwijk @ 2011-06-12 19:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1307890657.2872.158.camel@edumazet-laptop>
On 2011-06-12, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Think of GRO being a receiver facility against stress/load, typically
> in datacenter.
>
> Only when receiver is overloaded, GRO kicks in and can coalesce
> several frames before being handled in TCP stack in one run.
Ok, it now becomes clear to me that I have a different scenario in mind
than GRO was designed to handle. I'm interested in LRO as a method
to sustain 1 Gbit through a single TCP connection on a slow embedded
computer.
> If receiver is so loaded that more than 2 frames are coalesced in a
> NAPI run, it certainly helps to not allow sender to increase its cwnd
> more than one SMSS. We probably are right before packet drops anyway.
Right. So unlike TSO, GRO is not a transparent, generally applicable
performance improvement. It's more like a form of graceful degradation,
helping a server to sustain overall throughput when it is already
swamped in TCP traffic.
Thanks for your clarification. This has certainly solved some confusion
on my side.
Joris.
^ permalink raw reply
* 3c503: fix broken IRQ autoprobing
From: Ondrej Zary @ 2011-06-12 19:40 UTC (permalink / raw)
To: netdev; +Cc: Kernel development list
Fix broken IRQ autoprobing in 3c503 driver:
- improper IRQ freeing (does not free IRQs causes WARN)
- missing break when an working IRQ is found
The driver works with this patch.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.39-rc2-orig/drivers/net/3c503.c 2011-04-06 03:30:43.000000000 +0200
+++ linux-2.6.39-rc2/drivers/net/3c503.c 2011-06-12 21:29:47.000000000 +0200
@@ -412,7 +412,7 @@ el2_open(struct net_device *dev)
outb_p(0x04 << ((*irqp == 9) ? 2 : *irqp), E33G_IDCFR);
outb_p(0x00, E33G_IDCFR);
msleep(1);
- free_irq(*irqp, el2_probe_interrupt);
+ free_irq(*irqp, &seen);
if (!seen)
continue;
@@ -422,6 +422,7 @@ el2_open(struct net_device *dev)
continue;
if (retval < 0)
goto err_disable;
+ break;
} while (*++irqp);
if (*irqp == 0) {
--
Ondrej Zary
^ permalink raw reply
* 3.0-rc2: Reported regressions from 2.6.39
From: Rafael J. Wysocki @ 2011-06-12 20:23 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.39,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.39, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-06-12 8 7 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=37242
Subject : lockdep deadlock warning in shutdown
Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2011-06-03 3:24 (10 days old)
Message-ID : <1307071472.15392.60.camel@sli10-conroe>
References : http://marc.info/?l=linux-acpi&m=130707148811930&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=37232
Subject : [3.0-rc1][NMI/DMAR][iwlagn] errors - PCI system error (SERR) for reason a1 on CPU 0
Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org>
Date : 2011-06-03 4:56 (10 days old)
Message-ID : <4478124.OuFNgaPiHS-RRHT56Q3PSMGBMjmSbuoWl6hYfS7NtTn@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130707737616116&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=37222
Subject : 3.0.0-rc1-git3 -- kernel/sched.c:619 invoked rcu_dereference_check() without protection!
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-06-04 3:22 (9 days old)
Message-ID : <BANLkTikHS7TuFhm3cfJ+Y=erWDaAwuE_TA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130715775803343&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36982
Subject : 3.0-rc1 problem with usb, cdrom
Submitter : werner <w.landgraf-ow1r9FSYgO0@public.gmane.org>
Date : 2011-06-01 16:43 (12 days old)
Message-ID : <web-538043386-zcyLqNHFQq3Ee+7He9zlJw@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130694663410114&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36972
Subject : 3.0-rc1: DMAR errors from iwlagn
Submitter : Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Date : 2011-05-31 21:14 (13 days old)
Message-ID : <4DE55A26.6040702-TSDbQ3PG+2Y@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130687723213857&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36452
Subject : Artifacts with 3.0-rc1 on SandyBridge
Submitter : Alex Zhavnerchik <alex.vizor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-06-01 13:55 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36302
Subject : SandyBridge can't do s2disk with linux 3.0-rc1
Submitter : Alex Zhavnerchik <alex.vizor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-05-30 23:10 (14 days old)
Regressions with patches
------------------------
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.39,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=36912
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ 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