* Re: [PATCH net 1/3] bnx2x: fix hw attention handling
From: David Miller @ 2011-09-27 19:04 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong
In-Reply-To: <1316694813-25274-1-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Thu, 22 Sep 2011 15:33:31 +0300
> Use register name to initialize attention mask
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/3] bnx2x: fix WOL by enablement PME in config space
From: David Miller @ 2011-09-27 19:04 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong
In-Reply-To: <1316694813-25274-2-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Thu, 22 Sep 2011 15:33:32 +0300
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 3/3] bnx2x: add missing break in bnx2x_dcbnl_get_cap
From: David Miller @ 2011-09-27 19:04 UTC (permalink / raw)
To: dmitry; +Cc: netdev, shmulikr, eilong
In-Reply-To: <1316694813-25274-3-git-send-email-dmitry@broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Thu, 22 Sep 2011 15:33:33 +0300
> From: Shmulik Ravid <shmulikr@broadcom.com>
>
> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: pull request: batman-adv 2011-09-22 (regression fix)
From: David Miller @ 2011-09-27 19:06 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1316717836-19374-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Thu, 22 Sep 2011 20:57:15 +0200
> The following changes since commit 322a8b034003c0d46d39af85bf24fee27b902f48:
>
> Linux 3.1-rc1 (2011-08-07 18:23:30 -0700)
>
> are available in the git repository at:
> git://git.open-mesh.org/linux-merge.git batman-adv/maint
Pulled, thanks.
^ permalink raw reply
* [PATCH] ipv6-multicast: Fix memory leak in input path.
From: greearb @ 2011-09-27 18:58 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Have to free the skb before returning if we fail
the fib lookup.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 e9a8df9... 86e3cc1... M net/ipv6/ip6mr.c
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 e9a8df9..86e3cc1 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -2053,8 +2053,10 @@ int ip6_mr_input(struct sk_buff *skb)
int err;
err = ip6mr_fib_lookup(net, &fl6, &mrt);
- if (err < 0)
+ if (err < 0) {
+ kfree_skb(skb);
return err;
+ }
read_lock(&mrt_lock);
cache = ip6mr_cache_find(mrt,
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] ipv6-multicast: Fix memory leak in input path.
From: David Miller @ 2011-09-27 19:16 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1317149897-14932-1-git-send-email-greearb@candelatech.com>
From: greearb@candelatech.com
Date: Tue, 27 Sep 2011 11:58:17 -0700
> From: Ben Greear <greearb@candelatech.com>
>
> Have to free the skb before returning if we fail
> the fib lookup.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Applied, thanks.
^ permalink raw reply
* macvlan/macvtap patch in patchwork
From: David Miller @ 2011-09-27 19:14 UTC (permalink / raw)
To: kaber; +Cc: netdev, herbert, krkumar2, david.ward
Could you guys please review:
http://patchwork.ozlabs.org/patch/115273/
My gut instinct is that the current behavior is intentional, but since
the patch submitter didn't describe exactly what the undesirable
behavior is it's hard to tell what the patch is actually fixing.
Thanks.
^ permalink raw reply
* ICMP redirect issue
From: Flavio Leitner @ 2011-09-27 19:21 UTC (permalink / raw)
To: netdev
Hi,
While investigating an issue on Red Hat Enterprise Linux, I found that
upstream commit below removed the old_gw check.
commit f39925dbde7788cfb96419c0f092b086aa325c0f
Author: David S. Miller <davem@davemloft.net>
Date: Wed Feb 9 22:00:16 2011 -0800
ipv4: Cache learned redirect information in inetpeer.
The issue is about the gateway being a LVS, so the servers behind use
the IP alias address as the default gateway. However, when the gateway
sends an ICMP redirect, it comes from the primary IP address which is
ignored on older kernels because of the old_gw check:
- if (rth->rt_dst != daddr ||
- rth->rt_src != saddr ||
- rth->dst.error ||
- rth->rt_gateway != old_gw ||
- rth->dst.dev != dev)
- break;
Well, the consequence is that the issue doesn't happen in newer kernels
because it happily accepts the ICMP redirect.
The admin can still control using shared_media and secure_redirects if
the host should accept only the ICMP redirects for gateways listed in
default gateway list or not.
In terms of a security, if someone manages to send ICMP redirect, then
I think it possible to fake the saddr to appear as coming from the
correct gateway.
So, I'm not seeing a problem, but I was told to bring this up to netdev.
Thoughts?
thanks,
fbl
^ permalink raw reply
* Re: [PATCH] net/flow: remove sleeping and deferral mechanism from flow_cache_flush
From: David Miller @ 2011-09-27 19:28 UTC (permalink / raw)
To: madalin.bucur; +Cc: eric.dumazet, netdev, timo.teras
In-Reply-To: <1317056956-23644-1-git-send-email-madalin.bucur@freescale.com>
From: Madalin Bucur <madalin.bucur@freescale.com>
Date: Mon, 26 Sep 2011 20:09:16 +0300
> flow_cache_flush must not sleep as it can be called in atomic context;
> removed the schedule_work as the deferred processing lead to the flow
> cache gc never being actually run under heavy network load
>
> Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
How is this called in an atomic context? The only caller of
flow_cache_flush() is __xfrm_garbage_collect() which is only invoked
during a NETDEV_DOWN event which ought to be non-atomic.
afinfo->garbage_collect is the only other place __xfrm_garbage_collect
is referenced, and that is completely unused and should thus be deleted
(I'll take care of that in net-next).
If NETDEV_DOWN notifier is in an atomic context, we need to accomodate
or fix that somehow.
^ permalink raw reply
* Re: [PATCH 1/2] net: check return value for dst_alloc
From: David Miller @ 2011-09-27 19:32 UTC (permalink / raw)
To: madalin.bucur; +Cc: eric.dumazet, netdev, timo.teras
In-Reply-To: <1317056676-23584-1-git-send-email-madalin.bucur@freescale.com>
From: Madalin Bucur <madalin.bucur@freescale.com>
Date: Mon, 26 Sep 2011 20:04:36 +0300
> return value of dst_alloc must be checked before use
>
> Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] net: check return value for dst_alloc
From: David Miller @ 2011-09-27 19:32 UTC (permalink / raw)
To: madalin.bucur; +Cc: eric.dumazet, netdev, timo.teras
In-Reply-To: <1317056696-23611-1-git-send-email-madalin.bucur@freescale.com>
From: Madalin Bucur <madalin.bucur@freescale.com>
Date: Mon, 26 Sep 2011 20:04:56 +0300
> return value of dst_alloc must be checked before use
>
> Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/flow: remove sleeping and deferral mechanism from flow_cache_flush
From: David Miller @ 2011-09-27 19:31 UTC (permalink / raw)
To: madalin.bucur; +Cc: eric.dumazet, netdev, timo.teras
In-Reply-To: <20110927.152836.1747700807304689813.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 27 Sep 2011 15:28:36 -0400 (EDT)
> afinfo->garbage_collect is the only other place __xfrm_garbage_collect
> is referenced, and that is completely unused and should thus be deleted
> (I'll take care of that in net-next).
Nevermind I see how these are referenced directly via xfrm4_policy.c
and xfrm6_policy.c, sigh...
^ permalink raw reply
* Re: [PATCH] ipv6-multicast: Fix memory leak in IPv6 multicast.
From: David Miller @ 2011-09-27 19:34 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <1316819461-3192-1-git-send-email-greearb@candelatech.com>
From: greearb@candelatech.com
Date: Fri, 23 Sep 2011 16:11:01 -0700
> From: Ben Greear <greearb@candelatech.com>
>
> If reg_vif_xmit cannot find a routing entry, be sure to
> free the skb before returning the error.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Applied.
^ permalink raw reply
* Re: [RFC PATCH] net: Always fire at least one linkwatch event
From: Neil Horman @ 2011-09-27 19:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jfeeney
In-Reply-To: <20110927.145943.1365764295978178226.davem@redhat.com>
On Tue, Sep 27, 2011 at 02:59:43PM -0400, David Miller wrote:
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Wed, 21 Sep 2011 15:51:29 -0400
>
> > It was recently noted that the tg3 driver had a problem in that after boot a
> > kernel and if-upping the tg3 interface the sysfs operstate attribute continued
> > to read 'unkown'. This was happening because tg3 assumes the default carrier
> > state (which is to say the __LINK_STATE_NOCARRIER bit is clear) is correct.
> > That said, when the device is if-upped, and the open path, calls
> > netif_carrier_on, the test_and_set_bit call in that function returns false
> > (since the bit was previously zero from its initial state). This means that
> > netif_carrier_on call never generates a linkwatch event, and as a result
> > dev->operstate never gets recomputed. This could be fixed by unconditionally
> > calling netif_carrier_off in the probe routine, to simply force a state change
> > on that bit, but that seems like a sub-par solution, given that many drivers may
> > have this error. Instead it seems like it might be better to burn an extra bit
> > in the state field to indicate that the CARRIER bit is still in the initial
> > state and our first call to netif_carrier_[off|on] should always fire a
> > linkwatch event.
>
> I'm finding this analysis hard to follow.
>
> tg3_open() does netif_carrier_off(), and this will set the
> __LINK_STATE_NOCARRIER bit.
>
Sorry, I should have explained further. In the interests of full disclosure,
this was initially reported on a RHEL 2.6.32 kernel, where netif_carrier_off was
not called from tg3_open. As a result, when tg3_carrier_on was called later in
the open path, the test_and_clear would return 0, since NOCARRIER was
initialized to 0, and we wouldn't fire a linkwatch event, which in turn meant
that operstate was never updated until a full ifup/down/up cycle was completed.
So tg3 actually works properly upstream, but the larger issue remains - Drivers
individually must set and clear the NOCARRIER flag in order to effectively prime
the linkwatch state machine, which seems to me haphazard and prone to recurring
bugs. What I'm proposing here is a driver independent method of ensuring that
the first call to netif_carrier_off/on gets called regardless of initial state.
This prevents drivers from having to individually remember to call
netif_carrier_off at the start of an open routine, which visually makes more
sense to me, especially when they almost immediately call netif_carrier_on right
afterwards.
Hope that clarifies things somewhat.
Neil
^ permalink raw reply
* Re: [PATCH] ipv6-multicast: Fix memory leak in input path.
From: Ben Greear @ 2011-09-27 19:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110927.151616.1706187903528893128.davem@davemloft.net>
On 09/27/2011 12:16 PM, David Miller wrote:
> From: greearb@candelatech.com
> Date: Tue, 27 Sep 2011 11:58:17 -0700
>
>> From: Ben Greear<greearb@candelatech.com>
>>
>> Have to free the skb before returning if we fail
>> the fib lookup.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>
> Applied, thanks.
Thanks.
This bug was introduced in 2.6.35, I believe, so should probably send
this to stable as well.
Thanks,
Ben
> --
> 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
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC PATCH] net: Always fire at least one linkwatch event
From: David Miller @ 2011-09-27 19:49 UTC (permalink / raw)
To: nhorman; +Cc: netdev, jfeeney
In-Reply-To: <20110927193413.GA30020@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Tue, 27 Sep 2011 15:34:13 -0400
> So tg3 actually works properly upstream, but the larger issue remains - Drivers
> individually must set and clear the NOCARRIER flag in order to effectively prime
> the linkwatch state machine, which seems to me haphazard and prone to recurring
> bugs.
Driver controls when the PHY is reset, auto-negotiation is started, etc. so it is
the only entity which is in the position to set the correct state.
So we kind of depend upon drivers managing the state correctly and accurately.
If I follow what tg3 is currently doing, just to show an example, it first
sets carrier off then resets then entire chip atomically. This reset will
restart auto-neg, etc. and trigger a subsequent link-up event which will
netif_carrier_on() and get the proper transition.
^ permalink raw reply
* __pskb_pull_tail oops from 2.6.35
From: Dave Jones @ 2011-09-27 20:03 UTC (permalink / raw)
To: netdev
A user just reported this on a fairly old kernel (running the latest -longterm patch).
I had a look through net/core/skbuff.c since 2.6.35, and didn't see anything obvious.
Does this look familiar to anyone ?
Dave
> I disabled the nvidia kernel module, booted into run level 3, and kicked off an
> fsck of the ext3 partition on the XL2000. It panic'ed pretty quickly and this
> was the result:
>
> # crash /var/crash/2011-09-27-20\:04/vmcore /usr/lib/debug/lib/modules/`uname -r`/vmlinux
>
> crash 5.0.6-2.fc14
> Copyright (C) 2002-2010 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005 NEC Corporation
> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for details.
>
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu"...
>
> KERNEL: /usr/lib/debug/lib/modules/2.6.35.14-96.fc14.x86_64/vmlinux
> DUMPFILE: /var/crash/2011-09-27-20:04/vmcore
> CPUS: 4
> DATE: Tue Sep 27 20:02:02 2011
> UPTIME: 00:04:22
> LOAD AVERAGE: 1.80, 0.87, 0.35
> TASKS: 312
> NODENAME: mythtv.xxx.xxx.xxx
> RELEASE: 2.6.35.14-96.fc14.x86_64
> VERSION: #1 SMP Thu Sep 1 11:59:56 UTC 2011
> MACHINE: x86_64 (2809 Mhz)
> MEMORY: 4 GB
> PANIC: "[ 262.575493] Oops: 0000 [#1] SMP " (check log for details)
> PID: 0
> COMMAND: "swapper"
> TASK: ffffffff81a4a020 (1 of 4) [THREAD_INFO: ffffffff81a00000]
> CPU: 0
> STATE: TASK_RUNNING (PANIC)
>
> crash> bt
> PID: 0 TASK: ffffffff81a4a020 CPU: 0 COMMAND: "swapper"
> #0 [ffff88000a203ba8] __pskb_pull_tail at ffffffff813b8e02
> #1 [ffff88000a203bf8] dev_queue_xmit at ffffffff813c2e46
> #2 [ffff88000a203c38] ip_finish_output2 at ffffffff813f557c
> #3 [ffff88000a203c68] ip_finish_output at ffffffff813f5621
> #4 [ffff88000a203c88] ip_output at ffffffff813f5e48
> #5 [ffff88000a203ca8] ip_forward_finish at ffffffff813f35dd
> #6 [ffff88000a203cc8] ip_forward at ffffffff813f38ba
> #7 [ffff88000a203d08] ip_rcv_finish at ffffffff813f2171
> #8 [ffff88000a203d48] NF_HOOK.clone.8 at ffffffff813f2412
> #9 [ffff88000a203d78] ip_rcv at ffffffff813f27a1
> #10 [ffff88000a203da8] __netif_receive_skb at ffffffff813bf812
> #11 [ffff88000a203e08] process_backlog at ffffffff813c1064
> #12 [ffff88000a203e68] net_rx_action at ffffffff813c11e6
> #13 [ffff88000a203ec8] __do_softirq at ffffffff81053db9
> #14 [ffff88000a203f38] call_softirq at ffffffff8100ab9c
> #15 [ffff88000a203f50] do_softirq at ffffffff8100c2f8
> #16 [ffff88000a203f70] irq_exit at ffffffff81053f45
> #17 [ffff88000a203f80] do_IRQ at ffffffff814715c5
> --- <IRQ stack> ---
> #18 [ffffffff81a01db8] ret_from_intr at ffffffff8146bad3
> [exception RIP: intel_idle+273]
> RIP: ffffffff81265bfc RSP: ffffffff81a01e68 RFLAGS: 00000206
> RAX: 0000000000000000 RBX: ffffffff81a01ec8 RCX: 00000000000000bb
> RDX: 00000000000000bb RSI: 0000000000000000 RDI: 00000000000003e8
> RBP: ffffffff8146bace R8: 0000000000000000 R9: 00000000000002b3
> R10: 0000003d2d072cee R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff81a01df8 R14: ffffffff8146ea81 R15: ffffffff81a01df8
> ORIG_RAX: ffffffffffffff86 CS: 0010 SS: 0018
> #19 [ffffffff81a01ed0] cpuidle_idle_call at ffffffff813955b5
> #20 [ffffffff81a01ef0] cpu_idle at ffffffff8100830b
>
> # tail -64 /var/crash/2011-09-27-20\:04/dmesg
> <1>[ 262.574738] BUG: unable to handle kernel NULL pointer dereference at (null)
> <1>[ 262.574991] IP: [<ffffffff810dca57>] put_page+0x10/0x7c
> <4>[ 262.575213] PGD 10fd81067 PUD 10fe18067 PMD 0
> <0>[ 262.575493] Oops: 0000 [#1] SMP
> <0>[ 262.575736] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
> <4>[ 262.576067] CPU 0
> <4>[ 262.576106] Modules linked in: nfsd lockd nfs_acl auth_rpcgss exportfs
> coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf nf_nat_irc
> nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp xt_limit ipt_LOG iptable_mangle
> ipt_MASQUERADE iptable_nat nf_nat ip6t_REJECT nf_conntrack_ipv6 ip6table_filter
> ip6_tables ipv6 jfs uinput dvb_pll cx22702 cx88_dvb cx88_vp3054_i2c
> videobuf_dvb rc_hauppauge_new mt2060 snd_hda_codec_via ir_lirc_codec cx8800
> dvb_usb_dib0700 cx8802 lirc_dev cx88xx snd_hda_intel dib7000p dib0090 dib7000m
> dib0070 ir_sony_decoder snd_hda_codec dvb_usb ir_jvc_decoder dib8000
> ir_rc6_decoder dib9000 ir_rc5_decoder dvb_core ir_nec_decoder dib3000mc rc_core
> snd_hwdep dibx000_common snd_seq snd_seq_device i2c_algo_bit tveeprom
> v4l2_common videodev microcode snd_pcm v4l2_compat_ioctl32 snd_timer sundance
> videobuf_dma_sg snd shpchp btcx_risc videobuf_core soundcore snd_page_alloc
> iTCO_wdt iTCO_vendor_support i2c_i801 i2c_core r8169 mii asus_atk0110 joydev
> raid1 usb_storage [last unloaded: scsi_wait_scan]
> <4>[ 262.581273]
> <4>[ 262.581450] Pid: 0, comm: swapper Tainted: G I 2.6.35.14-96.fc14.x86_64 #1 P7H55/System Product Name
> <4>[ 262.581785] RIP: 0010:[<ffffffff810dca57>] [<ffffffff810dca57>] put_page+0x10/0x7c
> <4>[ 262.582147] RSP: 0018:ffff88000a203b80 EFLAGS: 00010246
> <4>[ 262.582332] RAX: 0000000000000030 RBX: ffff88012115fd00 RCX: ffff880120859670
> <4>[ 262.582519] RDX: ffff880120859640 RSI: 1506b29c96c716b9 RDI: 0000000000000000
> <4>[ 262.582707] RBP: ffff88000a203ba0 R08: ffff880127f2da58 R09: ffff880120859042
> <4>[ 262.582895] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> <4>[ 262.583083] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> <4>[ 262.583272] FS: 0000000000000000(0000) GS:ffff88000a200000(0000) knlGS:0000000000000000
> <4>[ 262.583601] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> <4>[ 262.583786] CR2: 0000000000000000 CR3: 000000010fd65000 CR4: 00000000000006f0
> <4>[ 262.583974] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> <4>[ 262.584162] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> <4>[ 262.584351] Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a4a020)
> <0>[ 262.584679] Stack:
> <4>[ 262.584855] ffff88012115fd00 0000000000000000 0000000000000000 0000000000000000
> <4>[ 262.585140] <0> ffff88000a203bf0 ffffffff813b8e02 0000001400000000 0000000000000030
> <4>[ 262.585631] <0> 9b07280a0002bb01 ffff88012115fd00 ffff88012a538000 ffff8800b7851800
> <0>[ 262.586289] Call Trace:
> <0>[ 262.586466] <IRQ>
> <4>[ 262.586679] [<ffffffff813b8e02>] __pskb_pull_tail+0x1e1/0x293
> <4>[ 262.586867] [<ffffffff813c2e46>] dev_queue_xmit+0x70/0x3ce
> <4>[ 262.587057] [<ffffffff813f55bc>] ? ip_finish_output+0x0/0x6a
> <4>[ 262.587245] [<ffffffff813f557c>] ip_finish_output2+0x1d6/0x216
> <4>[ 262.587468] [<ffffffff813f5621>] ip_finish_output+0x65/0x6a
> <4>[ 262.587654] [<ffffffff813f5e48>] ip_output+0x91/0x96
> <4>[ 262.587841] [<ffffffff813f35dd>] ip_forward_finish+0x49/0x4d
> <4>[ 262.588028] [<ffffffff813f38ba>] ip_forward+0x2d9/0x347
> <4>[ 262.588215] [<ffffffff813f2171>] ip_rcv_finish+0x324/0x34a
> <4>[ 262.588402] [<ffffffff813f1e4d>] ? ip_rcv_finish+0x0/0x34a
> <4>[ 262.588588] [<ffffffff813f2412>] NF_HOOK.clone.8+0x51/0x58
> <4>[ 262.588775] [<ffffffff813f27a1>] ip_rcv+0x21e/0x24d
> <4>[ 262.588962] [<ffffffff813bf812>] __netif_receive_skb+0x3ed/0x412
> <4>[ 262.589151] [<ffffffff813c1064>] process_backlog+0x87/0x15d
> <4>[ 262.589338] [<ffffffff813c11e6>] net_rx_action+0xac/0x1bb
> <4>[ 262.589527] [<ffffffff81053db9>] __do_softirq+0xf0/0x1bf
> <4>[ 262.589715] [<ffffffff81023795>] ? apic_write+0x16/0x18
> <4>[ 262.589902] [<ffffffff8101054b>] ? native_sched_clock+0x35/0x37
> <4>[ 262.590090] [<ffffffff8100ab9c>] call_softirq+0x1c/0x30
> <4>[ 262.590276] [<ffffffff8100c2f8>] do_softirq+0x46/0x82
> <4>[ 262.590462] [<ffffffff81053f45>] irq_exit+0x49/0x8b
> <4>[ 262.590647] [<ffffffff814715c5>] do_IRQ+0x9d/0xb4
> <4>[ 262.590835] [<ffffffff8146bad3>] ret_from_intr+0x0/0x11
> <0>[ 262.591018] <EOI>
> <4>[ 262.591233] [<ffffffff81265bfc>] ? intel_idle+0x111/0x139
> <4>[ 262.591419] [<ffffffff81265bdb>] ? intel_idle+0xf0/0x139
> <4>[ 262.591607] [<ffffffff813955b5>] cpuidle_idle_call+0x8b/0xe9
> <4>[ 262.591795] [<ffffffff8100830b>] cpu_idle+0xaa/0xcc
> <4>[ 262.591982] [<ffffffff81453186>] rest_init+0x8a/0x8c
> <4>[ 262.592169] [<ffffffff81ba1c49>] start_kernel+0x40b/0x416
> <4>[ 262.592357] [<ffffffff81ba12c6>] x86_64_start_reservations+0xb1/0xb5
> <4>[ 262.592546] [<ffffffff81ba13c2>] x86_64_start_kernel+0xf8/0x107
> <0>[ 262.592731] Code: c1 e8 35 48 c1 ea 37 83 e0 03 48 69 c0 00 07 00 00 48 03 04 d5 70 0e b8 81 c9 c3 55 48 89 e5 41 56 41 55 41 54 53 0f 1f 44 00 00 <48> f7 07 00 c0 00 00 48 89 fb 74 07 e8 3f fe ff ff eb 50 e8 c5
> <1>[ 262.595307] RIP [<ffffffff810dca57>] put_page+0x10/0x7c
> <4>[ 262.595524] RSP <ffff88000a203b80>
> <0>[ 262.595703] CR2: 0000000000000000
^ permalink raw reply
* Re: [PATCH net-next v2] candev: allow SJW user setting for bittiming calculation
From: Wolfgang Grandegger @ 2011-09-27 20:04 UTC (permalink / raw)
To: Oliver Hartkopp; +Cc: SocketCAN Core Mailing List, Linux Netdev List
In-Reply-To: <4E8208B5.4050907-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On 09/27/2011 07:32 PM, Oliver Hartkopp wrote:
> On 09/24/11 09:22, Wolfgang Grandegger wrote:
>
>> On 09/23/2011 11:32 AM, Pavel Pisa wrote:
>
>>> On base of above analysis, I think that blindly set SJW
>>> on maximum is not good idea. It should be at least limited
>>> to 5% of bit time.
>
>
> (..)
>
>
>>> SJW is more problematic, but may it be use of 2 or 5%
>>> of bittime by default with assurance that zero is
>>> replaced by one, would serve to most people pleasure.
>
>
> (..)
>
>>> But there is still unknown parameter
>>> capacity/length of connected wires so there is still
>>> something left to user consideration.
>>
>> Thanks for your detailed explanation. It clearly shows that adjusting
>> SJW is non-trivial and nothing a normal CAN user should deal with. When
>> adjusting SJW, do you also need to tweek other bit-timing parameters,
>> e.g. tq? I mean, would "ip link set can0 type can bitrate x
>> sampling-point y sjw z" work for your setup or do you need to use the
>> expert mode setting via "ip link set can0 type can tq ..." anyway?
>
>
> Hello Wolfgang,
>
> i double checked a specification where i got my requirement to influence the
> SJW value from. It says (non literally):
>
> "Put the SJW to the highest possible value only reduced by tseg2."
>
> The fact that this requirement might no fit to any CAN setup or may not be in
> best academical shape is not my problem. My requirement is to provide an easy
> way to move the SJW away from it's default value, which is currently
> hard-coded to 1 in the can-dev framework when using it's bittiming calculation
> function.
OK.
> As almost everything is already done (only the provided SJW is not evaluated
> in dev.c) this patch is IMO an valid option to support it. If Joe user can
> tune the sampling point, why should he not be able to influence the SJW if he
> thinks, he knows what he's doing?
>
> Especially as the good working bittiming calculation is not touched in any way
> and the default SJW remains 1 (even if '0' is provided as user input).
Still not sure if it's useful. Anyway, just added my acked-by to your patch.
Thanks,
Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next v2] candev: allow SJW user setting for bittiming calculation
From: Wolfgang Grandegger @ 2011-09-27 20:05 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: SocketCAN Core Mailing List, Linux Netdev List, David Miller
In-Reply-To: <4E7B0DE6.9020807-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
On 09/22/2011 12:28 PM, Oliver Hartkopp wrote:
> This patch adds support for SJW user settings to not set the synchronization
> jump width (SJW) to 1 in any case when using the in-kernel bittiming
> calculation.
>
> The ip-tool from iproute2 already supports to pass the user defined SJW
> value. The given SJW value is sanitized with the controller specific sjw_max
> and the calculated tseg2 value. As the SJW can have values up to 4 providing
> this value will lead to the maximum possible SJW automatically. A higher SJW
> allows higher controller oscillator tolerances.
>
> Signed-off-by: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
Acked-by: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
Thanks,
Wolfgang.
^ permalink raw reply
* Re: __pskb_pull_tail oops from 2.6.35
From: David Miller @ 2011-09-27 20:08 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20110927200328.GA22678@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Tue, 27 Sep 2011 16:03:28 -0400
> A user just reported this on a fairly old kernel (running the latest -longterm patch).
> I had a look through net/core/skbuff.c since 2.6.35, and didn't see anything obvious.
> Does this look familiar to anyone ?
I would say that something far outside of __pskb_pull_tail() is corrupting the
SKB state. He has a bunch of netfilter stuff loaded so the possibilities are
endless :-)
Any chance to figure out exactly what NULL dereference happens inside of
__pskb_pull_tail()?
^ permalink raw reply
* Re: [PATCH] ipv6-multicast: Fix memory leak in input path.
From: Eric Dumazet @ 2011-09-27 20:08 UTC (permalink / raw)
To: Ben Greear; +Cc: David Miller, netdev
In-Reply-To: <4E822552.7000401@candelatech.com>
Le mardi 27 septembre 2011 à 12:34 -0700, Ben Greear a écrit :
> On 09/27/2011 12:16 PM, David Miller wrote:
> > From: greearb@candelatech.com
> > Date: Tue, 27 Sep 2011 11:58:17 -0700
> >
> >> From: Ben Greear<greearb@candelatech.com>
> >>
> >> Have to free the skb before returning if we fail
> >> the fib lookup.
> >>
> >> Signed-off-by: Ben Greear<greearb@candelatech.com>
> >
> > Applied, thanks.
>
> Thanks.
>
> This bug was introduced in 2.6.35, I believe, so should probably send
> this to stable as well.
>
A good way to handle this is to include in the changelog of the patch
the reference on faulty commit, to ease David and stable teams work.
Commit d1db275dd3f6
(ipv6: ip6mr: support multiple tables)
^ permalink raw reply
* Re: __pskb_pull_tail oops from 2.6.35
From: Dave Jones @ 2011-09-27 20:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110927.160804.528213323197711241.davem@davemloft.net>
On Tue, Sep 27, 2011 at 04:08:04PM -0400, David Miller wrote:
> From: Dave Jones <davej@redhat.com>
> Date: Tue, 27 Sep 2011 16:03:28 -0400
>
> > A user just reported this on a fairly old kernel (running the latest -longterm patch).
> > I had a look through net/core/skbuff.c since 2.6.35, and didn't see anything obvious.
> > Does this look familiar to anyone ?
>
> I would say that something far outside of __pskb_pull_tail() is corrupting the
> SKB state. He has a bunch of netfilter stuff loaded so the possibilities are
> endless :-)
>
> Any chance to figure out exactly what NULL dereference happens inside of
> __pskb_pull_tail()?
It looks like it died in put_page..
<1>[ 262.574991] IP: [<ffffffff810dca57>] put_page+0x10/0x7c
which is only called in one place..
1267 for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
1268 if (skb_shinfo(skb)->frags[i].size <= eat) {
1269 put_page(skb_shinfo(skb)->frags[i].page);
1270 eat -= skb_shinfo(skb)->frags[i].size;
1271 } else {
Dave
^ permalink raw reply
* Re: __pskb_pull_tail oops from 2.6.35
From: David Miller @ 2011-09-27 20:18 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20110927201500.GA27713@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Tue, 27 Sep 2011 16:15:00 -0400
> It looks like it died in put_page..
>
> <1>[ 262.574991] IP: [<ffffffff810dca57>] put_page+0x10/0x7c
>
> which is only called in one place..
>
> 1267 for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> 1268 if (skb_shinfo(skb)->frags[i].size <= eat) {
> 1269 put_page(skb_shinfo(skb)->frags[i].page);
> 1270 eat -= skb_shinfo(skb)->frags[i].size;
> 1271 } else {
That's a pretty serious corruption, all frag array entries from 0 to
nr_frags should have valid, non-NULL page pointers.
Maybe a LRO/GRO bug? There were a couple of those.
^ permalink raw reply
* Re: __pskb_pull_tail oops from 2.6.35
From: Dave Jones @ 2011-09-27 20:24 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110927.161848.1967387021236457958.davem@davemloft.net>
On Tue, Sep 27, 2011 at 04:18:48PM -0400, David Miller wrote:
> From: Dave Jones <davej@redhat.com>
> Date: Tue, 27 Sep 2011 16:15:00 -0400
>
> > It looks like it died in put_page..
> >
> > <1>[ 262.574991] IP: [<ffffffff810dca57>] put_page+0x10/0x7c
> >
> > which is only called in one place..
> >
> > 1267 for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> > 1268 if (skb_shinfo(skb)->frags[i].size <= eat) {
> > 1269 put_page(skb_shinfo(skb)->frags[i].page);
> > 1270 eat -= skb_shinfo(skb)->frags[i].size;
> > 1271 } else {
>
> That's a pretty serious corruption, all frag array entries from 0 to
> nr_frags should have valid, non-NULL page pointers.
>
> Maybe a LRO/GRO bug? There were a couple of those.
I'll see if I can talk him into trying a self-built kernel, as we're not
rebasing f14 at this point in its life-cycle. If it turns out to still affect
3.x, I'll bring it up again.
Dave
^ permalink raw reply
* Re: __pskb_pull_tail oops from 2.6.35
From: Eric Dumazet @ 2011-09-27 20:37 UTC (permalink / raw)
To: Dave Jones; +Cc: David Miller, netdev
In-Reply-To: <20110927202405.GB27713@redhat.com>
Le mardi 27 septembre 2011 à 16:24 -0400, Dave Jones a écrit :
> On Tue, Sep 27, 2011 at 04:18:48PM -0400, David Miller wrote:
> > From: Dave Jones <davej@redhat.com>
> > Date: Tue, 27 Sep 2011 16:15:00 -0400
> >
> > > It looks like it died in put_page..
> > >
> > > <1>[ 262.574991] IP: [<ffffffff810dca57>] put_page+0x10/0x7c
> > >
> > > which is only called in one place..
> > >
> > > 1267 for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
> > > 1268 if (skb_shinfo(skb)->frags[i].size <= eat) {
> > > 1269 put_page(skb_shinfo(skb)->frags[i].page);
> > > 1270 eat -= skb_shinfo(skb)->frags[i].size;
> > > 1271 } else {
> >
> > That's a pretty serious corruption, all frag array entries from 0 to
> > nr_frags should have valid, non-NULL page pointers.
> >
> > Maybe a LRO/GRO bug? There were a couple of those.
>
> I'll see if I can talk him into trying a self-built kernel, as we're not
> rebasing f14 at this point in its life-cycle. If it turns out to still affect
> 3.x, I'll bring it up again.
>
This could be a struct skb_shared_info -> nr_frags corruption
(Something was overflowing skb head and overflowing very beginning of
skb_shared_info in rare circumstances)
We had such bug in the past, I cant remember details right now.
^ 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