* Re: [PATCH 1/2] workqueue: Catch more locking problems with flush_work()
From: Tejun Heo @ 2012-04-19 15:28 UTC (permalink / raw)
To: Stephen Boyd; +Cc: linux-kernel, netdev, Ben Dooks
In-Reply-To: <1334805958-29119-1-git-send-email-sboyd@codeaurora.org>
On Wed, Apr 18, 2012 at 08:25:57PM -0700, Stephen Boyd wrote:
> @@ -2513,8 +2513,11 @@ bool flush_work(struct work_struct *work)
> wait_for_completion(&barr.done);
> destroy_work_on_stack(&barr.work);
> return true;
> - } else
> + } else {
> + lock_map_acquire(&work->lockdep_map);
> + lock_map_release(&work->lockdep_map);
> return false;
We don't have this annotation when start_flush_work() succeeds either,
right? IOW, would lockdep trigger when an actual deadlock happens?
If not, why not add the acquire/release() before flush_work() does
anything?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] net: filter: Just In Time compiler for sparc
From: Sam Ravnborg @ 2012-04-19 15:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sparclinux
In-Reply-To: <20120417.164400.89608576188768018.davem@davemloft.net>
>
> >> + select HAVE_BPF_JIT
> > If we sorted this block of select then the chances
> > for merge conflict would be smaller.
> > But this is not this patch to do so.
>
> I also think we should create an arch/sparc/Kbuild for sparc
> too, just like x86 has.
I will look into both issues.
But only after the merge window to avoid conflicts.
Sam
^ permalink raw reply
* Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support
From: Ben Hutchings @ 2012-04-19 15:30 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev, rayagond, davem
In-Reply-To: <4F900C08.5000906@st.com>
On Thu, 2012-04-19 at 14:58 +0200, Giuseppe CAVALLARO wrote:
> Hello Ben,
>
> On 4/16/2012 7:41 AM, Giuseppe CAVALLARO wrote:
> [snip]
> >> What I meant is that userland should be able to find out (a), and,
> >> *separately*, either (b) or (c). That is, there must be at least 2
> >> separate flags for this. In fact, I explicitly requested you define
> >> supported/advertising/lp_advertising bitmasks for EEE link modes just
> >> like we have for autonegotiation. But you've made no substantive
> >> changes in response to my review, aside from dropping the added field in
> >> ethtool_cmd.
> >
> > Sorry Ben but I believed that (c) was enough.
> >
> >> What you're submitting just isn't good enough for a generic interface,
> >> as the ethtool API is supposed to be. It's not even a good interface to
> >> your driver.
> >
> > yes! I'll rework this and provide new patches asap.
>
> sorry if I disturb you but I want to be sure to avoid to forget
> something else in the next EEE patches (avoiding to continuously disturb
> you).
>
> I'm changing the code for getting/setting the EEE capability and trying
> to follow your suggestions.
>
> The "get" will show the following things; this is a bit different of the
> points "a" "b" and "c" we had discussed. Maybe, this could also be a
> more complete (*) .
> The ethtool (see output below as example) could report the phy
> (supported/advertised/lp_advertised) and mac eee capabilities separately.
Sounds reasonable.
> The "set" will be useful for some eth devices (like the stmmac) that can
> stop/enable internally the eee capability (at mac level).
I don't know much about EEE, but shouldn't the driver take care of
configuring the MAC for this whenever the PHY is set to advertise EEE
capability?
> What do you think?
>
> Regards
> Peppe
>
> ----
>
> # ./ethtool eth0
> Settings for eth0:
>
> [snip]
>
> Current message level: 0x0000003f (63)
> drv probe link timer ifdown ifup
> Link detected: yes
> Energy-Efficient Ethernet: -------------------------
> MAC supports: yes |-> related to MAC side |
> phy supports modes: ... |-> from MMD 3.20 |
> phy advertising modes: ... |-> from MMD 7.60 |
> LP advertising modes: ... |-> from MMD 7.61 |
> --------------------------
> (*)
> PS. The "..." above means that we can actually dump: 100BASE-TX EEE etc
> for each advertising modes and also for phy support (reg 3.20).
Yes, that's the sort of information I would expect to see (but try to be
consistent with the wording used for AN).
The EEE advertising mask presumably should be changeable similarly to
the AN advertising mask ('ethtool -s <devname> eeeadv <mask>'). But I
don't know how the two advertising masks interact. Is one supposed to
be a subset of the other? Currently ethtool automatically changes the
AN advertising mask in response to a speed/duplex change; should it also
try to change the EEE advertising mask?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next 1/3] Add capability to retrieve plug-in module EEPROM
From: Stuart Hodgson @ 2012-04-19 15:39 UTC (permalink / raw)
To: netdev
Cc: Ben Hutchings, bruce.w.allan, decot, alexander.h.duyck, davem,
linux-kernel
We want to support reading module (SFP+, XFP, ...) EEPROMs as well as
NIC EEPROMs. They will need a different command number and driver
operation, but the structure and arguments will be the same and so we
can share most of the code here.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Stuart Hodgson <smhodgson@solarflare.com>
---
net/core/ethtool.c | 24 +++++++++++++++++-------
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index beacdd9..ca7698f 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -751,18 +751,17 @@ static int ethtool_get_link(struct net_device *dev, char __user *useraddr)
return 0;
}
-static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
+static int ethtool_get_any_eeprom(struct net_device *dev, void __user *useraddr,
+ int (*getter)(struct net_device *,
+ struct ethtool_eeprom *, u8 *),
+ u32 total_len)
{
struct ethtool_eeprom eeprom;
- const struct ethtool_ops *ops = dev->ethtool_ops;
void __user *userbuf = useraddr + sizeof(eeprom);
u32 bytes_remaining;
u8 *data;
int ret = 0;
- if (!ops->get_eeprom || !ops->get_eeprom_len)
- return -EOPNOTSUPP;
-
if (copy_from_user(&eeprom, useraddr, sizeof(eeprom)))
return -EFAULT;
@@ -771,7 +770,7 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
return -EINVAL;
/* Check for exceeding total eeprom len */
- if (eeprom.offset + eeprom.len > ops->get_eeprom_len(dev))
+ if (eeprom.offset + eeprom.len > total_len)
return -EINVAL;
data = kmalloc(PAGE_SIZE, GFP_USER);
@@ -782,7 +781,7 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
while (bytes_remaining > 0) {
eeprom.len = min(bytes_remaining, (u32)PAGE_SIZE);
- ret = ops->get_eeprom(dev, &eeprom, data);
+ ret = getter(dev, &eeprom, data);
if (ret)
break;
if (copy_to_user(userbuf, data, eeprom.len)) {
@@ -803,6 +802,17 @@ static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
return ret;
}
+static int ethtool_get_eeprom(struct net_device *dev, void __user *useraddr)
+{
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+
+ if (!ops->get_eeprom || !ops->get_eeprom_len)
+ return -EOPNOTSUPP;
+
+ return ethtool_get_any_eeprom(dev, useraddr, ops->get_eeprom,
+ ops->get_eeprom_len(dev));
+}
+
static int ethtool_set_eeprom(struct net_device *dev, void __user *useraddr)
{
struct ethtool_eeprom eeprom;
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 3/3] Add capability to retrieve plug-in module EEPROM
From: Stuart Hodgson @ 2012-04-19 15:39 UTC (permalink / raw)
To: netdev
Cc: Ben Hutchings, bruce.w.allan, decot, alexander.h.duyck, davem,
linux-kernel
Currently allows for SFP+ eeprom to be returned using the ethtool API.
This can be extended in future to handle different eeprom formats
and sizes
Signed-off-by: Stuart Hodgson <smhodgson@solarflare.com>
---
drivers/net/ethernet/sfc/ethtool.c | 35 ++++++++++
drivers/net/ethernet/sfc/mcdi_phy.c | 111 +++++++++++++++++++++++++++++++++
drivers/net/ethernet/sfc/net_driver.h | 5 ++
3 files changed, 151 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ethtool.c b/drivers/net/ethernet/sfc/ethtool.c
index f22f45f..60e718f 100644
--- a/drivers/net/ethernet/sfc/ethtool.c
+++ b/drivers/net/ethernet/sfc/ethtool.c
@@ -1108,6 +1108,39 @@ static int efx_ethtool_set_rxfh_indir(struct net_device *net_dev,
return 0;
}
+static int efx_ethtool_get_module_eeprom(struct net_device *net_dev,
+ struct ethtool_eeprom *ee,
+ u8 *data)
+{
+ struct efx_nic *efx = netdev_priv(net_dev);
+ int ret;
+
+ if (!efx->phy_op || !efx->phy_op->get_module_eeprom)
+ return -EOPNOTSUPP;
+
+ mutex_lock(&efx->mac_lock);
+ ret = efx->phy_op->get_module_eeprom(efx, ee, data);
+ mutex_unlock(&efx->mac_lock);
+
+ return ret;
+}
+
+static int efx_ethtool_get_module_info(struct net_device *net_dev,
+ struct ethtool_modinfo *modinfo)
+{
+ struct efx_nic *efx = netdev_priv(net_dev);
+ int ret;
+
+ if (!efx->phy_op || !efx->phy_op->get_module_info)
+ return 0;
+
+ mutex_lock(&efx->mac_lock);
+ ret = efx->phy_op->get_module_info(efx, modinfo);
+ mutex_unlock(&efx->mac_lock);
+
+ return ret;
+}
+
const struct ethtool_ops efx_ethtool_ops = {
.get_settings = efx_ethtool_get_settings,
.set_settings = efx_ethtool_set_settings,
@@ -1137,4 +1170,6 @@ const struct ethtool_ops efx_ethtool_ops = {
.get_rxfh_indir_size = efx_ethtool_get_rxfh_indir_size,
.get_rxfh_indir = efx_ethtool_get_rxfh_indir,
.set_rxfh_indir = efx_ethtool_set_rxfh_indir,
+ .get_module_info = efx_ethtool_get_module_info,
+ .get_module_eeprom = efx_ethtool_get_module_eeprom,
};
diff --git a/drivers/net/ethernet/sfc/mcdi_phy.c b/drivers/net/ethernet/sfc/mcdi_phy.c
index 7bcad89..4bac56c 100644
--- a/drivers/net/ethernet/sfc/mcdi_phy.c
+++ b/drivers/net/ethernet/sfc/mcdi_phy.c
@@ -304,6 +304,26 @@ static u32 mcdi_to_ethtool_media(u32 media)
}
}
+static u32 mcdi_to_module_eeprom_len(u32 media)
+{
+ switch (media) {
+ case MC_CMD_MEDIA_SFP_PLUS:
+ return ETH_MODULE_SFF_8079_LEN;
+ default:
+ return 0;
+ }
+}
+
+static u32 mcdi_to_module_eeprom_type(u32 media)
+{
+ switch (media) {
+ case MC_CMD_MEDIA_SFP_PLUS:
+ return ETH_MODULE_SFF_8079;
+ default:
+ return 0;
+ }
+}
+
static int efx_mcdi_phy_probe(struct efx_nic *efx)
{
struct efx_mcdi_phy_data *phy_data;
@@ -739,6 +759,95 @@ static const char *efx_mcdi_phy_test_name(struct efx_nic *efx,
return NULL;
}
+#define SFP_PAGE_SIZE 128
+#define SFP_NUM_PAGES 2
+static int efx_mcdi_phy_get_module_eeprom(struct efx_nic *efx,
+ struct ethtool_eeprom *ee, u8 *data)
+{
+ u8 outbuf[MC_CMD_GET_PHY_MEDIA_INFO_OUT_LENMAX];
+ u8 inbuf[MC_CMD_GET_PHY_MEDIA_INFO_IN_LEN];
+ size_t outlen;
+ int rc;
+ unsigned int payload_len;
+ unsigned int copied = 0;
+ unsigned int space_remaining = ee->len;
+ unsigned int page;
+ unsigned int page_off;
+ unsigned int to_copy;
+ u8 *user_data = data;
+
+ if (ee->offset > (SFP_PAGE_SIZE * SFP_NUM_PAGES))
+ return -EINVAL;
+
+ page_off = (ee->offset % SFP_PAGE_SIZE);
+ page = (ee->offset > SFP_PAGE_SIZE) ? 1 : 0;
+
+ while (space_remaining && (page < SFP_NUM_PAGES)) {
+
+ MCDI_SET_DWORD(inbuf, GET_PHY_MEDIA_INFO_IN_PAGE, page);
+
+ rc = efx_mcdi_rpc(efx, MC_CMD_GET_PHY_MEDIA_INFO,
+ inbuf, sizeof(inbuf),
+ outbuf, sizeof(outbuf),
+ &outlen);
+
+ if (rc)
+ return rc;
+
+ /* Copy as much as we can into data */
+ if (outlen < SFP_PAGE_SIZE ||
+ outlen < MC_CMD_GET_PHY_MEDIA_INFO_OUT_LENMIN ||
+ outlen > MC_CMD_GET_PHY_MEDIA_INFO_OUT_LENMAX)
+ return -EIO;
+
+ payload_len = MCDI_DWORD(outbuf,
+ GET_PHY_MEDIA_INFO_OUT_DATALEN);
+
+ payload_len -= page_off;
+ to_copy = (space_remaining < payload_len) ?
+ space_remaining : payload_len;
+
+ memcpy(user_data,
+ (outbuf + page_off +
+ MC_CMD_GET_PHY_MEDIA_INFO_OUT_DATA_OFST),
+ to_copy);
+
+ space_remaining -= to_copy;
+ user_data += to_copy;
+ copied += to_copy;
+ page_off = 0;
+ page++;
+ }
+
+ ee->len = copied;
+
+ return 0;
+}
+
+static int efx_mcdi_phy_get_module_info(struct efx_nic *efx,
+ struct ethtool_modinfo *modinfo)
+{
+ /* This will return a length of the eeprom
+ * type of the module that was detected during the probe,
+ * if not modules inserted then phy_data will be NULL */
+ struct efx_mcdi_phy_data *phy_cfg;
+
+ phy_cfg = efx->phy_data;
+ modinfo->eeprom_len = 0;
+ modinfo->type = 0;
+
+ switch (phy_cfg->media) {
+ case MC_CMD_MEDIA_SFP_PLUS:
+ modinfo->type = ETH_MODULE_SFF_8079;
+ modinfo->eeprom_len = ETH_MODULE_SFF_8079_LEN;
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
const struct efx_phy_operations efx_mcdi_phy_ops = {
.probe = efx_mcdi_phy_probe,
.init = efx_port_dummy_op_int,
@@ -751,4 +860,6 @@ const struct efx_phy_operations efx_mcdi_phy_ops = {
.test_alive = efx_mcdi_phy_test_alive,
.run_tests = efx_mcdi_phy_run_tests,
.test_name = efx_mcdi_phy_test_name,
+ .get_module_eeprom = efx_mcdi_phy_get_module_eeprom,
+ .get_module_info = efx_mcdi_phy_get_module_info,
};
diff --git a/drivers/net/ethernet/sfc/net_driver.h b/drivers/net/ethernet/sfc/net_driver.h
index f0385e1..0af8c47 100644
--- a/drivers/net/ethernet/sfc/net_driver.h
+++ b/drivers/net/ethernet/sfc/net_driver.h
@@ -522,6 +522,11 @@ struct efx_phy_operations {
int (*test_alive) (struct efx_nic *efx);
const char *(*test_name) (struct efx_nic *efx, unsigned int index);
int (*run_tests) (struct efx_nic *efx, int *results, unsigned flags);
+ int (*get_module_eeprom) (struct efx_nic *efx,
+ struct ethtool_eeprom *ee,
+ u8 *data);
+ int (*get_module_info) (struct efx_nic *efx,
+ struct ethtool_modinfo *modinfo);
};
/**
--
1.7.1
^ permalink raw reply related
* [PATCH net-next 2/3] Add capability to retrieve plug-in module EEPROM
From: Stuart Hodgson @ 2012-04-19 15:39 UTC (permalink / raw)
To: netdev
Cc: Ben Hutchings, bruce.w.allan, decot, alexander.h.duyck, davem,
linux-kernel
Provides a new struct ethtool_modinfo that will return the
type and size of plug-in module eeprom (such as SFP+) for parsing
by userland program.
The second provides the API to get the raw eeprom information
using the existing ethtool_eeprom structture to return the data
Signed-off-by: Stuart Hodgson <smhodgson@solarflare.com>
---
include/linux/ethtool.h | 33 +++++++++++++++++++++++++++++++++
net/core/ethtool.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 89d68d8..f6500f3 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -137,6 +137,23 @@ struct ethtool_eeprom {
};
/**
+ * struct ethtool_modinfo - plugin module eeprom information
+ * @cmd: ETHTOOL_GMODULEINFO
+ * @type: Standard the module information conforms to SFF_xxxx
+ * @eeprom_len: Length of the eeprom
+ *
+ * This structure is used to return the information to
+ * properly size memory for a subsequent call to ETHTOOL_GMODULEEEPROM
+ *
+ */
+struct ethtool_modinfo {
+ __u32 cmd;
+ __u32 type;
+ __u32 eeprom_len;
+ __u32 reserved[8];
+};
+
+/**
* struct ethtool_coalesce - coalescing parameters for IRQs and stats updates
* @cmd: ETHTOOL_{G,S}COALESCE
* @rx_coalesce_usecs: How many usecs to delay an RX interrupt after
@@ -920,6 +937,9 @@ static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
* @get_ts_info: Get the time stamping and PTP hardware clock capabilities.
* Drivers supporting transmit time stamps in software should set this to
* ethtool_op_get_ts_info().
+ * @get_module_info: Get the size and type of the eeprom contained within
+ * a plug-in module.
+ * @get_module_eeprom: Get the eeprom information from the plug-in module
*
* All operations are optional (i.e. the function pointer may be set
* to %NULL) and callers must take this into account. Callers must
@@ -982,6 +1002,11 @@ struct ethtool_ops {
struct ethtool_dump *, void *);
int (*set_dump)(struct net_device *, struct ethtool_dump *);
int (*get_ts_info)(struct net_device *, struct ethtool_ts_info *);
+ int (*get_module_info)(struct net_device *,
+ struct ethtool_modinfo *);
+ int (*get_module_eeprom)(struct net_device *,
+ struct ethtool_eeprom *, u8 *);
+
};
#endif /* __KERNEL__ */
@@ -1057,6 +1082,8 @@ struct ethtool_ops {
#define ETHTOOL_GET_DUMP_FLAG 0x0000003f /* Get dump settings */
#define ETHTOOL_GET_DUMP_DATA 0x00000040 /* Get dump data */
#define ETHTOOL_GET_TS_INFO 0x00000041 /* Get time stamping and PHC info */
+#define ETHTOOL_GMODULEINFO 0x00000042 /* Get plug-in module information */
+#define ETHTOOL_GMODULEEEPROM 0x00000043 /* Get plug-in module eeprom */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
@@ -1206,6 +1233,12 @@ struct ethtool_ops {
#define RX_CLS_LOC_FIRST 0xfffffffe
#define RX_CLS_LOC_LAST 0xfffffffd
+/* EEPROM Standards for plug in modules */
+#define ETH_MODULE_SFF_8079 0x1
+#define ETH_MODULE_SFF_8079_LEN 256
+#define ETH_MODULE_SFF_8472 0x2
+#define ETH_MODULE_SFF_8472_LEN 512
+
/* Reset flags */
/* The reset() operation must clear the flags for the components which
* were actually reset. On successful return, the flags indicate the
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index ca7698f..9c2afb4 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1335,6 +1335,47 @@ static int ethtool_get_ts_info(struct net_device *dev, void __user *useraddr)
return err;
}
+static int ethtool_get_module_info(struct net_device *dev,
+ void __user *useraddr)
+{
+ int ret;
+ struct ethtool_modinfo modinfo;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+
+ if (!ops->get_module_info)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&modinfo, useraddr, sizeof(modinfo)))
+ return -EFAULT;
+
+ ret = ops->get_module_info(dev, &modinfo);
+ if (ret)
+ return ret;
+
+ if (copy_to_user(useraddr, &modinfo, sizeof(modinfo)))
+ return -EFAULT;
+
+ return 0;
+}
+
+static int ethtool_get_module_eeprom(struct net_device *dev,
+ void __user *useraddr)
+{
+ int ret;
+ struct ethtool_modinfo modinfo;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+
+ if (!ops->get_module_info || !ops->get_module_eeprom)
+ return -EOPNOTSUPP;
+
+ ret = ops->get_module_info(dev, &modinfo);
+ if (ret)
+ return ret;
+
+ return ethtool_get_any_eeprom(dev, useraddr, ops->get_module_eeprom,
+ modinfo.eeprom_len);
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1559,6 +1600,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_GET_TS_INFO:
rc = ethtool_get_ts_info(dev, useraddr);
break;
+ case ETHTOOL_GMODULEINFO:
+ rc = ethtool_get_module_info(dev, useraddr);
+ break;
+ case ETHTOOL_GMODULEEEPROM:
+ rc = ethtool_get_module_eeprom(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.1
^ permalink raw reply related
* Awesomeness delivered ;)
From: Shannon @ 2012-04-19 14:58 UTC (permalink / raw)
To: netdev
This 4 Video "Business Accellerator" Action Plan
was put together by one of
all time greats in direct sales for his team
and word got out and now it's going viral
Here's a "backstage pass" to get in and watch
the videos while they are still open and fr.ee
http://www.BoldStatementMarketing.com/backstage
I guarantee you'll be blown away. You'll see
immediate results using the step-by-step plan
detailed in each video.
Some folks are reporting sales increases of 200%
or more!
Watch them while they are still fr.ee:
http://www.BoldStatementMarketing.com/backstage
All the best,
Shannon
PS: I don't know how long they'll keep this open for
fr.ee with all the traffic that's pounding the site. Hopefully
it's still open when you get there...
http://www.BoldStatementMarketing.com/backstage
^ permalink raw reply
* [PATCH net-next] ipv4: dont drop packet in defrag but consume it
From: Eric Dumazet @ 2012-04-19 16:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
When defragmentation is finalized, we clone a packet and kfree_skb() it.
Call consume_skb() to not confuse dropwatch, since its not a drop.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ip_fragment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 3727e23..631f596 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -569,7 +569,7 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
skb_morph(head, qp->q.fragments);
head->next = qp->q.fragments->next;
- kfree_skb(qp->q.fragments);
+ consume_skb(qp->q.fragments);
qp->q.fragments = head;
}
^ permalink raw reply related
* Re: [PATCH] NET: bcm63xx_enet: move phy_(dis)connect into probe/remove
From: Maxime Bizon @ 2012-04-19 16:17 UTC (permalink / raw)
To: Jonas Gorski; +Cc: netdev, Florian Fainelli, Eric Dumazet, David S. Miller
In-Reply-To: <CAOiHx==f0czkaEVTe=+wabQMmifdaN00PMQwaR8f-602Dq56pA@mail.gmail.com>
On Thu, 2012-04-19 at 16:52 +0200, Jonas Gorski wrote:
> Yes, but none of the ethtool functions cause register writes in the
> priv->has_phy = true case when in PHY_READY or PHY_HALTED state. All
> they do is modify the phy_device's settings.
unless I'm mistaken:
phy_ethtool_sset() => phy_start_aneg()
will kick the state machine even when state is PHY_READY
--
Maxime
^ permalink raw reply
* [PATCH] Fix request_irq/free_irq mismatch
From: mjr @ 2012-04-19 16:46 UTC (permalink / raw)
To: sboyd; +Cc: ben, netdev, Matt Renzelmann
From: Matt Renzelmann <mjr@cs.wisc.edu>
The dev_id parameter passed to free_irq needs to match the one passed
to the corresponding request_irq.
Signed-off-by: Matt Renzelmann <mjr@cs.wisc.edu>
---
drivers/net/ethernet/micrel/ks8851.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c
index e5dc075..a8b7d5b 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -1524,7 +1524,7 @@ static int __devinit ks8851_probe(struct spi_device *spi)
err_netdev:
- free_irq(ndev->irq, ndev);
+ free_irq(ndev->irq, ks);
err_id:
err_irq:
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: gro: GRO_MERGED_FREE consumes packets
From: Eric Dumazet @ 2012-04-19 17:07 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
As part of GRO processing, merged skbs should be consumed, not freed, to
not confuse dropwatch/drop_monitor.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index c938127..501f3cc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3542,10 +3542,13 @@ gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
break;
case GRO_DROP:
- case GRO_MERGED_FREE:
kfree_skb(skb);
break;
+ case GRO_MERGED_FREE:
+ consume_skb(skb);
+ break;
+
case GRO_HELD:
case GRO_MERGED:
break;
^ permalink raw reply related
* [PATCH] drop_monitor: allow more events per second
From: Eric Dumazet @ 2012-04-19 17:16 UTC (permalink / raw)
To: Neil Horman, David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
It seems there is a logic error in trace_drop_common(), since we store
only 64 drops, even if they are from same location.
This fix is a one liner, but we probably need more work to avoid useless
atomic dec/inc
Now I can watch 1 Mpps drops through dropwatch...
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
---
Neil, it seems this code is not SMP/preempt safe. Worker can free our
data under us, and genlmsg_new() can return NULL under stress.
net/core/drop_monitor.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
index 7f36b38..5c3c81a 100644
--- a/net/core/drop_monitor.c
+++ b/net/core/drop_monitor.c
@@ -150,6 +150,7 @@ static void trace_drop_common(struct sk_buff *skb, void *location)
for (i = 0; i < msg->entries; i++) {
if (!memcmp(&location, msg->points[i].pc, sizeof(void *))) {
msg->points[i].count++;
+ atomic_inc(&data->dm_hit_count);
goto out;
}
}
^ permalink raw reply related
* [PATCH] ks8851: Fix request_irq/free_irq mismatch
From: mjr @ 2012-04-19 17:17 UTC (permalink / raw)
To: sboyd; +Cc: ben, netdev, Matt Renzelmann
From: Matt Renzelmann <mjr@cs.wisc.edu>
The dev_id parameter passed to free_irq needs to match the one passed
to the corresponding request_irq.
Signed-off-by: Matt Renzelmann <mjr@cs.wisc.edu>
---
Resending -- forgot driver name in the title. Sorry about that.
drivers/net/ethernet/micrel/ks8851.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c
index e5dc075..a8b7d5b 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -1524,7 +1524,7 @@ static int __devinit ks8851_probe(struct spi_device *spi)
err_netdev:
- free_irq(ndev->irq, ndev);
+ free_irq(ndev->irq, ks);
err_id:
err_irq:
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v2 net-next] tcp: avoid expensive pskb_expand_head() calls
From: Eric Dumazet @ 2012-04-19 17:25 UTC (permalink / raw)
To: Rick Jones
Cc: Ilpo Järvinen, Neal Cardwell, David Miller, netdev,
Tom Herbert, Maciej Żenczykowski, Yuchung Cheng
In-Reply-To: <4F904955.7070403@hp.com>
On Thu, 2012-04-19 at 10:20 -0700, Rick Jones wrote:
> By copying them to smaller buffers? Or just by altering truesize?
> Wasn't the whole point of fixing all the broken truesize settings to
> accurately account for memory consumed?
I checked, their truesize are OK (1024+256) for ixgbe driver.
They could be little smaller, but not that much. (512 + 256)
No, its only the sk_rcvbuf is small for a tcp sender,
and sk_add_backlog() makes sure we dont queue more than sk_rcvbuf bytes
in backlog.
^ permalink raw reply
* Re: [patch] ksz884x: don't copy too much in netdev_set_mac_address()
From: David Miller @ 2012-04-19 17:25 UTC (permalink / raw)
To: dan.carpenter; +Cc: Tristram.Ha, bhutchings, netdev
In-Reply-To: <20120419070018.GA16645@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 19 Apr 2012 10:00:19 +0300
> MAX_ADDR_LEN is 32. ETH_ALEN is 6. mac->sa_data is a 14 byte array, so
> the memcpy() is doing a read past the end of the array. I asked about
> this on netdev and Ben Hutchings told me it's supposed to be copying
> ETH_ALEN bytes (thanks Ben).
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH] drop_monitor: allow more events per second
From: Neil Horman @ 2012-04-19 17:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1334855781.2395.203.camel@edumazet-glaptop>
On Thu, Apr 19, 2012 at 07:16:21PM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> It seems there is a logic error in trace_drop_common(), since we store
> only 64 drops, even if they are from same location.
>
> This fix is a one liner, but we probably need more work to avoid useless
> atomic dec/inc
>
> Now I can watch 1 Mpps drops through dropwatch...
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> ---
> Neil, it seems this code is not SMP/preempt safe. Worker can free our
> data under us, and genlmsg_new() can return NULL under stress.
>
> net/core/drop_monitor.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/drop_monitor.c b/net/core/drop_monitor.c
> index 7f36b38..5c3c81a 100644
> --- a/net/core/drop_monitor.c
> +++ b/net/core/drop_monitor.c
> @@ -150,6 +150,7 @@ static void trace_drop_common(struct sk_buff *skb, void *location)
> for (i = 0; i < msg->entries; i++) {
> if (!memcmp(&location, msg->points[i].pc, sizeof(void *))) {
> msg->points[i].count++;
> + atomic_inc(&data->dm_hit_count);
> goto out;
> }
> }
>
>
>
I spent a good deal of time going through it to make sure it was preempt safe,
but its certainly possible that I missed something. I'll look at it shortly.
Thanks for this update though
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid expensive pskb_expand_head() calls
From: Rick Jones @ 2012-04-19 17:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ilpo Järvinen, Neal Cardwell, David Miller, netdev,
Tom Herbert, Maciej Żenczykowski, Yuchung Cheng
In-Reply-To: <1334844652.2395.187.camel@edumazet-glaptop>
On 04/19/2012 07:10 AM, Eric Dumazet wrote:
> On Thu, 2012-04-19 at 15:52 +0200, Eric Dumazet wrote:
>
>> And disabling GRO on receiver definitely demonstrates the problem, even
>> with a single flow. (and performance drops from 9410 Mbit to 6050 Mbit)
>
> That insane.
>
> Performance drops so much because we _drop_ incoming ACKS :
>
> < TCPSackShifted: 39117
> < TCPSackMerged: 16500
> < TCPSackShiftFallback: 5092
> < TCPBacklogDrop: 27965
> ---
>> TCPSackShifted: 35122
>> TCPSackMerged: 16368
>> TCPSackShiftFallback: 4889
>> TCPBacklogDrop: 23247
>
> Hmm, maybe we should reduce skb->truesize for small packets before
> queueing them in socket backlog...
By copying them to smaller buffers? Or just by altering truesize?
Wasn't the whole point of fixing all the broken truesize settings to
accurately account for memory consumed?
rick
^ permalink raw reply
* Re: [PATCH] net: filter: Just In Time compiler for sparc
From: David Miller @ 2012-04-19 17:47 UTC (permalink / raw)
To: sam; +Cc: netdev, sparclinux
In-Reply-To: <20120419152937.GA1120@merkur.ravnborg.org>
From: Sam Ravnborg <sam@ravnborg.org>
Date: Thu, 19 Apr 2012 17:29:37 +0200
>>
>> >> + select HAVE_BPF_JIT
>> > If we sorted this block of select then the chances
>> > for merge conflict would be smaller.
>> > But this is not this patch to do so.
>>
>> I also think we should create an arch/sparc/Kbuild for sparc
>> too, just like x86 has.
>
> I will look into both issues.
> But only after the merge window to avoid conflicts.
Thanks a lot Sam.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid expensive pskb_expand_head() calls
From: Rick Jones @ 2012-04-19 17:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ilpo Järvinen, Neal Cardwell, David Miller, netdev,
Tom Herbert, Maciej Żenczykowski, Yuchung Cheng
In-Reply-To: <1334856306.2395.208.camel@edumazet-glaptop>
On 04/19/2012 10:25 AM, Eric Dumazet wrote:
> On Thu, 2012-04-19 at 10:20 -0700, Rick Jones wrote:
>
>> By copying them to smaller buffers? Or just by altering truesize?
>> Wasn't the whole point of fixing all the broken truesize settings to
>> accurately account for memory consumed?
>
> I checked, their truesize are OK (1024+256) for ixgbe driver.
> They could be little smaller, but not that much. (512 + 256)
>
> No, its only the sk_rcvbuf is small for a tcp sender,
> and sk_add_backlog() makes sure we dont queue more than sk_rcvbuf
> bytes in backlog.
Sounds like a variation on the theme of wildly divergent
inbound/outbound bandwidth and constraining ACKs constraining throughput
- only with buffer sizes.
87380 is the default SO_RCVBUF right? That should have allowed
87380/1280 or 68 ACKs to be queued. Without ACK stretching from GRO
that should have covered 68 * 2896 or 196928 bytes. Based on your
previous 54 usec to transmit 64 KB that would be 162+ usecs to
accumulate those ACKs, so I guess a question becomes if TCP can be
held-off processing ACKs for > 162 usecs, and if so and that cannot be
changed, the autotuning will have to start increasing SO_SNDBUF
alongside so_sndbuf even if the endpoint is not receiving. As a
handwave, since TCP does not know the buffer size(s) used by the driver,
by 1 MSS for every 2 MSS it adds to SO_SNDBUF. Or find some way to do
it "on demand" in the about to drop path.
That or bare ACKs have to be excluded from the overhead checks somehow I
guess, or there be more aggressive copying into smaller buffers.
Thankfully, when applications make explicit setsockopt() calls, they
tend (ok, perhaps that is a bit of a guess) to set both SO_SNDBUF and
SO_RCVBUF at the same time.
rick
^ permalink raw reply
* RE: rx_dropped packets stop with tcpdump running
From: Dave, Tushar N @ 2012-04-19 17:57 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <1334842088.2395.178.camel@edumazet-glaptop>
Marco,
Do you see any packet drop at HW level?
How are you measuring drop packet? ethtool -S ethx shows you any packet drop?
Also can you please send me the eeprom dump of you card/LOM. ethtool -e ethx
-Tushar
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Eric Dumazet
>Sent: Thursday, April 19, 2012 6:28 AM
>To: Marco Berizzi
>Cc: netdev@vger.kernel.org
>Subject: Re: rx_dropped packets stop with tcpdump running
>
>On Thu, 2012-04-19 at 15:24 +0200, Eric Dumazet wrote:
>
>> When linux receives a packet with no protocol handler, we increment
>> the rx_dropped counter.
>>
>> When you start a tcpdump, all packets are handled, so we dont
>> increment rx_dropped for this reason anymore.
>>
>>
>
>Its done since 2.6.37 (commit caf586e5)
>
>
>
>
>--
>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
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid expensive pskb_expand_head() calls
From: Eric Dumazet @ 2012-04-19 18:00 UTC (permalink / raw)
To: Rick Jones
Cc: Ilpo Järvinen, Neal Cardwell, David Miller, netdev,
Tom Herbert, Maciej Żenczykowski, Yuchung Cheng
In-Reply-To: <4F904FFE.60703@hp.com>
On Thu, 2012-04-19 at 10:48 -0700, Rick Jones wrote:
> On 04/19/2012 10:25 AM, Eric Dumazet wrote:
> > On Thu, 2012-04-19 at 10:20 -0700, Rick Jones wrote:
> >
> >> By copying them to smaller buffers? Or just by altering truesize?
> >> Wasn't the whole point of fixing all the broken truesize settings to
> >> accurately account for memory consumed?
> >
> > I checked, their truesize are OK (1024+256) for ixgbe driver.
> > They could be little smaller, but not that much. (512 + 256)
> >
> > No, its only the sk_rcvbuf is small for a tcp sender,
> > and sk_add_backlog() makes sure we dont queue more than sk_rcvbuf
> > bytes in backlog.
>
> Sounds like a variation on the theme of wildly divergent
> inbound/outbound bandwidth and constraining ACKs constraining throughput
> - only with buffer sizes.
>
> 87380 is the default SO_RCVBUF right? That should have allowed
> 87380/1280 or 68 ACKs to be queued. Without ACK stretching from GRO
> that should have covered 68 * 2896 or 196928 bytes. Based on your
> previous 54 usec to transmit 64 KB that would be 162+ usecs to
> accumulate those ACKs, so I guess a question becomes if TCP can be
> held-off processing ACKs for > 162 usecs, and if so and that cannot be
> changed, the autotuning will have to start increasing SO_SNDBUF
> alongside so_sndbuf even if the endpoint is not receiving. As a
> handwave, since TCP does not know the buffer size(s) used by the driver,
> by 1 MSS for every 2 MSS it adds to SO_SNDBUF. Or find some way to do
> it "on demand" in the about to drop path.
>
> That or bare ACKs have to be excluded from the overhead checks somehow I
> guess, or there be more aggressive copying into smaller buffers.
>
Nope, we need a limit or risk OOM if a malicious peer send ACK flood ;)
To be clear, if I change the tcp_rmem[1] from 87380 to big value, I no
longer have ACK drops, but still poor performance, I am still
investigating.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid expensive pskb_expand_head() calls
From: Rick Jones @ 2012-04-19 18:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ilpo Järvinen, Neal Cardwell, David Miller, netdev,
Tom Herbert, Maciej Żenczykowski, Yuchung Cheng
In-Reply-To: <1334858436.2395.212.camel@edumazet-glaptop>
>> That or bare ACKs have to be excluded from the overhead checks somehow I
>> guess, or there be more aggressive copying into smaller buffers.
>>
>
> Nope, we need a limit or risk OOM if a malicious peer send ACK flood ;)
Well, there is that...
>
> To be clear, if I change the tcp_rmem[1] from 87380 to big value, I no
> longer have ACK drops, but still poor performance, I am still
> investigating.
What happens if you set net.core.[rw]mem_max to 4 MB and then use
something like -s 1M -S 1M in netperf?
netperf -t TCP_STREAM -H <remote> -- -s 1M -S 1M -m 64K
(or -m 16K if you want to keep the send size the same as your previous
tests...)
rick
^ permalink raw reply
* Re: [PATCH 1/2] workqueue: Catch more locking problems with flush_work()
From: Stephen Boyd @ 2012-04-19 18:10 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel, netdev, Ben Dooks
In-Reply-To: <20120419152841.GA10553@google.com>
On 04/19/12 08:28, Tejun Heo wrote:
> On Wed, Apr 18, 2012 at 08:25:57PM -0700, Stephen Boyd wrote:
>> @@ -2513,8 +2513,11 @@ bool flush_work(struct work_struct *work)
>> wait_for_completion(&barr.done);
>> destroy_work_on_stack(&barr.work);
>> return true;
>> - } else
>> + } else {
>> + lock_map_acquire(&work->lockdep_map);
>> + lock_map_release(&work->lockdep_map);
>> return false;
> We don't have this annotation when start_flush_work() succeeds either,
> right? IOW, would lockdep trigger when an actual deadlock happens?
I believe it does although I haven't tested it.
> If not, why not add the acquire/release() before flush_work() does
> anything?
>
I was worried about causing false positive lockdep warnings in the case
that start_flush_work() succeeds and returns true. In that case, lockdep
is told about the cwq lockdep map:
static bool start_flush_work(struct work_struct *work, struct wq_barrier *barr,
bool wait_executing)
{
.....
if (cwq->wq->saved_max_active == 1 || cwq->wq->flags & WQ_RESCUER)
lock_map_acquire(&cwq->wq->lockdep_map);
else
lock_map_acquire_read(&cwq->wq->lockdep_map);
and so if we acquired the work->lockdep_map before the
cwq->wq->lockdep_map we would get a warning about ABBA between these two
lockdep maps. At least that is what I'm lead to believe when I look at
what process_one_work() is doing. Please correct me if I'm wrong.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] ks8851: Fix request_irq/free_irq mismatch
From: Stephen Boyd @ 2012-04-19 18:13 UTC (permalink / raw)
To: mjr; +Cc: ben, netdev
In-Reply-To: <1334855837-28366-1-git-send-email-mjr@cs.wisc.edu>
On 04/19/12 10:17, mjr@cs.wisc.edu wrote:
> From: Matt Renzelmann <mjr@cs.wisc.edu>
>
> The dev_id parameter passed to free_irq needs to match the one passed
> to the corresponding request_irq.
>
> Signed-off-by: Matt Renzelmann <mjr@cs.wisc.edu>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH net-next] netfilter: nf_conntrack.h: use this_cpu_inc()
From: Pablo Neira Ayuso @ 2012-04-19 18:16 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, Christoph Lameter, Tejun Heo,
Patrick McHardy, Netfilter Development Mailing list
In-Reply-To: <1334723800.2472.88.camel@edumazet-glaptop>
On Wed, Apr 18, 2012 at 06:36:40AM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> this_cpu_inc() is IRQ safe and faster than
> local_bh_disable()/__this_cpu_inc()/local_bh_enable(), at least on x86.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Christoph Lameter <cl@linux.com>
> Cc: Tejun Heo <tj@kernel.org>
Applied, 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