LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [RFC/PATCH] init/main.c: Simplify initcall_blacklisted()
@ 2015-01-17  0:25 Rasmus Villemoes
  2015-01-19 19:19 ` Oleg Nesterov
  0 siblings, 1 reply; 10+ messages in thread
From: Rasmus Villemoes @ 2015-01-17  0:25 UTC (permalink / raw)
  To: Andrew Morton, Rusty Russell, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Oleg Nesterov, Geert Uytterhoeven, Prarit Bhargava,
	Fabian Frederick, Johannes Weiner
  Cc: Rasmus Villemoes, linux-kernel

Using kasprintf to get the function name makes us look up the name
twice, along with all the vsnprintf overhead of parsing the format
string etc. It also means there is an allocation failure case to deal
with. Since symbol_string in vsprintf.c would anyway allocate an array
of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
here.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---

Notes:
    I don't know how expensive it is to do the symbol lookup for each
    initcall. It might be worthwhile adding an
    
      if (list_empty(&blacklisted_initcalls))
        return false;
    
    at the very beginning of initcall_blacklisted(), since this is a debug
    feature and the blacklist is indeed usually empty.

 init/main.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/init/main.c b/init/main.c
index 61b993767db5..286602b677de 100644
--- a/init/main.c
+++ b/init/main.c
@@ -733,22 +733,18 @@ static bool __init_or_module initcall_blacklisted(initcall_t fn)
 {
 	struct list_head *tmp;
 	struct blacklist_entry *entry;
-	char *fn_name;
+	char fn_name[KSYM_SYMBOL_LEN];
 
-	fn_name = kasprintf(GFP_KERNEL, "%pf", fn);
-	if (!fn_name)
-		return false;
+	sprint_symbol_no_offset(fn_name, (unsigned long)fn);
 
 	list_for_each(tmp, &blacklisted_initcalls) {
 		entry = list_entry(tmp, struct blacklist_entry, next);
 		if (!strcmp(fn_name, entry->buf)) {
 			pr_debug("initcall %s blacklisted\n", fn_name);
-			kfree(fn_name);
 			return true;
 		}
 	}
 
-	kfree(fn_name);
 	return false;
 }
 #else
-- 
2.1.3


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC/PATCH] init/main.c: Simplify initcall_blacklisted()
  2015-01-17  0:25 [RFC/PATCH] init/main.c: Simplify initcall_blacklisted() Rasmus Villemoes
@ 2015-01-19 19:19 ` Oleg Nesterov
  2015-01-20  1:05   ` Rusty Russell
  0 siblings, 1 reply; 10+ messages in thread
From: Oleg Nesterov @ 2015-01-19 19:19 UTC (permalink / raw)
  To: Rasmus Villemoes
  Cc: Andrew Morton, Rusty Russell, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Geert Uytterhoeven, Prarit Bhargava, Fabian Frederick,
	Johannes Weiner, linux-kernel

On 01/17, Rasmus Villemoes wrote:
>
> Using kasprintf to get the function name makes us look up the name
> twice, along with all the vsnprintf overhead of parsing the format
> string etc. It also means there is an allocation failure case to deal
> with. Since symbol_string in vsprintf.c would anyway allocate an array
> of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
> here.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> 
> Notes:
>     I don't know how expensive it is to do the symbol lookup for each
>     initcall. It might be worthwhile adding an
>     
>       if (list_empty(&blacklisted_initcalls))
>         return false;
>     
>     at the very beginning of initcall_blacklisted(), since this is a debug
>     feature and the blacklist is indeed usually empty.

If we want to optimize this... I am wondering if we can change
initcall_blacklist()

	-	entry->buf = alloc_bootmem(strlen(str_entry) + 1);
	+	ebtry->fn = kallsyms_lookup_name(str_entry);

and then change initcall_blacklisted() to just compare the pointers.

Oleg.

>  init/main.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/init/main.c b/init/main.c
> index 61b993767db5..286602b677de 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -733,22 +733,18 @@ static bool __init_or_module initcall_blacklisted(initcall_t fn)
>  {
>  	struct list_head *tmp;
>  	struct blacklist_entry *entry;
> -	char *fn_name;
> +	char fn_name[KSYM_SYMBOL_LEN];
>  
> -	fn_name = kasprintf(GFP_KERNEL, "%pf", fn);
> -	if (!fn_name)
> -		return false;
> +	sprint_symbol_no_offset(fn_name, (unsigned long)fn);
>  
>  	list_for_each(tmp, &blacklisted_initcalls) {
>  		entry = list_entry(tmp, struct blacklist_entry, next);
>  		if (!strcmp(fn_name, entry->buf)) {
>  			pr_debug("initcall %s blacklisted\n", fn_name);
> -			kfree(fn_name);
>  			return true;
>  		}
>  	}
>  
> -	kfree(fn_name);
>  	return false;
>  }
>  #else
> -- 
> 2.1.3
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC/PATCH] init/main.c: Simplify initcall_blacklisted()
  2015-01-19 19:19 ` Oleg Nesterov
@ 2015-01-20  1:05   ` Rusty Russell
  2015-01-20 10:49     ` Prarit Bhargava
  0 siblings, 1 reply; 10+ messages in thread
From: Rusty Russell @ 2015-01-20  1:05 UTC (permalink / raw)
  To: Oleg Nesterov, Rasmus Villemoes
  Cc: Andrew Morton, H. Peter Anvin, Peter Zijlstra (Intel),
	Geert Uytterhoeven, Prarit Bhargava, Fabian Frederick,
	Johannes Weiner, linux-kernel

Oleg Nesterov <oleg@redhat.com> writes:
> On 01/17, Rasmus Villemoes wrote:
>>
>> Using kasprintf to get the function name makes us look up the name
>> twice, along with all the vsnprintf overhead of parsing the format
>> string etc. It also means there is an allocation failure case to deal
>> with. Since symbol_string in vsprintf.c would anyway allocate an array
>> of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
>> here.
>> 
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>> ---
>> 
>> Notes:
>>     I don't know how expensive it is to do the symbol lookup for each
>>     initcall. It might be worthwhile adding an
>>     
>>       if (list_empty(&blacklisted_initcalls))
>>         return false;
>>     
>>     at the very beginning of initcall_blacklisted(), since this is a debug
>>     feature and the blacklist is indeed usually empty.
>
> If we want to optimize this... I am wondering if we can change
> initcall_blacklist()
>
> 	-	entry->buf = alloc_bootmem(strlen(str_entry) + 1);
> 	+	ebtry->fn = kallsyms_lookup_name(str_entry);
>
> and then change initcall_blacklisted() to just compare the pointers.

That would make far, far more sense.  It would fail for modules of
course, but that might be OK.  Prarit, this was your code; does it
matter?

Cheers,
Rusty.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC/PATCH] init/main.c: Simplify initcall_blacklisted()
  2015-01-20  1:05   ` Rusty Russell
@ 2015-01-20 10:49     ` Prarit Bhargava
  2015-01-20 18:05       ` Oleg Nesterov
  0 siblings, 1 reply; 10+ messages in thread
From: Prarit Bhargava @ 2015-01-20 10:49 UTC (permalink / raw)
  To: Rusty Russell
  Cc: Oleg Nesterov, Rasmus Villemoes, Andrew Morton, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Geert Uytterhoeven, Fabian Frederick, Johannes Weiner,
	linux-kernel



On 01/19/2015 08:05 PM, Rusty Russell wrote:
> Oleg Nesterov <oleg@redhat.com> writes:
>> On 01/17, Rasmus Villemoes wrote:
>>>
>>> Using kasprintf to get the function name makes us look up the name
>>> twice, along with all the vsnprintf overhead of parsing the format
>>> string etc. It also means there is an allocation failure case to deal
>>> with. Since symbol_string in vsprintf.c would anyway allocate an array
>>> of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
>>> here.
>>>
>>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>>> ---
>>>
>>> Notes:
>>>     I don't know how expensive it is to do the symbol lookup for each
>>>     initcall. It might be worthwhile adding an
>>>     
>>>       if (list_empty(&blacklisted_initcalls))
>>>         return false;
>>>     
>>>     at the very beginning of initcall_blacklisted(), since this is a debug
>>>     feature and the blacklist is indeed usually empty.
>>
>> If we want to optimize this... I am wondering if we can change
>> initcall_blacklist()
>>
>> 	-	entry->buf = alloc_bootmem(strlen(str_entry) + 1);
>> 	+	ebtry->fn = kallsyms_lookup_name(str_entry);
>>
>> and then change initcall_blacklisted() to just compare the pointers.
> 
> That would make far, far more sense.  It would fail for modules of
> course, but that might be OK.  Prarit, this was your code; does it
> matter?

It does actually matter to me.  I've been using it to blacklist modules at boot
as well ... and it works really well :)  So I'm okay with the original patch but
not the second suggested change.

P.

> 
> Cheers,
> Rusty.
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC/PATCH] init/main.c: Simplify initcall_blacklisted()
  2015-01-20 10:49     ` Prarit Bhargava
@ 2015-01-20 18:05       ` Oleg Nesterov
  2015-01-20 18:39         ` Prarit Bhargava
  0 siblings, 1 reply; 10+ messages in thread
From: Oleg Nesterov @ 2015-01-20 18:05 UTC (permalink / raw)
  To: Prarit Bhargava
  Cc: Rusty Russell, Rasmus Villemoes, Andrew Morton, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Geert Uytterhoeven, Fabian Frederick, Johannes Weiner,
	linux-kernel

On 01/20, Prarit Bhargava wrote:
>
> On 01/19/2015 08:05 PM, Rusty Russell wrote:
> > Oleg Nesterov <oleg@redhat.com> writes:
> >>
> >> If we want to optimize this... I am wondering if we can change
> >> initcall_blacklist()
> >>
> >> 	-	entry->buf = alloc_bootmem(strlen(str_entry) + 1);
> >> 	+	ebtry->fn = kallsyms_lookup_name(str_entry);
> >>
> >> and then change initcall_blacklisted() to just compare the pointers.
> >
> > That would make far, far more sense.  It would fail for modules of
> > course, but that might be OK.  Prarit, this was your code; does it
> > matter?
>
> It does actually matter to me.  I've been using it to blacklist modules at boot
> as well ... and it works really well :)  So I'm okay with the original patch but
> not the second suggested change.

Yes, I didn't know/realize that initcall_blacklist paramater can be
also used to disable the modules, thanks for correcting me.

But I'd say that initcall_blacklisted(mod->init) looks a bit strange,
I mean it would be probably better to use mod->name in this case, not
the "internal" name of this likely static function.

Perhaps even another kernel parameter makes sense for this, I dunno..
>From Documentation/kernel-parameters.txt:

	initcall_blacklist=  [KNL] Do not execute a comma-separated list of
			initcall functions.  Useful for debugging built-in
			modules and initcalls.

note that this only mentions built-in modules.

Nevermind, I was wrong anyway. Thanks!

Oleg.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [RFC/PATCH] init/main.c: Simplify initcall_blacklisted()
  2015-01-20 18:05       ` Oleg Nesterov
@ 2015-01-20 18:39         ` Prarit Bhargava
  2016-03-21 23:14           ` [PATCH resend] " Rasmus Villemoes
  0 siblings, 1 reply; 10+ messages in thread
From: Prarit Bhargava @ 2015-01-20 18:39 UTC (permalink / raw)
  To: Oleg Nesterov
  Cc: Rusty Russell, Rasmus Villemoes, Andrew Morton, H. Peter Anvin,
	Peter Zijlstra (Intel),
	Geert Uytterhoeven, Fabian Frederick, Johannes Weiner,
	linux-kernel



On 01/20/2015 01:05 PM, Oleg Nesterov wrote:
> On 01/20, Prarit Bhargava wrote:
>>
>> On 01/19/2015 08:05 PM, Rusty Russell wrote:
>>> Oleg Nesterov <oleg@redhat.com> writes:
>>>>
>>>> If we want to optimize this... I am wondering if we can change
>>>> initcall_blacklist()
>>>>
>>>> 	-	entry->buf = alloc_bootmem(strlen(str_entry) + 1);
>>>> 	+	ebtry->fn = kallsyms_lookup_name(str_entry);
>>>>
>>>> and then change initcall_blacklisted() to just compare the pointers.
>>>
>>> That would make far, far more sense.  It would fail for modules of
>>> course, but that might be OK.  Prarit, this was your code; does it
>>> matter?
>>
>> It does actually matter to me.  I've been using it to blacklist modules at boot
>> as well ... and it works really well :)  So I'm okay with the original patch but
>> not the second suggested change.
> 
> Yes, I didn't know/realize that initcall_blacklist paramater can be
> also used to disable the modules, thanks for correcting me.

I didn't have that in mind originally, but I've been using it to debug initramfs
module loading.  It has worked quite well.

> 
> But I'd say that initcall_blacklisted(mod->init) looks a bit strange,
> I mean it would be probably better to use mod->name in this case, not
> the "internal" name of this likely static function.

:)  I've been thinking about exactly this too.  I just haven't had any time to
do it.

> 
> Perhaps even another kernel parameter makes sense for this, I dunno..
> From Documentation/kernel-parameters.txt:
> 
> 	initcall_blacklist=  [KNL] Do not execute a comma-separated list of
> 			initcall functions.  Useful for debugging built-in
> 			modules and initcalls.
> 
> note that this only mentions built-in modules.

I can fix that up too.

P.

> 
> Nevermind, I was wrong anyway. Thanks!
> 
> Oleg.
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH resend] init/main.c: Simplify initcall_blacklisted()
  2015-01-20 18:39         ` Prarit Bhargava
@ 2016-03-21 23:14           ` Rasmus Villemoes
  2016-03-22  3:27             ` Rusty Russell
  2016-03-24 17:16             ` Prarit Bhargava
  0 siblings, 2 replies; 10+ messages in thread
From: Rasmus Villemoes @ 2016-03-21 23:14 UTC (permalink / raw)
  To: Oleg Nesterov, Prarit Bhargava, Rusty Russell
  Cc: Andrew Morton, Rasmus Villemoes, linux-kernel

Using kasprintf to get the function name makes us look up the name
twice, along with all the vsnprintf overhead of parsing the format
string etc. It also means there is an allocation failure case to deal
with. Since symbol_string in vsprintf.c would anyway allocate an array
of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
here.

Moreover, since this is a debug feature and the blacklisted_initcalls
list is usually empty, we might as well test that and thus avoid
looking up the symbol name even once in the common case.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 init/main.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/init/main.c b/init/main.c
index b3c6e363ae18..d76d94cd537c 100644
--- a/init/main.c
+++ b/init/main.c
@@ -706,21 +706,20 @@ static int __init initcall_blacklist(char *str)
 static bool __init_or_module initcall_blacklisted(initcall_t fn)
 {
 	struct blacklist_entry *entry;
-	char *fn_name;
+	char fn_name[KSYM_SYMBOL_LEN];
 
-	fn_name = kasprintf(GFP_KERNEL, "%pf", fn);
-	if (!fn_name)
+	if (list_empty(&blacklisted_initcalls))
 		return false;
 
+	sprint_symbol_no_offset(fn_name, (unsigned long)fn);
+
 	list_for_each_entry(entry, &blacklisted_initcalls, next) {
 		if (!strcmp(fn_name, entry->buf)) {
 			pr_debug("initcall %s blacklisted\n", fn_name);
-			kfree(fn_name);
 			return true;
 		}
 	}
 
-	kfree(fn_name);
 	return false;
 }
 #else
-- 
2.1.4

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH resend] init/main.c: Simplify initcall_blacklisted()
  2016-03-21 23:14           ` [PATCH resend] " Rasmus Villemoes
@ 2016-03-22  3:27             ` Rusty Russell
  2016-03-23 23:54               ` Rasmus Villemoes
  2016-03-24 17:16             ` Prarit Bhargava
  1 sibling, 1 reply; 10+ messages in thread
From: Rusty Russell @ 2016-03-22  3:27 UTC (permalink / raw)
  To: Rasmus Villemoes, Oleg Nesterov, Prarit Bhargava
  Cc: Andrew Morton, Rasmus Villemoes, linux-kernel

Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
> Using kasprintf to get the function name makes us look up the name
> twice, along with all the vsnprintf overhead of parsing the format
> string etc. It also means there is an allocation failure case to deal
> with. Since symbol_string in vsprintf.c would anyway allocate an array
> of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
> here.
>
> Moreover, since this is a debug feature and the blacklisted_initcalls
> list is usually empty, we might as well test that and thus avoid
> looking up the symbol name even once in the common case.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>

Acked-by: Rusty Russell <rusty@rustcorp.com.au>

Thanks!
Rusty.

> ---
>  init/main.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index b3c6e363ae18..d76d94cd537c 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -706,21 +706,20 @@ static int __init initcall_blacklist(char *str)
>  static bool __init_or_module initcall_blacklisted(initcall_t fn)
>  {
>  	struct blacklist_entry *entry;
> -	char *fn_name;
> +	char fn_name[KSYM_SYMBOL_LEN];
>  
> -	fn_name = kasprintf(GFP_KERNEL, "%pf", fn);
> -	if (!fn_name)
> +	if (list_empty(&blacklisted_initcalls))
>  		return false;
>  
> +	sprint_symbol_no_offset(fn_name, (unsigned long)fn);
> +
>  	list_for_each_entry(entry, &blacklisted_initcalls, next) {
>  		if (!strcmp(fn_name, entry->buf)) {
>  			pr_debug("initcall %s blacklisted\n", fn_name);
> -			kfree(fn_name);
>  			return true;
>  		}
>  	}
>  
> -	kfree(fn_name);
>  	return false;
>  }
>  #else
> -- 
> 2.1.4

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH resend] init/main.c: Simplify initcall_blacklisted()
  2016-03-22  3:27             ` Rusty Russell
@ 2016-03-23 23:54               ` Rasmus Villemoes
  0 siblings, 0 replies; 10+ messages in thread
From: Rasmus Villemoes @ 2016-03-23 23:54 UTC (permalink / raw)
  To: Rusty Russell; +Cc: Oleg Nesterov, Prarit Bhargava, Andrew Morton, linux-kernel

On Tue, Mar 22 2016, Rusty Russell <rusty@rustcorp.com.au> wrote:

> Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
>> Using kasprintf to get the function name makes us look up the name
>> twice, along with all the vsnprintf overhead of parsing the format
>> string etc. It also means there is an allocation failure case to deal
>> with. Since symbol_string in vsprintf.c would anyway allocate an array
>> of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
>> here.
>>
>> Moreover, since this is a debug feature and the blacklisted_initcalls
>> list is usually empty, we might as well test that and thus avoid
>> looking up the symbol name even once in the common case.
>>
>> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
>
> Acked-by: Rusty Russell <rusty@rustcorp.com.au>
>

Thanks. Andrew, can I get you to take it?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH resend] init/main.c: Simplify initcall_blacklisted()
  2016-03-21 23:14           ` [PATCH resend] " Rasmus Villemoes
  2016-03-22  3:27             ` Rusty Russell
@ 2016-03-24 17:16             ` Prarit Bhargava
  1 sibling, 0 replies; 10+ messages in thread
From: Prarit Bhargava @ 2016-03-24 17:16 UTC (permalink / raw)
  To: Rasmus Villemoes, Oleg Nesterov, Rusty Russell
  Cc: Andrew Morton, linux-kernel



On 03/21/2016 07:14 PM, Rasmus Villemoes wrote:
> Using kasprintf to get the function name makes us look up the name
> twice, along with all the vsnprintf overhead of parsing the format
> string etc. It also means there is an allocation failure case to deal
> with. Since symbol_string in vsprintf.c would anyway allocate an array
> of size KSYM_SYMBOL_LEN on the stack, that might as well be done up
> here.
> 
> Moreover, since this is a debug feature and the blacklisted_initcalls
> list is usually empty, we might as well test that and thus avoid
> looking up the symbol name even once in the common case.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>


Acked-by: Prarit Bhargava <prarit@redhat.com>

P.


> ---
>  init/main.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/init/main.c b/init/main.c
> index b3c6e363ae18..d76d94cd537c 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -706,21 +706,20 @@ static int __init initcall_blacklist(char *str)
>  static bool __init_or_module initcall_blacklisted(initcall_t fn)
>  {
>  	struct blacklist_entry *entry;
> -	char *fn_name;
> +	char fn_name[KSYM_SYMBOL_LEN];
>  
> -	fn_name = kasprintf(GFP_KERNEL, "%pf", fn);
> -	if (!fn_name)
> +	if (list_empty(&blacklisted_initcalls))
>  		return false;
>  
> +	sprint_symbol_no_offset(fn_name, (unsigned long)fn);
> +
>  	list_for_each_entry(entry, &blacklisted_initcalls, next) {
>  		if (!strcmp(fn_name, entry->buf)) {
>  			pr_debug("initcall %s blacklisted\n", fn_name);
> -			kfree(fn_name);
>  			return true;
>  		}
>  	}
>  
> -	kfree(fn_name);
>  	return false;
>  }
>  #else
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2016-03-24 17:16 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-17  0:25 [RFC/PATCH] init/main.c: Simplify initcall_blacklisted() Rasmus Villemoes
2015-01-19 19:19 ` Oleg Nesterov
2015-01-20  1:05   ` Rusty Russell
2015-01-20 10:49     ` Prarit Bhargava
2015-01-20 18:05       ` Oleg Nesterov
2015-01-20 18:39         ` Prarit Bhargava
2016-03-21 23:14           ` [PATCH resend] " Rasmus Villemoes
2016-03-22  3:27             ` Rusty Russell
2016-03-23 23:54               ` Rasmus Villemoes
2016-03-24 17:16             ` Prarit Bhargava

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).