* Re: [PATCH net-next] bnx2x: Add Nic partitioning mode (57712 devices)
From: Dimitris Michailidis @ 2010-12-06 18:21 UTC (permalink / raw)
To: Matt Domsch
Cc: Eilon Greenstein, Dmitry Kravkov, davem@davemloft.net,
netdev@vger.kernel.org, narendra_k@dell.com,
jordan_hargrave@dell.com
In-Reply-To: <20101206173534.GC13628@auslistsprd01.us.dell.com>
Matt Domsch wrote:
> For SR-IOV, biosdevname follows the physfn and virtfn* pointers to map
> VFs to the PF.
This gives the PF a VF maps to but in general doesn't say anything about the
port the VF maps to, unless you make additional assumptions as below.
> But it assumes 1 PF -> 1 port. For the Intel 1GbE and
> 10GbE cards I have, this is true, but nothing says it has to be true.
Yes, there are devices for which this isn't true. You can have several PFs
mapping to 1 port, 1 PF mapping to several ports, a PF mapping to some
port(s) but its VFs mapping to different port(s), ...
> Maybe something like:
>
> /sys/class/net_port/<port_name>/<ifname> -> /sys/class/net/<ifname>
>
> /sys/class/net/<ifname>/port -> /sys/class/net_port/<port_name>
>
> This introduces the idea of ports, though adds the complication of
> needing to name them somehow. But it would expose the relationship of
> each net interface to a specific port, as well as allow multiple
> interfaces per port, conceptually independent of the PCI device
> mapping. That way, each driver, which must know the mapping somehow,
> could fill these links out?
/sys/class/net/<ifname>/dev_id indicates the physical port <ifname> is
associated with. At least a few drivers set up dev_id this way.
^ permalink raw reply
* Re: [PATCH 2/2] bluetooth: Use printf extension %pMbt
From: Gustavo F. Padovan @ 2010-12-06 18:15 UTC (permalink / raw)
To: Joe Perches
Cc: Marcel Holtmann, netdev, David S. Miller, linux-bluetooth,
linux-kernel
In-Reply-To: <b966e9510dec12556a3d1313b026cb2c8281e4d6.1291419007.git.joe@perches.com>
Hi Joe,
* Joe Perches <joe@perches.com> [2010-12-03 18:33:04 -0800]:
> Save some text and bss.
> Remove function batostr so there's no possibility of bad output.
>
> from the net/bluetooth directory:
>
> $ size built-in.o.*
> text data bss dec hex filename
> 293562 16265 70088 379915 5cc0b built-in.o.allyesconfig.new
> 294619 16269 70480 381368 5d1b8 built-in.o.allyesconfig.old
> 30359 772 56 31187 79d3 built-in.o.btonly.new
> 30555 776 92 31423 7abf built-in.o.btonly.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> net/bluetooth/bnep/core.c | 3 +--
> net/bluetooth/cmtp/core.c | 2 +-
> net/bluetooth/hci_conn.c | 6 +++---
> net/bluetooth/hci_core.c | 8 ++++----
> net/bluetooth/hci_event.c | 6 +++---
> net/bluetooth/hci_sysfs.c | 10 +++++-----
> net/bluetooth/hidp/core.c | 4 ++--
> net/bluetooth/l2cap.c | 19 +++++++++----------
> net/bluetooth/lib.c | 14 --------------
> net/bluetooth/rfcomm/core.c | 16 ++++++++--------
> net/bluetooth/rfcomm/sock.c | 8 ++++----
> net/bluetooth/rfcomm/tty.c | 6 +++---
> net/bluetooth/sco.c | 12 ++++++------
> 13 files changed, 49 insertions(+), 65 deletions(-)
This patch doesn't apply to the bluetooth-next-2.6 tree. Can you please rebase
it against the bluetooth-next-2.6 tree? The tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 1/2] vsprintf: Add %pMbt, bluetooth mac address
From: Gustavo F. Padovan @ 2010-12-06 18:11 UTC (permalink / raw)
To: Joe Perches; +Cc: Marcel Holtmann, linux-kernel, netdev
In-Reply-To: <a33a0b00eeb29713a08d91156cbb2d816176f990.1291419007.git.joe@perches.com>
Hi Joe,
* Joe Perches <joe@perches.com> [2010-12-03 18:33:03 -0800]:
> Bluetooth output the MAC address in reverse order.
> Bluetooth memory order: 00 01 02 03 04 05 is output "05:04:03:02:01:00".
>
> This can save overall text when bluetooth is compiled in.
>
> Bluetooth currently uses a very slightly unsafe local function (batostr)
> to output these formatted addresses.
>
> Adding %pMbt allows the batostr function to be removed.
>
> For x86:
>
> $ size lib/vsprintf*.o*
> text data bss dec hex filename
> 8189 0 2 8191 1fff lib/vsprintf.o.defconfig.new
> 8150 0 2 8152 1fd8 lib/vsprintf.o.defconfig.old
> 18633 56 3936 22625 5861 lib/vsprintf.o.allyesconfig.new
> 18571 56 3920 22547 5813 lib/vsprintf.o.allyesconfig.old
>
> Signed-off-by: Joe Perches <joe@perches.com>
Looks good to me.
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [RFC] mark devices with broken LRO implementation
From: Stephen Hemminger @ 2010-12-06 17:58 UTC (permalink / raw)
To: David Miller, Yevgeny Petrilin; +Cc: olof, leitao, eli, netdev
In-Reply-To: <20101206.092855.193714367.davem@davemloft.net>
On Mon, 06 Dec 2010 09:28:55 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Olof Johansson <olof@lixom.net>
> Date: Mon, 6 Dec 2010 11:18:16 -0600
>
> > On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
> >> The kernel uses dev_disable_lro to disable Large Receive Offload
> >> for cases where it is inappropriate. But several drivers do not implement
> >> the required hook. This is a "penalty box" patch to encourage those
> >> drivers to add support for the necessary ethtool set_flags.
> >>
> >> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > pasemi_mac:
> >
> > Acked-by: Olof Johansson <olof@lixom.net>
> >
> >> I only found three drivers that are broken. Normally, I would just fix
> >> them; but since changing state in the device is hardware specific, and
> >> I don't have the hardware or specs to do anything useful to fix it.
> >
> > Thanks. All my hardware is currently in storage due to my relocation, but
> > I'll take a look at it when I have something to run on back. :-)
>
> I don't think we can do what this patch does.
>
> It serves no purpose, as it just means the user is going to have an
> extra headache to turn their driver on.
>
> And %99 of them won't see it, the distribution folks will.
>
> So this is all for nothing.
>
> Better to just work on fixing the problem in the few drivers for
> which the issue exists.
>
> And I'm always happy to receive patches that just plain rip LRO
> support out of such drivers. That's a real legitimate patch unlike
> this one because it keeps the user able to get their driver enabled
> with no fuss and it removes only the improperly functioning feature.
I am less worried about the drivers for embedded devices, the one that
surprises me the mellanox driver. But it looks like that driver doesn't
really do LRO (only GRO).
Subject: mlx4: remove reference to LRO
This device does not do LRO, the current version does GRO.
This patch removes unused inline and changes the configuration
and comments to reflect that. Compile tested only.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/Kconfig | 1 -
drivers/net/mlx4/en_rx.c | 6 +++---
drivers/net/mlx4/mlx4_en.h | 17 -----------------
3 files changed, 3 insertions(+), 21 deletions(-)
--- a/drivers/net/Kconfig 2010-12-06 09:49:11.210488154 -0800
+++ b/drivers/net/Kconfig 2010-12-06 09:49:45.461406671 -0800
@@ -2859,7 +2859,6 @@ config MLX4_EN
tristate "Mellanox Technologies 10Gbit Ethernet support"
depends on PCI && INET
select MLX4_CORE
- select INET_LRO
help
This driver supports Mellanox Technologies ConnectX Ethernet
devices.
--- a/drivers/net/mlx4/en_rx.c 2010-12-06 09:51:38.316270948 -0800
+++ b/drivers/net/mlx4/en_rx.c 2010-12-06 09:51:55.758024934 -0800
@@ -584,7 +584,7 @@ int mlx4_en_process_rx_cq(struct net_dev
if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
(cqe->checksum == cpu_to_be16(0xffff))) {
priv->port_stats.rx_chksum_good++;
- /* This packet is eligible for LRO if it is:
+ /* This packet is eligible for GRO if it is:
* - DIX Ethernet (type interpretation)
* - TCP/IP (v4)
* - without IP options
@@ -616,7 +616,7 @@ int mlx4_en_process_rx_cq(struct net_dev
goto next;
}
- /* LRO not possible, complete processing here */
+ /* GRO not possible, complete processing here */
ip_summed = CHECKSUM_UNNECESSARY;
} else {
ip_summed = CHECKSUM_NONE;
@@ -657,7 +657,7 @@ next:
cqe = &cq->buf[index];
if (++polled == budget) {
/* We are here because we reached the NAPI budget -
- * flush only pending LRO sessions */
+ * flush only pending GRO sessions */
goto out;
}
}
--- a/drivers/net/mlx4/mlx4_en.h 2010-12-06 09:50:40.142348439 -0800
+++ b/drivers/net/mlx4/mlx4_en.h 2010-12-06 09:51:59.470397030 -0800
@@ -83,8 +83,6 @@
#define MLX4_EN_ALLOC_ORDER 2
#define MLX4_EN_ALLOC_SIZE (PAGE_SIZE << MLX4_EN_ALLOC_ORDER)
-#define MLX4_EN_MAX_LRO_DESCRIPTORS 32
-
/* Receive fragment sizes; we use at most 4 fragments (for 9600 byte MTU
* and 4K allocations) */
enum {
@@ -268,21 +266,6 @@ struct mlx4_en_rx_ring {
unsigned long packets;
};
-
-static inline int mlx4_en_can_lro(__be16 status)
-{
- return (status & cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
- MLX4_CQE_STATUS_IPV4F |
- MLX4_CQE_STATUS_IPV6 |
- MLX4_CQE_STATUS_IPV4OPT |
- MLX4_CQE_STATUS_TCP |
- MLX4_CQE_STATUS_UDP |
- MLX4_CQE_STATUS_IPOK)) ==
- cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
- MLX4_CQE_STATUS_IPOK |
- MLX4_CQE_STATUS_TCP);
-}
-
struct mlx4_en_cq {
struct mlx4_cq mcq;
struct mlx4_hwq_resources wqres;
^ permalink raw reply
* Re: [PATCH] use total_highpages when calculating lowmem-only allocation sizes (dccp)
From: David Miller @ 2010-12-06 17:36 UTC (permalink / raw)
To: JBeulich; +Cc: netdev, akpm
In-Reply-To: <4CFD2096020000780002627B@vpn.id2.novell.com>
From: "Jan Beulich" <JBeulich@novell.com>
Date: Mon, 06 Dec 2010 16:42:46 +0000
> For those (large) table allocations that come only from lowmem, the
> total amount of memory shouldn't really matter.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
Instead of continually tweaking the bits in these code paths,
we should be converting them over to using a central routine
such as alloc_large_system_hash() where the logic is consolidated
_AND_ the code knows to use vmalloc() and NUMA aware allocations
when warranted.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Add Nic partitioning mode (57712 devices)
From: Matt Domsch @ 2010-12-06 17:35 UTC (permalink / raw)
To: Eilon Greenstein
Cc: Dmitry Kravkov, davem@davemloft.net, netdev@vger.kernel.org,
narendra_k@dell.com, jordan_hargrave@dell.com
In-Reply-To: <1291023192.9770.0.camel@lb-tlvb-eilong.il.broadcom.com>
On Mon, Nov 29, 2010 at 11:33:12AM +0200, Eilon Greenstein wrote:
> The main difference here is that we are talking about multiple PFs - so
> each can be brought up or down independently of the others. So there is
> no one master PF that controls the port and once it is brought down, the
> port is down too. At any given moment, one of the PFs is acting as the
> port master and controls the shared HW - but once this PF is brought
> down, another PF is seamlessly taking over.
Hmm, that complicates things a bit.
> I think the main difference is that we have real PCI functions and not
> virtual ones. On the same PCI bus, we have two physical ports, and 8
> physical functions - 4 on each port. I agree that exposing which
> functions are using the same port can really help - so I'm open to
> suggestions on the "how".
We really need, for NPAR, SR-IOV, and the Chelsio
multiple-ports-per-PCI-device model, a "network port" abstraction in
sysfs. We need the ability to map M ports to N PCI devices, and
expose that mapping in sysfs.
For SR-IOV, biosdevname follows the physfn and virtfn* pointers to map
VFs to the PF. But it assumes 1 PF -> 1 port. For the Intel 1GbE and
10GbE cards I have, this is true, but nothing says it has to be true.
Maybe something like:
/sys/class/net_port/<port_name>/<ifname> -> /sys/class/net/<ifname>
/sys/class/net/<ifname>/port -> /sys/class/net_port/<port_name>
This introduces the idea of ports, though adds the complication of
needing to name them somehow. But it would expose the relationship of
each net interface to a specific port, as well as allow multiple
interfaces per port, conceptually independent of the PCI device
mapping. That way, each driver, which must know the mapping somehow,
could fill these links out?
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH] ehea: add the correct LRO status at dev->features
From: David Miller @ 2010-12-06 17:33 UTC (permalink / raw)
To: leitao; +Cc: shemminger, netdev
In-Reply-To: <4CFD15F6.7040609@linux.vnet.ibm.com>
From: Breno Leitao <leitao@linux.vnet.ibm.com>
Date: Mon, 06 Dec 2010 14:57:26 -0200
> On 12/06/2010 02:48 PM, Stephen Hemminger wrote:
>> On Mon, 6 Dec 2010 14:39:42 -0200
>> leitao@linux.vnet.ibm.com wrote:
>>
>>> Currently ehea is not setting NETIF_F_LRO, and it is not providing
>>> a callback for get_flags on ethtool. This patch fixes it.
>>>
>>> Signed-off-by: Breno Leitao<leitao@linux.vnet.ibm.com>
>>
>> More importantly, ehea does not support set_flags to disable LRO.
> Correct, currently LRO is a module parameter. I have an item in my
> TODO list to implement set_flags, and thus, the LRO scheme.
>
> So, if you prefer I can send this patch with the future set_flags
> ones. But, for now, this patch allows the user to check when LRO is
> enabled. As it is today, it shows that LRO is disabled all the time.
>
> Anyway, you choose what is the best option.
Your options are: 1) send a set_flags patch now 2) rip LRO support
completely out of the ehea driver.
The feature is implemented improperly, and as such we have every right
to forcefully disable it or remove it until it is fixed to function
correctly.
^ permalink raw reply
* Re: PATCH] filter: fix sk_filter rcu handling
From: David Miller @ 2010-12-06 17:29 UTC (permalink / raw)
To: eric.dumazet; +Cc: hagen, xiaosuo, wirelesser, netdev, xemul, stable, paulmck
In-Reply-To: <1291582432.2806.300.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 05 Dec 2010 21:53:52 +0100
> [PATCH] filter: fix sk_filter rcu handling
>
> Pavel Emelyanov tried to fix a race between sk_filter_(de|at)tach and
> sk_clone() in commit 47e958eac280c263397
>
> Problem is we can have several clones sharing a common sk_filter, and
> these clones might want to sk_filter_attach() their own filters at the
> same time, and can overwrite old_filter->rcu, corrupting RCU queues.
>
> We can not use filter->rcu without being sure no other thread could do
> the same thing.
>
> Switch code to a more conventional ref-counting technique : Do the
> atomic decrement immediately and queue one rcu call back when last
> reference is released.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: [RFC] mark devices with broken LRO implementation
From: David Miller @ 2010-12-06 17:28 UTC (permalink / raw)
To: olof; +Cc: shemminger, leitao, eli, netdev
In-Reply-To: <20101206171816.GA25568@lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Mon, 6 Dec 2010 11:18:16 -0600
> On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
>> The kernel uses dev_disable_lro to disable Large Receive Offload
>> for cases where it is inappropriate. But several drivers do not implement
>> the required hook. This is a "penalty box" patch to encourage those
>> drivers to add support for the necessary ethtool set_flags.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> pasemi_mac:
>
> Acked-by: Olof Johansson <olof@lixom.net>
>
>> I only found three drivers that are broken. Normally, I would just fix
>> them; but since changing state in the device is hardware specific, and
>> I don't have the hardware or specs to do anything useful to fix it.
>
> Thanks. All my hardware is currently in storage due to my relocation, but
> I'll take a look at it when I have something to run on back. :-)
I don't think we can do what this patch does.
It serves no purpose, as it just means the user is going to have an
extra headache to turn their driver on.
And %99 of them won't see it, the distribution folks will.
So this is all for nothing.
Better to just work on fixing the problem in the few drivers for
which the issue exists.
And I'm always happy to receive patches that just plain rip LRO
support out of such drivers. That's a real legitimate patch unlike
this one because it keeps the user able to get their driver enabled
with no fuss and it removes only the improperly functioning feature.
^ permalink raw reply
* Re: [RFC] mark devices with broken LRO implementation
From: Olof Johansson @ 2010-12-06 17:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Breno Leitao, Eli Cohen, davem, netdev
In-Reply-To: <20101206091010.036cd78b@nehalam>
On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
> The kernel uses dev_disable_lro to disable Large Receive Offload
> for cases where it is inappropriate. But several drivers do not implement
> the required hook. This is a "penalty box" patch to encourage those
> drivers to add support for the necessary ethtool set_flags.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
pasemi_mac:
Acked-by: Olof Johansson <olof@lixom.net>
> I only found three drivers that are broken. Normally, I would just fix
> them; but since changing state in the device is hardware specific, and
> I don't have the hardware or specs to do anything useful to fix it.
Thanks. All my hardware is currently in storage due to my relocation, but
I'll take a look at it when I have something to run on back. :-)
-Olof
^ permalink raw reply
* [RFC] mark devices with broken LRO implementation
From: Stephen Hemminger @ 2010-12-06 17:10 UTC (permalink / raw)
To: Breno Leitao, Olof Johansson, Eli Cohen; +Cc: davem, netdev
In-Reply-To: <4CFD15F6.7040609@linux.vnet.ibm.com>
The kernel uses dev_disable_lro to disable Large Receive Offload
for cases where it is inappropriate. But several drivers do not implement
the required hook. This is a "penalty box" patch to encourage those
drivers to add support for the necessary ethtool set_flags.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
I only found three drivers that are broken. Normally, I would just fix
them; but since changing state in the device is hardware specific, and
I don't have the hardware or specs to do anything useful to fix it.
--- a/drivers/net/Kconfig 2010-12-06 08:52:30.376926696 -0800
+++ b/drivers/net/Kconfig 2010-12-06 09:02:02.013224592 -0800
@@ -28,6 +28,13 @@ menuconfig NETDEVICES
# that for each of the symbols.
if NETDEVICES
+config BROKEN_LRO
+ bool
+ ---help---
+ Allow drivers with partial Large Receive Offload support. These drivers
+ do not implement the necessary feature of disabling LRO support via
+ the ethtool set_flags operation.
+
config IFB
tristate "Intermediate Functional Block support"
depends on NET_CLS_ACT
@@ -2675,7 +2682,7 @@ config CHELSIO_T4VF
config EHEA
tristate "eHEA Ethernet support"
- depends on IBMEBUS && INET && SPARSEMEM
+ depends on IBMEBUS && INET && SPARSEMEM && BROKEN_LRO
select INET_LRO
---help---
This driver supports the IBM pSeries eHEA ethernet adapter.
@@ -2848,7 +2855,7 @@ config NIU
config PASEMI_MAC
tristate "PA Semi 1/10Gbit MAC"
- depends on PPC_PASEMI && PCI && INET
+ depends on PPC_PASEMI && PCI && INET && BROKEN_LRO
select PHYLIB
select INET_LRO
help
@@ -2857,7 +2864,7 @@ config PASEMI_MAC
config MLX4_EN
tristate "Mellanox Technologies 10Gbit Ethernet support"
- depends on PCI && INET
+ depends on PCI && INET && BROKEN_LRO
select MLX4_CORE
select INET_LRO
help
^ permalink raw reply
* Re: [PATCH] ehea: add the correct LRO status at dev->features
From: Breno Leitao @ 2010-12-06 16:57 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20101206084824.637d6b29@nehalam>
On 12/06/2010 02:48 PM, Stephen Hemminger wrote:
> On Mon, 6 Dec 2010 14:39:42 -0200
> leitao@linux.vnet.ibm.com wrote:
>
>> Currently ehea is not setting NETIF_F_LRO, and it is not providing
>> a callback for get_flags on ethtool. This patch fixes it.
>>
>> Signed-off-by: Breno Leitao<leitao@linux.vnet.ibm.com>
>
> More importantly, ehea does not support set_flags to disable LRO.
Correct, currently LRO is a module parameter. I have an item in my TODO
list to implement set_flags, and thus, the LRO scheme.
So, if you prefer I can send this patch with the future set_flags ones.
But, for now, this patch allows the user to check when LRO is enabled.
As it is today, it shows that LRO is disabled all the time.
Anyway, you choose what is the best option.
Thanks,
Breno
^ permalink raw reply
* Re: [PATCH] ehea: add the correct LRO status at dev->features
From: Stephen Hemminger @ 2010-12-06 16:48 UTC (permalink / raw)
To: leitao; +Cc: davem, netdev
In-Reply-To: <1291653582-14177-1-git-send-email-leitao@linux.vnet.ibm.com>
On Mon, 6 Dec 2010 14:39:42 -0200
leitao@linux.vnet.ibm.com wrote:
> Currently ehea is not setting NETIF_F_LRO, and it is not providing
> a callback for get_flags on ethtool. This patch fixes it.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
More importantly, ehea does not support set_flags to disable LRO.
I will be more blunt. Any device that supports LRO and does
not have the necessary interface to disable it is broken and should
not be used.
--
^ permalink raw reply
* [PATCH] use total_highpages when calculating lowmem-only allocation sizes (sctp)
From: Jan Beulich @ 2010-12-06 16:43 UTC (permalink / raw)
To: netdev; +Cc: akpm
For those (large) table allocations that come only from lowmem, the
total amount of memory shouldn't really matter.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
net/sctp/protocol.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.37-rc4/net/sctp/protocol.c
+++ 2.6.37-rc4-use-totalhigh_pages/net/sctp/protocol.c
@@ -1190,10 +1190,10 @@ SCTP_STATIC __init int sctp_init(void)
/* Size and allocate the association hash table.
* The methodology is similar to that of the tcp hash tables.
*/
- if (totalram_pages >= (128 * 1024))
- goal = totalram_pages >> (22 - PAGE_SHIFT);
+ if (nr_pages >= (128 * 1024))
+ goal = nr_pages >> (22 - PAGE_SHIFT);
else
- goal = totalram_pages >> (24 - PAGE_SHIFT);
+ goal = nr_pages >> (24 - PAGE_SHIFT);
for (order = 0; (1UL << order) < goal; order++)
;
^ permalink raw reply
* [PATCH] use total_highpages when calculating lowmem-only allocation sizes (netlink)
From: Jan Beulich @ 2010-12-06 16:43 UTC (permalink / raw)
To: netdev; +Cc: akpm
For those (large) table allocations that come only from lowmem, the
total amount of memory shouldn't really matter.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
net/netlink/af_netlink.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- linux-2.6.37-rc4/net/netlink/af_netlink.c
+++ 2.6.37-rc4-use-totalhigh_pages/net/netlink/af_netlink.c
@@ -30,6 +30,7 @@
#include <linux/sched.h>
#include <linux/errno.h>
#include <linux/string.h>
+#include <linux/highmem.h>
#include <linux/stat.h>
#include <linux/socket.h>
#include <linux/un.h>
@@ -2127,10 +2128,11 @@ static int __init netlink_proto_init(voi
if (!nl_table)
goto panic;
- if (totalram_pages >= (128 * 1024))
- limit = totalram_pages >> (21 - PAGE_SHIFT);
+ limit = totalram_pages - totalhigh_pages;
+ if (limit >= (128 * 1024))
+ limit >>= 21 - PAGE_SHIFT;
else
- limit = totalram_pages >> (23 - PAGE_SHIFT);
+ limit >>= 23 - PAGE_SHIFT;
order = get_bitmask_order(limit) - 1 + PAGE_SHIFT;
limit = (1UL << order) / sizeof(struct hlist_head);
^ permalink raw reply
* [PATCH] use total_highpages when calculating lowmem-only allocation sizes (netfilter)
From: Jan Beulich @ 2010-12-06 16:43 UTC (permalink / raw)
To: netdev; +Cc: akpm
For those (large) table allocations that come only from lowmem, the
total amount of memory shouldn't really matter.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
net/netfilter/nf_conntrack_core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- linux-2.6.37-rc4/net/netfilter/nf_conntrack_core.c
+++ 2.6.37-rc4-use-totalhigh_pages/net/netfilter/nf_conntrack_core.c
@@ -17,6 +17,7 @@
#include <linux/sched.h>
#include <linux/skbuff.h>
#include <linux/proc_fs.h>
+#include <linux/highmem.h>
#include <linux/vmalloc.h>
#include <linux/stddef.h>
#include <linux/slab.h>
@@ -1398,10 +1399,12 @@ static int nf_conntrack_init_init_net(vo
/* Idea from tcp.c: use 1/16384 of memory. On i386: 32MB
* machine has 512 buckets. >= 1GB machines have 16384 buckets. */
if (!nf_conntrack_htable_size) {
+ unsigned long nr_pages = totalram_pages - totalhigh_pages;
+
nf_conntrack_htable_size
- = (((totalram_pages << PAGE_SHIFT) / 16384)
+ = (((nr_pages << PAGE_SHIFT) / 16384)
/ sizeof(struct hlist_head));
- if (totalram_pages > (1024 * 1024 * 1024 / PAGE_SIZE))
+ if (nr_pages > (1024 * 1024 * 1024 / PAGE_SIZE))
nf_conntrack_htable_size = 16384;
if (nf_conntrack_htable_size < 32)
nf_conntrack_htable_size = 32;
^ permalink raw reply
* [PATCH] use total_highpages when calculating lowmem-only allocation sizes (decnet)
From: Jan Beulich @ 2010-12-06 16:43 UTC (permalink / raw)
To: netdev; +Cc: akpm
For those (large) table allocations that come only from lowmem, the
total amount of memory shouldn't really matter.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
net/decnet/dn_route.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.37-rc4/net/decnet/dn_route.c
+++ 2.6.37-rc4-use-totalhigh_pages/net/decnet/dn_route.c
@@ -69,6 +69,7 @@
#include <linux/slab.h>
#include <net/sock.h>
#include <linux/mm.h>
+#include <linux/highmem.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#include <linux/init.h>
@@ -1762,7 +1763,7 @@ void __init dn_route_init(void)
dn_route_timer.expires = jiffies + decnet_dst_gc_interval * HZ;
add_timer(&dn_route_timer);
- goal = totalram_pages >> (26 - PAGE_SHIFT);
+ goal = (totalram_pages - totalhigh_pages) >> (26 - PAGE_SHIFT);
for(order = 0; (1UL << order) < goal; order++)
/* NOTHING */;
^ permalink raw reply
* [PATCH] use total_highpages when calculating lowmem-only allocation sizes (dccp)
From: Jan Beulich @ 2010-12-06 16:42 UTC (permalink / raw)
To: netdev; +Cc: akpm
For those (large) table allocations that come only from lowmem, the
total amount of memory shouldn't really matter.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
---
net/dccp/proto.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- linux-2.6.37-rc4/net/dccp/proto.c
+++ 2.6.37-rc4-use-totalhigh_pages/net/dccp/proto.c
@@ -14,6 +14,7 @@
#include <linux/types.h>
#include <linux/sched.h>
#include <linux/kernel.h>
+#include <linux/highmem.h>
#include <linux/skbuff.h>
#include <linux/netdevice.h>
#include <linux/in.h>
@@ -1068,10 +1069,11 @@ static int __init dccp_init(void)
*
* The methodology is similar to that of the buffer cache.
*/
- if (totalram_pages >= (128 * 1024))
- goal = totalram_pages >> (21 - PAGE_SHIFT);
+ goal = totalram_pages - totalhigh_pages;
+ if (goal >= (128 * 1024))
+ goal >>= 21 - PAGE_SHIFT;
else
- goal = totalram_pages >> (23 - PAGE_SHIFT);
+ goal >>= 23 - PAGE_SHIFT;
if (thash_entries)
goal = (thash_entries *
^ permalink raw reply
* [PATCH] ehea: add the correct LRO status at dev->features
From: leitao @ 2010-12-06 16:39 UTC (permalink / raw)
To: davem; +Cc: netdev, Breno Leitao
Currently ehea is not setting NETIF_F_LRO, and it is not providing
a callback for get_flags on ethtool. This patch fixes it.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
---
drivers/net/ehea/ehea_ethtool.c | 1 +
drivers/net/ehea/ehea_main.c | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index 75b099c..b0892b0 100644
--- a/drivers/net/ehea/ehea_ethtool.c
+++ b/drivers/net/ehea/ehea_ethtool.c
@@ -273,6 +273,7 @@ const struct ethtool_ops ehea_ethtool_ops = {
.get_ethtool_stats = ehea_get_ethtool_stats,
.get_rx_csum = ehea_get_rx_csum,
.set_settings = ehea_set_settings,
+ .get_flags = ethtool_op_get_flags,
.nway_reset = ehea_nway_reset, /* Restart autonegotiation */
};
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index a84c389..da75846 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -3266,6 +3266,9 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
| NETIF_F_LLTX;
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
+ if (use_lro)
+ dev->features |= NETIF_F_LRO;
+
INIT_WORK(&port->reset_task, ehea_reset_port);
ret = register_netdev(dev);
--
1.7.3.2
^ permalink raw reply related
* Re: echo > 0 .../disable_ipv6 broken in 2.6.37-rc4
From: Brian Haley @ 2010-12-06 16:10 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev, Mahesh Kelkar, Lorenzo Colitti
In-Reply-To: <m17hfnlpe1.fsf@fess.ebiederm.org>
On 12/05/2010 07:24 PM, Eric W. Biederman wrote:
>
> In 2.6.37-rc4 ipv6 can be disabled not enabled.
> The last kernel I have tested and know this works on is 2.6.33.
>
> To reproduce:
> ~ # ip link set lo up
> ~ # ping6 ::1
> PING ::1(::1) 56 data bytes
> 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.026 ms
> ^C
> --- ::1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 782ms
> rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms
> ~ # echo 1 > /proc/sys/net/ipv6/conf/lo/disable_ipv6
> ~ # ping6 ::1
> connect: Network is unreachable
> ~ # echo 0 > /proc/sys/net/ipv6/conf/lo/disable_ipv6
> ~ # ping6 ::1
> connect: Network is unreachable
>
>
> I intend to poke at this a little more but at the moment
> I am drawing a blank at what is going on.
It should just be calling addrconf_notify() with either NETDEV_UP
or NETDEV_DOWN. Does the address not come back? Or the route?
> I intend to keep poking at this but if anyone can figure this out
> before I do I would be greatly appreciative.
I'm pulling the latest tree now, my 2.6.32.24 system is running fine, so
it's something after that.
-Brian
^ permalink raw reply
* Re: NET_NS: unregister_netdevice: waiting for lo to become free (adding ipv6 address to interface)
From: Menil Jean-Philippe @ 2010-12-06 16:08 UTC (permalink / raw)
To: netdev
Cc: Michael Leun, David Lamparter, Eric W. Biederman, Greg KH, davem,
linux-kernel, Alexey Dobriyan, Patrick McHardy
In-Reply-To: <20101024151541.161bf46c@xenia.leun.net>
[-- Attachment #1: Type: text/plain, Size: 11175 bytes --]
Le 24/10/2010 15:15, Michael Leun a écrit :
> On Fri, 22 Oct 2010 19:05:32 +0200
> Michael Leun<lkml20100708@newton.leun.net> wrote:
>
>> On Fri, 22 Oct 2010 14:48:58 +0200
>> David Lamparter<equinox@diac24.net> wrote:
>>
>>> On Thu, Oct 21, 2010 at 05:15:32PM +0200, Michael Leun wrote:
>>>> unfortunately the bug described below originally reported in
>>>> 2.6.35-rcX is still there in 2.6.36.
>>>
>>> can you post your full kernel .config?
>>
>> Please find below.
>>
>>> I'm using network namespaces quite extensively - OpenVPN and IPv6
>>> included - and i haven't hit this bug. That makes it rather likely
>>> it depends on some option difference.
>>
>> I take candidates for options to change for test... ;-)
>>
>> Maybe I will try to strip it down for test towards a minimal config.
>
> Now I have tried a kernel config with almost everything disabled -
> please find below.
>
> If I have overlooked anything I should disable (or if you suggest I
> should not disable, but enable any option) - please tell me.
>
> I've created an ~2.5MB bootable ISO image based on buildroot/busybox
> with this kernel, which also shows this bug (e.g. when run in
> VirtualBox).
>
> If anybody is interested I could send this image as mail attachment or
> provide a download link.
>
> ml@xenia:~> grep -v "^#" .config |grep -v "^ *$"
> CONFIG_X86_32=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf32-i386"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
> CONFIG_GENERIC_CMOS_UPDATE=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_HAVE_LATENCYTOP_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ZONE_DMA=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_IOMAP=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_DEFAULT_IDLE=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_POPULATES_NODE_MAP=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_HAVE_EARLY_RES=y
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_X86_32_LAZY_GS=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
> CONFIG_KTIME_SCALAR=y
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_CONSTRUCTORS=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> CONFIG_LOCALVERSION=""
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_KERNEL_LZMA=y
> CONFIG_TREE_RCU=y
> CONFIG_RCU_FANOUT=32
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=18
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_NAMESPACES=y
> CONFIG_NET_NS=y
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_INITRAMFS_SOURCE=""
> CONFIG_RD_GZIP=y
> CONFIG_RD_BZIP2=y
> CONFIG_RD_LZMA=y
> CONFIG_RD_LZO=y
> CONFIG_SYSCTL=y
> CONFIG_ANON_INODES=y
> CONFIG_UID16=y
> CONFIG_SYSCTL_SYSCALL=y
> CONFIG_KALLSYMS=y
> CONFIG_HOTPLUG=y
> CONFIG_PRINTK=y
> CONFIG_BUG=y
> CONFIG_ELF_CORE=y
> CONFIG_PCSPKR_PLATFORM=y
> CONFIG_BASE_FULL=y
> CONFIG_FUTEX=y
> CONFIG_EPOLL=y
> CONFIG_SIGNALFD=y
> CONFIG_TIMERFD=y
> CONFIG_EVENTFD=y
> CONFIG_SHMEM=y
> CONFIG_AIO=y
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_PERF_EVENTS=y
> CONFIG_VM_EVENT_COUNTERS=y
> CONFIG_PCI_QUIRKS=y
> CONFIG_SLUB_DEBUG=y
> CONFIG_SLUB=y
> CONFIG_HAVE_OPROFILE=y
> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
> CONFIG_HAVE_IOREMAP_PROT=y
> CONFIG_HAVE_KPROBES=y
> CONFIG_HAVE_KRETPROBES=y
> CONFIG_HAVE_OPTPROBES=y
> CONFIG_HAVE_ARCH_TRACEHOOK=y
> CONFIG_HAVE_DMA_ATTRS=y
> CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
> CONFIG_HAVE_DMA_API_DEBUG=y
> CONFIG_HAVE_HW_BREAKPOINT=y
> CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
> CONFIG_HAVE_USER_RETURN_NOTIFIER=y
> CONFIG_HAVE_PERF_EVENTS_NMI=y
> CONFIG_HAVE_GENERIC_DMA_COHERENT=y
> CONFIG_SLABINFO=y
> CONFIG_RT_MUTEXES=y
> CONFIG_BASE_SMALL=0
> CONFIG_BLOCK=y
> CONFIG_LBDAF=y
> CONFIG_IOSCHED_NOOP=y
> CONFIG_DEFAULT_NOOP=y
> CONFIG_DEFAULT_IOSCHED="noop"
> CONFIG_INLINE_SPIN_UNLOCK=y
> CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
> CONFIG_INLINE_READ_UNLOCK=y
> CONFIG_INLINE_READ_UNLOCK_IRQ=y
> CONFIG_INLINE_WRITE_UNLOCK=y
> CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> CONFIG_M586=y
> CONFIG_X86_CPU=y
> CONFIG_X86_INTERNODE_CACHE_SHIFT=5
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_L1_CACHE_SHIFT=5
> CONFIG_X86_XADD=y
> CONFIG_X86_F00F_BUG=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_INVLPG=y
> CONFIG_X86_BSWAP=y
> CONFIG_X86_POPAD_OK=y
> CONFIG_X86_ALIGNMENT_16=y
> CONFIG_X86_MINIMUM_CPU_FAMILY=4
> CONFIG_CPU_SUP_INTEL=y
> CONFIG_CPU_SUP_CYRIX_32=y
> CONFIG_CPU_SUP_AMD=y
> CONFIG_CPU_SUP_CENTAUR=y
> CONFIG_CPU_SUP_TRANSMETA_32=y
> CONFIG_CPU_SUP_UMC_32=y
> CONFIG_DMI=y
> CONFIG_NR_CPUS=1
> CONFIG_PREEMPT_NONE=y
> CONFIG_VM86=y
> CONFIG_HIGHMEM4G=y
> CONFIG_PAGE_OFFSET=0xC0000000
> CONFIG_HIGHMEM=y
> CONFIG_NEED_NODE_MEMMAP_SIZE=y
> CONFIG_ARCH_FLATMEM_ENABLE=y
> CONFIG_ARCH_SPARSEMEM_ENABLE=y
> CONFIG_ARCH_SELECT_MEMORY_MODEL=y
> CONFIG_ILLEGAL_POINTER_VALUE=0
> CONFIG_SELECT_MEMORY_MODEL=y
> CONFIG_SPARSEMEM_MANUAL=y
> CONFIG_SPARSEMEM=y
> CONFIG_HAVE_MEMORY_PRESENT=y
> CONFIG_SPARSEMEM_STATIC=y
> CONFIG_SPLIT_PTLOCK_CPUS=4
> CONFIG_ZONE_DMA_FLAG=1
> CONFIG_BOUNCE=y
> CONFIG_VIRT_TO_BUS=y
> CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
> CONFIG_MTRR=y
> CONFIG_X86_PAT=y
> CONFIG_ARCH_USES_PG_UNCACHED=y
> CONFIG_HZ_1000=y
> CONFIG_HZ=1000
> CONFIG_PHYSICAL_START=0x1000000
> CONFIG_PHYSICAL_ALIGN=0x1000000
> CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
> CONFIG_PCI=y
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_PCI_DOMAINS=y
> CONFIG_ISA_DMA_API=y
> CONFIG_K8_NB=y
> CONFIG_BINFMT_ELF=y
> CONFIG_HAVE_AOUT=y
> CONFIG_HAVE_ATOMIC_IOMAP=y
> CONFIG_NET=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_IP_FIB_HASH=y
> CONFIG_TCP_CONG_CUBIC=y
> CONFIG_DEFAULT_TCP_CONG="cubic"
> CONFIG_IPV6=y
> CONFIG_UEVENT_HELPER_PATH=""
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FW_LOADER=y
> CONFIG_EXTRA_FIRMWARE=""
> CONFIG_HAVE_IDE=y
> CONFIG_SCSI_MOD=y
> CONFIG_NETDEVICES=y
> CONFIG_VETH=y
> CONFIG_INPUT=y
> CONFIG_INPUT_MOUSEDEV=y
> CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
> CONFIG_INPUT_MOUSEDEV_SCREEN_Y=576
> CONFIG_INPUT_KEYBOARD=y
> CONFIG_KEYBOARD_ATKBD=y
> CONFIG_SERIO=y
> CONFIG_SERIO_I8042=y
> CONFIG_SERIO_LIBPS2=y
> CONFIG_VT=y
> CONFIG_CONSOLE_TRANSLATIONS=y
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_DEVPORT=y
> CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
> CONFIG_SSB_POSSIBLE=y
> CONFIG_VGA_ARB=y
> CONFIG_VGA_ARB_MAX_GPUS=16
> CONFIG_VGA_CONSOLE=y
> CONFIG_VGACON_SOFT_SCROLLBACK=y
> CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FIRMWARE_MEMMAP=y
> CONFIG_FILE_LOCKING=y
> CONFIG_PROC_FS=y
> CONFIG_PROC_SYSCTL=y
> CONFIG_PROC_PAGE_MONITOR=y
> CONFIG_SYSFS=y
> CONFIG_MSDOS_PARTITION=y
> CONFIG_TRACE_IRQFLAGS_SUPPORT=y
> CONFIG_FRAME_WARN=2048
> CONFIG_DEBUG_BUGVERBOSE=y
> CONFIG_DEBUG_MEMORY_INIT=y
> CONFIG_ARCH_WANT_FRAME_POINTERS=y
> CONFIG_USER_STACKTRACE_SUPPORT=y
> CONFIG_HAVE_FUNCTION_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
> CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
> CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
> CONFIG_HAVE_DYNAMIC_FTRACE=y
> CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
> CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> CONFIG_TRACING_SUPPORT=y
> CONFIG_HAVE_ARCH_KGDB=y
> CONFIG_HAVE_ARCH_KMEMCHECK=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_DOUBLEFAULT=y
> CONFIG_HAVE_MMIOTRACE_SUPPORT=y
> CONFIG_IO_DELAY_TYPE_0X80=0
> CONFIG_IO_DELAY_TYPE_0XED=1
> CONFIG_IO_DELAY_TYPE_UDELAY=2
> CONFIG_IO_DELAY_TYPE_NONE=3
> CONFIG_IO_DELAY_0X80=y
> CONFIG_DEFAULT_IO_DELAY_TYPE=0
> CONFIG_DEFAULT_SECURITY_DAC=y
> CONFIG_DEFAULT_SECURITY=""
> CONFIG_HAVE_KVM=y
> CONFIG_GENERIC_FIND_FIRST_BIT=y
> CONFIG_GENERIC_FIND_NEXT_BIT=y
> CONFIG_GENERIC_FIND_LAST_BIT=y
> CONFIG_ZLIB_INFLATE=y
> CONFIG_LZO_DECOMPRESS=y
> CONFIG_DECOMPRESS_GZIP=y
> CONFIG_DECOMPRESS_BZIP2=y
> CONFIG_DECOMPRESS_LZMA=y
> CONFIG_DECOMPRESS_LZO=y
> CONFIG_HAS_IOMEM=y
> CONFIG_HAS_IOPORT=y
> CONFIG_HAS_DMA=y
> CONFIG_NLATTR=y
>
Hi,
curiously, i'm facing a similar problem in 2.6.36.1
in my container, when i configure ipv6 adress on the interfaces,
everything seems good on the first boot of the host. If i shutdown my
container (lxc), then boot it, i observe the following logs:
Dec 6 17:04:12 suntory.u06.univ-nantes.prive kernel: [ 368.192019]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:04:22 suntory.u06.univ-nantes.prive kernel: [ 378.432018]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:04:32 suntory.u06.univ-nantes.prive kernel: [ 388.672015]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:04:42 suntory.u06.univ-nantes.prive kernel: [ 398.912016]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:04:53 suntory.u06.univ-nantes.prive kernel: [ 409.152016]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:05:03 suntory.u06.univ-nantes.prive kernel: [ 419.392018]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:05:13 suntory.u06.univ-nantes.prive kernel: [ 429.632018]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:05:23 suntory.u06.univ-nantes.prive kernel: [ 439.876016]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:05:34 suntory.u06.univ-nantes.prive kernel: [ 450.116015]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:05:44 suntory.u06.univ-nantes.prive kernel: [ 460.356019]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:05:54 suntory.u06.univ-nantes.prive kernel: [ 470.596020]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:06:04 suntory.u06.univ-nantes.prive kernel: [ 480.836019]
unregister_netdevice: waiting for lo to become free. Usage count = 4
Dec 6 17:06:05 suntory.u06.univ-nantes.prive kernel: [ 481.468021]
INFO: task lxc-start:3805 blocked for more than 120 seconds.
Then i must reboot the host.
The same on kernel 2.6.34, but everything is good on a 2.6.32
Some relvant informations about the kernel:
root@suntory:~# cat /boot/config-2.6.36.1-dsiun-1d | grep -i sysfs
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_ACPI_SYSFS_POWER=y
# CONFIG_WIRELESS_EXT_SYSFS is not set
CONFIG_ISCSI_BOOT_SYSFS=m
CONFIG_RTC_INTF_SYSFS=y
CONFIG_SYSFS=y
root@suntory:~# cat /boot/config-2.6.36.1-dsiun-1d | grep -i net_ns
CONFIG_NET_NS=y
Is there anything in my configuration, i must check in order to get ipv6
working fully in the container?
Regards.
[-- Attachment #2: jean-philippe_menil.vcf --]
[-- Type: text/x-vcard, Size: 377 bytes --]
begin:vcard
fn:Jean-Philippe Menil
n:Menil;Jean-Philippe
org;quoted-printable:Universit=C3=A9 de Nantes;IRTS
adr;quoted-printable:;;2 rue de la Houssini=C3=A8re;Nantes;;44322;France
email;internet:jean-philippe.menil@univ-nantes.fr
title:Reseau
tel;work:02 53 48 49 27
tel;fax:(33)2 51 12 58 60
tel;cell:06 45 38 87 75
url:http://www.cri.univ-nantes.fr
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH 3/5] xfrm: Traffic Flow Confidentiality for IPv4 ESP
From: Herbert Xu @ 2010-12-06 15:22 UTC (permalink / raw)
To: Martin Willi; +Cc: linux-crypto, netdev
In-Reply-To: <1291648225.1954.179.camel@martin>
On Mon, Dec 06, 2010 at 04:10:25PM +0100, Martin Willi wrote:
> >
> > Has this scheme been discussed on a public forum somewhere?
>
> No, sorry, I haven't found much valuable discussion about TFC padding.
> Nothing at all how to overcome the ESPv2 padding limit.
OK.
> I'll re-spin the patchset with get_random_bytes(). Even if the ESPv2
> padding fallback makes TFC in this case less efficient, it shouldn't
> harm. Or do you see this differently?
Indeed I don't think we should do anything for the ESPv2 case
at all without having this discussed in an appropriate forum
first.
So please remove that part completely from your submission for
now.
Thanks,
--
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 3/5] xfrm: Traffic Flow Confidentiality for IPv4 ESP
From: Martin Willi @ 2010-12-06 15:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, netdev
In-Reply-To: <20101203083908.GA2940@gondor.apana.org.au>
Hi Herbert,
> I know why you want to do this, what I'm asking is do you have any
> research behind this with regards to security
>
> Has this scheme been discussed on a public forum somewhere?
No, sorry, I haven't found much valuable discussion about TFC padding.
Nothing at all how to overcome the ESPv2 padding limit.
> using an insecure RNG to generate a value that is then used as the
> basis for concealment
Using get_random_bytes() adds another ~10% processing overhead due to
the underlying sha_transform. But this is probably negligible, we add
much more with the additional padding to encrypt/MAC.
I'll re-spin the patchset with get_random_bytes(). Even if the ESPv2
padding fallback makes TFC in this case less efficient, it shouldn't
harm. Or do you see this differently?
Regards
Martin
^ permalink raw reply
* biosdevname v0.3.2
From: Matt Domsch @ 2010-12-06 14:06 UTC (permalink / raw)
To: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Co
Bugfix update to biosdevname, now version 0.3.2.
The legacy code for reading the PCI IRQ Routing Table ($PIR) and the
PCMCIA information has been removed. This means biosdevname will only
report BIOS-provided names if your system has SMBIOS 2.6 or higher and
has the information in Type 9 or Type 41. This is in preparation for
widespread use, and will keep biosdevname from suggesting names on
systems that are well into or beyond their useful lifetime and
introducing an unexpected change of behavior on them. Dell PowerEdge
10G and newer, HP ProLiant G6 and newer are known to have SMBIOS 2.6,
as do a number of desktop, laptop, and netbook-class systems as
reported on the fedora-devel mailing list.
This release also provides correct names for Intel and Broadcom
quad-port GigE cards that I've tried. Format is pci<slot>#<port>.
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.2.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.2.tar.gz.sign
git://linux.dell.com/biosdevname.git
This is already built in Fedora rawhide (will be 15), and I encourage
other distributions to pick it up as well.
On a related note, I've submitted a patch to dracut upstream to
include calls to biosdevname via udev. This will let us use
BIOS-suggested names for network functionality during initramfs time,
such as finding your root file system on NFS or iSCSI.
Shortlog:
Matt Domsch (7):
only match on smbios_type Ethernet, ignore sysfs index file for now
PIRQ-ectomy, add pci_access pointer to state, pci_dev pointer instead of struct in pci_device
PCMCIA-ectomy
copy SMBIOS slot info to all matching domain/bus/device/functions
skip bridges when setting index_in_slot
fix RPM spec URL
bump version
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [patch 1/1] driver/net/benet: fix be_cmd_multicast_set() memcpy bug
From: Joe Jin @ 2010-12-06 13:00 UTC (permalink / raw)
To: sathyap, subbus, sarveshwarb, ajitk
Cc: netdev, linux-kernel, greg.marsden, guru.anbalagane, joe.jin
Hi,
Regarding benet be_cmd_multicast_set() function, now using
netdev_for_each_mc_addr() helper for mac address copy, but
when copying to req->mac[] did not increase of the index.
Cc: Sathya Perla <sathyap@serverengines.com>
Cc: Subbu Seetharaman <subbus@serverengines.com>
Cc: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Cc: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: Joe Jin <joe.jin@oracle.com>
---
be_cmds.c | 2 +-
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index 36eca1c..e4465d2 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1235,7 +1235,7 @@ int be_cmd_multicast_set(struct be_adapter *adapter, u32 if_id,
i = 0;
netdev_for_each_mc_addr(ha, netdev)
- memcpy(req->mac[i].byte, ha->addr, ETH_ALEN);
+ memcpy(req->mac[i++].byte, ha->addr, ETH_ALEN);
} else {
req->promiscuous = 1;
}
--
Oracle <http://www.oracle.com>
Joe Jin | Team Leader, Software Development | +8610.8278.6295
ORACLE | Linux and Virtualization
Incubator Building 2-A ZPark | Beijing China, 100094
^ 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