* [RFC PATCH 0/5] Cache PMTU/redirects in inetpeer
From: David Miller @ 2011-02-10 6:12 UTC (permalink / raw)
To: netdev
This is what I've been working on for the past several days.
Right now if the routing cache is turned off (by setting
rt_cache_rebuild_count to "0") several things stop working.
We never make use of any PMTU or redirect information we learn
via ICMP packets. This is because when the routing cache is
off, we can't "find" the existing cached routes that match
the ICMP because we don't add them to the hash table.
This functionality loss is also a blocker for eliminating the
routing cache entirely.
Solve this by remembering this state in the inetpeer entries.
PMTU information now self-expires. It gets validated when
cached routes are sanity checked via dst_ops->check(). At
expiration, the original RTAX_MTU metric value is restored.
So we don't have to invalidate the entire cached route just
because it's PMTU learned value has expired.
Similarly, we store redirect information in inetpeer too.
Except that currently my patches don't remember the "original"
gateway the route had, so we have to kill the route off when
we get a dst_ops->negative_advice() call on a redirected route.
Avoid this is easy to fix and I might do that soon.
These patches implement the PMTU/redirect bits in ipv4 only at the
moment, but I do have ipv6 patches I'm in the process of finishing
up. I just wanted people to see this as soon as possible so that
I can start getting feedback.
And hey if people can test this stuff out that'd be awesome! If
you've used these changes in an environment where you did hit PMTU
and redirects, please do let me know.
^ permalink raw reply
* Re: [RFC PATCH net-next] net: rename group sysfs entry to netdev_group
From: David Miller @ 2011-02-10 3:16 UTC (permalink / raw)
To: dfeng; +Cc: netdev, eric.dumazet, therbert, ebiederm, shemminger, ddvlad
In-Reply-To: <4D53536B.2010505@redhat.com>
From: Xiaotian Feng <dfeng@redhat.com>
Date: Thu, 10 Feb 2011 10:54:35 +0800
> Subject: [PATCH net-next v2] net: rename group sysfs entry to netdev_group
>
> commit a512b92 adds sysfs entry for net device group, but
> before this commit, tun also uses group sysfs, so after this
> commit checkin, kernel warns like this:
> sysfs: cannot create duplicate filename '/devices/virtual/net/vnet0/group'
>
> Since tun has used this for years, rename sysfs under tun might
> break existing userspace, so rename group sysfs entry for net device
> group is a better choice.
>
> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH net-next] net: rename group sysfs entry to netdev_group
From: Xiaotian Feng @ 2011-02-10 2:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.dumazet, therbert, ebiederm, shemminger, ddvlad
In-Reply-To: <20110209.140558.59676278.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
On 02/10/2011 06:05 AM, David Miller wrote:
> From: David Miller<davem@davemloft.net>
> Date: Wed, 09 Feb 2011 14:03:23 -0800 (PST)
>
>> From: Xiaotian feng<dfeng@redhat.com>
>> Date: Wed, 9 Feb 2011 18:52:49 +0800
>>
>>> From: Xiaotian Feng<dfeng@redhat.com>
>>>
>>> commit a512b92 adds sysfs entry for net device group, but
>>> before this commit, tun also uses group sysfs, so after this
>>> commit checkin, kernel warns like this:
>>> sysfs: cannot create duplicate filename '/devices/virtual/net/vnet0/group'
>>>
>>> Since tun has used this for years, rename sysfs under tun might
>>> break existing userspace, so rename group sysfs entry for net device
>>> group is a better choice.
>>>
>>> Signed-off-by: Xiaotian Feng<dfeng@redhat.com>
>>
>> I don't think we have much choice in this matter, so I have applied
>> this patch, thanks!
>
> Wait, you didn't even build test this patch?!?!?!?!
>
> net/core/net-sysfs.c: In function ‘format_netdev_group’:
> net/core/net-sysfs.c:298: error: ‘const struct net_device’ has no member named ‘netdev_group’
> net/core/net-sysfs.c: At top level:
> net/core/net-sysfs.c:333: error: ‘show_group’ undeclared here (not in a function)
>
> "RFC" doesn't preclude you from at least build testing patches you
> post.
>
> Sigh...
>
Sorry, my bad ... v2 patch is attatched, I've built and r/w this renamed
sysfs, all work fine now. Sorry again about my carelessness ...
Regards
Xiaotian
>
>
[-- Attachment #2: 0001-net-rename-group-sysfs-entry-to-netdev_group.patch --]
[-- Type: text/plain, Size: 1535 bytes --]
>From 35388da8821a72a71f54cb955146a881f916eb25 Mon Sep 17 00:00:00 2001
From: Xiaotian Feng <dfeng@redhat.com>
Date: Thu, 10 Feb 2011 10:48:53 +0800
Subject: [PATCH net-next v2] net: rename group sysfs entry to netdev_group
commit a512b92 adds sysfs entry for net device group, but
before this commit, tun also uses group sysfs, so after this
commit checkin, kernel warns like this:
sysfs: cannot create duplicate filename '/devices/virtual/net/vnet0/group'
Since tun has used this for years, rename sysfs under tun might
break existing userspace, so rename group sysfs entry for net device
group is a better choice.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Tom Herbert <therbert@google.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Vlad Dogaru <ddvlad@rosedu.org>
---
net/core/net-sysfs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index 2e4a393..5ceb257 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -330,7 +330,7 @@ static struct device_attribute net_class_attributes[] = {
__ATTR(flags, S_IRUGO | S_IWUSR, show_flags, store_flags),
__ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len,
store_tx_queue_len),
- __ATTR(group, S_IRUGO | S_IWUSR, show_group, store_group),
+ __ATTR(netdev_group, S_IRUGO | S_IWUSR, show_group, store_group),
{}
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] virtio-net: add schedule check to napi_enable call in refill_work
From: Bruce Rogers @ 2011-02-10 2:44 UTC (permalink / raw)
To: virtualization, Rusty Russell; +Cc: netdev
In-Reply-To: <201102101201.19656.rusty@rustcorp.com.au>
>>> On 2/9/2011 at 06:31 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Thu, 10 Feb 2011 06:59:25 am Ken Stailey wrote:
>> Justification:
>>
>> Impact: Under heavy network I/O load virtio-net driver crashes making VM
> guest unusable.
>
> Hmm, this went badly wrong. I acked this patch, and it was mailed to
> netdev six months ago.
>
> Bruce's patch used spaces instead of tabs, but that should not have caused
> it to be dropped. I've taken that and ported it forwards, will repost now.
>
> Thanks for picking this up off the floor!
> Rusty.
Thanks for taking care of that!
Bruce
^ permalink raw reply
* [PATCH] virtio_net: Add schedule check to napi_enable call
From: Rusty Russell @ 2011-02-10 2:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David Miller, virtualization, Ken Stailey
From: "Bruce Rogers" <brogers@novell.com>
Under harsh testing conditions, including low memory, the guest would
stop receiving packets. With this patch applied we no longer see any
problems in the driver while performing these tests for extended periods
of time.
Make sure napi is scheduled subsequent to each napi_enable.
Signed-off-by: Bruce Rogers <brogers@novell.com>
Signed-off-by: Olaf Kirch <okir@suse.de>
Cc: stable@kernel.org
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/net/virtio_net.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -446,6 +446,20 @@ static void skb_recv_done(struct virtque
}
}
+static void virtnet_napi_enable(struct virtnet_info *vi)
+{
+ napi_enable(&vi->napi);
+
+ /* If all buffers were filled by other side before we napi_enabled, we
+ * won't get another interrupt, so process any outstanding packets
+ * now. virtnet_poll wants re-enable the queue, so we disable here.
+ * We synchronize against interrupts via NAPI_STATE_SCHED */
+ if (napi_schedule_prep(&vi->napi)) {
+ virtqueue_disable_cb(vi->rvq);
+ __napi_schedule(&vi->napi);
+ }
+}
+
static void refill_work(struct work_struct *work)
{
struct virtnet_info *vi;
@@ -454,7 +468,7 @@ static void refill_work(struct work_stru
vi = container_of(work, struct virtnet_info, refill.work);
napi_disable(&vi->napi);
still_empty = !try_fill_recv(vi, GFP_KERNEL);
- napi_enable(&vi->napi);
+ virtnet_napi_enable(vi);
/* In theory, this can happen: if we don't get any buffers in
* we will *never* try to fill again. */
@@ -638,16 +652,7 @@ static int virtnet_open(struct net_devic
{
struct virtnet_info *vi = netdev_priv(dev);
- napi_enable(&vi->napi);
-
- /* If all buffers were filled by other side before we napi_enabled, we
- * won't get another interrupt, so process any outstanding packets
- * now. virtnet_poll wants re-enable the queue, so we disable here.
- * We synchronize against interrupts via NAPI_STATE_SCHED */
- if (napi_schedule_prep(&vi->napi)) {
- virtqueue_disable_cb(vi->rvq);
- __napi_schedule(&vi->napi);
- }
+ virtnet_napi_enable(vi);
return 0;
}
^ permalink raw reply
* Re: [PATCH] virtio-net: add schedule check to napi_enable call in refill_work
From: Rusty Russell @ 2011-02-10 1:31 UTC (permalink / raw)
To: virtualization; +Cc: Ken Stailey, netdev, Bruce Rogers
In-Reply-To: <132885.30568.qm@web110313.mail.gq1.yahoo.com>
On Thu, 10 Feb 2011 06:59:25 am Ken Stailey wrote:
> Justification:
>
> Impact: Under heavy network I/O load virtio-net driver crashes making VM guest unusable.
Hmm, this went badly wrong. I acked this patch, and it was mailed to
netdev six months ago.
Bruce's patch used spaces instead of tabs, but that should not have caused
it to be dropped. I've taken that and ported it forwards, will repost now.
Thanks for picking this up off the floor!
Rusty.
^ permalink raw reply
* Re: [PATCH] pch_can: fix tseg1/tseg2 setting issue
From: David Miller @ 2011-02-10 0:46 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
toshiharu-linux-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1297298399-6250-1-git-send-email-tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Thu, 10 Feb 2011 09:39:59 +0900
> Previous patch "[PATCH 1/3] pch_can: fix 800k comms issue" is wrong.
> I should have modified tseg1_min not tseg2_min.
> This patch reverts tseg2_min to 1 and set tseg1_min to 2.
>
> Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* [PATCH] pch_can: fix tseg1/tseg2 setting issue
From: Tomoya MORINAGA @ 2011-02-10 0:39 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
toshiharu-linux-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
Previous patch "[PATCH 1/3] pch_can: fix 800k comms issue" is wrong.
I should have modified tseg1_min not tseg2_min.
This patch reverts tseg2_min to 1 and set tseg1_min to 2.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index 7d8bc12..e54712b 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -185,9 +185,9 @@ struct pch_can_priv {
static struct can_bittiming_const pch_can_bittiming_const = {
.name = KBUILD_MODNAME,
- .tseg1_min = 1,
+ .tseg1_min = 2,
.tseg1_max = 16,
- .tseg2_min = 2,
+ .tseg2_min = 1,
.tseg2_max = 8,
.sjw_max = 4,
.brp_min = 1,
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 1/3 v2] pch_can: fix 800k comms issue
From: David Miller @ 2011-02-09 23:57 UTC (permalink / raw)
To: tomoya-linux-ECg8zkTtlr0C6LszWs/t0g
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
toshiharu-linux-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w, wg-5Yr1BZd7O62+XT7JhA+gdA
In-Reply-To: <1297295776-3735-1-git-send-email-tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
From: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Date: Thu, 10 Feb 2011 08:56:16 +0900
> Previous patch "[PATCH 1/3] pch_can: fix 800k comms issue" is wrong.
> I should have modified tseg1_min not tseg2_min.
> Please discard previous patch and use this patch.
I can't "discard" the previous patch as it's already pushed upstream
into my GIT tree and therefore cannot be reverted.
You need to send a relative fix-up patch.
^ permalink raw reply
* [PATCH 1/3 v2] pch_can: fix 800k comms issue
From: Tomoya MORINAGA @ 2011-02-09 23:56 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
qi.wang-ral2JQCrhuEAvxtiuMwx3w,
yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
toshiharu-linux-ECg8zkTtlr0C6LszWs/t0g,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w,
joel.clark-ral2JQCrhuEAvxtiuMwx3w
Previous patch "[PATCH 1/3] pch_can: fix 800k comms issue" is wrong.
I should have modified tseg1_min not tseg2_min.
Please discard previous patch and use this patch.
Currently, 800k comms fails since prop_seg set zero.
(EG20T PCH CAN register of prop_seg must be set more than 1)
To prevent prop_seg set to zero, change tseg2_min 1 to 2.
Signed-off-by: Tomoya MORINAGA <tomoya-linux-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
---
drivers/net/can/pch_can.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/pch_can.c b/drivers/net/can/pch_can.c
index c42e972..0534eed 100644
--- a/drivers/net/can/pch_can.c
+++ b/drivers/net/can/pch_can.c
@@ -185,7 +185,7 @@ struct pch_can_priv {
static struct can_bittiming_const pch_can_bittiming_const = {
.name = KBUILD_MODNAME,
- .tseg1_min = 1,
+ .tseg1_min = 2,
.tseg1_max = 16,
.tseg2_min = 1,
.tseg2_max = 8,
--
1.7.3.4
^ permalink raw reply related
* RE: [net-next-2.6 PATCH 0/5] enic: updates to version 2.1.1.6
From: Vasanthy Kolluri (vkolluri) @ 2011-02-09 23:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110207.113932.226768580.davem@davemloft.net>
Hi Dave,
Sorry for the trouble. Will handle such cases better next time.
Thanks for taking care of it this time.
Thanks
Vasanthy
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Monday, February 07, 2011 11:40 AM
To: Vasanthy Kolluri (vkolluri)
Cc: netdev@vger.kernel.org
Subject: Re: [net-next-2.6 PATCH 0/5] enic: updates to version 2.1.1.6
From: "Vasanthy Kolluri (vkolluri)" <vkolluri@cisco.com>
Date: Mon, 7 Feb 2011 11:32:08 -0800
> Hi David,
>
> The below patch series should apply clean on top of another enic patch
> "enic: Decouple mac address registration and deregistration from port
> profile set operation" submitted earlier by roprabhu@cisco.com. Just
> want to ensure that it's not missed.
>
> Please let me know if there is still a need to re-spin.
How in the world was I supposed to know about this dependency?
Tell me.
^ permalink raw reply
* Re: [RFC PATCH net-next] net: rename group sysfs entry to netdev_group
From: David Miller @ 2011-02-09 22:05 UTC (permalink / raw)
To: dfeng; +Cc: netdev, eric.dumazet, therbert, ebiederm, shemminger, ddvlad
In-Reply-To: <20110209.140323.39178091.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 09 Feb 2011 14:03:23 -0800 (PST)
> From: Xiaotian feng <dfeng@redhat.com>
> Date: Wed, 9 Feb 2011 18:52:49 +0800
>
>> From: Xiaotian Feng <dfeng@redhat.com>
>>
>> commit a512b92 adds sysfs entry for net device group, but
>> before this commit, tun also uses group sysfs, so after this
>> commit checkin, kernel warns like this:
>> sysfs: cannot create duplicate filename '/devices/virtual/net/vnet0/group'
>>
>> Since tun has used this for years, rename sysfs under tun might
>> break existing userspace, so rename group sysfs entry for net device
>> group is a better choice.
>>
>> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
>
> I don't think we have much choice in this matter, so I have applied
> this patch, thanks!
Wait, you didn't even build test this patch?!?!?!?!
net/core/net-sysfs.c: In function ‘format_netdev_group’:
net/core/net-sysfs.c:298: error: ‘const struct net_device’ has no member named ‘netdev_group’
net/core/net-sysfs.c: At top level:
net/core/net-sysfs.c:333: error: ‘show_group’ undeclared here (not in a function)
"RFC" doesn't preclude you from at least build testing patches you
post.
Sigh...
^ permalink raw reply
* Re: [RFC PATCH net-next] net: rename group sysfs entry to netdev_group
From: David Miller @ 2011-02-09 22:03 UTC (permalink / raw)
To: dfeng; +Cc: netdev, eric.dumazet, therbert, ebiederm, shemminger, ddvlad
In-Reply-To: <1297248769-28530-1-git-send-email-dfeng@redhat.com>
From: Xiaotian feng <dfeng@redhat.com>
Date: Wed, 9 Feb 2011 18:52:49 +0800
> From: Xiaotian Feng <dfeng@redhat.com>
>
> commit a512b92 adds sysfs entry for net device group, but
> before this commit, tun also uses group sysfs, so after this
> commit checkin, kernel warns like this:
> sysfs: cannot create duplicate filename '/devices/virtual/net/vnet0/group'
>
> Since tun has used this for years, rename sysfs under tun might
> break existing userspace, so rename group sysfs entry for net device
> group is a better choice.
>
> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
I don't think we have much choice in this matter, so I have applied
this patch, thanks!
^ permalink raw reply
* Re: Linux 2.6.38-rc4 (hysdn: BUG)
From: Linus Torvalds @ 2011-02-09 22:00 UTC (permalink / raw)
To: David Miller; +Cc: randy.dunlap, netdev, linux-kernel, isdn
In-Reply-To: <20110209.135751.112605587.davem@davemloft.net>
On Wed, Feb 9, 2011 at 1:57 PM, David Miller <davem@davemloft.net> wrote:
>
> I propose we just kill this stuff off completely.
>
> I note that there is code in other places of this driver that copy
> the read-only revision string into a local string buffer then pass
> it into the hysdn_getrev() function, it just doesn't happen in this
> one spot.
>
> Anyways, I think I'll fix this like so:
Ack from me. Removing terminally buggy and pointless code is certainly
better than trying to fix it up. No amount of lipstick will make that
pig look good.
Linus
^ permalink raw reply
* Re: Linux 2.6.38-rc4 (hysdn: BUG)
From: David Miller @ 2011-02-09 21:57 UTC (permalink / raw)
To: randy.dunlap; +Cc: torvalds, netdev, linux-kernel, isdn
In-Reply-To: <20110209132529.76927f5f.randy.dunlap@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Wed, 9 Feb 2011 13:25:29 -0800
> On Wed, 9 Feb 2011 11:44:00 -0800 Linus Torvalds wrote:
>
>> On Wed, Feb 9, 2011 at 9:24 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> >
>> > on x86_64. no HYSDN hardware found (correct).
>> > Nearly allmodconfig.
>> >
>> >
>> > [ 65.397577] HYSDN: module Rev: 1.6.6.6 loaded
>> > [ 65.397584] HYSDN: network interface Rev: 1.8.6.4
>> > [ 65.398057] HYSDN: 0 card(s) found.
>> > [ 65.398121] BUG: unable to handle kernel paging request at ffffffffa06c99f0
>> > [ 65.398269] IP: [<ffffffffa06c68ba>] hysdn_getrev+0x2e/0x50 [hysdn]
>> > [ 65.398379] PGD 1a14067 PUD 1a18063 PMD 6f6c1067 PTE 800000006ce8c161
>> > [ 65.398613] Oops: 0003 [#1] SMP DEBUG_PAGEALLOC
>> > [ 65.400030]
>> > [ 65.400030] Pid: 2497, comm: modprobe Not tainted 2.6.38-rc4 #1 0TY565/OptiPlex 745
>> > [ 65.400030] RIP: 0010:[<ffffffffa06c68ba>] [<ffffffffa06c68ba>] hysdn_getrev+0x2e/0x50 [hysdn]
>> > [ 65.400030] RSP: 0018:ffff88006eec1e68 EFLAGS: 00010206
>> > [ 65.400030] RAX: ffffffffa06c99f1 RBX: ffffffffa06c99e9 RCX: ffff88007c4159a0
>>
>> The instruction sequence decodes to
>>
>> 1e: be 24 00 00 00 mov $0x24,%esi
>> 23: 48 89 df mov %rbx,%rdi
>> 26: e8 5b 39 c0 e0 callq 0xffffffffe0c03986
>> 2b:* c6 40 ff 00 movb $0x0,-0x1(%rax) <-- trapping instruction
>>
>> which seems to be this
>>
>> p = strchr(rev, '$');
>> *--p = 0;
>>
>> code. And yes, it's total crap, because while "p" and "rev" are "char
>> *", the string that is passed in is actually of type "const char *",
>> so that function is seriously broken. It's also seriously broken to
>> not test that "p" is non-NULL - the function would just break if there
>> is a colon in the string but not a '$'.
>>
>> And hysdn_procconf_init() passes in a constant string to the thing:
>>
>> static char *hysdn_procconf_revision = "$Revision: 1.8.6.4 $";
>>
>> What happens is that it breaks when we mark the constant section as
>> read-only, because you have CONFIG_DEBUG_RODATA enabled.
>>
>> So the fix seems to be to
>> - fix the prototype for hysdn_getrev() to not have "const".
>> - fix hysdn_procconf_init() to not pass in a constant string to it
>>
>> The minimal patch would appear to be something like the appended. UNTESTED!
>
> for your patch:
>
> Tested-and-acked-by: Randy Dunlap <randy.dunlap@oracle.com>
This stuff just prints out a CVS revision string that hasn't changed
in 10 years into the kernel log.
I propose we just kill this stuff off completely.
I note that there is code in other places of this driver that copy
the read-only revision string into a local string buffer then pass
it into the hysdn_getrev() function, it just doesn't happen in this
one spot.
Anyways, I think I'll fix this like so:
--------------------
isdn: hysdn: Kill (partially buggy) CVS regision log reporting.
Some cases try to modify const strings, and in any event the
CVS revision strings have not changed in over ten years making
these printouts completely worthless.
Just kill all of this stuff off.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/isdn/hysdn/hysdn_defs.h | 2 --
drivers/isdn/hysdn/hysdn_init.c | 26 +-------------------------
drivers/isdn/hysdn/hysdn_net.c | 3 ---
drivers/isdn/hysdn/hysdn_procconf.c | 3 +--
4 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/drivers/isdn/hysdn/hysdn_defs.h b/drivers/isdn/hysdn/hysdn_defs.h
index 729df40..18b801a 100644
--- a/drivers/isdn/hysdn/hysdn_defs.h
+++ b/drivers/isdn/hysdn/hysdn_defs.h
@@ -227,7 +227,6 @@ extern hysdn_card *card_root; /* pointer to first card */
/*************************/
/* im/exported functions */
/*************************/
-extern char *hysdn_getrev(const char *);
/* hysdn_procconf.c */
extern int hysdn_procconf_init(void); /* init proc config filesys */
@@ -259,7 +258,6 @@ extern int hysdn_tx_cfgline(hysdn_card *, unsigned char *,
/* hysdn_net.c */
extern unsigned int hynet_enable;
-extern char *hysdn_net_revision;
extern int hysdn_net_create(hysdn_card *); /* create a new net device */
extern int hysdn_net_release(hysdn_card *); /* delete the device */
extern char *hysdn_net_getname(hysdn_card *); /* get name of net interface */
diff --git a/drivers/isdn/hysdn/hysdn_init.c b/drivers/isdn/hysdn/hysdn_init.c
index b7cc5c2..0ab42ac 100644
--- a/drivers/isdn/hysdn/hysdn_init.c
+++ b/drivers/isdn/hysdn/hysdn_init.c
@@ -36,7 +36,6 @@ MODULE_DESCRIPTION("ISDN4Linux: Driver for HYSDN cards");
MODULE_AUTHOR("Werner Cornelius");
MODULE_LICENSE("GPL");
-static char *hysdn_init_revision = "$Revision: 1.6.6.6 $";
static int cardmax; /* number of found cards */
hysdn_card *card_root = NULL; /* pointer to first card */
static hysdn_card *card_last = NULL; /* pointer to first card */
@@ -49,25 +48,6 @@ static hysdn_card *card_last = NULL; /* pointer to first card */
/* Additionally newer versions may be activated without rebooting. */
/****************************************************************************/
-/******************************************************/
-/* extract revision number from string for log output */
-/******************************************************/
-char *
-hysdn_getrev(const char *revision)
-{
- char *rev;
- char *p;
-
- if ((p = strchr(revision, ':'))) {
- rev = p + 2;
- p = strchr(rev, '$');
- *--p = 0;
- } else
- rev = "???";
- return rev;
-}
-
-
/****************************************************************************/
/* init_module is called once when the module is loaded to do all necessary */
/* things like autodetect... */
@@ -175,13 +155,9 @@ static int hysdn_have_procfs;
static int __init
hysdn_init(void)
{
- char tmp[50];
int rc;
- strcpy(tmp, hysdn_init_revision);
- printk(KERN_NOTICE "HYSDN: module Rev: %s loaded\n", hysdn_getrev(tmp));
- strcpy(tmp, hysdn_net_revision);
- printk(KERN_NOTICE "HYSDN: network interface Rev: %s \n", hysdn_getrev(tmp));
+ printk(KERN_NOTICE "HYSDN: module loaded\n");
rc = pci_register_driver(&hysdn_pci_driver);
if (rc)
diff --git a/drivers/isdn/hysdn/hysdn_net.c b/drivers/isdn/hysdn/hysdn_net.c
index feec8d8..11f2cce 100644
--- a/drivers/isdn/hysdn/hysdn_net.c
+++ b/drivers/isdn/hysdn/hysdn_net.c
@@ -26,9 +26,6 @@
unsigned int hynet_enable = 0xffffffff;
module_param(hynet_enable, uint, 0);
-/* store the actual version for log reporting */
-char *hysdn_net_revision = "$Revision: 1.8.6.4 $";
-
#define MAX_SKB_BUFFERS 20 /* number of buffers for keeping TX-data */
/****************************************************************************/
diff --git a/drivers/isdn/hysdn/hysdn_procconf.c b/drivers/isdn/hysdn/hysdn_procconf.c
index 96b3e39..5fe83bd 100644
--- a/drivers/isdn/hysdn/hysdn_procconf.c
+++ b/drivers/isdn/hysdn/hysdn_procconf.c
@@ -23,7 +23,6 @@
#include "hysdn_defs.h"
static DEFINE_MUTEX(hysdn_conf_mutex);
-static char *hysdn_procconf_revision = "$Revision: 1.8.6.4 $";
#define INFO_OUT_LEN 80 /* length of info line including lf */
@@ -404,7 +403,7 @@ hysdn_procconf_init(void)
card = card->next; /* next entry */
}
- printk(KERN_NOTICE "HYSDN: procfs Rev. %s initialised\n", hysdn_getrev(hysdn_procconf_revision));
+ printk(KERN_NOTICE "HYSDN: procfs initialised\n");
return (0);
} /* hysdn_procconf_init */
--
1.7.4
^ permalink raw reply related
* Re: STMMAC driver: NFS Problem on 2.6.37
From: Chuck Lever @ 2011-02-09 21:26 UTC (permalink / raw)
To: Brian Downing
Cc: deepaksi, Armando VISCONTI, Trond Myklebust,
netdev-u79uwXL29TY76Z2rM5mHXA, Linux NFS Mailing List,
Shiraz HASHIM, Viresh KUMAR, Peppe CAVALLARO, amitgoel
In-Reply-To: <20110209205855.GB6402-QEOkiq82tQWoLK6CJbI5/KxOck334EZe@public.gmane.org>
On Feb 9, 2011, at 3:58 PM, Brian Downing wrote:
> On Wed, Feb 09, 2011 at 03:12:22PM -0500, Chuck Lever wrote:
>> Based on your console logs, I see that the working case uses UDP to
>> contact the server's mountd, but the failing case uses TCP. You can
>> try explicitly specifying "proto=udp" to force the use of UDP, to test
>> this theory.
>
> This does indeed make it work again for me, thanks!
>
>> Meanwhile, the patch description explicitly states that the default
>> mount option settings have changed. Does it make sense to change the
>> default behavior of NFSROOT mounts to use UDP again? I don't see
>> another way to make this process more reliable across NIC
>> initialization. If this is considered a regression, we can make a
>> patch for 2.6.38-rc and 2.6.37.
>
> I only use nfsroot for development, so I don't have a terribly strong
> opinion. I would point out though that the default u-boot parameters
> for nfsrooting a lot of boards will no longer work at this point, so if
> it's not patched to work again without specifying nfs options I think
> there should at least be a note in the documentation and possibly a
> "maybe try proto=udp?" console message on failure.
>
> I assume it's not feasable to either wait until the chosen interface's
> link is ready before trying to mount nfsroot, or retrying TCP-based
> connections a little bit more aggressively/at all?
Our goal is to use the same mount logic for both normal user space mounts and for NFSROOT (that was the purpose of the patch series this particular patch comes from). It's exceptionally difficult to add a special case for retrying TCP connections here, as that would change the behavior of user space mounts, which often want to fail quickly, and don't need to worry about NIC initialization.
Sounds like the right thing to do is restore the default UDP behavior. I'll cook up a patch.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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: Linux 2.6.38-rc4 (hysdn: BUG)
From: Randy Dunlap @ 2011-02-09 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: netdev, Linux Kernel Mailing List, Karsten Keil
In-Reply-To: <AANLkTimUg8Dm9mZotubcgPHz8_at=_hnbeWUo-LfSALp@mail.gmail.com>
On Wed, 9 Feb 2011 11:44:00 -0800 Linus Torvalds wrote:
> On Wed, Feb 9, 2011 at 9:24 AM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >
> > on x86_64. no HYSDN hardware found (correct).
> > Nearly allmodconfig.
> >
> >
> > [ 65.397577] HYSDN: module Rev: 1.6.6.6 loaded
> > [ 65.397584] HYSDN: network interface Rev: 1.8.6.4
> > [ 65.398057] HYSDN: 0 card(s) found.
> > [ 65.398121] BUG: unable to handle kernel paging request at ffffffffa06c99f0
> > [ 65.398269] IP: [<ffffffffa06c68ba>] hysdn_getrev+0x2e/0x50 [hysdn]
> > [ 65.398379] PGD 1a14067 PUD 1a18063 PMD 6f6c1067 PTE 800000006ce8c161
> > [ 65.398613] Oops: 0003 [#1] SMP DEBUG_PAGEALLOC
> > [ 65.400030]
> > [ 65.400030] Pid: 2497, comm: modprobe Not tainted 2.6.38-rc4 #1 0TY565/OptiPlex 745
> > [ 65.400030] RIP: 0010:[<ffffffffa06c68ba>] [<ffffffffa06c68ba>] hysdn_getrev+0x2e/0x50 [hysdn]
> > [ 65.400030] RSP: 0018:ffff88006eec1e68 EFLAGS: 00010206
> > [ 65.400030] RAX: ffffffffa06c99f1 RBX: ffffffffa06c99e9 RCX: ffff88007c4159a0
>
> The instruction sequence decodes to
>
> 1e: be 24 00 00 00 mov $0x24,%esi
> 23: 48 89 df mov %rbx,%rdi
> 26: e8 5b 39 c0 e0 callq 0xffffffffe0c03986
> 2b:* c6 40 ff 00 movb $0x0,-0x1(%rax) <-- trapping instruction
>
> which seems to be this
>
> p = strchr(rev, '$');
> *--p = 0;
>
> code. And yes, it's total crap, because while "p" and "rev" are "char
> *", the string that is passed in is actually of type "const char *",
> so that function is seriously broken. It's also seriously broken to
> not test that "p" is non-NULL - the function would just break if there
> is a colon in the string but not a '$'.
>
> And hysdn_procconf_init() passes in a constant string to the thing:
>
> static char *hysdn_procconf_revision = "$Revision: 1.8.6.4 $";
>
> What happens is that it breaks when we mark the constant section as
> read-only, because you have CONFIG_DEBUG_RODATA enabled.
>
> So the fix seems to be to
> - fix the prototype for hysdn_getrev() to not have "const".
> - fix hysdn_procconf_init() to not pass in a constant string to it
>
> The minimal patch would appear to be something like the appended. UNTESTED!
for your patch:
Tested-and-acked-by: Randy Dunlap <randy.dunlap@oracle.com>
> Btw, all of this code seems to go back to before the git history even
> started, so it doesn't seem to be new. I assume you haven't tried
> booting these all-module kernels before? Or is it just the
> DEBUG_RODATA thing that is new for you?
Neither is new. I tested and reported many-modules on 2.6.37-rc1 and
reported these 2 bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=22912
https://bugzilla.kernel.org/show_bug.cgi?id=22882
and that was with CONFIG_DEBUG_RODATA=y.
I don't know how hysdn was missed at that time.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* bleeding edge kernels misidentify my Broadcom BCM4401-B0
From: Celejar @ 2011-02-09 20:58 UTC (permalink / raw)
To: netdev
Hi,
Recently, while using bleeding edge kernels (built from git pulls of
vanillas sources from kernel.org), my Broadcom BCM4401-B0 Ethernet
card, normally driven by the b44 driver, has stopped working. Poking
around, I discovered that the card is no longer correctly identified;
it now shows up (with 'lspci -v' as root) as this bizarre device:
06:01.0 Network and computing encryption device: Broadcom Corporation Device 0010 (rev 02) (prog-if 10)
Subsystem: Allied Telesis, Inc Device 0010
Flags: fast devsel, IRQ 10
Memory at d0000000 (32-bit, non-prefetchable) [disabled] [size=8K]
Capabilities: [40] Power Management version 2
Using a stock Debian kernel (2.6.32-5-686), it shows up (and works)
correctly:
06:01.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
Subsystem: Acer Incorporated [ALI] Device 0090
Flags: bus master, fast devsel, latency 64, IRQ 21
Memory at d0000000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Kernel driver in use: b44
What on earth is this all about?
I tried another kernel I had lying around,
2.6.37-rc6-lizzie-00132-g55ec86f (built from kernel.org vanilla
sources), and it also works fine. I can do a bisection if necessary,
but I figured I'd check here first.
[Please cc. me on replies.]
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
^ permalink raw reply
* Re: [net-2.6][2.6.38-rc2] panic during stress testing
From: David Miller @ 2011-02-09 20:46 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: netdev, jeffrey.e.pieper
In-Reply-To: <alpine.WNT.2.00.1102081611130.5424@JBRANDEB-DESK2.amr.corp.intel.com>
From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Date: Wed, 9 Feb 2011 10:12:03 -0800 (Pacific Standard Time)
> neigh appears to be zero? since the check just above in dst_destroy was
> checking it against NULL already, maybe we have a race, with some other
> free of neigh (assigned from dst->neighbor)
>
> This is quickly getting beyond me, I tried to check for some changes
> around dst->neighbor but didn't see anything recent.
"neigh" is non-zero, however it is freed memory and thus unmapped by
the "use after free" debugging code.
That's why it OOPS's.
^ permalink raw reply
* Re: [PATCH -next] can: softing_cs needs slab.h
From: David Miller @ 2011-02-09 20:43 UTC (permalink / raw)
To: randy.dunlap-veTT2BtV2gBXrIkS9f7CXA
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w, sfr-3FnU+UHB4dNDw9hX6IcOSA,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110209084456.802370fa.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
From: Randy Dunlap <randy.dunlap-veTT2BtV2gBXrIkS9f7CXA@public.gmane.org>
Date: Wed, 9 Feb 2011 08:44:56 -0800
> From: Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
>
> softing_cs.c uses kzalloc & kfree, so it needs to include linux/slab.h.
>
> drivers/net/can/softing/softing_cs.c:234: error: implicit declaration of function 'kfree'
> drivers/net/can/softing/softing_cs.c:271: error: implicit declaration of function 'kzalloc'
>
> Signed-off-by: Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH 0/1] netfilter: netfilter fixes
From: David Miller @ 2011-02-09 20:40 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1297262369-26393-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Wed, 9 Feb 2011 15:39:28 +0100
> Hi Dave,
>
> following is a single netfilter fix for net-2.6.git, fixing use of conntrack
> templates when TCP conntrack kills the current conntrack in TIME_WAIT state
> in order to have the conntrack core create a fresh one, from Pablo.
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Also pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH 0/2] netfilter: netfilter update
From: David Miller @ 2011-02-09 20:39 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1297262027-26237-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Wed, 9 Feb 2011 15:33:45 +0100
> following are two IPVS patches for net-next-2.6, fixing:
>
> - use of an incorrect lock in the SCTP module, from Simon
>
> - a precedence bug in ip_vs_sync_switch_mode(), from Dan Carpenter
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6.git master
Pulled, thanks Patrick.
^ permalink raw reply
* Re: [PATCH v2] pch_gbe: Fix the issue which a driver locks when rx offload is set by ethtool
From: David Miller @ 2011-02-09 20:28 UTC (permalink / raw)
To: toshiharu-linux
Cc: netdev, linux-kernel, qi.wang, yong.y.wang, andrew.chih.howe.khor,
joel.clark, kok.howg.ewe, tomoya-linux
In-Reply-To: <4D524C7F.1000700@dsn.okisemi.com>
From: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Date: Wed, 09 Feb 2011 17:12:47 +0900
> This driver will be in a deadlock, When the rx offload is set by ethtool.
> The pch_gbe_reinit_locked function was modified.
>
> Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Applied.
^ permalink raw reply
* [PATCH 1/1] tlan: Fix bugs introduced by the last tlan cleanup patch
From: Sakari Ailus @ 2011-02-09 20:25 UTC (permalink / raw)
To: netdev; +Cc: error27
In-Reply-To: <4D52F80E.9030307@iki.fi>
Fix two bugs introduced by the patch "tlan: Code cleanup: checkpatch.pl is
relatively happy now." In that patch, TLAN_CSTAT_READY was considered as a
bit mask containing a single bit set while it was actually had two set
instead.
Many thanks to Dan Carpenter for finding the mistake.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
---
drivers/net/tlan.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tlan.c b/drivers/net/tlan.c
index 0678e7e..e48a808 100644
--- a/drivers/net/tlan.c
+++ b/drivers/net/tlan.c
@@ -1522,7 +1522,8 @@ static u32 tlan_handle_tx_eof(struct net_device *dev, u16 host_int)
head_list = priv->tx_list + priv->tx_head;
head_list_phys = priv->tx_list_dma
+ sizeof(struct tlan_list)*priv->tx_head;
- if (head_list->c_stat & TLAN_CSTAT_READY) {
+ if ((head_list->c_stat & TLAN_CSTAT_READY)
+ == TLAN_CSTAT_READY) {
outl(head_list_phys, dev->base_addr + TLAN_CH_PARM);
ack |= TLAN_HC_GO;
} else {
@@ -1766,7 +1767,8 @@ static u32 tlan_handle_tx_eoc(struct net_device *dev, u16 host_int)
head_list = priv->tx_list + priv->tx_head;
head_list_phys = priv->tx_list_dma
+ sizeof(struct tlan_list)*priv->tx_head;
- if (head_list->c_stat & TLAN_CSTAT_READY) {
+ if ((head_list->c_stat & TLAN_CSTAT_READY)
+ == TLAN_CSTAT_READY) {
netif_stop_queue(dev);
outl(head_list_phys, dev->base_addr + TLAN_CH_PARM);
ack |= TLAN_HC_GO;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/1] tlan cleanup fix
From: Sakari Ailus @ 2011-02-09 20:24 UTC (permalink / raw)
To: netdev; +Cc: Dan Carpenter
Hi,
Dan Carpenter found a problem in my last tlan cleanup patch. In the
cleanup, I accidentally considered a bit mask containing multiple bits
set as one containing a single bit set. The following patch fixes this
issue.
Regards,
--
Sakari Ailus
sakari.ailus@iki.fi
^ 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