Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] net: compute a more reasonable default ip6_rt_max_size
From: Eric Dumazet @ 2012-05-27 13:18 UTC (permalink / raw)
  To: Arun Sharma; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <4FC1A57A.7080807@fb.com>

On Sat, 2012-05-26 at 20:54 -0700, Arun Sharma wrote:
> On 5/25/12 8:39 PM, Eric Dumazet wrote:
> >
> > But your patch is not a  "modest increase", so whats the deal ?
> >
> > A modest increase would be 8192 instead of 4096, regardless of RAM size.
> >
> 
> Yes - 8192 solves our immediate problem, but I was worrying that the 
> problem might resurface as ipv6 adoption becomes more widespread.
> 

Going from 4096 to 8192 is modest increase. If you put 65536, it should
be enough for the next years.

Your patch was increasing 4096 to 524288 (for 2GB of ram), which sounds
not modest at all.

> We were testing a pre-3.0 kernel that didn't have Dave's DST_NOCOUNT 
> patch. Will retest with that patch applied.

Good

> 
>  > More over, a boot parameter to tweak it is absolutely not needed
> 
> Agreed. Will remove that part.
> 
> Still not sure why you'd like to go for one size regardless of 
> totalram_pages.

Because size of IPv6 route table is not depending on RAM size, but on
number or IPv6 routes.

A router runs a piece of software complex enough to be able to adjust
the limit when needed, don't you think so ?

Your patch basically removes the whole idea of having a limit in the
first place. Why do we have a limit if you set it to four order of
magnitudes bigger than necessary ?

^ permalink raw reply

* Re: [PATCH] Bluetooth: Really fix registering hci with duplicate name
From: Marcel Holtmann @ 2012-05-27  7:10 UTC (permalink / raw)
  To: Sasha Levin
  Cc: gustavo-THi1TnShQwVAfugRpC6u6w,
	johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q,
	linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1338060231-31108-1-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hi Sasha,

> Commit fc50744 ("Bluetooth: Fix registering hci with duplicate name") didn't
> fully fix the duplicate naming issue with devices, and duplicate device names
> could still be created:
> 
> [  142.484097] device: 'hci1': device_add
> [...]
> [  150.545263] device: 'hci1': device_add
> [  150.550128] kobject: 'hci1' (ffff880014cc4e58): kobject_add_internal: parent: 'bluetooth', set: 'devices'
> [  150.558979] ------------[ cut here ]------------
> [  150.561438] WARNING: at fs/sysfs/dir.c:529 sysfs_add_one+0xb0/0xd0()
> [  150.572974] Hardware name: Bochs
> [  150.580502] sysfs: cannot create duplicate filename '/devices/virtual/bluetooth/hci1'
> [  150.584444] Pid: 7563, comm: trinity-child1 Tainted: G        W    3.4.0-next-20120524-sasha #296
> [...]
> 
> Instead of the weird logic and the attempt at keeping the device list sorted,
> just use an IDA.
> 
> Signed-off-by: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  net/bluetooth/hci_core.c |   30 ++++++++++++++++--------------
>  1 files changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 9c586fb..eca6dd1 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -26,6 +26,7 @@
>  /* Bluetooth HCI core. */
>  
>  #include <linux/export.h>
> +#include <linux/idr.h>
>  
>  #include <linux/rfkill.h>
>  
> @@ -46,6 +47,9 @@ DEFINE_RWLOCK(hci_dev_list_lock);
>  LIST_HEAD(hci_cb_list);
>  DEFINE_RWLOCK(hci_cb_list_lock);
>  
> +/* HCI ID Numbering */
> +static DEFINE_IDA(hci_index_ida);
> +
>  /* ---- HCI notifications ---- */
>  
>  static void hci_notify(struct hci_dev *hdev, int event)
> @@ -1689,7 +1693,6 @@ EXPORT_SYMBOL(hci_free_dev);
>  /* Register HCI device */
>  int hci_register_dev(struct hci_dev *hdev)
>  {
> -	struct list_head *head, *p;
>  	int id, error;
>  
>  	if (!hdev->open || !hdev->close)
> @@ -1701,25 +1704,19 @@ int hci_register_dev(struct hci_dev *hdev)
>  	 * so the index can be used as the AMP controller ID.
>  	 */
>  	id = (hdev->dev_type == HCI_BREDR) ? 0 : 1;
> -	head = &hci_dev_list;
>  
> -	/* Find first available device id */
> -	list_for_each(p, &hci_dev_list) {
> -		int nid = list_entry(p, struct hci_dev, list)->id;
> -		if (nid > id)
> -			break;
> -		if (nid == id)
> -			id++;
> -		head = p;
> -	}
> +	error = ida_simple_get(&hci_index_ida, id, 0, GFP_KERNEL);
> +	if (error < 0)
> +		return error;
>  
> +	id = error;

I do not really like this "error" thing here.

Why not something simple like this:

	switch (hdev->dev_type) {
	case HCI_BREDR:
		id = ida_simple_get(&hci_index_ida, 0, 0, GFP_KERNEL);
		break;
	case HCI_AMP:
		id = ida_simple_get(&hci_index_idx, 1, 0, GFP_KERNEL);
		break;
	default:
		return -EINVAL;
	}

	if (id < 0)
		return id;

It would have the side effect to also check for valid dev_type at the
same time.

Or just just an extra variable start_id to avoid the "error" naming for
what is expected to be a positive result in almost all cases.

>  	sprintf(hdev->name, "hci%d", id);
>  	hdev->id = id;
>  
>  	BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
>  
> -	list_add(&hdev->list, head);
> -
> +	write_lock(&hci_dev_list_lock);
> +	list_add(&hdev->list, &hci_dev_list);
>  	write_unlock(&hci_dev_list_lock);
>  
>  	hdev->workqueue = alloc_workqueue(hdev->name, WQ_HIGHPRI | WQ_UNBOUND |
> @@ -1755,6 +1752,7 @@ int hci_register_dev(struct hci_dev *hdev)
>  err_wqueue:
>  	destroy_workqueue(hdev->workqueue);
>  err:
> +	ida_simple_remove(&hci_index_ida, hdev->id);
>  	write_lock(&hci_dev_list_lock);
>  	list_del(&hdev->list);
>  	write_unlock(&hci_dev_list_lock);
> @@ -1766,12 +1764,14 @@ EXPORT_SYMBOL(hci_register_dev);
>  /* Unregister HCI device */
>  void hci_unregister_dev(struct hci_dev *hdev)
>  {
> -	int i;
> +	int i, id;
>  
>  	BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
>  
>  	set_bit(HCI_UNREGISTER, &hdev->dev_flags);
>  
> +	id = hdev->id;
> +
>  	write_lock(&hci_dev_list_lock);
>  	list_del(&hdev->list);
>  	write_unlock(&hci_dev_list_lock);
> @@ -1812,6 +1812,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
>  	hci_dev_unlock(hdev);
>  
>  	hci_dev_put(hdev);
> +
> +	ida_simple_remove(&hci_index_ida, id);
>  }
>  EXPORT_SYMBOL(hci_unregister_dev);
>  

Regards

Marcel

^ permalink raw reply

* Re: [PATCH v2] ipv6: fix incorrect ipsec fragment
From: David Miller @ 2012-05-27  5:12 UTC (permalink / raw)
  To: gaofeng; +Cc: netdev, steffen.klassert, lw
In-Reply-To: <1338031853-24938-1-git-send-email-gaofeng@cn.fujitsu.com>

From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Sat, 26 May 2012 19:30:53 +0800

> Since commit ad0081e43a
> "ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
> the fragment of packets is incorrect.
> because tunnel mode needs IPsec headers and trailer for all fragments,
> while on transport mode it is sufficient to add the headers to the
> first fragment and the trailer to the last.
> 
> so modify mtu and maxfraglen base on ipsec mode and if fragment is first
> or last.
> 
> with my test,it work well(every fragment's size is the mtu)
> and does not trigger slow fragment path.
> 
> Changes from v1:
> 	though optimization, mtu_prev and maxfraglen_prev can be delete.
> 	replace xfrm mode codes with dst_entry's new frag DST_XFRM_TUNNEL.
> 	add fuction ip6_append_data_mtu to make codes clearer.
> 
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>

Applied, and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH v4] xfrm: take net hdr len into account for esp payload size calculation
From: David Miller @ 2012-05-27  5:09 UTC (permalink / raw)
  To: bpoirier
  Cc: netdev, kuznet, jmorris, yoshfuji, kaber, linux-kernel,
	steffen.klassert, diego.beltrami
In-Reply-To: <1337895158-23521-1-git-send-email-bpoirier@suse.de>

From: Benjamin Poirier <bpoirier@suse.de>
Date: Thu, 24 May 2012 17:32:38 -0400

> Corrects the function that determines the esp payload size. The calculations
> done in esp{4,6}_get_mtu() lead to overlength frames in transport mode for
> certain mtu values and suboptimal frames for others.
> 
> According to what is done, mainly in esp{,6}_output() and tcp_mtu_to_mss(),
> net_header_len must be taken into account before doing the alignment
> calculation.
> 
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH v7 2/2] decrement static keys on real destroy time
From: David Miller @ 2012-05-27  5:10 UTC (permalink / raw)
  To: glommer
  Cc: akpm, linux-mm, cgroups, devel, kamezawa.hiroyu, netdev, tj,
	lizefan, hannes, mhocko
In-Reply-To: <1337938328-11537-3-git-send-email-glommer@parallels.com>

From: Glauber Costa <glommer@parallels.com>
Date: Fri, 25 May 2012 13:32:08 +0400

 ...
> Signed-off-by: Glauber Costa <glommer@parallels.com>

Acked-by: David S. Miller <davem@davemloft.net>

--
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: [PATCH] net: compute a more reasonable default ip6_rt_max_size
From: Arun Sharma @ 2012-05-27  3:54 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev, linux-kernel
In-Reply-To: <1338003580.10135.6.camel@edumazet-glaptop>

On 5/25/12 8:39 PM, Eric Dumazet wrote:
>
> But your patch is not a  "modest increase", so whats the deal ?
>
> A modest increase would be 8192 instead of 4096, regardless of RAM size.
>

Yes - 8192 solves our immediate problem, but I was worrying that the 
problem might resurface as ipv6 adoption becomes more widespread.

We were testing a pre-3.0 kernel that didn't have Dave's DST_NOCOUNT 
patch. Will retest with that patch applied.

 > More over, a boot parameter to tweak it is absolutely not needed

Agreed. Will remove that part.

Still not sure why you'd like to go for one size regardless of 
totalram_pages.

  -Arun

^ permalink raw reply

* Re: [PATCH 1/2] nfct-extensions/timeout: adjust for changed nfct_timeout_snprintf API
From: spiro @ 2012-05-27  2:35 UTC (permalink / raw)
  To: Pablo Neira Ayuso, netfilter-announce-bounces, Jan Engelhardt
  Cc: netdev, netfilter, netfilter-devel, netfilter-announce
In-Reply-To: <20120526202105.GB452@1984>

remove me from this list and your lists
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Pablo Neira Ayuso <pablo@netfilter.org>
Sender: netfilter-announce-bounces@lists.netfilter.org
Date: Sat, 26 May 2012 22:21:05 
To: Jan Engelhardt<jengelh@inai.de>
Cc: <netdev@vger.kernel.org>; <netfilter@vger.kernel.org>; <netfilter-devel@vger.kernel.org>; <netfilter-announce@lists.netfilter.org>
Subject: Re: [PATCH 1/2] nfct-extensions/timeout: adjust for changed
	nfct_timeout_snprintf API

On Sat, May 26, 2012 at 09:02:34PM +0200, Jan Engelhardt wrote:
> Despite requiring libnetfilter_cttimeout >= 1.0.0, it did not
> use the new API.
> 
> nfct-extensions/timeout.c: In function 'nfct_timeout_cb':
> nfct-extensions/timeout.c:99:2: error: too few arguments to function
> 	'nfct_timeout_snprintf'
> In file included from nfct-extensions/timeout.c:26:0:
> /usr/include/libnetfilter_cttimeout-1.0.0/libnetfilter_cttimeout/
> 	libnetfilter_cttimeout.h:114:5: note: declared here
> 
> 114: int nfct_timeout_snprintf(char *buf, size_t size,
> 	const struct nfct_timeout *, unsigned int type, unsigned int flags);

We noticed at the same time.

It's fixed now, and conntrack-tools 1.2.1 is out. Thanks!


^ permalink raw reply

* I NEED YOUR ASSISTANCE
From: mrleungcheungkong12 @ 2012-05-26 18:18 UTC (permalink / raw)






Hello,
I need your assistance to transfer $22,500,000.00 Dollars from Hong Kong
to your country

^ permalink raw reply

* Re: [PATCH 1/2] nfct-extensions/timeout: adjust for changed nfct_timeout_snprintf API
From: Pablo Neira Ayuso @ 2012-05-26 20:21 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter, netfilter-devel, netfilter-announce, netdev
In-Reply-To: <1338058955-5789-2-git-send-email-jengelh@inai.de>

On Sat, May 26, 2012 at 09:02:34PM +0200, Jan Engelhardt wrote:
> Despite requiring libnetfilter_cttimeout >= 1.0.0, it did not
> use the new API.
> 
> nfct-extensions/timeout.c: In function 'nfct_timeout_cb':
> nfct-extensions/timeout.c:99:2: error: too few arguments to function
> 	'nfct_timeout_snprintf'
> In file included from nfct-extensions/timeout.c:26:0:
> /usr/include/libnetfilter_cttimeout-1.0.0/libnetfilter_cttimeout/
> 	libnetfilter_cttimeout.h:114:5: note: declared here
> 
> 114: int nfct_timeout_snprintf(char *buf, size_t size,
> 	const struct nfct_timeout *, unsigned int type, unsigned int flags);

We noticed at the same time.

It's fixed now, and conntrack-tools 1.2.1 is out. Thanks!

^ permalink raw reply

* Re: [PATCH 2/2] Update .gitignore
From: Pablo Neira Ayuso @ 2012-05-26 20:19 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter, netfilter-devel, netfilter-announce, netdev
In-Reply-To: <1338058955-5789-3-git-send-email-jengelh@inai.de>

Applied, thanks Jan.

On Sat, May 26, 2012 at 09:02:35PM +0200, Jan Engelhardt wrote:
> ---
>  .gitignore     |    1 +
>  src/.gitignore |    1 +
>  2 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> index 928e44b..f7a5fc7 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,5 +1,6 @@
>  .deps/
>  .libs/
> +.dirstamp
>  Makefile
>  Makefile.in
>  *.o
> diff --git a/src/.gitignore b/src/.gitignore
> index 6e6763d..55a0d27 100644
> --- a/src/.gitignore
> +++ b/src/.gitignore
> @@ -1,5 +1,6 @@
>  /conntrack
>  /conntrackd
> +/nfct
>  
>  /read_config_lex.c
>  /read_config_yy.c
> -- 
> 1.7.7
> 

^ permalink raw reply

* Re: [PATCH] STA2X11 CAN: CAN driver for the STA2X11 board
From: Wolfgang Grandegger @ 2012-05-26 19:57 UTC (permalink / raw)
  To: Federico Vaga
  Cc: Marc Kleine-Budde, linux-can, netdev, linux-kernel,
	Giancarlo Asnaghi, Alan Cox
In-Reply-To: <CAH5GJ0rFB4xaR7o-wVR3ze_UogeDW84dehh0rx5z+300ghB4uA@mail.gmail.com>

On 05/26/2012 10:36 AM, Federico Vaga wrote:
>> Thanks for your contribution. At a first glance, this driver looks
>> similar to the pch_can and the c_can driver. It seems that a C_CAN based
>> controller is used on that board as well. If that's true, it should be
>> handled by the C_CAN driver. To get ride of the obsolete pch_can driver,
>> I sent some time ago the patch "[RFC/PATCH] c_can: add driver for the
>> PCH CAN controller":
>>
>>  http://marc.info/?t=132991563600003&r=1&w=4
>>
>> I could serve as base of a generic c_can_pci driver.
> 
> You are right, this is a C-CAN but it isn't specified on the board manual.
> I compared the board manual with the Bosch C-CAN manual, and it is the same.

Like with the Intel EG20T PCH CAN controller.

> I'm working on a PCI module for this board, when it is ready we can think for
> a generic c_can_pci

That would be nice, thanks. You might have realized that AnilKumar has
provided support for the D_CAN controllers to the C_CAN driver which
will show up mainline soon.

Wolfgang.


^ permalink raw reply

* [PATCH] Bluetooth: Really fix registering hci with duplicate name
From: Sasha Levin @ 2012-05-26 19:23 UTC (permalink / raw)
  To: marcel, gustavo, johan.hedberg, davem
  Cc: linux-bluetooth, netdev, linux-kernel, Sasha Levin

Commit fc50744 ("Bluetooth: Fix registering hci with duplicate name") didn't
fully fix the duplicate naming issue with devices, and duplicate device names
could still be created:

[  142.484097] device: 'hci1': device_add
[...]
[  150.545263] device: 'hci1': device_add
[  150.550128] kobject: 'hci1' (ffff880014cc4e58): kobject_add_internal: parent: 'bluetooth', set: 'devices'
[  150.558979] ------------[ cut here ]------------
[  150.561438] WARNING: at fs/sysfs/dir.c:529 sysfs_add_one+0xb0/0xd0()
[  150.572974] Hardware name: Bochs
[  150.580502] sysfs: cannot create duplicate filename '/devices/virtual/bluetooth/hci1'
[  150.584444] Pid: 7563, comm: trinity-child1 Tainted: G        W    3.4.0-next-20120524-sasha #296
[...]

Instead of the weird logic and the attempt at keeping the device list sorted,
just use an IDA.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
---
 net/bluetooth/hci_core.c |   30 ++++++++++++++++--------------
 1 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 9c586fb..eca6dd1 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -26,6 +26,7 @@
 /* Bluetooth HCI core. */
 
 #include <linux/export.h>
+#include <linux/idr.h>
 
 #include <linux/rfkill.h>
 
@@ -46,6 +47,9 @@ DEFINE_RWLOCK(hci_dev_list_lock);
 LIST_HEAD(hci_cb_list);
 DEFINE_RWLOCK(hci_cb_list_lock);
 
+/* HCI ID Numbering */
+static DEFINE_IDA(hci_index_ida);
+
 /* ---- HCI notifications ---- */
 
 static void hci_notify(struct hci_dev *hdev, int event)
@@ -1689,7 +1693,6 @@ EXPORT_SYMBOL(hci_free_dev);
 /* Register HCI device */
 int hci_register_dev(struct hci_dev *hdev)
 {
-	struct list_head *head, *p;
 	int id, error;
 
 	if (!hdev->open || !hdev->close)
@@ -1701,25 +1704,19 @@ int hci_register_dev(struct hci_dev *hdev)
 	 * so the index can be used as the AMP controller ID.
 	 */
 	id = (hdev->dev_type == HCI_BREDR) ? 0 : 1;
-	head = &hci_dev_list;
 
-	/* Find first available device id */
-	list_for_each(p, &hci_dev_list) {
-		int nid = list_entry(p, struct hci_dev, list)->id;
-		if (nid > id)
-			break;
-		if (nid == id)
-			id++;
-		head = p;
-	}
+	error = ida_simple_get(&hci_index_ida, id, 0, GFP_KERNEL);
+	if (error < 0)
+		return error;
 
+	id = error;
 	sprintf(hdev->name, "hci%d", id);
 	hdev->id = id;
 
 	BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
 
-	list_add(&hdev->list, head);
-
+	write_lock(&hci_dev_list_lock);
+	list_add(&hdev->list, &hci_dev_list);
 	write_unlock(&hci_dev_list_lock);
 
 	hdev->workqueue = alloc_workqueue(hdev->name, WQ_HIGHPRI | WQ_UNBOUND |
@@ -1755,6 +1752,7 @@ int hci_register_dev(struct hci_dev *hdev)
 err_wqueue:
 	destroy_workqueue(hdev->workqueue);
 err:
+	ida_simple_remove(&hci_index_ida, hdev->id);
 	write_lock(&hci_dev_list_lock);
 	list_del(&hdev->list);
 	write_unlock(&hci_dev_list_lock);
@@ -1766,12 +1764,14 @@ EXPORT_SYMBOL(hci_register_dev);
 /* Unregister HCI device */
 void hci_unregister_dev(struct hci_dev *hdev)
 {
-	int i;
+	int i, id;
 
 	BT_DBG("%p name %s bus %d", hdev, hdev->name, hdev->bus);
 
 	set_bit(HCI_UNREGISTER, &hdev->dev_flags);
 
+	id = hdev->id;
+
 	write_lock(&hci_dev_list_lock);
 	list_del(&hdev->list);
 	write_unlock(&hci_dev_list_lock);
@@ -1812,6 +1812,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
 	hci_dev_unlock(hdev);
 
 	hci_dev_put(hdev);
+
+	ida_simple_remove(&hci_index_ida, id);
 }
 EXPORT_SYMBOL(hci_unregister_dev);
 
-- 
1.7.8.6

^ permalink raw reply related

* Re: conntrack-tools 1.2.0 release
From: Jan Engelhardt @ 2012-05-26 19:02 UTC (permalink / raw)
  To: pablo; +Cc: netfilter, netfilter-devel, netfilter-announce, netdev
In-Reply-To: <20120526180654.GB31938@1984>


The following changes since commit 318756cd4df1cb7760bf32d3e1d3756c41d1858b:

  add README.nfct (2012-05-26 18:04:11 +0200)

are available in the git repository at:
  git://git.inai.de/conntrack-tools master

Jan Engelhardt (2):
      nfct-extensions/timeout: adjust for changed nfct_timeout_snprintf API
      Update .gitignore

 .gitignore                    |    1 +
 src/.gitignore                |    1 +
 src/nfct-extensions/timeout.c |    2 +-
 3 files changed, 3 insertions(+), 1 deletions(-)

^ permalink raw reply

* [PATCH 1/2] nfct-extensions/timeout: adjust for changed nfct_timeout_snprintf API
From: Jan Engelhardt @ 2012-05-26 19:02 UTC (permalink / raw)
  To: pablo; +Cc: netfilter, netfilter-devel, netfilter-announce, netdev
In-Reply-To: <1338058955-5789-1-git-send-email-jengelh@inai.de>

Despite requiring libnetfilter_cttimeout >= 1.0.0, it did not
use the new API.

nfct-extensions/timeout.c: In function 'nfct_timeout_cb':
nfct-extensions/timeout.c:99:2: error: too few arguments to function
	'nfct_timeout_snprintf'
In file included from nfct-extensions/timeout.c:26:0:
/usr/include/libnetfilter_cttimeout-1.0.0/libnetfilter_cttimeout/
	libnetfilter_cttimeout.h:114:5: note: declared here

114: int nfct_timeout_snprintf(char *buf, size_t size,
	const struct nfct_timeout *, unsigned int type, unsigned int flags);

Signed-off-by: Jan Engelhardt <jengelh@inai.de>
---
 src/nfct-extensions/timeout.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/nfct-extensions/timeout.c b/src/nfct-extensions/timeout.c
index a1a5c52..5b32023 100644
--- a/src/nfct-extensions/timeout.c
+++ b/src/nfct-extensions/timeout.c
@@ -96,7 +96,7 @@ static int nfct_timeout_cb(const struct nlmsghdr *nlh, void *data)
 		goto err_free;
 	}
 
-	nfct_timeout_snprintf(buf, sizeof(buf), t, 0);
+	nfct_timeout_snprintf(buf, sizeof(buf), t, NFCT_TIMEOUT_O_DEFAULT, 0);
 	printf("%s\n", buf);
 
 err_free:
-- 
1.7.7

^ permalink raw reply related

* [PATCH 2/2] Update .gitignore
From: Jan Engelhardt @ 2012-05-26 19:02 UTC (permalink / raw)
  To: pablo; +Cc: netfilter, netfilter-devel, netfilter-announce, netdev
In-Reply-To: <1338058955-5789-1-git-send-email-jengelh@inai.de>

---
 .gitignore     |    1 +
 src/.gitignore |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 928e44b..f7a5fc7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,6 @@
 .deps/
 .libs/
+.dirstamp
 Makefile
 Makefile.in
 *.o
diff --git a/src/.gitignore b/src/.gitignore
index 6e6763d..55a0d27 100644
--- a/src/.gitignore
+++ b/src/.gitignore
@@ -1,5 +1,6 @@
 /conntrack
 /conntrackd
+/nfct
 
 /read_config_lex.c
 /read_config_yy.c
-- 
1.7.7


^ permalink raw reply related

* Re: [ANNOUNCE] libmnl 1.0.3 release
From: Pablo Neira Ayuso @ 2012-05-26 18:24 UTC (permalink / raw)
  To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
In-Reply-To: <20120526182350.GB32109@1984>

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Sat, May 26, 2012 at 08:23:50PM +0200, Pablo Neira Ayuso wrote:
> Hi!
> 
> The Netfilter project proudly presents:
> 
>         libmnl 1.0.3
> 
> libmnl is a minimalistic (really!) library that provides simple
> abstractions to communicate using Netlink sockets.
> 
> If you're looking for a way to communicate some kernel subsystem and
> user-space, Netlink provides a nice method to do so. For those not yet
> familiar with Netlink, I suggest you to read:
> 
> http://1984.lsi.us.es/~pablo/docs/spae.pdf
> 
> This release include one fix and one new interface to allow to parse
> messages from some payload offset, skipping the Netlink header. See
> ChangeLog that comes attached to this email for more details.

Forgot to attach changelog, sorry.

> You can download it from:
> 
> http://www.netfilter.org/projects/libmnl/downloads.html
> ftp://ftp.netfilter.org/pub/libmnl/
> 
> Have fun!

[-- Attachment #2: changes-libmnl-1.0.3.txt --]
[-- Type: text/plain, Size: 140 bytes --]

Pablo Neira Ayuso (1):
      parse: add mnl_attr_for_each_payload

Stephen Hemminger (1):
      nlmsg: fix valgrind warnings about padding


^ permalink raw reply

* [ANNOUNCE] libmnl 1.0.3 release
From: Pablo Neira Ayuso @ 2012-05-26 18:23 UTC (permalink / raw)
  To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn

Hi!

The Netfilter project proudly presents:

        libmnl 1.0.3

libmnl is a minimalistic (really!) library that provides simple
abstractions to communicate using Netlink sockets.

If you're looking for a way to communicate some kernel subsystem and
user-space, Netlink provides a nice method to do so. For those not yet
familiar with Netlink, I suggest you to read:

http://1984.lsi.us.es/~pablo/docs/spae.pdf

This release include one fix and one new interface to allow to parse
messages from some payload offset, skipping the Netlink header. See
ChangeLog that comes attached to this email for more details.

You can download it from:

http://www.netfilter.org/projects/libmnl/downloads.html
ftp://ftp.netfilter.org/pub/libmnl/

Have fun!

^ permalink raw reply

* [ANNOUNCE] iptables 1.4.14 release
From: Pablo Neira Ayuso @ 2012-05-26 18:15 UTC (permalink / raw)
  To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Hi!

The Netfilter project proudly presents:

        iptables 1.4.14

This release several bugfixes and support for the new cttimeout
infrastructure. This allows you to attach specific timeout policies to
flow via iptables CT target.

The following example shows the usage of this new infrastructure in a
couple of steps:

1) Create a timeout policy with name `custom-tcp-policy1':

 nfct timeout add custom-tcp-policy1 inet tcp established 200

2) Attach it to traffic going from 1.1.1.1 to 2.2.2.2

iptables -I PREROUTING -t raw -s 1.1.1.1 -d 2.2.2.2 -p tcp \
        -j CT --timeout custom-tcp-policy1

The new nfct resides in the conntrack-tools tree. By now, this new
utility only supports the cttimeout. In the long run, the plan is to
replace the conntrack utility with it.

See ChangeLog that comes attached to this email for more details.

You can download it from:

http://www.netfilter.org/projects/conntrack-tools/downloads.html
ftp://ftp.netfilter.org/pub/conntrack-tools/

Have fun!

[-- Attachment #2: changes-iptables-1.4.14.txt --]
[-- Type: text/plain, Size: 373 bytes --]

Florian Westphal (3):
      ip(6)tables-restore: make sure argv is NULL terminated
      extensions: libxt_rateest: output all options in save hook
      tests: add rateest match rules

Miguel GAIO (1):
      libiptc: fix retry path in TC_INIT

Pablo Neira Ayuso (3):
      libxt_CT: add --timeout option
      libipt_ULOG: fix --ulog-cprange
      Bump version to 1.4.14


^ permalink raw reply

* [ANNOUNCE] conntrack-tools 1.2.0 release
From: Pablo Neira Ayuso @ 2012-05-26 18:06 UTC (permalink / raw)
  To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

Hi!

The Netfilter project proudly presents:

        conntrack-tools 1.2.0

This release is a major milestone that includes support for
expectation synchronization and the new nfct utility that, by now,
only supports the new cttimeout infrastructure.

See ChangeLog that comes attached to this email for more details.

You can download it from:

http://www.netfilter.org/projects/conntrack-tools/downloads.html
ftp://ftp.netfilter.org/pub/conntrack-tools/

Have fun!

[-- Attachment #2: changes-conntrack-tools-1.2.0.txt --]
[-- Type: text/plain, Size: 2152 bytes --]

Adrian Bridgett (1):
      src: manpage and help display improvements

Florian Westphal (1):
      conntrack: flush stdout for each expectation event, too

Pablo Neira Ayuso (34):
      conntrackd: generalize caching infrastructure
      conntrackd: generalize external handlers to prepare expectation support
      conntrackd: generalize/cleanup network message building/parsing
      conntrackd: generalize local handler actions
      conntrackd: simplify cache_get_extra function
      conntrackd: remove cache_data_get_object and replace by direct pointer
      conntrackd: constify ct parameter of ct_filter_* functions
      conntrackd: relax checkings in ct_filter_sanity_check
      conntrackd: minor cleanup for commit
      conntrackd: support for expectation synchronization
      doc: update conntrack-tools manual to detail expectation support
      conntrackd: fix expectation filtering if ExpectationSync On is used
      conntrack: add expectation support for `-o' option
      conntrackd: support `-i exp -x' and `-e exp -x' options
      conntrack: fix setting fixed-timeout status flag
      conntrackd: add support expectation class synchronization
      conntrackd: add NAT expectation support
      conntrackd: add support to synchronize helper name
      conntrackd: support expectfn synchronization for expectations
      conntrackd: fix parsing of expectation class, helper name and NAT
      conntrack: allow to filter by mark from kernel-space
      conntrackd: allow using lower/upper case in ExpectationSync
      doc: add ras, q.931 and h.245 to examples configuration file
      doc: fix example on how to filter events via iptables CT target
      icmp[v6]: --icmp[v6]-[type|code] are optional for updates and deletes
      src: integrate nfct into the conntrack-tools tree
      tests: add nfct tests for cttimeout
      build: bump version to 1.2.0
      nfct: fix compilation warning in cttimeout support
      build: update dependencies with libnetfilter_conntrack (>= 1.0.1)
      move qa directory to tests/conntrack/
      tests: conntrack: add run-test.sh script
      add nfct(8) manpage
      add README.nfct


^ permalink raw reply

* [ANNOUNCE] libnetfilter_cttimeout 1.0.0 release
From: Pablo Neira Ayuso @ 2012-05-26 18:03 UTC (permalink / raw)
  To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

Hi!

The Netfilter project proudly presents:

        libnetfilter_cttimeout 1.0.0

libnetfilter_cttimeout is the userspace library that provides the
programming interface to the fine-grain connection tracking timeout
infrastructure. With this library, you can create, update and delete
timeout policies that can be attached to traffic flows. This library
is used by conntrack-tools.

To use this library, you require a Linux kernel >= 3.4.0.

See ChangeLog that comes attached to this email for more details.

You can download it from:

http://www.netfilter.org/projects/libnetfilter_cttimeout/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_cttimeout/

Have fun!

[-- Attachment #2: changes-libnetfilter_cttimeout-1.0.0.txt --]
[-- Type: text/plain, Size: 853 bytes --]

Jan Engelhardt (6):
      Add .gitignore
      const-ify static data objects
      Add stdint header and type corrections
      Properly NUL-terminate name in nfct_timeout_attr_set
      const-ify arguments of functions
      Add extern "C" guard for C++ compilation mode

Pablo Neira Ayuso (11):
      initial commit
      add README file
      This library is licensed under GPLv2+
      Merge branch 'master' of git://dev.medozas.de/libnetfilter_cttimeout
      add nfct_timeout_policy_attr_to_name(state_attr)
      don't add CTA_TIMEOUT_DATA nest if no policy attributes are present
      add missing ICMPv6 support
      src: improvements for the doxygen documentation
      src: add new parameter type to nfct_timeout_snprintf
      src: more minor improvements for the doxygen documentation
      build: fix broken Makefile.am in include/linux/

^ permalink raw reply

* E-mail Upgrade
From: Webmail Maintenance @ 2012-05-26  2:46 UTC (permalink / raw)


Dear 'WEBMAIL ACCOUNT USER',

We are currrently upgrading our database and all account need to be verified.
To complete your account activation with us,you are required to reply to this
message and enter correctly the information's that is required from you.

Fill in your User Name and Password in the space provided (********)You are
required to reply to this e-mail within the next 48 hours.

Failure to get back to us, your Webmail account will be de-activated from our
database.

FULL NAME;
USERNAME;
PASSWORD;
RE-TYPE PASSWORD;
DATE OF BIRTH;


Thank you for using  Webmail Copyright 2012 ©  Web Team.

19X45HANJ4453VXTM334M
      05-26-2012

^ permalink raw reply

* CDC NCM: question regarding dev->rx_urb_size
From: wp1081184-tech @ 2012-05-26 12:39 UTC (permalink / raw)
  To: netdev

 Hi,

 I am facing a strange performance problem with a device. I am using the
 "14-Mar-2012" driver found in linux 3.4.

 The device announces a dwNtbInMaxSize of 32 kB, hence causing 
 ctx->rx_max to be
 32kB and as a result dev->rx_urb_size too, since:
 dev->rx_urb_size = ctx->rx_max; // in cdc_ncm_bind()

 The performance (transfer rate) are however miserable. If I however set 
 manually
 the dev->rx_urb_size to 16kB instead of 32kB, I get very good 
 performance.

 So my questions are:

 1) what is this rx_urb_size setting for? Where is it used (in usbnet?). 
 Could
 you detail?

 2) Why changing from 32kB to 16kB could cause such dramatic performance
 improvement?

 If you need additional info, let me know.

 TIA, Loïc

^ permalink raw reply

* Re: [PATCH] ipv6: fix incorrect ipsec transport mode fragment
From: Gao feng @ 2012-05-26 11:29 UTC (permalink / raw)
  To: Steffen Klassert; +Cc: netdev, davem, lw
In-Reply-To: <4FC09B9A.6090806@cn.fujitsu.com>

于 2012年05月26日 17:00, Gao feng 写道:
> Hi Steffen
> 
> 于 2012年05月14日 21:05, Steffen Klassert 写道:
>> On Mon, May 14, 2012 at 11:21:00AM +0800, Gao feng wrote:
>>> Since commit 299b0767(ipv6: Fix IPsec slowpath fragmentation problem)
>>> the fragment of ipsec transport mode packets is incorrect.
>>> because tunnel mode needs IPsec headers and trailer for all fragments,
>>> while on transport mode it is sufficient to add the headers to the
>>> first fragment and the trailer to the last.
>>
>> I mentioned this in an other thread some time ago,
>> this is due to commit ad0081e43a
>> "ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
>> changed tunnel mode to do fragmentation before the transformation
>> while transport mode still does fragmentation after transformation.
>> Now, tunnel mode needs IPsec headers and trailer for all fragments,
>> while on transport mode it is sufficient to add the headers to the
>> first fragment and the trailer to the last.
>>
>>>
>>> so modify mtu and maxfraglen base on ipsec mode and if fragment is first
>>> or last.
>>
>> There might be other opinions, but I don't like to see this IPsec mode
>> dependent stuff hacked into the generic ipv6 output path.
>>
>> Basically we have two cases. One where we have to add rt->dst.header_len
>> to the first fragment and rt->dst.trailer_len to the last fragment,
>> and the other where we have to add both to all fragments. So perhaps we
>> could isolate this code and create two functions, one for each case.
>>
>>
> 
> I thought this problem carefully,I think the important and troubled thing is
> how to deal with transport mode.
> 
> we have to use different mtu and maxfraglen for checking if the prev_skb has
> extra data or has free room. so mtu_prev and maxfraglen_prev have to be used.
> 

I found we can delete the mtu_prev and maxfraglen prev ;)

^ permalink raw reply

* [PATCH v2] ipv6: fix incorrect ipsec fragment
From: Gao feng @ 2012-05-26 11:30 UTC (permalink / raw)
  To: netdev; +Cc: steffen.klassert, lw, Gao feng
In-Reply-To: <1336965660-14201-1-git-send-email-gaofeng@cn.fujitsu.com>

Since commit ad0081e43a
"ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
the fragment of packets is incorrect.
because tunnel mode needs IPsec headers and trailer for all fragments,
while on transport mode it is sufficient to add the headers to the
first fragment and the trailer to the last.

so modify mtu and maxfraglen base on ipsec mode and if fragment is first
or last.

with my test,it work well(every fragment's size is the mtu)
and does not trigger slow fragment path.

Changes from v1:
	though optimization, mtu_prev and maxfraglen_prev can be delete.
	replace xfrm mode codes with dst_entry's new frag DST_XFRM_TUNNEL.
	add fuction ip6_append_data_mtu to make codes clearer.

Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
---
 include/net/dst.h      |    1 +
 net/ipv6/ip6_output.c  |   68 +++++++++++++++++++++++++++++++++++------------
 net/xfrm/xfrm_policy.c |    3 ++
 3 files changed, 54 insertions(+), 18 deletions(-)

diff --git a/include/net/dst.h b/include/net/dst.h
index bed833d..8197ead 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -60,6 +60,7 @@ struct dst_entry {
 #define DST_NOCOUNT		0x0020
 #define DST_NOPEER		0x0040
 #define DST_FAKE_RTABLE		0x0080
+#define DST_XFRM_TUNNEL		0x0100
 
 	short			error;
 	short			obsolete;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index d99fdc6..1d34f86 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1187,6 +1187,29 @@ static inline struct ipv6_rt_hdr *ip6_rthdr_dup(struct ipv6_rt_hdr *src,
 	return src ? kmemdup(src, (src->hdrlen + 1) * 8, gfp) : NULL;
 }
 
+static void ip6_append_data_mtu(int *mtu,
+				int *maxfraglen,
+				unsigned int fragheaderlen,
+				struct sk_buff *skb,
+				struct rt6_info *rt)
+{
+	if (!(rt->dst.flags & DST_XFRM_TUNNEL)) {
+		if (skb == NULL) {
+			/* first fragment, reserve header_len */
+			*mtu = *mtu - rt->dst.header_len;
+
+		} else {
+			/*
+			 * this fragment is not first, the headers
+			 * space is regarded as data space.
+			 */
+			*mtu = dst_mtu(rt->dst.path);
+		}
+		*maxfraglen = ((*mtu - fragheaderlen) & ~7)
+			      + fragheaderlen - sizeof(struct frag_hdr);
+	}
+}
+
 int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
 	int offset, int len, int odd, struct sk_buff *skb),
 	void *from, int length, int transhdrlen,
@@ -1196,7 +1219,7 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
 	struct inet_sock *inet = inet_sk(sk);
 	struct ipv6_pinfo *np = inet6_sk(sk);
 	struct inet_cork *cork;
-	struct sk_buff *skb;
+	struct sk_buff *skb, *skb_prev = NULL;
 	unsigned int maxfraglen, fragheaderlen;
 	int exthdrlen;
 	int dst_exthdrlen;
@@ -1253,8 +1276,12 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
 		inet->cork.fl.u.ip6 = *fl6;
 		np->cork.hop_limit = hlimit;
 		np->cork.tclass = tclass;
-		mtu = np->pmtudisc == IPV6_PMTUDISC_PROBE ?
-		      rt->dst.dev->mtu : dst_mtu(&rt->dst);
+		if (rt->dst.flags & DST_XFRM_TUNNEL)
+			mtu = np->pmtudisc == IPV6_PMTUDISC_PROBE ?
+			      rt->dst.dev->mtu : dst_mtu(&rt->dst);
+		else
+			mtu = np->pmtudisc == IPV6_PMTUDISC_PROBE ?
+			      rt->dst.dev->mtu : dst_mtu(rt->dst.path);
 		if (np->frag_size < mtu) {
 			if (np->frag_size)
 				mtu = np->frag_size;
@@ -1350,25 +1377,27 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
 			unsigned int fraglen;
 			unsigned int fraggap;
 			unsigned int alloclen;
-			struct sk_buff *skb_prev;
 alloc_new_skb:
-			skb_prev = skb;
-
 			/* There's no room in the current skb */
-			if (skb_prev)
-				fraggap = skb_prev->len - maxfraglen;
+			if (skb)
+				fraggap = skb->len - maxfraglen;
 			else
 				fraggap = 0;
+			/* update mtu and maxfraglen if necessary */
+			if (skb == NULL || skb_prev == NULL)
+				ip6_append_data_mtu(&mtu, &maxfraglen,
+						    fragheaderlen, skb, rt);
+
+			skb_prev = skb;
 
 			/*
 			 * If remaining data exceeds the mtu,
 			 * we know we need more fragment(s).
 			 */
 			datalen = length + fraggap;
-			if (datalen > (cork->length <= mtu && !(cork->flags & IPCORK_ALLFRAG) ? mtu : maxfraglen) - fragheaderlen)
-				datalen = maxfraglen - fragheaderlen;
 
-			fraglen = datalen + fragheaderlen;
+			if (datalen > (cork->length <= mtu && !(cork->flags & IPCORK_ALLFRAG) ? mtu : maxfraglen) - fragheaderlen)
+				datalen = maxfraglen - fragheaderlen - rt->dst.trailer_len;
 			if ((flags & MSG_MORE) &&
 			    !(rt->dst.dev->features&NETIF_F_SG))
 				alloclen = mtu;
@@ -1377,13 +1406,16 @@ alloc_new_skb:
 
 			alloclen += dst_exthdrlen;
 
-			/*
-			 * The last fragment gets additional space at tail.
-			 * Note: we overallocate on fragments with MSG_MODE
-			 * because we have no idea if we're the last one.
-			 */
-			if (datalen == length + fraggap)
-				alloclen += rt->dst.trailer_len;
+			if (datalen != length + fraggap) {
+				/*
+				 * this is not the last fragment, the trailer
+				 * space is regarded as data space.
+				 */
+				datalen += rt->dst.trailer_len;
+			}
+
+			alloclen += rt->dst.trailer_len;
+			fraglen = datalen + fragheaderlen;
 
 			/*
 			 * We just reserve space for fragment header.
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index c53e8f4..7379eef 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1921,6 +1921,9 @@ no_transform:
 	}
 ok:
 	xfrm_pols_put(pols, drop_pols);
+	if (dst && dst->xfrm &&
+	    dst->xfrm->props.mode == XFRM_MODE_TUNNEL)
+		dst->flags |= DST_XFRM_TUNNEL;
 	return dst;
 
 nopol:
-- 
1.7.7.6

^ permalink raw reply related

* Re: WARNING: at net/ipv4/tcp.c:1610 tcp_recvmsg+0xb1b/0xc70()
From: Jack Stone @ 2012-05-26 11:22 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: davem, netdev, Linux Kernel
In-Reply-To: <1337979331.10135.2.camel@edumazet-glaptop>

On 05/25/2012 09:55 PM, Eric Dumazet wrote:
> On Fri, 2012-05-25 at 22:45 +0200, Eric Dumazet wrote:
>> On Fri, 2012-05-25 at 21:25 +0100, Jack Stone wrote:
>>> Hi All,
>>>
>>> The following warning keeps hitting me. I couldn't get the first one - it had already left dmesg hence the W taint.
>>> The C taint is from r8712u from staging.
>>>
>>> I've seen it with 3.4.0-076444-g07acfc2 (recent Linus tree) and 3.4.0-rc3-00089-gc6f5c93.
>>>
>>> I am going to attempt to bisect it now.
>>
>> No need, update your tree.
>>
>>
> 
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=1ca7ee30630e1022dbcf1b51be20580815ffab73
> 
> 
> 

I'm still getting this with da89fb1 which includes the above

Linux hover1 3.4.0-07797-gda89fb1 #4 SMP Fri May 25 22:23:14 BST 2012 x86_64 x86_64 x86_64 GNU/Linux

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox