* Re: e1000e hardware CRC stripping breaks bridging
From: Johan Andersson @ 2008-02-12 13:57 UTC (permalink / raw)
To: Daniel Drake; +Cc: Auke Kok, netdev
In-Reply-To: <47B19EDE.5020802@gentoo.org>
Here is the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=9940
/Johan
On Tue, 2008-02-12 at 13:27 +0000, Daniel Drake wrote:
> Hi,
>
> Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
> stripping enabled by e1000e breaks bridging because sometimes the CRC is
> not stripped:
> https://bugs.gentoo.org/show_bug.cgi?id=209235
>
> Apparently "upstream" are aware but I couldn't find any mails or bug
> reports on this topic.
>
> What's the current status of this issue? Perhaps we should disable
> hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
>
> Thanks,
> Daniel
> --
> 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
* e1000e hardware CRC stripping breaks bridging
From: Daniel Drake @ 2008-02-12 13:27 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev
Hi,
Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
stripping enabled by e1000e breaks bridging because sometimes the CRC is
not stripped:
https://bugs.gentoo.org/show_bug.cgi?id=209235
Apparently "upstream" are aware but I couldn't find any mails or bug
reports on this topic.
What's the current status of this issue? Perhaps we should disable
hardware CRC stripping for 2.6.24.x/2.6.25 until this gets fixed?
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-12 13:24 UTC (permalink / raw)
To: James Chapman; +Cc: David Miller, netdev
In-Reply-To: <47B17BCD.2070903@katalix.com>
On Tue, Feb 12, 2008 at 10:58:21AM +0000, James Chapman wrote:
...
> Here is a trace from when we had _bh locks.
Very nice...
...But since it's quite long, and if you don't know all these paths
this could take some time, maybe one question: so if lockdep got these
locks right (sometimes it can be wrong when the same structures are
nested), then it seems some problem is with this place below. This
lock is taken for writing with softirqs enabled here, and IMHO it
would be interesting to test if changing this is enough for lockdep.
It seems this is in ip4_datagram_connect() during sk_dst_reset() or
sk_dst_set(). So maybe you could try with local_bh_disable/enable()
around them (or maybe some better idea)? Anyway, I'll try to learn
this more in the meantime.
Jarek P.
> Feb 5 16:26:32 to a soft-irq-unsafe lock:
> Feb 5 16:26:32 (&sk->sk_dst_lock){----}
> Feb 5 16:26:32 ... which became soft-irq-unsafe at:
> Feb 5 16:26:32 ... [<c014e02e>] mark_held_locks+0x5e/0x80
> Feb 5 16:26:32 [<c014ed92>] __lock_acquire+0x6a2/0x10a0
> Feb 5 16:26:32 [<c010f5b0>] save_stack_trace+0x20/0x40
> Feb 5 16:26:32 [<c014c524>] add_lock_to_list+0x44/0xb0
> Feb 5 16:26:32 [<c03dea29>] __udp_lib_get_port+0x19/0x200
> Feb 5 16:26:32 [<c014f735>] __lock_acquire+0x1045/0x10a0
> Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
> Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
> Feb 5 16:26:32 [<c040418a>] _write_lock+0x2a/0x40
> Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
> Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
> Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
> Feb 5 16:26:32 [<c0132317>] local_bh_enable_ip+0xa7/0x120
> Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
> Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
> Feb 5 16:26:32 [<c03e4d55>] inet_dgram_connect+0x35/0x80
> Feb 5 16:26:32 [<c038ec52>] sys_connect+0x82/0xd0
> Feb 5 16:26:32 [<c01455df>] down_read_trylock+0x4f/0x60
> Feb 5 16:26:32 [<c011fe9c>] do_page_fault+0xfc/0x940
> Feb 5 16:26:32 [<c0404024>] _spin_unlock+0x14/0x20
> Feb 5 16:26:32 [<c03905f8>] sys_socketcall+0x98/0x280
> Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
> Feb 5 16:26:32 [<c02a86ba>] copy_to_user+0x3a/0x70
> Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
> Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
> Feb 5 16:26:32 [<ffffffff>] 0xffffffff
^ permalink raw reply
* Re: [git patches] net driver updates
From: Ben Dooks @ 2008-02-12 12:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, netdev, Laurent Pinchart
In-Reply-To: <20080211170516.GA13872@havoc.gtf.org>
On Mon, Feb 11, 2008 at 12:05:16PM -0500, Jeff Garzik wrote:
> Mostly fixes, a few cleanups (generally assisting fixes), and an
> exception for PS3 wireless because it had been posted, reviewed and
> acked for a while, just not committed.
Thanks, good to get the DM9000 changes moving.
> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem
>
> Ben Dooks (24):
> DM9000: Fix endian-ness of data accesses.
> DM9000: Add platform data to specify external phy
These two where meant to be from Laurent Pinchart, they do have
the correct signed-off lines in for him and start with "Patch from:". Is
there any chance of fixing the authour attribution now?
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: James Chapman @ 2008-02-12 10:58 UTC (permalink / raw)
To: David Miller, jarkao2; +Cc: netdev
In-Reply-To: <20080211.213048.192442721.davem@davemloft.net>
David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Mon, 11 Feb 2008 23:41:18 +0000
>
>> Jarek Poplawski wrote:
>>> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
>>> ...
>>>> Below is example output from lockdep. The oops is reproducible when
>>>> creating/deleting lots of sessions while passing data. The lock is being
>>>> acquired for read and write in softirq contexts.
>>>>
>>>> Is there a better way to fix this?
>>>>
>>>> =================================
>>>> [ INFO: inconsistent lock state ]
>>>> 2.6.24-core2 #1
>>>> ---------------------------------
>>>> inconsistent {in-softirq-R} -> {softirq-on-W} usage.
>>>> openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
>>>> (&tunnel->hlist_lock){---?}, at: [<f8eea157>]
>>>> pppol2tp_connect+0x517/0x6d0 [pppol2tp]
>>>> {in-softirq-R} state was registered at:
>>> IMHO, according to this, disabling bh should be enough. And if it's
>>> like in this report: only read_lock is taken from softirqs, then this
>>> should be necessary to change only all write_locks to write_lock_bh
>>> (of course unless somewhere bhs are disabled already). Unless I miss
>>> something?!
>> I thought so too. I tried _bh locks first and the problem still
>> occurred. Maybe I'll try it again in case I messed something up.
>
> I agree with Jarek here, I look at all the code paths that take
> ->hlist_lock and all of them are in user context or software
> interrupts.
>
> Please get a lockdep trace with the change to _bh intead of
> hw interrupt protection so we can find out what that doesn't
> work.
>
> Thanks!
Here is a trace from when we had _bh locks.
Feb 5 16:26:32 ======================================================
Feb 5 16:26:32 [ INFO: soft-safe -> soft-unsafe lock order detected ]
Feb 5 16:26:32 2.6.24-core2 #1
Feb 5 16:26:32 ------------------------------------------------------
Feb 5 16:26:32 pppd/3224 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
Feb 5 16:26:32 (&sk->sk_dst_lock){----}, at: [<f8efacac>]
pppol2tp_xmit+0x23c/0x460 [pppol2tp]
Feb 5 16:26:32
Feb 5 16:26:32 and this task is already holding:
Feb 5 16:26:32 (&pch->downl){-...}, at: [<f8eb828e>]
ppp_push+0x44e/0x620 [ppp_generic]
Feb 5 16:26:32 which would create a new lock dependency:
Feb 5 16:26:32 (&pch->downl){-...} -> (&sk->sk_dst_lock){----}
Feb 5 16:26:32
Feb 5 16:26:32 but this new dependency connects a soft-irq-safe lock:
Feb 5 16:26:32 (&pch->upl){-.-+}
Feb 5 16:26:32 ... which became soft-irq-safe at:
Feb 5 16:26:32 [<c014d87f>] check_usage_backwards+0x1f/0x50
Feb 5 16:26:32 [<c014c479>] save_trace+0x39/0xa0
Feb 5 16:26:32 [<c014edaf>] __lock_acquire+0x6bf/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8ef915a>] pppol2tp_recv_core+0x46a/0x960 [pppol2tp]
Feb 5 16:26:32 [<f8ef967e>] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
Feb 5 16:26:32 [<c0403fd4>] _read_unlock+0x14/0x20
Feb 5 16:26:32 [<c03dd6b6>] udp_queue_rcv_skb+0x106/0x2a0
Feb 5 16:26:32 [<c03ddc7a>] __udp4_lib_rcv+0x42a/0x7e0
Feb 5 16:26:32 [<f8d5c090>] ipt_hook+0x0/0x20 [iptable_filter]
Feb 5 16:26:32 [<c03bc2fa>] ip_local_deliver_finish+0xca/0x1c0
Feb 5 16:26:32 [<c03bc25e>] ip_local_deliver_finish+0x2e/0x1c0
Feb 5 16:26:32 [<c03bbfcf>] ip_rcv_finish+0xff/0x360
Feb 5 16:26:32 [<c03bc6fc>] ip_rcv+0x20c/0x2a0
Feb 5 16:26:32 [<c03bbed0>] ip_rcv_finish+0x0/0x360
Feb 5 16:26:32 [<c039ad87>] netif_receive_skb+0x317/0x4b0
Feb 5 16:26:32 [<c039ab70>] netif_receive_skb+0x100/0x4b0
Feb 5 16:26:32 [<f8d7e27a>] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
Feb 5 16:26:32 [<f8d7dff0>] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
Feb 5 16:26:32 [<c0536150>] unknown_bootoption+0x0/0x1f0
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32
Feb 5 16:26:32 to a soft-irq-unsafe lock:
Feb 5 16:26:32 (&sk->sk_dst_lock){----}
Feb 5 16:26:32 ... which became soft-irq-unsafe at:
Feb 5 16:26:32 ... [<c014e02e>] mark_held_locks+0x5e/0x80
Feb 5 16:26:32 [<c014ed92>] __lock_acquire+0x6a2/0x10a0
Feb 5 16:26:32 [<c010f5b0>] save_stack_trace+0x20/0x40
Feb 5 16:26:32 [<c014c524>] add_lock_to_list+0x44/0xb0
Feb 5 16:26:32 [<c03dea29>] __udp_lib_get_port+0x19/0x200
Feb 5 16:26:32 [<c014f735>] __lock_acquire+0x1045/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
Feb 5 16:26:32 [<c040418a>] _write_lock+0x2a/0x40
Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
Feb 5 16:26:32 [<c03db0a3>] ip4_datagram_connect+0x53/0x380
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0132317>] local_bh_enable_ip+0xa7/0x120
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<c03e4d55>] inet_dgram_connect+0x35/0x80
Feb 5 16:26:32 [<c038ec52>] sys_connect+0x82/0xd0
Feb 5 16:26:32 [<c01455df>] down_read_trylock+0x4f/0x60
Feb 5 16:26:32 [<c011fe9c>] do_page_fault+0xfc/0x940
Feb 5 16:26:32 [<c0404024>] _spin_unlock+0x14/0x20
Feb 5 16:26:32 [<c03905f8>] sys_socketcall+0x98/0x280
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c02a86ba>] copy_to_user+0x3a/0x70
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32
Feb 5 16:26:32 other info that might help us debug this:
Feb 5 16:26:32
Feb 5 16:26:32 2 locks held by pppd/3224:
Feb 5 16:26:32 #0: (&ppp->wlock){-...}, at: [<f8eb8478>]
ppp_xmit_process+0x18/0x630 [ppp_generic]
Feb 5 16:26:32 #1: (&pch->downl){-...}, at: [<f8eb828e>]
ppp_push+0x44e/0x620 [ppp_generic]
Feb 5 16:26:32
Feb 5 16:26:32 the soft-irq-safe lock's dependencies:
Feb 5 16:26:32 -> (&pch->upl){-.-+} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<f8efacf3>] pppol2tp_xmit+0x283/0x460 [pppol2tp]
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb9ffd>] ppp_write+0xdd/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0181f86>] vfs_write+0xa6/0x140
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<f8eb9f20>] ppp_write+0x0/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0182651>] sys_write+0x41/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-W at:
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014c524>] add_lock_to_list+0x44/0xb0
Feb 5 16:26:32 [<c014ed68>] __lock_acquire+0x678/0x10a0
Feb 5 16:26:32 [<c014e02e>] mark_held_locks+0x5e/0x80
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7387>] ppp_ioctl+0x647/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c04041cf>] _write_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7387>] ppp_ioctl+0x647/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7387>] ppp_ioctl+0x647/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 in-softirq-R at:
Feb 5 16:26:32 [<c014d87f>] check_usage_backwards+0x1f/0x50
Feb 5 16:26:32 [<c014c479>] save_trace+0x39/0xa0
Feb 5 16:26:32 [<c014edaf>] __lock_acquire+0x6bf/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8eba092>] ppp_input+0x62/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8ef915a>] pppol2tp_recv_core+0x46a/0x960 [pppol2tp]
Feb 5 16:26:32 [<f8ef967e>] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
Feb 5 16:26:32 [<c0403fd4>] _read_unlock+0x14/0x20
Feb 5 16:26:32 [<c03dd6b6>] udp_queue_rcv_skb+0x106/0x2a0
Feb 5 16:26:32 [<c03ddc7a>] __udp4_lib_rcv+0x42a/0x7e0
Feb 5 16:26:32 [<f8d5c090>] ipt_hook+0x0/0x20 [iptable_filter]
Feb 5 16:26:32 [<c03bc2fa>] ip_local_deliver_finish+0xca/0x1c0
Feb 5 16:26:32 [<c03bc25e>] ip_local_deliver_finish+0x2e/0x1c0
Feb 5 16:26:32 [<c03bbfcf>] ip_rcv_finish+0xff/0x360
Feb 5 16:26:32 [<c03bc6fc>] ip_rcv+0x20c/0x2a0
Feb 5 16:26:32 [<c03bbed0>] ip_rcv_finish+0x0/0x360
Feb 5 16:26:32 [<c039ad87>] netif_receive_skb+0x317/0x4b0
Feb 5 16:26:32 [<c039ab70>] netif_receive_skb+0x100/0x4b0
Feb 5 16:26:32 [<f8d7e27a>] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
Feb 5 16:26:32 [<f8d7dff0>] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
Feb 5 16:26:32 [<c0536150>] unknown_bootoption+0x0/0x1f0
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-R at:
Feb 5 16:26:32 [<c014da27>] mark_lock+0x77/0x620
Feb 5 16:26:32 [<c014ec2f>] __lock_acquire+0x53f/0x10a0
Feb 5 16:26:32 [<f8efacf3>] pppol2tp_xmit+0x283/0x460 [pppol2tp]
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<c040425f>] _read_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb8af2>] ppp_channel_push+0x62/0x90 [ppp_generic]
Feb 5 16:26:32 [<f8eb9ffd>] ppp_write+0xdd/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0181f86>] vfs_write+0xa6/0x140
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<f8eb9f20>] ppp_write+0x0/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0182651>] sys_write+0x41/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 }
Feb 5 16:26:32 ... key at: [<f8ebdf20>]
__key.30415+0x0/0xffffc2e7 [ppp_generic]
Feb 5 16:26:32 -> (&ppp->wlock){-...} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-W at:
Feb 5 16:26:32 [<c014da27>] mark_lock+0x77/0x620
Feb 5 16:26:32 [<c014ed68>] __lock_acquire+0x678/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7698>] ppp_ioctl+0x958/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 }
Feb 5 16:26:32 ... key at: [<f8ebdf08>]
__key.30659+0x0/0xffffc2ff [ppp_generic]
Feb 5 16:26:32 -> (&ppp->rlock){-...} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 hardirq-on-W at:
Feb 5 16:26:32 [<c014da27>] mark_lock+0x77/0x620
Feb 5 16:26:32 [<c014ed68>] __lock_acquire+0x678/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb7661>] ppp_ioctl+0x921/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c014e1c5>] trace_hardirqs_on+0xc5/0x170
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 }
Feb 5 16:26:32 ... key at: [<f8ebdf10>]
__key.30658+0x0/0xffffc2f7 [ppp_generic]
Feb 5 16:26:32 ... acquired at:
Feb 5 16:26:32 [<c014f68f>] __lock_acquire+0xf9f/0x10a0
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c040414f>] _spin_lock_bh+0x2f/0x40
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<f8eb76a5>] ppp_ioctl+0x965/0xf40 [ppp_generic]
Feb 5 16:26:32 [<c0404665>] _spin_unlock_irqrestore+0x55/0x70
Feb 5 16:26:32 [<c0403e4e>] __down+0xde/0xed
Feb 5 16:26:32 [<c0124220>] default_wake_function+0x0/0x10
Feb 5 16:26:32 [<c0403bdb>] __down_failed+0x7/0xc
Feb 5 16:26:32 [<c018d8f8>] do_ioctl+0x78/0x90
Feb 5 16:26:32 [<c018d96c>] vfs_ioctl+0x5c/0x290
Feb 5 16:26:32 [<c018dbdd>] sys_ioctl+0x3d/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32
Feb 5 16:26:32 -> (&list->lock#4){.+..} ops: 0 {
Feb 5 16:26:32 initial-use at:
Feb 5 16:26:32 [<c014e80d>] __lock_acquire+0x11d/0x10a0
Feb 5 16:26:32 [<c0193ba2>] dput+0xa2/0x130
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c040450c>] _spin_lock_irqsave+0x4c/0x70
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<f8eb9fd5>] ppp_write+0xb5/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0181f86>] vfs_write+0xa6/0x140
Feb 5 16:26:32 [<c0108417>] restore_nocheck+0x12/0x15
Feb 5 16:26:32 [<f8eb9f20>] ppp_write+0x0/0x110 [ppp_generic]
Feb 5 16:26:32 [<c0182651>] sys_write+0x41/0x70
Feb 5 16:26:32 [<c01083aa>] syscall_call+0x7/0xb
Feb 5 16:26:32 [<ffffffff>] 0xffffffff
Feb 5 16:26:32 in-softirq-W at:
Feb 5 16:26:32 [<c014c479>] save_trace+0x39/0xa0
Feb 5 16:26:32 [<c014db32>] mark_lock+0x182/0x620
Feb 5 16:26:32 [<c014ed36>] __lock_acquire+0x646/0x10a0
Feb 5 16:26:32 [<c014ef26>] __lock_acquire+0x836/0x10a0
Feb 5 16:26:32 [<c014ee8e>] __lock_acquire+0x79e/0x10a0
Feb 5 16:26:32 [<c014f804>] lock_acquire+0x74/0xa0
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c040450c>] _spin_lock_irqsave+0x4c/0x70
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<c0394b9c>] skb_queue_tail+0x1c/0x50
Feb 5 16:26:32 [<f8eba0a8>] ppp_input+0x78/0x140 [ppp_generic]
Feb 5 16:26:32 [<f8ef915a>] pppol2tp_recv_core+0x46a/0x960 [pppol2tp]
Feb 5 16:26:32 [<f8ef967e>] pppol2tp_udp_encap_recv+0x2e/0x70 [pppol2tp]
Feb 5 16:26:32 [<c0403fd4>] _read_unlock+0x14/0x20
Feb 5 16:26:32 [<c03dd6b6>] udp_queue_rcv_skb+0x106/0x2a0
Feb 5 16:26:32 [<c03ddc7a>] __udp4_lib_rcv+0x42a/0x7e0
Feb 5 16:26:32 [<f8d5c090>] ipt_hook+0x0/0x20 [iptable_filter]
Feb 5 16:26:32 [<c03bc2fa>] ip_local_deliver_finish+0xca/0x1c0
Feb 5 16:26:32 [<c03bc25e>] ip_local_deliver_finish+0x2e/0x1c0
Feb 5 16:26:32 [<c03bbfcf>] ip_rcv_finish+0xff/0x360
Feb 5 16:26:32 [<c03bc6fc>] ip_rcv+0x20c/0x2a0
Feb 5 16:26:32 [<c03bbed0>] ip_rcv_finish+0x0/0x360
Feb 5 16:26:32 [<c039ad87>] netif_receive_skb+0x317/0x4b0
Feb 5 16:26:32 [<c039ab70>] netif_receive_skb+0x100/0x4b0
Feb 5 16:26:32 [<f8d7e27a>] e1000_clean_rx_irq_ps+0x28a/0x560 [e1000]
Feb 5 16:26:32 [<f8d7dff0>] e1000_clean_rx_irq_ps+0x0/0x560 [e1000]
Feb 5 16:26:32 [<f8d7b84d>] e1000_clean+0x5d/0x290 [e1000]
Feb 5 16:26:32 [<c039d580>] net_rx_action+0x1a0/0x2a0
Feb 5 16:26:32 [<c039d43f>] net_rx_action+0x5f/0x2a0
Feb 5 16:26:32 [<c0131e72>] __do_softirq+0x92/0x120
Feb 5 16:26:32 [<c0131f78>] do_softirq+0x78/0x80
Feb 5 16:26:32 [<c010b15a>] do_IRQ+0x4a/0xa0
Feb 5 16:26:32 [<c0127af0>] finish_task_switch+0x0/0xc0
Feb 5 16:26:32 [<c0108dcc>] common_interrupt+0x24/0x34
Feb 5 16:26:32 [<c0108dd6>] common_interrupt+0x2e/0x34
Feb 5 16:26:32 [<c01062d6>] mwait_idle_with_hints+0x46/0x60
Feb 5 16:26:32 [<c0106550>] mwait_idle+0x0/0x20
Feb 5 16:26:32 [<c0106694>] cpu_idle+0x74/0xe0
Feb 5 16:26:32 [<c0536a9a>] start_kernel+0x30a/0x3a0
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* [Bug 9750] [patch 2.6.25] dev: avoid a race that triggers assertion failure
From: Matti Linnanvuori @ 2008-02-12 10:45 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: bugme-daemon
From: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
There is a race in Linux kernel file net/core/dev.c, function dev_close.
The function calls function dev_deactivate, which calls function
dev_watchdog_down that deletes the watchdog timer. However, after that, a
driver can call netif_carrier_ok, which calls function
__netdev_watchdog_up that can add the watchdog timer again. Function
unregister_netdevice calls function dev_shutdown that traps the bug
!timer_pending(&dev->watchdog_timer). Moving dev_deactivate after
netif_running() has been cleared prevents function netif_carrier_on
from calling __netdev_watchdog_up and adding the watchdog timer again.
Signed-off-by: Matti Linnanvuori <mattilinnanvuori@yahoo.com>
---
--- linux-2.6.25/net/core/dev.c 2008-02-12 12:37:51.206833000 +0200
+++ b/net/core/dev.c 2008-02-12 12:38:48.727611400 +0200
@@ -1071,8 +1071,6 @@ int dev_close(struct net_device *dev)
*/
call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
- dev_deactivate(dev);
-
clear_bit(__LINK_STATE_START, &dev->state);
/* Synchronize to scheduled poll. We cannot touch poll list,
@@ -1083,6 +1081,7 @@ int dev_close(struct net_device *dev)
*/
smp_mb__after_clear_bit(); /* Commit netif_running(). */
+ dev_deactivate(dev);
/*
* Call the device specific close. This cannot fail.
* Only if device is UP
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-12 10:42 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <47B0DD54.5000100@katalix.com>
On Mon, Feb 11, 2008 at 11:42:12PM +0000, James Chapman wrote:
> Jarek Poplawski wrote:
>> On Mon, Feb 11, 2008 at 11:49:24PM +0100, Jarek Poplawski wrote:
>>> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
>>> ...
>>>> Below is example output from lockdep. The oops is reproducible when
>>>> creating/deleting lots of sessions while passing data. The lock is
>>>> being acquired for read and write in softirq contexts.
>>
>> ...Hmmm... And according to this, changing read_locks should be
>> necessary too.
>
> The patch changes both read and write locks.
Right! This was only "errata" to my earlier comment where I considered
only lockdep info and forgot about yours...
Sorry,
Jarek P.
^ permalink raw reply
* [PATCH] [IRDA] irda_init() nuke useless debug printk
From: maximilian attems @ 2008-02-12 10:30 UTC (permalink / raw)
To: davem; +Cc: netdev, maximilian attems
irda_init()
dmesg line is not really informative, thus remove it.
There are better ways to know that a module is loaded.
Seen on a debian config with IRDA_DEBUG enabled.
Signed-off-by: maximilian attems <max@stro.at>
---
net/irda/irmod.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/irda/irmod.c b/net/irda/irmod.c
index 01554b9..73db875 100644
--- a/net/irda/irmod.c
+++ b/net/irda/irmod.c
@@ -90,8 +90,6 @@ static int __init irda_init(void)
{
int ret = 0;
- IRDA_DEBUG(0, "%s()\n", __FUNCTION__);
-
/* Lower layer of the stack */
irlmp_init();
irlap_init();
--
1.5.4
^ permalink raw reply related
* Re: [Bugme-new] [Bug 9940] New: e1000e driver with 82566DM-2 controller doesn't strip crc from frames
From: Andrew Morton @ 2008-02-12 10:12 UTC (permalink / raw)
To: Auke Kok; +Cc: bugme-daemon, netdev, johan.andersson
In-Reply-To: <bug-9940-10286@http.bugzilla.kernel.org/>
On Tue, 12 Feb 2008 01:50:49 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9940
>
> Summary: e1000e driver with 82566DM-2 controller doesn't strip
> crc from frames
> Product: Drivers
> Version: 2.5
> KernelVersion: 2.6.24
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: jgarzik@pobox.com
> ReportedBy: johan.andersson@transmode.se
>
>
> Latest working kernel version: n/a
> Earliest failing kernel version: 2.6.24
> Distribution: Gentoo 2007.0
> Hardware Environment: HP Compaq dc7800p
> Software Environment: n/a
> Problem Description:
> The e1000e driver doesn't strip the ethernet frame crc is used with the
> 82566DM-2 chip.
> This will result, among other things, that bridging doesn't work together with
> this chip.
> Reverting commit 140a74802894e9db57e5cd77ccff77e590ece5f3 fixes this issue but
> has performance implications.
>
> Steps to reproduce:
> Send a ping and monitor the responce with tcpdump.
>
^ permalink raw reply
* [PATCH] 2.6.25-rc1 ml4x network driver build failure
From: Kamalesh Babulal @ 2008-02-12 9:42 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, akpm
The 2.6.25-rc1 kernel build fails on the powerpc with the error
drivers/net/mlx4/alloc.c: In function ‘mlx4_buf_alloc’:
drivers/net/mlx4/alloc.c:162: error: implicit declaration of function ‘vmap’
drivers/net/mlx4/alloc.c:162: error: ‘VM_MAP’ undeclared (first use in this function)
drivers/net/mlx4/alloc.c:162: error: (Each undeclared identifier is reported only once
drivers/net/mlx4/alloc.c:162: error: for each function it appears in.)
drivers/net/mlx4/alloc.c:162: warning: assignment makes pointer from integer without a cast
drivers/net/mlx4/alloc.c: In function ‘mlx4_buf_free’:
drivers/net/mlx4/alloc.c:187: error: implicit declaration of function ‘vunmap’
make[3]: *** [drivers/net/mlx4/alloc.o] Error 1
make[2]: *** [drivers/net/mlx4] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
I have tested the patch for the build failure.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
--- linux-2.6.25-rc1/drivers/net/mlx4/alloc.c 2008-02-11 03:48:14.000000000 +0530
+++ linux-2.6.25-rc1/drivers/net/mlx4/~alloc.c 2008-02-12 14:43:46.000000000 +0530
@@ -34,6 +34,7 @@
#include <linux/slab.h>
#include <linux/bitmap.h>
#include <linux/dma-mapping.h>
+#include <linux/vmalloc.h>
#include "mlx4.h"
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
From: Jarek Poplawski @ 2008-02-12 9:44 UTC (permalink / raw)
To: Jann Traschewski
Cc: 'David Miller', 'Bernard Pidoux F6BVP',
'Ralf Baechle DL5RB', netdev
In-Reply-To: <000201c86d53$569297e0$453c822c@dg8ngn>
On Tue, Feb 12, 2008 at 09:43:26AM +0100, Jann Traschewski wrote:
> Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
> Thanks,
> Jann
Thanks Jann, too!
BTW, I hope maybe until tomorrow I'll figure out something about those
earlier two AX25 testing patches.
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Jarek Poplawski @ 2008-02-12 8:57 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, paulmck, netdev, linux-kernel
In-Reply-To: <20080211.171645.74019568.davem@davemloft.net>
On 12-02-2008 02:16, David Miller wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Mon, 11 Feb 2008 16:59:54 -0800
>
> linux-kernel added to CC:, any change to generic kernel infrastructure
> should be posted there
>
>> Eliminate warnings when rcu_assign_pointer is used with unsigned long.
>> It is reasonable to use RCU with non-pointer values so allow it for general
>> use. Add a comment to explain the if test.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>> ---
>> include/linux/rcupdate.h | 13 +++++++------
>> 1 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
>> index 37a642c..c44ac87 100644
>> --- a/include/linux/rcupdate.h
>> +++ b/include/linux/rcupdate.h
>> @@ -172,14 +172,15 @@ struct rcu_head {
>> * structure after the pointer assignment. More importantly, this
>> * call documents which pointers will be dereferenced by RCU read-side
>> * code.
>> + *
>> + * If value is the NULL (constant 0), then no barrier is needed.
>> */
>>
>> -#define rcu_assign_pointer(p, v) \
>> - ({ \
>> - if (!__builtin_constant_p(v) || \
>> - ((v) != NULL)) \
>> - smp_wmb(); \
>> - (p) = (v); \
>> +#define rcu_assign_pointer(p, v) \
>> + ({ \
>> + if (!(__builtin_constant_p(v) && v)) \
...But, "If value is the NULL (constant 0)" we have:
if (!(1 && NULL != 0)) ==> if (!(0)) and the barrier is used?!
>> + smp_wmb(); \
>> + (p) = (v); \
>> })
>>
>> /**
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
From: Jann Traschewski @ 2008-02-12 8:43 UTC (permalink / raw)
To: 'Jarek Poplawski', 'David Miller'
Cc: 'Bernard Pidoux F6BVP', 'Ralf Baechle DL5RB',
netdev
In-Reply-To: <20080211124251.GB3597@ff.dom.local>
Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
Thanks,
Jann
> -----Ursprüngliche Nachricht-----
> Von: Jarek Poplawski [mailto:jarkao2@gmail.com]
> Gesendet: Montag, 11. Februar 2008 13:43
> An: David Miller
> Cc: Jann Traschewski; Bernard Pidoux F6BVP; Ralf Baechle
> DL5RB; netdev@vger.kernel.org
> Betreff: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
>
>
> Subject: [AX25] ax25_route: make ax25_route_lock BH safe
>
> > =================================
> > [ INFO: inconsistent lock state ]
> > 2.6.24-dg8ngn-p02 #1
> > ---------------------------------
> > inconsistent {softirq-on-W} -> {in-softirq-R} usage.
> > linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
> > (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7
> > [ax25] {softirq-on-W} state was registered at:
> ...
>
> This lockdep report shows that ax25_route_lock is taken for
> reading in softirq context, and for writing in process
> context with BHs enabled.
> So, to make this safe, all write_locks in ax25_route.c are
> changed to _bh versions.
>
>
> Reported-by: Jann Traschewski <jann@gmx.de>,
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
>
> ---
>
> diff -Nurp 2.6.24-mm1-/net/ax25/ax25_route.c
> 2.6.24-mm1+/net/ax25/ax25_route.c
> --- 2.6.24-mm1-/net/ax25/ax25_route.c 2008-02-05
> 07:45:38.000000000 +0000
> +++ 2.6.24-mm1+/net/ax25/ax25_route.c 2008-02-11
> 11:58:47.000000000 +0000
> @@ -45,7 +45,7 @@ void ax25_rt_device_down(struct net_devi {
> ax25_route *s, *t, *ax25_rt;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> s = ax25_rt;
> @@ -68,7 +68,7 @@ void ax25_rt_device_down(struct net_devi
> }
> }
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> }
>
> static int __must_check ax25_rt_add(struct
> ax25_routes_struct *route) @@ -82,7 +82,7 @@ static int
> __must_check ax25_rt_add(stru
> if (route->digi_count > AX25_MAX_DIGIS)
> return -EINVAL;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
>
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> @@ -92,7 +92,7 @@ static int __must_check ax25_rt_add(stru
> ax25_rt->digipeat = NULL;
> if (route->digi_count != 0) {
> if ((ax25_rt->digipeat =
> kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
> - write_unlock(&ax25_route_lock);
> +
> write_unlock_bh(&ax25_route_lock);
> return -ENOMEM;
> }
> ax25_rt->digipeat->lastrepeat =
> -1; @@ -102,14 +102,14 @@ static int __must_check ax25_rt_add(stru
>
> ax25_rt->digipeat->calls[i] = route->digi_addr[i];
> }
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> return 0;
> }
> ax25_rt = ax25_rt->next;
> }
>
> if ((ax25_rt = kmalloc(sizeof(ax25_route), GFP_ATOMIC))
> == NULL) {
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> return -ENOMEM;
> }
>
> @@ -120,7 +120,7 @@ static int __must_check ax25_rt_add(stru
> ax25_rt->ip_mode = ' ';
> if (route->digi_count != 0) {
> if ((ax25_rt->digipeat =
> kmalloc(sizeof(ax25_digi), GFP_ATOMIC)) == NULL) {
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> kfree(ax25_rt);
> return -ENOMEM;
> }
> @@ -133,7 +133,7 @@ static int __must_check ax25_rt_add(stru
> }
> ax25_rt->next = ax25_route_list;
> ax25_route_list = ax25_rt;
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
>
> return 0;
> }
> @@ -152,7 +152,7 @@ static int ax25_rt_del(struct ax25_route
> if ((ax25_dev = ax25_addr_ax25dev(&route->port_addr)) == NULL)
> return -EINVAL;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
>
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> @@ -174,7 +174,7 @@ static int ax25_rt_del(struct ax25_route
> }
> }
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
>
> return 0;
> }
> @@ -188,7 +188,7 @@ static int ax25_rt_opt(struct ax25_route
> if ((ax25_dev =
> ax25_addr_ax25dev(&rt_option->port_addr)) == NULL)
> return -EINVAL;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
>
> ax25_rt = ax25_route_list;
> while (ax25_rt != NULL) {
> @@ -216,7 +216,7 @@ static int ax25_rt_opt(struct ax25_route
> }
>
> out:
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> return err;
> }
>
> @@ -492,7 +492,7 @@ void __exit ax25_rt_free(void) {
> ax25_route *s, *ax25_rt = ax25_route_list;
>
> - write_lock(&ax25_route_lock);
> + write_lock_bh(&ax25_route_lock);
> while (ax25_rt != NULL) {
> s = ax25_rt;
> ax25_rt = ax25_rt->next;
> @@ -500,5 +500,5 @@ void __exit ax25_rt_free(void)
> kfree(s->digipeat);
> kfree(s);
> }
> - write_unlock(&ax25_route_lock);
> + write_unlock_bh(&ax25_route_lock);
> }
^ permalink raw reply
* [PATCH] trivial: fix alignment of IP-Config output
From: Uwe Kleine-König @ 2008-02-12 8:38 UTC (permalink / raw)
To: netdev; +Cc: trivial, linux-kernel
make the intended lines aligned in the output (not in the code)
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
---
net/ipv4/ipconfig.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index a52b585..10013cc 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1390,7 +1390,7 @@ static int __init ip_auto_config(void)
* Clue in the operator.
*/
printk("IP-Config: Complete:");
- printk("\n device=%s", ic_dev->name);
+ printk("\n device=%s", ic_dev->name);
printk(", addr=%u.%u.%u.%u", NIPQUAD(ic_myaddr));
printk(", mask=%u.%u.%u.%u", NIPQUAD(ic_netmask));
printk(", gw=%u.%u.%u.%u", NIPQUAD(ic_gateway));
--
1.5.4
^ permalink raw reply related
* Open bugs
From: Natalie Protasevich @ 2008-02-12 8:18 UTC (permalink / raw)
To: linux-kernel, akpm, netdev, alsa-devel, linux-ide, bugme-daemon
Hello,
The bugs listed are over a month old, and haven't been addressed yet.
It would be appreciated if corresponding maintainers identify whether
the bugs have been fixed, or need to be worked on, and take
appropriate action.
In most cases, reporters are standing by and ready to provide
information and necessary testing.
Thanks!
Memory Management=======================================
swapping in 2.6.24-rc5-git3
http://bugzilla.kernel.org/show_bug.cgi?id=9592
Date: 12/07/2007
Regression
Summary:
# /proc/sys/vm# cat swappiness
0
but scp-ing 2GB file causes many processes are swapped out due to
increase of the file cache size.
Was looked at by Jan Kara <jack@suse.cz>; KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> - commented
I/O-Storage================================================
SATA DVD drive & UDF filesystem problem
http://bugzilla.kernel.org/show_bug.cgi?id=9668
12/31/2007
Summary: I mount dvd discs (udf) with piix and ide_cd modules without
problem (on hw decribed higher).
Then I put NEC drive to new mainboard (ICH9 + jmicron SATA/PATA chips)
and use ahci (jmicron) + sr_mod modules.
SCSI======================================================
Problems on booting
http://bugzilla.kernel.org/show_bug.cgi?id=9621
Date: 12/22/2007
Regression
Summary: The boot stops / hangs on hardware detection of SCSI. I have
an InitioINI-9X00U/UW
When I have an usb key sticked in /dev/sba, and run lilo then, then it
dont boot but give L99 99 99 99 ... error
Resetting RAID attached to a FC Switch causes kernel panic and crash
http://bugzilla.kernel.org/show_bug.cgi?id=9598
12/18/2007
Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
8GB Ram, Qlogic FC adapter.
Summary: Resetting the RAID box causes the X4200 to crash.
3ware 9650SE -8LPML not recognized by 3w-9xxx driver
http://bugzilla.kernel.org/show_bug.cgi?id=8908
08/19/2007
Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
RAID Controller.
Plarform===================================================
kexec buffer error
http://bugzilla.kernel.org/show_bug.cgi?id=9693
Date: 01/04/2008
Regression
Summary: Close of /boot/kernel-2.6.24-rc6-git11 failed: : buffer error
kexec load failed, error = 1
20000+ wake-ups/second in 2.6.24
http://bugzilla.kernel.org/show_bug.cgi?id=9489
Date: 12/02/2007
Summary: "something" is causing the system to go into a state where
the cpu throws us right out of the C-state the kernel asks for
Discussed: Arjan van de Ven, Mark Lord
VIDEO/FB======================================================
No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
http://bugzilla.kernel.org/show_bug.cgi?id=9310
11/05/2007 still there
Regression
Summary: After initial boot messages all output to console stops. The
last visible messages are:
checking if image is initramfs...<6>Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 0
After that, nothing until XOrg starts up and graphical login/desktop
on VT7are displayed normal.
DVB===========================================================
DVB-T Pluto2: SUSPEND/RESUME methods are missing for this driver
04/05/2007 - still present in 2.6.24
http://bugzilla.kernel.org/show_bug.cgi?id=8304
Summary: After SWSUPS resume, pluto2 card is not started properly, led
getts not green and card is unable load tda firmware
Hardware Environment: Acer TravelMate
No one looked at it yet.
Several Pluto bug:
DVB-T Pluto2 && PCI: When playing in dmesg I often getts: "pluto2
0000:03:00.0: overflow irq (10)"
Date: 11/08/2006 still there
http://bugzilla.kernel.org/show_bug.cgi?id=7473
Hardware Environment: Acer TravelMate
DVB-T Pluto2: Getting tons of "card hung up :(" messages when card is
removed from pcmcia slot
Date: 11/08/2006 - still there
http://bugzilla.kernel.org/show_bug.cgi?id=7472
DVB-T Pluto2: Unable to change MUX
Date: 11/08/2006
http://bugzilla.kernel.org/show_bug.cgi?id=7471
KNC1 DVB-C cam module not working on driver load
Date: 1/15/2007 - still there
http://bugzilla.kernel.org/show_bug.cgi?id=7825
Error:
DVB: registering new adapter (KNC1 DVB-C)
adapter failed MAC signature check
encoded MAC from EEPROM was
ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
KNC1-0: MAC addr = 00:09:d6:6d:5a:f0
TDA10021: i2c-addr = 0x0c, id = 0x7c
DVB: registering frontend 0 (Philips TDA10021 DVB-C)...
budget-av: ci interface initialised.
budget-av: cam inserted A
dvb_ca adaptor 0: PC card did not respond :(
build #341 failed for 2.6.24-rc6-g1842c7f in
linux/./drivers/media/dvb/ttpci/budget-av.c
01/01/2008
http://bugzilla.kernel.org/show_bug.cgi?id=9671
Still there in 2.6.24.. has it been fixed?
DVB-USB UMT-010 driver has certain oops when installed
01/09/2008
http://bugzilla.kernel.org/show_bug.cgi?id=9720
In the umt-010 driver the struct umt_properties sets the number of
URBs for transfer to 20.
But in dvb-usb.h MAX_NO_URBS_FOR_DATA_STREAM is set to 10. This causes
an oops for all devices which use the umt-010 chipset when they are
inserted.
v4l Problem with dvb-usb and Hauppage USB Stick
http://bugzilla.kernel.org/show_bug.cgi?id=9001
9/9/2007
x86_64
dvb-usb: Hauppauge Nova-T Stick crashes during channel search with Kaffeine
KEXEC=============================================================
kexec buffer error
http://bugzilla.kernel.org/show_bug.cgi?id=9693
01/05/2008
2.6.24-rc6-git9 works as expected. git10 fails with root device not found
DRIVERS===========================================================
Two small bugs detected by code review:
physmap does not have a release() function
01/05/2008
http://bugzilla.kernel.org/show_bug.cgi?id=9690
Summary: Pretty trivial addition of the release()
hgafb module is broken & unmaintained
http://bugzilla.kernel.org/show_bug.cgi?id=9689
This one also needs release() function
FILESYSTEMS======================================================
journal_data mount option causes filesystem corruption with blocksize != 4096
01/05/2008
http://bugzilla.kernel.org/show_bug.cgi?id=9692
Appears to be e2fsck problem
ALSA==============================================================
SC-5200 + wine = System freeze
http://bugzilla.kernel.org/show_bug.cgi?id=9649
12/27/2007
-- Motherboard: Asus A8R-MVP
-- Harddrive: Samsung 200Gb
-- Soundcard 1: Onboard
-- Soundcard 2: Trust SC-5200
Running any part of wine freezes up the whole system. Both SSH
connections, the normal X screen and any other device, including sound
played by for example music players, freezes up. After about 10
seconds the system reboots.
By removing my second sound card it works. By disabling my onboard
sound it still causes the freeze.
Networking=========================================================
An ioctl to delete an ipv6 tunnel leads to a kernel panic
http://bugzilla.kernel.org/show_bug.cgi?id=8895
8/16/2007
Summary: The mip6d HA was modified to make a redundancy evolution,
when an HA is interrupted, the other takes over, this leads to some
creation/deletion of routes and tunnels.
BUG: bad unlock balance detected!
http://bugzilla.kernel.org/show_bug.cgi?id=9542
Date: 12/11/2007
Summary:
...bug in the bonding driver...bond->lock should always turn BH off,
even on read lock.
Handled: Herbert Xu
Problem and solution has been identified, but the bug stalled -
probably needs someone to submit an actual patch
WIRELESS==========================================================
IWL3945 generates WARNING in mac80211/rx.c code
http://bugzilla.kernel.org/show_bug.cgi?id=9656
12/28/2007
WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx()
Pid: 0, comm: swapper Not tainted 2.6.24-rc6 #8
Call Trace:
<IRQ> [<ffffffff88123d89>] :mac80211:__ieee80211_rx+0xc69/0xd30
[<ffffffff812abd86>] _spin_lock_irqsave+0x26/0xa0
[<ffffffff812ac3a5>] _spin_unlock_irqrestore+0x15/0x30
[<ffffffff8815af91>] :iwl3945:iwl_rx_queue_restock+0xd1/0x160
[<ffffffff812abd86>] _spin_lock_irqsave+0x26/0xa0
[<ffffffff88114f7b>] :mac80211:ieee80211_tasklet_handler+0xbb/0x120
[<ffffffff810420a7>] tasklet_action+0x47/0xb0
[<ffffffff81041fb9>] __do_softirq+0x59/0xd0
[<ffffffff8100d5dc>] call_softirq+0x1c/0x30
[<ffffffff8100f975>] do_softirq+0x35/0x90
[<ffffffff81041ee5>] irq_exit+0x85/0x90
[<ffffffff8100fa54>] do_IRQ+0x84/0x100
[<ffffffff8100c931>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff811a312f>] acpi_idle_enter_bm+0x272/0x2de
[<ffffffff811a3125>] acpi_idle_enter_bm+0x268/0x2de
[<ffffffff81230357>] cpuidle_idle_call+0x97/0xd0
[<ffffffff812302c0>] cpuidle_idle_call+0x0/0xd0
[<ffffffff8100b001>] cpu_idle+0x71/0xe0
NFS/RPC===================================================
in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4 requests
http://bugzilla.kernel.org/show_bug.cgi?id=8891
8/15/2007
Problem Description: When locking a file, an invalid
RPCBPROC_GETVERSADDR procedure call is sent out
Chuck Lever looked at it a while ago
^ permalink raw reply
* Re: [PATCH] [IPV4]: Remove warning in node_set_parent.
From: Denis V. Lunev @ 2008-02-12 8:11 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev, devel
In-Reply-To: <20080211114849.042a3da2@extreme>
ugly :), but
Acked-by: Denis V. Lunev <den@openvz.org>
On Mon, 2008-02-11 at 11:48 -0800, Stephen Hemminger wrote:
> On Mon, 11 Feb 2008 11:47:17 +0300
> "Denis V. Lunev" <den@openvz.org> wrote:
>
> > net/ipv4/fib_trie.c: In function 'node_set_parent':
> > net/ipv4/fib_trie.c:184: warning: assignment makes integer from pointer
> > without a cast
> >
> > Signed-off-by: Denis V. Lunev <den@openvz.org>
> > ---
> > net/ipv4/fib_trie.c | 7 ++++---
> > 1 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> > index f5fba3f..1753cd4 100644
> > --- a/net/ipv4/fib_trie.c
> > +++ b/net/ipv4/fib_trie.c
> > @@ -177,10 +177,11 @@ static inline struct tnode *node_parent_rcu(struct node *node)
> > return rcu_dereference(ret);
> > }
> >
> > -static inline void node_set_parent(struct node *node, struct tnode *ptr)
> > +static inline void node_set_parent(struct node *node, struct tnode *__ptr)
> > {
> > - rcu_assign_pointer(node->parent,
> > - (unsigned long)ptr | NODE_TYPE(node));
> > + struct node *ptr;
> > + ptr = (struct node *)((unsigned long)__ptr | NODE_TYPE(node));
> > + rcu_assign_pointer(node->parent, ptr);
> > }
> >
> > static inline struct node *tnode_get_child(struct tnode *tn, unsigned int i)
>
> No, this causes new warning from assigning pointer (ptr) to integer node->parent.
>
> Why not just change rcupdate.h to do the right thing.
>
> >From a00f7cbf1c2f2282eced236e1e8b99b0fecd213a Mon Sep 17 00:00:00 2001
> From: Stephen Hemminger <stephen.hemminger@vyatta.com>
> Date: Mon, 11 Feb 2008 11:28:13 -0800
> Subject: [PATCH] eliminate warnings when rcu_assign_pointer is used with unsigned long
>
> It is reasonable to use RCU with non-pointer values, and describe
> the optimization.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> ---
> include/linux/rcupdate.h | 13 +++++++------
> 1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 37a642c..c44ac87 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -172,14 +172,15 @@ struct rcu_head {
> * structure after the pointer assignment. More importantly, this
> * call documents which pointers will be dereferenced by RCU read-side
> * code.
> + *
> + * If value is the NULL (constant 0), then no barrier is needed.
> */
>
> -#define rcu_assign_pointer(p, v) \
> - ({ \
> - if (!__builtin_constant_p(v) || \
> - ((v) != NULL)) \
> - smp_wmb(); \
> - (p) = (v); \
> +#define rcu_assign_pointer(p, v) \
> + ({ \
> + if (!(__builtin_constant_p(v) && v)) \
> + smp_wmb(); \
> + (p) = (v); \
> })
>
> /**
> --
> 1.5.3.8
>
>
>
>
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: Jarek Poplawski @ 2008-02-12 7:19 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <47B0DD1E.5000608@katalix.com>
On Mon, Feb 11, 2008 at 11:41:18PM +0000, James Chapman wrote:
> Jarek Poplawski wrote:
>> On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
>> ...
>>> Below is example output from lockdep. The oops is reproducible when
>>> creating/deleting lots of sessions while passing data. The lock is
>>> being acquired for read and write in softirq contexts.
>>>
>>> Is there a better way to fix this?
>>>
>>> =================================
>>> [ INFO: inconsistent lock state ]
>>> 2.6.24-core2 #1
>>> ---------------------------------
>>> inconsistent {in-softirq-R} -> {softirq-on-W} usage.
>>> openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
>>> (&tunnel->hlist_lock){---?}, at: [<f8eea157>]
>>> pppol2tp_connect+0x517/0x6d0 [pppol2tp]
>>> {in-softirq-R} state was registered at:
>>
>> IMHO, according to this, disabling bh should be enough. And if it's
>> like in this report: only read_lock is taken from softirqs, then this
>> should be necessary to change only all write_locks to write_lock_bh
>> (of course unless somewhere bhs are disabled already). Unless I miss
>> something?!
>
> I thought so too. I tried _bh locks first and the problem still
> occurred. Maybe I'll try it again in case I messed something up.
If there are any new lockdep warnings I'd be interested to have
a look. (BTW, with irqs disabling such ISP would probably get
considerable drop in performance?)
Regards,
Jarek P.
^ permalink raw reply
* Re: [git patches] net driver updates
From: David Miller @ 2008-02-12 5:57 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel
In-Reply-To: <20080211170516.GA13872@havoc.gtf.org>
From: Jeff Garzik <jeff@garzik.org>
Date: Mon, 11 Feb 2008 12:05:16 -0500
> Mostly fixes, a few cleanups (generally assisting fixes), and an
> exception for PS3 wireless because it had been posted, reviewed and
> acked for a while, just not committed.
>
> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-davem
>
> to receive the following updates:
Pulled, thanks a lot Jeff!
^ permalink raw reply
* Re: [PATCH][RFC] race in generic address resolution
From: David Miller @ 2008-02-12 5:47 UTC (permalink / raw)
To: blaschka; +Cc: netdev
In-Reply-To: <47B00EE0.4040109@linux.vnet.ibm.com>
From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Date: Mon, 11 Feb 2008 10:01:20 +0100
> we run your patch during the weekend on single CPU and SMP
> machines. We do not see any problems. Thanks for providing the fix.
Thanks for testing Frank, I can now push this fix upstream.
^ permalink raw reply
* Re: [patch 6/7] hci_ldisc: fix null pointer deref
From: David Miller @ 2008-02-12 5:42 UTC (permalink / raw)
To: marcel; +Cc: akpm, netdev, david, alan, arjan
In-Reply-To: <1202230268.15090.105.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Tue, 05 Feb 2008 17:51:07 +0100
> Hi David,
>
> > > akpm:
> > >
> > > No idea. trollmerge.
> > >
> > > Cc: Arjan van de Ven <arjan@linux.intel.com>
> > > Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > > Cc: Marcel Holtmann <marcel@holtmann.org>
> > > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> >
> > I'll let Marcel and/or Alan take a look at this one.
>
> we might have to re-work the whole hci_uart driver at some point, but
> for now I think this fix is feasible.
Ok, I've applied this patch.
^ permalink raw reply
* Re: [PATCH][AX25] ax25_ds_timer: use mod_timer instead of add_timer
From: David Miller @ 2008-02-12 5:38 UTC (permalink / raw)
To: jarkao2; +Cc: netdev, ralf, jann
In-Reply-To: <20080206091413.GE4496@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Wed, 6 Feb 2008 09:14:13 +0000
> [AX25] ax25_ds_timer: use mod_timer instead of add_timer
>
> This patch changes current use of: init_timer(), add_timer()
> and del_timer() to setup_timer() with mod_timer(), which
> should be safer anyway.
>
>
> Reported-by: Jann Traschewski <jann@gmx.de>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][AX25] Fwd: SMP with AX.25
From: David Miller @ 2008-02-12 5:37 UTC (permalink / raw)
To: jarkao2; +Cc: netdev, ralf, jann
In-Reply-To: <20080206081509.GD4496@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Wed, 6 Feb 2008 08:15:09 +0000
> On Wed, Feb 06, 2008 at 07:45:29AM +0000, Jarek Poplawski wrote:
> ...
> > From: Jann Traschewski <jann@gmx.de>
> > Subject: SMP with AX.25
>
>
> [AX25] ax25_timer: use mod_timer instead of add_timer
>
> According to one of Jann's OOPS reports it looks like
> BUG_ON(timer_pending(timer)) triggers during add_timer()
> in ax25_start_t1timer(). This patch changes current use
> of: init_timer(), add_timer() and del_timer() to
> setup_timer() with mod_timer(), which should be safer
> anyway.
>
>
> Reported-by: Jann Traschewski <jann@gmx.de>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH][PPPOL2TP]: Fix SMP oops in pppol2tp driver
From: David Miller @ 2008-02-12 5:30 UTC (permalink / raw)
To: jchapman; +Cc: jarkao2, netdev
In-Reply-To: <47B0DD1E.5000608@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Mon, 11 Feb 2008 23:41:18 +0000
> Jarek Poplawski wrote:
> > On Mon, Feb 11, 2008 at 10:19:35PM +0000, James Chapman wrote:
> > ...
> >> Below is example output from lockdep. The oops is reproducible when
> >> creating/deleting lots of sessions while passing data. The lock is being
> >> acquired for read and write in softirq contexts.
> >>
> >> Is there a better way to fix this?
> >>
> >> =================================
> >> [ INFO: inconsistent lock state ]
> >> 2.6.24-core2 #1
> >> ---------------------------------
> >> inconsistent {in-softirq-R} -> {softirq-on-W} usage.
> >> openl2tpd/3215 [HC0[0]:SC0[0]:HE1:SE1] takes:
> >> (&tunnel->hlist_lock){---?}, at: [<f8eea157>]
> >> pppol2tp_connect+0x517/0x6d0 [pppol2tp]
> >> {in-softirq-R} state was registered at:
> >
> > IMHO, according to this, disabling bh should be enough. And if it's
> > like in this report: only read_lock is taken from softirqs, then this
> > should be necessary to change only all write_locks to write_lock_bh
> > (of course unless somewhere bhs are disabled already). Unless I miss
> > something?!
>
> I thought so too. I tried _bh locks first and the problem still
> occurred. Maybe I'll try it again in case I messed something up.
I agree with Jarek here, I look at all the code paths that take
->hlist_lock and all of them are in user context or software
interrupts.
Please get a lockdep trace with the change to _bh intead of
hw interrupt protection so we can find out what that doesn't
work.
Thanks!
^ permalink raw reply
* Re: [PATCH][AX25] ax25_route: make ax25_route_lock BH safe
From: David Miller @ 2008-02-12 5:26 UTC (permalink / raw)
To: jarkao2; +Cc: jann, f6bvp, ralf, netdev
In-Reply-To: <20080211124251.GB3597@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Mon, 11 Feb 2008 12:42:51 +0000
> [AX25] ax25_route: make ax25_route_lock BH safe
>
> > =================================
> > [ INFO: inconsistent lock state ]
> > 2.6.24-dg8ngn-p02 #1
> > ---------------------------------
> > inconsistent {softirq-on-W} -> {in-softirq-R} usage.
> > linuxnet/3046 [HC0[0]:SC1[2]:HE1:SE0] takes:
> > (ax25_route_lock){--.+}, at: [<f8a0cfb7>] ax25_get_route+0x18/0xb7 [ax25]
> > {softirq-on-W} state was registered at:
> ...
>
> This lockdep report shows that ax25_route_lock is taken for reading in
> softirq context, and for writing in process context with BHs enabled.
> So, to make this safe, all write_locks in ax25_route.c are changed to
> _bh versions.
>
>
> Reported-by: Jann Traschewski <jann@gmx.de>,
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied, thanks a lot Jarek.
^ permalink raw reply
* Re: [PATCH v2][AX25] af_ax25: remove sock lock in ax25_info_show()
From: David Miller @ 2008-02-12 5:25 UTC (permalink / raw)
To: jarkao2; +Cc: f6bvp, ralf, jann, netdev
In-Reply-To: <20080210131051.GA7750@ami.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Sun, 10 Feb 2008 14:10:51 +0100
> [AX25] af_ax25: remove sock lock in ax25_info_show()
>
> This lockdep warning:
>
> > =======================================================
> > [ INFO: possible circular locking dependency detected ]
> > 2.6.24 #3
> > -------------------------------------------------------
> > swapper/0 is trying to acquire lock:
> > (ax25_list_lock){-+..}, at: [<f91dd3b1>] ax25_destroy_socket+0x171/0x1f0 [ax25]
> >
> > but task is already holding lock:
> > (slock-AF_AX25){-+..}, at: [<f91dbabc>] ax25_std_heartbeat_expiry+0x1c/0xe0 [ax25]
> >
> > which lock already depends on the new lock.
> ...
>
> shows that ax25_list_lock and slock-AF_AX25 are taken in different
> order: ax25_info_show() takes slock (bh_lock_sock(ax25->sk)) while
> ax25_list_lock is held, so reversely to other functions. To fix this
> the sock lock should be moved to ax25_info_start(), and there would
> be still problem with breaking ax25_list_lock (it seems this "proper"
> order isn't optimal yet). But, since it's only for reading proc info
> it seems this is not necessary (e.g. ax25_send_to_raw() does similar
> reading without this lock too).
>
> So, this patch removes sock lock to avoid deadlock possibility; there
> is also used sock_i_ino() function, which reads sk_socket under proper
> read lock. Additionally printf format of this i_ino is changed to %lu.
>
> Reported-by: Bernard Pidoux F6BVP <f6bvp@free.fr>
> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Applied, thanks Jarek.
> + sock_i_ino(ax25->sk));
Note that this taks the sk callback lock, it should be OK but
let's keep a watch out for any new lockdep warnings this
ends up causing :-)
^ 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