* [PATCH net-next 8/9] cxgb4: add new PCI IDs
From: Dimitris Michailidis @ 2010-08-02 23:19 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1280791164-14181-8-git-send-email-dm@chelsio.com>
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4_main.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index 5d5ea82..a4c4f52 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -175,6 +175,16 @@ enum {
static DEFINE_PCI_DEVICE_TABLE(cxgb4_pci_tbl) = {
CH_DEVICE(0xa000, 0), /* PE10K */
+ CH_DEVICE(0x4001, 0),
+ CH_DEVICE(0x4002, 0),
+ CH_DEVICE(0x4003, 0),
+ CH_DEVICE(0x4004, 0),
+ CH_DEVICE(0x4005, 0),
+ CH_DEVICE(0x4006, 0),
+ CH_DEVICE(0x4007, 0),
+ CH_DEVICE(0x4008, 0),
+ CH_DEVICE(0x4009, 0),
+ CH_DEVICE(0x400a, 0),
{ 0, }
};
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 9/9] cxgb4: update driver version
From: Dimitris Michailidis @ 2010-08-02 23:19 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1280791164-14181-9-git-send-email-dm@chelsio.com>
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/cxgb4_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
index a4c4f52..c327527 100644
--- a/drivers/net/cxgb4/cxgb4_main.c
+++ b/drivers/net/cxgb4/cxgb4_main.c
@@ -67,7 +67,7 @@
#include "t4fw_api.h"
#include "l2t.h"
-#define DRV_VERSION "1.0.0-ko"
+#define DRV_VERSION "1.3.0-ko"
#define DRV_DESC "Chelsio T4 Network Driver"
/*
--
1.5.4
^ permalink raw reply related
* [PATCH net-next 7/9] cxgb4: fix wrong shift direction
From: Dimitris Michailidis @ 2010-08-02 23:19 UTC (permalink / raw)
To: netdev; +Cc: Dimitris Michailidis
In-Reply-To: <1280791164-14181-7-git-send-email-dm@chelsio.com>
Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
---
drivers/net/cxgb4/t4_hw.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cxgb4/t4_hw.h b/drivers/net/cxgb4/t4_hw.h
index e875d09..10a0555 100644
--- a/drivers/net/cxgb4/t4_hw.h
+++ b/drivers/net/cxgb4/t4_hw.h
@@ -135,5 +135,5 @@ struct rsp_ctrl {
#define QINTR_CNT_EN 0x1
#define QINTR_TIMER_IDX(x) ((x) << 1)
-#define QINTR_TIMER_IDX_GET(x) (((x) << 1) & 0x7)
+#define QINTR_TIMER_IDX_GET(x) (((x) >> 1) & 0x7)
#endif /* __T4_HW_H */
--
1.5.4
^ permalink raw reply related
* Re: [PATCH 1/4] net: check for reference outside of skb
From: Stephen Hemminger @ 2010-08-02 23:21 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, netdev
In-Reply-To: <AANLkTi=8+xRJn_26740uKuWdgA=XvyB7-hgGT9dxjOXr@mail.gmail.com>
On Tue, 3 Aug 2010 07:11:14 +0800
Changli Gao <xiaosuo@gmail.com> wrote:
> On Tue, Aug 3, 2010 at 6:00 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> > It is legitimate for callers of skb_header_pointer to pass a negative
> > offset, but the resulting pointer should not go outside the valid
> > range of data in the skb.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > --- a/include/linux/skbuff.h 2010-08-01 09:23:01.635121262 -0700
> > +++ b/include/linux/skbuff.h 2010-08-01 09:25:27.453901530 -0700
> > @@ -1853,6 +1853,9 @@ static inline void *skb_header_pointer(c
> > {
> > int hlen = skb_headlen(skb);
> >
> > + if (hlen + offset < 0)
> > + return NULL;
> > +
>
> It seems wrong. do you mean
>
> if (skb_headroom(hlen) + offset < 0)
>
> Nevertheless it is also wrong. skb_header_pointer doesn't know if the
> headroom is filled with valid data or not.
>
It should be headroom. It is okay if the request is looking at PAD
area, that is the callers problem. Just don't want wander off into
into unallocated space.
Anyway, I'll fix it in cls_u32.
^ permalink raw reply
* LOAN OFFER
From: P.M.L @ 2010-08-02 23:21 UTC (permalink / raw)
To: pmlender.com
We offer loan at cheap rate, they say opprtunity does not knock twice.But with our loan firm, you can get the cheapest loan at a low
percentage rate of 2% yearly from $5,000.00 Min. To $10 000 000.00 Max.Contact us via email if you are interested with the following details
NAME:
PHONE:
LOAN DURATION:
ADDRESS:
AMOUNT:
Private Fund Loan Inc
Mrs.Hannah Stone
^ permalink raw reply
* Re: [PATCH 1/4] net: check for reference outside of skb
From: Changli Gao @ 2010-08-02 23:25 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20100802162158.0b0c6e70@nehalam>
On Tue, Aug 3, 2010 at 7:21 AM, Stephen Hemminger <shemminger@vyatta.com> wrote:
>
> It should be headroom. It is okay if the request is looking at PAD
> area, that is the callers problem. Just don't want wander off into
> into unallocated space.
>
> Anyway, I'll fix it in cls_u32.
>
FYI: act_pedit may have the same issue. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH net-next 0/9] cxgb4 updates
From: David Miller @ 2010-08-02 23:27 UTC (permalink / raw)
To: dm; +Cc: netdev
In-Reply-To: <1280791164-14181-1-git-send-email-dm@chelsio.com>
From: Dimitris Michailidis <dm@chelsio.com>
Date: Mon, 2 Aug 2010 16:19:15 -0700
>
> Following are 9 patches for cxgb4. A few small fixes, new PCI ids, and a
> couple features.
All applied, thanks.
^ permalink raw reply
* [PATCH] u32: negative offset fix
From: Stephen Hemminger @ 2010-08-02 23:44 UTC (permalink / raw)
To: David Miller, Changli Gao; +Cc: netdev
In-Reply-To: <20100802220030.991706005@vyatta.com>
It was possible to use a negative offset in a u32 match to reference
the ethernet header or other parts of the link layer header.
This fixes the regression caused by:
commit fbc2e7d9cf49e0bf89b9e91fd60a06851a855c5d
Author: Changli Gao <xiaosuo@gmail.com>
Date: Wed Jun 2 07:32:42 2010 -0700
cls_u32: use skb_header_pointer() to dereference data safely
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Combines change to signed type and check in one patch.
--- a/net/sched/cls_u32.c 2010-08-02 15:02:36.778304996 -0700
+++ b/net/sched/cls_u32.c 2010-08-02 16:25:40.661661091 -0700
@@ -134,10 +134,12 @@ next_knode:
#endif
for (i = n->sel.nkeys; i>0; i--, key++) {
- unsigned int toff;
+ int toff = off + key->off + (off2 & key->offmask);
__be32 *data, _data;
+
+ if (skb_headroom(skb) + toff < 0)
+ goto out;
- toff = off + key->off + (off2 & key->offmask);
data = skb_header_pointer(skb, toff, 4, &_data);
if (!data)
goto out;
^ permalink raw reply
* [PATCH]hostap:hostap_ioctl.c Fix variable 'ret' set but not used
From: Justin P. Mattock @ 2010-08-03 0:04 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel, j, linville, Justin P. Mattock
The below patch fixes a warning message generated by GCC:
CC [M] drivers/net/wireless/hostap/hostap_ioctl.o
drivers/net/wireless/hostap/hostap_ioctl.c: In function 'prism2_request_scan':
drivers/net/wireless/hostap/hostap_ioctl.c:1666:6: warning: variable 'ret' set but not used
Keep in mind Im not sure if this is the right fix for this, so please
feedback is appreciated.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/hostap/hostap_ioctl.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
index a85e43a..27d462f 100644
--- a/drivers/net/wireless/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -1663,7 +1663,6 @@ static int prism2_request_scan(struct net_device *dev)
struct hostap_interface *iface;
local_info_t *local;
struct hfa384x_scan_request scan_req;
- int ret = 0;
iface = netdev_priv(dev);
local = iface->local;
@@ -1689,7 +1688,7 @@ static int prism2_request_scan(struct net_device *dev)
if (local->func->set_rid(dev, HFA384X_RID_SCANREQUEST, &scan_req,
sizeof(scan_req))) {
printk(KERN_DEBUG "SCANREQUEST failed\n");
- ret = -EINVAL;
+ return -EINVAL;
}
if (!local->host_roaming)
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH]hostap:hostap_ioctl.c Fix variable 'hostscan' set but not used
From: Justin P. Mattock @ 2010-08-03 0:04 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel, j, linville, Justin P. Mattock
The patch below fixes a compiler warning:
CC [M] drivers/net/wireless/hostap/hostap_ioctl.o
drivers/net/wireless/hostap/hostap_ioctl.c: In function 'prism2_translate_scan':
drivers/net/wireless/hostap/hostap_ioctl.c:1954:13: warning: variable 'hostscan' set but not used
Keep in mind I've looked and searched for a fix for this but
couldnt come up with anything.(if there is let me know and I'll have a try at it).
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/hostap/hostap_ioctl.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
index 27d462f..25420e3 100644
--- a/drivers/net/wireless/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -1951,7 +1951,7 @@ static inline int prism2_translate_scan(local_info_t *local,
char *buffer, int buflen)
{
struct hfa384x_hostscan_result *scan;
- int entry, hostscan;
+ int entry;
char *current_ev = buffer;
char *end_buf = buffer + buflen;
struct list_head *ptr;
@@ -1964,7 +1964,6 @@ static inline int prism2_translate_scan(local_info_t *local,
bss->included = 0;
}
- hostscan = local->last_scan_type == PRISM2_HOSTSCAN;
for (entry = 0; entry < local->last_scan_results_count; entry++) {
int found = 0;
scan = &local->last_scan_results[entry];
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* [PATCH]hostap:hostap_hw.c Fix variable 'fc' set but not used
From: Justin P. Mattock @ 2010-08-03 0:05 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel, j, linville, Justin P. Mattock
The below fixes a build wanring from GCC.
CC [M] drivers/net/wireless/hostap/hostap_plx.o
In file included from drivers/net/wireless/hostap/hostap_plx.c:264:0:
drivers/net/wireless/hostap/hostap_hw.c: In function 'prism2_tx_80211':
drivers/net/wireless/hostap/hostap_hw.c:1816:18: warning: variable 'fc' set but not used
Removing fc from this just introduces a new warning
CC [M] drivers/net/wireless/hostap/hostap_plx.o
In file included from drivers/net/wireless/hostap/hostap_plx.c:264:0:
drivers/net/wireless/hostap/hostap_hw.c: In function 'prism2_tx_80211':
drivers/net/wireless/hostap/hostap_hw.c:1839:3: warning: statement with no effect
So I went and removed the whole thing. Let me know if theres another solution.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/hostap/hostap_hw.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_hw.c b/drivers/net/wireless/hostap/hostap_hw.c
index e9d9d62..d734f3e 100644
--- a/drivers/net/wireless/hostap/hostap_hw.c
+++ b/drivers/net/wireless/hostap/hostap_hw.c
@@ -1813,7 +1813,7 @@ static int prism2_tx_80211(struct sk_buff *skb, struct net_device *dev)
struct hfa384x_tx_frame txdesc;
struct hostap_skb_tx_data *meta;
int hdr_len, data_len, idx, res, ret = -1;
- u16 tx_control, fc;
+ u16 tx_control;
iface = netdev_priv(dev);
local = iface->local;
@@ -1836,7 +1836,6 @@ static int prism2_tx_80211(struct sk_buff *skb, struct net_device *dev)
/* skb->data starts with txdesc->frame_control */
hdr_len = 24;
skb_copy_from_linear_data(skb, &txdesc.frame_control, hdr_len);
- fc = le16_to_cpu(txdesc.frame_control);
if (ieee80211_is_data(txdesc.frame_control) &&
ieee80211_has_a4(txdesc.frame_control) &&
skb->len >= 30) {
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* Re: [PATCH]hostap:hostap_ioctl.c Fix variable 'ret' set but not used
From: Luis R. Rodriguez @ 2010-08-03 0:15 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-wireless, netdev, linux-kernel, j, linville
In-Reply-To: <1280793851-1719-1-git-send-email-justinmattock@gmail.com>
On Mon, Aug 2, 2010 at 5:04 PM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> The below patch fixes a warning message generated by GCC:
> CC [M] drivers/net/wireless/hostap/hostap_ioctl.o
> drivers/net/wireless/hostap/hostap_ioctl.c: In function 'prism2_request_scan':
> drivers/net/wireless/hostap/hostap_ioctl.c:1666:6: warning: variable 'ret' set but not used
>
> Keep in mind Im not sure if this is the right fix for this, so please
> feedback is appreciated.
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/net/wireless/hostap/hostap_ioctl.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
> index a85e43a..27d462f 100644
> --- a/drivers/net/wireless/hostap/hostap_ioctl.c
> +++ b/drivers/net/wireless/hostap/hostap_ioctl.c
> @@ -1663,7 +1663,6 @@ static int prism2_request_scan(struct net_device *dev)
> struct hostap_interface *iface;
> local_info_t *local;
> struct hfa384x_scan_request scan_req;
> - int ret = 0;
>
> iface = netdev_priv(dev);
> local = iface->local;
> @@ -1689,7 +1688,7 @@ static int prism2_request_scan(struct net_device *dev)
> if (local->func->set_rid(dev, HFA384X_RID_SCANREQUEST, &scan_req,
> sizeof(scan_req))) {
> printk(KERN_DEBUG "SCANREQUEST failed\n");
> - ret = -EINVAL;
> + return -EINVAL;
> }
>
> if (!local->host_roaming)
NACK please read the code instead of just patching blindly to cure a
compile issue. For example read this big block:
/* FIX:
* It seems to be enough to set roaming mode for a short moment to
* host-based and then setup scanrequest data and return the mode to
* firmware-based.
*
* Master mode would need to drop to Managed mode for a short while
* to make scanning work.. Or sweep through the different channels and
* use passive scan based on beacons. */
So.. it seems to me you likely want to flip back to
HFA384X_ROAMING_FIRMWARE *after* you've tried to issue the
HFA384X_RID_SCANREQUEST, even if it has failed. So the compile fix
should require just changing the last return statement of the function
to return ret value.
Luis
^ permalink raw reply
* Re: [PATCH]hostap:hostap_ioctl.c Fix variable 'ret' set but not used
From: Luis R. Rodriguez @ 2010-08-03 0:16 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-wireless, netdev, linux-kernel, j, linville
In-Reply-To: <AANLkTinCa3Z+E6FhgmEkbS65dDVZ-Ss0aNYyDb_GGHMH@mail.gmail.com>
On Mon, Aug 2, 2010 at 5:15 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Mon, Aug 2, 2010 at 5:04 PM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
>> The below patch fixes a warning message generated by GCC:
>> CC [M] drivers/net/wireless/hostap/hostap_ioctl.o
>> drivers/net/wireless/hostap/hostap_ioctl.c: In function 'prism2_request_scan':
>> drivers/net/wireless/hostap/hostap_ioctl.c:1666:6: warning: variable 'ret' set but not used
>>
>> Keep in mind Im not sure if this is the right fix for this, so please
>> feedback is appreciated.
>>
>> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>>
>> ---
>> drivers/net/wireless/hostap/hostap_ioctl.c | 3 +--
>> 1 files changed, 1 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
>> index a85e43a..27d462f 100644
>> --- a/drivers/net/wireless/hostap/hostap_ioctl.c
>> +++ b/drivers/net/wireless/hostap/hostap_ioctl.c
>> @@ -1663,7 +1663,6 @@ static int prism2_request_scan(struct net_device *dev)
>> struct hostap_interface *iface;
>> local_info_t *local;
>> struct hfa384x_scan_request scan_req;
>> - int ret = 0;
>>
>> iface = netdev_priv(dev);
>> local = iface->local;
>> @@ -1689,7 +1688,7 @@ static int prism2_request_scan(struct net_device *dev)
>> if (local->func->set_rid(dev, HFA384X_RID_SCANREQUEST, &scan_req,
>> sizeof(scan_req))) {
>> printk(KERN_DEBUG "SCANREQUEST failed\n");
>> - ret = -EINVAL;
>> + return -EINVAL;
>> }
>>
>> if (!local->host_roaming)
>
> NACK please read the code instead of just patching blindly to cure a
> compile issue. For example read this big block:
>
>
> /* FIX:
> * It seems to be enough to set roaming mode for a short moment to
> * host-based and then setup scanrequest data and return the mode to
> * firmware-based.
> *
> * Master mode would need to drop to Managed mode for a short while
> * to make scanning work.. Or sweep through the different channels and
> * use passive scan based on beacons. */
>
> So.. it seems to me you likely want to flip back to
> HFA384X_ROAMING_FIRMWARE *after* you've tried to issue the
> HFA384X_RID_SCANREQUEST, even if it has failed. So the compile fix
> should require just changing the last return statement of the function
> to return ret value.
And for 802.11 there is no need to cc netdev and lkml. Just use linux-wireless.
Luis
^ permalink raw reply
* Re: [PATCH] ip_fragment: fix subtracting PPPOE_SES_HLEN from mtu twice
From: David Miller @ 2010-08-03 0:25 UTC (permalink / raw)
To: bdschuym; +Cc: kaber, xiaosuo, netdev
In-Reply-To: <4C571A70.20103@pandora.be>
From: Bart De Schuymer <bdschuym@pandora.be>
Date: Mon, 02 Aug 2010 21:20:16 +0200
> Patrick McHardy schreef:
>> On 01.08.2010 01:25, Changli Gao wrote:
>>
>>> 6c79bf0f2440fd250c8fce8d9b82fcf03d4e8350 subtracts PPPOE_SES_HLEN from
>>> mtu at
>>> the front of ip_fragment(). So the later subtraction should be
>>> removed. The
>>> MTU of 802.1q is also 1500, so MTU should not be changed.
...
> Signed-off-by: Bart De Schuymer <bdschuym@pandora.bo>
>>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net: Add getsockopt support for TCP thin-streams
From: David Miller @ 2010-08-03 0:25 UTC (permalink / raw)
To: apetlund; +Cc: johunt, kuznet, jmorris, kaber, netdev, linux-kernel, juhlenko
In-Reply-To: <4C56B018.8030309@simula.no>
From: Andreas Petlund <apetlund@simula.no>
Date: Mon, 02 Aug 2010 13:46:32 +0200
> On 07/31/2010 01:49 AM, Josh Hunt wrote:
>> Initial TCP thin-stream commit did not add getsockopt support for the new
>> socket options: TCP_THIN_LINEAR_TIMEOUTS and TCP_THIN_DUPACK. This adds support
>> for them.
>>
>> Signed-off-by: Josh Hunt <johunt@akamai.com>
...
> Tested-by: Andreas Petlund <apetlund@simula.no>
> Acked-by: Andreas Petlund <apetlund@simula.no>
Applied, thanks.
^ permalink raw reply
* [net-next-2.6 PATCH 1/3] e1000e: register pm_qos request on hardware activation
From: Jeff Kirsher @ 2010-08-03 0:27 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Florian Mickler, Jeff Kirsher
From: Florian Mickler <florian@mickler.org>
The pm_qos_add_request call has to register the pm_qos request with the pm_qos
susbsystem before first use of the pm_qos request via
pm_qos_update_request.
As pm_qos changed to use plists there is no benefit in registering and
unregistering the pm_qos request on ifup/ifdown and thus we move the
registering into e1000_open and the unregistering in e1000_close.
This fixes the following warning:
[ 1.786060] WARNING: at kernel/pm_qos_params.c:264
pm_qos_update_request+0x28/0x54()
[ 1.786088] Hardware name: Latitude E6500
[ 1.787045] pm_qos_update_request() called for unknown object
[ 1.787966] Modules linked in:
[ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
[ 1.790035] Call Trace:
[ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
[ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
[ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
[ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
[ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
[ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
[ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
[ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
[ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
[ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
[ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
[ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
[ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
[ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
[ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
[ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
[ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
[ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
[ 1.809958] ---[ end trace 84b562a00a60539e ]---
Signed-off-by: Florian Mickler <florian@mickler.org>
Tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 23 +++++++++++------------
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index afd0129..464c9a2 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3218,12 +3218,6 @@ int e1000e_up(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
- /* DMA latency requirement to workaround early-receive/jumbo issue */
- if (adapter->flags & FLAG_HAS_ERT)
- adapter->netdev->pm_qos_req =
- pm_qos_add_request(PM_QOS_CPU_DMA_LATENCY,
- PM_QOS_DEFAULT_VALUE);
-
/* hardware has been reset, we need to reload some things */
e1000_configure(adapter);
@@ -3287,12 +3281,6 @@ void e1000e_down(struct e1000_adapter *adapter)
e1000_clean_tx_ring(adapter);
e1000_clean_rx_ring(adapter);
- if (adapter->flags & FLAG_HAS_ERT) {
- pm_qos_remove_request(
- adapter->netdev->pm_qos_req);
- adapter->netdev->pm_qos_req = NULL;
- }
-
/*
* TODO: for power management, we could drop the link and
* pci_disable_device here.
@@ -3527,6 +3515,12 @@ static int e1000_open(struct net_device *netdev)
E1000_MNG_DHCP_COOKIE_STATUS_VLAN))
e1000_update_mng_vlan(adapter);
+ /* DMA latency requirement to workaround early-receive/jumbo issue */
+ if (adapter->flags & FLAG_HAS_ERT)
+ adapter->netdev->pm_qos_req =
+ pm_qos_add_request(PM_QOS_CPU_DMA_LATENCY,
+ PM_QOS_DEFAULT_VALUE);
+
/*
* before we allocate an interrupt, we must be ready to handle it.
* Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
@@ -3631,6 +3625,11 @@ static int e1000_close(struct net_device *netdev)
if (adapter->flags & FLAG_HAS_AMT)
e1000_release_hw_control(adapter);
+ if (adapter->flags & FLAG_HAS_ERT) {
+ pm_qos_remove_request(adapter->netdev->pm_qos_req);
+ adapter->netdev->pm_qos_req = NULL;
+ }
+
pm_runtime_put_sync(&pdev->dev);
return 0;
^ permalink raw reply related
* [net-next-2.6 PATCH 2/3] e1000e: Fix irq_synchronize in MSI-X case
From: Jeff Kirsher @ 2010-08-03 0:27 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, bphilips, Jean Delvare, Jesse Brandeburg,
Jeff Kirsher, Bruce Allan
In-Reply-To: <20100803002622.4179.31850.stgit@localhost.localdomain>
Based on original patch/work from Jean Delvare <jdelvare@suse.de>
Synchronize all IRQs when in MSI-X IRQ mode.
Jean's original patch hard coded the sync with the 3 possible vectors,
this patch incorporates more flexibility for the future and aligns
with how igb stores the number of vectors into the adapter structure.
CC: Jean Delvare <jdelvare@suse.de>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
---
drivers/net/e1000e/e1000.h | 1 +
drivers/net/e1000e/netdev.c | 26 ++++++++++++++++++--------
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 9ee133f..f9a31c8 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -348,6 +348,7 @@ struct e1000_adapter {
u32 test_icr;
u32 msg_enable;
+ unsigned int num_vectors;
struct msix_entry *msix_entries;
int int_mode;
u32 eiac_mask;
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 464c9a2..9e9164a 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1785,25 +1785,25 @@ void e1000e_reset_interrupt_capability(struct e1000_adapter *adapter)
void e1000e_set_interrupt_capability(struct e1000_adapter *adapter)
{
int err;
- int numvecs, i;
-
+ int i;
switch (adapter->int_mode) {
case E1000E_INT_MODE_MSIX:
if (adapter->flags & FLAG_HAS_MSIX) {
- numvecs = 3; /* RxQ0, TxQ0 and other */
- adapter->msix_entries = kcalloc(numvecs,
+ adapter->num_vectors = 3; /* RxQ0, TxQ0 and other */
+ adapter->msix_entries = kcalloc(adapter->num_vectors,
sizeof(struct msix_entry),
GFP_KERNEL);
if (adapter->msix_entries) {
- for (i = 0; i < numvecs; i++)
+ for (i = 0; i < adapter->num_vectors; i++)
adapter->msix_entries[i].entry = i;
err = pci_enable_msix(adapter->pdev,
adapter->msix_entries,
- numvecs);
- if (err == 0)
+ adapter->num_vectors);
+ if (err == 0) {
return;
+ }
}
/* MSI-X failed, so fall through and try MSI */
e_err("Failed to initialize MSI-X interrupts. "
@@ -1825,6 +1825,9 @@ void e1000e_set_interrupt_capability(struct e1000_adapter *adapter)
/* Don't do anything; this is the system default */
break;
}
+
+ /* store the number of vectors being used */
+ adapter->num_vectors = 1;
}
/**
@@ -1946,7 +1949,14 @@ static void e1000_irq_disable(struct e1000_adapter *adapter)
if (adapter->msix_entries)
ew32(EIAC_82574, 0);
e1e_flush();
- synchronize_irq(adapter->pdev->irq);
+
+ if (adapter->msix_entries) {
+ int i;
+ for (i = 0; i < adapter->num_vectors; i++)
+ synchronize_irq(adapter->msix_entries[i].vector);
+ } else {
+ synchronize_irq(adapter->pdev->irq);
+ }
}
/**
^ permalink raw reply related
* [net-next-2.6 PATCH 3/3] e1000e: update to workaround for jumbo frames on 82577
From: Jeff Kirsher @ 2010-08-03 0:27 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100803002622.4179.31850.stgit@localhost.localdomain>
From: Bruce Allan <bruce.w.allan@intel.com>
For OEM systems with this part that also has Spread Spectrum Clocking (SSC)
enabled in the BIOS, there is an Rx performance issue with 4K jumbo frames.
Leaving the defaults in PHY page 770 register 26 resolves the issue, and
does not negatively impact jumbo frames on systems with SSC disabled.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/netdev.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 9e9164a..cc97b58 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -2727,11 +2727,6 @@ static void e1000_setup_rctl(struct e1000_adapter *adapter)
if ((hw->phy.type == e1000_phy_82577) && (rctl & E1000_RCTL_LPE)) {
u16 phy_data;
- e1e_rphy(hw, PHY_REG(770, 26), &phy_data);
- phy_data &= 0xfff8;
- phy_data |= (1 << 2);
- e1e_wphy(hw, PHY_REG(770, 26), phy_data);
-
e1e_rphy(hw, 22, &phy_data);
phy_data &= 0x0fff;
phy_data |= (1 << 14);
^ permalink raw reply related
* Re: [net-next-2.6 PATCH 3/3] e1000e: update to workaround for jumbo frames on 82577
From: Jeff Kirsher @ 2010-08-03 0:36 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Bruce Allan, Jeff Kirsher
In-Reply-To: <20100803002748.4179.85660.stgit@localhost.localdomain>
On Mon, Aug 2, 2010 at 17:27, Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> For OEM systems with this part that also has Spread Spectrum Clocking (SSC)
> enabled in the BIOS, there is an Rx performance issue with 4K jumbo frames.
> Leaving the defaults in PHY page 770 register 26 resolves the issue, and
> does not negatively impact jumbo frames on systems with SSC disabled.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>
> drivers/net/e1000e/netdev.c | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
>
Please disregard this patch, it was sent out accidentally (my bad).
During testing issues were found and changes need to be made to this
patch.
--
Cheers,
Jeff
^ permalink raw reply
* [net-next-2.6 PATCH] igb: Use irq_synchronize per vector when using MSI-X
From: Jeff Kirsher @ 2010-08-03 0:40 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Jean Delvare, Emil Tantilov,
Jeff Kirsher
From: Emil Tantilov <emil.s.tantilov@intel.com>
Synchronize all IRQs when using MSI-X. Similar to ixgbe.
Issue was reported on e1000e, but the patch is also valid for igb.
CC: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/igb/igb_main.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 667b527..df5dcd2 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -1290,7 +1290,13 @@ static void igb_irq_disable(struct igb_adapter *adapter)
wr32(E1000_IAM, 0);
wr32(E1000_IMC, ~0);
wrfl();
- synchronize_irq(adapter->pdev->irq);
+ if (adapter->msix_entries) {
+ int i;
+ for (i = 0; i < adapter->num_q_vectors; i++)
+ synchronize_irq(adapter->msix_entries[i].vector);
+ } else {
+ synchronize_irq(adapter->pdev->irq);
+ }
}
/**
^ permalink raw reply related
* [net-next-2.6 PATCH] ixgbevf: fix null pointer dereference due to filter being set for VLAN 0
From: Jeff Kirsher @ 2010-08-03 0:59 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, bphilips, Alexander Duyck, Jeff Kirsher
From: Alexander Duyck <alexander.h.duyck@intel.com>
This change corrects an issue that resulted in a null pointer dereference
for the addition of VLAN 0 without any VLANs being registered. Also this
code removes some unnecessary checks for defines and the unnecessary setting
of VLAN flags since that is now handled within the kernel via the
vlan_features.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbevf/ixgbevf_main.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c b/drivers/net/ixgbevf/ixgbevf_main.c
index 4867440..3e291cc 100644
--- a/drivers/net/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ixgbevf/ixgbevf_main.c
@@ -1463,18 +1463,10 @@ static void ixgbevf_vlan_rx_add_vid(struct net_device *netdev, u16 vid)
{
struct ixgbevf_adapter *adapter = netdev_priv(netdev);
struct ixgbe_hw *hw = &adapter->hw;
- struct net_device *v_netdev;
/* add VID to filter table */
if (hw->mac.ops.set_vfta)
hw->mac.ops.set_vfta(hw, vid, 0, true);
- /*
- * Copy feature flags from netdev to the vlan netdev for this vid.
- * This allows things like TSO to bubble down to our vlan device.
- */
- v_netdev = vlan_group_get_device(adapter->vlgrp, vid);
- v_netdev->features |= adapter->netdev->features;
- vlan_group_set_device(adapter->vlgrp, vid, v_netdev);
}
static void ixgbevf_vlan_rx_kill_vid(struct net_device *netdev, u16 vid)
@@ -3402,7 +3394,6 @@ static int __devinit ixgbevf_probe(struct pci_dev *pdev,
/* setup the private structure */
err = ixgbevf_sw_init(adapter);
-#ifdef MAX_SKB_FRAGS
netdev->features = NETIF_F_SG |
NETIF_F_IP_CSUM |
NETIF_F_HW_VLAN_TX |
@@ -3416,13 +3407,12 @@ static int __devinit ixgbevf_probe(struct pci_dev *pdev,
netdev->vlan_features |= NETIF_F_TSO;
netdev->vlan_features |= NETIF_F_TSO6;
netdev->vlan_features |= NETIF_F_IP_CSUM;
+ netdev->vlan_features |= NETIF_F_IPV6_CSUM;
netdev->vlan_features |= NETIF_F_SG;
if (pci_using_dac)
netdev->features |= NETIF_F_HIGHDMA;
-#endif /* MAX_SKB_FRAGS */
-
/* The HW MAC address was set and/or determined in sw_init */
memcpy(netdev->dev_addr, adapter->hw.mac.addr, netdev->addr_len);
memcpy(netdev->perm_addr, adapter->hw.mac.addr, netdev->addr_len);
^ permalink raw reply related
* Re: [net-2.6 PATCH] e1000e: 82577/82578 PHY register access issues
From: Jeff Kirsher @ 2010-08-03 1:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, gospo, bphilips, stable, bruce.w.allan
In-Reply-To: <20100727.210642.137855605.davem@davemloft.net>
On Tue, Jul 27, 2010 at 21:06, David Miller <davem@davemloft.net> wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Tue, 27 Jul 2010 15:28:46 -0700
>
>> From: Bruce Allan <bruce.w.allan@intel.com>
>>
>> The MAC-PHY interconnect on 82577/82578 uses a power management feature
>> (called K1) which must be disabled when in 1Gbps due to a hardware issue on
>> these parts. The #define bit setting used to enable/disable K1 is
>> incorrect and can cause PHY register accesses to stop working altogether
>> until the next device reset. This patch sets the register correctly.
>>
>> This issue is present in kernels since 2.6.32.
>>
>> CC: stable@kernel.org
>> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
>> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Applied, thanks.
> --
Dave,
Have you sync'd up your net-next-2.6 tree with net-2.6 tree? Because
I do not see this change in the net-next-2.6 tree.
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH -mmotm 05/30] mm: sl[au]b: add knowledge of reserve pages
From: Neil Brown @ 2010-08-03 1:44 UTC (permalink / raw)
To: Pekka Enberg
Cc: Xiaotian Feng, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
riel-H+wXaHxf7aLQT0dZR+AlfA, cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, lwang-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <AANLkTilj5GrhbRJZfSsfXP1v9cQSRlARFmxpys1vUelr-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 13 Jul 2010 23:33:14 +0300
Pekka Enberg <penberg-bbCR+/B0CizivPeTLB3BmA@public.gmane.org> wrote:
> Hi Xiaotian!
>
> I would actually prefer that the SLAB, SLOB, and SLUB changes were in
> separate patches to make reviewing easier.
>
> Looking at SLUB:
>
> On Tue, Jul 13, 2010 at 1:17 PM, Xiaotian Feng <dfeng-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 7bb7940..7a5d6dc 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -27,6 +27,8 @@
> > #include <linux/memory.h>
> > #include <linux/math64.h>
> > #include <linux/fault-inject.h>
> > +#include "internal.h"
> > +
> >
> > /*
> > * Lock order:
> > @@ -1139,7 +1141,8 @@ static void setup_object(struct kmem_cache *s, struct page *page,
> > s->ctor(object);
> > }
> >
> > -static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> > +static
> > +struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node, int *reserve)
> > {
> > struct page *page;
> > void *start;
> > @@ -1153,6 +1156,8 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> > if (!page)
> > goto out;
> >
> > + *reserve = page->reserve;
> > +
> > inc_slabs_node(s, page_to_nid(page), page->objects);
> > page->slab = s;
> > page->flags |= 1 << PG_slab;
> > @@ -1606,10 +1611,20 @@ static void *__slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
> > {
> > void **object;
> > struct page *new;
> > + int reserve;
> >
> > /* We handle __GFP_ZERO in the caller */
> > gfpflags &= ~__GFP_ZERO;
> >
> > + if (unlikely(c->reserve)) {
> > + /*
> > + * If the current slab is a reserve slab and the current
> > + * allocation context does not allow access to the reserves we
> > + * must force an allocation to test the current levels.
> > + */
> > + if (!(gfp_to_alloc_flags(gfpflags) & ALLOC_NO_WATERMARKS))
> > + goto grow_slab;
>
> OK, so assume that:
>
> (1) c->reserve is set to one
>
> (2) GFP flags don't allow dipping into the reserves
>
> (3) we've managed to free enough pages so normal
> allocations are fine
>
> (4) the page from reserves is not yet empty
>
> we will call flush_slab() and put the "emergency page" on partial list
> and clear c->reserve. This effectively means that now some other
> allocation can fetch the partial page and start to use it. Is this OK?
> Who makes sure the emergency reserves are large enough for the next
> out-of-memory condition where we swap over NFS?
Yes, this is OK. The emergency reserves are maintained at a lower level -
within alloc_page.
The fact that (3) normal allocations are fine means that there are enough
free pages to satisfy any swap-out allocation - so any pages that were
previously allocated as 'emergency' pages can have their emergency status
forgotten (the emergency has passed).
This is a subtle but important aspect of the emergency reservation scheme in
swap-over-NFS. It is the act-of-allocating that is emergency-or-not. The
memory itself, once allocated, is not special.
c->reserve means "the last page allocated required an emergency allocation".
This means that parts of that page, or any other page, can only be given as
emergency allocations. Once the slab succeeds at a non-emergency allocation,
the flag should obviously be cleared.
Similarly the page->reserve flag does not mean "this is a reserve page", but
simply "when this page was allocated, it was an emergency allocation". The
flag is often soon lost as it is in a union with e.g. freelist. But that
doesn't matter as it is only really meaningful at the moment of allocation.
I hope that clarifies the situation,
NeilBrown
>
> > + }
> > if (!c->page)
> > goto new_slab;
> >
> > @@ -1623,8 +1638,8 @@ load_freelist:
> > object = c->page->freelist;
> > if (unlikely(!object))
> > goto another_slab;
> > - if (unlikely(SLABDEBUG && PageSlubDebug(c->page)))
> > - goto debug;
> > + if (unlikely(SLABDEBUG && PageSlubDebug(c->page) || c->reserve))
> > + goto slow_path;
> >
> > c->freelist = get_freepointer(s, object);
> > c->page->inuse = c->page->objects;
> > @@ -1646,16 +1661,18 @@ new_slab:
> > goto load_freelist;
> > }
> >
> > +grow_slab:
> > if (gfpflags & __GFP_WAIT)
> > local_irq_enable();
> >
> > - new = new_slab(s, gfpflags, node);
> > + new = new_slab(s, gfpflags, node, &reserve);
> >
> > if (gfpflags & __GFP_WAIT)
> > local_irq_disable();
> >
> > if (new) {
> > c = __this_cpu_ptr(s->cpu_slab);
> > + c->reserve = reserve;
> > stat(s, ALLOC_SLAB);
> > if (c->page)
> > flush_slab(s, c);
> > @@ -1667,10 +1684,20 @@ new_slab:
> > if (!(gfpflags & __GFP_NOWARN) && printk_ratelimit())
> > slab_out_of_memory(s, gfpflags, node);
> > return NULL;
> > -debug:
> > - if (!alloc_debug_processing(s, c->page, object, addr))
> > +
> > +slow_path:
> > + if (!c->reserve && !alloc_debug_processing(s, c->page, object, addr))
> > goto another_slab;
> >
> > + /*
> > + * Avoid the slub fast path in slab_alloc() by not setting
> > + * c->freelist and the fast path in slab_free() by making
> > + * node_match() fail by setting c->node to -1.
> > + *
> > + * We use this for for debug and reserve checks which need
> > + * to be done for each allocation.
> > + */
> > +
> > c->page->inuse++;
> > c->page->freelist = get_freepointer(s, object);
> > c->node = -1;
> > @@ -2095,10 +2122,11 @@ static void early_kmem_cache_node_alloc(gfp_t gfpflags, int node)
> > struct page *page;
> > struct kmem_cache_node *n;
> > unsigned long flags;
> > + int reserve;
> >
> > BUG_ON(kmalloc_caches->size < sizeof(struct kmem_cache_node));
> >
> > - page = new_slab(kmalloc_caches, gfpflags, node);
> > + page = new_slab(kmalloc_caches, gfpflags, node, &reserve);
> >
> > BUG_ON(!page);
> > if (page_to_nid(page) != node) {
> > --
> > 1.7.1.1
> >
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo-Bw31MaZKKs0EbZ0PF+XxCw@public.gmane.org For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"> email-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org </a>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: Is it a possible bug in dev_gro_receive()?
From: Xin, Xiaohui @ 2010-08-03 2:33 UTC (permalink / raw)
To: Jarek Poplawski
Cc: netdev@vger.kernel.org, herbert@gondor.apana.org.au,
davem@davemloft.net
In-Reply-To: <20100802102906.GA8439@ff.dom.local>
>-----Original Message-----
>From: Jarek Poplawski [mailto:jarkao2@gmail.com]
>Sent: Monday, August 02, 2010 6:29 PM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; herbert@gondor.apana.org.au; davem@davemloft.net
>Subject: Re: Is it a possible bug in dev_gro_receive()?
>
>Xin Xiaohui wrote:
>> I looked into the code dev_gro_receive(), found the code here:
>> if the frags[0] is pulled to 0, then the page will be released,
>> and memmove() frags left.
>> Is that right? I'm not sure if memmove do right or not, but
>> frags[0].size is never set after memove at least. what I think
>> a simple way is not to do anything if we found frags[0].size == 0.
>> The patch is as followed.
>>
>> Or am I missing something here?
>
>I think, you're right, but fixing memmove looks nicer to me:
>
> - --skb_shinfo(skb)->nr_frags);
> + --skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
>
>Jarek P.
Is there a little hurt of performance to do memmove() if skb_shinfo(skb)->nr_frags is large?
We're now working on the zero-copy patches based on napi_gro_frags() interface, and in
this case, we have found a lot of skbs which frags[0] is pulled to 0. And after the memmove is
fixed, each frags[x].size is needed to modify too.
So I think don't do anything is better. Or is there any side effect with a null page in the stack?
Thanks
Xiaohui
>
>>
>> ---
>> net/core/dev.c | 7 -------
>> 1 files changed, 0 insertions(+), 7 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 264137f..28cdbbf 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2730,13 +2730,6 @@ pull:
>>
>> skb_shinfo(skb)->frags[0].page_offset += grow;
>> skb_shinfo(skb)->frags[0].size -= grow;
>> -
>> - if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
>> - put_page(skb_shinfo(skb)->frags[0].page);
>> - memmove(skb_shinfo(skb)->frags,
>> - skb_shinfo(skb)->frags + 1,
>> - --skb_shinfo(skb)->nr_frags);
>> - }
>> }
>>
>> ok:
>
>
^ permalink raw reply
* [PATCH] deal with if frags[0].size is pulled to 0 in dev_gro_receive()
From: xiaohui.xin @ 2010-08-03 3:17 UTC (permalink / raw)
To: netdev, herbert, davem; +Cc: Xin Xiaohui
From: Xin Xiaohui <xiaohui.xin@intel.com>
Now in dev_gro_receive(), if frags[0].size is pulled to 0, memmove is called and
the null page is released. But it's not enough, we should reset size of each frags
left as well. Compared to this, we can have another way to do this, it's not do do
anything at all.
Signed-off-by: Xin Xiaohui <xiaohui.xin@intel.com>
---
net/core/dev.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 264137f..28cdbbf 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2730,13 +2730,6 @@ pull:
skb_shinfo(skb)->frags[0].page_offset += grow;
skb_shinfo(skb)->frags[0].size -= grow;
-
- if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
- put_page(skb_shinfo(skb)->frags[0].page);
- memmove(skb_shinfo(skb)->frags,
- skb_shinfo(skb)->frags + 1,
- --skb_shinfo(skb)->nr_frags);
- }
}
ok:
--
1.5.4.4
^ permalink raw reply related
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