* Re: gro: Fix illegal merging of trailer trash
From: David Miller @ 2009-11-17 13:18 UTC (permalink / raw)
To: herbert; +Cc: netdev, mwagner
In-Reply-To: <20091117124414.GA14951@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Tue, 17 Nov 2009 20:44:14 +0800
> gro: Fix illegal merging of trailer trash
>
> When we've merged skb's with page frags, and subsequently receive
> a trailer skb (< MSS) that is not completely non-linear (this can
> occur on Intel NICs if the packet size falls below the threshold),
> GRO ends up producing an illegal GSO skb with a frag_list.
>
> This is harmless unless the skb is then forwarded through an
> interface that requires software GSO, whereupon the GSO code
> will BUG.
>
> This patch detects this case in GRO and avoids merging the
> trailer skb.
>
> Reported-by: Mark Wagner <mwagner@redhat.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: updates to the mscan-driver in net-next
From: Wolfram Sang @ 2009-11-17 13:07 UTC (permalink / raw)
To: netdev; +Cc: socketcan-core, linuxppc-dev, David Miller
In-Reply-To: <1258412274-14686-1-git-send-email-w.sang@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]
> I will also update my branch on pengutronix.de tomorrow,
Done.
===
The following changes since commit a0a9020c1725cd5c9a13a7aab65831f3c85ea9ca:
Wolfram Sang (1):
net/can/mscan: final checkpatch cleanups
are available in the git repository at:
git://git.pengutronix.de/git/wsa/linux-2.6.git net-next-52xx-can
Wolfram Sang (11):
net/can/mscan: move defines into .h file
net/can/mscan: trivial fixes
net/can/mscan: drop support for CAN_MODE_{SLEEP|STOP}
net/can/mscan: use {clr|set}bits8 macros
net/can/mscan: fix function annotations
net/can/mscan: drop assignment in while-construct
net/can/mpc52xx_can: refactor clock-get routine
net/can/mpc52xx_can: improve properties and their description
net/can/mscan: replace hardcoded values with defines
net/can/mscan: add error path to mscan_open()
net/can/mscan: improve build
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt | 9 +-
drivers/net/can/Kconfig | 19 +---
drivers/net/can/mscan/Kconfig | 23 ++++
drivers/net/can/mscan/Makefile | 4 +-
.../net/can/mscan/{mpc52xx_can.c => mpc5xxx_can.c} | 64 ++++-------
drivers/net/can/mscan/mscan.c | 121 +++++++------------
drivers/net/can/mscan/mscan.h | 36 ++++++-
7 files changed, 133 insertions(+), 143 deletions(-)
create mode 100644 drivers/net/can/mscan/Kconfig
rename drivers/net/can/mscan/{mpc52xx_can.c => mpc5xxx_can.c} (90%)
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [RFC] [PATCH net-next] Phonet: convert devices list to RCU
From: Rémi Denis-Courmont @ 2009-11-17 13:02 UTC (permalink / raw)
To: netdev; +Cc: Rémi Denis-Courmont
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
---
include/net/phonet/pn_dev.h | 2 +-
net/phonet/pn_dev.c | 63 ++++++++++++++++++++++++++++---------------
net/phonet/pn_netlink.c | 6 ++--
3 files changed, 45 insertions(+), 26 deletions(-)
diff --git a/include/net/phonet/pn_dev.h b/include/net/phonet/pn_dev.h
index afa7def..d7b989c 100644
--- a/include/net/phonet/pn_dev.h
+++ b/include/net/phonet/pn_dev.h
@@ -25,7 +25,7 @@
struct phonet_device_list {
struct list_head list;
- spinlock_t lock;
+ struct mutex lock;
};
struct phonet_device_list *phonet_device_list(struct net *net);
diff --git a/net/phonet/pn_dev.c b/net/phonet/pn_dev.c
index 3287f8f..3d9608f 100644
--- a/net/phonet/pn_dev.c
+++ b/net/phonet/pn_dev.c
@@ -61,7 +61,8 @@ static struct phonet_device *__phonet_device_alloc(struct net_device *dev)
pnd->netdev = dev;
bitmap_zero(pnd->addrs, 64);
- list_add(&pnd->list, &pndevs->list);
+ BUG_ON(!mutex_is_locked(&pndevs->lock));
+ list_add_rcu(&pnd->list, &pndevs->list);
return pnd;
}
@@ -70,6 +71,7 @@ static struct phonet_device *__phonet_get(struct net_device *dev)
struct phonet_device_list *pndevs = phonet_device_list(dev_net(dev));
struct phonet_device *pnd;
+ BUG_ON(!mutex_is_locked(&pndevs->lock));
list_for_each_entry(pnd, &pndevs->list, list) {
if (pnd->netdev == dev)
return pnd;
@@ -77,6 +79,18 @@ static struct phonet_device *__phonet_get(struct net_device *dev)
return NULL;
}
+static struct phonet_device *__phonet_get_rcu(struct net_device *dev)
+{
+ struct phonet_device_list *pndevs = phonet_device_list(dev_net(dev));
+ struct phonet_device *pnd;
+
+ list_for_each_entry_rcu(pnd, &pndevs->list, list) {
+ if (pnd->netdev == dev)
+ return pnd;
+ }
+ return NULL;
+}
+
static void phonet_device_destroy(struct net_device *dev)
{
struct phonet_device_list *pndevs = phonet_device_list(dev_net(dev));
@@ -84,11 +98,11 @@ static void phonet_device_destroy(struct net_device *dev)
ASSERT_RTNL();
- spin_lock_bh(&pndevs->lock);
+ mutex_lock(&pndevs->lock);
pnd = __phonet_get(dev);
if (pnd)
- list_del(&pnd->list);
- spin_unlock_bh(&pndevs->lock);
+ list_del_rcu(&pnd->list);
+ mutex_unlock(&pndevs->lock);
if (pnd) {
u8 addr;
@@ -106,8 +120,8 @@ struct net_device *phonet_device_get(struct net *net)
struct phonet_device *pnd;
struct net_device *dev = NULL;
- spin_lock_bh(&pndevs->lock);
- list_for_each_entry(pnd, &pndevs->list, list) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(pnd, &pndevs->list, list) {
dev = pnd->netdev;
BUG_ON(!dev);
@@ -118,7 +132,7 @@ struct net_device *phonet_device_get(struct net *net)
}
if (dev)
dev_hold(dev);
- spin_unlock_bh(&pndevs->lock);
+ rcu_read_unlock();
return dev;
}
@@ -128,7 +142,7 @@ int phonet_address_add(struct net_device *dev, u8 addr)
struct phonet_device *pnd;
int err = 0;
- spin_lock_bh(&pndevs->lock);
+ mutex_lock(&pndevs->lock);
/* Find or create Phonet-specific device data */
pnd = __phonet_get(dev);
if (pnd == NULL)
@@ -137,7 +151,7 @@ int phonet_address_add(struct net_device *dev, u8 addr)
err = -ENOMEM;
else if (test_and_set_bit(addr >> 2, pnd->addrs))
err = -EEXIST;
- spin_unlock_bh(&pndevs->lock);
+ mutex_unlock(&pndevs->lock);
return err;
}
@@ -147,27 +161,32 @@ int phonet_address_del(struct net_device *dev, u8 addr)
struct phonet_device *pnd;
int err = 0;
- spin_lock_bh(&pndevs->lock);
+ mutex_lock(&pndevs->lock);
pnd = __phonet_get(dev);
- if (!pnd || !test_and_clear_bit(addr >> 2, pnd->addrs))
+ if (!pnd || !test_and_clear_bit(addr >> 2, pnd->addrs)) {
err = -EADDRNOTAVAIL;
- else if (bitmap_empty(pnd->addrs, 64)) {
- list_del(&pnd->list);
+ pnd = NULL;
+ } else if (bitmap_empty(pnd->addrs, 64))
+ list_del_rcu(&pnd->list);
+ else
+ pnd = NULL;
+ mutex_unlock(&pndevs->lock);
+
+ if (pnd) {
+ synchronize_rcu();
kfree(pnd);
}
- spin_unlock_bh(&pndevs->lock);
return err;
}
/* Gets a source address toward a destination, through a interface. */
u8 phonet_address_get(struct net_device *dev, u8 daddr)
{
- struct phonet_device_list *pndevs = phonet_device_list(dev_net(dev));
struct phonet_device *pnd;
u8 saddr;
- spin_lock_bh(&pndevs->lock);
- pnd = __phonet_get(dev);
+ rcu_read_lock();
+ pnd = __phonet_get_rcu(dev);
if (pnd) {
BUG_ON(bitmap_empty(pnd->addrs, 64));
@@ -178,7 +197,7 @@ u8 phonet_address_get(struct net_device *dev, u8 daddr)
saddr = find_first_bit(pnd->addrs, 64) << 2;
} else
saddr = PN_NO_ADDR;
- spin_unlock_bh(&pndevs->lock);
+ rcu_read_unlock();
if (saddr == PN_NO_ADDR) {
/* Fallback to another device */
@@ -200,8 +219,8 @@ int phonet_address_lookup(struct net *net, u8 addr)
struct phonet_device *pnd;
int err = -EADDRNOTAVAIL;
- spin_lock_bh(&pndevs->lock);
- list_for_each_entry(pnd, &pndevs->list, list) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(pnd, &pndevs->list, list) {
/* Don't allow unregistering devices! */
if ((pnd->netdev->reg_state != NETREG_REGISTERED) ||
((pnd->netdev->flags & IFF_UP)) != IFF_UP)
@@ -213,7 +232,7 @@ int phonet_address_lookup(struct net *net, u8 addr)
}
}
found:
- spin_unlock_bh(&pndevs->lock);
+ rcu_read_unlock();
return err;
}
@@ -304,7 +323,7 @@ static int phonet_init_net(struct net *net)
}
INIT_LIST_HEAD(&pnn->pndevs.list);
- spin_lock_init(&pnn->pndevs.lock);
+ mutex_init(&pnn->pndevs.lock);
mutex_init(&pnn->routes.lock);
net_assign_generic(net, phonet_net_id, pnn);
return 0;
diff --git a/net/phonet/pn_netlink.c b/net/phonet/pn_netlink.c
index 609e509..2e6c7eb 100644
--- a/net/phonet/pn_netlink.c
+++ b/net/phonet/pn_netlink.c
@@ -131,8 +131,8 @@ static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
int addr_idx = 0, addr_start_idx = cb->args[1];
pndevs = phonet_device_list(sock_net(skb->sk));
- spin_lock_bh(&pndevs->lock);
- list_for_each_entry(pnd, &pndevs->list, list) {
+ rcu_read_lock();
+ list_for_each_entry_rcu(pnd, &pndevs->list, list) {
u8 addr;
if (dev_idx > dev_start_idx)
@@ -154,7 +154,7 @@ static int getaddr_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
}
out:
- spin_unlock_bh(&pndevs->lock);
+ rcu_read_unlock();
cb->args[0] = dev_idx;
cb->args[1] = addr_idx;
--
1.6.3.3
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: David Miller @ 2009-11-17 12:48 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: eric.dumazet, william.allen.simpson, netdev, joe
In-Reply-To: <alpine.DEB.2.00.0911171432420.7024@wel-95.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 17 Nov 2009 14:38:42 +0200 (EET)
> Right, but we could be just as crazy and just drop such things and
> keep resending SYN+DATA without any harm?
Two crazies == sane? :-)
Sure, we could do that.
^ permalink raw reply
* gro: Fix illegal merging of trailer trash
From: Herbert Xu @ 2009-11-17 12:44 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: Mark Wagner
Hi Dave:
Just found this thanks to Mark Wagner testing GRO with Xen.
We'll need this for stable too.
gro: Fix illegal merging of trailer trash
When we've merged skb's with page frags, and subsequently receive
a trailer skb (< MSS) that is not completely non-linear (this can
occur on Intel NICs if the packet size falls below the threshold),
GRO ends up producing an illegal GSO skb with a frag_list.
This is harmless unless the skb is then forwarded through an
interface that requires software GSO, whereupon the GSO code
will BUG.
This patch detects this case in GRO and avoids merging the
trailer skb.
Reported-by: Mark Wagner <mwagner@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 80a9616..ec85681 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2701,7 +2701,8 @@ int skb_gro_receive(struct sk_buff **head, struct sk_buff *skb)
NAPI_GRO_CB(skb)->free = 1;
goto done;
- }
+ } else if (skb_gro_len(p) != pinfo->gso_size)
+ return -E2BIG;
headroom = skb_headroom(p);
nskb = netdev_alloc_skb(p->dev, headroom + skb_gro_offset(p));
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: Ilpo Järvinen @ 2009-11-17 12:38 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, william.allen.simpson, Netdev, joe
In-Reply-To: <20091117.042250.28821014.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1402 bytes --]
On Tue, 17 Nov 2009, David Miller wrote:
> From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Tue, 17 Nov 2009 14:18:57 +0200 (EET)
>
> > On Mon, 16 Nov 2009, David Miller wrote:
> >
> >> From: Eric Dumazet <eric.dumazet@gmail.com>
> >> Date: Mon, 16 Nov 2009 23:26:04 +0100
> >>
> >> > So adding DATA to SYN packets might be problematic for part of our tcp
> >> > stack.
> >>
> >> I can almost guarentee it won't work. For one thing getting a SACK
> >> response to a SYN+DATA packet will explode quite nicely for one thing.
> >
> > Now I'm really lost??? How can you get SACKs for that in the first
> > place since they are either lost or delivered in unison???
>
> Ideally, you're probably right.
>
> However, it seems to me that the receiver can do whatever it likes
> with it's receive queue when it's under memory pressure.
>
> It can chop packets up, partially free bits, and then send a SACK
> block back to you for the parts it tried to free.
>
> If you'll recall, I wanted to put some tough restrictions into what is
> allowed with SACK so that we could optimize things on the sender side.
> But there was resistence and therefore we have to keep allowing all
> kinds of silly situations, the one we're talking about here merely
> being one of them :-)
Right, but we could be just as crazy and just drop such things and keep
resending SYN+DATA without any harm?
--
i.
^ permalink raw reply
* Re: [RFC PATCH] net: add dataref destructor to sk_buff
From: Gregory Haskins @ 2009-11-17 12:33 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, ghaskins, mst, alacrityvm-devel, linux-kernel,
netdev
In-Reply-To: <20091117010238.GA10029@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
Herbert Xu wrote:
> On Mon, Nov 16, 2009 at 09:22:57AM -0500, Gregory Haskins wrote:
>> But really, this is somewhat orthogonal to the original problem, so let
>> me see if we can bring it back on topic. Michael stated that this patch
>> in question may be problematic because there are places in the stack
>> that can get_page() without also maintaining a reference to the shinfo
>> object. Evgeniy seems to say the opposite. I am not sure who is right,
>> or if I misunderstood one or both of them. Any thoughts?
>
> There are loads of places where this can happen. Start with
> pskb_expand_head.
Indeed, I see your point. Looks like we can potentially solve that with
an extra level of indirection. E.g. skb->shinfo->owner, with a
ref-count+callback. Thoughts?
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: PATCH net-next-2.6] linkwatch: linkwatch_forget_dev() to speedup device dismantle
From: Herbert Xu @ 2009-11-17 12:31 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, eric.dumazet, netdev
In-Reply-To: <20091117.042604.99618154.davem@davemloft.net>
On Tue, Nov 17, 2009 at 04:26:04AM -0800, David Miller wrote:
>
> Really, the link watch stuff is just due for a redesign. I don't
> think a simple hack is going to cut it this time, sorry Eric :-)
I have no objections against any redesigns, but since the only
caller of linkwatch_forget_dev runs in process context with the
RTNL, it could also legally emit those events.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: PATCH net-next-2.6] linkwatch: linkwatch_forget_dev() to speedup device dismantle
From: David Miller @ 2009-11-17 12:26 UTC (permalink / raw)
To: shemminger; +Cc: eric.dumazet, herbert, netdev
In-Reply-To: <20091116143917.14e4fa4f@s6510>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 16 Nov 2009 14:39:17 -0800
> On Mon, 16 Nov 2009 22:50:48 +0100
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Is this really valid?
The whole point in emitting the netif_carrier_off() is so
that applications see the event in userspace and therefore
can clean things up.
Sure, the kernel will no longer make the device visible, and therefore
the application can't operate on it any longer. But the application
is deserved of receiving the event anyways so that it can clean up
internal state and datastructures.
It seem to me that in this ->stop() case we'll now elide the event
emission, and I don't see how that can be right.
Really, the link watch stuff is just due for a redesign. I don't
think a simple hack is going to cut it this time, sorry Eric :-)
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: David Miller @ 2009-11-17 12:22 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: eric.dumazet, william.allen.simpson, netdev, joe
In-Reply-To: <alpine.DEB.2.00.0911171412380.7024@wel-95.cs.helsinki.fi>
From: "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Tue, 17 Nov 2009 14:18:57 +0200 (EET)
> On Mon, 16 Nov 2009, David Miller wrote:
>
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Mon, 16 Nov 2009 23:26:04 +0100
>>
>> > So adding DATA to SYN packets might be problematic for part of our tcp
>> > stack.
>>
>> I can almost guarentee it won't work. For one thing getting a SACK
>> response to a SYN+DATA packet will explode quite nicely for one thing.
>
> Now I'm really lost??? How can you get SACKs for that in the first
> place since they are either lost or delivered in unison???
Ideally, you're probably right.
However, it seems to me that the receiver can do whatever it likes
with it's receive queue when it's under memory pressure.
It can chop packets up, partially free bits, and then send a SACK
block back to you for the parts it tried to free.
If you'll recall, I wanted to put some tough restrictions into what is
allowed with SACK so that we could optimize things on the sender side.
But there was resistence and therefore we have to keep allowing all
kinds of silly situations, the one we're talking about here merely
being one of them :-)
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: Ilpo Järvinen @ 2009-11-17 12:18 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, william.allen.simpson, Netdev, joe
In-Reply-To: <20091116.191522.178198674.davem@davemloft.net>
On Mon, 16 Nov 2009, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon, 16 Nov 2009 23:26:04 +0100
>
> > So adding DATA to SYN packets might be problematic for part of our tcp
> > stack.
>
> I can almost guarentee it won't work. For one thing getting a SACK
> response to a SYN+DATA packet will explode quite nicely for one thing.
Now I'm really lost??? How can you get SACKs for that in the first
place since they are either lost or delivered in unison???
> A lot of the other retransmit queue handling would need to be audited
> as well. So much code assumes that if we see sent data in the
> retransmit queue, there won't be SYN or SYN+ACK things in there to
> contend with.
...Valid ACKs will either remove that SYN+DATA segment completely, other
ACK could (or should) just be dropped. I kind of fail to see what is the
problem here.
--
i.
^ permalink raw reply
* Re: [PATCH 2/2] act_mirred: optimization
From: David Miller @ 2009-11-17 12:16 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, shemminger, netdev
In-Reply-To: <412e6f7f0911162149q1eedf18vfbf980fc690629f5@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 17 Nov 2009 13:49:00 +0800
> On Mon, Nov 16, 2009 at 9:33 PM, David Miller <davem@davemloft.net> wrote:
>> From: Changli Gao <xiaosuo@gmail.com>
>> Date: Mon, 16 Nov 2009 21:22:46 +0800
>>
>>> I am working against linux-next. I'll check if there is any
>>> difference. BTW: were these patches applied in order, 1 - 2?
>>
>> Yes, they were.
>>
>
> Patch is resubmitted as attachment.
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] act_mirred: cleanup
From: David Miller @ 2009-11-17 12:15 UTC (permalink / raw)
To: xiaosuo; +Cc: hadi, shemminger, netdev
In-Reply-To: <412e6f7f0911162148g72eb3749g860e476b7b5f3ab6@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 17 Nov 2009 13:48:06 +0800
> Patch is resubmitted as attachment.
That's a lot better, applied.
^ permalink raw reply
* Re: net-next-2.6 compilation errors: missing wireless/i82593.h
From: Alan Cox @ 2009-11-17 12:13 UTC (permalink / raw)
To: William Allen Simpson; +Cc: David Miller, linux-kernel, netdev, linville
In-Reply-To: <4B029012.6030202@gmail.com>
> >> /home/administer/net-next-2.6/drivers/net/znet.c:107:29: error:
> >> wireless/i82593.h: No such file or directory
> >
> > That header file got moved out to drivers/staging along with the
> > wavelan driver.
> >
> Too bad that CONFIG_STAGING "N" (# CONFIG_STAGING is not set) doesn't
> actually turn off all the staging....
It does - that isn't the problem. Someone moves shared header files out
of the right directory into staging without double checking (lxr is
rather handy..)
Alan
^ permalink raw reply
* Re: [PATCH net-next] Phonet: missing rcu_dereference()
From: David Miller @ 2009-11-17 12:09 UTC (permalink / raw)
To: remi; +Cc: netdev, remi.denis-courmont
In-Reply-To: <1258445844-6079-1-git-send-email-remi@remlab.net>
From: Rémi Denis-Courmont <remi@remlab.net>
Date: Tue, 17 Nov 2009 10:17:24 +0200
> From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH 2.6.32-rc3] net: Getting rid of the x86 dependency to built vmxnet3
From: David Miller @ 2009-11-17 12:09 UTC (permalink / raw)
To: sbhatewara; +Cc: netdev, pv-drivers, linux-kernel
In-Reply-To: <alpine.LRH.2.00.0911161053050.23246@sbhatewara-dev1.eng.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Mon, 16 Nov 2009 15:41:33 -0800 (PST)
>
> Getting rid of the x86 dependency to built vmxnet3
>
> From: Shreyas Bhatewara <sbhatewara@vmware.com>
>
> This patch removes config dependency on x86 to build vmxnet3 driver. Thus
> the driver can be built on big endian architectures now. Although vmxnet3
> is not supported on VMs other than x86 architecture, all this code goes in
> to ensure correctness. If the code is not dependent on x86, it should not
> assume little endian architecture in any of its operations.
>
> Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Patch applied, thanks for following up on this.
^ permalink raw reply
* Re: netlink: remove subscriptions check on notifier
From: David Miller @ 2009-11-17 12:09 UTC (permalink / raw)
To: johannes; +Cc: netdev, kaber
In-Reply-To: <1258409134.1375.0.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 16 Nov 2009 23:05:34 +0100
> The netlink URELEASE notifier doesn't notify for
> sockets that have been used to receive multicast
> but it should be called for such sockets as well
> since they might _also_ be used for sending and
> not solely for receiving multicast. We will need
> that for nl80211 (generic netlink sockets) in the
> future.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied, let's see what this breaks :-)
^ permalink raw reply
* Re: [net-next] bnx2x: Handle Rx and Tx together in NAPI
From: David Miller @ 2009-11-17 12:08 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <1258387558.30637.77.camel@lb-tlvb-vladz.il.broadcom.com>
From: "Vladislav Zolotarov" <vladz@broadcom.com>
Date: Mon, 16 Nov 2009 18:05:58 +0200
> Put Tx and Rx DPC to be handled in the NAPI:
> - Saves status blocks.
> - Moves the Tx work from hardIRQ to NAPI.
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thank you.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's
From: Ilpo Järvinen @ 2009-11-17 12:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: William Allen Simpson, Linux Kernel Network Developers,
Joe Perches
In-Reply-To: <4B01D17C.4010407@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1077 bytes --]
On Mon, 16 Nov 2009, Eric Dumazet wrote:
> William Allen Simpson a écrit :
> > Eric Dumazet wrote:
> >
> >> I remember a previous remark from David that our skb queues would not
> >> contain
> >> DATA on SYN packets...
> >>
> > I haven't seen anything by David, but there's an existing comment in
> > tcp_input.c at the place where SYN data will be added later:
> >
>
> Yep, David comment was about another netdev thread, while tracking an
> obscure bug
>
> http://www.spinics.net/lists/netdev/msg110759.html
>
> http://www.spinics.net/lists/netdev/msg110764.html
>
>
> So adding DATA to SYN packets might be problematic for part of our tcp
> stack.
You both are right (and that's what is causing confusion)... What DaveM
said is this:
"And we're only dealing with data packets once we enter established
state, and when we enter established by definition we have unlinked
and freed up any SYN and SYN+ACK SKBs in the write queue."
We certainly can have SYN/SYNACKs in write queue but not in certain
states, and consequently, not in certain functions.
--
i.
^ permalink raw reply
* Re: [PATCH] net: fix mdio section mismatch warning
From: David Miller @ 2009-11-17 12:06 UTC (permalink / raw)
To: sfr; +Cc: netdev, laurentp, paulius.zaleckas, mware
In-Reply-To: <20091117194733.bd2308a8.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 17 Nov 2009 19:47:33 +1100
> This fixes the following warning:
>
> WARNING: drivers/net/phy/built-in.o(.devexit.text+0x70): Section mismatch in reference from the function .mdio_gpio_bus_destroy() to the function .devinit.text:.mdio_gpio_bus_deinit()
> The function __devexit .mdio_gpio_bus_destroy() references
> a function __devinit .mdio_gpio_bus_deinit().
> This is often seen when error handling in the exit function
> uses functionality in the init path.
> The fix is often to remove the __devinit annotation of
> .mdio_gpio_bus_deinit() so it may be used outside an init section.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied to net-2.6, thanks Stephen.
I wish there was a better way to handle this kind of situation as it's
a quite common pattern (exit cleanup function used by device init
functions) because currently we end up not being able to put such
things into either init or exit sections.
^ permalink raw reply
* Re: [PATCH 1/5]net: PPP buffer too small for higher speed connections
From: Franko Fang @ 2009-11-17 12:04 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, william.allen.simpson, jarkao2
In-Reply-To: <20091117.040234.245024359.davem@davemloft.net>
Well, that's great.
Thanks very much for your help.
----- Original Message -----
From: "David Miller" <davem@davemloft.net>
To: <huananhu@huawei.com>
Cc: <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>; <william.allen.simpson@gmail.com>; <jarkao2@gmail.com>
Sent: Tuesday, November 17, 2009 8:02 PM
Subject: Re: [PATCH 1/5]net: PPP buffer too small for higher speed connections
> From: fangxiaozhi 00110321 <huananhu@huawei.com>
> Date: Tue, 17 Nov 2009 19:59:05 +0800
>
>> From: fangxiaozhi <huananhu@huawei.com>
>> 1. This patch is based on the kernel of 2.6.32-rc7
>> 2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
>> Signed-off-by: fangxiaozhi <huananhu@huawei.com>
>
> Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 1/5]net: PPP buffer too small for higher speed connections
From: David Miller @ 2009-11-17 12:02 UTC (permalink / raw)
To: huananhu; +Cc: netdev, linux-kernel, william.allen.simpson, jarkao2
In-Reply-To: <fb8cc3511cffa.1cffafb8cc351@huawei.com>
From: fangxiaozhi 00110321 <huananhu@huawei.com>
Date: Tue, 17 Nov 2009 19:59:05 +0800
> From: fangxiaozhi <huananhu@huawei.com>
> 1. This patch is based on the kernel of 2.6.32-rc7
> 2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
> Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: net-next-2.6 compilation errors: missing wireless/i82593.h
From: William Allen Simpson @ 2009-11-17 11:59 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, linville
In-Reply-To: <20091117.034428.47467823.davem@davemloft.net>
David Miller wrote:
> From: William Allen Simpson <william.allen.simpson@gmail.com>
> Date: Tue, 17 Nov 2009 06:34:15 -0500
>
>> For the past 9-10 days, net-next-2.6 has failed to compile. In
>> addition to the errors and warnings already reported here last week,
>
> Those seemed to be for Android drivers and such, so I hope you
> reported those failures to the driver maintainers as well as
> linux-kernel.
>
I did, at least some of them. Nothing seems to have been fixed yet.
> For the time being could you just disable those drivers in your
> build just to get work done or do you absolutely need them?
>
I did, at least some of them. Of course, since I'm making changes to
linux/tcp.h and net/tcp.h, an awful lot of drivers seem to include them
one way or another, and I'm trying to ensure nothing breaks (at least
for compilation purposes).
>> since Nov 12th there has been another missing file. I kept hoping
>> it was temporary, but no joy.
>>
>> /home/administer/net-next-2.6/drivers/net/znet.c:107:29: error:
>> wireless/i82593.h: No such file or directory
>
> That header file got moved out to drivers/staging along with the
> wavelan driver.
>
Too bad that CONFIG_STAGING "N" (# CONFIG_STAGING is not set) doesn't
actually turn off all the staging....
> John please fix this up, thanks!
>
Please.
^ permalink raw reply
* [PATCH 1/5]net: PPP buffer too small for higher speed connections
From: fangxiaozhi 00110321 @ 2009-11-17 11:59 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, william.allen.simpson, jarkao2
From: fangxiaozhi <huananhu@huawei.com>
1. This patch is based on the kernel of 2.6.32-rc7
2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
-----------------------------------------------------------------------------------------
--- a/drivers/net/ppp_async.c 2009-10-12 05:43:56.000000000 +0800
+++ b/drivers/net/ppp_async.c 2009-10-15 16:29:56.000000000 +0800
@@ -36,7 +36,7 @@
#define PPP_VERSION "2.4.2"
-#define OBUFSIZE 256
+#define OBUFSIZE 4096
/* Structure for storing local state. */
struct asyncppp {
******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
immediately and delete it!
*****************************************************************************************
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: Franko Fang @ 2009-11-17 11:54 UTC (permalink / raw)
To: Jarek Poplawski, William Allen Simpson; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <20091117111454.GA8341@ff.dom.local>
Well, yes, I think that it misses the tab.
I will update the patch, and resubmit it again.
Thanks for all .
----- Original Message -----
From: "Jarek Poplawski" <jarkao2@gmail.com>
To: "William Allen Simpson" <william.allen.simpson@gmail.com>
Cc: <huananhu@huawei.com>; "David Miller" <davem@davemloft.net>; <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org>
Sent: Tuesday, November 17, 2009 7:14 PM
Subject: Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
> On 17-11-2009 11:20, William Allen Simpson wrote:
>> David Miller wrote:
>>> Your patch is broken, please don't wate my time like this.
>>>
>>> + git apply --check --whitespace=error-all diff
>>> error: patch failed: drivers/net/ppp_async.c:36
>>> error: drivers/net/ppp_async.c: patch does not apply
>>>
>> What David may have meant, had he followed Documentation/ManagementStyle
>> or had any project management skills what-so-ever, is that you need to
>> follow Documentation/SubmittingPatches more carefully.
>
> I think this time it was only about a missing tab ;-)
>
> Jarek P.
>
>>
>> Look at 15) The canonical patch format
>>
>> [PATCH 17/11] makes no sense, you don't have 11 patches, and the 17th
>> patch of 11 can never exist.
>>
>> Need a better "subsystem: summary phrase", perhaps
>> "net: PPP buffer too small for higher speed connections"
>>
>> A marker line containing simply "---".
>>
>> And your trailer boilerplate badly breaks the system, because it's
>> missing the SMTP email standard "--" line in front of it.
>>
>> You'll get nicer formatting with 'git format-patch -o ~ HEAD~1' after you
>> do a 'git commit -a' on your git tree.
>>
>> It takes some time, even for a simple 1 line fix like this....
>>
>> Hope that helps.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ 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