* Re: [PATCH 1/7] netpoll: use GFP_ATOMIC in slave_enable_netpoll() and __netpoll_setup()
From: Eric Dumazet @ 2012-08-03 9:17 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, David S. Miller, Jay Vosburgh, Andy Gospodarek,
Eric Dumazet, Cong Wang, Joe Perches, Neil Horman, linux-kernel
In-Reply-To: <1343403484-29347-2-git-send-email-amwang@redhat.com>
On Fri, 2012-07-27 at 23:37 +0800, Cong Wang wrote:
> slave_enable_netpoll() and __netpoll_setup() may be called
> with read_lock() held, so should use GFP_ATOMIC to allocate
> memory.
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Cong Wang <amwang@redhat.com>
> ---
> drivers/net/bonding/bond_main.c | 2 +-
> net/core/netpoll.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 6fae5f3..ab773d4 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1235,7 +1235,7 @@ static inline int slave_enable_netpoll(struct slave *slave)
> struct netpoll *np;
> int err = 0;
>
> - np = kzalloc(sizeof(*np), GFP_KERNEL);
> + np = kzalloc(sizeof(*np), GFP_ATOMIC);
> err = -ENOMEM;
> if (!np)
> goto out;
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index b4c90e4..c78a966 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -734,7 +734,7 @@ int __netpoll_setup(struct netpoll *np, struct net_device *ndev)
> }
>
> if (!ndev->npinfo) {
> - npinfo = kmalloc(sizeof(*npinfo), GFP_KERNEL);
> + npinfo = kmalloc(sizeof(*npinfo), GFP_ATOMIC);
> if (!npinfo) {
> err = -ENOMEM;
> goto out;
Yes this works, but maybe you instead could pass/add a gfp_t flags
argument to __netpoll_setup() ?
Management tasks should allow GFP_KERNEL allocations to have less
failure risks.
Its sad bonding uses the rwlock here instead of a mutex
^ permalink raw reply
* [PATCH v3] isdnloop: fix and simplify isdnloop_init()
From: Fengguang Wu @ 2012-08-03 9:10 UTC (permalink / raw)
To: David Miller
Cc: netdev, dan.carpenter, gregkh, devel, joe, isdn, linux-kernel
In-Reply-To: <20120803.015126.198679260163049459.davem@davemloft.net>
Fix a buffer overflow bug by removing the revision and printk.
[ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
[ 22.097508] isdnloop: (loop0) virtual card added
[ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
[ 22.174400]
[ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
[ 22.624071] Call Trace:
[ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
[ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
[ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
[ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
drivers/isdn/isdnloop/isdnloop.c | 12 ------------
1 file changed, 12 deletions(-)
--- linux.orig/drivers/isdn/isdnloop/isdnloop.c 2012-08-03 16:39:08.543650310 +0800
+++ linux/drivers/isdn/isdnloop/isdnloop.c 2012-08-03 17:08:07.515691639 +0800
@@ -16,7 +16,6 @@
#include <linux/sched.h>
#include "isdnloop.h"
-static char *revision = "$Revision: 1.11.6.7 $";
static char *isdnloop_id = "loop0";
MODULE_DESCRIPTION("ISDN4Linux: Pseudo Driver that simulates an ISDN card");
@@ -1494,17 +1493,6 @@ isdnloop_addcard(char *id1)
static int __init
isdnloop_init(void)
{
- char *p;
- char rev[10];
-
- if ((p = strchr(revision, ':'))) {
- strcpy(rev, p + 1);
- p = strchr(rev, '$');
- *p = 0;
- } else
- strcpy(rev, " ??? ");
- printk(KERN_NOTICE "isdnloop-ISDN-driver Rev%s\n", rev);
-
if (isdnloop_id)
return (isdnloop_addcard(isdnloop_id));
^ permalink raw reply
* Re: Premature timeout for MLDv1 Host compatibility mode?
From: Dragos Ilie @ 2012-08-03 8:54 UTC (permalink / raw)
To: David Stevens; +Cc: netdev, netdev-owner
In-Reply-To: <OFA8EDA0BC.A9D42E39-ON85257A4E.004ECE32-85257A4E.004F3FC7@us.ibm.com>
Hi David,
I have been thinking about how to address your concerns about the
MLDv1-mode timeout. Unfortunately, I think by doing that we would stop
being compliant with RFC 3810 on the following points:
a) Section 5.1.9 states that the QQIC field is meant for other
multicast routers that are not the current querier. I "grep-ed" after
mld2q_qqic in the entire kernel source tree and it is not being used
at all. I take this as a sign that the field is not to be interpreted
by listeners. Of course, that does not mean we cannot use it, but see
b) below
b) Section 8.3.1 says that "if an MLDv1 router is present on the link,
the Querier MUST use the lowest version of MLD present on the
network". Also, "if an MLDv1 router is present on the link, the system
administrator must explicitly configure all MLDv2 routers to act in
MLDv1 mode". It seems to me that these statements together preclude a
scenario with MLDv1 and MLDv2 routers mixed together on the same link,
unless all routers speak MLDv1.
The current implementation for MLDv1 compatibility mode works very
badly. The listeners fail most of the time to join the groups on the
MLDv1 server. I suggest that my patch sent earlier this week is
pushed upstream, unless there are concerns that it will make things
worse than they are today. This will improve the behavior of MLDv2
listeners with MLDv1 routers and keep us compliant with the RFC. What
do you think?
On Thu, Aug 2, 2012 at 4:25 PM, David Stevens <dlstevens@us.ibm.com> wrote:
> netdev-owner@vger.kernel.org wrote on 08/02/2012 10:03:24 AM:
>
>> > The QQIC would come from v2 queries prior to the v1 query that
>> > triggered us to switch to v1. But, see below.
>>
>> How about the scenario where you have only MLDv1 queriers? There will
>> be no prior v2 query
>
> Yes, this is why I suggested initializing it to the
> default of 125. If we actually saw v2 queries with different
> intervals, we'd adjust longer or shorter, but use the default
> only when we had no queries to update it.
>
> +-DLS
>
> --
> 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: remove parentheses in return statement
From: David Miller @ 2012-08-03 8:52 UTC (permalink / raw)
To: sakiwit; +Cc: netdev
In-Reply-To: <1343979790-17408-1-git-send-email-sakiwit@gmail.com>
From: Jean Sacren <sakiwit@gmail.com>
Date: Fri, 3 Aug 2012 01:43:10 -0600
> It is always wrong to write 'return (...)'.
In your imagination.
> After removal, realign the code where necessary.
>
> Signed-off-by: Jean Sacren <sakiwit@gmail.com>
> - return ((val ^ (val >> 8) ^ (val >> 16) ^ (val >> 24)) &
> - (IN4_ADDR_HSIZE - 1));
> + return (val ^ (val >> 8) ^ (val >> 16) ^ (val >> 24)) &
> + (IN4_ADDR_HSIZE - 1);
Those parenthesis are there to make the evaluation order and
grouping explicit.
The other ones you changed are wrong for similar reasons.
I absolutely am not applying patches like this.
^ permalink raw reply
* Re: skb_warn_bad_offload with kernel 3.5 (maybe gso/bridge related ?)
From: Eric Dumazet @ 2012-08-03 8:51 UTC (permalink / raw)
To: Yann Dupont; +Cc: netdev@vger.kernel.org, Ben Hutchings, Herbert Xu
In-Reply-To: <501B8792.6040605@univ-nantes.fr>
On Fri, 2012-08-03 at 10:10 +0200, Yann Dupont wrote:
> Hello everybody,
>
> I have a machine using ceph rbd volume, as a client (rbd module) to
> backup data.
>
> I was running kernel 3.2.22 ok. Tried 3.5.0 because some rbd fixes went in.
>
> Now, shortly after the start, my logs are filled by that :
>
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.780860]
> WARNING: at net/core/dev.c:1888 skb_warn_bad_offload+0xb6/0xc1()
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.780920]
> Hardware name: PowerEdge M605
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.780990] :
> caps=(0x0000000000005000, 0x0000000000000000) len=7292 data_len=5792
> gso_size=1448 gso_type=1 ip_summed=1
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.781071]
> Modules linked in: rbd libceph ipt_MASQUERADE iptable_nat nf_nat
> ipt_REJECT veth fuse xt_physdev xt_iprange xt_multiport ip6table_filter
> ip6_tables xt_LOG xt_limit xt_tcpudp xt_state iptable_filter ip_tables
> x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4
> nf_defrag_ipv4 8021q bridge stp llc ext2 mbcache dm_round_robin
> dm_multipath scsi_dh nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6
> powernow_k8 freq_table mperf kvm_amd snd_pcm kvm snd_timer snd soundcore
> snd_page_alloc tpm_tis tpm tpm_bios pcspkr evdev psmouse microcode
> joydev dcdbas shpchp i2c_nforce2 pci_hotplug serio_raw processor
> i2c_core hid_generic thermal_sys hed button xfs exportfs dm_mod ses
> enclosure usbhid hid sg sr_mod sd_mod cdrom usb_storage lpfc
> scsi_transport_fc scsi_tgt ohci_hcd bnx2x mptsas mptscsih bnx2 mptbase
> scsi_transport_sas crc32c scsi_mod libcrc32c mdio ehci_hcd [last
> unloaded: scsi_wait_scan]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.785995]
> Pid: 0, comm: swapper/0 Not tainted 3.5.0-dsiun-120521 #5
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786055]
> Call Trace:
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786108]
> <IRQ> [<ffffffff813bde00>] ? skb_warn_bad_offload+0x6f/0xc1
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786209]
> [<ffffffff8103a109>] ? warn_slowpath_common+0x79/0xc0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786269]
> [<ffffffff8103a205>] ? warn_slowpath_fmt+0x45/0x50
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786330]
> [<ffffffff81068647>] ? get_nohz_timer_target+0x57/0xd0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786390]
> [<ffffffff813bde47>] ? skb_warn_bad_offload+0xb6/0xc1
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786452]
> [<ffffffff813110e7>] ? skb_gso_segment+0x207/0x280
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786512]
> [<ffffffff81313f26>] ? dev_hard_start_xmit+0x1f6/0x620
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786574]
> [<ffffffff8132f17d>] ? sch_direct_xmit+0xfd/0x1d0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786633]
> [<ffffffff813147a4>] ? dev_queue_xmit+0x454/0x610
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786697]
> [<ffffffffa06f3c42>] ? br_dev_queue_push_xmit+0x72/0xc0 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786762]
> [<ffffffffa06fa673>] ? br_nf_post_routing+0x223/0x340 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786825]
> [<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786885]
> [<ffffffffa06f3bd0>] ? deliver_clone+0x60/0x60 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786945]
> [<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787005]
> [<ffffffffa06f3bd0>] ? deliver_clone+0x60/0x60 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787067]
> [<ffffffffa06f3f00>] ? br_multicast_flood+0x170/0x170 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787130]
> [<ffffffffa06f3f42>] ? br_forward_finish+0x42/0x50 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787193]
> [<ffffffffa06f9f29>] ? br_nf_forward_finish+0xb9/0x180 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787256]
> [<ffffffffa06faa21>] ? br_nf_forward_ip+0x291/0x3d0 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787318]
> [<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787379]
> [<ffffffffa06a301f>] ? tcp_packet+0x82f/0xf10 [nf_conntrack]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787442]
> [<ffffffffa06f3f00>] ? br_multicast_flood+0x170/0x170 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787503]
> [<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787563]
> [<ffffffffa06f3f00>] ? br_multicast_flood+0x170/0x170 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787626]
> [<ffffffffa06f3fe0>] ? __br_forward+0x90/0xb0 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787688]
> [<ffffffffa06f4e34>] ? br_handle_frame_finish+0x214/0x2b0 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787765]
> [<ffffffffa06fa2ab>] ? br_nf_pre_routing_finish+0x19b/0x340 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787842]
> [<ffffffffa06fb0f2>] ? br_nf_pre_routing+0x3a2/0x650 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787904]
> [<ffffffff8108b184>] ? generic_exec_single+0xb4/0xc0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787964]
> [<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788025]
> [<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788087]
> [<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788147]
> [<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788210]
> [<ffffffffa06f5098>] ? br_handle_frame+0x1c8/0x260 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788273]
> [<ffffffffa06f4ed0>] ? br_handle_frame_finish+0x2b0/0x2b0 [bridge]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788348]
> [<ffffffff813121b8>] ? __netif_receive_skb+0x418/0x5a0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788409]
> [<ffffffffa0736954>] ? ipt_do_table+0x344/0x5e0 [ip_tables]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788470]
> [<ffffffff813124ca>] ? netif_receive_skb+0x1a/0x80
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788530]
> [<ffffffff81312620>] ? napi_skb_finish+0x50/0x70
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788599]
> [<ffffffffa0126bc6>] ? bnx2x_rx_int+0x656/0x13d0 [bnx2x]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788671]
> [<ffffffffa01994ae>] ? lpfc_sli_handle_fast_ring_event+0x26e/0x5d0 [lpfc]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788748]
> [<ffffffffa071abf5>] ? ipv4_confirm+0x175/0x200 [nf_conntrack_ipv4]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788828]
> [<ffffffffa0129073>] ? bnx2x_poll+0x93/0x2b0 [bnx2x]
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788889]
> [<ffffffff81312e98>] ? net_rx_action+0x138/0x220
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788949]
> [<ffffffff810424ae>] ? __do_softirq+0xae/0x1c0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789009]
> [<ffffffff813c281c>] ? call_softirq+0x1c/0x30
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789068]
> [<ffffffff81004b95>] ? do_softirq+0x75/0xb0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789127]
> [<ffffffff81042845>] ? irq_exit+0xa5/0xb0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789185]
> [<ffffffff8100480b>] ? do_IRQ+0x5b/0xd0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789243]
> [<ffffffff813c0aea>] ? common_interrupt+0x6a/0x6a
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789301]
> <EOI> [<ffffffff8104ac21>] ? get_next_timer_interrupt+0x1e1/0x280
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789414]
> [<ffffffff8102ab82>] ? native_safe_halt+0x2/0x10
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789474]
> [<ffffffff8100b847>] ? default_idle+0x47/0x190
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789533]
> [<ffffffff8100b9e0>] ? amd_e400_idle+0x50/0x110
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789593]
> [<ffffffff8100c466>] ? cpu_idle+0xb6/0xd0
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789651]
> [<ffffffff8157fb77>] ? start_kernel+0x366/0x371
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789711]
> [<ffffffff8157f627>] ? repair_env_string+0x5b/0x5b
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789771]
> [<ffffffff8157f436>] ? x86_64_start_kernel+0x105/0x114
> Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789831]
> ---[ end trace ad41e3fec21667dd ]---
>
>
> Shorter traces :
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537129]
> WARNING: at net/core/dev.c:1888 skb_warn_bad_offload+0xb6/0xc1()
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537156]
> Hardware name: PowerEdge M605
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537178] :
> caps=(0x0000000000005000, 0x0000000000000000) len=23220 data_len=21720
> gso_size=1448 gso_type=1 ip_summed=1
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537226]
> Modules linked in: rbd libceph ipt_MASQUERADE iptable_nat nf_nat
> ipt_REJECT veth fuse xt_physdev xt_iprange xt_multiport ip6table_filter
> ip6_tables xt_LOG xt_limit xt_tcpudp xt_state iptable_filter ip_tables
> x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4
> nf_defrag_ipv4 8021q bridge stp llc ext2 mbcache dm_round_robin
> dm_multipath scsi_dh nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6
> powernow_k8 freq_table mperf kvm_amd snd_pcm kvm snd_timer snd soundcore
> snd_page_alloc tpm_tis tpm tpm_bios pcspkr evdev psmouse microcode
> joydev dcdbas shpchp i2c_nforce2 pci_hotplug serio_raw processor
> i2c_core hid_generic thermal_sys hed button xfs exportfs dm_mod ses
> enclosure usbhid hid sg sr_mod sd_mod cdrom usb_storage lpfc
> scsi_transport_fc scsi_tgt ohci_hcd bnx2x mptsas mptscsih bnx2 mptbase
> scsi_transport_sas crc32c scsi_mod libcrc32c mdio ehci_hcd [last
> unloaded: scsi_wait_scan]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537632]
> Pid: 22553, comm: smtp Tainted: G W 3.5.0-dsiun-120521 #5
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537673]
> Call Trace:
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537691]
> <IRQ> [<ffffffff813bde00>] ? skb_warn_bad_offload+0x6f/0xc1
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537720]
> [<ffffffff8103a109>] ? warn_slowpath_common+0x79/0xc0
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537747]
> [<ffffffff8103a205>] ? warn_slowpath_fmt+0x45/0x50
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537773]
> [<ffffffff813bde47>] ? skb_warn_bad_offload+0xb6/0xc1
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537800]
> [<ffffffff813110e7>] ? skb_gso_segment+0x207/0x280
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537826]
> [<ffffffff81313f26>] ? dev_hard_start_xmit+0x1f6/0x620
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537853]
> [<ffffffff8132f17d>] ? sch_direct_xmit+0xfd/0x1d0
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537879]
> [<ffffffff813147a4>] ? dev_queue_xmit+0x454/0x610
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537907]
> [<ffffffffa06f3c42>] ? br_dev_queue_push_xmit+0x72/0xc0 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537937]
> [<ffffffffa06fa673>] ? br_nf_post_routing+0x223/0x340 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.538103]
> [<ffffffffa06f3f42>] ? br_forward_finish+0x42/0x50 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.538132]
> [<ffffffffa06f9f29>] ? br_nf_forward_finish+0xb9/0x180 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.538704]
> [<ffffffff813124ca>] ? netif_receive_skb+0x1a/0x80
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539024]
> <EOI>
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539162] :
> caps=(0x0000000000005000, 0x0000000000000000) len=6250 data_len=4750
> gso_size=1448 gso_type=1 ip_summed=1
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539209]
> Modules linked in: rbd libceph ipt_MASQUERADE iptable_nat nf_nat
> ipt_REJECT veth fuse xt_physdev xt_iprange xt_multiport ip6table_filter
> ip6_tables xt_LOG xt_limit xt_tcpudp xt_state iptable_filter ip_tables
> x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4
> nf_defrag_ipv4 8021q bridge stp llc ext2 mbcache dm_round_robin
> dm_multipath scsi_dh nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6
> powernow_k8 freq_table mperf kvm_amd snd_pcm kvm snd_timer snd soundcore
> snd_page_alloc tpm_tis tpm tpm_bios pcspkr evdev psmouse microcode
> joydev dcdbas shpchp i2c_nforce2 pci_hotplug serio_raw processor
> i2c_core hid_generic thermal_sys hed button xfs exportfs dm_mod ses
> enclosure usbhid hid sg sr_mod sd_mod cdrom usb_storage lpfc
> scsi_transport_fc scsi_tgt ohci_hcd bnx2x mptsas mptscsih bnx2 mptbase
> scsi_transport_sas crc32c scsi_mod libcrc32c mdio ehci_hcd [last
> unloaded: scsi_wait_scan]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539614]
> Pid: 22553, comm: smtp Tainted: G W 3.5.0-dsiun-120521 #5
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539654]
> Call Trace:
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539673]
> <IRQ> [<ffffffff813bde00>] ? skb_warn_bad_offload+0x6f/0xc1
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539702]
> [<ffffffff8103a109>] ? warn_slowpath_common+0x79/0xc0
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539728]
> [<ffffffff8103a205>] ? warn_slowpath_fmt+0x45/0x50
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539755]
> [<ffffffff813bde47>] ? skb_warn_bad_offload+0xb6/0xc1
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539782]
> [<ffffffff813110e7>] ? skb_gso_segment+0x207/0x280
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539808]
> [<ffffffff81313f26>] ? dev_hard_start_xmit+0x1f6/0x620
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.540933]
> [<ffffffff81042845>] ? irq_exit+0xa5/0xb0
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543067]
> [<ffffffff813147a4>] ? dev_queue_xmit+0x454/0x610
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543095]
> [<ffffffffa06f3c42>] ? br_dev_queue_push_xmit+0x72/0xc0 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543125]
> [<ffffffffa06fa673>] ? br_nf_post_routing+0x223/0x340 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543514]
> [<ffffffffa06f3fe0>] ? __br_forward+0x90/0xb0 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543585]
> [<ffffffffa06fa2ab>] ? br_nf_pre_routing_finish+0x19b/0x340 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543629]
> [<ffffffffa06fb0f2>] ? br_nf_pre_routing+0x3a2/0x650 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543657]
> [<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543684]
> [<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543712]
> [<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543739]
> [<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543767]
> [<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
> Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543795]
> [<ffffffffa06f5098>] ? br_handle_frame+0x1c8/0x260 [bridge]
>
> Despite thoses messages, the machine is still running OK. It runs lxc
> instances (and so , bridge & tun/tap), only one of thoses instances uses
> rbd.
>
> I don't think the problem is ceph related.
>
> This machine have bnx2 (Gb) & bnx2x (10Gb) - Lots of trafic is using
> bnx2x-.
>
> I'm running 3.5.0 on other hosts (bnx2/bnx2x or ixgbe drivers) without
> problems. But it's not the same workload.
>
> As the problem seems more or less gso related, I've deactivated gso two
> days ago. This cure the symptom, running ok since.
>
> Anyone here seeing this problem ?
>
> Cheers,
>
I dont know, maybe its more a GRO issue ?
When a NIC delivers skbs with ip_summed set to CHECKSUM_UNNECESSARY,
should resulting GRO packet have ip_summed set to CHECKSUM_PARTIAL ?
CC Ben and Herbert
^ permalink raw reply
* Re: [PATCH v2] isdnloop: fix and simplify isdnloop_init()
From: David Miller @ 2012-08-03 8:51 UTC (permalink / raw)
To: fengguang.wu
Cc: netdev, dan.carpenter, gregkh, devel, joe, isdn, linux-kernel
In-Reply-To: <20120803073240.GA12723@localhost>
From: Fengguang Wu <fengguang.wu@intel.com>
Date: Fri, 3 Aug 2012 15:32:40 +0800
> On Thu, Aug 02, 2012 at 04:21:56PM -0700, David Miller wrote:
>> From: Fengguang Wu <fengguang.wu@intel.com>
>> Date: Thu, 2 Aug 2012 19:05:43 +0800
>>
>> > Fix a buffer overflow bug by removing the revision transform code.
>> >
>> > [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
>> > [ 22.097508] isdnloop: (loop0) virtual card added
>> > [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
>> > [ 22.174400]
>> > [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
>> > [ 22.624071] Call Trace:
>> > [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
>> > [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
>> > [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
>> > [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
>> > [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
>> > [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>> >
>> > Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>>
>> The reason the "$Revision ..." prefix is there is so that automated
>> version control tools will change the string automatically when code
>> is committed in CVS.
>>
>> In the GIT era this revision style is obsolete.
>>
>> Therefore you might as well just delete this crap altogether.
>
> OK. The below updated version will simply print the hard coded
> revision number as it's unlikely to change any more.
This is worse, I said delete this crap altogether.
^ permalink raw reply
* Re: [PATCH 0/4] net/mlx4: Fixes to mlx4 driver
From: David Miller @ 2012-08-03 8:50 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <953B660C027164448AE903364AC447D2871F0C73@MTLDAG01.mtl.com>
From: Yevgeny Petrilin <yevgenyp@mellanox.com>
Date: Fri, 3 Aug 2012 07:20:50 +0000
> Can you please apply the other 3 or should I resubmit them?
You should always resubmit the entire series when one of your patches
needs changes or is rejected.
^ permalink raw reply
* Re: [PATCH v2] isdnloop: fix and simplify isdnloop_init()
From: Karsten Keil @ 2012-08-03 8:47 UTC (permalink / raw)
To: Fengguang Wu
Cc: devel, isdn, netdev, linux-kernel, gregkh, joe, David Miller,
dan.carpenter
In-Reply-To: <20120803073240.GA12723@localhost>
Am 03.08.2012 09:32, schrieb Fengguang Wu:
> On Thu, Aug 02, 2012 at 04:21:56PM -0700, David Miller wrote:
>> From: Fengguang Wu <fengguang.wu@intel.com>
>> Date: Thu, 2 Aug 2012 19:05:43 +0800
>>
>>> Fix a buffer overflow bug by removing the revision transform code.
>>>
>>> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
>>> [ 22.097508] isdnloop: (loop0) virtual card added
>>> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
>>> [ 22.174400]
>>> [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
>>> [ 22.624071] Call Trace:
>>> [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
>>> [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
>>> [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
>>> [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
>>> [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
>>> [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>>>
>>> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>>
>> The reason the "$Revision ..." prefix is there is so that automated
>> version control tools will change the string automatically when code
>> is committed in CVS.
>>
>> In the GIT era this revision style is obsolete.
>>
>> Therefore you might as well just delete this crap altogether.
>
> OK. The below updated version will simply print the hard coded
> revision number as it's unlikely to change any more.
>
> Thanks,
> Fengguang
> ---
> isdnloop: fix and simplify isdnloop_init
>
> Fix a buffer overflow bug by hard coding the revision number.
>
> [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> [ 22.097508] isdnloop: (loop0) virtual card added
> [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
> [ 22.174400]
> [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> [ 22.624071] Call Trace:
> [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
> [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
> [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
> [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> ---
> drivers/isdn/isdnloop/isdnloop.c | 12 +-----------
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> --- linux.orig/drivers/isdn/isdnloop/isdnloop.c 2012-08-03 15:24:49.047544323 +0800
> +++ linux/drivers/isdn/isdnloop/isdnloop.c 2012-08-03 15:27:39.503548375 +0800
> @@ -16,7 +16,6 @@
> #include <linux/sched.h>
> #include "isdnloop.h"
>
> -static char *revision = "$Revision: 1.11.6.7 $";
> static char *isdnloop_id = "loop0";
>
> MODULE_DESCRIPTION("ISDN4Linux: Pseudo Driver that simulates an ISDN card");
> @@ -1494,16 +1493,7 @@ isdnloop_addcard(char *id1)
> static int __init
> isdnloop_init(void)
> {
> - char *p;
> - char rev[10];
> -
> - if ((p = strchr(revision, ':'))) {
> - strcpy(rev, p + 1);
> - p = strchr(rev, '$');
> - *p = 0;
> - } else
> - strcpy(rev, " ??? ");
> - printk(KERN_NOTICE "isdnloop-ISDN-driver Rev%s\n", rev);
> + printk(KERN_NOTICE "isdnloop-ISDN-driver Rev 1.11.6.7\n");
>
> if (isdnloop_id)
> return (isdnloop_addcard(isdnloop_id));
>
>
You could remove the revision completely, even from the printk.
Maybe use pr_notice("isdnloop-ISDN driver loaded\n");
Best Regards
Karsten
^ permalink raw reply
* RE: [PATCH] mlx4_en: add UFO support
From: Yevgeny Petrilin @ 2012-08-03 8:29 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo, David S. Miller
Cc: netdev@vger.kernel.org, Or Gerlitz
In-Reply-To: <1343940824-4720-1-git-send-email-cascardo@linux.vnet.ibm.com>
>
> Mellanox Ethernet adapters support Large Segmentation Offload for UDP
> packets. The only change needed is using the proper header size when the
> packet is UDP instead of TCP.
>
> This significantly increases performance for large UDP packets on platforms
> which have an expensive dma_map call, like pseries.
>
> On a simple test with 64000 payload size, throughput has increased from
> about 6Gbps to 9.5Gbps, while CPU use dropped from about 600% to about
> 80% or less, on a 8-core Power7 machine.
>
Hi Thadeu,
Can you please send the info regarding the adapter you are testing with? What test are you running?
I just tried this patch with netperf on my x86_64, and it doesn't work. Packets are not fragmented properly (fragment offsets are not calculated).
It is true that the TX side doesn't work as hard (OS doesn't need to do the fragmentation), but traffic is not sent properly on the wire.
I'll do further investigation and get back with more details.
Yevgeny
^ permalink raw reply
* skb_warn_bad_offload with kernel 3.5 (maybe gso/bridge related ?)
From: Yann Dupont @ 2012-08-03 8:10 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello everybody,
I have a machine using ceph rbd volume, as a client (rbd module) to
backup data.
I was running kernel 3.2.22 ok. Tried 3.5.0 because some rbd fixes went in.
Now, shortly after the start, my logs are filled by that :
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.780860]
WARNING: at net/core/dev.c:1888 skb_warn_bad_offload+0xb6/0xc1()
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.780920]
Hardware name: PowerEdge M605
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.780990] :
caps=(0x0000000000005000, 0x0000000000000000) len=7292 data_len=5792
gso_size=1448 gso_type=1 ip_summed=1
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.781071]
Modules linked in: rbd libceph ipt_MASQUERADE iptable_nat nf_nat
ipt_REJECT veth fuse xt_physdev xt_iprange xt_multiport ip6table_filter
ip6_tables xt_LOG xt_limit xt_tcpudp xt_state iptable_filter ip_tables
x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4
nf_defrag_ipv4 8021q bridge stp llc ext2 mbcache dm_round_robin
dm_multipath scsi_dh nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6
powernow_k8 freq_table mperf kvm_amd snd_pcm kvm snd_timer snd soundcore
snd_page_alloc tpm_tis tpm tpm_bios pcspkr evdev psmouse microcode
joydev dcdbas shpchp i2c_nforce2 pci_hotplug serio_raw processor
i2c_core hid_generic thermal_sys hed button xfs exportfs dm_mod ses
enclosure usbhid hid sg sr_mod sd_mod cdrom usb_storage lpfc
scsi_transport_fc scsi_tgt ohci_hcd bnx2x mptsas mptscsih bnx2 mptbase
scsi_transport_sas crc32c scsi_mod libcrc32c mdio ehci_hcd [last
unloaded: scsi_wait_scan]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.785995]
Pid: 0, comm: swapper/0 Not tainted 3.5.0-dsiun-120521 #5
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786055]
Call Trace:
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786108]
<IRQ> [<ffffffff813bde00>] ? skb_warn_bad_offload+0x6f/0xc1
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786209]
[<ffffffff8103a109>] ? warn_slowpath_common+0x79/0xc0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786269]
[<ffffffff8103a205>] ? warn_slowpath_fmt+0x45/0x50
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786330]
[<ffffffff81068647>] ? get_nohz_timer_target+0x57/0xd0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786390]
[<ffffffff813bde47>] ? skb_warn_bad_offload+0xb6/0xc1
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786452]
[<ffffffff813110e7>] ? skb_gso_segment+0x207/0x280
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786512]
[<ffffffff81313f26>] ? dev_hard_start_xmit+0x1f6/0x620
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786574]
[<ffffffff8132f17d>] ? sch_direct_xmit+0xfd/0x1d0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786633]
[<ffffffff813147a4>] ? dev_queue_xmit+0x454/0x610
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786697]
[<ffffffffa06f3c42>] ? br_dev_queue_push_xmit+0x72/0xc0 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786762]
[<ffffffffa06fa673>] ? br_nf_post_routing+0x223/0x340 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786825]
[<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786885]
[<ffffffffa06f3bd0>] ? deliver_clone+0x60/0x60 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.786945]
[<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787005]
[<ffffffffa06f3bd0>] ? deliver_clone+0x60/0x60 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787067]
[<ffffffffa06f3f00>] ? br_multicast_flood+0x170/0x170 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787130]
[<ffffffffa06f3f42>] ? br_forward_finish+0x42/0x50 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787193]
[<ffffffffa06f9f29>] ? br_nf_forward_finish+0xb9/0x180 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787256]
[<ffffffffa06faa21>] ? br_nf_forward_ip+0x291/0x3d0 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787318]
[<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787379]
[<ffffffffa06a301f>] ? tcp_packet+0x82f/0xf10 [nf_conntrack]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787442]
[<ffffffffa06f3f00>] ? br_multicast_flood+0x170/0x170 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787503]
[<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787563]
[<ffffffffa06f3f00>] ? br_multicast_flood+0x170/0x170 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787626]
[<ffffffffa06f3fe0>] ? __br_forward+0x90/0xb0 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787688]
[<ffffffffa06f4e34>] ? br_handle_frame_finish+0x214/0x2b0 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787765]
[<ffffffffa06fa2ab>] ? br_nf_pre_routing_finish+0x19b/0x340 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787842]
[<ffffffffa06fb0f2>] ? br_nf_pre_routing+0x3a2/0x650 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787904]
[<ffffffff8108b184>] ? generic_exec_single+0xb4/0xc0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.787964]
[<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788025]
[<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788087]
[<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788147]
[<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788210]
[<ffffffffa06f5098>] ? br_handle_frame+0x1c8/0x260 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788273]
[<ffffffffa06f4ed0>] ? br_handle_frame_finish+0x2b0/0x2b0 [bridge]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788348]
[<ffffffff813121b8>] ? __netif_receive_skb+0x418/0x5a0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788409]
[<ffffffffa0736954>] ? ipt_do_table+0x344/0x5e0 [ip_tables]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788470]
[<ffffffff813124ca>] ? netif_receive_skb+0x1a/0x80
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788530]
[<ffffffff81312620>] ? napi_skb_finish+0x50/0x70
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788599]
[<ffffffffa0126bc6>] ? bnx2x_rx_int+0x656/0x13d0 [bnx2x]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788671]
[<ffffffffa01994ae>] ? lpfc_sli_handle_fast_ring_event+0x26e/0x5d0 [lpfc]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788748]
[<ffffffffa071abf5>] ? ipv4_confirm+0x175/0x200 [nf_conntrack_ipv4]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788828]
[<ffffffffa0129073>] ? bnx2x_poll+0x93/0x2b0 [bnx2x]
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788889]
[<ffffffff81312e98>] ? net_rx_action+0x138/0x220
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.788949]
[<ffffffff810424ae>] ? __do_softirq+0xae/0x1c0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789009]
[<ffffffff813c281c>] ? call_softirq+0x1c/0x30
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789068]
[<ffffffff81004b95>] ? do_softirq+0x75/0xb0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789127]
[<ffffffff81042845>] ? irq_exit+0xa5/0xb0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789185]
[<ffffffff8100480b>] ? do_IRQ+0x5b/0xd0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789243]
[<ffffffff813c0aea>] ? common_interrupt+0x6a/0x6a
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789301]
<EOI> [<ffffffff8104ac21>] ? get_next_timer_interrupt+0x1e1/0x280
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789414]
[<ffffffff8102ab82>] ? native_safe_halt+0x2/0x10
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789474]
[<ffffffff8100b847>] ? default_idle+0x47/0x190
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789533]
[<ffffffff8100b9e0>] ? amd_e400_idle+0x50/0x110
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789593]
[<ffffffff8100c466>] ? cpu_idle+0xb6/0xd0
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789651]
[<ffffffff8157fb77>] ? start_kernel+0x366/0x371
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789711]
[<ffffffff8157f627>] ? repair_env_string+0x5b/0x5b
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789771]
[<ffffffff8157f436>] ? x86_64_start_kernel+0x105/0x114
Jul 31 18:15:01 singleton.u06.univ-nantes.prive kernel: [ 1175.789831]
---[ end trace ad41e3fec21667dd ]---
Shorter traces :
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537129]
WARNING: at net/core/dev.c:1888 skb_warn_bad_offload+0xb6/0xc1()
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537156]
Hardware name: PowerEdge M605
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537178] :
caps=(0x0000000000005000, 0x0000000000000000) len=23220 data_len=21720
gso_size=1448 gso_type=1 ip_summed=1
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537226]
Modules linked in: rbd libceph ipt_MASQUERADE iptable_nat nf_nat
ipt_REJECT veth fuse xt_physdev xt_iprange xt_multiport ip6table_filter
ip6_tables xt_LOG xt_limit xt_tcpudp xt_state iptable_filter ip_tables
x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4
nf_defrag_ipv4 8021q bridge stp llc ext2 mbcache dm_round_robin
dm_multipath scsi_dh nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6
powernow_k8 freq_table mperf kvm_amd snd_pcm kvm snd_timer snd soundcore
snd_page_alloc tpm_tis tpm tpm_bios pcspkr evdev psmouse microcode
joydev dcdbas shpchp i2c_nforce2 pci_hotplug serio_raw processor
i2c_core hid_generic thermal_sys hed button xfs exportfs dm_mod ses
enclosure usbhid hid sg sr_mod sd_mod cdrom usb_storage lpfc
scsi_transport_fc scsi_tgt ohci_hcd bnx2x mptsas mptscsih bnx2 mptbase
scsi_transport_sas crc32c scsi_mod libcrc32c mdio ehci_hcd [last
unloaded: scsi_wait_scan]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537632]
Pid: 22553, comm: smtp Tainted: G W 3.5.0-dsiun-120521 #5
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537673]
Call Trace:
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537691]
<IRQ> [<ffffffff813bde00>] ? skb_warn_bad_offload+0x6f/0xc1
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537720]
[<ffffffff8103a109>] ? warn_slowpath_common+0x79/0xc0
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537747]
[<ffffffff8103a205>] ? warn_slowpath_fmt+0x45/0x50
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537773]
[<ffffffff813bde47>] ? skb_warn_bad_offload+0xb6/0xc1
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537800]
[<ffffffff813110e7>] ? skb_gso_segment+0x207/0x280
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537826]
[<ffffffff81313f26>] ? dev_hard_start_xmit+0x1f6/0x620
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537853]
[<ffffffff8132f17d>] ? sch_direct_xmit+0xfd/0x1d0
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537879]
[<ffffffff813147a4>] ? dev_queue_xmit+0x454/0x610
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537907]
[<ffffffffa06f3c42>] ? br_dev_queue_push_xmit+0x72/0xc0 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.537937]
[<ffffffffa06fa673>] ? br_nf_post_routing+0x223/0x340 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.538103]
[<ffffffffa06f3f42>] ? br_forward_finish+0x42/0x50 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.538132]
[<ffffffffa06f9f29>] ? br_nf_forward_finish+0xb9/0x180 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.538704]
[<ffffffff813124ca>] ? netif_receive_skb+0x1a/0x80
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539024]
<EOI>
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539162] :
caps=(0x0000000000005000, 0x0000000000000000) len=6250 data_len=4750
gso_size=1448 gso_type=1 ip_summed=1
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539209]
Modules linked in: rbd libceph ipt_MASQUERADE iptable_nat nf_nat
ipt_REJECT veth fuse xt_physdev xt_iprange xt_multiport ip6table_filter
ip6_tables xt_LOG xt_limit xt_tcpudp xt_state iptable_filter ip_tables
x_tables nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv4
nf_defrag_ipv4 8021q bridge stp llc ext2 mbcache dm_round_robin
dm_multipath scsi_dh nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6
powernow_k8 freq_table mperf kvm_amd snd_pcm kvm snd_timer snd soundcore
snd_page_alloc tpm_tis tpm tpm_bios pcspkr evdev psmouse microcode
joydev dcdbas shpchp i2c_nforce2 pci_hotplug serio_raw processor
i2c_core hid_generic thermal_sys hed button xfs exportfs dm_mod ses
enclosure usbhid hid sg sr_mod sd_mod cdrom usb_storage lpfc
scsi_transport_fc scsi_tgt ohci_hcd bnx2x mptsas mptscsih bnx2 mptbase
scsi_transport_sas crc32c scsi_mod libcrc32c mdio ehci_hcd [last
unloaded: scsi_wait_scan]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539614]
Pid: 22553, comm: smtp Tainted: G W 3.5.0-dsiun-120521 #5
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539654]
Call Trace:
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539673]
<IRQ> [<ffffffff813bde00>] ? skb_warn_bad_offload+0x6f/0xc1
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539702]
[<ffffffff8103a109>] ? warn_slowpath_common+0x79/0xc0
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539728]
[<ffffffff8103a205>] ? warn_slowpath_fmt+0x45/0x50
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539755]
[<ffffffff813bde47>] ? skb_warn_bad_offload+0xb6/0xc1
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539782]
[<ffffffff813110e7>] ? skb_gso_segment+0x207/0x280
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.539808]
[<ffffffff81313f26>] ? dev_hard_start_xmit+0x1f6/0x620
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.540933]
[<ffffffff81042845>] ? irq_exit+0xa5/0xb0
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543067]
[<ffffffff813147a4>] ? dev_queue_xmit+0x454/0x610
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543095]
[<ffffffffa06f3c42>] ? br_dev_queue_push_xmit+0x72/0xc0 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543125]
[<ffffffffa06fa673>] ? br_nf_post_routing+0x223/0x340 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543514]
[<ffffffffa06f3fe0>] ? __br_forward+0x90/0xb0 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543585]
[<ffffffffa06fa2ab>] ? br_nf_pre_routing_finish+0x19b/0x340 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543629]
[<ffffffffa06fb0f2>] ? br_nf_pre_routing+0x3a2/0x650 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543657]
[<ffffffff8133c0c4>] ? nf_iterate+0x84/0xa0
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543684]
[<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543712]
[<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543739]
[<ffffffffa06f4c20>] ? br_handle_local_finish+0x50/0x50 [bridge]
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543767]
[<ffffffff8133c14e>] ? nf_hook_slow+0x6e/0x130
Aug 1 14:37:41 singleton.u06.univ-nantes.prive kernel: [74424.543795]
[<ffffffffa06f5098>] ? br_handle_frame+0x1c8/0x260 [bridge]
Despite thoses messages, the machine is still running OK. It runs lxc
instances (and so , bridge & tun/tap), only one of thoses instances uses
rbd.
I don't think the problem is ceph related.
This machine have bnx2 (Gb) & bnx2x (10Gb) - Lots of trafic is using
bnx2x-.
I'm running 3.5.0 on other hosts (bnx2/bnx2x or ixgbe drivers) without
problems. But it's not the same workload.
As the problem seems more or less gso related, I've deactivated gso two
days ago. This cure the symptom, running ok since.
Anyone here seeing this problem ?
Cheers,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* [PATCH] ipv4: remove parentheses in return statement
From: Jean Sacren @ 2012-08-03 7:43 UTC (permalink / raw)
To: netdev; +Cc: Jean Sacren
It is always wrong to write 'return (...)'.
After removal, realign the code where necessary.
Signed-off-by: Jean Sacren <sakiwit@gmail.com>
---
net/ipv4/devinet.c | 4 ++--
net/ipv4/inetpeer.c | 2 +-
net/ipv4/syncookies.c | 8 ++++----
net/ipv4/tcp_input.c | 16 ++++++++--------
net/ipv4/tcp_output.c | 2 +-
5 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 44bf82e..72b16e4 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -106,8 +106,8 @@ static inline unsigned int inet_addr_hash(struct net *net, __be32 addr)
{
u32 val = (__force u32) addr ^ hash_ptr(net, 8);
- return ((val ^ (val >> 8) ^ (val >> 16) ^ (val >> 24)) &
- (IN4_ADDR_HSIZE - 1));
+ return (val ^ (val >> 8) ^ (val >> 16) ^ (val >> 24)) &
+ (IN4_ADDR_HSIZE - 1);
}
static void inet_hash_insert(struct net *net, struct in_ifaddr *ifa)
diff --git a/net/ipv4/inetpeer.c b/net/ipv4/inetpeer.c
index e1e0a4e..8049ce0 100644
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -96,7 +96,7 @@ static atomic_t v6_seq = ATOMIC_INIT(0);
static atomic_t *inetpeer_seq_ptr(int family)
{
- return (family == AF_INET ? &v4_seq : &v6_seq);
+ return (family == AF_INET) ? &v4_seq : &v6_seq;
}
static inline void flush_check(struct inet_peer_base *base, int family)
diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
index 650e152..cb9c489 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -103,10 +103,10 @@ static __u32 secure_tcp_syn_cookie(__be32 saddr, __be32 daddr, __be16 sport,
* MSS into the second hash value.
*/
- return (cookie_hash(saddr, daddr, sport, dport, 0, 0) +
- sseq + (count << COOKIEBITS) +
- ((cookie_hash(saddr, daddr, sport, dport, count, 1) + data)
- & COOKIEMASK));
+ return cookie_hash(saddr, daddr, sport, dport, 0, 0) +
+ sseq + (count << COOKIEBITS) +
+ ((cookie_hash(saddr, daddr, sport, dport, count, 1) + data)
+ & COOKIEMASK);
}
/*
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 2fd2bc9..1d220f9 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3993,17 +3993,17 @@ static int tcp_disordered_ack(const struct sock *sk, const struct sk_buff *skb)
u32 seq = TCP_SKB_CB(skb)->seq;
u32 ack = TCP_SKB_CB(skb)->ack_seq;
- return (/* 1. Pure ACK with correct sequence number. */
- (th->ack && seq == TCP_SKB_CB(skb)->end_seq && seq == tp->rcv_nxt) &&
+ return /* 1. Pure ACK with correct sequence number. */
+ (th->ack && seq == TCP_SKB_CB(skb)->end_seq && seq == tp->rcv_nxt) &&
- /* 2. ... and duplicate ACK. */
- ack == tp->snd_una &&
+ /* 2. ... and duplicate ACK. */
+ ack == tp->snd_una &&
- /* 3. ... and does not update window. */
- !tcp_may_update_window(tp, ack, seq, ntohs(th->window) << tp->rx_opt.snd_wscale) &&
+ /* 3. ... and does not update window. */
+ !tcp_may_update_window(tp, ack, seq, ntohs(th->window) << tp->rx_opt.snd_wscale) &&
- /* 4. ... and sits in replay window. */
- (s32)(tp->rx_opt.ts_recent - tp->rx_opt.rcv_tsval) <= (inet_csk(sk)->icsk_rto * 1024) / HZ);
+ /* 4. ... and sits in replay window. */
+ (s32)(tp->rx_opt.ts_recent - tp->rx_opt.rcv_tsval) <= (inet_csk(sk)->icsk_rto * 1024) / HZ;
}
static inline bool tcp_paws_discard(const struct sock *sk,
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a7b3ec9..eac214c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1557,7 +1557,7 @@ static inline unsigned int tcp_cwnd_test(const struct tcp_sock *tp,
in_flight = tcp_packets_in_flight(tp);
cwnd = tp->snd_cwnd;
if (in_flight < cwnd)
- return (cwnd - in_flight);
+ return cwnd - in_flight;
return 0;
}
^ permalink raw reply related
* RFC3484: default address selection malfunctioning
From: BALAKUMARAN KANNAN @ 2012-08-03 7:35 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi all,
In Default address selction, From DNS query, the destination addresses are both a site local and a link scope addresses. the source addresses a site local address and a global address. So while pinging to the host(with name) according to RFC3484, the kernel should select the link local destination address and link local source address right? But linux kernel-3.0.26 is using the global address as source address and site local as destination address.
Why? is it a bug? And the DNS server address is a site local address. Had a default router with link local address
Thank you.
^ permalink raw reply
* [PATCH v2] isdnloop: fix and simplify isdnloop_init()
From: Fengguang Wu @ 2012-08-03 7:32 UTC (permalink / raw)
To: David Miller
Cc: devel, isdn, netdev, linux-kernel, gregkh, joe, dan.carpenter
In-Reply-To: <20120802.162156.1853851468137303302.davem@davemloft.net>
On Thu, Aug 02, 2012 at 04:21:56PM -0700, David Miller wrote:
> From: Fengguang Wu <fengguang.wu@intel.com>
> Date: Thu, 2 Aug 2012 19:05:43 +0800
>
> > Fix a buffer overflow bug by removing the revision transform code.
> >
> > [ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
> > [ 22.097508] isdnloop: (loop0) virtual card added
> > [ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
> > [ 22.174400]
> > [ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
> > [ 22.624071] Call Trace:
> > [ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> > [ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
> > [ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
> > [ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
> > [ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
> > [ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
> >
> > Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>
> The reason the "$Revision ..." prefix is there is so that automated
> version control tools will change the string automatically when code
> is committed in CVS.
>
> In the GIT era this revision style is obsolete.
>
> Therefore you might as well just delete this crap altogether.
OK. The below updated version will simply print the hard coded
revision number as it's unlikely to change any more.
Thanks,
Fengguang
---
isdnloop: fix and simplify isdnloop_init
Fix a buffer overflow bug by hard coding the revision number.
[ 22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
[ 22.097508] isdnloop: (loop0) virtual card added
[ 22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
[ 22.174400]
[ 22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
[ 22.624071] Call Trace:
[ 22.720558] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[ 22.815248] [<ffffffff8222b623>] panic+0x110/0x329
[ 22.914330] [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
[ 23.014800] [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[ 23.090763] [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
[ 23.185748] [<ffffffff83244972>] isdnloop_init+0xaf/0xb1
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
drivers/isdn/isdnloop/isdnloop.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
--- linux.orig/drivers/isdn/isdnloop/isdnloop.c 2012-08-03 15:24:49.047544323 +0800
+++ linux/drivers/isdn/isdnloop/isdnloop.c 2012-08-03 15:27:39.503548375 +0800
@@ -16,7 +16,6 @@
#include <linux/sched.h>
#include "isdnloop.h"
-static char *revision = "$Revision: 1.11.6.7 $";
static char *isdnloop_id = "loop0";
MODULE_DESCRIPTION("ISDN4Linux: Pseudo Driver that simulates an ISDN card");
@@ -1494,16 +1493,7 @@ isdnloop_addcard(char *id1)
static int __init
isdnloop_init(void)
{
- char *p;
- char rev[10];
-
- if ((p = strchr(revision, ':'))) {
- strcpy(rev, p + 1);
- p = strchr(rev, '$');
- *p = 0;
- } else
- strcpy(rev, " ??? ");
- printk(KERN_NOTICE "isdnloop-ISDN-driver Rev%s\n", rev);
+ printk(KERN_NOTICE "isdnloop-ISDN-driver Rev 1.11.6.7\n");
if (isdnloop_id)
return (isdnloop_addcard(isdnloop_id));
^ permalink raw reply
* RE: [PATCH 0/4] net/mlx4: Fixes to mlx4 driver
From: Yevgeny Petrilin @ 2012-08-03 7:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120802.161251.331601378090436432.davem@davemloft.net>
> > Yevgeny Petrilin (3):
> > net/mlx4_en: Setting the NETIF_F_GRO flag back to dev->hw_features
>
> As pointed out, this isn't a bug.
>
> You just made this change purely via code inspection, and that's very
> disappointing because this would have been so simple to validate.
Hello Dave,
You are absolutely right,
I should have checked it better.
There are few more modules setting this flag during device initialization, I guess we need to clean all.
Can you please apply the other 3 or should I resubmit them?
Thanks,
Yevgeny
^ permalink raw reply
* Re: [PATCH v2 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: Jun Zhao @ 2012-08-03 7:10 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20120802.234311.2108069975669469931.davem@davemloft.net>
On Thu, 2012-08-02 at 23:43 -0700, David Miller wrote:
> From: Jun Zhao <mypopydev@gmail.com>
> Date: Fri, 3 Aug 2012 14:27:51 +0800
>
> > @@ -1960,7 +1962,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
> >
> > IP6CB(skb)->flags |= IP6SKB_FORWARDED;
> >
> > - return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, skb->dev, dev,
> > + return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, indev, dev,
> > ip6mr_forward2_finish);
> >
>
> This patch has the same problem I mentioned, it means someone who is
> now matching on the VIF device will now fail to do son.
>
> You have to understand that you simply cannot change the behavior
> here without breaking something for someone.
Hi, David:
Can you give me some more details what I break in this fix?
As my understanding, in the ip6mr_forward2(), vifi is the VIF index for
output, we can get the output device used vif->dev and record input
device before change skb->dev; then used FORWARD chain match the rules.
Tks.
^ permalink raw reply
* [PATCH] ipv4/ipv6: multicast api unappropriate errno fix.
From: Li Wei @ 2012-08-03 7:06 UTC (permalink / raw)
To: davem; +Cc: netdev, dlstevens, Li Wei
commit 917f2f105([IPV4]: multicast API "join" issues) corrected
some errno values but also caused unappropriate errno returned.
With an unjoined group address, return -EADDRNOTAVAIL would be
much better than -EINVAL.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
---
net/ipv4/igmp.c | 8 +++-----
net/ipv6/mcast.c | 8 +++-----
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 6699f23..c45c092 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1933,10 +1933,8 @@ int ip_mc_source(int add, int omode, struct sock *sk, struct
(pmc->multi.imr_ifindex == imr.imr_ifindex))
break;
}
- if (!pmc) { /* must have a prior join */
- err = -EINVAL;
- goto done;
- }
+ if (!pmc) /* must have a prior join */
+ goto done; /* err = -EADDRNOTAVAIL */
/* if a source filter was set, must be the same mode as before */
if (pmc->sflist) {
if (pmc->sfmode != omode) {
@@ -2076,7 +2074,7 @@ int ip_mc_msfilter(struct sock *sk, struct ip_msfilter *msf, int ifindex)
break;
}
if (!pmc) { /* must have a prior join */
- err = -EINVAL;
+ err = -EADDRNOTAVAIL;
goto done;
}
if (msf->imsf_numsrc) {
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 92f8e48..89dcefd 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -347,10 +347,8 @@ int ip6_mc_source(int add, int omode, struct sock *sk,
if (ipv6_addr_equal(&pmc->addr, group))
break;
}
- if (!pmc) { /* must have a prior join */
- err = -EINVAL;
- goto done;
- }
+ if (!pmc) /* must have a prior join */
+ goto done; /* err = -EADDRNOTAVAIL */
/* if a source filter was set, must be the same mode as before */
if (pmc->sflist) {
if (pmc->sfmode != omode) {
@@ -488,7 +486,7 @@ int ip6_mc_msfilter(struct sock *sk, struct group_filter *gsf)
break;
}
if (!pmc) { /* must have a prior join */
- err = -EINVAL;
+ err = -EADDRNOTAVAIL;
goto done;
}
if (gsf->gf_numsrc) {
--
1.7.10.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: David Miller @ 2012-08-03 6:43 UTC (permalink / raw)
To: mypopydev; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1343975271-4263-1-git-send-email-mypopydev@gmail.com>
From: Jun Zhao <mypopydev@gmail.com>
Date: Fri, 3 Aug 2012 14:27:51 +0800
> @@ -1960,7 +1962,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
>
> IP6CB(skb)->flags |= IP6SKB_FORWARDED;
>
> - return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, skb->dev, dev,
> + return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, indev, dev,
> ip6mr_forward2_finish);
>
This patch has the same problem I mentioned, it means someone who is
now matching on the VIF device will now fail to do son.
You have to understand that you simply cannot change the behavior
here without breaking something for someone.
^ permalink raw reply
* [PATCH v2 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: Jun Zhao @ 2012-08-03 6:27 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy
Cc: netdev, mypopydev
Current kernel change the skb's net device with output device before netfilter FORWARD chain,
that will lead to can't match the IPv6 multicast packets with input net device in netfilter
FORWARD chain.
the test case for reproduce this issue as follow:
IPv6 multicast udp stream from eth0(input device) to eth1(output device)
Dst Addr: Port
{ff03::4}:6789 --->
Router
+---------------------------+
-------> | [eth0] --FORWARD--> [eth1]| ------->
+---------------------------+
ip6tables -I FORWARD -p udp -i eth0 -o eth1 --dst ff03::4 -j ACCEPT [first rules ]
ip6tables -A FORWARD -p udp -i eth1 -o eth1 --dst ff03::4 -j ACCEPT [second rules]
Before fix this issue, it will match the second rules not the first rules. you can used
command "ip6tables -L -vnx" to check the match result.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
net/ipv6/ip6mr.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 4532973..b099dfb 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1901,6 +1901,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
struct ipv6hdr *ipv6h;
struct mif_device *vif = &mrt->vif6_table[vifi];
struct net_device *dev;
+ struct net_device *indev;
struct dst_entry *dst;
struct flowi6 fl6;
@@ -1946,6 +1947,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
* result in receiving multiple packets.
*/
dev = vif->dev;
+ indev = skb->dev;
skb->dev = dev;
vif->pkt_out++;
vif->bytes_out += skb->len;
@@ -1960,7 +1962,7 @@ static int ip6mr_forward2(struct net *net, struct mr6_table *mrt,
IP6CB(skb)->flags |= IP6SKB_FORWARDED;
- return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, skb->dev, dev,
+ return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, indev, dev,
ip6mr_forward2_finish);
out_free:
--
1.7.2.5
^ permalink raw reply related
* 0432..180..52882...2004..
From: eef @ 2012-08-03 6:04 UTC (permalink / raw)
To: ppechmann
经理/财务您好！
我司可代开全国各地普通(国-地税)发&票，
点数优惠，承诺绝对真票，可验证后再付款。
（若打扰，请谅解）。
聯系人:杨小姐
手 機: 13818893119
Q Q: 925805893
^ permalink raw reply
* Re: [PATCH 1/1] ipv6 : ip6mr.c : Fix can't match the IPv6 multicast packets with input net device in netfilter FORWARD chain.
From: Jun Zhao @ 2012-08-03 6:10 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, netdev
In-Reply-To: <20120802.162015.2106150087918919160.davem@davemloft.net>
On Thu, 2012-08-02 at 16:20 -0700, David Miller wrote:
> From: Jun Zhao <mypopydev@gmail.com>
> Date: Thu, 2 Aug 2012 21:00:55 +0800
>
> > Current kernel change the skb's net device with output device before netfilter FORWARD chain,
> > that will lead to can't match the IPv6 multicast packets with input net device in netfilter
> > FORWARD chain.
> >
> > the test case for reproduce this issue as follow:
> >
> > IPv6 multicast udp stream from eth0(input device) to eth1(output device)
>
> Your change means we now can't match on the VIF device in this situation.
>
> I'm not applying this patch, it breaks as much as it fixes.
Hi, David:
Maybe I need to used conservative approach to fix it and don't breaks
much more, I will supply the version 2 patch for this issue.
Tks.
^ permalink raw reply
* RE: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Hiremath, Vaibhav @ 2012-08-03 5:53 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev@vger.kernel.org, N, Mugunthan V,
devicetree-discuss@lists.ozlabs.org, koen@dominion.thruhere.net,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <501B6020.7090502@gmail.com>
On Fri, Aug 03, 2012 at 10:52:40, Daniel Mack wrote:
> On 03.08.2012 07:16, Vaibhav Hiremath wrote:
> >
> >
> > On 8/3/2012 1:13 AM, Daniel Mack wrote:
> >> Make the driver control the device clocks. Appearantly, the Davinci
> >> platform probes this driver with the clock all powered up, but on OMAP,
> >> this isn't the case.
> >>
> >> Signed-off-by: Daniel Mack <zonque@gmail.com>
> >> ---
> >> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
> >> 1 file changed, 14 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> >> index cd7ee20..b4b6015 100644
> >> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> >> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> >> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
> >> goto bail_out;
> >> }
> >>
> >> + clk_enable(data->clk);
> >> +
> >> dev_set_drvdata(dev, data);
> >> data->dev = dev;
> >> spin_lock_init(&data->lock);
> >> @@ -379,8 +381,11 @@ bail_out:
> >> if (data->bus)
> >> mdiobus_free(data->bus);
> >>
> >> - if (data->clk)
> >> + if (data->clk) {
> >> + clk_disable(data->clk);
> >> clk_put(data->clk);
> >> + }
> >> +
> >> pm_runtime_put_sync(&pdev->dev);
> >> pm_runtime_disable(&pdev->dev);
> >>
> >> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
> >> if (data->bus)
> >> mdiobus_free(data->bus);
> >>
> >> - if (data->clk)
> >> + if (data->clk) {
> >> + clk_disable(data->clk);
> >> clk_put(data->clk);
> >> + }
> >> +
> >> pm_runtime_put_sync(&pdev->dev);
> >> pm_runtime_disable(&pdev->dev);
> >>
> >> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
> >> data->suspended = true;
> >> spin_unlock(&data->lock);
> >>
> >> + clk_disable(data->clk);
> >> +
> >> return 0;
> >> }
> >>
> >> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
> >> struct davinci_mdio_data *data = dev_get_drvdata(dev);
> >> u32 ctrl;
> >>
> >> + clk_enable(data->clk);
> >> +
> >
> > Danial,
> >
> > I would request you to wait for this, its not that simple and straight.
> > And once you migrate to runtime PM you don't need clk_enable/disable,
> > this should get handled under runtime PM api's.
>
> As I said, it can be dropped.
>
> > Also have you read my another email post -
> >
> > http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
> >
> > Certainly, with respect to CPSW & MDIO, this patch is not enough and
> > requires further investigation. I have started looking at this and
> > hopefully will have some solution soon...
>
> Ok, no problem. We certainly need the DT bindings for davinci_mdio. With
> that applied, and the hwmod added (in the patch I posted yesterday), I
> can at least mount the rootfs via NFS, which is all I currently need.
>
>
I certainly understand your requirement here.
Actually this is not the only device we have, the same issue is applicable
to PWM subsystem available in AM335x. Hopefully I should have something soon
on this.
Thanks,
Vaibhav
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-03 5:51 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, xemul, netdev
In-Reply-To: <1343972729.9299.596.camel@edumazet-glaptop>
On Fri, 2012-08-03 at 07:45 +0200, Eric Dumazet wrote:
> Yes I am sure (by the way my output device was dummy0, not lo, but its
> the same for the case here)
Of course, the ifindex was related to lo, sorry for the confusion,
-ENOCOFFEE_YET_THIS_MORNING
^ permalink raw reply
* Re: [PATCH 1/2] net: Allow to create links with given ifindex
From: Eric Dumazet @ 2012-08-03 5:45 UTC (permalink / raw)
To: David Miller; +Cc: ebiederm, xemul, netdev
In-Reply-To: <20120802.162601.2080519313891137444.davem@davemloft.net>
On Thu, 2012-08-02 at 16:26 -0700, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 02 Aug 2012 12:28:30 +0200
>
> > Strange because I see no false sharing on this ifindex location for
> > loopback device.
>
> Are you sure netdev->rx_dropped isn't being incremented? That appears
> as if it would land on the same cache line as netdev->ifindex.
>
Yes I am sure (by the way my output device was dummy0, not lo, but its
the same for the case here)
offsetof(struct net_device, features)=0x80
... (all features are mostly read only)
offsetof(struct net_device, ifindex)=0xa0
struct net_device_stats stats; is untouched on dummy device
offsetof(struct net_device, rx_dropped)=0x160
So thats only the dereference done million times per second that show in
the profiles, even if cache lines are clean and in cpu cache.
I see that even more clear in the IN_DEV_ROUTE_LOCALNET(in_dev) macro in
ip_route_input_slow(), doing so many derefs :
Its actually faster to avoid it, if we already have the net pointer in
hand : IN_DEV_NET_ROUTE_LOCALNET(in_dev, net)
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 67f9dda..d032780 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -104,9 +104,14 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
#define IN_DEV_ANDCONF(in_dev, attr) \
(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) && \
IN_DEV_CONF_GET((in_dev), attr))
-#define IN_DEV_ORCONF(in_dev, attr) \
- (IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr) || \
+
+#define IN_DEV_NET_ORCONF(in_dev, net, attr) \
+ (IPV4_DEVCONF_ALL(net, attr) || \
IN_DEV_CONF_GET((in_dev), attr))
+
+#define IN_DEV_ORCONF(in_dev, attr) \
+ IN_DEV_NET_ORCONF(in_dev, dev_net(in_dev->dev), attr)
+
#define IN_DEV_MAXCONF(in_dev, attr) \
(max(IPV4_DEVCONF_ALL(dev_net(in_dev->dev), attr), \
IN_DEV_CONF_GET((in_dev), attr)))
@@ -133,6 +138,8 @@ static inline void ipv4_devconf_setall(struct in_device *in_dev)
IN_DEV_ORCONF((in_dev), \
PROMOTE_SECONDARIES)
#define IN_DEV_ROUTE_LOCALNET(in_dev) IN_DEV_ORCONF(in_dev, ROUTE_LOCALNET)
+#define IN_DEV_NET_ROUTE_LOCALNET(in_dev, net) \
+ IN_DEV_NET_ORCONF(in_dev, net, ROUTE_LOCALNET)
#define IN_DEV_RX_REDIRECTS(in_dev) \
((IN_DEV_FORWARD(in_dev) && \
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e4ba974..5e88e3b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1587,13 +1587,11 @@ static int ip_route_input_slow(struct sk_buff *skb, __be32 daddr, __be32 saddr,
if (ipv4_is_zeronet(daddr))
goto martian_destination;
- if (likely(!IN_DEV_ROUTE_LOCALNET(in_dev))) {
- if (ipv4_is_loopback(daddr))
- goto martian_destination;
+ if (ipv4_is_loopback(daddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
+ goto martian_destination;
- if (ipv4_is_loopback(saddr))
- goto martian_source;
- }
+ if (ipv4_is_loopback(saddr) && !IN_DEV_NET_ROUTE_LOCALNET(in_dev, net))
+ goto martian_source;
/*
* Now we are ready to route packet.
^ permalink raw reply related
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Daniel Mack @ 2012-08-03 5:22 UTC (permalink / raw)
To: Vaibhav Hiremath
Cc: netdev, mugunthanvnm, devicetree-discuss, koen, linux-arm-kernel
In-Reply-To: <501B5EC1.7010304@ti.com>
On 03.08.2012 07:16, Vaibhav Hiremath wrote:
>
>
> On 8/3/2012 1:13 AM, Daniel Mack wrote:
>> Make the driver control the device clocks. Appearantly, the Davinci
>> platform probes this driver with the clock all powered up, but on OMAP,
>> this isn't the case.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>> ---
>> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
>> index cd7ee20..b4b6015 100644
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
>> goto bail_out;
>> }
>>
>> + clk_enable(data->clk);
>> +
>> dev_set_drvdata(dev, data);
>> data->dev = dev;
>> spin_lock_init(&data->lock);
>> @@ -379,8 +381,11 @@ bail_out:
>> if (data->bus)
>> mdiobus_free(data->bus);
>>
>> - if (data->clk)
>> + if (data->clk) {
>> + clk_disable(data->clk);
>> clk_put(data->clk);
>> + }
>> +
>> pm_runtime_put_sync(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>>
>> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
>> if (data->bus)
>> mdiobus_free(data->bus);
>>
>> - if (data->clk)
>> + if (data->clk) {
>> + clk_disable(data->clk);
>> clk_put(data->clk);
>> + }
>> +
>> pm_runtime_put_sync(&pdev->dev);
>> pm_runtime_disable(&pdev->dev);
>>
>> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
>> data->suspended = true;
>> spin_unlock(&data->lock);
>>
>> + clk_disable(data->clk);
>> +
>> return 0;
>> }
>>
>> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
>> struct davinci_mdio_data *data = dev_get_drvdata(dev);
>> u32 ctrl;
>>
>> + clk_enable(data->clk);
>> +
>
> Danial,
>
> I would request you to wait for this, its not that simple and straight.
> And once you migrate to runtime PM you don't need clk_enable/disable,
> this should get handled under runtime PM api's.
As I said, it can be dropped.
> Also have you read my another email post -
>
> http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
>
> Certainly, with respect to CPSW & MDIO, this patch is not enough and
> requires further investigation. I have started looking at this and
> hopefully will have some solution soon...
Ok, no problem. We certainly need the DT bindings for davinci_mdio. With
that applied, and the hwmod added (in the patch I posted yesterday), I
can at least mount the rootfs via NFS, which is all I currently need.
Best regards,
Daniel
^ permalink raw reply
* Re: [PATCH 1/2] net: davinci_mdio: enable and disable clock
From: Vaibhav Hiremath @ 2012-08-03 5:16 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev, mugunthanvnm, devicetree-discuss, koen, linux-arm-kernel
In-Reply-To: <1343936616-29318-1-git-send-email-zonque@gmail.com>
On 8/3/2012 1:13 AM, Daniel Mack wrote:
> Make the driver control the device clocks. Appearantly, the Davinci
> platform probes this driver with the clock all powered up, but on OMAP,
> this isn't the case.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index cd7ee20..b4b6015 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -332,6 +332,8 @@ static int __devinit davinci_mdio_probe(struct platform_device *pdev)
> goto bail_out;
> }
>
> + clk_enable(data->clk);
> +
> dev_set_drvdata(dev, data);
> data->dev = dev;
> spin_lock_init(&data->lock);
> @@ -379,8 +381,11 @@ bail_out:
> if (data->bus)
> mdiobus_free(data->bus);
>
> - if (data->clk)
> + if (data->clk) {
> + clk_disable(data->clk);
> clk_put(data->clk);
> + }
> +
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -397,8 +402,11 @@ static int __devexit davinci_mdio_remove(struct platform_device *pdev)
> if (data->bus)
> mdiobus_free(data->bus);
>
> - if (data->clk)
> + if (data->clk) {
> + clk_disable(data->clk);
> clk_put(data->clk);
> + }
> +
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> @@ -427,6 +435,8 @@ static int davinci_mdio_suspend(struct device *dev)
> data->suspended = true;
> spin_unlock(&data->lock);
>
> + clk_disable(data->clk);
> +
> return 0;
> }
>
> @@ -435,6 +445,8 @@ static int davinci_mdio_resume(struct device *dev)
> struct davinci_mdio_data *data = dev_get_drvdata(dev);
> u32 ctrl;
>
> + clk_enable(data->clk);
> +
Danial,
I would request you to wait for this, its not that simple and straight.
And once you migrate to runtime PM you don't need clk_enable/disable,
this should get handled under runtime PM api's.
Also have you read my another email post -
http://comments.gmane.org/gmane.linux.ports.arm.omap/80796
Certainly, with respect to CPSW & MDIO, this patch is not enough and
requires further investigation. I have started looking at this and
hopefully will have some solution soon...
Thanks,
Vaibhav
^ 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