Skip to contentSkip to conversation

vmalloc fixes and improvements

PATCH In review [email protected] 3 participants 15 messages Nov 8, 2008 – Nov 9, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

cover vmalloc fixes and improvements

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

Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#1 lore raw

PATCH 1/9 mm: vmalloc allocator off by one

Fix off by one bug in the KVA allocator that can leave gaps in the address space.

---

mm/vmalloc.c +1 -1
Index: 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);
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#2 lore raw

PATCH 2/9 mm: vmalloc failure flush fix

In reply to [email protected]

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.

---

mm/vmalloc.c +13 -2
Index: 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)
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#3 lore raw

PATCH 3/9 mm: vmalloc search restart fix

In reply to [email protected]

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.

---
 mm/vmalloc.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
mm/vmalloc.c +2 -2
Index: 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;
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#4 lore raw

PATCH 4/9 mm: vmalloc tweak failure printk

In reply to [email protected]

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

---
 mm/vmalloc.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
mm/vmalloc.c +3 -2
Index: 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);
 	}
 
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#5 lore raw

PATCH 5/9 mm: vmalloc improve vmallocinfo

In reply to [email protected]

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

---
 mm/vmalloc.c |   12 ++++++++----
 1 files changed, 8 insertions(+), 4 deletions(-)
mm/vmalloc.c +8 -4
Index: 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;
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#6 lore raw

PATCH 6/9 mm: vmalloc guard fix

In reply to [email protected]

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)

---

mm/vmalloc.c +7 -13
Index: 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;
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#7 lore raw

PATCH 7/9 mm: vmalloc use mutex for purge

In reply to [email protected]

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).

---

mm/vmalloc.c +5 -4
Index: 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);
 }
 
 /*
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#8 lore raw

PATCH 8/9 mm: vmalloc make guard configurable

In reply to [email protected]

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

Reworked so the guard size logic remains inside the allocator.

---
 mm/vmalloc.c |   25 +++++++++++++++----------
 1 files changed, 15 insertions(+), 10 deletions(-)
mm/vmalloc.c +11 -1
Index: 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)
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#9 lore raw

PATCH 9/9 mm: vmalloc make lazy unmapping configurable

In reply to [email protected]

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).

---

mm/vmalloc.c +24 -0
Index: 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);
Signature · 5 lines
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#10 lore raw
In reply to [email protected]
Quoted 3 lines · On Sat, 8 Nov 2008, [email protected] 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: [email protected]

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#11 lore raw
Quoted 13 lines · Linus Torvalds
Quoted 3 lines · On Sat, 8 Nov 2008, [email protected] 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

Quoted 7 lines

From: [email protected]

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).

Quoted 2 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#12 lore raw
Quoted 18 lines · Nick Piggin
Quoted 17 lines · Linus Torvalds
Quoted 3 lines · On Sat, 8 Nov 2008, [email protected] 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: [email protected]

without any "Nick Piggin" there.

Quoted 7 lines
Quoted 3 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#13 lore raw
Quoted 27 lines · Johannes Weiner
Quoted 18 lines · Nick Piggin
Quoted 17 lines · Linus Torvalds
Quoted 3 lines · On Sat, 8 Nov 2008, [email protected] 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: [email protected]

without any "Nick Piggin" there.

Quoted 7 lines
Quoted 3 lines

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).

Quoted 7 lines

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

#14 lore raw
In reply to Nick Piggin
Quoted 3 lines · Nick Piggin

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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>