[patch 0/9] vmalloc fixes and improvements

[patch 0/9] vmalloc fixes and improvements

[npiggin]

Hi,

The following patches are a set of fixes and improvements for the vmap
layer.

Patches 1-3 fix "[Bug #11903] regression: vmalloc easily fail", and these
should go upstream for 2.6.28. They've been tested and shown to fix the
problem, and I've tested them here on my XFS stress test as well. The
off-by-one bug, I tested and verified in a userspace test harness (it
doesn't actually cause any corruption, but just suboptimal use of space).

Patches 4,5 are improvements to information exported to user. Not very risky,
but not urgent either.

Patches 6-9 improve locking, guard page scheme, put guard pages under
CONFIG_DEBUG_PAGEALLOC, and add a non-lazy-flush mode for
CONFIG_DEBUG_PAGEALLOC to catch use-after-free better. These are more
intrusive improvements. I'd like to see them merged, but they can happily
wait for next merge window.

Andrew, it's probably best if you take care of sending these upstream?

Thanks,
Nick
 
-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 1/9] mm: vmalloc allocator off by one

[npiggin]

[-- Attachment #1: mm-vmalloc-gap-fix.patch --]
[-- Type: text/plain, Size: 793 bytes --]

Fix off by one bug in the KVA allocator that can leave gaps in the
address space.
 
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -362,7 +363,7 @@ retry:
 				goto found;
 		}
 
-		while (addr + size >= first->va_start && addr + size <= vend) {
+		while (addr + size > first->va_start && addr + size <= vend) {
 			addr = ALIGN(first->va_end + PAGE_SIZE, align);
 
 			n = rb_next(&first->rb_node);

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 2/9] mm: vmalloc failure flush fix

[npiggin]

[-- Attachment #1: mm-vmalloc-flush-fix.patch --]
[-- Type: text/plain, Size: 1584 bytes --]

An initial vmalloc failure should start off a synchronous flush of lazy
areas, in case someone is in progress flushing them already, which could
cause us to return an allocation failure even if there is plenty of KVA
free.
 
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -522,13 +522,24 @@ static void __purge_vmap_area_lazy(unsig
 }
 
 /*
+ * Kick off a purge of the outstanding lazy areas. Don't bother if somebody
+ * is already purging.
+ */
+static void try_purge_vmap_area_lazy(void)
+{
+	unsigned long start = ULONG_MAX, end = 0;
+
+	__purge_vmap_area_lazy(&start, &end, 0, 0);
+}
+
+/*
  * Kick off a purge of the outstanding lazy areas.
  */
 static void purge_vmap_area_lazy(void)
 {
 	unsigned long start = ULONG_MAX, end = 0;
 
-	__purge_vmap_area_lazy(&start, &end, 0, 0);
+	__purge_vmap_area_lazy(&start, &end, 1, 0);
 }
 
 /*
@@ -539,7 +550,7 @@ static void free_unmap_vmap_area(struct 
 	va->flags |= VM_LAZY_FREE;
 	atomic_add((va->va_end - va->va_start) >> PAGE_SHIFT, &vmap_lazy_nr);
 	if (unlikely(atomic_read(&vmap_lazy_nr) > lazy_max_pages()))
-		purge_vmap_area_lazy();
+		try_purge_vmap_area_lazy();
 }
 
 static struct vmap_area *find_vmap_area(unsigned long addr)

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 3/9] mm: vmalloc search restart fix

[npiggin]

[-- Attachment #1: mm-vmalloc-restart-search-fix.patch --]
[-- Type: text/plain, Size: 1577 bytes --]

Current vmalloc restart search for a free area in case we can't find one. The
reason is there are areas which are lazily freed, and could be possibly freed
now. However, current implementation start searching the tree from the last
failing address, which is pretty much by definition at the end of address
space. So, we fail.

The proposal of this patch is to restart the search from the beginning of the
requested vstart address. This fixes the regression in running KVM virtual
machines for me, described in http://lkml.org/lkml/2008/10/28/349, caused by
commit db64fe02258f1507e13fe5212a989922323685ce.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
 mm/vmalloc.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -324,14 +324,14 @@ static struct vmap_area *alloc_vmap_area
 
 	BUG_ON(size & ~PAGE_MASK);
 
-	addr = ALIGN(vstart, align);
-
 	va = kmalloc_node(sizeof(struct vmap_area),
 			gfp_mask & GFP_RECLAIM_MASK, node);
 	if (unlikely(!va))
 		return ERR_PTR(-ENOMEM);
 
 retry:
+	addr = ALIGN(vstart, align);
+
 	spin_lock(&vmap_area_lock);
 	/* XXX: could have a last_hole cache */
 	n = vmap_area_root.rb_node;

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 4/9] mm: vmalloc tweak failure printk

[npiggin]

[-- Attachment #1: mm-vmalloc-tweak-output.patch --]
[-- Type: text/plain, Size: 1010 bytes --]

If we can't service a vmalloc allocation, show size of the allocation that
actually failed. Useful for debugging.

Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
 mm/vmalloc.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -381,8 +381,9 @@ found:
 			goto retry;
 		}
 		if (printk_ratelimit())
-			printk(KERN_WARNING "vmap allocation failed: "
-				 "use vmalloc=<size> to increase size.\n");
+			printk(KERN_WARNING
+				"vmap allocation for size %lu failed: "
+				"use vmalloc=<size> to increase size.\n", size);
 		return ERR_PTR(-EBUSY);
 	}
 

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 5/9] mm: vmalloc improve vmallocinfo

[npiggin]

[-- Attachment #1: mm-vmalloc-vmallocinfo-improve.patch --]
[-- Type: text/plain, Size: 2277 bytes --]

If we do that, output of files like /proc/vmallocinfo will show things like
"vmalloc_32", "vmalloc_user", or whomever the caller was as the caller. This
info is not as useful as the real caller of the allocation.

So, proposal is to call __vmalloc_node node directly, with matching parameters
to save the caller information

Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
 mm/vmalloc.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)

Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -1356,7 +1356,8 @@ void *vmalloc_user(unsigned long size)
 	struct vm_struct *area;
 	void *ret;
 
-	ret = __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO, PAGE_KERNEL);
+	ret = __vmalloc_node(size, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO,
+			     PAGE_KERNEL, -1, __builtin_return_address(0));
 	if (ret) {
 		area = find_vm_area(ret);
 		area->flags |= VM_USERMAP;
@@ -1401,7 +1402,8 @@ EXPORT_SYMBOL(vmalloc_node);
 
 void *vmalloc_exec(unsigned long size)
 {
-	return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC);
+	return __vmalloc_node(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC,
+			      -1, __builtin_return_address(0));
 }
 
 #if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
@@ -1421,7 +1423,8 @@ void *vmalloc_exec(unsigned long size)
  */
 void *vmalloc_32(unsigned long size)
 {
-	return __vmalloc(size, GFP_VMALLOC32, PAGE_KERNEL);
+	return __vmalloc_node(size, GFP_VMALLOC32, PAGE_KERNEL,
+			      -1, __builtin_return_address(0));
 }
 EXPORT_SYMBOL(vmalloc_32);
 
@@ -1437,7 +1440,8 @@ void *vmalloc_32_user(unsigned long size
 	struct vm_struct *area;
 	void *ret;
 
-	ret = __vmalloc(size, GFP_VMALLOC32 | __GFP_ZERO, PAGE_KERNEL);
+	ret = __vmalloc_node(size, GFP_VMALLOC32 | __GFP_ZERO, PAGE_KERNEL,
+			     -1, __builtin_return_address(0));
 	if (ret) {
 		area = find_vm_area(ret);
 		area->flags |= VM_USERMAP;

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 6/9] mm: vmalloc guard fix

[npiggin]

[-- Attachment #1: mm-vmalloc-guard-fix.patch --]
[-- Type: text/plain, Size: 3190 bytes --]

The vmap virtual address allocator always leaves a guard page; no need for
these hacks to add PAGE_SIZE to the vm_struct that we wanted to allocate in
order to get the guard page (this has been giving 2 guard pages)

Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -966,7 +966,7 @@ void unmap_kernel_range(unsigned long ad
 int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page ***pages)
 {
 	unsigned long addr = (unsigned long)area->addr;
-	unsigned long end = addr + area->size - PAGE_SIZE;
+	unsigned long end = addr + area->size;
 	int err;
 
 	err = vmap_page_range(addr, end, prot, *pages);
@@ -1012,11 +1012,6 @@ static struct vm_struct *__get_vm_area_n
 	if (unlikely(!area))
 		return NULL;
 
-	/*
-	 * We always allocate a guard page.
-	 */
-	size += PAGE_SIZE;
-
 	va = alloc_vmap_area(size, align, start, end, node, gfp_mask);
 	if (IS_ERR(va)) {
 		kfree(area);
@@ -1110,7 +1105,6 @@ struct vm_struct *remove_vm_area(const v
 		struct vm_struct *vm = va->private;
 		struct vm_struct *tmp, **p;
 		free_unmap_vmap_area(va);
-		vm->size -= PAGE_SIZE;
 
 		write_lock(&vmlist_lock);
 		for (p = &vmlist; (tmp = *p) != vm; p = &tmp->next)
@@ -1238,7 +1232,7 @@ static void *__vmalloc_area_node(struct 
 	struct page **pages;
 	unsigned int nr_pages, array_size, i;
 
-	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
+	nr_pages = area->size >> PAGE_SHIFT;
 	array_size = (nr_pages * sizeof(struct page *));
 
 	area->nr_pages = nr_pages;
@@ -1463,7 +1457,7 @@ long vread(char *buf, char *addr, unsign
 	read_lock(&vmlist_lock);
 	for (tmp = vmlist; tmp; tmp = tmp->next) {
 		vaddr = (char *) tmp->addr;
-		if (addr >= vaddr + tmp->size - PAGE_SIZE)
+		if (addr >= vaddr + tmp->size)
 			continue;
 		while (addr < vaddr) {
 			if (count == 0)
@@ -1473,7 +1467,7 @@ long vread(char *buf, char *addr, unsign
 			addr++;
 			count--;
 		}
-		n = vaddr + tmp->size - PAGE_SIZE - addr;
+		n = vaddr + tmp->size - addr;
 		do {
 			if (count == 0)
 				goto finished;
@@ -1501,7 +1495,7 @@ long vwrite(char *buf, char *addr, unsig
 	read_lock(&vmlist_lock);
 	for (tmp = vmlist; tmp; tmp = tmp->next) {
 		vaddr = (char *) tmp->addr;
-		if (addr >= vaddr + tmp->size - PAGE_SIZE)
+		if (addr >= vaddr + tmp->size)
 			continue;
 		while (addr < vaddr) {
 			if (count == 0)
@@ -1510,7 +1504,7 @@ long vwrite(char *buf, char *addr, unsig
 			addr++;
 			count--;
 		}
-		n = vaddr + tmp->size - PAGE_SIZE - addr;
+		n = vaddr + tmp->size - addr;
 		do {
 			if (count == 0)
 				goto finished;
@@ -1556,7 +1550,7 @@ int remap_vmalloc_range(struct vm_area_s
 	if (!(area->flags & VM_USERMAP))
 		return -EINVAL;
 
-	if (usize + (pgoff << PAGE_SHIFT) > area->size - PAGE_SIZE)
+	if (usize + (pgoff << PAGE_SHIFT) > area->size)
 		return -EINVAL;
 
 	addr += pgoff << PAGE_SHIFT;

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 7/9] mm: vmalloc use mutex for purge

[npiggin]

[-- Attachment #1: mm-vmalloc-mutex.patch --]
[-- Type: text/plain, Size: 1692 bytes --]

The vmalloc purge lock can be a mutex so we can sleep while a purge is going
on (purge involves a global kernel TLB invalidate, so it can take quite a
while).
 
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -14,6 +14,7 @@
 #include <linux/highmem.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/mutex.h>
 #include <linux/interrupt.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
@@ -473,7 +474,7 @@ static atomic_t vmap_lazy_nr = ATOMIC_IN
 static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
 					int sync, int force_flush)
 {
-	static DEFINE_SPINLOCK(purge_lock);
+	static DEFINE_MUTEX(purge_lock);
 	LIST_HEAD(valist);
 	struct vmap_area *va;
 	int nr = 0;
@@ -484,10 +485,10 @@ static void __purge_vmap_area_lazy(unsig
 	 * the case that isn't actually used at the moment anyway.
 	 */
 	if (!sync && !force_flush) {
-		if (!spin_trylock(&purge_lock))
+		if (!mutex_trylock(&purge_lock))
 			return;
 	} else
-		spin_lock(&purge_lock);
+		mutex_lock(&purge_lock);
 
 	rcu_read_lock();
 	list_for_each_entry_rcu(va, &vmap_area_list, list) {
@@ -519,7 +520,7 @@ static void __purge_vmap_area_lazy(unsig
 			__free_vmap_area(va);
 		spin_unlock(&vmap_area_lock);
 	}
-	spin_unlock(&purge_lock);
+	mutex_unlock(&purge_lock);
 }
 
 /*

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 8/9] mm: vmalloc make guard configurable

[npiggin]

[-- Attachment #1: mm-vmalloc-guard-config.patch --]
[-- Type: text/plain, Size: 1377 bytes --]

In mm/vmalloc.c, make usage of guard pages dependant on CONFIG_DEBUG_PAGEALLOC.

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

Reworked so the guard size logic remains inside the allocator.

Signed-off-by: Nick Piggin <npiggin@suse.de>
---
 mm/vmalloc.c |   25 +++++++++++++++----------
 1 files changed, 15 insertions(+), 10 deletions(-)

Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -29,6 +29,16 @@
 #include <asm/uaccess.h>
 #include <asm/tlbflush.h>
 
+/*
+ * Add a guard page between each kernel virtual address allocation if
+ * DEBUG_PAGEALLOC is turned on (could be a separate config option, but
+ * no big deal).
+ */
+#ifdef CONFIG_DEBUG_PAGEALLOC
+#define GUARD_SIZE PAGE_SIZE
+#else
+#define GUARD_SIZE 0
+#endif
 
 /*** Page table manipulation functions ***/
 
@@ -364,7 +374,7 @@ retry:
 		}
 
 		while (addr + size > first->va_start && addr + size <= vend) {
-			addr = ALIGN(first->va_end + PAGE_SIZE, align);
+			addr = ALIGN(first->va_end + GUARD_SIZE, align);
 
 			n = rb_next(&first->rb_node);
 			if (n)

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[patch 9/9] mm: vmalloc make lazy unmapping configurable

[npiggin]

[-- Attachment #1: mm-vmalloc-nolazy-debug.patch --]
[-- Type: text/plain, Size: 2120 bytes --]

Lazy unmapping in the vmalloc code has now opened the possibility for use
after free bugs to go undetected. We can catch those by forcing an unmap
and flush (which is going to be slow, but that's what happens).

Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/vmalloc.c
===================================================================
--- linux-2.6.orig/mm/vmalloc.c
+++ linux-2.6/mm/vmalloc.c
@@ -444,6 +444,27 @@ static void unmap_vmap_area(struct vmap_
 	vunmap_page_range(va->va_start, va->va_end);
 }
 
+static void vmap_debug_free_range(unsigned long start, unsigned long end)
+{
+	/*
+	 * Unmap page tables and force a TLB flush immediately if
+	 * CONFIG_DEBUG_PAGEALLOC is set. This catches use after free
+	 * bugs similarly to those in linear kernel virtual address
+	 * space after a page has been freed.
+	 *
+	 * All the lazy freeing logic is still retained, in order to
+	 * minimise intrusiveness of this debugging feature.
+	 *
+	 * This is going to be *slow* (linear kernel virtual address
+	 * debugging doesn't do a broadcast TLB flush so it is a lot
+	 * faster).
+	 */
+#ifdef CONFIG_DEBUG_PAGEALLOC
+	vunmap_page_range(start, end);
+	flush_tlb_kernel_range(start, end);
+#endif
+}
+
 /*
  * lazy_max_pages is the maximum amount of virtual address space we gather up
  * before attempting to purge with a TLB flush.
@@ -906,6 +927,7 @@ void vm_unmap_ram(const void *mem, unsig
 	BUG_ON(addr & (PAGE_SIZE-1));
 
 	debug_check_no_locks_freed(mem, size);
+	vmap_debug_free_range(addr, addr+size);
 
 	if (likely(count <= VMAP_MAX_ALLOC))
 		vb_free(mem, size);
@@ -1115,6 +1137,8 @@ struct vm_struct *remove_vm_area(const v
 	if (va && va->flags & VM_VM_AREA) {
 		struct vm_struct *vm = va->private;
 		struct vm_struct *tmp, **p;
+
+		vmap_debug_free_range(va->va_start, va->va_end);
 		free_unmap_vmap_area(va);
 
 		write_lock(&vmlist_lock);

-- 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 0/9] vmalloc fixes and improvements

[Linus Torvalds]

On Sat, 8 Nov 2008, npiggin@suse.de wrote:
> 
> The following patches are a set of fixes and improvements for the vmap
> layer.

They seem seriously buggered.

Patches that seem to be authorted by others (judging by sign-off) have no 
such attribution. And because you apparently use some sh*t-for-emailer, 
the patches that _are_ yours are missing your name, because it just says

	From: npiggin@suse.de

without any "Nick Piggin" there.

I'd suggest fixing your emailer scripts regardless, but a "From: " at the 
top of the body would fix both the attribution to others, and give you a 
name too.

PLEASE. Missing authorship attribution is seriously screwed up. Don't do 
it.

			Linus

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 0/9] vmalloc fixes and improvements

[Nick Piggin]

On Fri, Nov 07, 2008 at 09:13:38PM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 8 Nov 2008, npiggin@suse.de wrote:
> > 
> > The following patches are a set of fixes and improvements for the vmap
> > layer.
> 
> They seem seriously buggered.
> 
> Patches that seem to be authorted by others (judging by sign-off) have no 
> such attribution. And because you apparently use some sh*t-for-emailer, 
> the patches that _are_ yours are missing your name, because it just says
> 
> 	From: npiggin@suse.de
> 
> without any "Nick Piggin" there.
> 
> I'd suggest fixing your emailer scripts regardless, but a "From: " at the 
> top of the body would fix both the attribution to others, and give you a 
> name too.

I thought when there is no From in the body, then it defaults to the first
Signed-off-by:. At least Andrew's scripts IIRC have got that right? (unless
it is Andrew fixing it manually).

 
> PLEASE. Missing authorship attribution is seriously screwed up. Don't do 
> it.

Don't merge them.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 0/9] vmalloc fixes and improvements

[Johannes Weiner]

On Sat, Nov 08, 2008 at 06:41:44AM +0100, Nick Piggin wrote:
> On Fri, Nov 07, 2008 at 09:13:38PM -0800, Linus Torvalds wrote:
> > 
> > 
> > On Sat, 8 Nov 2008, npiggin@suse.de wrote:
> > > 
> > > The following patches are a set of fixes and improvements for the vmap
> > > layer.
> > 
> > They seem seriously buggered.
> > 
> > Patches that seem to be authorted by others (judging by sign-off) have no 
> > such attribution. And because you apparently use some sh*t-for-emailer, 
> > the patches that _are_ yours are missing your name, because it just says
> > 
> > 	From: npiggin@suse.de
> > 
> > without any "Nick Piggin" there.
> > 
> > I'd suggest fixing your emailer scripts regardless, but a "From: " at the 
> > top of the body would fix both the attribution to others, and give you a 
> > name too.
> 
> I thought when there is no From in the body, then it defaults to the first
> Signed-off-by:. At least Andrew's scripts IIRC have got that right? (unless
> it is Andrew fixing it manually).

I thought just the last From: line in the raw email text, including
both headers and body.  So it defaults to the header which your mua
sets automatically or you override it with an extra From:-line in the
body to attribute authorship to somebody else.

But you apperently just need to set a --from switch in .quiltrc's
QUILT_MAIL_ARGS.

	Hannes

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 0/9] vmalloc fixes and improvements

[Nick Piggin]

On Sat, Nov 08, 2008 at 04:00:48PM +0100, Johannes Weiner wrote:
> On Sat, Nov 08, 2008 at 06:41:44AM +0100, Nick Piggin wrote:
> > On Fri, Nov 07, 2008 at 09:13:38PM -0800, Linus Torvalds wrote:
> > > 
> > > 
> > > On Sat, 8 Nov 2008, npiggin@suse.de wrote:
> > > > 
> > > > The following patches are a set of fixes and improvements for the vmap
> > > > layer.
> > > 
> > > They seem seriously buggered.
> > > 
> > > Patches that seem to be authorted by others (judging by sign-off) have no 
> > > such attribution. And because you apparently use some sh*t-for-emailer, 
> > > the patches that _are_ yours are missing your name, because it just says
> > > 
> > > 	From: npiggin@suse.de
> > > 
> > > without any "Nick Piggin" there.
> > > 
> > > I'd suggest fixing your emailer scripts regardless, but a "From: " at the 
> > > top of the body would fix both the attribution to others, and give you a 
> > > name too.
> > 
> > I thought when there is no From in the body, then it defaults to the first
> > Signed-off-by:. At least Andrew's scripts IIRC have got that right? (unless
> > it is Andrew fixing it manually).
> 
> I thought just the last From: line in the raw email text, including
> both headers and body.  So it defaults to the header which your mua
> sets automatically or you override it with an extra From:-line in the
> body to attribute authorship to somebody else.
> 
> But you apperently just need to set a --from switch in .quiltrc's
> QUILT_MAIL_ARGS.

OK, will do that. Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [patch 0/9] vmalloc fixes and improvements

[Linus Torvalds]

On Sat, 8 Nov 2008, Nick Piggin wrote:
> 
> I thought when there is no From in the body, then it defaults to the first
> Signed-off-by:

Nope. It defaults to the sender. The first signed-off is _usually_ the 
right choice, and you can use that as a sanity double-check, but I really 
avoid using it for authorship. We actually did that at one point, and it 
was reasonably often seriously screwed up and mis-attributed things.

[ It happened either because the first point in the chain had been some 
  trivial thing that got picked up without sign-off, or because the patch 
  had actually gone back-and-forth and the author signed off after testing 
  or improvements.

  The first case has been getting fairly rare as people get so used to 
  sign-offs, but it still happens. The second case has always been pretty 
  rare, but I'd still rather have it as a "sanity check" than a "blind 
  heuristic" ]

			Linus

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>