* Re: [PATCH] via-velocity: Codestyle fixes
From: Bob Beers @ 2010-10-28 14:34 UTC (permalink / raw)
To: alex; +Cc: netdev, linux-kernel
In-Reply-To: <1288242011-32257-1-git-send-email-alex@wigen.net>
On Thu, Oct 28, 2010 at 1:00 AM, <alex@wigen.net> wrote:
> From: Alexander Wigen <alex@wigen.net>
> static void mac_wol_reset(struct mac_regs __iomem *regs)
> @@ -342,7 +342,7 @@ VELOCITY_PARAM(ValPktLen, "Receiving or Drop invalid 802.3 frame");
> 1: Wake up if link status is on/off.
> 2: Wake up if recevied an arp packet.
> 4: Wake up if recevied any unicast packet.
> - Those value can be sumed up to support more than one option.
> + Those value can be summed up to support more than one option.
> */
> VELOCITY_PARAM(wol_opts, "Wake On Lan options");
>
my $.02 ...
s/recevied/receive/ x2
s/These values can be summed/Those value can be summed up/
-Bob Beers
^ permalink raw reply
* Re: [Bugme-new] [Bug 20772] New: ip= nfsaddrs= stopped working
From: Chuck Lever @ 2010-10-28 14:32 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon, mpetersen
In-Reply-To: <20101027223103.GA10484@verge.net.au>
On Oct 27, 2010, at 6:31 PM, Simon Horman wrote:
> On Tue, Oct 19, 2010 at 12:09:38PM -0700, Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Tue, 19 Oct 2010 18:20:15 GMT
>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=20772
>>>
>>> Summary: ip= nfsaddrs= stopped working
>>> Product: Networking
>>> Version: 2.5
>>> Kernel Version: 2.6.33, 2.6.32, 2.6.26
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: high
>>> Priority: P1
>>> Component: IPV4
>>> AssignedTo: shemminger@linux-foundation.org
>>> ReportedBy: mpetersen@peak6.com
>>> Regression: Yes
>>>
>>>
>>> I can no longer set a static IP address using either ip= or nfsaddr=,
>>> ie ip=192.168.0.42:192.168.0.69:255.255.255.0:testhost:eth0:none has no
>>> effect, and DHCP is still attempted.
>>>
>>> Even if I undefine IP_PNP_DHCP IP_PNP_BOOTP and IP_PNP_RARP in the
>>> config (but leave IP_PNP,) the kernel seems to ignore the static IP
>>> settings and try to get a an IP address with DHCP somehow.
>
> Hi,
>
> I believe that the problem is that there is a minor syntax error in the
> configuration parameter. Specifically there should be two colons between
> 192.168.0.69 and 255.255.255.0 or between 192.168.0.42 and 192.168.0.69.
>
> As it stands the settings are:
>
> my address 192.168.0.42
> server address 192.168.0.69
> gateway 255.255.255.0
> netmask testhost
> hostname eth0
> interface none
>
> I believe it is the interface=none that is killing any IP configuration
> by the kernel as no such interface exists.
Did "interface=none" work in 2.6.36 and earlier?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [Bugme-new] [Bug 20772] New: ip= nfsaddrs= stopped working
From: Chuck Lever @ 2010-10-28 14:51 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon, mpetersen
In-Reply-To: <17D7A64D-B275-43EB-AE42-6CA3E65ABCA1@oracle.com>
On Oct 28, 2010, at 10:32 AM, Chuck Lever wrote:
>
> On Oct 27, 2010, at 6:31 PM, Simon Horman wrote:
>
>> On Tue, Oct 19, 2010 at 12:09:38PM -0700, Andrew Morton wrote:
>>>
>>> (switched to email. Please respond via emailed reply-to-all, not via the
>>> bugzilla web interface).
>>>
>>> On Tue, 19 Oct 2010 18:20:15 GMT
>>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=20772
>>>>
>>>> Summary: ip= nfsaddrs= stopped working
>>>> Product: Networking
>>>> Version: 2.5
>>>> Kernel Version: 2.6.33, 2.6.32, 2.6.26
>>>> Platform: All
>>>> OS/Version: Linux
>>>> Tree: Mainline
>>>> Status: NEW
>>>> Severity: high
>>>> Priority: P1
>>>> Component: IPV4
>>>> AssignedTo: shemminger@linux-foundation.org
>>>> ReportedBy: mpetersen@peak6.com
>>>> Regression: Yes
>>>>
>>>>
>>>> I can no longer set a static IP address using either ip= or nfsaddr=,
>>>> ie ip=192.168.0.42:192.168.0.69:255.255.255.0:testhost:eth0:none has no
>>>> effect, and DHCP is still attempted.
>>>>
>>>> Even if I undefine IP_PNP_DHCP IP_PNP_BOOTP and IP_PNP_RARP in the
>>>> config (but leave IP_PNP,) the kernel seems to ignore the static IP
>>>> settings and try to get a an IP address with DHCP somehow.
>>
>> Hi,
>>
>> I believe that the problem is that there is a minor syntax error in the
>> configuration parameter. Specifically there should be two colons between
>> 192.168.0.69 and 255.255.255.0 or between 192.168.0.42 and 192.168.0.69.
>>
>> As it stands the settings are:
>>
>> my address 192.168.0.42
>> server address 192.168.0.69
>> gateway 255.255.255.0
>> netmask testhost
>> hostname eth0
>> interface none
>>
>> I believe it is the interface=none that is killing any IP configuration
>> by the kernel as no such interface exists.
>
> Did "interface=none" work in 2.6.36 and earlier?
OK, I see that's a dumb question.
I made changes to this area of code in 2.6.37. I was responding to the bug report above, and not Simon's observation that there was possibly a syntax error.
Sorry for the noise.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* [PATCH] pktgen: Limit how much data we copy onto the stack.
From: Nelson Elhage @ 2010-10-28 15:20 UTC (permalink / raw)
To: David S. Miller
Cc: Eric Dumazet, Robert Olsson, Andy Shevchenko, netdev, Eugene Teo,
Nelson Elhage
In-Reply-To: <1288206788-21063-1-git-send-email-nelhage@ksplice.com>
A program that accidentally writes too much data to the pktgen file can overflow
the kernel stack and oops the machine. This is only triggerable by root, so
there's no security issue, but it's still an unfortunate bug.
printk() won't print more than 1024 bytes in a single call, anyways, so let's
just never copy more than that much data. We're on a fairly shallow stack, so
that should be safe even with CONFIG_4KSTACKS.
Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
---
While testing Dan's patch, I realized the printk() limitation, so I don't think
there's any reason to need a kmalloc() at all. I've tested this on a
CONFIG_4KSTACKS kernel, and copying 1k works fine.
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 10a1ea7..d6667cf 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -889,10 +889,11 @@ static ssize_t pktgen_if_write(struct file *file,
i += len;
if (debug) {
- char tb[count + 1];
- if (copy_from_user(tb, user_buffer, count))
+ size_t copy = min(count, 1023);
+ char tb[copy + 1];
+ if (copy_from_user(tb, user_buffer, copy))
return -EFAULT;
- tb[count] = 0;
+ tb[copy] = 0;
printk(KERN_DEBUG "pktgen: %s,%lu buffer -:%s:-\n", name,
(unsigned long)count, tb);
}
--
1.7.1.31.g6297e
^ permalink raw reply related
* Re: [patch v3] fix stack overflow in pktgen_if_write()
From: Nelson Elhage @ 2010-10-28 15:22 UTC (permalink / raw)
To: Dan Carpenter
Cc: Eric Dumazet, David S. Miller, Robert Olsson, Andy Shevchenko,
netdev
In-Reply-To: <20101028060529.GX6062@bicker>
You've got a leak if copy_user fails.
While testing this, I realized that printk() won't print more than 1k in a
single call, anyways, so I've sent along a patch that just copies up to 1k onto
the stack, which should prevent the overflow without changing behavior or
needing a heap allocation.
- Nelson
On Thu, Oct 28, 2010 at 08:05:29AM +0200, Dan Carpenter wrote:
> Nelson Elhage says he was able to oops both amd64 and i386 test
> machines with 8k writes to the pktgen file. Let's just allocate the
> buffer on the heap instead of on the stack.
>
> This can only be triggered by root so there are no security issues here.
>
> Reported-by: Nelson Elhage <nelhage@ksplice.com>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> v3: just use kmalloc()
>
> diff --git a/net/core/pktgen.c b/net/core/pktgen.c
> index 2c0df0f..c8d3620 100644
> --- a/net/core/pktgen.c
> +++ b/net/core/pktgen.c
> @@ -887,12 +887,17 @@ static ssize_t pktgen_if_write(struct file *file,
> i += len;
>
> if (debug) {
> - char tb[count + 1];
> + char *tb;
> +
> + tb = kmalloc(count + 1, GFP_KERNEL);
> + if (!tb)
> + return -ENOMEM;
> if (copy_from_user(tb, user_buffer, count))
> return -EFAULT;
> tb[count] = 0;
> printk(KERN_DEBUG "pktgen: %s,%lu buffer -:%s:-\n", name,
> (unsigned long)count, tb);
> + kfree(tb);
> }
>
> if (!strcmp(name, "min_pkt_size")) {
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Shirley Ma @ 2010-10-28 15:24 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <20101028052021.GD5599@redhat.com>
On Thu, 2010-10-28 at 07:20 +0200, Michael S. Tsirkin wrote:
> My concern is this can delay signalling for unlimited time.
> Could you pls test this with guests that do not have
> 2b5bbe3b8bee8b38bdc27dd9c0270829b6eb7eeb
> b0c39dbdc204006ef3558a66716ff09797619778
> that is 2.6.31 and older?
I will test it out.
> This seems to be slighltly out of spec, even though
> for TX, signals are less important.
> Two ideas:
> 1. How about writing out used, just delaying the signal?
> This way we don't have to queue separately.
> 2. How about flushing out queued stuff before we exit
> the handle_tx loop? That would address most of
> the spec issue.
I will modify the patch to test out the performance for both 1 & 2
approaches.
Thanks
Shirley
^ permalink raw reply
* Re: [Security] TIPC security issues
From: Linus Torvalds @ 2010-10-28 15:32 UTC (permalink / raw)
To: David Miller, Andy Grover
Cc: jon.maloy, netdev, drosenberg, security, allan.stephens
In-Reply-To: <20101027.122757.98903207.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]
Heh. We apparently have _another_ iovec overflow in networking. This time rds.
Reported by Thomas Pollet <thomas.pollet@gmail.com>: look at
net/rds/rdma.c around line 490. It doesn't use the regular iovec code,
instead it cooks its own, and has a few problems with overflow.
It gathers the number of pages into an "unsigned int", and for each
entry in its own rds_iovec it will check that the size is < UINT_MAX,
and then generate the number of pages for that entry. With the whole
"unaligned address adds one" logic, it means that each entry can get
(UINT_MAX >> PAGE_SHIFT)+1 pages.
And how many entries can we have? Apparently that is capped to
UINT_MAX too. So add all those up, and they can easily overflow the
unsigned int page counter.
So this time fixing verify_iovec() doesn't help, because rds just
cooks its own, and this is using a totally different interface: it
seems to hook into sendmsg, but it looks like it uses the ancillary
data objects and passes in its own magical iovec rather than use any
"normal" iovec thing. I don't know the code, I may be totally off.
Attached is a half-arsed patch. I say "half-arsed" because I think it
fixes one thing, but I haven't looked at any other use. And quite
frankly, even the one thing it fixes is totally broken: the iovec is
left in user space, so there are all those crazy race-conditions where
another thread in user space can _change_ the rds_iovec after we have
counted the pages, and now the page count is totally wrong.
So the code is just an unmitigated disaster from any standpoint. My
patch - if it works - makes it slightly better. But I'd suggest
disabling RDS in any sane setup.
This was the same subsystem that totally didn't check the user
addresses at all, after all. So there are probably tons of other bugs
lurking.
Btw: patch is totally untested. I haven't even compiled it. So take it
with a pinch of salt.
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1306 bytes --]
From: Linus Torvalds <torvalds@linux-foundation.org>
Subject: net: fix rds_iovec page count overflow
As reported by Thomas Pollet, the rdma page counting can overflow. We
get the rdma sizes in 64-bit unsigned entities, but then limit it to
UINT_MAX bytes and shift them down to pages (so with a possible "+1" for
an unaligned address).
So each individual page count fits comfortably in an 'unsigned int' (not
even close to overflowing into signed), but as they are added up, they
might end up resulting in a signed return value. Which would be wrong.
Catch the case of tot_pages turning negative, and return the appropriate
error code.
Reported-by: Thomas Pollet <thomas.pollet@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
net/rds/rdma.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/net/rds/rdma.c b/net/rds/rdma.c
index 1a41deb..0df02c8 100644
--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -502,6 +502,13 @@ static int rds_rdma_pages(struct rds_rdma_args *args)
return -EINVAL;
tot_pages += nr_pages;
+
+ /*
+ * nr_pages for one entry is limited to (UINT_MAX>>PAGE_SHIFT)+1,
+ * so tot_pages cannot overflow without first going negative.
+ */
+ if ((int)tot_pages < 0)
+ return -EINVAL;
}
return tot_pages;
^ permalink raw reply related
* [PATCH] phy/marvell: rename 88ec048 to 88e1318s and fix mscr1 addr
From: Cyril Chemparathy @ 2010-10-28 15:35 UTC (permalink / raw)
To: netdev; +Cc: Cyril Chemparathy
The marvell 88ec048's official part number is 88e1318s. This patch renames
definitions in the driver to reflect this.
In addition, a minor bug fix has been added to write back the MSCR1 register
value properly.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
---
drivers/net/phy/marvell.c | 18 +++++++++---------
include/linux/marvell_phy.h | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 0101f2b..e6ef44c 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -74,8 +74,8 @@
#define MII_88E1121_PHY_MSCR_TX_DELAY BIT(4)
#define MII_88E1121_PHY_MSCR_DELAY_MASK (~(0x3 << 4))
-#define MII_88EC048_PHY_MSCR1_REG 16
-#define MII_88EC048_PHY_MSCR1_PAD_ODD BIT(6)
+#define MII_88E1318S_PHY_MSCR1_REG 16
+#define MII_88E1318S_PHY_MSCR1_PAD_ODD BIT(6)
#define MII_88E1121_PHY_LED_CTRL 16
#define MII_88E1121_PHY_LED_PAGE 3
@@ -233,7 +233,7 @@ static int m88e1121_config_aneg(struct phy_device *phydev)
return err;
}
-static int m88ec048_config_aneg(struct phy_device *phydev)
+static int m88e1318_config_aneg(struct phy_device *phydev)
{
int err, oldpage, mscr;
@@ -244,10 +244,10 @@ static int m88ec048_config_aneg(struct phy_device *phydev)
if (err < 0)
return err;
- mscr = phy_read(phydev, MII_88EC048_PHY_MSCR1_REG);
- mscr |= MII_88EC048_PHY_MSCR1_PAD_ODD;
+ mscr = phy_read(phydev, MII_88E1318S_PHY_MSCR1_REG);
+ mscr |= MII_88E1318S_PHY_MSCR1_PAD_ODD;
- err = phy_write(phydev, MII_88E1121_PHY_MSCR_REG, mscr);
+ err = phy_write(phydev, MII_88E1318S_PHY_MSCR1_REG, mscr);
if (err < 0)
return err;
@@ -652,12 +652,12 @@ static struct phy_driver marvell_drivers[] = {
.driver = { .owner = THIS_MODULE },
},
{
- .phy_id = MARVELL_PHY_ID_88EC048,
+ .phy_id = MARVELL_PHY_ID_88E1318S,
.phy_id_mask = MARVELL_PHY_ID_MASK,
- .name = "Marvell 88EC048",
+ .name = "Marvell 88E1318S",
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
- .config_aneg = &m88ec048_config_aneg,
+ .config_aneg = &m88e1318_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index d0f0801..1ff81b5 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -12,7 +12,7 @@
#define MARVELL_PHY_ID_88E1121R 0x01410cb0
#define MARVELL_PHY_ID_88E1145 0x01410cd0
#define MARVELL_PHY_ID_88E1240 0x01410e30
-#define MARVELL_PHY_ID_88EC048 0x01410e90
+#define MARVELL_PHY_ID_88E1318S 0x01410e90
/* struct phy_device dev_flags definitions */
#define MARVELL_PHY_M1145_FLAGS_RESISTANCE 0x00000001
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ip_gre: fix percpu stats accounting
From: Pavel Emelyanov @ 2010-10-28 16:07 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Linux Netdev List
commit e985aad7 (ip_gre: percpu stats accounting) forgot the fallback
tunnel case (gre0).
This is the 4th part of the "foo: fix percpu stats accounting" series ;)
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 01087e0..be05d5b 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -1321,7 +1321,7 @@ static int ipgre_tunnel_init(struct net_device *dev)
return 0;
}
-static void ipgre_fb_tunnel_init(struct net_device *dev)
+static int ipgre_fb_tunnel_init(struct net_device *dev)
{
struct ip_tunnel *tunnel = netdev_priv(dev);
struct iphdr *iph = &tunnel->parms.iph;
@@ -1335,8 +1335,13 @@ static void ipgre_fb_tunnel_init(struct net_device *dev)
iph->ihl = 5;
tunnel->hlen = sizeof(struct iphdr) + 4;
+ dev->tstats = alloc_percpu(struct pcpu_tstats);
+ if (!dev->tstats)
+ return -ENOMEM;
+
dev_hold(dev);
rcu_assign_pointer(ign->tunnels_wc[0], tunnel);
+ return 0;
}
@@ -1377,7 +1382,10 @@ static int __net_init ipgre_init_net(struct net *net)
}
dev_net_set(ign->fb_tunnel_dev, net);
- ipgre_fb_tunnel_init(ign->fb_tunnel_dev);
+ err = ipgre_fb_tunnel_init(ign->fb_tunnel_dev);
+ if (err)
+ goto err_reg_dev;
+
ign->fb_tunnel_dev->rtnl_link_ops = &ipgre_link_ops;
if ((err = register_netdev(ign->fb_tunnel_dev)))
@@ -1386,7 +1394,7 @@ static int __net_init ipgre_init_net(struct net *net)
return 0;
err_reg_dev:
- free_netdev(ign->fb_tunnel_dev);
+ ipgre_dev_free(ign->fb_tunnel_dev);
err_alloc_dev:
return err;
}
^ permalink raw reply related
* Re: [patch v3] fix stack overflow in pktgen_if_write()
From: Dan Carpenter @ 2010-10-28 16:28 UTC (permalink / raw)
To: Nelson Elhage
Cc: Eric Dumazet, David S. Miller, Robert Olsson, Andy Shevchenko,
netdev
In-Reply-To: <20101028152222.GU16803@ksplice.com>
On Thu, Oct 28, 2010 at 11:22:22AM -0400, Nelson Elhage wrote:
> You've got a leak if copy_user fails.
>
My QC scripts should have caught that, but they didn't... I'll figure
it out. It shouldn't happen again.
> While testing this, I realized that printk() won't print more than 1k in a
> single call, anyways, so I've sent along a patch that just copies up to 1k onto
> the stack, which should prevent the overflow without changing behavior or
> needing a heap allocation.
>
Ok. Good to hear. Sorry I wasted people's time.
regards,
dan carpenter
^ permalink raw reply
* Re: Future of the Wimedia LLC Protocol (WLP) subsystem/drivers
From: David Miller @ 2010-10-28 16:29 UTC (permalink / raw)
To: greg; +Cc: randy.dunlap, david.vrabel, netdev
In-Reply-To: <20101020192233.GA8912@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Wed, 20 Oct 2010 12:22:33 -0700
> On Wed, Oct 20, 2010 at 09:15:41AM -0700, Randy Dunlap wrote:
>> On Tue, 19 Oct 2010 17:30:47 +0100 David Vrabel wrote:
>>
>> > Hi,
>> >
>> > I've have been nominally the maintainer of the Wimedia LLC Protocol
>> > (WLP) subsystem and driver since it was originally submitted. I am no
>> > longer in a position to even pretend to be a maintainer.
>> >
>> > The only usable hardware was an Intel i1480 devices with beta firmware
>> > that was never released as a product. Intel have since sold all there
>> > UWB/WLP IP and I see little prospect of there ever being hardware
>> > commercially available for WLP.
>> >
>> > Here are a number of options:
>> >
>> > 1. Someone else maintains it. Any volunteers?
>> >
>> > 2. It gets labelled as Orphaned in MAINTAINERS.
>> >
>> > 3. It gets moved to staging.
>> >
>> > 4, It gets removed.
>> >
>> > If no one says anything I'll submit a patch to Linus to mark it as Orphaned.
>>
>> I'd say either 3 or 4.
>>
>> It could go to staging on it way to removal, but that's not really necessary.
>>
>>
>> cc: gregkh
>
> 3 or 4 is fine with me, which ever David wants.
I'm fine with either but prefer 4, if we want to resurrect the code
for whatever reason it is there in the history and we can just revert
the revert commit to get it all back.
^ permalink raw reply
* Re: [patch v3] fix stack overflow in pktgen_if_write()
From: Nelson Elhage @ 2010-10-28 16:30 UTC (permalink / raw)
To: Dan Carpenter
Cc: Eric Dumazet, David S. Miller, Robert Olsson, Andy Shevchenko,
netdev
In-Reply-To: <20101028162825.GG6062@bicker>
On Thu, Oct 28, 2010 at 06:28:25PM +0200, Dan Carpenter wrote:
> On Thu, Oct 28, 2010 at 11:22:22AM -0400, Nelson Elhage wrote:
> > You've got a leak if copy_user fails.
> >
>
> My QC scripts should have caught that, but they didn't... I'll figure
> it out. It shouldn't happen again.
>
> > While testing this, I realized that printk() won't print more than 1k in a
> > single call, anyways, so I've sent along a patch that just copies up to 1k onto
> > the stack, which should prevent the overflow without changing behavior or
> > needing a heap allocation.
> >
>
> Ok. Good to hear. Sorry I wasted people's time.
No worries. I appreciate you jumping in to help, even if it looks like the
approach wasn't needed in the end.
- Nelson
>
> regards,
> dan carpenter
>
>
^ permalink raw reply
* Re: [PATCH] ip_gre: fix percpu stats accounting
From: Eric Dumazet @ 2010-10-28 16:33 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List
In-Reply-To: <4CC99FDC.9070102@parallels.com>
Le jeudi 28 octobre 2010 à 20:07 +0400, Pavel Emelyanov a écrit :
> commit e985aad7 (ip_gre: percpu stats accounting) forgot the fallback
> tunnel case (gre0).
>
> This is the 4th part of the "foo: fix percpu stats accounting" series ;)
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
Indeed, right you are ;)
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Anyway, I suspect more work is needed...
(check patch against ixgbe : http://patchwork.ozlabs.org/patch/69458/ )
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Shirley Ma @ 2010-10-28 17:14 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <20101028052021.GD5599@redhat.com>
> Two ideas:
> 1. How about writing out used, just delaying the signal?
> This way we don't have to queue separately.
This improves some performance, but not as good as delaying
both used and signal. Since delaying used buffers combining
multiple small copies to a large copy, which saves more CPU
utilization and increased some BW.
> 2. How about flushing out queued stuff before we exit
> the handle_tx loop? That would address most of
> the spec issue.
The performance is almost as same as the previous patch. I will resubmit
the modified one, adding vhost_add_used_and_signal_n after handle_tx
loop for processing pending queue.
This patch was a part of modified macvtap zero copy which I haven't
submitted yet. I found this helped vhost TX in general. This pending
queue will be used by DMA done later, so I put it in vq instead of a
local variable in handle_tx.
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] Fix missing dependency of PCH_GBE driver
From: David Miller @ 2010-10-28 17:16 UTC (permalink / raw)
To: rostedt; +Cc: linux-kernel, netdev, error27, masa-korg, akpm
In-Reply-To: <1288268189.18238.173.camel@gandalf.stny.rr.com>
From: Steven Rostedt <rostedt@goodmis.org>
Date: Thu, 28 Oct 2010 08:16:29 -0400
> While doing some randconfigs I stumbled across this build error:
>
> ERROR: "mii_ethtool_gset" [drivers/net/pch_gbe/pch_gbe.ko] undefined!
> ERROR: "generic_mii_ioctl" [drivers/net/pch_gbe/pch_gbe.ko] undefined!
> ERROR: "mii_nway_restart" [drivers/net/pch_gbe/pch_gbe.ko] undefined!
> ERROR: "mii_check_gmii_support" [drivers/net/pch_gbe/pch_gbe.ko] undefined!
> ERROR: "mii_link_ok" [drivers/net/pch_gbe/pch_gbe.ko] undefined!
> ERROR: "mii_ethtool_sset" [drivers/net/pch_gbe/pch_gbe.ko] undefined!
>
> The config option PCH_GBE is missing the dependency of MII.
>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
The canonical way to handle this is to use 'select'. Thus,
I've committed the following to fix this.
Thanks.
--------------------
pch_gbe: Select MII.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 77c1fab..f24179d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2520,6 +2520,7 @@ source "drivers/net/stmmac/Kconfig"
config PCH_GBE
tristate "PCH Gigabit Ethernet"
depends on PCI
+ select MII
---help---
This is a gigabit ethernet driver for Topcliff PCH.
Topcliff PCH is the platform controller hub that is used in Intel's
--
1.7.3.2
^ permalink raw reply related
* Re: [net-2.6 PATCH] ixgb: call pci_disable_device in ixgb_remove
From: David Miller @ 2010-10-28 17:19 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, bhutchings, emil.s.tantilov
In-Reply-To: <20101028105949.27748.82780.stgit@localhost6.localdomain6>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 28 Oct 2010 03:59:49 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> ixgb fails to work after reload on recent kernels:
>
> rmmod ixgb (dev->current_state = PCI_UNKNOWN)
> modprobe ixgb (pci_enable_device will bail leaving current_state to PCI_UNKNOWN)
> ifup eth0
> do_IRQ: 2.82 No irq handler for vector (irq -1)
>
> The issue was exposed by commit fcd097f31a6ee207cc0c3da9cccd2a86d4334785
> PCI: MSI: Remove unsafe and unnecessary hardware access
>
> which avoids HW writes for power states != PCI_D0
>
> CC: Ben Hutchings <bhutchings@solarflare.com>
> 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>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] igbvf: fix panic on load
From: David Miller @ 2010-10-28 17:20 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, emil.s.tantilov, greg.v.rose
In-Reply-To: <20101028105951.27748.36868.stgit@localhost6.localdomain6>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 28 Oct 2010 03:59:51 -0700
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Introduced by commit:e6484930d7c73d324bccda7d43d131088da697b9
> net: allocate tx queues in register_netdevice
>
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Acked-by: Greg Rose <greg.v.rose@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000e: reset PHY after errors detected
From: David Miller @ 2010-10-28 17:20 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: netdev, gospo, bphilips, jesse.brandeburg, carolyn.wyborny
In-Reply-To: <20101028105953.27748.5285.stgit@localhost6.localdomain6>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 28 Oct 2010 03:59:53 -0700
> From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>
> Some errors can be induced in the PHY via environmental testing
> (specifically extreme temperature changes and electro static
> discharge testing), and in the case of the PHY hanging due to
> this input, this detects the problem and resets to continue.
> This issue only applies to 82574 silicon.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000e: Add check for reset flags before displaying reset message
From: David Miller @ 2010-10-28 17:20 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, carolyn.wyborny, bruce.w.allan
In-Reply-To: <20101028105955.27748.92516.stgit@localhost6.localdomain6>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 28 Oct 2010 03:59:55 -0700
> From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>
> Some parts need to execute resets during normal operation. This flag
> check ensures that those parts reset without needlessly alarming the
> user. Other unexpected resets by other parts will dump debug info
> and message the reset action to the user, as originally intended.
>
> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH] ixgbe: DCB, fix TX hang occurring in stress condition with PFC
From: David Miller @ 2010-10-28 17:20 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, john.r.fastabend
In-Reply-To: <20101028105957.27748.39154.stgit@localhost6.localdomain6>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 28 Oct 2010 03:59:57 -0700
> From: John Fastabend <john.r.fastabend@intel.com>
>
> The DCB credits refill quantum _must_ be greater than half the max
> packet size. This is needed to guarantee that TX DMA operations
> are not attempted during a pause state. Additionally, the min IFG
> must be set correctly for DCB mode. If a DMA operation is
> requested unexpectedly during the pause state the HW data
> store may be corrupted leading to a DMA hang. The DMA hang
> requires a reset to correct. This fixes the HW configuration
> to avoid this condition.
>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> Tested-by: Ross Brattain <ross.b.brattain@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: net-next-2.6 [PATCH 0/4] dccp: CCID packet dequeueing interface
From: David Miller @ 2010-10-28 17:28 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <1288242988-5333-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Thu, 28 Oct 2010 07:16:24 +0200
> The set has also been placed into a fresh (today's) copy of net-next-2.6, on
>
> git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
>
> The set is fully bisectable.
All applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH] cxgb3: fix crash due to manipulating queues before registration
From: David Miller @ 2010-10-28 17:28 UTC (permalink / raw)
To: nacc; +Cc: eric.dumazet, sonnyrao, divy, dm, netdev, linux-kernel
In-Reply-To: <20101028052349.GA21144@us.ibm.com>
From: Nishanth Aravamudan <nacc@us.ibm.com>
Date: Wed, 27 Oct 2010 22:23:49 -0700
> On 28.10.2010 [07:18:30 +0200], Eric Dumazet wrote:
>> Le mercredi 27 octobre 2010 à 22:06 -0700, Nishanth Aravamudan a écrit :
>> > Hi Eric,
>> >
>> > Something like the following?:
>> >
>> > Thanks,
>> > Nish
>>
>> Yes, probably, but I dont have the hardware so cannot test.
>
> Sorry, should have been clearer. I do have the hardware, tested with the
> patch, it does work. Wanted to make sure that it made sense to the
> maintainers, of course, but:
>
> Tested-by: Nishanth Aravamudan <nacc@us.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] 8390: Don't oops on starting dev queue
From: David Miller @ 2010-10-28 17:28 UTC (permalink / raw)
To: xemul; +Cc: p_gortmaker, netdev
In-Reply-To: <4CC93BCE.4020303@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Thu, 28 Oct 2010 13:01:02 +0400
> The __NS8390_init tries to start the device queue before the
> device is registered. This results in an oops (snipped):
>
> [ 2.865493] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> [ 2.866106] IP: [<ffffffffa000602a>] netif_start_queue+0xb/0x12 [8390]
> [ 2.881267] Call Trace:
> [ 2.881437] [<ffffffffa000624d>] __NS8390_init+0x102/0x15a [8390]
> [ 2.881999] [<ffffffffa00062ae>] NS8390_init+0x9/0xb [8390]
> [ 2.882237] [<ffffffffa000d820>] ne2k_pci_init_one+0x297/0x354 [ne2k_pci]
> [ 2.882955] [<ffffffff811c7a0e>] local_pci_probe+0x12/0x16
> [ 2.883308] [<ffffffff811c85ad>] pci_device_probe+0xc3/0xef
> [ 2.884049] [<ffffffff8129218d>] driver_probe_device+0xbe/0x14b
> [ 2.884937] [<ffffffff81292260>] __driver_attach+0x46/0x62
> [ 2.885170] [<ffffffff81291788>] bus_for_each_dev+0x49/0x78
> [ 2.885781] [<ffffffff81291fbb>] driver_attach+0x1c/0x1e
> [ 2.886089] [<ffffffff812912ab>] bus_add_driver+0xba/0x227
> [ 2.886330] [<ffffffff8129259a>] driver_register+0x9e/0x115
> [ 2.886933] [<ffffffff811c8815>] __pci_register_driver+0x50/0xac
> [ 2.887785] [<ffffffffa001102c>] ne2k_pci_init+0x2c/0x2e [ne2k_pci]
> [ 2.888093] [<ffffffff81000212>] do_one_initcall+0x7c/0x130
> [ 2.888693] [<ffffffff8106d74f>] sys_init_module+0x99/0x1da
> [ 2.888946] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b
>
> This happens because the netif_start_queue sets respective bit on the dev->_tx
> array which is not yet allocated.
>
> As far as I understand the code removing the netif_start_queue from __NS8390_init
> is OK, since queue will be started later on device open. Plz, correct me if I'm wrong.
>
> Found in the Dave's current tree, so he's in Cc.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH] cxgb3: fix crash due to manipulating queues before registration
From: David Miller @ 2010-10-28 17:28 UTC (permalink / raw)
To: divy; +Cc: nacc, eric.dumazet, sonnyrao, dm, netdev, linux-kernel
In-Reply-To: <4CC919B1.1040602@chelsio.com>
From: Divy Le Ray <divy@chelsio.com>
Date: Wed, 27 Oct 2010 23:35:29 -0700
> On 10/27/2010 10:06 PM, Nishanth Aravamudan wrote:
>> Hi Eric,
>>
>> Something like the following?:
>>
>> Thanks,
>> Nish
>>
>>
>> Along the same lines as "cxgb4: fix crash due to manipulating queues
>> before registration" (8f6d9f40476895571df039b6f1f5230ec7faebad),
>> before
>> commit "net: allocate tx queues in register_netdevice"
>> netif_tx_stop_all_queues and related functions could be used between
>> device allocation and registration but now only after registration.
>> cxgb4 has such a call before registration and crashes now. Move it
>> after register_netdev.
>>
>> Signed-off-by: Nishanth Aravamudan<nacc@us.ibm.com>
>
> Acked-by: Divy Le Ray <divy@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH] fib: Fix fib zone and its hash leak on namespace stop
From: David Miller @ 2010-10-28 17:28 UTC (permalink / raw)
To: xemul; +Cc: netdev
In-Reply-To: <4CC965EB.60600@parallels.com>
From: Pavel Emelyanov <xemul@parallels.com>
Date: Thu, 28 Oct 2010 16:00:43 +0400
> When we stop a namespace we flush the table and free one, but the
> added fn_zone-s (and their hashes if grown) are leaked. Need to free.
> Tries releases all its stuff in the flushing code.
>
> Shame on us - this bug exists since the very first make-fib-per-net
> patches in 2.6.27 :(
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ 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