* Re: [PATCH v3 03/10] net: Add netdev interfaces recording send/compl
From: Tom Herbert @ 2011-11-24 0:32 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20111123.190623.2026426589805797580.davem@davemloft.net>
>> I was referring to the transmit routine, there for netdev_sent_queue()
>> is always called with one packet.
>
> Optimism for the future? :-)
>
Yep, I am looking forward to the day that someone figures out how to
batch transmits in a meaningful way!
> But yeah if nobody batches right now, no reason to support this in the
> interfaces, we can add it later.
Okay.
>
^ permalink raw reply
* Re: [PATCH] ipv4: Save nexthop address of LSRR/SSRR option to IPCB.
From: David Miller @ 2011-11-24 0:41 UTC (permalink / raw)
To: lw; +Cc: netdev
In-Reply-To: <4ECCBDD6.8080708@cn.fujitsu.com>
From: Li Wei <lw@cn.fujitsu.com>
Date: Wed, 23 Nov 2011 17:33:10 +0800
> We can not update iph->daddr in ip_options_rcv_srr(), It is too early.
> When some exception ocurred later (eg. in ip_forward() when goto
> sr_failed) we need the ip header be identical to the original one as
> ICMP need it.
>
> Add a field 'nexthop' in struct ip_options to save nexthop of LSRR
> or SSRR option.
>
> Signed-off-by: Li Wei <lw@cn.fujitsu.com>
Applied, thanks.
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with Linus' tree
From: Stephen Rothwell @ 2011-11-24 0:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-next, linux-kernel, Jean-Christophe PLAGNIOL-VILLARD,
David Miller, netdev, Jamie Iles
[-- Attachment #1: Type: text/plain, Size: 920 bytes --]
Hi Arnd,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/net/ethernet/cadence/Kconfig between commit eccab1ec87d0
("net/cadence: enable by default NET_ATMEL") from Linus' tree and commit
f75ba50bdc2b ("macb: initial support for Cadence GEM") from the arm-soc
tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/cadence/Kconfig
index b48378a,a2e1500..0000000
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@@ -5,9 -5,8 +5,9 @@@
config HAVE_NET_MACB
bool
- config NET_ATMEL
- bool "Atmel devices"
+ config NET_CADENCE
+ bool "Cadence devices"
+ default y
depends on HAVE_NET_MACB || (ARM && ARCH_AT91RM9200)
---help---
If you have a network (Ethernet) card belonging to this class, say Y.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes
From: Herbert Xu @ 2011-11-24 1:01 UTC (permalink / raw)
To: David Miller; +Cc: steffen.klassert, netdev
In-Reply-To: <20111123.191758.1061988020384521241.davem@davemloft.net>
On Wed, Nov 23, 2011 at 07:17:58PM -0500, David Miller wrote:
>
> It means there is a propagation delay of PMTU increasing which is on the
> order of the number of hops between the sender and the PMTU increased link.
> So if the PMTU timeout is X, the propagation time is X * N_HOPS.
That assumes that each router in the path would constantly probe
to refresh its cached value, as otherwise they should all expire
after X.
However, as this was the original behaviour, I think going back to
it is fine.
I am curious in knowing exactly what scenario Steffen ran into
that prompted this change though.
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 v2] ipv4 : igmp : optimize timer modify logic in igmp_mod_timer()
From: Jun Zhao @ 2011-11-24 1:27 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20111123.190428.1925341377347198202.davem@davemloft.net>
On Wed, 2011-11-23 at 19:04 -0500, David Miller wrote:
> From: Jun Zhao <mypopydev@gmail.com>
> Date: Thu, 24 Nov 2011 06:54:45 +0800
>
> > On Wed, 2011-11-23 at 17:28 -0500, David Miller wrote:
> >> From: Jun Zhao <mypopydev@gmail.com>
> >> Date: Thu, 24 Nov 2011 00:38:42 +0800
> >>
> >> > When timer is pending and expires less-than-or-equal-to new delay,
> >> > we need not used del_timer()/add_timer().
> >> >
> >> > Signed-off-by: Jun Zhao <mypopydev@gmail.com>
> >>
> >> You did not answer Eric's question, why are you optimizing this
> >> less-used code path?
> >
> > 1). Oh, in the RFC 3376 $5.2, Page 23:
>
> Then your commit message is terrible.
>
> Your commit message, one the one hand, talks about optimizing the code.
>
> Your explanation here talks about RFC conformance.
>
> Your inconsistencies, and how you ignore important questions posed to
> you like Eric's (until I point it out to you) makes your work
> incredibly irritating to review and process.
I think Eric's means the v1 patch have a obvious bug about lock, I
didn't ignore it. ：（
>
> Your patch submissions need to be more well formed and your commit
> messages need to explain exactly what your goals are with your change
> and how those goals are being met by the patch you are proposing.
>
> When we read "optimize timer modify logic" how the heck are we
> supposed to know what this change is actually doing? Why should we
> think that we actually need your change? How am we supposed to figure
> out that you are fixing an RFC conformance issue?
>
I got it, Tks. Maybe the terrible commit message lead to the problem,
I just try to make this function more readability.
Yes, I need to describe the goals more accurately in the commit.
> I'm sorry, this patch submission is junk. Don't send us junk.
>
I got it.
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: Add Open vSwitch kernel components.
From: Justin Pettit @ 2011-11-24 2:34 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
David S. Miller
In-Reply-To: <1322012755.2039.36.camel@mojatatu>
On Nov 22, 2011, at 5:45 PM, Jamal Hadi Salim wrote:
> BTW, you _are using some of the actions_ already (the policer for
> example to do rate control; no disrespect intended but in a terrible
> way).
Hi, Jamal. I did the initial implementation of the rate control in Open vSwitch. Can you help us out with a few more specifics on the problems you see and how they could be improved?
Thanks,
--Justin
^ permalink raw reply
* [PATCH net-next] igb: reset PHY after recovering from PHY power down
From: Koki Sanagi @ 2011-11-24 3:18 UTC (permalink / raw)
To: netdev, jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
e1000-devel
Cc: davem
According to 82576_Datasheet.pdf, PHY setting is lost after PHY power down.
So resetting PHY is needed when recovering from PHY power down to set a default
setting to PHY register.
Owing to this lack, NIC doesn't link up in some rare situation.
The situation I encountered is following.
1.Both ports connect to switch.
+---------+ +--------+
| |-----------| |
| 82576NS | | switch |
| |-----------| |
+---------+ +--------+
2.Detach both cables from switch.
+---------+ +--------+
| |------- | |
| 82576NS | | switch |
| |------- | |
+---------+ +--------+
3.Detach one cable from one port.
+---------+ +--------+
| |------- | |
| 82576NS | | switch |
| | | |
+---------+ +--------+
4.Attach that cable to the other port.(It means connecting directly each port)
+---------+ +--------+
| |-------+ | |
| 82576NS | | | switch |
| |-------+ | |
+---------+ +--------+
As a result, NIC doesn't link up sometimes.
Signed-off-by: Koki Sanagi <sanagi.koki@jp.fujitsu.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index bd9b30e..4d4f065 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2496,6 +2496,7 @@ static int igb_open(struct net_device *netdev)
goto err_setup_rx;
igb_power_up_link(adapter);
+ igb_reset_phy(hw);
/* before we allocate an interrupt, we must be ready to handle it.
* Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
^ permalink raw reply related
* Re: [PATCH net-next] netxen: write IP address to firmware when using bonding
From: Andy Gospodarek @ 2011-11-24 3:24 UTC (permalink / raw)
To: David Miller; +Cc: andy, netdev, sony.chacko, rajesh.borundia
In-Reply-To: <20111123.160922.1983654308126240492.davem@davemloft.net>
On Wed, Nov 23, 2011 at 04:09:22PM -0500, David Miller wrote:
> From: Andy Gospodarek <andy@greyhouse.net>
> Date: Wed, 23 Nov 2011 13:43:11 -0500
>
> > The following patch was added to enable NX3031 devices to properly
> > aggregate frames for LRO:
> >
> > commit 6598b169b856793f8f9b80a3f3c5a48f5eaf40e3
> > Author: Dhananjay Phadke <dhananjay@netxen.com>
> > Date: Sun Jul 26 20:07:37 2009 +0000
> >
> > netxen: enable ip addr hashing
> >
> > This patch is a followup to that fix as it allows LRO aggregation on
> > bonded devices that contain an NX3031 device. This was tested on an
> > older distro and modified slightly to the latest upstream.
> >
> > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>
> Let's put a helper function somewhere instead of expanding this sequence
> in every driver that might want to determine if it is a bonding slave.
Dave,
Are you talking about adding a macro like this:
for_each_dev_in_bond(bond,slave) {
[...]
}
to replace the statements I added that were like this:
for_each_netdev_rcu(&init_net, slave) {
if (slave->master == dev) {
[...]
}
}
If so, that totally seems reasonable. If were requesting something
else, please let me know.
Thanks,
-andy
^ permalink raw reply
* [PATCH] net: mv643xx_eth: fix build error
From: Axel Lin @ 2011-11-24 3:47 UTC (permalink / raw)
To: linux-kernel; +Cc: Lennert Buytenhek, David S. Miller, netdev
Fix below build error:
CC drivers/net/ethernet/marvell/mv643xx_eth.o
drivers/net/ethernet/marvell/mv643xx_eth.c: In function 'mv643xx_eth_get_drvinfo':
drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: 'info' undeclared (first use in this function)
drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: (Each undeclared identifier is reported only once
drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: for each function it appears in.)
make[4]: *** [drivers/net/ethernet/marvell/mv643xx_eth.o] Error 1
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 43e3e61..e87847e 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -1502,11 +1502,12 @@ mv643xx_eth_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
static void mv643xx_eth_get_drvinfo(struct net_device *dev,
struct ethtool_drvinfo *drvinfo)
{
- strlcpy(drvinfo->driver, mv643xx_eth_driver_name, sizeof(info->driver));
+ strlcpy(drvinfo->driver, mv643xx_eth_driver_name,
+ sizeof(drvinfo->driver));
strlcpy(drvinfo->version, mv643xx_eth_driver_version,
- sizeof(info->version));
- strlcpy(drvinfo->fw_version, "N/A", sizeof(info->fw_version));
- strlcpy(drvinfo->bus_info, "platform", sizeof(info->bus_info));
+ sizeof(drvinfo->version));
+ strlcpy(drvinfo->fw_version, "N/A", sizeof(drvinfo->fw_version));
+ strlcpy(drvinfo->bus_info, "platform", sizeof(drvinfo->bus_info));
drvinfo->n_stats = ARRAY_SIZE(mv643xx_eth_stats);
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH net-next] netxen: write IP address to firmware when using bonding
From: David Miller @ 2011-11-24 5:38 UTC (permalink / raw)
To: andy; +Cc: netdev, sony.chacko, rajesh.borundia
In-Reply-To: <20111124032426.GG25132@gospo.rdu.redhat.com>
From: Andy Gospodarek <andy@greyhouse.net>
Date: Wed, 23 Nov 2011 22:24:27 -0500
> Are you talking about adding a macro like this:
>
> for_each_dev_in_bond(bond,slave) {
> [...]
> }
>
> to replace the statements I added that were like this:
>
> for_each_netdev_rcu(&init_net, slave) {
> if (slave->master == dev) {
> [...]
> }
> }
>
> If so, that totally seems reasonable. If were requesting something
> else, please let me know.
Yes, some helper that walks the device list and tries to find
a device whose ->master matches 'dev'.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: fix build error
From: David Miller @ 2011-11-24 5:42 UTC (permalink / raw)
To: axel.lin; +Cc: linux-kernel, buytenh, netdev
In-Reply-To: <1322106438.16201.11.camel@phoenix>
From: Axel Lin <axel.lin@gmail.com>
Date: Thu, 24 Nov 2011 11:47:18 +0800
> Fix below build error:
> CC drivers/net/ethernet/marvell/mv643xx_eth.o
> drivers/net/ethernet/marvell/mv643xx_eth.c: In function 'mv643xx_eth_get_drvinfo':
> drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: 'info' undeclared (first use in this function)
> drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: (Each undeclared identifier is reported only once
> drivers/net/ethernet/marvell/mv643xx_eth.c:1505: error: for each function it appears in.)
> make[4]: *** [drivers/net/ethernet/marvell/mv643xx_eth.o] Error 1
>
> Signed-off-by: Axel Lin <axel.lin@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: slub: use irqsafe_cpu_cmpxchg for put_cpu_partial
From: Pekka Enberg @ 2011-11-24 6:45 UTC (permalink / raw)
To: Christian Kujau
Cc: Christoph Lameter, Benjamin Herrenschmidt, Eric Dumazet,
Markus Trippelsdorf, Alex,Shi, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Matt Mackall, netdev@vger.kernel.org,
Tejun Heo, David Rientjes
In-Reply-To: <alpine.DEB.2.01.1111231025180.8000@trent.utfs.org>
> On Wed, 23 Nov 2011 at 09:14, Christoph Lameter wrote:
>> I think he only tested the patch that he showed us.
On Wed, Nov 23, 2011 at 8:33 PM, Christian Kujau <lists@nerdbynature.de> wrote:
> Yes, that's the (only) one I tested so far. I did some overnight testing
> (rsync'ing to the external disk again) for 6hrs and ran "slabinfo" every
> 30s during the run: http://nerdbynature.de/bits/3.2.0-rc1/oops/slabinfo-1.txt.xz
>
> The machine is still up & running. So for me, your patch fixes it!
>
> Tested-by: Christian Kujau <lists@nerdbynature.de>
Applied, thanks!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: RAW netfilter - "advanced netfilter setting" or not?
From: Patrick McHardy @ 2011-11-24 7:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Engelhardt, David Miller, Pablo Neira Ayuso, netfilter-devel,
netdev
In-Reply-To: <CA+55aFxPHAf7DDD4cd3ZHNhwdbV4ijSZz83U5=5BzYqgiVKdtg@mail.gmail.com>
On 23.11.2011 23:58, Linus Torvalds wrote:
> On Wed, Nov 23, 2011 at 2:32 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>>
>> Right, but how would you decide what will be enabled/disabled by
>> default? It seems unlikely you will be adding a patch (like Dave's)
>> everytime a default distro installation throws certain errors once
>> you run your own kernel configs.
>
> I do think that "major distributions do this by default" should simply
> be the point for deciding it. Nothing more, nothing less.
Agreed, that's also the criteria we used when we introduced this option.
^ permalink raw reply
* [patch] net/netlabel: copy and paste bug in netlbl_cfg_unlbl_map_add()
From: Dan Carpenter @ 2011-11-24 7:18 UTC (permalink / raw)
To: Paul Moore; +Cc: David S. Miller, netdev, kernel-janitors
This was copy and pasted from the IPv4 code. We're calling the
ip4 version of that function and map4 is NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 8ed67dcc..3735297 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -162,8 +162,8 @@ int netlbl_cfg_unlbl_map_add(const char *domain,
map6->list.addr.s6_addr32[3] &= mask6->s6_addr32[3];
map6->list.mask = *mask6;
map6->list.valid = 1;
- ret_val = netlbl_af4list_add(&map4->list,
- &addrmap->list4);
+ ret_val = netlbl_af6list_add(&map6->list,
+ &addrmap->list6);
if (ret_val != 0)
goto cfg_unlbl_map_add_failure;
break;
^ permalink raw reply related
* [PATCH net] net: Revert ARCNET and PHYLIB to tristate options
From: Ben Hutchings @ 2011-11-24 7:23 UTC (permalink / raw)
To: David Miller; +Cc: Jeff Kirsher, netdev, Debian kernel maintainers
Commit 88491d8103498a6166f70d5999902fec70924314 ("drivers/net: Kconfig
& Makefile cleanup") changed the type of these options to bool, but
they select code that could (and still can) be built as modules.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
I consider the inability to build arcnet.o and libphy.o as modules to be
a regression in 3.2 for general-purpose distribution kernels.
Therefore, please apply this to the net tree.
Ben.
drivers/net/arcnet/Kconfig | 2 +-
drivers/net/phy/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/arcnet/Kconfig b/drivers/net/arcnet/Kconfig
index a73d9dc..84fb634 100644
--- a/drivers/net/arcnet/Kconfig
+++ b/drivers/net/arcnet/Kconfig
@@ -4,7 +4,7 @@
menuconfig ARCNET
depends on NETDEVICES && (ISA || PCI || PCMCIA)
- bool "ARCnet support"
+ tristate "ARCnet support"
---help---
If you have a network card of this type, say Y and check out the
(arguably) beautiful poetry in
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index bb88e12..a702443 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig PHYLIB
- bool "PHY Device support and infrastructure"
+ tristate "PHY Device support and infrastructure"
depends on !S390
depends on NETDEVICES
help
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH v3 03/10] net: Add netdev interfaces recording send/compl
From: Dave Taht @ 2011-11-24 7:30 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, shemminger, netdev
In-Reply-To: <CA+mtBx-VSJ6U2SyUxQt7eK9+cXFFAEQXgmhc+yWwpTX8zd6TJA@mail.gmail.com>
On Thu, Nov 24, 2011 at 1:32 AM, Tom Herbert <therbert@google.com> wrote:
>>> I was referring to the transmit routine, there for netdev_sent_queue()
>>> is always called with one packet.
>>
>> Optimism for the future? :-)
>>
>
> Yep, I am looking forward to the day that someone figures out how to
> batch transmits in a meaningful way!
I liked it in potentia, as wireless likes to aggregate packets into
batches that fit into an AMPDU directed at a single station
and/or TXOP.
not that BQL can help there at present as this happens below the
mac80211 layer, and packets vanish once consumed by the driver.
>
>> But yeah if nobody batches right now, no reason to support this in the
>> interfaces, we can add it later.
>
> Okay.
>
>>
> --
> 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
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
^ permalink raw reply
* Re: [PATCH] net: fsl_pq_mdio: fix oops when using uninitialized mutex
From: Kumar Gala @ 2011-11-24 7:50 UTC (permalink / raw)
To: Andy Fleming; +Cc: Baruch Siach, netdev, linuxppc-dev, Andy Fleming
In-Reply-To: <CAKWjMd5WCx8pSJiL5U_WkD6XA5dSZLgLZkvMA6sjAKNuAz7PKg@mail.gmail.com>
On Nov 9, 2011, at 2:10 PM, Andy Fleming wrote:
>> Fix this by moving the of_mdiobus_register() call earlier.
>>
>> Cc: Andy Fleming <afleming@freescale.com>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 14 +++++++-------
>> 1 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
>> index 52f4e8a..e17fd2f 100644
>> --- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
>> +++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
>> @@ -385,6 +385,13 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
>> tbiaddr = *prop;
>> }
>>
>> + err = of_mdiobus_register(new_bus, np);
>> + if (err) {
>> + printk (KERN_ERR "%s: Cannot register as MDIO bus\n",
>> + new_bus->name);
>> + goto err_free_irqs;
>> + }
>> +
>
>
> This fix totally breaks the point of setting tbipa beforehand.
> mdiobus_register will cause the bus to be scanned, and if any of the
> PHYs are at the default address for tbipa, they won't be found. I have
> a different fix which I will (re)submit today.
What happened here, did you send a patch?
- k
^ permalink raw reply
* [PATCH] macvtap: Fix macvtap_get_queue to use rxhash first
From: Krishna Kumar @ 2011-11-24 8:17 UTC (permalink / raw)
To: arnd; +Cc: Krishna Kumar, mst, netdev, virtualization, levinsasha928, davem
It was reported that the macvtap device selects a
different vhost (when used with multiqueue feature)
for incoming packets of a single connection. Use
packet hash first. Patch tested on MQ virtio_net.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
drivers/net/macvtap.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff -ruNp org/drivers/net/macvtap.c new/drivers/net/macvtap.c
--- org/drivers/net/macvtap.c 2011-10-22 08:38:01.000000000 +0530
+++ new/drivers/net/macvtap.c 2011-11-16 18:34:51.000000000 +0530
@@ -175,6 +175,14 @@ static struct macvtap_queue *macvtap_get
if (!numvtaps)
goto out;
+ /* Check if we can use flow to select a queue */
+ rxq = skb_get_rxhash(skb);
+ if (rxq) {
+ tap = rcu_dereference(vlan->taps[rxq % numvtaps]);
+ if (tap)
+ goto out;
+ }
+
if (likely(skb_rx_queue_recorded(skb))) {
rxq = skb_get_rx_queue(skb);
@@ -186,14 +194,6 @@ static struct macvtap_queue *macvtap_get
goto out;
}
- /* Check if we can use flow to select a queue */
- rxq = skb_get_rxhash(skb);
- if (rxq) {
- tap = rcu_dereference(vlan->taps[rxq % numvtaps]);
- if (tap)
- goto out;
- }
-
/* Everything failed - find first available queue */
for (rxq = 0; rxq < MAX_MACVTAP_QUEUES; rxq++) {
tap = rcu_dereference(vlan->taps[rxq]);
^ permalink raw reply
* [PATCH] virtio_net: Give indication on device probe failure.
From: Krishna Kumar @ 2011-11-24 8:24 UTC (permalink / raw)
To: rusty, mst; +Cc: netdev, levinsasha928, Krishna Kumar, davem
Provide an indication when the virtio_net device fails to
initialize.
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
---
drivers/net/virtio_net.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff -ruNp org/drivers/net/virtio_net.c new/drivers/net/virtio_net.c
--- org/drivers/net/virtio_net.c 2011-11-24 11:53:08.000000000 +0530
+++ new/drivers/net/virtio_net.c 2011-11-24 13:51:32.000000000 +0530
@@ -971,7 +971,7 @@ static void virtnet_config_changed(struc
static int virtnet_probe(struct virtio_device *vdev)
{
- int err;
+ int err = -ENOMEM;
struct net_device *dev;
struct virtnet_info *vi;
struct virtqueue *vqs[3];
@@ -982,7 +982,7 @@ static int virtnet_probe(struct virtio_d
/* Allocate ourselves a network device with room for our info */
dev = alloc_etherdev(sizeof(struct virtnet_info));
if (!dev)
- return -ENOMEM;
+ goto out;
/* Set up network device as normal. */
dev->priv_flags |= IFF_UNICAST_FLT;
@@ -1032,7 +1032,6 @@ static int virtnet_probe(struct virtio_d
vdev->priv = vi;
vi->pages = NULL;
vi->stats = alloc_percpu(struct virtnet_stats);
- err = -ENOMEM;
if (vi->stats == NULL)
goto free;
@@ -1104,6 +1103,8 @@ free_stats:
free_percpu(vi->stats);
free:
free_netdev(dev);
+out:
+ dev_err(&vdev->dev, "Device probe failed with errno: %d\n", err);
return err;
}
^ permalink raw reply
* Re: [PATCH] virtio_net: Give indication on device probe failure.
From: Sasha Levin @ 2011-11-24 8:35 UTC (permalink / raw)
To: Krishna Kumar; +Cc: rusty, mst, netdev, davem
In-Reply-To: <20111124082421.26821.71126.sendpatchset@krkumar2.in.ibm.com>
On Thu, 2011-11-24 at 13:54 +0530, Krishna Kumar wrote:
> Provide an indication when the virtio_net device fails to
> initialize.
>
> Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
> ---
[snip]
You already get a warning from the thingie that probes PCI:
[ 1.166311] virtio_net: probe of virtio1 failed with error -12
--
Sasha.
^ permalink raw reply
* Re: [PATCH 0/6] SUNRPC: make RPC clients use network-namespace-aware PipeFS routines
From: Stanislav Kinsbursky @ 2011-11-24 8:45 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond.Myklebust@netapp.com, linux-nfs@vger.kernel.org,
Pavel Emelianov, neilb@suse.de, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, James Bottomley,
davem@davemloft.net, devel@openvz.org
In-Reply-To: <20111123162711.GA30672@fieldses.org>
23.11.2011 20:27, J. Bruce Fields пишет:
> On Wed, Nov 23, 2011 at 02:51:10PM +0300, Stanislav Kinsbursky wrote:
>> This patch set was created in context of clone of git
>> branch: git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git.
>> tag: v3.1
>>
>> This patch set depends on previous patch sets titled:
>> 1) "SUNRPC: initial part of making pipefs work in net ns"
>> 2) "SUNPRC: cleanup PipeFS for network-namespace-aware users"
>
> Do you have a git tree set up with all of these applied?
>
Hello, Bruce.
You can clone my current working branch from:
git://github.com/skinsbursky/nfs-per-net-ns.git
I'll update it after any significant changes.
There is also web interface:
https://github.com/skinsbursky/nfs-per-net-ns/tree/rpcpipefs_per_netns
--
Best regards,
Stanislav Kinsbursky
^ permalink raw reply
* Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes
From: Steffen Klassert @ 2011-11-24 8:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev
In-Reply-To: <20111124010147.GA15318@gondor.apana.org.au>
On Thu, Nov 24, 2011 at 09:01:47AM +0800, Herbert Xu wrote:
> On Wed, Nov 23, 2011 at 07:17:58PM -0500, David Miller wrote:
> >
> > It means there is a propagation delay of PMTU increasing which is on the
> > order of the number of hops between the sender and the PMTU increased link.
> > So if the PMTU timeout is X, the propagation time is X * N_HOPS.
>
> That assumes that each router in the path would constantly probe
> to refresh its cached value, as otherwise they should all expire
> after X.
Well, it simply got unpredictable how long pmtu propagation takes.
This depends now on the network activity of the routers and on the
individual configuration of the expiration time on each router. With
the original behaviour, we could expect to notice a pmtu increase
if we probe after our timeout X. Now we don't know when this is going
to happen.
Btw. we leak a trigger to check if the learned pmtu information has
expired in our current tree, the learned pmtu informations never
expire. So we are doing good to not propagate our learned pmtu
to other hosts :)
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-24 8:50 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Alex,Shi, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj, dri-devel, Alex Deucher
In-Reply-To: <alpine.DEB.2.00.1111231004490.17317@router.home>
On 2011.11.23 at 10:06 -0600, Christoph Lameter wrote:
> On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
>
> > > FIX idr_layer_cache: Marking all objects used
> >
> > Yesterday I couldn't reproduce the issue at all. But today I've hit
> > exactly the same spot again. (CCing the drm list)
>
> Well this is looks like write after free.
>
> > =============================================================================
> > BUG idr_layer_cache: Poison overwritten
> > -----------------------------------------------------------------------------
> > Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> > Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
>
> And its an integer sized write of 0. If you look at the struct definition
> and lookup the offset you should be able to locate the field that
> was modified.
Here are two more BUGs that seem to point to the same bug:
1)
...
Nov 21 18:30:30 x4 kernel: [drm] radeon: irq initialized.
Nov 21 18:30:30 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072
Nov 21 18:30:30 x4 kernel: [drm] Loading RS780 Microcode
Nov 21 18:30:30 x4 kernel: [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
Nov 21 18:30:30 x4 kernel: radeon 0000:01:05.0: WB enabled
Nov 21 18:30:30 x4 kernel: =============================================================================
Nov 21 18:30:30 x4 kernel: BUG task_xstate: Not a valid slab page
Nov 21 18:30:30 x4 kernel: -----------------------------------------------------------------------------
Nov 21 18:30:30 x4 kernel:
Nov 21 18:30:30 x4 kernel: INFO: Slab 0xffffea0000044300 objects=32767 used=65535 fp=0x (null) flags=0x0401
Nov 21 18:30:30 x4 kernel: Pid: 9, comm: ksoftirqd/1 Not tainted 3.2.0-rc2-00274-g6fe4c6d-dirty #75
Nov 21 18:30:30 x4 kernel: Call Trace:
Nov 21 18:30:30 x4 kernel: [<ffffffff81101c1d>] slab_err+0x7d/0x90
Nov 21 18:30:30 x4 kernel: [<ffffffff8103e29f>] ? dump_trace+0x16f/0x2e0
Nov 21 18:30:30 x4 kernel: [<ffffffff81044764>] ? free_thread_xstate+0x24/0x40
Nov 21 18:30:30 x4 kernel: [<ffffffff81044764>] ? free_thread_xstate+0x24/0x40
Nov 21 18:30:30 x4 kernel: [<ffffffff81102566>] check_slab+0x96/0xc0
Nov 21 18:30:30 x4 kernel: [<ffffffff814c5c29>] free_debug_processing+0x34/0x19c
Nov 21 18:30:30 x4 kernel: [<ffffffff81101d9a>] ? set_track+0x5a/0x190
Nov 21 18:30:30 x4 kernel: [<ffffffff8110cf2b>] ? sys_open+0x1b/0x20
Nov 21 18:30:30 x4 kernel: [<ffffffff814c5e55>] __slab_free+0x33/0x2d0
Nov 21 18:30:30 x4 kernel: [<ffffffff8110cf2b>] ? sys_open+0x1b/0x20
Nov 21 18:30:30 x4 kernel: [<ffffffff81105134>] kmem_cache_free+0x104/0x120
Nov 21 18:30:30 x4 kernel: [<ffffffff81044764>] free_thread_xstate+0x24/0x40
Nov 21 18:30:30 x4 kernel: [<ffffffff81044794>] free_thread_info+0x14/0x30
Nov 21 18:30:30 x4 kernel: [<ffffffff8106a4ff>] free_task+0x2f/0x50
Nov 21 18:30:30 x4 kernel: [<ffffffff8106a5d0>] __put_task_struct+0xb0/0x110
Nov 21 18:30:30 x4 kernel: [<ffffffff8106eb4b>] delayed_put_task_struct+0x3b/0xa0
Nov 21 18:30:30 x4 kernel: [<ffffffff810aa01a>] __rcu_process_callbacks+0x12a/0x350
Nov 21 18:30:30 x4 kernel: [<ffffffff810aa2a2>] rcu_process_callbacks+0x62/0x140
Nov 21 18:30:30 x4 kernel: [<ffffffff81072e18>] __do_softirq+0xa8/0x200
Nov 21 18:30:30 x4 kernel: [<ffffffff81073077>] run_ksoftirqd+0x107/0x210
Nov 21 18:30:30 x4 kernel: [<ffffffff81072f70>] ? __do_softirq+0x200/0x200
Nov 21 18:30:30 x4 kernel: [<ffffffff8108bb87>] kthread+0x87/0x90
Nov 21 18:30:30 x4 kernel: [<ffffffff814cdcf4>] kernel_thread_helper+0x4/0x10
Nov 21 18:30:30 x4 kernel: [<ffffffff8108bb00>] ? kthread_flush_work_fn+0x10/0x10
Nov 21 18:30:30 x4 kernel: [<ffffffff814cdcf0>] ? gs_change+0xb/0xb
Nov 21 18:30:30 x4 kernel: FIX task_xstate: Object at 0xffffffff8110cf2b not freed
Nov 21 18:30:30 x4 kernel: [drm] ring test succeeded in 1 usecs
Nov 21 18:30:30 x4 kernel: [drm] radeon: ib pool ready.
Nov 21 18:30:30 x4 kernel: [drm] ib test succeeded in 0 usecs
Nov 21 18:30:30 x4 kernel: [drm] Radeon Display Connectors
Nov 21 18:30:30 x4 kernel: [drm] Connector 0
2)
...
Nov 21 17:04:38 x4 kernel: fbcon: radeondrmfb (fb0) is primary device
Nov 21 17:04:38 x4 kernel: Console: switching to colour frame buffer device 131x105
Nov 21 17:04:38 x4 kernel: fb0: radeondrmfb frame buffer device
Nov 21 17:04:38 x4 kernel: drm: registered panic notifier
Nov 21 17:04:38 x4 kernel: [drm] Initialized radeon 2.11.0 20080528 for 0000:01:05.0 on minor 0
Nov 21 17:04:38 x4 kernel: loop: module loaded
Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: version 3.0
Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
Nov 21 17:04:38 x4 kernel: ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc
Nov 21 17:04:38 x4 kernel: scsi0 : ahci
Nov 21 17:04:38 x4 kernel: scsi1 : ahci
Nov 21 17:04:38 x4 kernel: =============================================================================
Nov 21 17:04:38 x4 kernel: BUG task_struct: Poison overwritten
Nov 21 17:04:38 x4 kernel: -----------------------------------------------------------------------------
Nov 21 17:04:38 x4 kernel:
Nov 21 17:04:38 x4 kernel: INFO: 0xffff880215c43800-0xffff880215c43803. First byte 0x0 instead of 0x6b
Nov 21 17:04:38 x4 kernel: INFO: Allocated in copy_process+0xc4/0xf60 age=168 cpu=1 pid=5
Nov 21 17:04:38 x4 kernel: __slab_alloc.constprop.70+0x1a4/0x1e0
Nov 21 17:04:38 x4 kernel: kmem_cache_alloc+0x126/0x160
Nov 21 17:04:38 x4 kernel: copy_process+0xc4/0xf60
Nov 21 17:04:38 x4 kernel: do_fork+0x100/0x2b0
Nov 21 17:04:38 x4 kernel: kernel_thread+0x6c/0x70
Nov 21 17:04:38 x4 kernel: __call_usermodehelper+0x31/0xa0
Nov 21 17:04:38 x4 kernel: process_one_work+0x11a/0x430
Nov 21 17:04:38 x4 kernel: worker_thread+0x126/0x2d0
Nov 21 17:04:38 x4 kernel: kthread+0x87/0x90
Nov 21 17:04:38 x4 kernel: kernel_thread_helper+0x4/0x10
Nov 21 17:04:38 x4 kernel: INFO: Freed in free_task+0x3e/0x50 age=156 cpu=2 pid=13
Nov 21 17:04:38 x4 kernel: __slab_free+0x33/0x2d0
Nov 21 17:04:38 x4 kernel: kmem_cache_free+0x104/0x120
Nov 21 17:04:38 x4 kernel: free_task+0x3e/0x50
Nov 21 17:04:38 x4 kernel: __put_task_struct+0xb0/0x110
Nov 21 17:04:38 x4 kernel: delayed_put_task_struct+0x3b/0xa0
Nov 21 17:04:38 x4 kernel: __rcu_process_callbacks+0x12a/0x350
Nov 21 17:04:38 x4 kernel: rcu_process_callbacks+0x62/0x140
Nov 21 17:04:38 x4 kernel: __do_softirq+0xa8/0x200
Nov 21 17:04:38 x4 kernel: run_ksoftirqd+0x107/0x210
Nov 21 17:04:38 x4 kernel: kthread+0x87/0x90
Nov 21 17:04:38 x4 kernel: kernel_thread_helper+0x4/0x10
Nov 21 17:04:38 x4 kernel: INFO: Slab 0xffffea0008571000 objects=17 used=17 fp=0x (null) flags=0x4000000000004080
Nov 21 17:04:38 x4 kernel: INFO: Object 0xffff880215c432c0 @offset=12992 fp=0xffff880215c41d00
Nov 21 17:04:38 x4 kernel:
Nov 21 17:04:38 x4 kernel: Bytes b4 ffff880215c432b0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Nov 21 17:04:38 x4 kernel: Object ffff880215c432c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
...
Nov 21 17:04:38 x4 kernel: Object ffff880215c437f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c43890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Nov 21 17:04:38 x4 kernel: Object ffff880215c438a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Nov 21 17:04:38 x4 kernel: Redzone ffff880215c438b0: bb bb bb bb bb bb bb bb ........
Nov 21 17:04:38 x4 kernel: Padding ffff880215c439f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Nov 21 17:04:38 x4 kernel: Pid: 5, comm: kworker/u:0 Not tainted 3.2.0-rc2-00274-g6fe4c6d #72
Nov 21 17:04:38 x4 kernel: Call Trace:
Nov 21 17:04:38 x4 kernel: [<ffffffff81101ca8>] ? print_section+0x38/0x40
Nov 21 17:04:38 x4 kernel: [<ffffffff811021a3>] print_trailer+0xe3/0x150
Nov 21 17:04:38 x4 kernel: [<ffffffff811023a0>] check_bytes_and_report+0xe0/0x100
Nov 21 17:04:38 x4 kernel: [<ffffffff81103196>] check_object+0x1c6/0x240
Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] ? copy_process+0xc4/0xf60
Nov 21 17:04:38 x4 kernel: [<ffffffff814c5bb3>] alloc_debug_processing+0x62/0xe4
Nov 21 17:04:38 x4 kernel: [<ffffffff814c6461>] __slab_alloc.constprop.70+0x1a4/0x1e0
Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] ? copy_process+0xc4/0xf60
Nov 21 17:04:38 x4 kernel: [<ffffffff814ca12a>] ? schedule+0x3a/0x50
Nov 21 17:04:38 x4 kernel: [<ffffffff81104d66>] kmem_cache_alloc+0x126/0x160
Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] ? copy_process+0xc4/0xf60
Nov 21 17:04:38 x4 kernel: [<ffffffff81065f18>] ? enqueue_task_fair+0xf8/0x140
Nov 21 17:04:38 x4 kernel: [<ffffffff8106b034>] copy_process+0xc4/0xf60
Nov 21 17:04:38 x4 kernel: [<ffffffff8106c000>] do_fork+0x100/0x2b0
Nov 21 17:04:38 x4 kernel: [<ffffffff810920fd>] ? sched_clock_local+0x1d/0x90
Nov 21 17:04:38 x4 kernel: [<ffffffff81044dec>] kernel_thread+0x6c/0x70
Nov 21 17:04:38 x4 kernel: [<ffffffff81084430>] ? proc_cap_handler+0x180/0x180
Nov 21 17:04:38 x4 kernel: [<ffffffff814cdd30>] ? gs_change+0xb/0xb
Nov 21 17:04:38 x4 kernel: [<ffffffff810845a1>] __call_usermodehelper+0x31/0xa0
Nov 21 17:04:38 x4 kernel: [<ffffffff810869ba>] process_one_work+0x11a/0x430
Nov 21 17:04:38 x4 kernel: [<ffffffff81084570>] ? call_usermodehelper_freeinfo+0x30/0x30
Nov 21 17:04:38 x4 kernel: [<ffffffff81087026>] worker_thread+0x126/0x2d0
Nov 21 17:04:38 x4 kernel: [<ffffffff81086f00>] ? rescuer_thread+0x1f0/0x1f0
Nov 21 17:04:38 x4 kernel: [<ffffffff8108bb87>] kthread+0x87/0x90
Nov 21 17:04:38 x4 kernel: [<ffffffff814cdd34>] kernel_thread_helper+0x4/0x10
Nov 21 17:04:38 x4 kernel: [<ffffffff8108bb00>] ? kthread_flush_work_fn+0x10/0x10
Nov 21 17:04:38 x4 kernel: [<ffffffff814cdd30>] ? gs_change+0xb/0xb
Nov 21 17:04:38 x4 kernel: FIX task_struct: Restoring 0xffff880215c43800-0xffff880215c43803=0x6b
Nov 21 17:04:38 x4 kernel:
Nov 21 17:04:38 x4 kernel: FIX task_struct: Marking all objects used
--
Markus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] can: sja1000_isa: fix "limited range" compiler warnings
From: Wolfgang Grandegger @ 2011-11-24 9:08 UTC (permalink / raw)
To: Netdev; +Cc: linux-can@vger.kernel.org
This patch fixes the compiler warnings: "comparison is always
false due to limited range of data type" by using "0xff" instead
of "-1" for unsigned values.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/net/can/sja1000/sja1000_isa.c | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/can/sja1000/sja1000_isa.c b/drivers/net/can/sja1000/sja1000_isa.c
index 496223e..f0840d5 100644
--- a/drivers/net/can/sja1000/sja1000_isa.c
+++ b/drivers/net/can/sja1000/sja1000_isa.c
@@ -44,9 +44,9 @@ static unsigned long port[MAXDEV];
static unsigned long mem[MAXDEV];
static int __devinitdata irq[MAXDEV];
static int __devinitdata clk[MAXDEV];
-static char __devinitdata cdr[MAXDEV] = {[0 ... (MAXDEV - 1)] = -1};
-static char __devinitdata ocr[MAXDEV] = {[0 ... (MAXDEV - 1)] = -1};
-static char __devinitdata indirect[MAXDEV] = {[0 ... (MAXDEV - 1)] = -1};
+static unsigned char __devinitdata cdr[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
+static unsigned char __devinitdata ocr[MAXDEV] = {[0 ... (MAXDEV - 1)] = 0xff};
+static int __devinitdata indirect[MAXDEV] = {[0 ... (MAXDEV - 1)] = -1};
module_param_array(port, ulong, NULL, S_IRUGO);
MODULE_PARM_DESC(port, "I/O port number");
@@ -54,7 +54,7 @@ MODULE_PARM_DESC(port, "I/O port number");
module_param_array(mem, ulong, NULL, S_IRUGO);
MODULE_PARM_DESC(mem, "I/O memory address");
-module_param_array(indirect, byte, NULL, S_IRUGO);
+module_param_array(indirect, int, NULL, S_IRUGO);
MODULE_PARM_DESC(indirect, "Indirect access via address and data port");
module_param_array(irq, int, NULL, S_IRUGO);
@@ -189,17 +189,17 @@ static int __devinit sja1000_isa_probe(struct device *pdev, unsigned int idx)
else
priv->can.clock.freq = CLK_DEFAULT / 2;
- if (ocr[idx] != -1)
- priv->ocr = ocr[idx] & 0xff;
- else if (ocr[0] != -1)
- priv->ocr = ocr[0] & 0xff;
+ if (ocr[idx] != 0xff)
+ priv->ocr = ocr[idx];
+ else if (ocr[0] != 0xff)
+ priv->ocr = ocr[0];
else
priv->ocr = OCR_DEFAULT;
- if (cdr[idx] != -1)
- priv->cdr = cdr[idx] & 0xff;
- else if (cdr[0] != -1)
- priv->cdr = cdr[0] & 0xff;
+ if (cdr[idx] != 0xff)
+ priv->cdr = cdr[idx];
+ else if (cdr[0] != 0xff)
+ priv->cdr = cdr[0];
else
priv->cdr = CDR_DEFAULT;
--
1.7.4.1
^ permalink raw reply related
* [PATCH] ipv4: remove useless codes in ipmr_device_event()
From: roy.qing.li @ 2011-11-24 9:10 UTC (permalink / raw)
To: netdev
From: RongQing.Li <roy.qing.li@gmail.com>
Commit 7dc00c82 added a 'notify' parameter for vif_delete() to
distinguish whether to unregister the device.
When notify=1 means we does not need to unregister the device,
so calling unregister_netdevice_many is useless.
Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
---
net/ipv4/ipmr.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 76a7f07..8e54490 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1520,7 +1520,6 @@ static int ipmr_device_event(struct notifier_block *this, unsigned long event, v
struct mr_table *mrt;
struct vif_device *v;
int ct;
- LIST_HEAD(list);
if (event != NETDEV_UNREGISTER)
return NOTIFY_DONE;
@@ -1529,10 +1528,9 @@ static int ipmr_device_event(struct notifier_block *this, unsigned long event, v
v = &mrt->vif_table[0];
for (ct = 0; ct < mrt->maxvif; ct++, v++) {
if (v->dev == dev)
- vif_delete(mrt, ct, 1, &list);
+ vif_delete(mrt, ct, 1, NULL);
}
}
- unregister_netdevice_many(&list);
return NOTIFY_DONE;
}
--
1.7.1
^ 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