* [PATCH 2/2]: e1000 disable device on PCI error
From: Linas Vepstas @ 2006-06-29 20:11 UTC (permalink / raw)
To: Jesse Brandeburg, Rajesh Shah, Ronciak, John, Grant Grundler,
bibo,mao
Cc: linux-kernel, linux-pci, netdev, akpm
In-Reply-To: <20060629200644.GA29526@austin.ibm.com>
Same as last patch, but for the e1000 gigabit card.
A recent patch in -mm3 titled
"gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch"
causes pci_enable_device() to be a no-op if the kernel thinks
that the device is already enabled. This change breaks the
PCI error recovery mechanism in the e1000 device driver, since,
after PCI slot reset, the card is no longer enabled. This is
a trivial fix for this problem. Tested.
Please submit uptream.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/e1000/e1000_main.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.17-mm3/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.17-mm3.orig/drivers/net/e1000/e1000_main.c 2006-06-27 12:30:02.000000000 -0500
+++ linux-2.6.17-mm3/drivers/net/e1000/e1000_main.c 2006-06-29 14:52:29.000000000 -0500
@@ -4640,6 +4640,7 @@ static pci_ers_result_t e1000_io_error_d
if (netif_running(netdev))
e1000_down(adapter);
+ pci_disable_device(pdev);
/* Request a slot slot reset. */
return PCI_ERS_RESULT_NEED_RESET;
^ permalink raw reply
* Re: RDMA will be reverted
From: Tom Tucker @ 2006-06-29 20:11 UTC (permalink / raw)
To: David Miller; +Cc: rdreier, netdev, akpm
In-Reply-To: <20060629.124628.88476747.davem@davemloft.net>
On Thu, 2006-06-29 at 12:46 -0700, David Miller wrote:
> From: Roland Dreier <rdreier@cisco.com>
> Date: Thu, 29 Jun 2006 09:54:37 -0700
>
> > In any case I think we need to find a way for Linux to support iWARP
> > hardware, since there are users that want this, and (some of) the
> > vendors are working hard to do things the right way (including cc'ing
> > netdev on the conversation). I don't think it's good for Linux for
> > the answer to just be, "sorry, you're wrong to want to use that hardware."
>
> We give the same response for TOE stuff.
What does the word "we" represent in this context? Is it the Linux
community at large, Linux and Andrew, you? I'm not trying to be
argumentative, I just want to understand how carefully and by whom iWARP
technology has been considered.
>
> The integration of iWARP with the Linux networking, while much better
> than TOE, is still heavily flawed.
>
> What most people might not realize when using this stuff is that:
Agreed, the patch improves some things, but doesn't address others. But
isn't this position a condemnation of the good to spite the bad?
>
> 1) None of their firewall rules will apply to the iWARP communications.
> 2) None of their packet scheduling configurations can be applied to
> the iWARP communications.
> 3) It is not possible to encapsulate iWARP traffic in IPSEC
>
> And the list goes on and on.
It does, however, this position statement makes things worse, not
better. By this I mean that deep adapters (iSCSI, iWARP) are even more
debilitated by not being able to snoop MTU changes, etc... and are
therefore forced to duplicate sub-systems (e.g. ARP, ICMP, ...) already
ably implemented in host software.
> This is what we don't like about technologies that implement their own
> networking stack in the card firmware.
Doesn't this position force vendors to build deeper adapters, not
shallower adapters? Isn't this exactly the opposite of what is intended?
>
> -
> 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
* Subject: [PATCH 1/2]: e100 disable device on PCI error
From: Linas Vepstas @ 2006-06-29 20:06 UTC (permalink / raw)
To: Jesse Brandeburg, Rajesh Shah, Ronciak, John, Grant Grundler,
bibo,mao
Cc: linux-kernel, linux-pci, netdev, akpm
A recent patch in -mm3 titled
"gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch"
causes pci_enable_device() to be a no-op if the kernel thinks
that the device is already enabled. This change breaks the
PCI error recovery mechanism in the e100 device driver, since,
after PCI slot reset, the card is no longer enabled. This is
a trivial fix for this problem. Tested.
Please submit uptream.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
drivers/net/e100.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.17-mm3/drivers/net/e100.c
===================================================================
--- linux-2.6.17-mm3.orig/drivers/net/e100.c 2006-06-27 11:39:08.000000000 -0500
+++ linux-2.6.17-mm3/drivers/net/e100.c 2006-06-29 14:18:40.000000000 -0500
@@ -2742,6 +2742,7 @@ static pci_ers_result_t e100_io_error_de
/* Detach; put netif into state similar to hotplug unplug. */
netif_poll_enable(netdev);
netif_device_detach(netdev);
+ pci_disable_device(pdev);
/* Request a slot reset. */
return PCI_ERS_RESULT_NEED_RESET;
^ permalink raw reply
* Re: [Ubuntu PATCH] Broadcom wireless patch, PCIE/Mactel support
From: Michael Buesch @ 2006-06-29 20:04 UTC (permalink / raw)
To: John W. Linville; +Cc: Stefano Brivio, Randy Dunlap, lkml, netdev, mb, akpm
In-Reply-To: <20060629195456.GG24463@tuxdriver.com>
On Thursday 29 June 2006 21:55, John W. Linville wrote:
> On Thu, Jun 15, 2006 at 01:32:20PM +0200, Stefano Brivio wrote:
> > On Wed, 14 Jun 2006 16:22:39 -0700
> > Randy Dunlap <randy.dunlap@oracle.com> wrote:
> >
> > > From: Matthew Garrett <mjg59@srcf.ucam.org>
> > >
> > > Broadcom wireless patch, PCIE/Mactel support
> > >
> > > http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
> > >
> > > This patch adds support for PCIE cores to the bcm43xx driver. This is
> > > needed for wireless to work on the Intel imacs. I've submitted it to
> > > bcm43xx upstream.
> >
> > NACK.
> > This has been superseded by my patchset:
> > http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg01267.html
> >
> > I'm still waiting for more testing so I didn't request merging to mainline
>
> Are these patches coming soon?
No, we don't have hardware to test it.
So if someone knows a PCIe Broadcom WLAN card... ;)
--
Greetings Michael.
^ permalink raw reply
* Re: [2.6 patch] net/xfrm/xfrm_state: unexport xfrm_state_mtu
From: David Miller @ 2006-06-29 20:04 UTC (permalink / raw)
To: bunk; +Cc: netdev
In-Reply-To: <20060629192035.GT19712@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Thu, 29 Jun 2006 21:20:35 +0200
> This patch removes the unused EXPORT_SYMBOL(xfrm_state_mtu).
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Applied, thanks.
^ permalink raw reply
* Re: PATCH SB1250 NAPI support
From: Francois Romieu @ 2006-06-29 20:01 UTC (permalink / raw)
To: Tom Rix; +Cc: tbm, jgarzik, netdev, linux-mips, mark.e.mason
In-Reply-To: <op.tamrhvwlthfl8t@localhost.localdomain>
Tom Rix <trix@specifix.com> :
[...]
diff -rup a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
--- a/drivers/net/sb1250-mac.c 2006-03-09 04:25:41.000000000 -0600
+++ b/drivers/net/sb1250-mac.c 2006-03-09 05:30:52.000000000 -0600
[...]
@@ -2079,13 +2095,31 @@ static irqreturn_t sbmac_intr(int irq,vo
* Transmits on channel 0
*/
+#if defined(CONFIG_SBMAC_NAPI)
if (isr & (M_MAC_INT_CHANNEL << S_MAC_TX_CH0)) {
- sbdma_tx_process(sc,&(sc->sbm_txdma));
+ sbdma_tx_process(sc,&(sc->sbm_txdma), 0);
}
/*
* Receives on channel 0
*/
+ if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
+ if (netif_rx_schedule_prep(dev))
+ {
An irq could appear here. I am skeptical that it is safe to write
the irq mask register so late.
One should probably consider a break in the enclosing "for" loop too.
+ __raw_writeq(0, sc->sbm_imr);
+ __netif_rx_schedule(dev);
+ }
+ else
+ {
} else {, please.
--
Ueimor
^ permalink raw reply
* Re: [2.6 patch] make net/core/skbuff.c:skb_release_data() static
From: David Miller @ 2006-06-29 20:03 UTC (permalink / raw)
To: bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20060629192020.GR19712@stusta.de>
From: Adrian Bunk <bunk@stusta.de>
Date: Thu, 29 Jun 2006 21:20:20 +0200
> On Fri, Jun 23, 2006 at 04:01:15AM -0700, David Miller wrote:
> > From: Adrian Bunk <bunk@stusta.de>
> > Date: Fri, 23 Jun 2006 12:56:23 +0200
> >
> > > skb_release_data() no longer has any users in other files.
> > >
> > > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> > If you are going to do this, you need to remove the reference
> > in arch/x86_64/kernel/functionlist too.
> >
> > Thanks.
>
> Corrected patch below.
Applied, thanks.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Andrew Morton @ 2006-06-29 20:00 UTC (permalink / raw)
To: Shailabh Nagar
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <44A42D6D.6060108@watson.ibm.com>
On Thu, 29 Jun 2006 15:43:41 -0400
Shailabh Nagar <nagar@watson.ibm.com> wrote:
> >Could be so. But we need to understand how significant the impact of this
> >will be in practice.
> >
> >We could find, once this is deployed is real production environments on
> >large machines that the data loss is sufficiently common and sufficiently
> >serious that the feature needs a lot of rework.
> >
> >Now there's always a risk of that sort of thing happening with all
> >features, but it's usually not this evident so early in the development
> >process. We need to get a better understanding of the risk before
> >proceeding too far.
> >
> >
>
> >And there's always a 100% reliable fix for this: throttling. Make the
> >sender of the messages block until the consumer can catch up.
> >
> Is blocking exits an option ?
I think it has to be an option. I'm sure that some peope under some
circumstances will just want to collect all the data, thank you very much.
And I doubt if it'll be a performance problem for them - the amount of CPU
time per exit will be small - if you're exitting at great frequency then the
stats collecion overhead rises proportionately. That is to be expected.
There will be buffering in the channel, so we'd expect to gather thousands
of records per context switch.
> > In some
> >situations, that is what people will want to be able to do. I suspect a
> >good implementation would be to run a collection daemon on each CPU and
> >make the delivery be cpu-local. That's sounding more like relayfs than
> >netlink.
> >
> >
> Yup...the per-cpu, high speed requirements are up relayfs' alley, unless
> Jamal or netlink folks
> are planning something (or can shed light on) how large flows can be
> managed over netlink. I suspect
> this discussion has happened before :-)
yeah.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-29 20:01 UTC (permalink / raw)
To: Andrew Morton
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <20060629123338.0d355297.akpm@osdl.org>
Andrew Morton wrote:
>On Thu, 29 Jun 2006 15:10:31 -0400
>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
>
>
>>>I agree, and I'm viewing this as blocking the taskstats merge. Because if
>>>this _is_ a problem then it's a big one because fixing it will be
>>>intrusive, and might well involve userspace-visible changes.
>>>
>>>
>>>
>>>
>>First off, just a reminder that this is inherently a netlink flow
>>control issue...which was being exacerbated
>>earlier by taskstats decision to send per-tgid data (no longer the case).
>>
>>But I'd like to know whats our target here ? How many messages per
>>second do we want to be able to be sent
>>and received without risking any loss of data ? Netlink will lose
>>messages at a high enough rate so the design point
>>will need to be known a bit.
>>
>>For statistics type usage of the genetlink/netlink, I would have thought
>>that userspace, provided it is reliably informed
>>about the loss of data through ENOBUFS, could take measures to just
>>account for the missing data and carry on ?
>>
>>
>
>Could be so. But we need to understand how significant the impact of this
>will be in practice.
>
>We could find, once this is deployed is real production environments on
>large machines that the data loss is sufficiently common and sufficiently
>serious that the feature needs a lot of rework.
>
>Now there's always a risk of that sort of thing happening with all
>features, but it's usually not this evident so early in the development
>process. We need to get a better understanding of the risk before
>proceeding too far.
>
>
Ok.
I suppose we should first determine what number of tasks can be
forked/exited at a sustained rate
on these m/c's and that would be one upper bound.
Paul, Chris, Jay,
What total exit rate would be a good upper bound ? How much memory do
these 1024 CPU machines
have (in high end configurations, not just based on 64-bit
addressability) and how many tasks can actually be
forked/exited in such a machine ?
>And there's always a 100% reliable fix for this: throttling. Make the
>sender of the messages block until the consumer can catch up. In some
>situations, that is what people will want to be able to do.
>
Is this really an option for taskstats ? Allowing exits to get throttled
? I suppose its one way
but seems like overkill for something like stats.
>I suspect a
>good implementation would be to run a collection daemon on each CPU and
>make the delivery be cpu-local. That's sounding more like relayfs than
>netlink.
>
>
Yup...per-cpu, high speed delivery is looking like relayfs alright.
One option that we've not explored in detail is the "dump" functionality
of genetlink which allows
kernel space to keep getting called with skb's to fill until its done.
How much buffering that affords us
in the face of a slow user is not known. But if we're discussing large
exit rates happening in a burst, not
a sustained way, that may be one way out.
Jamal,
any thoughts on the flow control capabilities of netlink that apply here
? Usage of the connection is to
supply statistics data to userspace.
--Shailabh
^ permalink raw reply
* Re: 2.6.17-mm3 -- BUG: illegal lock usage -- illegal {softirq-on-W} -> {in-softirq-R} usage.
From: Andrew Morton @ 2006-06-29 19:56 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: miles.lane, linux-kernel, netdev
In-Reply-To: <1151610155.3122.65.camel@laptopd505.fenrus.org>
On Thu, 29 Jun 2006 21:42:34 +0200
Arjan van de Ven <arjan@infradead.org> wrote:
> On Thu, 2006-06-29 at 12:26 -0700, Andrew Morton wrote:
> > On Thu, 29 Jun 2006 12:01:06 -0700
> > "Miles Lane" <miles.lane@gmail.com> wrote:
> >
> > > [ BUG: illegal lock usage! ]
> > > ----------------------------
> >
> > This is claiming that we're taking sk->sk_dst_lock in a deadlockable manner.
> >
> > > illegal {softirq-on-W} -> {in-softirq-R} usage.
> >
> > It found someone doing write_lock(sk_dst_lock) with softirqs enabled, but
> > someone else takes read_lock(dst_lock) inside softirqs.
> >
> > > java_vm/4418 [HC0[0]:SC1[1]:HE1:SE0] takes:
> > > (&sk->sk_dst_lock){---?}, at: [<c119d0a9>] sk_dst_check+0x1b/0xe6
> > > {softirq-on-W} state was registered at:
> > > [<c102d1c8>] lock_acquire+0x60/0x80
> > > [<c12012d7>] _write_lock+0x23/0x32
> > > [<c11ddbe7>] inet_bind+0x16c/0x1cc
> > > [<c119ae58>] sys_bind+0x61/0x80
> > > [<c119b465>] sys_socketcall+0x7d/0x186
> > > [<c1002d6d>] sysenter_past_esp+0x56/0x8d
> >
> > inet_bind()
> > ->sk_dst_get
> > ->read_lock(&sk->sk_dst_lock)
>
> actually write_lock() not read_lock()
>
static inline struct dst_entry *
sk_dst_get(struct sock *sk)
{
struct dst_entry *dst;
read_lock(&sk->sk_dst_lock);
> >
> > > irq event stamp: 11052
> > > hardirqs last enabled at (11052): [<c105d454>] kmem_cache_alloc+0x89/0xa6
> > > hardirqs last disabled at (11051): [<c105d405>] kmem_cache_alloc+0x3a/0xa6
> > > softirqs last enabled at (11040): [<c11a506d>] dev_queue_xmit+0x224/0x24b
> > > softirqs last disabled at (11041): [<c1004a64>] do_softirq+0x58/0xbd
> > >
> > > other info that might help us debug this:
> > > 1 lock held by java_vm/4418:
> > > #0: (af_family_keys + (sk)->sk_family#4){-+..}, at: [<f93c9281>]
> > > tcp_v6_rcv+0x308/0x7b7 [ipv6]
> >
> > softirq
> > ->ip6_dst_lookup
> > ->sk_dst_check
> > ->sk_dst_reset
> > ->write_lock(&sk->sk_dst_lock);
>
> write_lock.. or read_lock() ?
static inline void
sk_dst_reset(struct sock *sk)
{
write_lock(&sk->sk_dst_lock);
> >
> > > stack backtrace:
> > > [<c1003502>] show_trace_log_lvl+0x54/0xfd
> > > [<c1003b6a>] show_trace+0xd/0x10
> > > [<c1003c0e>] dump_stack+0x19/0x1b
> > > [<c102b833>] print_usage_bug+0x1cc/0x1d9
> > > [<c102bd34>] mark_lock+0x193/0x360
> > > [<c102c94a>] __lock_acquire+0x3b7/0x970
> > > [<c102d1c8>] lock_acquire+0x60/0x80
> > > [<c12013eb>] _read_lock+0x23/0x32
>
> backtrace says read lock to me ...
> > > [<c119d0a9>] sk_dst_check+0x1b/0xe6
> > > [<f93ae479>] ip6_dst_lookup+0x31/0x172 [ipv6]
> > > [<f93c7065>] tcp_v6_send_synack+0x10f/0x238 [ipv6]
> > > [<f93c7dc5>] tcp_v6_conn_request+0x281/0x2c7 [ipv6]
> > > [<c11cca33>] tcp_rcv_state_process+0x5d/0xbde
>
>
> > So the allegation is that if a softirq runs sk_dst_reset() while
> > process-context code is running sk_dst_set(), we'll do write_lock() while
> > holding read_lock().
>
> hmm or...
>
> we're doing a write_lock(), then an interrupt can happen that triggers
> the softirq that triggers the read_lock(), which will deadlock because
> we interrupted the writer...
>
either way ain't good ;)
^ permalink raw reply
* Re: [Ubuntu PATCH] Broadcom wireless patch, PCIE/Mactel support
From: John W. Linville @ 2006-06-29 19:55 UTC (permalink / raw)
To: Stefano Brivio; +Cc: Randy Dunlap, lkml, netdev, mb, akpm
In-Reply-To: <20060615133220.57d8dd26@localhost>
On Thu, Jun 15, 2006 at 01:32:20PM +0200, Stefano Brivio wrote:
> On Wed, 14 Jun 2006 16:22:39 -0700
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> > From: Matthew Garrett <mjg59@srcf.ucam.org>
> >
> > Broadcom wireless patch, PCIE/Mactel support
> >
> > http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
> >
> > This patch adds support for PCIE cores to the bcm43xx driver. This is
> > needed for wireless to work on the Intel imacs. I've submitted it to
> > bcm43xx upstream.
>
> NACK.
> This has been superseded by my patchset:
> http://www.mail-archive.com/bcm43xx-dev@lists.berlios.de/msg01267.html
>
> I'm still waiting for more testing so I didn't request merging to mainline
Are these patches coming soon?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: RDMA will be reverted
From: David Miller @ 2006-06-29 19:46 UTC (permalink / raw)
To: rdreier; +Cc: netdev, akpm
In-Reply-To: <adawtazgawi.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Thu, 29 Jun 2006 09:54:37 -0700
> In any case I think we need to find a way for Linux to support iWARP
> hardware, since there are users that want this, and (some of) the
> vendors are working hard to do things the right way (including cc'ing
> netdev on the conversation). I don't think it's good for Linux for
> the answer to just be, "sorry, you're wrong to want to use that hardware."
We give the same response for TOE stuff.
The integration of iWARP with the Linux networking, while much better
than TOE, is still heavily flawed.
What most people might not realize when using this stuff is that:
1) None of their firewall rules will apply to the iWARP communications.
2) None of their packet scheduling configurations can be applied to
the iWARP communications.
3) It is not possible to encapsulate iWARP traffic in IPSEC
And the list goes on and on.
This is what we don't like about technologies that implement their own
networking stack in the card firmware.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Shailabh Nagar @ 2006-06-29 19:43 UTC (permalink / raw)
To: Andrew Morton
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <20060629123338.0d355297.akpm@osdl.org>
Andrew Morton wrote:
>On Thu, 29 Jun 2006 15:10:31 -0400
>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>
>
>
>>>I agree, and I'm viewing this as blocking the taskstats merge. Because if
>>>this _is_ a problem then it's a big one because fixing it will be
>>>intrusive, and might well involve userspace-visible changes.
>>>
>>>
>>>
>>>
>>First off, just a reminder that this is inherently a netlink flow
>>control issue...which was being exacerbated
>>earlier by taskstats decision to send per-tgid data (no longer the case).
>>
>>But I'd like to know whats our target here ? How many messages per
>>second do we want to be able to be sent
>>and received without risking any loss of data ? Netlink will lose
>>messages at a high enough rate so the design point
>>will need to be known a bit.
>>
>>For statistics type usage of the genetlink/netlink, I would have thought
>>that userspace, provided it is reliably informed
>>about the loss of data through ENOBUFS, could take measures to just
>>account for the missing data and carry on ?
>>
>>
>
>Could be so. But we need to understand how significant the impact of this
>will be in practice.
>
>We could find, once this is deployed is real production environments on
>large machines that the data loss is sufficiently common and sufficiently
>serious that the feature needs a lot of rework.
>
>Now there's always a risk of that sort of thing happening with all
>features, but it's usually not this evident so early in the development
>process. We need to get a better understanding of the risk before
>proceeding too far.
>
>
>And there's always a 100% reliable fix for this: throttling. Make the
>sender of the messages block until the consumer can catch up.
>
Is blocking exits an option ?
> In some
>situations, that is what people will want to be able to do. I suspect a
>good implementation would be to run a collection daemon on each CPU and
>make the delivery be cpu-local. That's sounding more like relayfs than
>netlink.
>
>
Yup...the per-cpu, high speed requirements are up relayfs' alley, unless
Jamal or netlink folks
are planning something (or can shed light on) how large flows can be
managed over netlink. I suspect
this discussion has happened before :-)
^ permalink raw reply
* Re: 2.6.17-mm3 -- BUG: illegal lock usage -- illegal {softirq-on-W} -> {in-softirq-R} usage.
From: Arjan van de Ven @ 2006-06-29 19:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Miles Lane, linux-kernel, netdev
In-Reply-To: <20060629122608.440d474c.akpm@osdl.org>
On Thu, 2006-06-29 at 12:26 -0700, Andrew Morton wrote:
> On Thu, 29 Jun 2006 12:01:06 -0700
> "Miles Lane" <miles.lane@gmail.com> wrote:
>
> > [ BUG: illegal lock usage! ]
> > ----------------------------
>
> This is claiming that we're taking sk->sk_dst_lock in a deadlockable manner.
>
> > illegal {softirq-on-W} -> {in-softirq-R} usage.
>
> It found someone doing write_lock(sk_dst_lock) with softirqs enabled, but
> someone else takes read_lock(dst_lock) inside softirqs.
>
> > java_vm/4418 [HC0[0]:SC1[1]:HE1:SE0] takes:
> > (&sk->sk_dst_lock){---?}, at: [<c119d0a9>] sk_dst_check+0x1b/0xe6
> > {softirq-on-W} state was registered at:
> > [<c102d1c8>] lock_acquire+0x60/0x80
> > [<c12012d7>] _write_lock+0x23/0x32
> > [<c11ddbe7>] inet_bind+0x16c/0x1cc
> > [<c119ae58>] sys_bind+0x61/0x80
> > [<c119b465>] sys_socketcall+0x7d/0x186
> > [<c1002d6d>] sysenter_past_esp+0x56/0x8d
>
> inet_bind()
> ->sk_dst_get
> ->read_lock(&sk->sk_dst_lock)
actually write_lock() not read_lock()
>
> > irq event stamp: 11052
> > hardirqs last enabled at (11052): [<c105d454>] kmem_cache_alloc+0x89/0xa6
> > hardirqs last disabled at (11051): [<c105d405>] kmem_cache_alloc+0x3a/0xa6
> > softirqs last enabled at (11040): [<c11a506d>] dev_queue_xmit+0x224/0x24b
> > softirqs last disabled at (11041): [<c1004a64>] do_softirq+0x58/0xbd
> >
> > other info that might help us debug this:
> > 1 lock held by java_vm/4418:
> > #0: (af_family_keys + (sk)->sk_family#4){-+..}, at: [<f93c9281>]
> > tcp_v6_rcv+0x308/0x7b7 [ipv6]
>
> softirq
> ->ip6_dst_lookup
> ->sk_dst_check
> ->sk_dst_reset
> ->write_lock(&sk->sk_dst_lock);
write_lock.. or read_lock() ?
>
> > stack backtrace:
> > [<c1003502>] show_trace_log_lvl+0x54/0xfd
> > [<c1003b6a>] show_trace+0xd/0x10
> > [<c1003c0e>] dump_stack+0x19/0x1b
> > [<c102b833>] print_usage_bug+0x1cc/0x1d9
> > [<c102bd34>] mark_lock+0x193/0x360
> > [<c102c94a>] __lock_acquire+0x3b7/0x970
> > [<c102d1c8>] lock_acquire+0x60/0x80
> > [<c12013eb>] _read_lock+0x23/0x32
backtrace says read lock to me ...
> > [<c119d0a9>] sk_dst_check+0x1b/0xe6
> > [<f93ae479>] ip6_dst_lookup+0x31/0x172 [ipv6]
> > [<f93c7065>] tcp_v6_send_synack+0x10f/0x238 [ipv6]
> > [<f93c7dc5>] tcp_v6_conn_request+0x281/0x2c7 [ipv6]
> > [<c11cca33>] tcp_rcv_state_process+0x5d/0xbde
> So the allegation is that if a softirq runs sk_dst_reset() while
> process-context code is running sk_dst_set(), we'll do write_lock() while
> holding read_lock().
hmm or...
we're doing a write_lock(), then an interrupt can happen that triggers
the softirq that triggers the read_lock(), which will deadlock because
we interrupted the writer...
^ permalink raw reply
* Re: [PATCH 1/3] [TIPC] Fixed skb_under_panic caused by tipc_link_bundle_buf
From: David Miller @ 2006-06-29 19:41 UTC (permalink / raw)
To: per.liden; +Cc: netdev, allan.stephens
In-Reply-To: <Pine.LNX.4.64.0606291703270.1695@ulinpc219.uab.ericsson.se>
From: Per Liden <per.liden@ericsson.com>
Date: Thu, 29 Jun 2006 17:17:20 +0200 (CEST)
> A problem was found with this patch. The direct inspection of bundle
> buffer tailroom did not account for the possiblity of unrequested tailroom
> added by skb_alloc(), thereby allowing a bundle to be created that exceeds
> the current link MTU.
>
> I'll resend this patch set with this issue resolved.
I've applied the patch already, please send a relative fix.
Thanks.
^ permalink raw reply
* Re: [PATCH] [IrDA] MCS7780 usb_driver struct should be static
From: David Miller @ 2006-06-29 19:39 UTC (permalink / raw)
To: samuel-jcdQHdrhKHMdnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, bunk-HeJ8Db2Gnd6zQB+pC5nmwQ,
irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20060629051236.GA31100-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
From: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Date: Thu, 29 Jun 2006 08:12:36 +0300
> Hi Dave,
>
> This patch makes a needlessly global struct static.
>
> Signed-off-by: Adrian Bunk <bunk-HeJ8Db2Gnd6zQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Applied, thanks a lot.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: [PATCH 2/2] bnx2: Turn off link during shutdown
From: David Miller @ 2006-06-29 19:38 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1151517560.3502.20.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 28 Jun 2006 10:59:20 -0700
> Minor change in shutdown logic to effect a link down.
>
> Update version to 1.4.43.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Also applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 1/2] bnx2: Use dev_kfree_skb() instead of the _irq version
From: David Miller @ 2006-06-29 19:37 UTC (permalink / raw)
To: mchan; +Cc: netdev
In-Reply-To: <1151517555.3502.19.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Wed, 28 Jun 2006 10:59:14 -0700
> Change all dev_kfree_skb_irq() and dev_kfree_skb_any() to
> dev_kfree_skb(). These calls are never used in irq context.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 4/4][ATM]: basic sysfs support for ATM devices
From: David Miller @ 2006-06-29 19:37 UTC (permalink / raw)
To: chas; +Cc: netdev
In-Reply-To: <200606281345.k5SDjgh9008958@relax.cmf.nrl.navy.mil>
From: "chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil>
Date: Wed, 28 Jun 2006 09:45:42 -0400
> please consider for 2.6.18 -- thanks!
>
> [ATM]: basic sysfs support for ATM devices
>
> From: Roman Kagan <rkagan@mail.ru>
> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Also applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 3/4][ATM]: [suni] change suni_init to __devinit
From: David Miller @ 2006-06-29 19:36 UTC (permalink / raw)
To: chas; +Cc: netdev
In-Reply-To: <200606281345.k5SDj4Ob008943@relax.cmf.nrl.navy.mil>
From: "chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil>
Date: Wed, 28 Jun 2006 09:45:04 -0400
> please consider for 2.6.18 -- thanks!
>
> [ATM]: [suni] change suni_init to __devinit
>
> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4][ATM]: [iphase] should be __devinit not __init
From: David Miller @ 2006-06-29 19:36 UTC (permalink / raw)
To: chas; +Cc: netdev
In-Reply-To: <200606281344.k5SDij70008930@relax.cmf.nrl.navy.mil>
From: "chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil>
Date: Wed, 28 Jun 2006 09:44:45 -0400
> please consider for 2.6.18 -- thanks!
>
> [ATM]: [iphase] should be __devinit not __init
>
> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Applied.
^ permalink raw reply
* Re: [PATCH 1/4][ATM]: [idt77105] should be __devinit not __init
From: David Miller @ 2006-06-29 19:36 UTC (permalink / raw)
To: chas; +Cc: netdev
In-Reply-To: <200606281344.k5SDiR0D008917@relax.cmf.nrl.navy.mil>
From: "chas williams - CONTRACTOR" <chas@cmf.nrl.navy.mil>
Date: Wed, 28 Jun 2006 09:44:27 -0400
> please consider for 2.6.18 -- thanks!
>
> [ATM]: [idt77105] should be __devinit not __init
>
> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] [TIPC] Initial activation message now includes TIPC version number
From: David Miller @ 2006-06-29 19:34 UTC (permalink / raw)
To: per.liden; +Cc: netdev, allan.stephens
In-Reply-To: <1151496472474-git-send-email-per.liden@ericsson.com>
From: Per Liden <per.liden@ericsson.com>
Date: Wed, 28 Jun 2006 14:07:52 +0200
> From: Allan Stephens <allan.stephens@windriver.com>
>
> Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
> Signed-off-by: Per Liden <per.liden@ericsson.com>
Also applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 2/3] [TIPC] Improve response to requests for node/link information
From: David Miller @ 2006-06-29 19:34 UTC (permalink / raw)
To: per.liden; +Cc: netdev, allan.stephens
In-Reply-To: <11514964721454-git-send-email-per.liden@ericsson.com>
From: Per Liden <per.liden@ericsson.com>
Date: Wed, 28 Jun 2006 14:07:51 +0200
> From: Allan Stephens <allan.stephens@windriver.com>
>
> Now allocates reply space for "get links" request based on number of actual
> links, not number of potential links. Also, limits reply to "get links" and
> "get nodes" requests to 32KB to match capabilities of tipc-config utility
> that issued request.
>
> Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
> Signed-off-by: Per Liden <per.liden@ericsson.com>
Applied, thanks.
^ permalink raw reply
* Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
From: Andrew Morton @ 2006-06-29 19:33 UTC (permalink / raw)
To: Shailabh Nagar
Cc: pj, Valdis.Kletnieks, jlan, balbir, csturtiv, linux-kernel, hadi,
netdev
In-Reply-To: <44A425A7.2060900@watson.ibm.com>
On Thu, 29 Jun 2006 15:10:31 -0400
Shailabh Nagar <nagar@watson.ibm.com> wrote:
> >I agree, and I'm viewing this as blocking the taskstats merge. Because if
> >this _is_ a problem then it's a big one because fixing it will be
> >intrusive, and might well involve userspace-visible changes.
> >
> >
> First off, just a reminder that this is inherently a netlink flow
> control issue...which was being exacerbated
> earlier by taskstats decision to send per-tgid data (no longer the case).
>
> But I'd like to know whats our target here ? How many messages per
> second do we want to be able to be sent
> and received without risking any loss of data ? Netlink will lose
> messages at a high enough rate so the design point
> will need to be known a bit.
>
> For statistics type usage of the genetlink/netlink, I would have thought
> that userspace, provided it is reliably informed
> about the loss of data through ENOBUFS, could take measures to just
> account for the missing data and carry on ?
Could be so. But we need to understand how significant the impact of this
will be in practice.
We could find, once this is deployed is real production environments on
large machines that the data loss is sufficiently common and sufficiently
serious that the feature needs a lot of rework.
Now there's always a risk of that sort of thing happening with all
features, but it's usually not this evident so early in the development
process. We need to get a better understanding of the risk before
proceeding too far.
And there's always a 100% reliable fix for this: throttling. Make the
sender of the messages block until the consumer can catch up. In some
situations, that is what people will want to be able to do. I suspect a
good implementation would be to run a collection daemon on each CPU and
make the delivery be cpu-local. That's sounding more like relayfs than
netlink.
^ 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