* Re: [SECURITY] memory corruption in X.25 facilities parsing
From: Andrew Hendry @ 2010-11-03 1:12 UTC (permalink / raw)
To: Dan Rosenberg; +Cc: netdev, security, stable
In-Reply-To: <1288710168.2504.6.camel@dan>
There is an issue here, under select scenarios I can crash systems.
However the patch doesn't resolve it fully, I think after breaking at
that point the len and p pointers are messed up before it tries to
parse the next facility.
Maybe it should return not break? It should reject/clear such calls.
I'll start checking if the callers properly handle errors.
Also should it be if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] <= 1),
because it does the memcpy with p[1] -1
On Wed, Nov 3, 2010 at 2:02 AM, Dan Rosenberg <drosenberg@vsecurity.com> wrote:
> I put this together after a quick glance, so if someone knows this code
> better than I do (i.e. at all), feel free to comment or drop this patch
> if it's unnecessary.
>
> A value of 0 will cause a memcpy() of ULONG_MAX size, destroying the
> kernel heap.
>
> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
>
> --- linux-2.6.36-rc6.orig/net/x25/x25_facilities.c 2010-09-28 21:01:22.000000000 -0400
> +++ linux-2.6.36-rc6/net/x25/x25_facilities.c 2010-11-02 10:36:02.827291324 -0400
> @@ -134,14 +134,14 @@ int x25_parse_facilities(struct sk_buff
> case X25_FAC_CLASS_D:
> switch (*p) {
> case X25_FAC_CALLING_AE:
> - if (p[1] > X25_MAX_DTE_FACIL_LEN)
> + if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] == 0)
> break;
> dte_facs->calling_len = p[2];
> memcpy(dte_facs->calling_ae, &p[3], p[1] - 1);
> *vc_fac_mask |= X25_MASK_CALLING_AE;
> break;
> case X25_FAC_CALLED_AE:
> - if (p[1] > X25_MAX_DTE_FACIL_LEN)
> + if (p[1] > X25_MAX_DTE_FACIL_LEN || p[1] == 0)
> break;
> dte_facs->called_len = p[2];
> memcpy(dte_facs->called_ae, &p[3], p[1] - 1);
>
>
>
^ permalink raw reply
* [PATCH] net dst: fix percpu_counter list corruption and poison overwritten
From: Xiaotian Feng @ 2010-11-03 2:11 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, Xiaotian Feng, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
There're some percpu_counter list corruption and poison overwritten warnings
in recent kernel, which is resulted by fc66f95c.
commit fc66f95c switches to use percpu_counter, in ip6_route_net_init, kernel
init the percpu_counter for dst entries, but, the percpu_counter is never destroyed
in ip6_route_net_exit. So if the related data is freed by kernel, the freed percpu_counter
is still on the list, then if we insert/remove other percpu_counter, list corruption
resulted. Also, if the insert/remove option modifies the ->prev,->next pointer of
the freed value, the poison overwritten is resulted then.
With the following patch, the percpu_counter list corruption and poison overwritten
warnings disappeared.
Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
---
net/ipv6/route.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 25661f9..fc32833 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2741,6 +2741,7 @@ static void __net_exit ip6_route_net_exit(struct net *net)
kfree(net->ipv6.ip6_prohibit_entry);
kfree(net->ipv6.ip6_blk_hole_entry);
#endif
+ dst_entries_destroy(&net->ipv6.ip6_dst_ops);
}
static struct pernet_operations ip6_route_net_ops = {
@@ -2832,5 +2833,6 @@ void ip6_route_cleanup(void)
xfrm6_fini();
fib6_gc_cleanup();
unregister_pernet_subsys(&ip6_route_net_ops);
+ dst_entries_destroy(&ip6_dst_blackhole_ops);
kmem_cache_destroy(ip6_dst_ops_template.kmem_cachep);
}
--
1.7.3.2
^ permalink raw reply related
* [Patch] netxen: remove unused firmware exports
From: Amerigo Wang @ 2010-11-03 4:25 UTC (permalink / raw)
To: linux-kernel
Cc: Dhananjay Phadke, Amit Kumar Salecha, Narender Kumar, netdev,
David S. Miller, Amerigo Wang
Quote from Amit Salecha:
"Actually I was not updated, NX_UNIFIED_ROMIMAGE_NAME (phanfw.bin) is already
submitted and its present in linux-firmware.git.
I will get back to you on NX_P2_MN_ROMIMAGE_NAME, NX_P3_CT_ROMIMAGE_NAME and
NX_P3_MN_ROMIMAGE_NAME. Whether this will be submitted ?"
We have to remove these, otherwise we will get wrong info from modinfo.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Amit Kumar Salecha <amit.salecha@qlogic.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
Cc: Narender Kumar <narender.kumar@qlogic.com>
---
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 50820be..5ddf112 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -41,9 +41,6 @@
MODULE_DESCRIPTION("QLogic/NetXen (1/10) GbE Converged Ethernet Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(NETXEN_NIC_LINUX_VERSIONID);
-MODULE_FIRMWARE(NX_P2_MN_ROMIMAGE_NAME);
-MODULE_FIRMWARE(NX_P3_CT_ROMIMAGE_NAME);
-MODULE_FIRMWARE(NX_P3_MN_ROMIMAGE_NAME);
MODULE_FIRMWARE(NX_UNIFIED_ROMIMAGE_NAME);
char netxen_nic_driver_name[] = "netxen_nic";
^ permalink raw reply related
* Re: [PATCH] net dst: fix percpu_counter list corruption and poison overwritten
From: Eric Dumazet @ 2010-11-03 5:22 UTC (permalink / raw)
To: Xiaotian Feng
Cc: netdev, linux-kernel, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <1288750265-17664-1-git-send-email-dfeng@redhat.com>
Le mercredi 03 novembre 2010 à 10:11 +0800, Xiaotian Feng a écrit :
> There're some percpu_counter list corruption and poison overwritten warnings
> in recent kernel, which is resulted by fc66f95c.
>
> commit fc66f95c switches to use percpu_counter, in ip6_route_net_init, kernel
> init the percpu_counter for dst entries, but, the percpu_counter is never destroyed
> in ip6_route_net_exit. So if the related data is freed by kernel, the freed percpu_counter
> is still on the list, then if we insert/remove other percpu_counter, list corruption
> resulted. Also, if the insert/remove option modifies the ->prev,->next pointer of
> the freed value, the poison overwritten is resulted then.
>
> With the following patch, the percpu_counter list corruption and poison overwritten
> warnings disappeared.
>
> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
> Cc: James Morris <jmorris@namei.org>
> Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> Cc: Patrick McHardy <kaber@trash.net>
> ---
Good catch, thanks !
Any reason you didnt Cc me (the author of the patch) ?
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH] net dst: fix percpu_counter list corruption and poison overwritten
From: Xiaotian Feng @ 2010-11-03 5:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, linux-kernel, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <1288761773.2467.535.camel@edumazet-laptop>
On 11/03/2010 01:22 PM, Eric Dumazet wrote:
> Le mercredi 03 novembre 2010 à 10:11 +0800, Xiaotian Feng a écrit :
>> There're some percpu_counter list corruption and poison overwritten warnings
>> in recent kernel, which is resulted by fc66f95c.
>>
>> commit fc66f95c switches to use percpu_counter, in ip6_route_net_init, kernel
>> init the percpu_counter for dst entries, but, the percpu_counter is never destroyed
>> in ip6_route_net_exit. So if the related data is freed by kernel, the freed percpu_counter
>> is still on the list, then if we insert/remove other percpu_counter, list corruption
>> resulted. Also, if the insert/remove option modifies the ->prev,->next pointer of
>> the freed value, the poison overwritten is resulted then.
>>
>> With the following patch, the percpu_counter list corruption and poison overwritten
>> warnings disappeared.
>>
>> Signed-off-by: Xiaotian Feng<dfeng@redhat.com>
>> Cc: "David S. Miller"<davem@davemloft.net>
>> Cc: Alexey Kuznetsov<kuznet@ms2.inr.ac.ru>
>> Cc: "Pekka Savola (ipv6)"<pekkas@netcore.fi>
>> Cc: James Morris<jmorris@namei.org>
>> Cc: Hideaki YOSHIFUJI<yoshfuji@linux-ipv6.org>
>> Cc: Patrick McHardy<kaber@trash.net>
>> ---
>
> Good catch, thanks !
>
> Any reason you didnt Cc me (the author of the patch) ?
Sorry, I just used get_maintainer.pl to get the cc list...
>
> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>
>
>
>
^ permalink raw reply
* [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Dave Chinner @ 2010-11-03 6:26 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
Folks,
Starting up KVM on a current mainline kernel using the tap
device for the networking is resulting in the ip process tryin gto
up the tap interface hanging. KVM is started with this networking
config:
....
-net nic,vlan=0,macaddr=00:e4:b6:63:63:6d,model=virtio \
-net tap,vlan=0,script=/vm-images/qemu-ifup,downscript=no \
....
And the script is effectively:
switch=br0
if [ -n "$1" ];then
/usr/bin/sudo /sbin/ip link set $1 up
sleep 0.5s
/usr/bin/sudo /usr/sbin/brctl addif $switch $1
exit 0
fi
exit 1
This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
In do_exit() with this trace:
[ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
[ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
[ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
[ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
[ 1630.811324] Call Trace:
[ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
[ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
[ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
[ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
The address comes down to the schedule() call:
(gdb) l *(do_exit+0x716)
0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
1029 preempt_disable();
1030 exit_rcu();
1031 /* causes final put_task_struct in finish_task_switch(). */
1032 tsk->state = TASK_DEAD;
1033 schedule();
1034 BUG();
1035 /* Avoid "noreturn function does return". */
1036 for (;;)
1037 cpu_relax(); /* For when BUG is null */
1038 }
Needless to say, KVM is not starting up. This works just fine on
2.6.35.1 and so is a regression. I can't do a lot of testing on this as
the host is the machine that hosts all my build and test environments....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Pavel Machek @ 2010-11-02 1:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, Oliver Neukum, Valdis.Kletnieks, Dave Airlie, codalist,
ksummit-2010-discuss, autofs, Jan Harkes, Samuel Ortiz, Jan Kara,
Arnaldo Carvalho de Melo, netdev, Anders Larsen, linux-kernel,
dri-devel, Bryan Schumaker, Christoph Hellwig, Petr Vandrovec,
Mikulas Patocka, linux-fsdevel, Evgeniy Dushistov, Ingo Molnar,
Andrew Hendry, linux-media
In-Reply-To: <201010192244.41913.arnd@arndb.de>
Hi!
> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>
> static int __init i810_init(void)
> {
> + if (num_present_cpus() > 1) {
> + pr_err("drm/i810 does not support SMP\n");
> + return -EINVAL;
> + }
> driver.num_ioctls = i810_max_ioctl;
> return drm_init(&driver);
Umm, and now someone onlines second cpu?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Pekka Enberg @ 2010-11-03 6:58 UTC (permalink / raw)
To: Pavel Machek
Cc: Arnd Bergmann, Greg KH, Oliver Neukum, Valdis.Kletnieks,
Dave Airlie, codalist, ksummit-2010-discuss, autofs, Jan Harkes,
Samuel Ortiz, Jan Kara, Arnaldo Carvalho de Melo, netdev,
Anders Larsen, linux-kernel, dri-devel, Bryan Schumaker,
Christoph Hellwig, Petr Vandrovec, Mikulas Patocka, linux-fsdevel,
Evgeniy Dushistov, Ingo Molnar, Andrew Hendry, linux-media
In-Reply-To: <20101102012135.GB2648@ucw.cz>
On Tue, Nov 2, 2010 at 3:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> @@ -79,6 +79,10 @@ static struct drm_driver driver = {
>>
>> static int __init i810_init(void)
>> {
>> + if (num_present_cpus() > 1) {
>> + pr_err("drm/i810 does not support SMP\n");
>> + return -EINVAL;
>> + }
>> driver.num_ioctls = i810_max_ioctl;
>> return drm_init(&driver);
>
> Umm, and now someone onlines second cpu?
Well, I see it's being fixed in a different way but yeah,
num_possible_cpus() would be more appropriate here.
^ permalink raw reply
* Re: [v3 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Michael S. Tsirkin @ 2010-11-03 7:01 UTC (permalink / raw)
To: Krishna Kumar2
Cc: anthony, arnd, avi, davem, eric.dumazet, kvm, netdev, rusty
In-Reply-To: <OFE75E1E91.9722BFB3-ON652577CA.00256D94-652577CA.0027E1CE@in.ibm.com>
On Thu, Oct 28, 2010 at 12:48:57PM +0530, Krishna Kumar2 wrote:
> > Krishna Kumar2/India/IBM wrote on 10/28/2010 10:44:14 AM:
> >
> > > > > > Results for UDP BW tests (unidirectional, sum across
> > > > > > 3 iterations, each iteration of 45 seconds, default
> > > > > > netperf, vhosts bound to cpus 0-3; no other tuning):
> > > > >
> > > > > Is binding vhost threads to CPUs really required?
> > > > > What happens if we let the scheduler do its job?
> > > >
> > > > Nothing drastic, I remember BW% and SD% both improved a
> > > > bit as a result of binding.
> > >
> > > If there's a significant improvement this would mean that
> > > we need to rethink the vhost-net interaction with the scheduler.
> >
> > I will get a test run with and without binding and post the
> > results later today.
>
> Correction: The result with binding is is much better for
> SD/CPU compared to without-binding:
Something that was suggested to me off-list is
trying to set smp affinity for NIC: in host to guest
case probably virtio-net, for external to guest
the host NIC as well.
--
MST
^ permalink raw reply
* [PATCH] virtio-net: init link state correctly
From: Jason Wang @ 2010-11-03 7:08 UTC (permalink / raw)
To: rusty, davem; +Cc: markmc, netdev, linux-kernel, kvm, mst
We need call netif_carrier_off() and do not assume VIRTIO_NET_S_LINKUP
before querying device state during probing, otherwise we may get
wrong operstate after driver was loaded because the link watch event
was not fired as expected.
Since the device state changed could be caught through interrupt, the
unconditional call to nerif_carrier_on() is also removed.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/virtio_net.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index bb6b67f..0a0cd35 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -986,9 +986,8 @@ static int virtnet_probe(struct virtio_device *vdev)
goto unregister;
}
- vi->status = VIRTIO_NET_S_LINK_UP;
+ netif_carrier_off(dev);
virtnet_update_status(vi);
- netif_carrier_on(dev);
pr_debug("virtnet: registered device %s\n", dev->name);
return 0;
^ permalink raw reply related
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Eric Dumazet @ 2010-11-03 7:13 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-kernel, netdev
In-Reply-To: <20101103062609.GB31163@dastard>
Le mercredi 03 novembre 2010 à 17:26 +1100, Dave Chinner a écrit :
> Folks,
>
> Starting up KVM on a current mainline kernel using the tap
> device for the networking is resulting in the ip process tryin gto
> up the tap interface hanging. KVM is started with this networking
> config:
>
> ....
> -net nic,vlan=0,macaddr=00:e4:b6:63:63:6d,model=virtio \
> -net tap,vlan=0,script=/vm-images/qemu-ifup,downscript=no \
> ....
>
> And the script is effectively:
>
> switch=br0
> if [ -n "$1" ];then
> /usr/bin/sudo /sbin/ip link set $1 up
> sleep 0.5s
> /usr/bin/sudo /usr/sbin/brctl addif $switch $1
> exit 0
> fi
> exit 1
>
> This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
>
> root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
> root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
> root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
>
> In do_exit() with this trace:
>
> [ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
> [ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
> [ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
> [ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
> [ 1630.811324] Call Trace:
> [ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
> [ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
> [ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
> [ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
>
> The address comes down to the schedule() call:
>
> (gdb) l *(do_exit+0x716)
> 0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
> 1029 preempt_disable();
> 1030 exit_rcu();
> 1031 /* causes final put_task_struct in finish_task_switch(). */
> 1032 tsk->state = TASK_DEAD;
> 1033 schedule();
> 1034 BUG();
> 1035 /* Avoid "noreturn function does return". */
> 1036 for (;;)
> 1037 cpu_relax(); /* For when BUG is null */
> 1038 }
>
> Needless to say, KVM is not starting up. This works just fine on
> 2.6.35.1 and so is a regression. I can't do a lot of testing on this as
> the host is the machine that hosts all my build and test environments....
>
> Cheers,
>
> Dave.
Could it be the same problem than
http://kerneltrap.com/mailarchive/linux-netdev/2010/10/23/6288128
Try to revert bee31369ce16fc3898ec9a54161248c9eddb06bc ?
Thanks
^ permalink raw reply
* Re: tc action mirred packet lost
From: Nieścierowicz Adam @ 2010-11-03 7:16 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <4CCEA16B.1050603@gmail.com>
On Mon, 01 Nov 2010 12:15:55 +0100, Jarek Poplawski <jarkao2@gmail.com>
wrote:
> Nieścierowicz Adam wrote:
>> Hello,
>> recently there was a need to create 3-4 copies of the data sent to
>> the
>> router, I decided to use the tc action mirred.
>>
>>
>> Ingress traficn on eth1 copies to eth1 eth2, eth3, eth4, eth5 using:
>> ---
>> tc qdisc add dev eth1 ingress
>>
>> tc filter add dev eth1 parent ffff: protocol ip prio 10 u32 match ip
>> src
>> 0/0 flowid 1:1 action mirred egress mirror dev eth2 pipe action
>> mirred
>> egress mirror dev eth3 pipe action mirred egress mirror dev eth4
>> pipe
>> action mirred egress mirror dev eth5
>> --
>>
>>
>> Unfortunately the number of packets seen on eth1 qdisc is different
>> than
>> the eth [2-5]
>
> Hi,
> Usually the reason for such differences is arp or other non-ip
> protocols. Try a filter with "protocol all" to check this.
>
> Jarek P.
> --
> 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
Thanks, it works
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Jarek Poplawski @ 2010-11-03 7:38 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <201011021549.47466.nuclearcat@nuclearcat.com>
On Tue, Nov 02, 2010 at 03:49:47PM +0200, Denys Fedoryshchenko wrote:
> I didn't try yet, but i enable more debugs and catch linked list corruption.
It should be very useful but it seems there were no significant changes
in ppp locking between 2.6.35 and .36 except the patch I mentioned, so
it would be nice to check this first and try to fix it properly later.
Jarek P.
>
> Here is dumps from netconsole:
> http://www.nuclearcat.com/ll.txt
> http://www.nuclearcat.com/ll2.txt
>
> I have another PC, also fails to run 2.6.36, but netconsole don't give
> anything.
> Both PC's have strange issue with clock drifting away too much (on 2.6.35 and
> maybe even before).
>
>
> On Thursday 28 October 2010 10:05:50 Jarek Poplawski wrote:
> > On 2010-10-25 11:22, Denys Fedoryshchenko wrote:
> > > Hi
> > >
> > > Here is what i got from netconsole
> > >
> > > [ 259.238755] BUG: unable to handle kernel
> > > paging request
> > > at f8ba001c
> > > [ 259.238953] IP:
> > > [<c0199ebe>] do_select+0x2cc/0x502
> >
> > ...
> >
> > > It is not easy to do full git bisect(it is semi-embedded distro), but i
> > > can try reversing particular commits, if someone can give idea which
> > > one, and can try debug patches.
> >
> > Hi,
> > Nothing concrete, but you might try reverting this one:
> >
> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=commi
> > tdiff;h=15fd0cd9a2ad24a78fbee369dec8ca660979d57e
> >
> > Jarek P.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ipv4: netfilter: arp_tables: fix information leak to userland
From: Patrick McHardy @ 2010-11-03 7:44 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <1288448806-6470-1-git-send-email-segooon@gmail.com>
On 30.10.2010 16:26, Vasiliy Kulikov wrote:
> Structure arpt_getinfo is copied to userland with the field "name"
> that has the last elements unitialized. It leads to leaking of
> contents of kernel stack memory.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: netfilter: ip_tables: fix information leak to userland
From: Patrick McHardy @ 2010-11-03 7:45 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: kernel-janitors, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
netfilter-devel, netfilter, coreteam, netdev, linux-kernel
In-Reply-To: <1288448810-6628-1-git-send-email-segooon@gmail.com>
On 30.10.2010 16:26, Vasiliy Kulikov wrote:
> Structure ipt_getinfo is copied to userland with the field "name"
> that has the last elements unitialized. It leads to leaking of
> contents of kernel stack memory.
Also applied, thanks.
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Denys Fedoryshchenko @ 2010-11-03 7:47 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <20101103073854.GA7279@ff.dom.local>
I try to reverse and got very weird lockups (no netconsole logs and no
watchdog triggered reboot on that remote machine).
I will try to cook something to reboot it, because it is very remote machine
On Wednesday 03 November 2010 09:38:54 Jarek Poplawski wrote:
> On Tue, Nov 02, 2010 at 03:49:47PM +0200, Denys Fedoryshchenko wrote:
> > I didn't try yet, but i enable more debugs and catch linked list
> > corruption.
>
> It should be very useful but it seems there were no significant changes
> in ppp locking between 2.6.35 and .36 except the patch I mentioned, so
> it would be nice to check this first and try to fix it properly later.
>
> Jarek P.
>
> > Here is dumps from netconsole:
> > http://www.nuclearcat.com/ll.txt
> > http://www.nuclearcat.com/ll2.txt
> >
> > I have another PC, also fails to run 2.6.36, but netconsole don't give
> > anything.
> > Both PC's have strange issue with clock drifting away too much (on 2.6.35
> > and maybe even before).
> >
> > On Thursday 28 October 2010 10:05:50 Jarek Poplawski wrote:
> > > On 2010-10-25 11:22, Denys Fedoryshchenko wrote:
> > > > Hi
> > > >
> > > > Here is what i got from netconsole
> > > >
> > > > [ 259.238755] BUG: unable to handle kernel
> > > > paging request
> > > > at f8ba001c9999
> > > > [ 259.238953] IP:
> > > > [<c0199ebe>] do_select+0x2cc/0x502
> > >
> > > ...
> > >
> > > > It is not easy to do full git bisect(it is semi-embedded distro), but
> > > > i can try reversing particular commits, if someone can give idea
> > > > which one, and can try debug patches.
> > >
> > > Hi,
> > > Nothing concrete, but you might try reverting this one:
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=c
> > > ommi tdiff;h=15fd0cd9a2ad24a78fbee369dec8ca660979d57e
> > >
> > > Jarek P.
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] virtio-net: init link state correctly
From: Michael S. Tsirkin @ 2010-11-03 8:00 UTC (permalink / raw)
To: Jason Wang; +Cc: rusty, davem, markmc, netdev, linux-kernel, kvm
In-Reply-To: <20101103070817.26272.31654.stgit@dhcp-91-158.nay.redhat.com>
On Wed, Nov 03, 2010 at 03:08:17PM +0800, Jason Wang wrote:
> We need call netif_carrier_off() and do not assume VIRTIO_NET_S_LINKUP
> before querying device state during probing, otherwise we may get
> wrong operstate after driver was loaded because the link watch event
> was not fired as expected.
>
> Since the device state changed could be caught through interrupt, the
> unconditional call to nerif_carrier_on() is also removed.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
OK, but this seems broken for hosts without VIRTIO_NET_F_STATUS. Right?
Probably
/* Assume link up if device can't report link status,
otherwise get link status from config. */
if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
vi->status = 0;
netif_carrier_off(dev);
virtnet_update_status(vi);
} else {
vi->status = VIRTIO_NET_S_LINK_UP;
netif_carrier_on(dev);
}
Makes sense?
> ---
> drivers/net/virtio_net.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index bb6b67f..0a0cd35 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -986,9 +986,8 @@ static int virtnet_probe(struct virtio_device *vdev)
> goto unregister;
> }
>
> - vi->status = VIRTIO_NET_S_LINK_UP;
> + netif_carrier_off(dev);
> virtnet_update_status(vi);
> - netif_carrier_on(dev);
>
> pr_debug("virtnet: registered device %s\n", dev->name);
> return 0;
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Jarek Poplawski @ 2010-11-03 8:02 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <201011030947.54464.nuclearcat@nuclearcat.com>
On Wed, Nov 03, 2010 at 09:47:53AM +0200, Denys Fedoryshchenko wrote:
> I try to reverse and got very weird lockups (no netconsole logs and no
> watchdog triggered reboot on that remote machine).
> I will try to cook something to reboot it, because it is very remote machine
OK, I only wanted to know if reverting could be a fast fix. Since it
isn't, please stay with 2.6.35 until there is some new idea (patch).
Jarek P.
^ permalink raw reply
* Re: 2.6.35->2.6.36 regression, vanilla kernel panic, ppp or hrtimers crashing
From: Jarek Poplawski @ 2010-11-03 8:59 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Thomas Gleixner, Paul Mackerras, linux-kernel, netdev
In-Reply-To: <201011031018.21178.nuclearcat@nuclearcat.com>
On Wed, Nov 03, 2010 at 10:18:20AM +0200, Denys Fedoryshchenko wrote:
>
> On Wednesday 03 November 2010 10:02:58 Jarek Poplawski wrote:
> > On Wed, Nov 03, 2010 at 09:47:53AM +0200, Denys Fedoryshchenko wrote:
> > > I try to reverse and got very weird lockups (no netconsole logs and no
> > > watchdog triggered reboot on that remote machine).
> > > I will try to cook something to reboot it, because it is very remote
> > > machine
> >
> > OK, I only wanted to know if reverting could be a fast fix. Since it
> > isn't, please stay with 2.6.35 until there is some new idea (patch).
> >
> Well, still i want to try (if i can) more debug, and maybe i'll catch
> something, also i have around 145 NAS servers to go, to try 2.6.36 :-)
I think the current debugging needs analyzing first. But here is
a patch which probably could matter at least wrt your first oopses.
(Please try this first on something you can easily reboot.)
Jarek P.
---
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 09cf56d..1b98c4c 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -409,6 +409,8 @@ static ssize_t ppp_read(struct file *file, char __user *buf,
if (!pf)
return -ENXIO;
+
+ atomic_inc(&pf->refcnt);
add_wait_queue(&pf->rwait, &wait);
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
@@ -440,6 +442,17 @@ static ssize_t ppp_read(struct file *file, char __user *buf,
set_current_state(TASK_RUNNING);
remove_wait_queue(&pf->rwait, &wait);
+ if (atomic_dec_and_test(&pf->refcnt)) {
+ switch (pf->kind) {
+ case INTERFACE:
+ ppp_destroy_interface(PF_TO_PPP(pf));
+ break;
+ case CHANNEL:
+ ppp_destroy_channel(PF_TO_CHANNEL(pf));
+ break;
+ }
+ }
+
if (!skb)
goto out;
@@ -504,6 +517,8 @@ static unsigned int ppp_poll(struct file *file, poll_table *wait)
if (!pf)
return 0;
+
+ atomic_inc(&pf->refcnt);
poll_wait(file, &pf->rwait, wait);
mask = POLLOUT | POLLWRNORM;
if (skb_peek(&pf->rq))
@@ -518,6 +533,17 @@ static unsigned int ppp_poll(struct file *file, poll_table *wait)
mask |= POLLIN | POLLRDNORM;
}
+ if (atomic_dec_and_test(&pf->refcnt)) {
+ switch (pf->kind) {
+ case INTERFACE:
+ ppp_destroy_interface(PF_TO_PPP(pf));
+ break;
+ case CHANNEL:
+ ppp_destroy_channel(PF_TO_CHANNEL(pf));
+ break;
+ }
+ }
+
return mask;
}
^ permalink raw reply related
* RE: [Patch] netxen: remove unused firmware exports
From: Amit Salecha @ 2010-11-03 9:35 UTC (permalink / raw)
To: Amerigo Wang, linux-kernel@vger.kernel.org
Cc: Dhananjay Phadke, Narender Kumar, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <20101103043021.5321.73681.sendpatchset@localhost.localdomain>
> From: Amerigo Wang [amwang@redhat.com]
> Sent: Wednesday, November 03, 2010 9:55 AM
> To: linux-kernel@vger.kernel.org
> Cc: Dhananjay Phadke; Amit Salecha; Narender Kumar; netdev@vger.kernel.org; David S. Miller; Amerigo Wang
> Subject: [Patch] netxen: remove unused firmware exports
>
> Quote from Amit Salecha:
>
> "Actually I was not updated, NX_UNIFIED_ROMIMAGE_NAME (phanfw.bin) is already
> submitted and its present in linux-firmware.git.
>
> I will get back to you on NX_P2_MN_ROMIMAGE_NAME, NX_P3_CT_ROMIMAGE_NAME and
> NX_P3_MN_ROMIMAGE_NAME. Whether this will be submitted ?"
>
> We have to remove these, otherwise we will get wrong info from modinfo.
>
> Signed-off-by: WANG Cong <amwang@redhat.com>
> Cc: Amit Kumar Salecha <amit.salecha@qlogic.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
> Cc: Narender Kumar narender.kumar@qlogic.com
Acked-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
^ permalink raw reply
* Irish Lotto***You Earned £750,000***
From: Fiduciary Desk @ 2010-11-03 9:51 UTC (permalink / raw)
Send Names, Age, Occupation, Country.
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Dave Chinner @ 2010-11-03 10:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <1288768402.2467.665.camel@edumazet-laptop>
On Wed, Nov 03, 2010 at 08:13:22AM +0100, Eric Dumazet wrote:
> Le mercredi 03 novembre 2010 à 17:26 +1100, Dave Chinner a écrit :
> > Folks,
> >
> > Starting up KVM on a current mainline kernel using the tap
> > device for the networking is resulting in the ip process tryin gto
> > up the tap interface hanging. KVM is started with this networking
> > config:
> >
> > ....
> > -net nic,vlan=0,macaddr=00:e4:b6:63:63:6d,model=virtio \
> > -net tap,vlan=0,script=/vm-images/qemu-ifup,downscript=no \
> > ....
> >
> > And the script is effectively:
> >
> > switch=br0
> > if [ -n "$1" ];then
> > /usr/bin/sudo /sbin/ip link set $1 up
> > sleep 0.5s
> > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
> > exit 0
> > fi
> > exit 1
> >
> > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
> >
> > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
> > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
> > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
> >
> > In do_exit() with this trace:
> >
> > [ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
> > [ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
> > [ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
> > [ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
> > [ 1630.811324] Call Trace:
> > [ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
> > [ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
> > [ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
> > [ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
> >
> > The address comes down to the schedule() call:
> >
> > (gdb) l *(do_exit+0x716)
> > 0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
> > 1029 preempt_disable();
> > 1030 exit_rcu();
> > 1031 /* causes final put_task_struct in finish_task_switch(). */
> > 1032 tsk->state = TASK_DEAD;
> > 1033 schedule();
> > 1034 BUG();
> > 1035 /* Avoid "noreturn function does return". */
> > 1036 for (;;)
> > 1037 cpu_relax(); /* For when BUG is null */
> > 1038 }
> >
> > Needless to say, KVM is not starting up. This works just fine on
> > 2.6.35.1 and so is a regression. I can't do a lot of testing on this as
> > the host is the machine that hosts all my build and test environments....
> >
> > Cheers,
> >
> > Dave.
>
> Could it be the same problem than
>
> http://kerneltrap.com/mailarchive/linux-netdev/2010/10/23/6288128
>
> Try to revert bee31369ce16fc3898ec9a54161248c9eddb06bc ?
It's working fine on 2.6.36 right now, so it's something that came in
with the .37 merge cycle...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [RFC PATCH 1/1] vhost: TX used buffer guest signal accumulation
From: Michael S. Tsirkin @ 2010-11-03 10:48 UTC (permalink / raw)
To: Shirley Ma; +Cc: David Miller, netdev, kvm, linux-kernel
In-Reply-To: <1288642673.19173.8.camel@localhost.localdomain>
On Mon, Nov 01, 2010 at 01:17:53PM -0700, Shirley Ma wrote:
> On Sat, 2010-10-30 at 22:06 +0200, Michael S. Tsirkin wrote:
> > On Fri, Oct 29, 2010 at 08:43:08AM -0700, Shirley Ma wrote:
> > > On Fri, 2010-10-29 at 10:10 +0200, Michael S. Tsirkin wrote:
> > > > Hmm. I don't yet understand. We are still doing copies into the
> > per-vq
> > > > buffer, and the data copied is really small. Is it about cache
> > line
> > > > bounces? Could you try figuring it out?
> > >
> > > per-vq buffer is much less expensive than 3 put_copy() call. I will
> > > collect the profiling data to show that.
> >
> > What about __put_user? Maybe the access checks are the ones
> > that add the cost here? I attach patches to strip access checks:
> > they are not needed as we do them on setup time already, anyway.
> > Can you try them out and see if performance is improved for you
> > please?
> > On top of this, we will need to add some scheme to accumulate signals,
> > but that is a separate issue.
>
> Yes, moving from put_user/get_user to __put_user/__get_user does improve
> the performance by removing the checking.
I mean in practice, you see a benefit from this patch?
> My concern here is whether checking only in set up would be sufficient
> for security?
It better be sufficient because the checks that put_user does
are not effictive when run from the kernel thread, anyway.
> Would be there is a case guest could corrupt the ring
> later? If not, that's OK.
You mean change the pointer after it's checked?
If you see such a case, please holler.
> > > > > > 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
> > > >
> > > > BTW why do we need another array? Isn't heads field exactly what
> > we
> > > > need
> > > > here?
> > >
> > > head field is only for up to 32, the more used buffers add and
> > signal
> > > accumulated the better performance is from test results.
> >
> > I think we should separate the used update and signalling. Interrupts
> > are expensive so I can believe accumulating even up to 100 of them
> > helps. But used head copies are already prety cheap. If we cut the
> > overhead by x32, that should make them almost free?
>
> I can separate the used update and signaling to see the best
> performance.
>
> > > That's was one
> > > of the reason I didn't use heads. The other reason was I used these
> > > buffer for pending dma done in mavctap zero copy patch. It could be
> > up
> > > to vq->num in worse case.
> >
> > We can always increase that, not an issue.
>
> Good, I will change heads up to vq->num and use it.
>
> Thanks
> Shirley
To clarify: the combination of __put_user and separate
signalling is giving the same performance benefit as your
patch?
I am mostly concerned with adding code that seems to help
speed for reasons we don't completely understand, because
then we might break the optimization easily without noticing.
--
MST
^ permalink raw reply
* Re: [regression, 2.6.37-rc1] 'ip link tap0 up' stuck in do_exit()
From: Dave Chinner @ 2010-11-03 11:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: linux-kernel, netdev
In-Reply-To: <20101103103448.GA9169@dastard>
On Wed, Nov 03, 2010 at 09:34:48PM +1100, Dave Chinner wrote:
> On Wed, Nov 03, 2010 at 08:13:22AM +0100, Eric Dumazet wrote:
> > Le mercredi 03 novembre 2010 à 17:26 +1100, Dave Chinner a écrit :
> > > Folks,
> > >
> > > Starting up KVM on a current mainline kernel using the tap
> > > device for the networking is resulting in the ip process tryin gto
> > > up the tap interface hanging. KVM is started with this networking
> > > config:
> > >
> > > ....
> > > -net nic,vlan=0,macaddr=00:e4:b6:63:63:6d,model=virtio \
> > > -net tap,vlan=0,script=/vm-images/qemu-ifup,downscript=no \
> > > ....
> > >
> > > And the script is effectively:
> > >
> > > switch=br0
> > > if [ -n "$1" ];then
> > > /usr/bin/sudo /sbin/ip link set $1 up
> > > sleep 0.5s
> > > /usr/bin/sudo /usr/sbin/brctl addif $switch $1
> > > exit 0
> > > fi
> > > exit 1
> > >
> > > This is resulting in the command 'ip link set tap0 up' hanging as a zombie:
> > >
> > > root 3005 1 0 16:53 pts/3 00:00:00 /bin/sh /vm-images/qemu-ifup tap0
> > > root 3011 3005 0 16:53 pts/3 00:00:00 /usr/bin/sudo /sbin/ip link set tap0 up
> > > root 3012 3011 0 16:53 pts/3 00:00:00 [ip] <defunct>
> > >
> > > In do_exit() with this trace:
> > >
> > > [ 1630.782255] ip x ffff88063fcb3600 0 3012 3011 0x00000000
> > > [ 1630.789121] ffff880631328000 0000000000000046 0000000000000000 ffff880633104380
> > > [ 1630.796524] 0000000000013600 ffff88062f031fd8 0000000000013600 0000000000013600
> > > [ 1630.803925] ffff8806313282d8 ffff8806313282e0 ffff880631328000 0000000000013600
> > > [ 1630.811324] Call Trace:
> > > [ 1630.813760] [<ffffffff8104a90d>] ? do_exit+0x716/0x724
> > > [ 1630.818964] [<ffffffff8104a995>] ? do_group_exit+0x7a/0xa4
> > > [ 1630.824512] [<ffffffff8104a9d1>] ? sys_exit_group+0x12/0x16
> > > [ 1630.830149] [<ffffffff81009a82>] ? system_call_fastpath+0x16/0x1b
> > >
> > > The address comes down to the schedule() call:
> > >
> > > (gdb) l *(do_exit+0x716)
> > > 0xffffffff8104a90d is in do_exit (kernel/exit.c:1034).
> > > 1029 preempt_disable();
> > > 1030 exit_rcu();
> > > 1031 /* causes final put_task_struct in finish_task_switch(). */
> > > 1032 tsk->state = TASK_DEAD;
> > > 1033 schedule();
> > > 1034 BUG();
> > > 1035 /* Avoid "noreturn function does return". */
> > > 1036 for (;;)
> > > 1037 cpu_relax(); /* For when BUG is null */
> > > 1038 }
> > >
> > > Needless to say, KVM is not starting up. This works just fine on
> > > 2.6.35.1 and so is a regression. I can't do a lot of testing on this as
> > > the host is the machine that hosts all my build and test environments....
> > >
> > > Cheers,
> > >
> > > Dave.
> >
> > Could it be the same problem than
> >
> > http://kerneltrap.com/mailarchive/linux-netdev/2010/10/23/6288128
> >
> > Try to revert bee31369ce16fc3898ec9a54161248c9eddb06bc ?
>
> It's working fine on 2.6.36 right now, so it's something that came in
> with the .37 merge cycle...
Actually, the machine isn't running a 2.6.36 kernel (it had booted
to the working .35 kernel and I didn't notice). So i've just tested
a 2.6.36 kernel, and the problem _is present_ in 2.6.36. I've
reverted the above commit but that does not fix the problem.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X
From: Michael Ellerman @ 2010-11-03 12:45 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: David Miller, bhutchings, somnath.kotur, netdev, linux-pci
In-Reply-To: <20101030232155.GA14129@parisc-linux.org>
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
On Sat, 2010-10-30 at 17:21 -0600, Matthew Wilcox wrote:
> On Tue, Oct 26, 2010 at 05:52:08PM +1100, Michael Ellerman wrote:
> > That horse has really really bolted, it's gawn.
> >
> > I count 26 drivers with "disable MSI/X" parameters. Some even have more
> > than one.
>
> That's 26 patches someone needs to write, then. You can put my Acked-by
> on all of them.
Bah, come on it's hardly the most horrendous sin committed by driver
writers. And removing them risks breaking someone's system, even if they
are clueless, should RTFM etc.
> > I agree it's a mess for users, but it's probably preferable to a
> > non-working driver.
>
> What more drivers need is an automatic detection of a non-working
> interrupt situation, great big warning messages, and fallback to an
> alternate interrupt mechanism. Doing it for one driver, then generalising
> as much of it into the core as possible would be nice.
More detection would be good.
I don't see much potential for generalising it though. Looking at e1000e
and tg3 there is really not much in common except the very basic idea.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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