* Re: linux-next: manual merge of the net tree with the wireless tree
From: John W. Linville @ 2010-10-06 13:27 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Dan Carpenter,
Joe Perches
In-Reply-To: <20101006120908.ffe99876.sfr@canb.auug.org.au>
On Wed, Oct 06, 2010 at 12:09:08PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/wireless/ipw2x00/ipw2200.c between commit
> 2ee4e27cf25ab647137713ca16377d8d9e138ea2 ("ipw2200: check for allocation
> failures") from the wireless tree and commit
> baeb2ffab4e67bb9174e6166e070a9a8ec94b0f6 ("drivers/net: Convert unbounded
> kzalloc calls to kcalloc") from the net tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
That looks correct to me -- thanks!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] SIW: iWARP Protocol headers
From: Bernard Metzler @ 2010-10-06 12:52 UTC (permalink / raw)
To: Bart Van Assche
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTimkJHntzqL5fs+6kTTq-3kzwmoDtWyVq=qGe6vj-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org wrote on 10/05/2010 06:10:45 PM:
> On Tue, Oct 5, 2010 at 8:53 AM, Bernard Metzler <bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
wrote:
> > +} __attribute__((__packed__));
>
> Apparently you make extensive use of the packed attribute. Please read
> this blog entry, in which it is explained why this is harmful:
>
> http://digitalvampire.org/blog/index.php/2006/07/31/why-you-
> shouldnt-use-__attribute__packed/
>
right, thanks, i was not aware of that
big overhead.
but...there are reasons why we may need it _packed_:
(1) to get the size of the packet hdr
(2) to read/write the hdr content
(1) is not harmful. (2) could be limited to
just one read/write operation per rx/tx path
and all other access could be done on a
structure which contains the host representation
of the hdr content. both structures could coexist
in a union, part of the rx or tx context.
would that satisfy your complain?
many thanks,
bernard.
> Bart.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: Armin Schindler @ 2010-10-06 12:49 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Karsten Keil, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20101006121119.GA11681@bicker>
On Wed, 6 Oct 2010, Dan Carpenter wrote:
> On Wed, Oct 06, 2010 at 10:44:47AM +0200, Armin Schindler wrote:
>>> 927 strcpy (clients[id].drvName, tmp);
>>> 928 strcpy (clients[id].Dbg.drvName, tmp);
>>> ^
>>> this buffer is only 16 chars
>>
>> Now I understand. You are right. So the fix would be to change these
>> strcpy() to e.g. strncpy() or similar.
>>
>
> We need more than 16 characters to store the information. What is the
> problem with just making the buffer larger?
The larger buffer is not really needed. Later versions of the driver will
use the strcpy/memcpy with checked size anyway.
I just want to avoid a change in the debug structure which is used in more than one module/tool.
But it shouldn't be a real problem.
Armin
^ permalink raw reply
* Re: [v2 RFC PATCH 0/4] Implement multiqueue virtio-net
From: Arnd Bergmann @ 2010-10-06 12:19 UTC (permalink / raw)
To: Krishna Kumar2, Ben Greear
Cc: Michael S. Tsirkin, anthony, avi, davem, kvm, netdev, rusty
In-Reply-To: <OF13594229.1A55A20C-ON652577B3.00393C8D-652577B3.003A54C9@in.ibm.com>
On Tuesday 05 October 2010, Krishna Kumar2 wrote:
> After testing various combinations of #txqs, #vhosts, #netperf
> sessions, I think the drop for 1 stream is due to TX and RX for
> a flow being processed on different cpus. I did two more tests:
> 1. Pin vhosts to same CPU:
> - BW drop is much lower for 1 stream case (- 5 to -8% range)
> - But performance is not so high for more sessions.
> 2. Changed vhost to be single threaded:
> - No degradation for 1 session, and improvement for upto
> 8, sometimes 16 streams (5-12%).
> - BW degrades after that, all the way till 128 netperf sessions.
> - But overall CPU utilization improves.
> Summary of the entire run (for 1-128 sessions):
> txq=4: BW: (-2.3) CPU: (-16.5) RCPU: (-5.3)
> txq=16: BW: (-1.9) CPU: (-24.9) RCPU: (-9.6)
>
> I don't see any reasons mentioned above. However, for higher
> number of netperf sessions, I see a big increase in retransmissions:
> _______________________________________
> #netperf ORG NEW
> BW (#retr) BW (#retr)
> _______________________________________
> 1 70244 (0) 64102 (0)
> 4 21421 (0) 36570 (416)
> 8 21746 (0) 38604 (148)
> 16 21783 (0) 40632 (464)
> 32 22677 (0) 37163 (1053)
> 64 23648 (4) 36449 (2197)
> 128 23251 (2) 31676 (3185)
> _______________________________________
This smells like it could be related to a problem that Ben Greear found
recently (see "macvlan: Enable qdisc backoff logic"). When the hardware
is busy, used to just drop the packet. With Ben's patch, we return -EAGAIN
to qemu (or vhost-net) to trigger a resend.
I suppose what we really should do is feed that condition back to the
guest network stack and implement the backoff in there.
Arnd
^ permalink raw reply
* Re: [PATCH 1/3] bonding: rejoin multicast groups on VLANs
From: Andy Gospodarek @ 2010-10-06 12:12 UTC (permalink / raw)
To: David Miller
Cc: fleitner@redhat.com, netdev@vger.kernel.org,
bonding-devel@lists.sourceforge.net, fubar@us.ibm.com
In-Reply-To: <20101005.202840.183059128.davem@davemloft.net>
On Oct 5, 2010, at 11:28 PM, David Miller <davem@davemloft.net> wrote:
> From: Flavio Leitner <fleitner@redhat.com>
> Date: Tue, 5 Oct 2010 21:23:57 -0300
>
>> During a failover, the IGMP membership is sent to update
>> the switch restoring the traffic, but it misses groups added
>> to VLAN devices running on top of bonding devices.
>>
>> This patch changes it to iterate over all VLAN devices
>> on top of it sending IGMP memberships too.
>>
>> Signed-off-by: Flavio Leitner <fleitner@redhat.com>
>
> This seems to address Andy's feedback properly, and otherwise
> looks good to me, so applied to net-next-2.6
Agreed. Thanks for making those changes, Flavio.
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: Dan Carpenter @ 2010-10-06 12:11 UTC (permalink / raw)
To: Armin Schindler; +Cc: Karsten Keil, netdev, linux-kernel, kernel-janitors
In-Reply-To: <alpine.DEB.2.00.1010061043550.29582@justus.melware.de>
On Wed, Oct 06, 2010 at 10:44:47AM +0200, Armin Schindler wrote:
>> 927 strcpy (clients[id].drvName, tmp);
>> 928 strcpy (clients[id].Dbg.drvName, tmp);
>> ^
>> this buffer is only 16 chars
>
> Now I understand. You are right. So the fix would be to change these
> strcpy() to e.g. strncpy() or similar.
>
We need more than 16 characters to store the information. What is the
problem with just making the buffer larger?
regards,
dan carpenter
> Armin
^ permalink raw reply
* Re: [PATCH net-next] igb: fix stats handling
From: Jesper Dangaard Brouer @ 2010-10-06 11:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jeff Kirsher, Jesper Dangaard Brouer, Alexander Duyck,
David S. Miller, netdev, Carolyn Wyborny
In-Reply-To: <1286339791.4861.26.camel@edumazet-laptop>
On Wed, 2010-10-06 at 06:36 +0200, Eric Dumazet wrote:
> Le mercredi 06 octobre 2010 à 05:28 +0200, Eric Dumazet a écrit :
>
> > I'll let Intel guys doing the backporting work, but for old kernels,
> > you'll probably need to use "unsigned long" instead of "u64"
> >
> > My plan is :
> >
> > - Provide 64bit counters even on 32bit arch
> > - with proper synchro (include/linux/u64_stats_sync.h)
> > - Add a spinlock so we can apply Jesper patch.
You have already integrated my patch, so you get my:
Acked-by: Jesper Dangaard Brouer <hawk@comx.dk>
> Here is the net-next-2.6 patch, I am currently enable to test it, the
> dev machine with IGB NIC cannot be restarted until tomorrow, my son
> Nicolas is currently using it ;)
>
> Could you and/or Jesper test it, possibly on 32 and 64 bit kernels ?
I could not resist, I have tested the patch, on a 64 bit kernel, it
works :-). Did some simple test with two while loops running ethtool -S
and ifconfig, didn't see any wrong packet counts.
Tested-by: Jesper Dangaard Brouer <hawk@comx.dk>
Now back to moving office ;-)
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] net/fec: fix link/queue interaction, wake queue iff link is up
From: Oskar Schirmer @ 2010-10-06 11:31 UTC (permalink / raw)
To: netdev; +Cc: Dan Malek, Sebastian Siewior, Hans J. Koch, Oskar Schirmer
with hardware slow in negotiation, the system did freeze
while trying to mount root on nfs at boot time.
while the driver did report being busy when the link is down
or no transmission buffers are available, it did not stop the
queue, causing instant retries. furthermore, transmission being
triggered with link down was caused by unconditional queue
wakes, especially on timeouts.
now, wake queue only iff link is up and transmission
buffers are available, and dont forget to wake queue
when link has been adjusted. next, add stop queue notification
upon driver induced transmission problems, so network stack has
a chance to handle the situation.
Signed-off-by: Oskar Schirmer <oskar@linutronix.de>
---
drivers/net/fec.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 768b840..c2da006 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -222,12 +222,14 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
unsigned short status;
unsigned long flags;
+ spin_lock_irqsave(&fep->hw_lock, flags);
if (!fep->link) {
/* Link is down or autonegotiation is in progress. */
+ netif_stop_queue(dev);
+ spin_unlock_irqrestore(&fep->hw_lock, flags);
return NETDEV_TX_BUSY;
}
- spin_lock_irqsave(&fep->hw_lock, flags);
/* Fill in a Tx ring entry */
bdp = fep->cur_tx;
@@ -238,6 +240,7 @@ fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
* This should not happen, since dev->tbusy should be set.
*/
printk("%s: tx queue full!.\n", dev->name);
+ netif_stop_queue(dev);
spin_unlock_irqrestore(&fep->hw_lock, flags);
return NETDEV_TX_BUSY;
}
@@ -309,7 +312,8 @@ fec_timeout(struct net_device *dev)
dev->stats.tx_errors++;
fec_restart(dev, fep->full_duplex);
- netif_wake_queue(dev);
+ if (fep->link && !fep->tx_full)
+ netif_wake_queue(dev);
}
static irqreturn_t
@@ -602,9 +606,11 @@ static void fec_enet_adjust_link(struct net_device *dev)
/* Link on or off change */
if (phy_dev->link != fep->link) {
fep->link = phy_dev->link;
- if (phy_dev->link)
+ if (phy_dev->link) {
fec_restart(dev, phy_dev->duplex);
- else
+ if (!fep->tx_full)
+ netif_wake_queue(dev);
+ } else
fec_stop(dev);
status_change = 1;
}
--
1.7.0.4
^ permalink raw reply related
* drivers/net/Makefile - question about link order comment introduced in 2.3.43
From: Joe Perches @ 2010-10-06 11:04 UTC (permalink / raw)
To: netdev; +Cc: Sam Ravnborg, David Miller
It wasn't that way in 2.3.43-pre7 , but it is in 2.3.43
and has remained there since. There's nothing in lkml
history as far as I can find to describe a reason for it.
http://lkml.org/lkml/2000/2/10
(or thereabout)
Anyone know why it's like that or if that Makefile link
ordering is still needed?
Currently, drivers/net/Makefile line 42
#
# link order important here
#
obj-$(CONFIG_PLIP) += plip.o
[about 60 lines later...]
obj-$(CONFIG_STMMAC_ETH) += stmmac/
#
# end link order section
#
^ permalink raw reply
* Re: powerpc, fs_enet: scanning PHY after Linux is up
From: Heiko Schocher @ 2010-10-06 9:53 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, netdev, devicetree-discuss, Holger Brunck,
Detlev Zundel
In-Reply-To: <AANLkTinSersREjDnvg=8Gvpa6YmLuzgF1H8eEXRyCpW0@mail.gmail.com>
Hello Grant,
Thanks for your answer!
Grant Likely wrote:
> On Mon, Oct 4, 2010 at 1:32 AM, Heiko Schocher <hs@denx.de> wrote:
>> Hello all,
>>
>> we have on the mgcoge arch/powerpc/boot/dts/mgcoge.dts 3 fs_enet
>> devices. The first is accessible on boot, and so get correct
>> probed and works fine. For the other two fs_enet devices the PHYs
>> are on startup in reset, and gets later, through userapplikations,
>> out of reset ... so, on bootup, this 2 fs_enet devices could
>> not detect the PHY in drivers/of/of_mdio.c of_mdiobus_register(),
>> and if we want to use them later, we get for example:
>>
>> -bash-3.2# ifconfig eth2 172.31.31.33
>> net eth2: Could not attach to PHY
>> SIOCSIFFLAGS: No such device
>>
>> So the problem is, that we cannot rescan the PHYs, if they are
>> accessible. Also we could not load the fs_enet driver as a module,
>> because the first port is used fix.
>>
>> So, first question which comes in my mind, is:
>>
>> Is detecting the phy in drivers/of/of_mdio.c of_mdiobus_register()
>> the right place, or should it not better be done, when really
>> using the port?
>>
>> But we found another way to solve this issue:
>>
>> After the PHYs are out of reset, we just have to rescan the PHYs
>> with (for example PHY with addr 1)
>>
>> err = mdiobus_scan(bus, 1);
>>
>> and
>>
>> of_find_node_by_path("/soc@f0000000/cpm@119c0/mdio@10d40/ethernet-phy@1");
>> of_node_get(np);
>> dev_archdata_set_node(&err->dev.archdata, np);
>>
>> but thats just a hack ...
>
> Yeah, that's a hack. It really needs to be done via the of_mdio
> mechanisms so that dt <--> phy_device linkages remain consistent.
Yep, I know, thats the reason why I ask ;-)
>> So, the question is, is there a possibility to solve this problem?
>>
>> If there is no standard option, what would be with adding a
>> "scan_phy" file in
>>
>> /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
>> (or better destination?)
>>
>> which with we could rescan a PHY with
>> "echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/scan_phy"
>> (so there is no need for using of_find_node_by_path(), as we should
>> have the associated device node here, and can step through the child
>> nodes with "for_each_child_of_node(np, child)" and check if reg == addr)
>>
>> or shouldn;t be at least, if the phy couldn;t be found when opening
>> the port, retrigger a scanning, if the phy now is accessible?
>
> One option would be to still register a phy_device for each phy
> described in the device tree, but defer binding a driver to each phy
> that doesn't respond. Then at of_phy_find_device() time, if it
Maybe I din;t get the trick, but the problem is, that
you can;t register a phy_device in drivers/of/of_mdio.c
of_mdiobus_register(), if the phy didn;t respond with the
phy_id ... and of_phy_find_device() is not (yet) used in fs_enet
> matches with a phy_device that isn't bound to a driver yet, then
> re-trigger the binding operation. At which point the phy id can be
> probed and the correct driver can be chosen. If binding succeeds,
> then return the phy_device handle. If not, then fail as it currently
> does.
Wouldn;t it be good, just if we need a PHY (on calling fs_enet_open)
to look if there is one?
Something like that (not tested):
in drivers/net/fs_enet/fs_enet-main.c in fs_init_phy()
called from fs_enet_open():
Do first:
phydev = of_phy_find_device(fep->fpi->phy_node);
Look if there is a driver (phy_dev->drv == NULL ?)
If not, call new function
of_mdiobus_register_phy(mii_bus, fep->fpi->phy_node)
see below patch for it.
If this succeeds, all is OK, and we can use this phy,
else ethernet not work.
!!just no idea, how to get mii_bus pointer ...
here the patch for the new function of_mdiobus_register_phy():
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index b474833..7afbb0b 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -21,6 +21,51 @@
MODULE_AUTHOR("Grant Likely <grant.likely@secretlab.ca>");
MODULE_LICENSE("GPL");
+int of_mdiobus_register_phy(struct mii_bus *mdio, struct device_node *child)
+{
+ struct phy_device *phy;
+ const __be32 *addr;
+ int len;
+ int rc;
+
+ /* A PHY must have a reg property in the range [0-31] */
+ addr = of_get_property(child, "reg", &len);
+ if (!addr || len < sizeof(*addr) || *addr >= 32 || *addr < 0) {
+ dev_err(&mdio->dev, "%s has invalid PHY address\n",
+ child->full_name);
+ return -1;
+ }
+
+ if (mdio->irq) {
+ mdio->irq[*addr] = irq_of_parse_and_map(child, 0);
+ if (!mdio->irq[*addr])
+ mdio->irq[*addr] = PHY_POLL;
+ }
+
+ phy = get_phy_device(mdio, be32_to_cpup(addr));
+ if (!phy || IS_ERR(phy)) {
+ dev_err(&mdio->dev, "error probing PHY at address %i\n",
+ *addr);
+ return -2;
+ }
+ phy_scan_fixups(phy);
+ /* Associate the OF node with the device structure so it
+ * can be looked up later */
+ of_node_get(child);
+ dev_archdata_set_node(&phy->dev.archdata, child);
+
+ /* All data is now stored in the phy struct; register it */
+ rc = phy_device_register(phy);
+ if (rc) {
+ phy_device_free(phy);
+ of_node_put(child);
+ return -3;
+ }
+
+ dev_dbg(&mdio->dev, "registered phy %s at address %i\n",
+ child->name, *addr);
+}
+
/**
* of_mdiobus_register - Register mii_bus and create PHYs from the device tree
* @mdio: pointer to mii_bus structure
@@ -31,7 +76,6 @@ MODULE_LICENSE("GPL");
*/
int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
{
- struct phy_device *phy;
struct device_node *child;
int rc, i;
@@ -51,46 +95,7 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
/* Loop over the child nodes and register a phy_device for each one */
for_each_child_of_node(np, child) {
- const __be32 *addr;
- int len;
-
- /* A PHY must have a reg property in the range [0-31] */
- addr = of_get_property(child, "reg", &len);
- if (!addr || len < sizeof(*addr) || *addr >= 32 || *addr < 0) {
- dev_err(&mdio->dev, "%s has invalid PHY address\n",
- child->full_name);
- continue;
- }
-
- if (mdio->irq) {
- mdio->irq[*addr] = irq_of_parse_and_map(child, 0);
- if (!mdio->irq[*addr])
- mdio->irq[*addr] = PHY_POLL;
- }
-
- phy = get_phy_device(mdio, be32_to_cpup(addr));
- if (!phy || IS_ERR(phy)) {
- dev_err(&mdio->dev, "error probing PHY at address %i\n",
- *addr);
- continue;
- }
- phy_scan_fixups(phy);
-
- /* Associate the OF node with the device structure so it
- * can be looked up later */
- of_node_get(child);
- dev_archdata_set_node(&phy->dev.archdata, child);
-
- /* All data is now stored in the phy struct; register it */
- rc = phy_device_register(phy);
- if (rc) {
- phy_device_free(phy);
- of_node_put(child);
- continue;
- }
-
- dev_dbg(&mdio->dev, "registered phy %s at address %i\n",
- child->name, *addr);
+ of_mdiobus_register_phy(mdio, child);
}
return 0;
With this change, it would work on boot as actual (phy_device_register()
will fail for the PHYs who don;t work when booting).
Later, when opening the ethernet device, fs_init_phy, will look, if
we have a valid phy with driver, if not we try to register it again.
If this is successfull, we can use the device, if not we will fail,
as now ... what do you think?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply related
* Re: [PATCH] net: Fix sk_dst_check() to reset the obsolete dst_entry of a socket.
From: Chung-Yih Wang (王崇懿) @ 2010-10-06 9:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, timo.teras
In-Reply-To: <AANLkTikx+GadeYfg5rZNxsEig-0Af97ER7V94fjaVc+U@mail.gmail.com>
I did not pay attention to the CL, actually that did not fix the issue
I encountered. I have a connected UDP socket which will not escape
from the "blackhole" since it will never enter the ipv4_blackhole
function.
In udp_sendmsg(), if the socket is connected one and the dst entry is
obsolete, you will never have a chance to reset the socket's dst entry
since rt will not be NULL.
udp_sendmsg() {
....
if (connected)
rt = (struct rtable *)sk_dst_check(sk, 0);
if (rt == NULL) {
... blackhole_function_will_be_executed_here?
}
...
}
On Wed, Oct 6, 2010 at 12:47 AM, Chung-Yih Wang (王崇懿) <cywang@google.com> wrote:
> In fact, that is what I intent to change originally. However, consider
> Timo's issue, I intent to submit this patch instead.
>
> On Wed, Oct 6, 2010 at 12:35 AM, David Miller <davem@davemloft.net> wrote:
>>
>> This should have been fixed by:
>>
>> --------------------
>> commit ae2688d59b5f861dc70a091d003773975d2ae7fb
>> Author: Jianzhao Wang <jianzhao.wang@6wind.com>
>> Date: Wed Sep 8 14:35:43 2010 -0700
>>
>> net: blackhole route should always be recalculated
>>
>> Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
>> triggered by IKE for example), hence this kind of route is always
>> temporary and so we should check if a better route exists for next
>> packets.
>> Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92.
>>
>> Signed-off-by: Jianzhao Wang <jianzhao.wang@6wind.com>
>> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>> index 3f56b6e..6298f75 100644
>> --- a/net/ipv4/route.c
>> +++ b/net/ipv4/route.c
>> @@ -2738,6 +2738,11 @@ slow_output:
>> }
>> EXPORT_SYMBOL_GPL(__ip_route_output_key);
>>
>> +static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 cookie)
>> +{
>> + return NULL;
>> +}
>> +
>> static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)
>> {
>> }
>> @@ -2746,7 +2751,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
>> .family = AF_INET,
>> .protocol = cpu_to_be16(ETH_P_IP),
>> .destroy = ipv4_dst_destroy,
>> - .check = ipv4_dst_check,
>> + .check = ipv4_blackhole_dst_check,
>> .update_pmtu = ipv4_rt_blackhole_update_pmtu,
>> .entries = ATOMIC_INIT(0),
>> };
>>
>
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH v3] Topcliff: Update PCH_CAN driver to 2.6.35
From: Wolfgang Grandegger @ 2010-10-06 9:12 UTC (permalink / raw)
To: David Miller
Cc: andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
sameo-VuQAYsv1563Yd54FQh9/CA,
margie.foster-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, yong.y.wang-ral2JQCrhuEAvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
masa-korg-ECg8zkTtlr0C6LszWs/t0g, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
joel.clark-ral2JQCrhuEAvxtiuMwx3w,
morinaga526-ECg8zkTtlr0C6LszWs/t0g,
meego-dev-WXzIur8shnEAvxtiuMwx3w,
kok.howg.ewe-ral2JQCrhuEAvxtiuMwx3w, chripell-VaTbYqLCNhc,
qi.wang-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20101005.200904.71120150.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 10/06/2010 05:09 AM, David Miller wrote:
> From: "Masayuki Ohtake" <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
> Date: Wed, 6 Oct 2010 12:07:15 +0900
>
>> Does your mail mean, for accepting upstream, NAPI is essential for
>> CAN driver ?
>
> It is up to the CAN maintainers :-)
Well, our SJA1000 reference driver does still not use NAPI. But NAPI is
for CAN especially useful to avoid the infamous *bus error irq
flooding*, which may hang low end systems if the interrupts are handled
in the IRQ context. Ohtake, if your system can handle well such CAN bus
error irq storms at 1MB/s, then NAPI is *not* a must to have. Anyway, as
you are at it, I also suggest to use NAPI right from the beginning.
Wolfgang.
^ permalink raw reply
* Re: [PATCH] Documentation/networking/ip-sysctl.txt tcp_tw_recycle & tcp_tw_reuse
From: Jack Stone @ 2010-10-06 9:09 UTC (permalink / raw)
To: Sami Kerola; +Cc: linux-doc, linux-kernel, davem, netdev
In-Reply-To: <1286213524-4659-1-git-send-email-kerolasa@iki.fi>
On 04/10/2010 18:32, Sami Kerola wrote:
> From: Sami Kerola <kerolasa@iki.fi>
>
> Instead of saying 'consult your technical export' the
> documentation needs to assist an export to decide whether to keep
> these settings off or set them on.
>
> Signed-off-by: Sami Kerola <kerolasa@iki.fi>
I think the idea of this patch is still valuable. I've included possible
rewordings inline below. I can't guarentee the english is correct but
hopefully we can iterate to something acceptable to all.
> ---
> Documentation/networking/ip-sysctl.txt | 20 +++++++++++++-------
> 1 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index f350c69..01e2948 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -444,15 +444,21 @@ tcp_tso_win_divisor - INTEGER
> Default: 3
>
> tcp_tw_recycle - BOOLEAN
> - Enable fast recycling TIME-WAIT sockets. Default value is 0.
> - It should not be changed without advice/request of technical
> - experts.
> + Enable fast recycling TIME-WAIT sockets. See also caution
> + wrote to tcp_tw_reuse. Default value is 0.
Enable fast recycling TIME-WAIT sockets. This option can be dangerous.
See the warning
under tcp_tw-reuse for more information. Default value is 0.
>
> tcp_tw_reuse - BOOLEAN
> - Allow to reuse TIME-WAIT sockets for new connections when it is
> - safe from protocol viewpoint. Default value is 0.
> - It should not be changed without advice/request of technical
> - experts.
> + Allow to reuse TIME-WAIT sockets for new connections when it is safe
> + from protocol viewpoint. One should enable also tcp_timestamps when
> + this is enabled. Default value is 0.
> +
> + Caution. Both tcp_tw_recycle and tcp_tw_reuse can cause problems. You
> + should not enable either without being sure about network topology in
> + between node(s) which are using, or used by, the node(s) where the
> + parameter is enabled. Connections that go via TCP state aware nodes,
> + such as firewalls, NAT devices or load balancers may start drop frames
> + because of the setting. The more there are connections the greater is
> + the likelyhood you will see this issue.
The above paragraph reads oddly to me. How about:
Neither of these options should be enabled unless the network topology
is known. Connections
that go via TCP state aware nodes, such as firewalls, NAT devices or
load balancers may experience
dropped frames. The larger the number of connections the greater the
likelihood of this issue occuring.
>
> tcp_window_scaling - BOOLEAN
> Enable window scaling as defined in RFC1323.
Hope this helps,
Jack
^ permalink raw reply
* Re: [PATCH] iwlwifi: fix iwlwifi scanning corner cases
From: Stanislaw Gruszka @ 2010-10-06 9:02 UTC (permalink / raw)
To: Florian Mickler
Cc: linville-2XuSBdqkA4R54TAoqtyWWQ, stable-DgEjT+Ai2ygdnm+yROfE0A,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wey-yi.w.guy-ral2JQCrhuEAvxtiuMwx3w,
reinette.chatre-ral2JQCrhuEAvxtiuMwx3w,
ilw-VuQAYsv1563Yd54FQh9/CA, johannes.berg-ral2JQCrhuEAvxtiuMwx3w,
ben.m.cahill-ral2JQCrhuEAvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1286317292-10679-1-git-send-email-florian-sVu6HhrpSfRAfugRpC6u6w@public.gmane.org>
Hi Florian
On Wed, Oct 06, 2010 at 12:21:32AM +0200, Florian Mickler wrote:
> Stanislaw Gruszka pointed out, that commit
> "iwl3945: queue the right work if the scan needs to be aborted"
> has an awkward definition of "right". Specifically the abort_scan work
> doesn't notify the generic wireless stack that the scan was aborted.
>
> In order to get rid of the warning in bug
> https://bugzilla.kernel.org/show_bug.cgi?id=17722
> we inform ieee80211_scan_completed that we are aborting
> the scan by setting the apropriate status bit in request_scan and
> pass it into ieee80211_scan_completed.
>
> Signed-off-by: Florian Mickler <florian-sVu6HhrpSfRAfugRpC6u6w@public.gmane.org>
> ---
>
> Hi John!
>
> Here is the fix that Stanislaw described.
> (Yes, it is in a brown paper bag.) Please wait for him to review this.
>
> Another option would be to just revert my previous patch and live with the
> warning until the scanning rework hit's mainline.
This patch is not so bad, but better would be just return value from
{iwlagn,iwl3945}_request_scan instead of queuing anything. I will
prepare patch(s) today or tomorrow.
Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: Armin Schindler @ 2010-10-06 8:44 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Karsten Keil, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20101006083117.GF5409@bicker>
On Wed, 6 Oct 2010, Dan Carpenter wrote:
> On Wed, Oct 06, 2010 at 10:21:02AM +0200, Armin Schindler wrote:
>> On Wed, 6 Oct 2010, Dan Carpenter wrote:
>>> On Wed, Oct 06, 2010 at 09:25:44AM +0200, Armin Schindler wrote:
>>>> On Mon, 4 Oct 2010, Dan Carpenter wrote:
>>>>> In diva_mnt_add_xdi_adapter() we do this:
>>>>> strcpy (clients[id].drvName, tmp);
>>>>> strcpy (clients[id].Dbg.drvName, tmp);
>>>>>
>>>>> The "clients[id].drvName" is a 128 character buffer and
>>>>> "clients[id].Dbg.drvName" was originally a 16 character buffer but I've
>>>>> changed it to 128 as well. We don't actually use 128 characters but we
>>>>> do use more than 16.
>>>>
>>>> I don't see any reason for that change. The driver names here do not use
>>>> more than 16 characters and when filled, the length is checked anyway.
>>>> Please avoid changing the size of that structure.
>>>>
>>>
>>> drivers/isdn/hardware/eicon/debug.c diva_mnt_add_xdi_adapter()
>>> 874 sprintf (tmp, "ADAPTER:%d SN:%u-%d",
>>> 12345678 90123 45 67
>>>
>>> That's a minimum 17 characters.
>>>
>>> 875 (int)logical,
>>> 876 serial & 0x00ffffff,
>>> 877 (byte)(((serial & 0xff000000) >> 24) + 1));
>>> 878 } else {
>>> 879 sprintf (tmp, "ADAPTER:%d SN:%u", (int)logical, serial);
>>> 880 }
>>
>> this is tmp with a bigger size. It seems you are mixing the sizes of
>> drvName and tmp.
>>
>
> What I mean is that later on we use strcpy() to copy "tmp" into
> "clients[id].Dbg.drvName"
>
> 927 strcpy (clients[id].drvName, tmp);
> 928 strcpy (clients[id].Dbg.drvName, tmp);
> ^
> this buffer is only 16 chars
Now I understand. You are right. So the fix would be to change these
strcpy() to e.g. strncpy() or similar.
Armin
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: Dan Carpenter @ 2010-10-06 8:31 UTC (permalink / raw)
To: Armin Schindler; +Cc: Karsten Keil, netdev, linux-kernel, kernel-janitors
In-Reply-To: <alpine.DEB.2.00.1010061019480.29404@justus.melware.de>
On Wed, Oct 06, 2010 at 10:21:02AM +0200, Armin Schindler wrote:
> On Wed, 6 Oct 2010, Dan Carpenter wrote:
>> On Wed, Oct 06, 2010 at 09:25:44AM +0200, Armin Schindler wrote:
>>> On Mon, 4 Oct 2010, Dan Carpenter wrote:
>>>> In diva_mnt_add_xdi_adapter() we do this:
>>>> strcpy (clients[id].drvName, tmp);
>>>> strcpy (clients[id].Dbg.drvName, tmp);
>>>>
>>>> The "clients[id].drvName" is a 128 character buffer and
>>>> "clients[id].Dbg.drvName" was originally a 16 character buffer but I've
>>>> changed it to 128 as well. We don't actually use 128 characters but we
>>>> do use more than 16.
>>>
>>> I don't see any reason for that change. The driver names here do not use
>>> more than 16 characters and when filled, the length is checked anyway.
>>> Please avoid changing the size of that structure.
>>>
>>
>> drivers/isdn/hardware/eicon/debug.c diva_mnt_add_xdi_adapter()
>> 874 sprintf (tmp, "ADAPTER:%d SN:%u-%d",
>> 12345678 90123 45 67
>>
>> That's a minimum 17 characters.
>>
>> 875 (int)logical,
>> 876 serial & 0x00ffffff,
>> 877 (byte)(((serial & 0xff000000) >> 24) + 1));
>> 878 } else {
>> 879 sprintf (tmp, "ADAPTER:%d SN:%u", (int)logical, serial);
>> 880 }
>
> this is tmp with a bigger size. It seems you are mixing the sizes of
> drvName and tmp.
>
What I mean is that later on we use strcpy() to copy "tmp" into
"clients[id].Dbg.drvName"
927 strcpy (clients[id].drvName, tmp);
928 strcpy (clients[id].Dbg.drvName, tmp);
^
this buffer is only 16 chars
regards,
dan carpenter
> Armin
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: Armin Schindler @ 2010-10-06 8:21 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Karsten Keil, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20101006074714.GE5409@bicker>
On Wed, 6 Oct 2010, Dan Carpenter wrote:
> On Wed, Oct 06, 2010 at 09:25:44AM +0200, Armin Schindler wrote:
>> On Mon, 4 Oct 2010, Dan Carpenter wrote:
>>> In diva_mnt_add_xdi_adapter() we do this:
>>> strcpy (clients[id].drvName, tmp);
>>> strcpy (clients[id].Dbg.drvName, tmp);
>>>
>>> The "clients[id].drvName" is a 128 character buffer and
>>> "clients[id].Dbg.drvName" was originally a 16 character buffer but I've
>>> changed it to 128 as well. We don't actually use 128 characters but we
>>> do use more than 16.
>>
>> I don't see any reason for that change. The driver names here do not use
>> more than 16 characters and when filled, the length is checked anyway.
>> Please avoid changing the size of that structure.
>>
>
> drivers/isdn/hardware/eicon/debug.c diva_mnt_add_xdi_adapter()
> 874 sprintf (tmp, "ADAPTER:%d SN:%u-%d",
> 12345678 90123 45 67
>
> That's a minimum 17 characters.
>
> 875 (int)logical,
> 876 serial & 0x00ffffff,
> 877 (byte)(((serial & 0xff000000) >> 24) + 1));
> 878 } else {
> 879 sprintf (tmp, "ADAPTER:%d SN:%u", (int)logical, serial);
> 880 }
this is tmp with a bigger size. It seems you are mixing the sizes of
drvName and tmp.
Armin
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: walter harms @ 2010-10-06 8:16 UTC (permalink / raw)
To: Dan Carpenter, Armin Schindler, Karsten Keil, netdev,
linux-kernel, kernel-janitors
In-Reply-To: <20101006074714.GE5409@bicker>
Dan Carpenter schrieb:
> On Wed, Oct 06, 2010 at 09:25:44AM +0200, Armin Schindler wrote:
>> On Mon, 4 Oct 2010, Dan Carpenter wrote:
>>> In diva_mnt_add_xdi_adapter() we do this:
>>> strcpy (clients[id].drvName, tmp);
>>> strcpy (clients[id].Dbg.drvName, tmp);
>>>
>>> The "clients[id].drvName" is a 128 character buffer and
>>> "clients[id].Dbg.drvName" was originally a 16 character buffer but I've
>>> changed it to 128 as well. We don't actually use 128 characters but we
>>> do use more than 16.
>> I don't see any reason for that change. The driver names here do not use
>> more than 16 characters and when filled, the length is checked anyway.
>> Please avoid changing the size of that structure.
>>
>
> drivers/isdn/hardware/eicon/debug.c diva_mnt_add_xdi_adapter()
> 874 sprintf (tmp, "ADAPTER:%d SN:%u-%d",
> 12345678 90123 45 67
>
> That's a minimum 17 characters.
>
> 875 (int)logical,
> 876 serial & 0x00ffffff,
> 877 (byte)(((serial & 0xff000000) >> 24) + 1));
> 878 } else {
> 879 sprintf (tmp, "ADAPTER:%d SN:%u", (int)logical, serial);
> 880 }
>
for that reason i am a fan of kasprintf().
Maybe this a solution here also ? samething like:
kasprintf (&buf, "ADAPTER:%d SN:%u-%d",12345678,90123,45,67):
...
kstrncpy(tmp,buf,sizeof(buf));
....
free(buf);
that would keep overflows away until the changes in the structure are ready.
re,
wh
^ permalink raw reply
* Re: Regarding to your linux kernel CL
From: David Miller @ 2010-10-06 8:14 UTC (permalink / raw)
To: herbert; +Cc: timo.teras, cywang, netdev
In-Reply-To: <20101006075946.GA5311@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 6 Oct 2010 15:59:46 +0800
> Perhaps we should move the genid/cookie logic into the dst so that
> we can eliminate the dst->check call or at least make it a lot less
> frequent.
That sounds like a good idea.
^ permalink raw reply
* Re: Regarding to your linux kernel CL
From: Chung-Yih Wang (王崇懿) @ 2010-10-06 8:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: Timo Teräs, davem, netdev
In-Reply-To: <20101006075946.GA5311@gondor.apana.org.au>
I have submitted a patch([PATCH] net: Fix sk_dst_check() to reset the
obsolete dst_entry of a socket) for this, please reply to that thread
then.
Thanks,
Chung-yih
On Wed, Oct 6, 2010 at 12:59 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Oct 06, 2010 at 10:02:56AM +0300, Timo Teräs wrote:
>>
>> What's the problem here? sk_dst_check not honoring if dst->obsolete>0 ?
>> Sounds like the sk_dst_check was buggy in the first place.
>
> Well the problem is that before we changed ip4_dst_check, everything
> worked properly. With IPv6, whenever a route is released, the serial
> number is always updated accordingly. This means that ip6_dst_check
> will always return NULL when obsolete > 1.
>
> The old ip4_dst_check also satisfied this requirement since it always
> returns NULL.
>
>> Looks like there's still some code around that does not do what the
>> obsolete field has been used for a long time.
>> obsolete = 0, dst entry is ok
>> obsolete = -1, you need to call ops->check for this entry
>> obsolete > 0, this entry is invalid
>>
>> So net/core/sock.c needs fixing. Just if we should change dst_check()
>> too, I'm not sure.
>>
>> Should we fix sk_dst_check to use dst_check(), and dst_check() to check
>> for dst->obsolete>0 ?
>
> Yes this should work too. However, I was never totally happy with
> this new dst->obsolete logic which means that we're doing an
> indirect call for every single packet which almost always does
> nothing.
>
> Perhaps we should move the genid/cookie logic into the dst so that
> we can eliminate the dst->check call or at least make it a lot less
> frequent.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
^ permalink raw reply
* Re: Regarding to your linux kernel CL
From: Herbert Xu @ 2010-10-06 7:59 UTC (permalink / raw)
To: Timo Teräs
Cc: "Chung-Yih Wang (王崇懿)", davem,
netdev
In-Reply-To: <4CAC1F20.6070009@iki.fi>
On Wed, Oct 06, 2010 at 10:02:56AM +0300, Timo Teräs wrote:
>
> What's the problem here? sk_dst_check not honoring if dst->obsolete>0 ?
> Sounds like the sk_dst_check was buggy in the first place.
Well the problem is that before we changed ip4_dst_check, everything
worked properly. With IPv6, whenever a route is released, the serial
number is always updated accordingly. This means that ip6_dst_check
will always return NULL when obsolete > 1.
The old ip4_dst_check also satisfied this requirement since it always
returns NULL.
> Looks like there's still some code around that does not do what the
> obsolete field has been used for a long time.
> obsolete = 0, dst entry is ok
> obsolete = -1, you need to call ops->check for this entry
> obsolete > 0, this entry is invalid
>
> So net/core/sock.c needs fixing. Just if we should change dst_check()
> too, I'm not sure.
>
> Should we fix sk_dst_check to use dst_check(), and dst_check() to check
> for dst->obsolete>0 ?
Yes this should work too. However, I was never totally happy with
this new dst->obsolete logic which means that we're doing an
indirect call for every single packet which almost always does
nothing.
Perhaps we should move the genid/cookie logic into the dst so that
we can eliminate the dst->check call or at least make it a lot less
frequent.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] net: Fix sk_dst_check() to reset the obsolete dst_entry of a socket.
From: Chung-Yih Wang (王崇懿) @ 2010-10-06 7:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, timo.teras
In-Reply-To: <20101006.003541.71128466.davem@davemloft.net>
In fact, that is what I intent to change originally. However, consider
Timo's issue, I intent to submit this patch instead.
On Wed, Oct 6, 2010 at 12:35 AM, David Miller <davem@davemloft.net> wrote:
>
> This should have been fixed by:
>
> --------------------
> commit ae2688d59b5f861dc70a091d003773975d2ae7fb
> Author: Jianzhao Wang <jianzhao.wang@6wind.com>
> Date: Wed Sep 8 14:35:43 2010 -0700
>
> net: blackhole route should always be recalculated
>
> Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
> triggered by IKE for example), hence this kind of route is always
> temporary and so we should check if a better route exists for next
> packets.
> Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92.
>
> Signed-off-by: Jianzhao Wang <jianzhao.wang@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 3f56b6e..6298f75 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2738,6 +2738,11 @@ slow_output:
> }
> EXPORT_SYMBOL_GPL(__ip_route_output_key);
>
> +static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 cookie)
> +{
> + return NULL;
> +}
> +
> static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)
> {
> }
> @@ -2746,7 +2751,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
> .family = AF_INET,
> .protocol = cpu_to_be16(ETH_P_IP),
> .destroy = ipv4_dst_destroy,
> - .check = ipv4_dst_check,
> + .check = ipv4_blackhole_dst_check,
> .update_pmtu = ipv4_rt_blackhole_update_pmtu,
> .entries = ATOMIC_INIT(0),
> };
>
^ permalink raw reply
* Re: [patch] eicon: make buffer larger
From: Dan Carpenter @ 2010-10-06 7:47 UTC (permalink / raw)
To: Armin Schindler; +Cc: Karsten Keil, netdev, linux-kernel, kernel-janitors
In-Reply-To: <alpine.DEB.2.00.1010060923120.29107@justus.melware.de>
On Wed, Oct 06, 2010 at 09:25:44AM +0200, Armin Schindler wrote:
> On Mon, 4 Oct 2010, Dan Carpenter wrote:
>> In diva_mnt_add_xdi_adapter() we do this:
>> strcpy (clients[id].drvName, tmp);
>> strcpy (clients[id].Dbg.drvName, tmp);
>>
>> The "clients[id].drvName" is a 128 character buffer and
>> "clients[id].Dbg.drvName" was originally a 16 character buffer but I've
>> changed it to 128 as well. We don't actually use 128 characters but we
>> do use more than 16.
>
> I don't see any reason for that change. The driver names here do not use
> more than 16 characters and when filled, the length is checked anyway.
> Please avoid changing the size of that structure.
>
drivers/isdn/hardware/eicon/debug.c diva_mnt_add_xdi_adapter()
874 sprintf (tmp, "ADAPTER:%d SN:%u-%d",
12345678 90123 45 67
That's a minimum 17 characters.
875 (int)logical,
876 serial & 0x00ffffff,
877 (byte)(((serial & 0xff000000) >> 24) + 1));
878 } else {
879 sprintf (tmp, "ADAPTER:%d SN:%u", (int)logical, serial);
880 }
regards,
dan carpenter
> Armin
^ permalink raw reply
* Re: [RFC] bonding: fix workqueue re-arming races
From: Narendra_K @ 2010-10-06 7:36 UTC (permalink / raw)
To: jbohac; +Cc: fubar, bonding-devel, markine, jarkao2, chavey, netdev
In-Reply-To: <20101005150317.GA15555@libnet-test.oslab.blr.amer.dell.com>
On Tue, Oct 05, 2010 at 08:33:29PM +0530, K, Narendra wrote:
> On Fri, Oct 01, 2010 at 11:52:32PM +0530, Jiri Bohac wrote:
> > On Fri, Sep 24, 2010 at 06:23:53AM -0500, Narendra K wrote:
> > > On Fri, Sep 17, 2010 at 04:14:33AM +0530, Jay Vosburgh wrote:
> > > > Jay Vosburgh <fubar@us.ibm.com> wrote:
> > > The follwing call trace was seen -
> >
> > This should be the BUG_ON(cwq->nr_active) in
> > destroy_workqueue()
> >
> > This is really strange. bondng_store_bonds() can do two things:
> > create or delete a bonding device.
> >
> > I checked the delete path, where I would normally expect such a
> > problem, but I can't find a way it could fail in this way.
> > bondng_store_bonds() calls unregister_netdevice(), which
> > - calls rollback_registered() -> bond_close()
> > - puts the device on the net_todo_list.
> > On rtnl_unlock() netdev_run_todo() gets called and that calls
> > bond_destructor().
> >
> > bond_close() now makes sure the rearming work items are not
> > pending, thus, the only work items that may still be pending on
> > the workqueue are the non-rearming "commit" work items.
> > flush_workqueue(), called at the beginning of destroy_workqueue()
> > should have waited for these to finish.
> > If all of the above is correct, this BUG_ON should never trigger.
> >
> > Maybe I am overlooking something, or it may be some kind of
> > failure/race condition in the create path, resulting in
> > bond_destructor() being called as well.
> >
> > Narendra, any chance to capture the dmesg lines preceeding the
> > BUG message? This should show which of the above cases it is.
>
> Jiri, I will try to reproduce the issue with ignore_loglevel to capture
> more data on the serial console and share it shortly.
Here is a more verbose sequence of log messages just before the issue is
hit. I have attached logs beginning two iterations before the failure.
Please let me know if you need logs further back in the sequence.
[ 6139.115628] bonding: bond0 is being created...
[ 6139.122159] bonding: bond0: setting mode to balance-alb (6).
[ 6139.128537] bonding: bond0: Setting MII monitoring interval to 100.
[ 6139.137702] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 6139.145516] bonding: bond0: Adding slave eth0.
[ 6139.173964] bnx2 0000:01:00.0: irq 79 for MSI/MSI-X
[ 6139.179111] bnx2 0000:01:00.0: irq 80 for MSI/MSI-X
[ 6139.184262] bnx2 0000:01:00.0: irq 81 for MSI/MSI-X
[ 6139.189424] bnx2 0000:01:00.0: irq 82 for MSI/MSI-X
[ 6139.194559] bnx2 0000:01:00.0: irq 83 for MSI/MSI-X
[ 6139.199701] bnx2 0000:01:00.0: irq 84 for MSI/MSI-X
[ 6139.204873] bnx2 0000:01:00.0: irq 85 for MSI/MSI-X
[ 6139.210016] bnx2 0000:01:00.0: irq 86 for MSI/MSI-X
[ 6139.215158] bnx2 0000:01:00.0: irq 87 for MSI/MSI-X
[ 6139.270975] bnx2 0000:01:00.0: eth0: using MSIX
[ 6139.278893] bonding: bond0: enslaving eth0 as an active interface with a down link.
[ 6139.291007] bonding: bond0: Adding slave eth1.
[ 6139.321113] bnx2 0000:01:00.1: irq 88 for MSI/MSI-X
[ 6139.325991] bnx2 0000:01:00.1: irq 89 for MSI/MSI-X
[ 6139.330866] bnx2 0000:01:00.1: irq 90 for MSI/MSI-X
[ 6139.335752] bnx2 0000:01:00.1: irq 91 for MSI/MSI-X
[ 6139.340626] bnx2 0000:01:00.1: irq 92 for MSI/MSI-X
[ 6139.345500] bnx2 0000:01:00.1: irq 93 for MSI/MSI-X
[ 6139.350373] bnx2 0000:01:00.1: irq 94 for MSI/MSI-X
[ 6139.355246] bnx2 0000:01:00.1: irq 95 for MSI/MSI-X
[ 6139.360119] bnx2 0000:01:00.1: irq 96 for MSI/MSI-X
[ 6139.418765] bnx2 0000:01:00.1: eth1: using MSIX
[ 6139.426671] bonding: bond0: enslaving eth1 as an active interface with a down link.
[ 6139.438664] bonding: bond0: Adding slave eth2.
[ 6139.469101] bnx2 0000:02:00.0: irq 97 for MSI/MSI-X
[ 6139.473980] bnx2 0000:02:00.0: irq 98 for MSI/MSI-X
[ 6139.478856] bnx2 0000:02:00.0: irq 99 for MSI/MSI-X
[ 6139.483743] bnx2 0000:02:00.0: irq 100 for MSI/MSI-X
[ 6139.488706] bnx2 0000:02:00.0: irq 101 for MSI/MSI-X
[ 6139.493670] bnx2 0000:02:00.0: irq 102 for MSI/MSI-X
[ 6139.498641] bnx2 0000:02:00.0: irq 103 for MSI/MSI-X
[ 6139.503604] bnx2 0000:02:00.0: irq 104 for MSI/MSI-X
[ 6139.508566] bnx2 0000:02:00.0: irq 105 for MSI/MSI-X
[ 6139.566908] bnx2 0000:02:00.0: eth2: using MSIX
[ 6139.574815] bonding: bond0: enslaving eth2 as an active interface with a down link.
[ 6139.586686] bonding: bond0: Adding slave eth3.
[ 6139.617042] bnx2 0000:02:00.1: irq 106 for MSI/MSI-X
[ 6139.622011] bnx2 0000:02:00.1: irq 107 for MSI/MSI-X
[ 6139.626974] bnx2 0000:02:00.1: irq 108 for MSI/MSI-X
[ 6139.631942] bnx2 0000:02:00.1: irq 109 for MSI/MSI-X
[ 6139.636904] bnx2 0000:02:00.1: irq 110 for MSI/MSI-X
[ 6139.641867] bnx2 0000:02:00.1: irq 111 for MSI/MSI-X
[ 6139.646835] bnx2 0000:02:00.1: irq 112 for MSI/MSI-X
[ 6139.651798] bnx2 0000:02:00.1: irq 113 for MSI/MSI-X
[ 6139.656760] bnx2 0000:02:00.1: irq 114 for MSI/MSI-X
[ 6139.714833] bnx2 0000:02:00.1: eth3: using MSIX
[ 6139.722929] bonding: bond0: enslaving eth3 as an active interface with a down link.
[ 6141.684544] bnx2 0000:01:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6141.732924] bonding: bond0: link status definitely up for interface eth0.
[ 6141.739714] bonding: bond0: making interface eth0 the new active one.
[ 6141.749618] bonding: bond0: first active interface up!
[ 6141.756427] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 6141.832597] bnx2 0000:01:00.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6141.840185] bonding: bond0: link status definitely up for interface eth1.
[ 6142.013511] bnx2 0000:02:00.0: eth2: NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
[ 6142.037019] bonding: bond0: link status definitely up for interface eth2.
[ 6146.252919] bonding: bond0: link status definitely down for interface eth0, disabling it
[ 6146.261009] bonding: bond0: making interface eth1 the new active one.
[ 6146.305466] bnx2 0000:01:00.0: irq 79 for MSI/MSI-X
[ 6146.310347] bnx2 0000:01:00.0: irq 80 for MSI/MSI-X
[ 6146.315223] bnx2 0000:01:00.0: irq 81 for MSI/MSI-X
[ 6146.320100] bnx2 0000:01:00.0: irq 82 for MSI/MSI-X
[ 6146.324983] bnx2 0000:01:00.0: irq 83 for MSI/MSI-X
[ 6146.329858] bnx2 0000:01:00.0: irq 84 for MSI/MSI-X
[ 6146.334735] bnx2 0000:01:00.0: irq 85 for MSI/MSI-X
[ 6146.339611] bnx2 0000:01:00.0: irq 86 for MSI/MSI-X
[ 6146.344535] bnx2 0000:01:00.0: irq 87 for MSI/MSI-X
[ 6146.402416] bnx2 0000:01:00.0: eth0: using MSIX
[ 6147.100849] bonding: bond0: link status definitely down for interface eth1, disabling it
[ 6147.108943] bonding: bond0: making interface eth2 the new active one.
[ 6147.153439] bnx2 0000:01:00.1: irq 88 for MSI/MSI-X
[ 6147.158322] bnx2 0000:01:00.1: irq 89 for MSI/MSI-X
[ 6147.163199] bnx2 0000:01:00.1: irq 90 for MSI/MSI-X
[ 6147.168081] bnx2 0000:01:00.1: irq 91 for MSI/MSI-X
[ 6147.172957] bnx2 0000:01:00.1: irq 92 for MSI/MSI-X
[ 6147.177833] bnx2 0000:01:00.1: irq 93 for MSI/MSI-X
[ 6147.182717] bnx2 0000:01:00.1: irq 94 for MSI/MSI-X
[ 6147.187597] bnx2 0000:01:00.1: irq 95 for MSI/MSI-X
[ 6147.192584] bnx2 0000:01:00.1: irq 96 for MSI/MSI-X
[ 6147.250432] bnx2 0000:01:00.1: eth1: using MSIX
[ 6147.956727] bonding: bond0: link status definitely down for interface eth2, disabling it
[ 6147.964821] bonding: bond0: now running without any active interface !
[ 6148.005316] bnx2 0000:02:00.0: irq 97 for MSI/MSI-X
[ 6148.010198] bnx2 0000:02:00.0: irq 98 for MSI/MSI-X
[ 6148.015072] bnx2 0000:02:00.0: irq 99 for MSI/MSI-X
[ 6148.019949] bnx2 0000:02:00.0: irq 100 for MSI/MSI-X
[ 6148.024911] bnx2 0000:02:00.0: irq 101 for MSI/MSI-X
[ 6148.029872] bnx2 0000:02:00.0: irq 102 for MSI/MSI-X
[ 6148.034833] bnx2 0000:02:00.0: irq 103 for MSI/MSI-X
[ 6148.039793] bnx2 0000:02:00.0: irq 104 for MSI/MSI-X
[ 6148.044756] bnx2 0000:02:00.0: irq 105 for MSI/MSI-X
[ 6148.102286] bnx2 0000:02:00.0: eth2: using MSIX
[ 6148.873352] bnx2 0000:02:00.1: irq 106 for MSI/MSI-X
[ 6148.878319] bnx2 0000:02:00.1: irq 107 for MSI/MSI-X
[ 6148.883293] bnx2 0000:02:00.1: irq 108 for MSI/MSI-X
[ 6148.888253] bnx2 0000:02:00.1: irq 109 for MSI/MSI-X
[ 6148.893213] bnx2 0000:02:00.1: irq 110 for MSI/MSI-X
[ 6148.898174] bnx2 0000:02:00.1: irq 111 for MSI/MSI-X
[ 6148.903134] bnx2 0000:02:00.1: irq 112 for MSI/MSI-X
[ 6148.908094] bnx2 0000:02:00.1: irq 113 for MSI/MSI-X
[ 6148.913060] bnx2 0000:02:00.1: irq 114 for MSI/MSI-X
[ 6148.970345] bnx2 0000:02:00.1: eth3: using MSIX
[ 6149.445381] bnx2 0000:01:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6149.540563] bonding: bond0: link status definitely up for interface eth0.
[ 6149.547352] bonding: bond0: making interface eth0 the new active one.
[ 6149.557274] bonding: bond0: first active interface up!
[ 6149.941355] bonding: bond0: Removing slave eth0.
[ 6149.945983] bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:22:19:cc:9a:25 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
[ 6149.962010] bonding: bond0: releasing active interface eth0
[ 6150.074401] bonding: bond0: Removing slave eth1.
[ 6150.079027] bonding: bond0: releasing active interface eth1
[ 6150.202403] bonding: bond0: Removing slave eth2.
[ 6150.207028] bonding: bond0: releasing active interface eth2
[ 6150.330275] bonding: bond0: Removing slave eth3.
[ 6150.334900] bonding: bond0: releasing active interface eth3
[ 6150.552776] bonding: bond0 is being deleted...
[ 6156.145939] bonding: bond0 is being created...
[ 6156.152253] bonding: bond0: setting mode to balance-alb (6).
[ 6156.158899] bonding: bond0: Setting MII monitoring interval to 100.
[ 6156.168142] ADDRCONF(NETDEV_UP): bond0: link is not ready
[ 6156.176120] bonding: bond0: Adding slave eth0.
[ 6156.205188] bnx2 0000:01:00.0: irq 79 for MSI/MSI-X
[ 6156.210066] bnx2 0000:01:00.0: irq 80 for MSI/MSI-X
[ 6156.214942] bnx2 0000:01:00.0: irq 81 for MSI/MSI-X
[ 6156.219817] bnx2 0000:01:00.0: irq 82 for MSI/MSI-X
[ 6156.224724] bnx2 0000:01:00.0: irq 83 for MSI/MSI-X
[ 6156.229599] bnx2 0000:01:00.0: irq 84 for MSI/MSI-X
[ 6156.234473] bnx2 0000:01:00.0: irq 85 for MSI/MSI-X
[ 6156.239347] bnx2 0000:01:00.0: irq 86 for MSI/MSI-X
[ 6156.244222] bnx2 0000:01:00.0: irq 87 for MSI/MSI-X
[ 6156.301985] bnx2 0000:01:00.0: eth0: using MSIX
[ 6156.309899] bonding: bond0: enslaving eth0 as an active interface with a down link.
[ 6156.321860] bonding: bond0: Adding slave eth1.
[ 6156.348184] bnx2 0000:01:00.1: irq 88 for MSI/MSI-X
[ 6156.353066] bnx2 0000:01:00.1: irq 89 for MSI/MSI-X
[ 6156.357942] bnx2 0000:01:00.1: irq 90 for MSI/MSI-X
[ 6156.362818] bnx2 0000:01:00.1: irq 91 for MSI/MSI-X
[ 6156.367694] bnx2 0000:01:00.1: irq 92 for MSI/MSI-X
[ 6156.372570] bnx2 0000:01:00.1: irq 93 for MSI/MSI-X
[ 6156.377445] bnx2 0000:01:00.1: irq 94 for MSI/MSI-X
[ 6156.382325] bnx2 0000:01:00.1: irq 95 for MSI/MSI-X
[ 6156.387199] bnx2 0000:01:00.1: irq 96 for MSI/MSI-X
[ 6156.445966] bnx2 0000:01:00.1: eth1: using MSIX
[ 6156.453878] bonding: bond0: enslaving eth1 as an active interface with a down link.
[ 6156.465826] bonding: bond0: Adding slave eth2.
[ 6156.496230] bnx2 0000:02:00.0: irq 97 for MSI/MSI-X
[ 6156.501110] bnx2 0000:02:00.0: irq 98 for MSI/MSI-X
[ 6156.505986] bnx2 0000:02:00.0: irq 99 for MSI/MSI-X
[ 6156.510868] bnx2 0000:02:00.0: irq 100 for MSI/MSI-X
[ 6156.515832] bnx2 0000:02:00.0: irq 101 for MSI/MSI-X
[ 6156.520794] bnx2 0000:02:00.0: irq 102 for MSI/MSI-X
[ 6156.525760] bnx2 0000:02:00.0: irq 103 for MSI/MSI-X
[ 6156.530723] bnx2 0000:02:00.0: irq 104 for MSI/MSI-X
[ 6156.535685] bnx2 0000:02:00.0: irq 105 for MSI/MSI-X
[ 6156.594017] bnx2 0000:02:00.0: eth2: using MSIX
[ 6156.601932] bonding: bond0: enslaving eth2 as an active interface with a down link.
[ 6156.613845] bonding: bond0: Adding slave eth3.
[ 6156.644229] bnx2 0000:02:00.1: irq 106 for MSI/MSI-X
[ 6156.649197] bnx2 0000:02:00.1: irq 107 for MSI/MSI-X
[ 6156.654161] bnx2 0000:02:00.1: irq 108 for MSI/MSI-X
[ 6156.659130] bnx2 0000:02:00.1: irq 109 for MSI/MSI-X
[ 6156.664093] bnx2 0000:02:00.1: irq 110 for MSI/MSI-X
[ 6156.669056] bnx2 0000:02:00.1: irq 111 for MSI/MSI-X
[ 6156.674023] bnx2 0000:02:00.1: irq 112 for MSI/MSI-X
[ 6156.678985] bnx2 0000:02:00.1: irq 113 for MSI/MSI-X
[ 6156.683947] bnx2 0000:02:00.1: irq 114 for MSI/MSI-X
[ 6156.742024] bnx2 0000:02:00.1: eth3: using MSIX
[ 6156.749940] bonding: bond0: enslaving eth3 as an active interface with a down link.
[ 6158.808483] bnx2 0000:01:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6158.868054] bonding: bond0: link status definitely up for interface eth0.
[ 6158.874846] bonding: bond0: making interface eth0 the new active one.
[ 6158.884753] bonding: bond0: first active interface up!
[ 6158.891563] ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
[ 6158.922727] bnx2 0000:01:00.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6158.968157] bonding: bond0: link status definitely up for interface eth1.
[ 6159.021517] bnx2 0000:02:00.0: eth2: NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
[ 6159.068235] bonding: bond0: link status definitely up for interface eth2.
[ 6160.040150] bnx2 0000:01:00.1: eth1: NIC Copper Link is Down
[ 6160.069773] bonding: bond0: link status definitely down for interface eth1, disabling it
[ 6162.460199] bnx2 0000:01:00.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6162.467865] bonding: bond0: link status definitely up for interface eth1.
[ 6163.168061] bonding: bond0: link status definitely down for interface eth0, disabling it
[ 6163.176149] bonding: bond0: making interface eth1 the new active one.
[ 6163.220460] bnx2 0000:01:00.0: irq 79 for MSI/MSI-X
[ 6163.225481] bnx2 0000:01:00.0: irq 80 for MSI/MSI-X
[ 6163.230413] bnx2 0000:01:00.0: irq 81 for MSI/MSI-X
[ 6163.235342] bnx2 0000:01:00.0: irq 82 for MSI/MSI-X
[ 6163.240282] bnx2 0000:01:00.0: irq 83 for MSI/MSI-X
[ 6163.245212] bnx2 0000:01:00.0: irq 84 for MSI/MSI-X
[ 6163.250142] bnx2 0000:01:00.0: irq 85 for MSI/MSI-X
[ 6163.255080] bnx2 0000:01:00.0: irq 86 for MSI/MSI-X
[ 6163.260009] bnx2 0000:01:00.0: irq 87 for MSI/MSI-X
[ 6163.317682] bnx2 0000:01:00.0: eth0: using MSIX
[ 6164.032023] bonding: bond0: link status definitely down for interface eth1, disabling it
[ 6164.040115] bonding: bond0: making interface eth2 the new active one.
[ 6164.084607] bnx2 0000:01:00.1: irq 88 for MSI/MSI-X
[ 6164.089488] bnx2 0000:01:00.1: irq 89 for MSI/MSI-X
[ 6164.094361] bnx2 0000:01:00.1: irq 90 for MSI/MSI-X
[ 6164.099236] bnx2 0000:01:00.1: irq 91 for MSI/MSI-X
[ 6164.104111] bnx2 0000:01:00.1: irq 92 for MSI/MSI-X
[ 6164.108986] bnx2 0000:01:00.1: irq 93 for MSI/MSI-X
[ 6164.113860] bnx2 0000:01:00.1: irq 94 for MSI/MSI-X
[ 6164.118733] bnx2 0000:01:00.1: irq 95 for MSI/MSI-X
[ 6164.123608] bnx2 0000:01:00.1: irq 96 for MSI/MSI-X
[ 6164.181533] bnx2 0000:01:00.1: eth1: using MSIX
[ 6164.880097] bonding: bond0: link status definitely down for interface eth2, disabling it
[ 6164.888191] bonding: bond0: now running without any active interface !
[ 6164.932440] bnx2 0000:02:00.0: irq 97 for MSI/MSI-X
[ 6164.937322] bnx2 0000:02:00.0: irq 98 for MSI/MSI-X
[ 6164.942253] bnx2 0000:02:00.0: irq 99 for MSI/MSI-X
[ 6164.947192] bnx2 0000:02:00.0: irq 100 for MSI/MSI-X
[ 6164.952208] bnx2 0000:02:00.0: irq 101 for MSI/MSI-X
[ 6164.957234] bnx2 0000:02:00.0: irq 102 for MSI/MSI-X
[ 6164.962247] bnx2 0000:02:00.0: irq 103 for MSI/MSI-X
[ 6164.967274] bnx2 0000:02:00.0: irq 104 for MSI/MSI-X
[ 6164.972290] bnx2 0000:02:00.0: irq 105 for MSI/MSI-X
[ 6165.029585] bnx2 0000:02:00.0: eth2: using MSIX
[ 6165.776479] bnx2 0000:02:00.1: irq 106 for MSI/MSI-X
[ 6165.781449] bnx2 0000:02:00.1: irq 107 for MSI/MSI-X
[ 6165.786422] bnx2 0000:02:00.1: irq 108 for MSI/MSI-X
[ 6165.791385] bnx2 0000:02:00.1: irq 109 for MSI/MSI-X
[ 6165.796345] bnx2 0000:02:00.1: irq 110 for MSI/MSI-X
[ 6165.801312] bnx2 0000:02:00.1: irq 111 for MSI/MSI-X
[ 6165.806273] bnx2 0000:02:00.1: irq 112 for MSI/MSI-X
[ 6165.811233] bnx2 0000:02:00.1: irq 113 for MSI/MSI-X
[ 6165.816199] bnx2 0000:02:00.1: irq 114 for MSI/MSI-X
[ 6165.873445] bnx2 0000:02:00.1: eth3: using MSIX
[ 6165.951287] bnx2 0000:01:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6165.967840] bonding: bond0: link status definitely up for interface eth0.
[ 6165.974631] bonding: bond0: making interface eth0 the new active one.
[ 6165.984534] bonding: bond0: first active interface up!
[ 6166.836175] bnx2 0000:01:00.1: eth1: NIC Copper Link is Up, 1000 Mbps full duplex
[ 6166.839757] bonding: bond0: Removing slave eth0.
[ 6166.839768] bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:22:19:cc:9a:25 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
[ 6166.839772] bonding: bond0: releasing active interface eth0
[ 6166.870004]
[ 6166.999414] bonding: bond0: Removing slave eth1.
[ 6167.004041] bonding: bond0: releasing active interface eth1
[ 6167.125571] bonding: bond0: Removing slave eth2.
[ 6167.130196] bonding: bond0: releasing active interface eth2
[ 6167.253539] bonding: bond0: Removing slave eth3.
[ 6167.258162] bonding: bond0: releasing active interface eth3
[ 6167.443911] bonding: bond0 is being deleted...
[ 6167.508557] ------------[ cut here ]------------
[ 6167.513167] kernel BUG at kernel/workqueue.c:2844!
[ 6167.517948] invalid opcode: 0000 [#1] SMP
[ 6167.522058] last sysfs file: /sys/class/net/bonding_masters
[ 6167.527619] CPU 0
[ 6167.529452] Modules linked in: af_packet bonding ipv6 mperf microcode fuse loop dm_mod joydev usbhid hid tpm_tis tpm usb_storage iTCO_wdt tpm_bios iTCO_vendor_support rtc_cmos rtc_core rtc_lib sg mptctl sr_mod cdrom dcdbas power_meter bnx2 serio_raw button pcspkr uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif edd ext3 mbcache jbd fan processor ide_pci_generic ide_core ata_generic ata_piix libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod thermal thermal_sys hwmon
[ 6167.571721]
[ 6167.573209] Pid: 13848, comm: ifdown-bonding Not tainted 2.6.35.with.upstream.patch-next-20100811-0.7-default+ #1 0M233H/PowerEdge R710
[ 6167.585362] RIP: 0010:[<ffffffff81067b50>] [<ffffffff81067b50>] destroy_workqueue+0x1d0/0x1e0
[ 6167.593977] RSP: 0018:ffff880229981d88 EFLAGS: 00010286
[ 6167.599278] RAX: 000000000000003c RBX: ffff880127646800 RCX: ffff880128324700
[ 6167.606401] RDX: 0000000000001000 RSI: 0000000000000002 RDI: 000000000000001a
[ 6167.613523] RBP: ffff880229981da8 R08: ffff880229981cf8 R09: 0000000000000000
[ 6167.620646] R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000002
[ 6167.627769] R13: ffffffff817b8560 R14: ffff88012a028480 R15: ffff88012a028488
[ 6167.634892] FS: 00007fb251db3700(0000) GS:ffff880133a00000(0000) knlGS:0000000000000000
[ 6167.642969] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 6167.648705] CR2: 00007fb251de6000 CR3: 00000001283ca000 CR4: 00000000000006f0
[ 6167.655827] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 6167.662950] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 6167.670073] Process ifdown-bonding (pid: 13848, threadinfo ffff880229980000, task ffff88021db9a600)
[ 6167.679103] Stack:
[ 6167.681110] ffff880229981da8 ffff88012a028000 ffff88012a028000 000000010016619c
[ 6167.688354] <0> ffff880229981dc8 ffffffffa03bf91d ffff88012a028000 000000010016619c
[ 6167.696053] <0> ffff880229981e28 ffffffff812e0a08 ffff880229981e38 ffff880229981de8
[ 6167.703936] Call Trace:
[ 6167.706382] [<ffffffffa03bf91d>] bond_destructor+0x1d/0x30 [bonding]
[ 6167.712816] [<ffffffff812e0a08>] netdev_run_todo+0x1a8/0x270
[ 6167.718555] [<ffffffff812ee859>] rtnl_unlock+0x9/0x10
[ 6167.723752] [<ffffffffa03cc824>] bonding_store_bonds+0x1c4/0x1f0 [bonding]
[ 6167.730705] [<ffffffff810f26be>] ? alloc_pages_current+0x9e/0x110
[ 6167.736876] [<ffffffff81285c9e>] class_attr_store+0x1e/0x20
[ 6167.742528] [<ffffffff8116e365>] sysfs_write_file+0xc5/0x140
[ 6167.748267] [<ffffffff8110a68f>] vfs_write+0xcf/0x190
[ 6167.753397] [<ffffffff8110a840>] sys_write+0x50/0x90
[ 6167.758444] [<ffffffff81002ec2>] system_call_fastpath+0x16/0x1b
[ 6167.764439] Code: 00 7f 14 8b 3b eb 91 3d 00 10 00 00 89 c2 77 10 8b 3b e9 07 ff ff ff 3d 00 10 00 00 89 c2 76 f0 8b 3b e9 a9 fe ff ff 0f 0b eb fe <0f> 0b eb fe 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8b 3d 00
[ 6167.783930] RIP [<ffffffff81067b50>] destroy_workqueue+0x1d0/0x1e0
[ 6167.790200] RSP <ffff880229981d88>
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
--
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] net: Fix sk_dst_check() to reset the obsolete dst_entry of a socket.
From: David Miller @ 2010-10-06 7:35 UTC (permalink / raw)
To: cywang; +Cc: netdev, linux-kernel, timo.teras
In-Reply-To: <AANLkTikkv4htP1f=KFwSaa8=K6LicDN0eusXctow-Efb@mail.gmail.com>
This should have been fixed by:
--------------------
commit ae2688d59b5f861dc70a091d003773975d2ae7fb
Author: Jianzhao Wang <jianzhao.wang@6wind.com>
Date: Wed Sep 8 14:35:43 2010 -0700
net: blackhole route should always be recalculated
Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
triggered by IKE for example), hence this kind of route is always
temporary and so we should check if a better route exists for next
packets.
Bug has been introduced by commit d11a4dc18bf41719c9f0d7ed494d295dd2973b92.
Signed-off-by: Jianzhao Wang <jianzhao.wang@6wind.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 3f56b6e..6298f75 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2738,6 +2738,11 @@ slow_output:
}
EXPORT_SYMBOL_GPL(__ip_route_output_key);
+static struct dst_entry *ipv4_blackhole_dst_check(struct dst_entry *dst, u32 cookie)
+{
+ return NULL;
+}
+
static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)
{
}
@@ -2746,7 +2751,7 @@ static struct dst_ops ipv4_dst_blackhole_ops = {
.family = AF_INET,
.protocol = cpu_to_be16(ETH_P_IP),
.destroy = ipv4_dst_destroy,
- .check = ipv4_dst_check,
+ .check = ipv4_blackhole_dst_check,
.update_pmtu = ipv4_rt_blackhole_update_pmtu,
.entries = ATOMIC_INIT(0),
};
^ permalink raw reply related
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