LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: -mm merge plans for 2.6.20
@ 2006-12-05 23:55 Alessandro Guido
  2006-12-06  0:13 ` Andrew Morton
  0 siblings, 1 reply; 61+ messages in thread
From: Alessandro Guido @ 2006-12-05 23:55 UTC (permalink / raw)
  To: akpm; +Cc: linux-kernel

Sorry, I didn't find in your list the patches regarding the sony_acpi
driver that were present in 2.6.19-rc6-mm2. I'm talking about:

2.6-sony_acpi4.patch
sony_apci-resume.patch
acpi-add-backlight-support-to-the-sony_acpi.patch
acpi-add-backlight-support-to-the-sony_acpi-v2.patch

What is the future of these?

Thanks.
                                         Alessandro

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 23:55 -mm merge plans for 2.6.20 Alessandro Guido
@ 2006-12-06  0:13 ` Andrew Morton
  0 siblings, 0 replies; 61+ messages in thread
From: Andrew Morton @ 2006-12-06  0:13 UTC (permalink / raw)
  To: Alessandro Guido; +Cc: linux-kernel

On Wed, 6 Dec 2006 00:55:29 +0100
Alessandro Guido <alessandro.guido@gmail.com> wrote:

> Sorry, I didn't find in your list the patches regarding the sony_acpi
> driver that were present in 2.6.19-rc6-mm2. I'm talking about:
> 
> 2.6-sony_acpi4.patch
> sony_apci-resume.patch
> acpi-add-backlight-support-to-the-sony_acpi.patch
> acpi-add-backlight-support-to-the-sony_acpi-v2.patch
> 
> What is the future of these?
> 

I spose I need to talk Len into merging the sony-acpi driver.

Before that I need to work out why /sys/class/backlight/sony/brightness
magically vanished on me after a suspend-to-ram operation.

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

* Re: -mm merge plans for 2.6.20
  2006-12-19  6:44       ` Dave Jones
@ 2006-12-19  7:02         ` Nick Piggin
  0 siblings, 0 replies; 61+ messages in thread
From: Nick Piggin @ 2006-12-19  7:02 UTC (permalink / raw)
  To: Dave Jones; +Cc: Andrew Morton, linux-kernel, Hugh Dickins, Chris Rankin

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

Dave Jones wrote:
> On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
>  > Dave Jones wrote:
>  > 
>  > > Eeek! page_mapcount(page) went negative! (-2)
>  > 
>  > Hmm, probably happened once before, too.
> 
> You're right. Going back further in the log, I noticed
> that it had happened again exactly at the time that cron restarted vpnc.
> The first time, the flags were different..
> 
>  Dec  4 00:01:03 firewall kernel: Eeek! page_mapcount(page) went negative! (-1)
>  Dec  4 00:01:03 firewall kernel:   page->flags = 400
>  Dec  4 00:01:03 firewall kernel:   page->count = 1
>  Dec  4 00:01:03 firewall kernel:   page->mapping = 00000000

Still reserved, with a NULL mapping. I'd say it could be the same page.

> 
>  > >   page->flags = 404
>  > 
>  > What's that? PG_referenced|PG_reserved? So I'd say it is likely
>  > that some driver has got its refcounting wrong.
> 
> At the time that it bit me, here's what was loaded..
> 
> tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6
> ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac
> parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine
> via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3
> jbd ehci_hcd ohci_hcd uhci_hcd
> 
> The scary ones (i2c, irda) weren't in use at all, and had never been opened afaik,
> so the potential for those to be corrupting memory is slim, but not out of the
> question. (Why the hell asus_acpi is loaded is a mystery, this isn't an Asus,
> or a laptop. Probably dumb initscripts).

OK that could be useful if I do some grepping and see which ones are
setting PG_reserved.

>  > And I see we've got another report for 2.6.19.1 from Chris, which
>  > is equally vague.
> 
> I'll be moving that box to 2.6.19.x at some point real soon, so I'll holler
> if I see it again on a later kernel.
> 
>  > IMO the pattern is much too consistent to be able to attribute
>  > them all to hardware problems. And considering it takes so long
>  > for these things to appear, can we get something like the attached
>  > patch upstream at least until we manage to stamp them out?
> 
> Sounds like a good idea to me.
> 
> ACKed-by: Dave Jones <davej@redhat.com>

Thanks.

> 
>  > Any other debugging info we can add?
> 
> Would it be useful to print the pfn of the page ?
> In cases like mine, where it bit twice before it killed the box, it
> might be interesting to see if its always the same page.  Not sure
> what that would prove/disprove though.

Might help. I guess the site where it is allocated from might be
another one, although I'm hoping that if we know what ->nopage is
being used then we'll be able to track it. OTOH it may be using
remap_pfn_range from fops->mmap, rather than nopage... I wonder
how we could get at that info? vma->vm_file->f_op->mmap?

-- 
SUSE Labs, Novell Inc.

[-- Attachment #2: mm-rmap-debug-more.patch --]
[-- Type: text/plain, Size: 4401 bytes --]

Index: linux-2.6/include/linux/rmap.h
===================================================================
--- linux-2.6.orig/include/linux/rmap.h	2006-12-04 19:56:17.000000000 +1100
+++ linux-2.6/include/linux/rmap.h	2006-12-19 16:14:30.000000000 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
 void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
 void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
 void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);
 
 /**
  * page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===================================================================
--- linux-2.6.orig/mm/filemap_xip.c	2006-12-04 19:07:10.000000000 +1100
+++ linux-2.6/mm/filemap_xip.c	2006-12-19 16:14:30.000000000 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
 			/* Nuke the page table entry. */
 			flush_cache_page(vma, address, pte_pfn(*pte));
 			pteval = ptep_clear_flush(vma, address, pte);
-			page_remove_rmap(page);
+			page_remove_rmap(page, vma);
 			dec_mm_counter(mm, file_rss);
 			BUG_ON(pte_dirty(pteval));
 			pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===================================================================
--- linux-2.6.orig/mm/fremap.c	2006-12-04 19:56:20.000000000 +1100
+++ linux-2.6/mm/fremap.c	2006-12-19 16:14:30.000000000 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
 		if (page) {
 			if (pte_dirty(pte))
 				set_page_dirty(page);
-			page_remove_rmap(page);
+			page_remove_rmap(page, vma);
 			page_cache_release(page);
 		}
 	} else {
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c	2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/memory.c	2006-12-19 16:14:30.000000000 +1100
@@ -681,7 +681,7 @@ static unsigned long zap_pte_range(struc
 					mark_page_accessed(page);
 				file_rss--;
 			}
-			page_remove_rmap(page);
+			page_remove_rmap(page, vma);
 			tlb_remove_page(tlb, page);
 			continue;
 		}
@@ -1576,7 +1576,7 @@ gotten:
 	page_table = pte_offset_map_lock(mm, pmd, address, &ptl);
 	if (likely(pte_same(*page_table, orig_pte))) {
 		if (old_page) {
-			page_remove_rmap(old_page);
+			page_remove_rmap(old_page, vma);
 			if (!PageAnon(old_page)) {
 				dec_mm_counter(mm, file_rss);
 				inc_mm_counter(mm, anon_rss);
Index: linux-2.6/mm/rmap.c
===================================================================
--- linux-2.6.orig/mm/rmap.c	2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/rmap.c	2006-12-19 18:02:18.000000000 +1100
@@ -47,6 +47,7 @@
 #include <linux/rmap.h>
 #include <linux/rcupdate.h>
 #include <linux/module.h>
+#include <linux/kallsyms.h>
 
 #include <asm/tlbflush.h>
 
@@ -567,14 +568,20 @@ void page_add_file_rmap(struct page *pag
  *
  * The caller needs to hold the pte lock.
  */
-void page_remove_rmap(struct page *page)
+void page_remove_rmap(struct page *page, struct vm_area_struct *vma)
 {
 	if (atomic_add_negative(-1, &page->_mapcount)) {
 		if (unlikely(page_mapcount(page) < 0)) {
 			printk (KERN_EMERG "Eeek! page_mapcount(page) went negative! (%d)\n", page_mapcount(page));
+			printk (KERN_EMERG "  page pfn = %lx\n", page_to_pfn(page));
 			printk (KERN_EMERG "  page->flags = %lx\n", page->flags);
 			printk (KERN_EMERG "  page->count = %x\n", page_count(page));
 			printk (KERN_EMERG "  page->mapping = %p\n", page->mapping);
+			print_symbol (KERN_EMERG "  vma->vm_ops = %s\n", (unsigned long)vma->vm_ops);
+			if (vma->vm_ops)
+				print_symbol (KERN_EMERG "  vma->vm_ops->nopage = %s\n", (unsigned long)vma->vm_ops->nopage);
+			if (vma->vm_file && vma->vm_file->f_op)
+				print_symbol (KERN_EMERG "  vma->vm_file->f_op->mmap = %s\n", (unsigned long)vma->vm_file->f_op->mmap);
 			BUG();
 		}
 
@@ -679,7 +686,7 @@ static int try_to_unmap_one(struct page 
 		dec_mm_counter(mm, file_rss);
 
 
-	page_remove_rmap(page);
+	page_remove_rmap(page, vma);
 	page_cache_release(page);
 
 out_unmap:
@@ -769,7 +776,7 @@ static void try_to_unmap_cluster(unsigne
 		if (pte_dirty(pteval))
 			set_page_dirty(page);
 
-		page_remove_rmap(page);
+		page_remove_rmap(page, vma);
 		page_cache_release(page);
 		dec_mm_counter(mm, file_rss);
 		(*mapcount)--;

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

* Re: -mm merge plans for 2.6.20
  2006-12-19  5:20     ` Nick Piggin
@ 2006-12-19  6:44       ` Dave Jones
  2006-12-19  7:02         ` Nick Piggin
  0 siblings, 1 reply; 61+ messages in thread
From: Dave Jones @ 2006-12-19  6:44 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Andrew Morton, linux-kernel, Hugh Dickins, Chris Rankin

On Tue, Dec 19, 2006 at 04:20:37PM +1100, Nick Piggin wrote:
 > Dave Jones wrote:
 > 
 > > Eeek! page_mapcount(page) went negative! (-2)
 > 
 > Hmm, probably happened once before, too.

You're right. Going back further in the log, I noticed
that it had happened again exactly at the time that cron restarted vpnc.
The first time, the flags were different..

 Dec  4 00:01:03 firewall kernel: Eeek! page_mapcount(page) went negative! (-1)
 Dec  4 00:01:03 firewall kernel:   page->flags = 400
 Dec  4 00:01:03 firewall kernel:   page->count = 1
 Dec  4 00:01:03 firewall kernel:   page->mapping = 00000000

 > >   page->flags = 404
 > 
 > What's that? PG_referenced|PG_reserved? So I'd say it is likely
 > that some driver has got its refcounting wrong.

At the time that it bit me, here's what was loaded..

tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac
parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine
via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3
jbd ehci_hcd ohci_hcd uhci_hcd

The scary ones (i2c, irda) weren't in use at all, and had never been opened afaik,
so the potential for those to be corrupting memory is slim, but not out of the
question. (Why the hell asus_acpi is loaded is a mystery, this isn't an Asus,
or a laptop. Probably dumb initscripts).

 > And I see we've got another report for 2.6.19.1 from Chris, which
 > is equally vague.

I'll be moving that box to 2.6.19.x at some point real soon, so I'll holler
if I see it again on a later kernel.

 > IMO the pattern is much too consistent to be able to attribute
 > them all to hardware problems. And considering it takes so long
 > for these things to appear, can we get something like the attached
 > patch upstream at least until we manage to stamp them out?

Sounds like a good idea to me.

ACKed-by: Dave Jones <davej@redhat.com>

 > Any other debugging info we can add?

Would it be useful to print the pfn of the page ?
In cases like mine, where it bit twice before it killed the box, it
might be interesting to see if its always the same page.  Not sure
what that would prove/disprove though.

		Dave

-- 
http://www.codemonkey.org.uk

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

* Re: -mm merge plans for 2.6.20
  2006-12-12 17:49   ` Dave Jones
@ 2006-12-19  5:20     ` Nick Piggin
  2006-12-19  6:44       ` Dave Jones
  0 siblings, 1 reply; 61+ messages in thread
From: Nick Piggin @ 2006-12-19  5:20 UTC (permalink / raw)
  To: Dave Jones; +Cc: Andrew Morton, linux-kernel, Hugh Dickins, Chris Rankin

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

Dave Jones wrote:

> Eeek! page_mapcount(page) went negative! (-2)

Hmm, probably happened once before, too.

>   page->flags = 404

What's that? PG_referenced|PG_reserved? So I'd say it is likely
that some driver has got its refcounting wrong.

Unfortunately, this debugging output is almost useless when it
comes to trying to track down the problem any further.

And I see we've got another report for 2.6.19.1 from Chris, which
is equally vague.

IMO the pattern is much too consistent to be able to attribute
them all to hardware problems. And considering it takes so long
for these things to appear, can we get something like the attached
patch upstream at least until we manage to stamp them out? Any
other debugging info we can add?

-- 
SUSE Labs, Novell Inc.

[-- Attachment #2: mm-rmap-debug-more.patch --]
[-- Type: text/plain, Size: 4146 bytes --]

Index: linux-2.6/include/linux/rmap.h
===================================================================
--- linux-2.6.orig/include/linux/rmap.h	2006-12-04 19:56:17.000000000 +1100
+++ linux-2.6/include/linux/rmap.h	2006-12-19 16:14:30.000000000 +1100
@@ -72,7 +72,7 @@ void __anon_vma_link(struct vm_area_stru
 void page_add_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
 void page_add_new_anon_rmap(struct page *, struct vm_area_struct *, unsigned long);
 void page_add_file_rmap(struct page *);
-void page_remove_rmap(struct page *);
+void page_remove_rmap(struct page *, struct vm_area_struct *);
 
 /**
  * page_dup_rmap - duplicate pte mapping to a page
Index: linux-2.6/mm/filemap_xip.c
===================================================================
--- linux-2.6.orig/mm/filemap_xip.c	2006-12-04 19:07:10.000000000 +1100
+++ linux-2.6/mm/filemap_xip.c	2006-12-19 16:14:30.000000000 +1100
@@ -189,7 +189,7 @@ __xip_unmap (struct address_space * mapp
 			/* Nuke the page table entry. */
 			flush_cache_page(vma, address, pte_pfn(*pte));
 			pteval = ptep_clear_flush(vma, address, pte);
-			page_remove_rmap(page);
+			page_remove_rmap(page, vma);
 			dec_mm_counter(mm, file_rss);
 			BUG_ON(pte_dirty(pteval));
 			pte_unmap_unlock(pte, ptl);
Index: linux-2.6/mm/fremap.c
===================================================================
--- linux-2.6.orig/mm/fremap.c	2006-12-04 19:56:20.000000000 +1100
+++ linux-2.6/mm/fremap.c	2006-12-19 16:14:30.000000000 +1100
@@ -33,7 +33,7 @@ static int zap_pte(struct mm_struct *mm,
 		if (page) {
 			if (pte_dirty(pte))
 				set_page_dirty(page);
-			page_remove_rmap(page);
+			page_remove_rmap(page, vma);
 			page_cache_release(page);
 		}
 	} else {
Index: linux-2.6/mm/memory.c
===================================================================
--- linux-2.6.orig/mm/memory.c	2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/memory.c	2006-12-19 16:14:30.000000000 +1100
@@ -681,7 +681,7 @@ static unsigned long zap_pte_range(struc
 					mark_page_accessed(page);
 				file_rss--;
 			}
-			page_remove_rmap(page);
+			page_remove_rmap(page, vma);
 			tlb_remove_page(tlb, page);
 			continue;
 		}
@@ -1576,7 +1576,7 @@ gotten:
 	page_table = pte_offset_map_lock(mm, pmd, address, &ptl);
 	if (likely(pte_same(*page_table, orig_pte))) {
 		if (old_page) {
-			page_remove_rmap(old_page);
+			page_remove_rmap(old_page, vma);
 			if (!PageAnon(old_page)) {
 				dec_mm_counter(mm, file_rss);
 				inc_mm_counter(mm, anon_rss);
Index: linux-2.6/mm/rmap.c
===================================================================
--- linux-2.6.orig/mm/rmap.c	2006-12-04 19:56:21.000000000 +1100
+++ linux-2.6/mm/rmap.c	2006-12-19 16:20:13.000000000 +1100
@@ -47,6 +47,7 @@
 #include <linux/rmap.h>
 #include <linux/rcupdate.h>
 #include <linux/module.h>
+#include <linux/kallsyms.h>
 
 #include <asm/tlbflush.h>
 
@@ -567,7 +568,7 @@ void page_add_file_rmap(struct page *pag
  *
  * The caller needs to hold the pte lock.
  */
-void page_remove_rmap(struct page *page)
+void page_remove_rmap(struct page *page, struct vm_area_struct *vma)
 {
 	if (atomic_add_negative(-1, &page->_mapcount)) {
 		if (unlikely(page_mapcount(page) < 0)) {
@@ -575,6 +576,9 @@ void page_remove_rmap(struct page *page)
 			printk (KERN_EMERG "  page->flags = %lx\n", page->flags);
 			printk (KERN_EMERG "  page->count = %x\n", page_count(page));
 			printk (KERN_EMERG "  page->mapping = %p\n", page->mapping);
+			print_symbol (KERN_EMERG "  vma->vm_ops = %s\n", (unsigned long)vma->vm_ops);
+			if (vma->vm_ops)
+				print_symbol (KERN_EMERG "  vma->vm_ops->nopage = %s\n", (unsigned long)vma->vm_ops->nopage);
 			BUG();
 		}
 
@@ -679,7 +683,7 @@ static int try_to_unmap_one(struct page 
 		dec_mm_counter(mm, file_rss);
 
 
-	page_remove_rmap(page);
+	page_remove_rmap(page, vma);
 	page_cache_release(page);
 
 out_unmap:
@@ -769,7 +773,7 @@ static void try_to_unmap_cluster(unsigne
 		if (pte_dirty(pteval))
 			set_page_dirty(page);
 
-		page_remove_rmap(page);
+		page_remove_rmap(page, vma);
 		page_cache_release(page);
 		dec_mm_counter(mm, file_rss);
 		(*mapcount)--;

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

* Re: -mm merge plans for 2.6.20
@ 2006-12-13  1:09 Chuck Ebbert
  0 siblings, 0 replies; 61+ messages in thread
From: Chuck Ebbert @ 2006-12-13  1:09 UTC (permalink / raw)
  To: Dave Jones; +Cc: Andrew Morton, linux-kernel

In-Reply-To: <20061212174909.GD2140@redhat.com>

On Tue, 12 Dec 2006 12:49:09 -0500, Dave Jones wrote:

> EFLAGS: 00010246   (2.6.18-1.2849.fc6 #1) 

> That was from a 2.6.18.3 kernel iirc.

Here's an idea from Michael Tokarev <mjt@tls.msk.ru>:
since .version always contains 1 when you build an RPM,
you can modify it and put your base kernel version there
during the build. Then you would see:

EFLAGS: 00010246   (2.6.18-1.2849.fc6 #2.6.18.3)

-- 
MBTI: IXTP


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

* Re: -mm merge plans for 2.6.20
  2006-12-05 16:02 ` Dave Jones
@ 2006-12-12 17:49   ` Dave Jones
  2006-12-19  5:20     ` Nick Piggin
  0 siblings, 1 reply; 61+ messages in thread
From: Dave Jones @ 2006-12-12 17:49 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel

On Tue, Dec 05, 2006 at 11:02:50AM -0500, Dave Jones wrote:
 > On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:
 >  
 >  > cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
 >  > remove-hotplug-cpu-crap-from-cpufreq.patch
 >  > cpufreq-select-consistently-re-2619-rc5-mm1.patch
 >  > cpufreq-set-policy-curfreq-on-initialization.patch
 >  > bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch
 >  > 
 >  > Sent to cpufreq maintainer
 > 
 > I'm travelling right now, and somehow managed to oops my home router
 > 3000 miles away making it hard for me to access mail & stuff.
 > (That "page count went negative" BUG() bit me when I did a killall -9 vpnc)

Finally managed to fish this out of the logs..


Eeek! page_mapcount(page) went negative! (-2)
  page->flags = 404
  page->count = 1
  page->mapping = 00000000
------------[ cut here ]------------
kernel BUG at mm/rmap.c:587!
invalid opcode: 0000 [#2]
SMP 
last sysfs file: /class/net/lo/type
Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat ipt_LOG xt_limit ipv6 ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables video sbs i2c_ec button battery asus_acpi ac parport_pc lp parport pcspkr ide_cd i2c_viapro i2c_core cdrom 3c59x via_rhine via_ircc mii irda crc_ccitt serio_raw dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
CPU:    0
EIP:    0060:[<c046396c>]    Not tainted VLI
EFLAGS: 00010246   (2.6.18-1.2849.fc6 #1) 
EIP is at page_remove_rmap+0x8b/0xac
eax: 00000000   ebx: c1000000   ecx: ffffffff   edx: 00000046
esi: dcaa2f98   edi: 00000020   ebp: cd3f7f00   esp: cd3e4ddc
ds: 007b   es: 007b   ss: 0068
Process vpnc (pid: 3367, ti=cd3e4000 task=cd3a0b50 task.ti=cd3e4000)
Stack: c0638bad 00000000 c1000000 09bc0000 c045e199 00000000 dcaa2f98 cd3e4e54 
       003ebff8 00000000 00000001 09bdb000 cd377098 c1624a80 c13e5f60 fffffffa 
       ffffffff c1624ad4 cd377098 09bdb000 00000000 cd3e4e54 c1485d4c c1624a80 
Call Trace:
 [<c045e199>] unmap_vmas+0x28e/0x504
 [<c0460c0f>] exit_mmap+0x77/0xf1
 [<c0422d75>] mmput+0x34/0x7a
 [<c0427818>] do_exit+0x20b/0x776
 [<c0427df9>] sys_exit_group+0x0/0xd
 [<cd39a644>] 0xcd39a644
DWARF2 unwinder stuck at 0xcd39a644
Leftover inexact backtrace:
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0430828>] get_signal_to_deliver+0x38b/0x3b3
 [<c04068d1>] do_IRQ+0xb0/0xbc
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0403626>] do_notify_resume+0x7e/0x6c1
 [<c045f135>] __handle_mm_fault+0x82c/0x860
 [<c04068d1>] do_IRQ+0xb0/0xbc
 [<c061455e>] _spin_unlock_irq+0x5/0x7
 [<c0612ccc>] schedule+0x960/0x9dd
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c04040a2>] work_notifysig+0x13/0x19
 =======================
Code: 82 1e fc ff 8b 43 10 c7 04 24 ad 8b 63 c0 89 44 24 04 e8 6f 1e fc ff 8b 46 40 85 c0 74 0d 8b 50 08 b8 c6 8b 63 c0 e8 07 ce fd ff <0f> 0b 4b 02 42 8b 63 c0 8b 53 10 89 d8 59 5b 5b 5e 83 f2 01 83 
EIP: [<c046396c>] page_remove_rmap+0x8b/0xac SS:ESP 0068:cd3e4ddc
 <3>BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():1, irqs_disabled():0
 [<c04051db>] dump_trace+0x69/0x1af
 [<c0405339>] show_trace_log_lvl+0x18/0x2c
 [<c04058ed>] show_trace+0xf/0x11
 [<c04059ea>] dump_stack+0x15/0x17
 [<c04394a2>] down_read+0x12/0x20
 [<c0431601>] blocking_notifier_call_chain+0xe/0x29
 [<c0427628>] do_exit+0x1b/0x776
 [<c040588e>] die+0x29d/0x2c2
 [<c0405fd3>] do_invalid_op+0xa2/0xab
 [<c0404b85>] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
 [<c046396c>] page_remove_rmap+0x8b/0xac
 [<c045e199>] unmap_vmas+0x28e/0x504
 [<c0460c0f>] exit_mmap+0x77/0xf1
 [<c0422d75>] mmput+0x34/0x7a
 [<c0427818>] do_exit+0x20b/0x776
 [<c042f153>] __dequeue_signal+0x151/0x15c
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0427df9>] sys_exit_group+0x0/0xd
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0430828>] get_signal_to_deliver+0x38b/0x3b3
 [<c04068d1>] do_IRQ+0xb0/0xbc
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0403626>] do_notify_resume+0x7e/0x6c1
 [<c045f135>] __handle_mm_fault+0x82c/0x860
 [<c04068d1>] do_IRQ+0xb0/0xbc
 [<c061455e>] _spin_unlock_irq+0x5/0x7
 [<c0612ccc>] schedule+0x960/0x9dd
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c04040a2>] work_notifysig+0x13/0x19
 =======================
Fixing recursive fault but reboot is needed!
BUG: scheduling while atomic: vpnc/0x00000001/3367
 [<c04051db>] dump_trace+0x69/0x1af
 [<c0405339>] show_trace_log_lvl+0x18/0x2c
 [<c04058ed>] show_trace+0xf/0x11
 [<c04059ea>] dump_stack+0x15/0x17
 [<c06123af>] schedule+0x43/0x9dd
 [<c04276f7>] do_exit+0xea/0x776
 [<c040588e>] die+0x29d/0x2c2
 [<c0405fd3>] do_invalid_op+0xa2/0xab
 [<c0404b85>] error_code+0x39/0x40
DWARF2 unwinder stuck at error_code+0x39/0x40
Leftover inexact backtrace:
 [<c046396c>] page_remove_rmap+0x8b/0xac
 [<c045e199>] unmap_vmas+0x28e/0x504
 [<c0460c0f>] exit_mmap+0x77/0xf1
 [<c0422d75>] mmput+0x34/0x7a
 [<c0427818>] do_exit+0x20b/0x776
 [<c042f153>] __dequeue_signal+0x151/0x15c
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0427df9>] sys_exit_group+0x0/0xd
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0430828>] get_signal_to_deliver+0x38b/0x3b3
 [<c04068d1>] do_IRQ+0xb0/0xbc
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c0403626>] do_notify_resume+0x7e/0x6c1
 [<c045f135>] __handle_mm_fault+0x82c/0x860
 [<c04068d1>] do_IRQ+0xb0/0xbc
 [<c061455e>] _spin_unlock_irq+0x5/0x7
 [<c0612ccc>] schedule+0x960/0x9dd
 [<c0615375>] do_page_fault+0x0/0x4db
 [<c04040a2>] work_notifysig+0x13/0x19
 =======================


That was from a 2.6.18.3 kernel iirc.

		Dave

-- 
http://www.codemonkey.org.uk

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

* Re: -mm merge plans for 2.6.20
@ 2006-12-11  9:32 Chuck Ebbert
  0 siblings, 0 replies; 61+ messages in thread
From: Chuck Ebbert @ 2006-12-11  9:32 UTC (permalink / raw)
  To: Steve French
  Cc: linux-cifs-client, Jeremy Allison, simo, Shirish S Pargaonkar,
	linux-kernel, akpm

In-Reply-To: <457CDC38.2090907@us.ibm.com>

On Sun, 10 Dec 2006 22:19:04 -0600, Steve French wrote:

> I don't remember any problems reported with plain text password
> support on current cifs and I have certainly seen it negotiated with no 
> problem,
> but I will double check with your reported flag combination.

I played around with it some more.

With SecurityFlags = 0x7 (default) the server asks for a plaintext
password and the client refuses.  That's fine.

With 0x37 the client agrees to send a plaintext password (or at least
fails to reject the server's request for one,) but actually sends:

<         ANSI Password Length: 24
<         Unicode Password Length: 24

<         ANSI Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C
<         Unicode Password: 3577D3557009178AFF455A0F7A99C6585CAEF99C515F2F2C

(my password was aaaaaaaa).  This fails with error -13 (invalid password.)

With 0x30 the client sends:

>         Password Length: 24

>         Password: 61616161616161610000000000000000681C1DCF00002200

and everything works.

> > Also, the client doesn't automatically pick up the domain name from
> > smb.conf like smbfs does.
> >
> >   
> That is true, and is intentional.   cifs sends a domain of null (ie use 
> the server's
> default domain) - but it can be overridden on mount

That's OK then.  I just happened to notice it when I was comparing
traces of smbfs mounts to the ones from cifs.  Maybe the manpage should
mention this difference for those who are converting, though.

-- 
MBTI: IXTP

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

* Re: -mm merge plans for 2.6.20
  2006-12-10  3:18 Chuck Ebbert
@ 2006-12-11  4:19 ` Steve French
  0 siblings, 0 replies; 61+ messages in thread
From: Steve French @ 2006-12-11  4:19 UTC (permalink / raw)
  To: Chuck Ebbert
  Cc: akpm, linux-kernel, Shirish S Pargaonkar, simo, Jeremy Allison,
	linux-cifs-client

Chuck Ebbert wrote:
> In-Reply-To: <4579AFA5.90003@us.ibm.com>
>
> On Fri, 08 Dec 2006 12:32:05 -0600, Steve French wrote:
>
>   
>> smbfs deprecation is ok but there are a few things to consider:
>>     
>
> How well-tested is the plaintext password support?
>
> By default the /proc/fs/cifs/SecurityFlags setting is 0x7 (MAY_SIGN |
> MAY_NTLM | MAYNTLMV2). Trying to connect to an old Samba server
> with that, I got a message that the server requested a plain text
> password but client support was disabled.
>
> After changing the flags to 0x37 (adding MAY_LANMAN | MAY_PLNTXT),
> I got "invalid password." Looking at the ethereal traces, it seemed
> that the password was being sent as encrypted Unicode, and the only
> way to make it connect was to set the flags to 0x30.
>   
I don't remember any problems reported with plain text password
support on current cifs and I have certainly seen it negotiated with no 
problem,
but I will double check with your reported flag combination.
> Also, the client doesn't automatically pick up the domain name from
> smb.conf like smbfs does.
>
>   
That is true, and is intentional.   cifs sends a domain of null (ie use 
the server's
default domain) - but it can be overridden on mount

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

* Re: -mm merge plans for 2.6.20
  2006-12-09  9:44   ` Andrew Morton
@ 2006-12-10 20:12     ` Randy Dunlap
  0 siblings, 0 replies; 61+ messages in thread
From: Randy Dunlap @ 2006-12-10 20:12 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Sat, 9 Dec 2006 01:44:45 -0800 Andrew Morton wrote:

> On Sat, 9 Dec 2006 01:30:55 -0800
> Randy Dunlap <randy.dunlap@oracle.com> wrote:
> 
> > On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote:
> > 
> > > kconfig-new-function-bool-conf_get_changedvoid.patch
> > > kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
> > > kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
> > > kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
> > > pa-risc-fix-bogus-warnings-from-modpost.patch
> > > kconfig-refactoring-for-better-menu-nesting.patch
> > > kbuild-fix-rr-is-now-default.patch
> > > kbuild-dont-put-temp-files-in-the-source-tree.patch
> > > actually-delete-the-as-instr-ld-option-tmp-file.patch
> > > 
> > >  Sent to Sam, but Sam's presently busy.  I might need to make some kbuild
> > >  decisions..
> > 
> > <groan> /me digs thru 65 KB email.
> > 
> > 
> > I can/will help on some of these if you want it...
> > 
> 
> feel free.  I'm planning on going through the above, see which of then have
> a sufficiently high obviousness*urgency product.

I see that you merged a few (or one?) of these. (obvious ones)

My review didn't come up with much help, I'm afraid.  And you
already asked for help on the series-of-4 gui-config patches.


actually-delete-the-as-instr-ld-option-tmp-file.patch
	I couldn't find this patch.

pa-risc-fix-bogus-warnings-from-modpost.patch
	looks obvious w/ medium priority

I'm little help on the Makefile changes, sorry.

My -git15 build finds lots of Section mismatch problems with
.parainstructions.  These could be false reports that need a
change in modpost (section checker).  I'll look into that
later today.

---
~Randy

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

* Re: -mm merge plans for 2.6.20
  2006-12-08 20:58   ` Andrew Morton
@ 2006-12-10 15:07     ` Mimi Zohar
  0 siblings, 0 replies; 61+ messages in thread
From: Mimi Zohar @ 2006-12-10 15:07 UTC (permalink / raw)
  To: Andrew Morton
  Cc: David Safford, kjhall, linux-kernel, Stephen Smalley, Serge E Hallyn


Andrew Morton <akpm@osdl.org> wrote on 12/08/2006 03:58:51 PM:

> > >  Shall hold in -mm.
> > Why?
>
> They're on hold awaiting further development and awaiting a
merge/no-merge
> They're not causing me any trouble.

Thank you!  We are getting ready to re-release EVM as an integrity
provider. As this version of EVM will not be using the LSM hooks,
which mailing list should we be posting the code?

As for SLIM, we will be addressing Stephen's comments and
submitting changes as necessary shortly thereafter.

Mimi Zohar


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

* Re: -mm merge plans for 2.6.20
@ 2006-12-10  3:18 Chuck Ebbert
  2006-12-11  4:19 ` Steve French
  0 siblings, 1 reply; 61+ messages in thread
From: Chuck Ebbert @ 2006-12-10  3:18 UTC (permalink / raw)
  To: Steve French
  Cc: akpm, linux-kernel, Shirish S Pargaonkar, simo, Jeremy Allison,
	linux-cifs-client

In-Reply-To: <4579AFA5.90003@us.ibm.com>

On Fri, 08 Dec 2006 12:32:05 -0600, Steve French wrote:

> smbfs deprecation is ok but there are a few things to consider:

> 2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support

How well-tested is the plaintext password support?

By default the /proc/fs/cifs/SecurityFlags setting is 0x7 (MAY_SIGN |
MAY_NTLM | MAYNTLMV2). Trying to connect to an old Samba server
with that, I got a message that the server requested a plain text
password but client support was disabled.

After changing the flags to 0x37 (adding MAY_LANMAN | MAY_PLNTXT),
I got "invalid password." Looking at the ethereal traces, it seemed
that the password was being sent as encrypted Unicode, and the only
way to make it connect was to set the flags to 0x30.

Also, the client doesn't automatically pick up the domain name from
smb.conf like smbfs does.

-- 
Chuck
"Even supernovas have their duller moments."


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

* Re: -mm merge plans for 2.6.20
  2006-12-09  9:30 ` Randy Dunlap
@ 2006-12-09  9:44   ` Andrew Morton
  2006-12-10 20:12     ` Randy Dunlap
  0 siblings, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2006-12-09  9:44 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: linux-kernel

On Sat, 9 Dec 2006 01:30:55 -0800
Randy Dunlap <randy.dunlap@oracle.com> wrote:

> On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote:
> 
> > kconfig-new-function-bool-conf_get_changedvoid.patch
> > kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
> > kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
> > kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
> > pa-risc-fix-bogus-warnings-from-modpost.patch
> > kconfig-refactoring-for-better-menu-nesting.patch
> > kbuild-fix-rr-is-now-default.patch
> > kbuild-dont-put-temp-files-in-the-source-tree.patch
> > actually-delete-the-as-instr-ld-option-tmp-file.patch
> > 
> >  Sent to Sam, but Sam's presently busy.  I might need to make some kbuild
> >  decisions..
> 
> <groan> /me digs thru 65 KB email.
> 
> 
> I can/will help on some of these if you want it...
> 

feel free.  I'm planning on going through the above, see which of then have
a sufficiently high obviousness*urgency product.

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (11 preceding siblings ...)
  2006-12-08 14:09 ` Stephen Smalley
@ 2006-12-09  9:30 ` Randy Dunlap
  2006-12-09  9:44   ` Andrew Morton
  12 siblings, 1 reply; 61+ messages in thread
From: Randy Dunlap @ 2006-12-09  9:30 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, 4 Dec 2006 20:40:24 -0800 Andrew Morton wrote:

> kconfig-new-function-bool-conf_get_changedvoid.patch
> kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
> kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
> kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
> pa-risc-fix-bogus-warnings-from-modpost.patch
> kconfig-refactoring-for-better-menu-nesting.patch
> kbuild-fix-rr-is-now-default.patch
> kbuild-dont-put-temp-files-in-the-source-tree.patch
> actually-delete-the-as-instr-ld-option-tmp-file.patch
> 
>  Sent to Sam, but Sam's presently busy.  I might need to make some kbuild
>  decisions..

<groan> /me digs thru 65 KB email.


I can/will help on some of these if you want it...

---
~Randy

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

* Re: -mm merge plans for 2.6.20
  2006-12-08 18:32 Steve French
@ 2006-12-08 21:38 ` Andrew Morton
  0 siblings, 0 replies; 61+ messages in thread
From: Andrew Morton @ 2006-12-08 21:38 UTC (permalink / raw)
  To: Steve French
  Cc: linux-kernel, Shirish S Pargaonkar, simo, Jeremy Allison,
	linux-cifs-client

On Fri, 08 Dec 2006 12:32:05 -0600
Steve French <smfltc@us.ibm.com> wrote:

> akpm wrote:
> >deprecate-smbfs-in-favour-of-cifs.patch
> >deprecate-smbfs-in-favour-of-cifs-docs.patch
> >
> > Am still waiting to hear from sfrench on the appropriateness of this.
> 
> 
> smbfs deprecation is ok but there are a few things to consider:

OK, thanks for the update.  We would like to make smbfs go away asap, but
from my POV it's up to you to say when we should do that.

otoh, it might be a good idea to merge a variant of that patch which
doesn't mention a specific data.  Say,

	if (warn_count < 5) {
		warn_count++;
		printk(KERN_EMERG "smbfs is not being maintained."
			" Please migrate to cifs\n");
	}

?

> 
> ...
>
> Running simple tests on smbfs, I run into so many problems now though, it
> is probably time to mark it as deprecated as Fedora etc. apparently 
> already have.

No, smbfs is not in very good shape.



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

* Re: -mm merge plans for 2.6.20
  2006-12-08 14:09 ` Stephen Smalley
@ 2006-12-08 20:58   ` Andrew Morton
  2006-12-10 15:07     ` Mimi Zohar
  0 siblings, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2006-12-08 20:58 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: linux-kernel, Mimi Zohar, Kylene Hall, Dave Safford, Mimi Zohar,
	Serge Hallyn

On Fri, 08 Dec 2006 09:09:34 -0500
Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote:
> > mprotect-patch-for-use-by-slim.patch
> > integrity-service-api-and-dummy-provider.patch
> > integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch
> > integrity-service-api-and-dummy-provider-compilation-warning-fix.patch
> > slim-main-patch.patch
> > slim-main-patch-socket_post_create-hook-return-code.patch
> > slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch
> > slim-main-patch-handle-failure-to-register.patch
> > slim-main-patch-fix-bug-with-mm_users-usage.patch
> > slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch
> > slim-secfs-patch.patch
> > slim-secfs-patch-slim-correct-use-of-snprintf.patch
> > slim-secfs-patch-cleanup-use-of-configh.patch
> > slim-make-and-config-stuff.patch
> > slim-make-and-config-stuff-makefile-fix.patch
> > slim-debug-output.patch
> > slim-fix-security-issue-with-the-task_post_setuid-hook.patch
> > slim-secfs-inode-i_private-build-fix.patch
> > slim-documentation.patch
> > fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch
> > 
> >  Shall hold in -mm.
> 
> Why?

They're on hold awaiting further development and awaiting a merge/no-merge
decision.

They're not causing me any trouble.

>  I haven't seen any evidence that prior review comments have been
> addressed so far, and a fresh patch set would be beneficial anyway to
> facilitate full review of the updated code and to allow them to fix
> their patch descriptions as well (as they were wrong in some instances,
> describing older versions of the code).

If/when the developers start doing more work, we can then decide whether
to use incremental patches or to take a drop-them-and-start-again approach.

(If a whole new patch series comes out, I have tricks which allow me to
check that none of the above fixup patches got lost.  Those tricks don't
work if I drop all the patches first)

But yes, it has been pretty quiet.  If there's no intention to proceed with
these patches, someone please tell me.

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

* Re: -mm merge plans for 2.6.20
@ 2006-12-08 18:32 Steve French
  2006-12-08 21:38 ` Andrew Morton
  0 siblings, 1 reply; 61+ messages in thread
From: Steve French @ 2006-12-08 18:32 UTC (permalink / raw)
  To: akpm
  Cc: linux-kernel, Shirish S Pargaonkar, simo, Jeremy Allison,
	linux-cifs-client

akpm wrote:
>deprecate-smbfs-in-favour-of-cifs.patch
>deprecate-smbfs-in-favour-of-cifs-docs.patch
>
> Am still waiting to hear from sfrench on the appropriateness of this.


smbfs deprecation is ok but there are a few things to consider:
1) Secure mounts:  although more secure mounts are possible now to
Windows (not just Samba) with the most recent NTLMv2 patch in the cifs
tree, implementation of Kerberized mounts are stuck in debates about the
right upcall mechanisms (gssapi/spnego blobs can be almost 64K in size,
and userspace turned out to need to keep state across a sequence of two 
to three
upcalls before discarding its state which complicates things).   smbfs 
can handle
kerberos mounts in some cases so this is critical, even though in 
practice ntlmv2
is often good enough.

2) minor holes in backlevel server (OS/2 and Windows 9x/WindowsME) support
cifs is better in many cases than smbfs for this now, but cifs does
not handle utimes() remotely to them  yet  ie setting date/time the old 
style
DOS or OS/2 way (cifs can of course query the time fine).   This may not 
matter
for most cases and would be pretty easy to finish up

3) Documentation - minor cifs vs. smbfs differences in 
syntax/behavior.   I have
added some of this to the cifs documentation .odt file but have not 
posted the
pdf yet nor updated the shorter fs/cifs/README with some of this
helpful information (differences in syntax to help users migrating from 
smbfs).
I will post that to the cifs project site as PDF and .ODT this weekend.

4) Hot bugs ... For most users we should be ok here, but there is one major
unresolved bug that worries me: the cache_reap bug ("sleeping function
called from invalid context" in list_del+0x9/0x6c)
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214622
Not sure whose bug that will turn out to be and ACPI settings seem to
affect it but it obviously affects some 2.6.19 users.

Running simple tests on smbfs, I run into so many problems now though, it
is probably time to mark it as deprecated as Fedora etc. apparently 
already have.

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (10 preceding siblings ...)
  2006-12-06  2:59 ` Roman Zippel
@ 2006-12-08 14:09 ` Stephen Smalley
  2006-12-08 20:58   ` Andrew Morton
  2006-12-09  9:30 ` Randy Dunlap
  12 siblings, 1 reply; 61+ messages in thread
From: Stephen Smalley @ 2006-12-08 14:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, 2006-12-04 at 20:40 -0800, Andrew Morton wrote:
> mprotect-patch-for-use-by-slim.patch
> integrity-service-api-and-dummy-provider.patch
> integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch
> integrity-service-api-and-dummy-provider-compilation-warning-fix.patch
> slim-main-patch.patch
> slim-main-patch-socket_post_create-hook-return-code.patch
> slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch
> slim-main-patch-handle-failure-to-register.patch
> slim-main-patch-fix-bug-with-mm_users-usage.patch
> slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch
> slim-secfs-patch.patch
> slim-secfs-patch-slim-correct-use-of-snprintf.patch
> slim-secfs-patch-cleanup-use-of-configh.patch
> slim-make-and-config-stuff.patch
> slim-make-and-config-stuff-makefile-fix.patch
> slim-debug-output.patch
> slim-fix-security-issue-with-the-task_post_setuid-hook.patch
> slim-secfs-inode-i_private-build-fix.patch
> slim-documentation.patch
> fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch
> 
>  Shall hold in -mm.

Why?  I haven't seen any evidence that prior review comments have been
addressed so far, and a fresh patch set would be beneficial anyway to
facilitate full review of the updated code and to allow them to fix
their patch descriptions as well (as they were wrong in some instances,
describing older versions of the code).

-- 
Stephen Smalley
National Security Agency


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

* Re: -mm merge plans for 2.6.20
  2006-12-06 23:40               ` Andrew Morton
@ 2006-12-07 14:31                 ` James Simmons
  0 siblings, 0 replies; 61+ messages in thread
From: James Simmons @ 2006-12-07 14:31 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis


> Anyway, it seems all screwed up - I'll drop the patch.

I'm working on a new patch. The build system has changed quite a bit 
from the last time I worked with it 2 years ago.  

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 21:34             ` James Simmons
@ 2006-12-06 23:40               ` Andrew Morton
  2006-12-07 14:31                 ` James Simmons
  0 siblings, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2006-12-06 23:40 UTC (permalink / raw)
  To: James Simmons; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis

On Tue, 5 Dec 2006 21:34:16 +0000 (GMT)
James Simmons <jsimmons@infradead.org> wrote:

> Here you go. This patch places the backlight before the framebuffers. You
> will now be able to select using the backlight with various framebuffer 
> drivers.

This doesn't work right for me.  x86_64 allmodconfig enables
CONFIG_FB_ATY_BACKLIGHT but fails to enable FB_BACKLIGHT so things won't
build.

drivers/video/aty/atyfb_base.c: In function 'aty_bl_get_level_brightness':
drivers/video/aty/atyfb_base.c:2130: error: 'struct fb_info' has no member named 'bl_curve'

I'm not sure how to fix it, either.  Are things like
CONFIG_FB_ATY_BACKLIGHT _really_ supposed to be pmac-only?

menuconfig says:

 Symbol: FB_BACKLIGHT [=FB_BACKLIGHT]
	Selected by: PMAC_BACKLIGHT && (PPC || MAC) && ADB_PMU && FB=y && (BROKEN || !PPC64)
 

Surely CONFIG_FB_ATY_BACKLIGHT should depend upon FB_BACKLIGHT?

How come I have CONFIG_BACKLIGHT_CLASS_DEVICE and things like that but
CONFIG_FB_BACKLIGHT=n?

And a `make oldconfig' says

drivers/macintosh/Kconfig:126:warning: 'select' used by config symbol 'PMAC_BACKLIGHT' refer to undefined symbol 'FB_BACKLIGHT'


Here's what allmodconfig gave:

akpm2:/usr/src/25> grep BACKL .config
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_RADEON_BACKLIGHT=y
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY_BACKLIGHT=y


Anyway, it seems all screwed up - I'll drop the patch.

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

* Re: -mm merge plans for 2.6.20
  2006-12-06 19:19     ` Conke Hu
  2006-12-06 19:26       ` Randy Dunlap
  2006-12-06 19:40       ` Jeff Garzik
@ 2006-12-06 22:36       ` Andrew Morton
  2 siblings, 0 replies; 61+ messages in thread
From: Andrew Morton @ 2006-12-06 22:36 UTC (permalink / raw)
  To: conke.hu; +Cc: Jeff Garzik, linux-kernel, linux-ide, Alan Cox

On Thu, 07 Dec 2006 03:19:40 +0800
Conke Hu <conke.hu@gmail.com> wrote:

> On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> > On Mon, 04 Dec 2006 23:56:42 -0500
> > Jeff Garzik <jeff@garzik.org> wrote:
> > 
> > > Andrew Morton wrote:
> > > > via-pata-controller-xfer-fixes.patch
> > > > via-pata-controller-xfer-fixes-fix.patch
> > > 
> > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the 
> > > reporter as fixing things, so these two shouldn't be needed.
> > 
> > OK thanks, I dropped it.
> > 
> > > 
> > > > libata_resume_fix.patch
> > > 
> > > I thought this was resolved long ago?  Are there still open reports that 
> > > this solves, where upstream doesn't work?
> > 
> > Heck, I don't know.
> > 
> > > 
> > > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > > 
> > > With the PCI quirk, I thought ATI was finally sorted?
> > 
> > Was it?  I don't know that either.
> > 
> > I'll drop these too.
> > -
> 
> Hi Jeff, Andrew
>     The following patch is ATI's final solution. It was ACKed by Alan.
>     Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
>     Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)
> 
> 
> Best regards,
> Conke @AMD/ATI

Please send a signed-off-by: for this work, and a changelog which tells us
what it does and why the kernel needs this change.

I shall then remove the ifdef (it's __devinit, and other quirks don't do
this, and vmlinux doesn't know whether or not this driver will later be
loaded) and I shall fix up the word wrapping and I shall convert the spaces
back into tabs and I shall then send it on to Greg, thanks.


> [------------------PATCH------------------]
> 
> --- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig     2006-11-23
> 19:45:49.000000000 +0800
> +++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c  2006-11-23
> 19:34:23.000000000 +0800
> @@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
>        }
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
> PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
> +
> +#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
> +static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
> +{
> +       /* set sb600 sata to ahci mode */
> +       if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> +               u8 tmp;
> +
> +               pci_read_config_byte(pdev, 0x40, &tmp);
> +               pci_write_config_byte(pdev, 0x40, tmp|1);
> +               pci_write_config_byte(pdev, 0x9, 1);
> +               pci_write_config_byte(pdev, 0xa, 6);
> +               pci_write_config_byte(pdev, 0x40, tmp);
> +
> +               pdev->class = 0x010601;
> +       }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
> PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
> +#endif



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

* Re: -mm merge plans for 2.6.20
  2006-12-06 19:19     ` Conke Hu
  2006-12-06 19:26       ` Randy Dunlap
@ 2006-12-06 19:40       ` Jeff Garzik
  2006-12-06 22:36       ` Andrew Morton
  2 siblings, 0 replies; 61+ messages in thread
From: Jeff Garzik @ 2006-12-06 19:40 UTC (permalink / raw)
  To: conke.hu; +Cc: Andrew Morton, linux-kernel, linux-ide, Alan Cox

Conke Hu wrote:
>     The following patch is ATI's final solution. It was ACKed by Alan.
>     Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
>     Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)


I ACK'd it as well, though probably Andrew or Greg should push it.

	Jeff



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

* Re: -mm merge plans for 2.6.20
  2006-12-06 19:19     ` Conke Hu
@ 2006-12-06 19:26       ` Randy Dunlap
  2006-12-06 19:40       ` Jeff Garzik
  2006-12-06 22:36       ` Andrew Morton
  2 siblings, 0 replies; 61+ messages in thread
From: Randy Dunlap @ 2006-12-06 19:26 UTC (permalink / raw)
  To: conke.hu; +Cc: Andrew Morton, Jeff Garzik, linux-kernel, linux-ide, Alan Cox

On Thu, 07 Dec 2006 03:19:40 +0800 Conke Hu wrote:

> On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> > On Mon, 04 Dec 2006 23:56:42 -0500
> > Jeff Garzik <jeff@garzik.org> wrote:
> > 
> > > Andrew Morton wrote:
> > > > via-pata-controller-xfer-fixes.patch
> > > > via-pata-controller-xfer-fixes-fix.patch
> > > 
> > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the 
> > > reporter as fixing things, so these two shouldn't be needed.
> > 
> > OK thanks, I dropped it.
> > 
> > > 
> > > > libata_resume_fix.patch
> > > 
> > > I thought this was resolved long ago?  Are there still open reports that 
> > > this solves, where upstream doesn't work?
> > 
> > Heck, I don't know.
> > 
> > > 
> > > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > > 
> > > With the PCI quirk, I thought ATI was finally sorted?
> > 
> > Was it?  I don't know that either.
> > 
> > I'll drop these too.
> > -
> 
> Hi Jeff, Andrew
>     The following patch is ATI's final solution. It was ACKed by Alan.
>     Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
>     Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)
> 
> 
> Best regards,
> Conke @AMD/ATI
> 
> 
> [------------------PATCH------------------]
> 
> --- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig     2006-11-23
> 19:45:49.000000000 +0800
> +++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c  2006-11-23
> 19:34:23.000000000 +0800
> @@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
>        }
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
> PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
> +
> +#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
> +static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
> +{
> +       /* set sb600 sata to ahci mode */
> +       if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> +               u8 tmp;
> +
> +               pci_read_config_byte(pdev, 0x40, &tmp);
> +               pci_write_config_byte(pdev, 0x40, tmp|1);
> +               pci_write_config_byte(pdev, 0x9, 1);
> +               pci_write_config_byte(pdev, 0xa, 6);
> +               pci_write_config_byte(pdev, 0x40, tmp);
> +
> +               pdev->class = 0x010601;
> +       }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
> PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
> +#endif
> 
>  /*
>  * As per PCI spec, ignore base address registers 0-3 of the IDE
> controllers


Can you use fewer magic numbers, please?
At least some of those are already #defined in
include/linux/pci_regs.h.

---
~Randy

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  5:41   ` Andrew Morton
  2006-12-05  7:04     ` Jens Axboe
  2006-12-05 15:00     ` Mark Lord
@ 2006-12-06 19:19     ` Conke Hu
  2006-12-06 19:26       ` Randy Dunlap
                         ` (2 more replies)
  2 siblings, 3 replies; 61+ messages in thread
From: Conke Hu @ 2006-12-06 19:19 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jeff Garzik, linux-kernel, linux-ide, Alan Cox

On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> On Mon, 04 Dec 2006 23:56:42 -0500
> Jeff Garzik <jeff@garzik.org> wrote:
> 
> > Andrew Morton wrote:
> > > via-pata-controller-xfer-fixes.patch
> > > via-pata-controller-xfer-fixes-fix.patch
> > 
> > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the 
> > reporter as fixing things, so these two shouldn't be needed.
> 
> OK thanks, I dropped it.
> 
> > 
> > > libata_resume_fix.patch
> > 
> > I thought this was resolved long ago?  Are there still open reports that 
> > this solves, where upstream doesn't work?
> 
> Heck, I don't know.
> 
> > 
> > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > 
> > With the PCI quirk, I thought ATI was finally sorted?
> 
> Was it?  I don't know that either.
> 
> I'll drop these too.
> -

Hi Jeff, Andrew
    The following patch is ATI's final solution. It was ACKed by Alan.
    Jeff, you're the maintainer of libata, but this patch is based on
pci/quirks.c, so I don't know who will apply this patch? You or somebody
else?
    Andrew, could you please drop ATI's previous patch and add this one
in next -mm patch? The previous patch I sent
(ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
this one :)


Best regards,
Conke @AMD/ATI


[------------------PATCH------------------]

--- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig     2006-11-23
19:45:49.000000000 +0800
+++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c  2006-11-23
19:34:23.000000000 +0800
@@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
       }
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
+
+#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
+static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
+{
+       /* set sb600 sata to ahci mode */
+       if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
+               u8 tmp;
+
+               pci_read_config_byte(pdev, 0x40, &tmp);
+               pci_write_config_byte(pdev, 0x40, tmp|1);
+               pci_write_config_byte(pdev, 0x9, 1);
+               pci_write_config_byte(pdev, 0xa, 6);
+               pci_write_config_byte(pdev, 0x40, tmp);
+
+               pdev->class = 0x010601;
+       }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
+#endif

 /*
 * As per PCI spec, ignore base address registers 0-3 of the IDE
controllers


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

* Re: -mm merge plans for 2.6.20
  2006-12-06 16:42               ` Roman Zippel
  2006-12-06 16:58                 ` Ingo Molnar
@ 2006-12-06 16:59                 ` Ingo Molnar
  1 sibling, 0 replies; 61+ messages in thread
From: Ingo Molnar @ 2006-12-06 16:59 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Thomas Gleixner, Andrew Morton, linux-kernel


* Roman Zippel <zippel@linux-m68k.org> wrote:

> > It cannot be had both ways: either we stay simpler and less 
> > intrusive, or we go more generic but more intrusive.
> 
> You miss the point, I don't care how intrusive this is, [...]

we do care about how intrusive this is. I guess we'll have to agree to 
disagree on that.

	Ingo

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

* Re: -mm merge plans for 2.6.20
  2006-12-06 16:42               ` Roman Zippel
@ 2006-12-06 16:58                 ` Ingo Molnar
  2006-12-06 16:59                 ` Ingo Molnar
  1 sibling, 0 replies; 61+ messages in thread
From: Ingo Molnar @ 2006-12-06 16:58 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Thomas Gleixner, Andrew Morton, linux-kernel


* Roman Zippel <zippel@linux-m68k.org> wrote:

> > > > > [...] one obvious user would be the scheduler, [...]
> > 
> > but that is not a refutation of what Thomas said, at all. You say 
> > that the scheduler /could/ use such a facility. What Thomas said was 
> > that /there are no current users of such a facility/. It is a really 
> > simple (and unconditionally true) observation from Thomas. Yes, we 
> > could change other kernel code not directly related to high-res 
> > timers, but we chose not to.
> 
> I didn't say "/could/", the scheduler _needs_ such a facility. [...]

i disagree that the scheduler unconditionally 'needs' such a facility. 
The scheduler clock is pretty special and has other requirements and 
constraints than generic timekeeping clocks. It /might/ and /could/ 
utilize such an infrastructure, but it's not at all clear that it 
'needs' such a facility.

in any case, i very much entertain the possibility of more synergy in 
this space, but it's far from obvious and it's definitely not 
unconditionally 'necessary'. The scheduler and profiling code certainly 
worked for 15 years without such synergy. What we concentrated on in 
this patchset is high-resolution timers and dynticks, not scheduler or 
profiler clock cleanups. We cleaned up everything that we impacted 
directly, but we also tried to limit the scope of the changes wherever 
possible.

	Ingo

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

* Re: -mm merge plans for 2.6.20
  2006-12-06 15:22             ` Ingo Molnar
@ 2006-12-06 16:42               ` Roman Zippel
  2006-12-06 16:58                 ` Ingo Molnar
  2006-12-06 16:59                 ` Ingo Molnar
  0 siblings, 2 replies; 61+ messages in thread
From: Roman Zippel @ 2006-12-06 16:42 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Thomas Gleixner, Andrew Morton, linux-kernel

Hi,

On Wed, 6 Dec 2006, Ingo Molnar wrote:

> > > > > If I understand it correctly, Roman wants clockevents to be usable 
> > > > > for other things aside hrtimer/dyntick, i.e. let other code request 
> > > > > unused timer event hardware for special purposes. I thought about 
> > > > > that in the originally but I stayed away from it, as there are no 
> > > > > users at the moment and I wanted to avoid the usual "who needs that" 
> > > > > comment.
> > > > 
> > > > Nonsense, [...]
> > > 
> > > why do you call Thomas' observation nonsense?
> > 
> > What's the point of this question? [...]
> 
> the point of my question was what it said: to ask you why you called 
> Thomas' pretty fair observation 'nonsense'.

The nonsense comment was regarding the 'the usual "who needs that" 
comment', how is it possible that Thomas can observe something that hasn't 
happened yet?

> > [...] Your answer is/was in the "[...]" part.
> 
> meaning:
> 
> > > > [...] one obvious user would be the scheduler, [...]
> 
> but that is not a refutation of what Thomas said, at all. You say that 
> the scheduler /could/ use such a facility. What Thomas said was that 
> /there are no current users of such a facility/. It is a really simple 
> (and unconditionally true) observation from Thomas. Yes, we could change 
> other kernel code not directly related to high-res timers, but we chose 
> not to.

I didn't say "/could/", the scheduler _needs_ such a facility. If hrtimer 
and scheduler have to use the same facility, they have to be coordinated 
somehow. The current patches don't clean up anything here and actually 
introduce extra complexity via the scheduler tick emulation, with little 
to no indication how this will be cleaned up. Others may have more faith, 
that it will somehow work out, but I'd like to get a bit more information 
beforehand.

> > > Fact: there is no current user of such a facility. What we 
> > > implemented, high-res timers and dynticks does not need such a 
> > > facility.
> > 
> > Fact: there _are_ users which need a timer facility (e.g. the 
> > scheduler).
> 
> this is something we are not contesting at all: that a new timer 
> facility /could/ be used by /other/ kernel code, which does /not/ use it 
> right now.
> 
> our point is simple: the code we add does not in itself necessiate the 
> new facility, hence we didnt add it. We didnt want to impact other 
> kernel code, just yet. We repeat: we agree (in theory) with such a 
> facility, but we wanted to do it separately.

You don't really refute that this eventually will impact other code. The 
problem here is that there is pretty much no plan how this will happen. 
Without this information most developers cannot tell (without diving deep 
into these issues), how this will impact existing code (e.g. all the arch 
timer code) or how much more cruft this is going to add, which may have to 
be cleaned up later again. Maybe this code is perfect, but how is anyone 
going to tell?

> > > we wholeheartedly agree that such a facility 'would be nice', and 
> > > 'could be used by existing kernel code' but we didnt want to chew 
> > > too much at a time.
> > 
> > Maybe the existing code should have been cleaned up first? 
> 
> yes, we'll do that, and we have a good track record doing such cleanups. 

You didn't answer my question, how are you going to do this _first_?

> > > > [...] one obvious user would be the scheduler, [...]
> > > 
> > > But cleaning up the scheduler tick was not our purpose with high-res 
> > > timers nor with dynticks. One of your previous complaints was that the 
> > > patches are too intrusive to be trusted. Now they are too simple?
> > 
> > Would you please stop these personal attacks?
> 
> please point it out which portion of the above two sentences you 
> consider a personal attack - or if you cannot, please retract your 
> baseless accusation.

Ingo, above it's you who makes a baseless accusation in the first place.
Your accusation is so generic, that I have no other way than to take this 
personally.

> Fact: you did complain in the past about the complexity and/or 
> intrusiveness of our high-res timers patches - we've been working on 
> getting high-res timers upstream for more than a year now.
> 
> Fact: you did complain about unused facilities in past patches of ours, 
> and your feedback caused us significant extra work to remove those 
> facilities, just to reintroduce them later again.

As long as you see my comments only as "complaining", I'm not really 
surprised we don't get nowhere...

> this time around we chose the minimalistic approach, we didnt add 
> anything that is not immediately needed, and we didnt want to increase 
> intrusiveness by "cleaning up" other code and changing it over to the 
> new facilities.

At the risk of repeating myself:

Since this is very important code, it would be rather useful to know
what's coming and to get to an agreement about the general direction this
code is taking. This code has to cover a wide range of applications, where
as you guys are rather focused on realtime applications, which is ok, but
we need to _carefully_ rethink how time is managed within the kernel,
instead of randomly poking around in the kernel.

> It cannot be had both ways: either we stay simpler and less intrusive, 
> or we go more generic but more intrusive.

You miss the point, I don't care how intrusive this is, but with every 
step we make we have to keep the big picture in mind and the latter is 
seriously lacking here.
I have my doubts about where this is going and all I'm getting from you 
now (again) is that you try to turn this around and put all the blame on 
me. Sorry, Ingo, I'm not taking it and if you continue like this it will 
end like this every single time.

bye, Roman

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

* Re: -mm merge plans for 2.6.20
  2006-12-06 14:33           ` Roman Zippel
@ 2006-12-06 15:22             ` Ingo Molnar
  2006-12-06 16:42               ` Roman Zippel
  0 siblings, 1 reply; 61+ messages in thread
From: Ingo Molnar @ 2006-12-06 15:22 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Thomas Gleixner, Andrew Morton, linux-kernel


* Roman Zippel <zippel@linux-m68k.org> wrote:

> > > > If I understand it correctly, Roman wants clockevents to be usable 
> > > > for other things aside hrtimer/dyntick, i.e. let other code request 
> > > > unused timer event hardware for special purposes. I thought about 
> > > > that in the originally but I stayed away from it, as there are no 
> > > > users at the moment and I wanted to avoid the usual "who needs that" 
> > > > comment.
> > > 
> > > Nonsense, [...]
> > 
> > why do you call Thomas' observation nonsense?
> 
> What's the point of this question? [...]

the point of my question was what it said: to ask you why you called 
Thomas' pretty fair observation 'nonsense'.

> [...] Your answer is/was in the "[...]" part.

meaning:

> > > [...] one obvious user would be the scheduler, [...]

but that is not a refutation of what Thomas said, at all. You say that 
the scheduler /could/ use such a facility. What Thomas said was that 
/there are no current users of such a facility/. It is a really simple 
(and unconditionally true) observation from Thomas. Yes, we could change 
other kernel code not directly related to high-res timers, but we chose 
not to.

[ The word 'nonsense' is in general a negative descriptor and implies 
  that what Thomas said was 'obviously false' - while in reality what we
  have is /at most/ a difference in opinion. I.e. even if our opinion 
  differs you shouldnt call his opinion "nonsense", unless you are 
  willing to prove that it's false - which you didnt do so far. I claim 
  that what Thomas said is /unconditionally true/, and i can prove it: 
  it is unconditionally true that such a new facility is not needed
  by our code, and that no other kernel code is using it at the moment -
  because the facility does not exist yet. If you misunderstood what 
  Thomas said then please point that out, or prove that his claims are 
  untrue - thanks. ]

> > Fact: there is no current user of such a facility. What we 
> > implemented, high-res timers and dynticks does not need such a 
> > facility.
> 
> Fact: there _are_ users which need a timer facility (e.g. the 
> scheduler).

this is something we are not contesting at all: that a new timer 
facility /could/ be used by /other/ kernel code, which does /not/ use it 
right now.

our point is simple: the code we add does not in itself necessiate the 
new facility, hence we didnt add it. We didnt want to impact other 
kernel code, just yet. We repeat: we agree (in theory) with such a 
facility, but we wanted to do it separately.

> > we wholeheartedly agree that such a facility 'would be nice', and 
> > 'could be used by existing kernel code' but we didnt want to chew 
> > too much at a time.
> 
> Maybe the existing code should have been cleaned up first? 

yes, we'll do that, and we have a good track record doing such cleanups. 

> Unfortunately the dynticks feature seems to more appealing than clean 
> code...

i think this accusation against us is very unfair.

> > > [...] one obvious user would be the scheduler, [...]
> > 
> > But cleaning up the scheduler tick was not our purpose with high-res 
> > timers nor with dynticks. One of your previous complaints was that the 
> > patches are too intrusive to be trusted. Now they are too simple?
> 
> Would you please stop these personal attacks?

please point it out which portion of the above two sentences you 
consider a personal attack - or if you cannot, please retract your 
baseless accusation.

Fact: you did complain in the past about the complexity and/or 
intrusiveness of our high-res timers patches - we've been working on 
getting high-res timers upstream for more than a year now.

Fact: you did complain about unused facilities in past patches of ours, 
and your feedback caused us significant extra work to remove those 
facilities, just to reintroduce them later again.

(i can provide URLs and Message-IDs for these facts)

this time around we chose the minimalistic approach, we didnt add 
anything that is not immediately needed, and we didnt want to increase 
intrusiveness by "cleaning up" other code and changing it over to the 
new facilities.

It cannot be had both ways: either we stay simpler and less intrusive, 
or we go more generic but more intrusive.

	Ingo

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 20:40       ` Miguel Ojeda
@ 2006-12-06 14:42         ` James Simmons
  0 siblings, 0 replies; 61+ messages in thread
From: James Simmons @ 2006-12-06 14:42 UTC (permalink / raw)
  To: Miguel Ojeda; +Cc: Andrew Morton, linux-kernel, Yu Luming


> 
> Right back from exams and with lots of spare time :)
> 
> I got your patch, so I'm going to try your patch and exchange all the
> "platform_device_*" stuff with your display class and move ks0108,
> cfag12864b and cfag12864bfb to drivers/video/display/

Thanks. I will post a new patch soon.


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

* Re: -mm merge plans for 2.6.20
  2006-12-06 13:11         ` Ingo Molnar
@ 2006-12-06 14:33           ` Roman Zippel
  2006-12-06 15:22             ` Ingo Molnar
  0 siblings, 1 reply; 61+ messages in thread
From: Roman Zippel @ 2006-12-06 14:33 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Thomas Gleixner, Andrew Morton, linux-kernel

Hi,

On Wed, 6 Dec 2006, Ingo Molnar wrote:

> * Roman Zippel <zippel@linux-m68k.org> wrote:
> 
> > On Wed, 6 Dec 2006, Thomas Gleixner wrote:
> > 
> > > If I understand it correctly, Roman wants clockevents to be usable 
> > > for other things aside hrtimer/dyntick, i.e. let other code request 
> > > unused timer event hardware for special purposes. I thought about 
> > > that in the originally but I stayed away from it, as there are no 
> > > users at the moment and I wanted to avoid the usual "who needs that" 
> > > comment.
> > 
> > Nonsense, [...]
> 
> why do you call Thomas' observation nonsense?

What's the point of this question? Your answer is/was in the "[...]" part.

> Fact: there is no current 
> user of such a facility. What we implemented, high-res timers and 
> dynticks does not need such a facility.

Fact: there _are_ users which need a timer facility (e.g. the scheduler).

> we wholeheartedly agree that such a facility 'would be nice', and 'could 
> be used by existing kernel code' but we didnt want to chew too much at a 
> time.

Maybe the existing code should have been cleaned up first? Unfortunately 
the dynticks feature seems to more appealing than clean code...

> > [...] one obvious user would be the scheduler, [...]
> 
> But cleaning up the scheduler tick was not our purpose with high-res 
> timers nor with dynticks. One of your previous complaints was that the 
> patches are too intrusive to be trusted. Now they are too simple?

Would you please stop these personal attacks?

> We'll clean up the scheduler tick and profiling too, but not now.

Since this is very important code, it would be rather useful to know 
what's coming and to get to an agreement about the general direction this 
code is taking. This code has to cover a wide range of applications, where 
as you guys are rather focused on realtime applications, which is ok, but 
we need to _carefully_ rethink how time is managed within the kernel, 
instead of randomly poking around in the kernel.

> > [...] the current scheduler tick emulation is rather ugly [...]
> 
> i disagree with you and it's pretty low-impact anyway. There's still 
> quite many HZ/tick assumptions all around the time code (NTP being one 
> example), we'll deal with those via other patches.

Why do you pick on the NTP code? That's actually one of the places where 
assumptions about HZ are largely gone. NTP state is updated incrementally 
and this won't change, but the update frequency can now be easily 
disconnected from HZ.

bye, Roman

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

* Re: -mm merge plans for 2.6.20
  2006-12-06 12:54       ` Roman Zippel
@ 2006-12-06 13:11         ` Ingo Molnar
  2006-12-06 14:33           ` Roman Zippel
  0 siblings, 1 reply; 61+ messages in thread
From: Ingo Molnar @ 2006-12-06 13:11 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Thomas Gleixner, Andrew Morton, linux-kernel


* Roman Zippel <zippel@linux-m68k.org> wrote:

> On Wed, 6 Dec 2006, Thomas Gleixner wrote:
> 
> > If I understand it correctly, Roman wants clockevents to be usable 
> > for other things aside hrtimer/dyntick, i.e. let other code request 
> > unused timer event hardware for special purposes. I thought about 
> > that in the originally but I stayed away from it, as there are no 
> > users at the moment and I wanted to avoid the usual "who needs that" 
> > comment.
> 
> Nonsense, [...]

why do you call Thomas' observation nonsense? Fact: there is no current 
user of such a facility. What we implemented, high-res timers and 
dynticks does not need such a facility.

we wholeheartedly agree that such a facility 'would be nice', and 'could 
be used by existing kernel code' but we didnt want to chew too much at a 
time.

> [...] one obvious user would be the scheduler, [...]

But cleaning up the scheduler tick was not our purpose with high-res 
timers nor with dynticks. One of your previous complaints was that the 
patches are too intrusive to be trusted. Now they are too simple?

We'll clean up the scheduler tick and profiling too, but not now.

> [...] the current scheduler tick emulation is rather ugly [...]

i disagree with you and it's pretty low-impact anyway. There's still 
quite many HZ/tick assumptions all around the time code (NTP being one 
example), we'll deal with those via other patches.

	Ingo

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

* Re: -mm merge plans for 2.6.20
  2006-12-06  8:32     ` Thomas Gleixner
@ 2006-12-06 12:54       ` Roman Zippel
  2006-12-06 13:11         ` Ingo Molnar
  0 siblings, 1 reply; 61+ messages in thread
From: Roman Zippel @ 2006-12-06 12:54 UTC (permalink / raw)
  To: Thomas Gleixner; +Cc: Andrew Morton, linux-kernel, Ingo Molnar

Hi,

On Wed, 6 Dec 2006, Thomas Gleixner wrote:

> If I understand it correctly, Roman wants clockevents to be usable for
> other things aside hrtimer/dyntick, i.e. let other code request unused
> timer event hardware for special purposes. I thought about that in the
> originally but I stayed away from it, as there are no users at the
> moment and I wanted to avoid the usual "who needs that" comment.

Nonsense, one obvious user would be the scheduler, the current scheduler 
tick emulation is rather ugly and sort of explains why you need the 
special wakeup logic I saw in previous versions.
The scheduler should be completely separate from hrtimer, in the long term 
they might optionally not even use the same clock source (e.g. the 
scheduler would use a low resolution, but fast clock, while posix timer 
whould use the high resolution timer).

bye, Roman

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

* Re: -mm merge plans for 2.6.20
  2006-12-06  4:30   ` Andrew Morton
  2006-12-06  8:32     ` Thomas Gleixner
@ 2006-12-06 12:33     ` Roman Zippel
  1 sibling, 0 replies; 61+ messages in thread
From: Roman Zippel @ 2006-12-06 12:33 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, tglx, Ingo Molnar

Hi,

On Tue, 5 Dec 2006, Andrew Morton wrote:

> > IMO it least at needs one more iteration to address the comments that 
> > were made (not just mine), in the short term the less it touches 
> > unconditionally the less I care right now.
> 
> I don't have a clue which review comments remain unaddressed - do you recall?

Outside clockevents I'd like to see at least the flag handling fixed 
before it gets merged.
Inside clockevents I could poke around forever...

> > In the long term IMO this might need a major rework, the basic problem I 
> > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how 
> > to dynamically manage multiple timer.
> 
> I'm not sure I understand that.  Are you referring to multiple,
> concurrently-operating hardware clock sources?  <wonders how that could
> work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
> isn't it?

A rather simple example would be profiling, where a separate timer is 
useful to see stuff that runs from the main timer, which is currently 
invisible.
It's insofar a clocksource thing as clock source and clock events should 
form a union, currently it's separate and that's a big problem. It's not 
really problem to have multiple clock sources and they don't really have 
to be synchronized with each other, but events _are_ connected to the 
source they are coming from.
In the end we could even expose multiple clocks via the posix clock/timer 
interface, but with the current design I don't see how this is possible.

bye, Roman

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

* Re: -mm merge plans for 2.6.20
  2006-12-06  4:30   ` Andrew Morton
@ 2006-12-06  8:32     ` Thomas Gleixner
  2006-12-06 12:54       ` Roman Zippel
  2006-12-06 12:33     ` Roman Zippel
  1 sibling, 1 reply; 61+ messages in thread
From: Thomas Gleixner @ 2006-12-06  8:32 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Roman Zippel, linux-kernel, Ingo Molnar

On Tue, 2006-12-05 at 20:30 -0800, Andrew Morton wrote: 
> I don't have a clue which review comments remain unaddressed - do you recall?
> 
> I never saw an item-by-item accounting of my own (extensive) review
> comments, actually.  And then an avalanche of new stuff got sent and I
> didn't have time to go through it all at the same level of detail.

Arjan did a review of the replacement and I'm in the process to go
through that and Romans comments again. I'll add a complete list of the
review issues and the resolution state. Sorry that this was delayed, but
I was busy regression testing and hunting nasty details in the last
weeks.

> So yeah, I don't have a lot of confidence from that POV either.  But otoh,
> I'm confident that Ingo and Thomas will competently and promptly address
> regressions, so the risk factor isn't too bad.  And changing APIC and
> timekeeping code sure is risky.

Timekeeping is mostly untouched and the APIC change was done to solve
real world issues:

- lapic verification gets stuck for ever
- lapic timer runs too fast

> > In the long term IMO this might need a major rework, the basic problem I 
> > have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how 
> > to dynamically manage multiple timer.
> 
> I'm not sure I understand that.  Are you referring to multiple,
> concurrently-operating hardware clock sources?  <wonders how that could
> work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
> isn't it?

If I understand it correctly, Roman wants clockevents to be usable for
other things aside hrtimer/dyntick, i.e. let other code request unused
timer event hardware for special purposes. I thought about that in the
originally but I stayed away from it, as there are no users at the
moment and I wanted to avoid the usual "who needs that" comment. Granted
that clockevents is not perfect, but it's rather self contained and has
no user space exposure, so it can be replaced by something better
anytime.

	tglx



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

* Re: -mm merge plans for 2.6.20
  2006-12-06  2:59 ` Roman Zippel
@ 2006-12-06  4:30   ` Andrew Morton
  2006-12-06  8:32     ` Thomas Gleixner
  2006-12-06 12:33     ` Roman Zippel
  0 siblings, 2 replies; 61+ messages in thread
From: Andrew Morton @ 2006-12-06  4:30 UTC (permalink / raw)
  To: Roman Zippel; +Cc: linux-kernel, tglx, Ingo Molnar

> On Wed, 6 Dec 2006 03:59:41 +0100 (CET) Roman Zippel <zippel@linux-m68k.org> wrote:
> Hi,
> 
> On Mon, 4 Dec 2006, Andrew Morton wrote:
> 
> > [dyntick]
> > 
> >  Shall merge, I guess.  My confidence is low, but it's Kconfigurable and it
> >  needs to get sorted out.
> 
> IMO it least at needs one more iteration to address the comments that 
> were made (not just mine), in the short term the less it touches 
> unconditionally the less I care right now.

I don't have a clue which review comments remain unaddressed - do you recall?

I never saw an item-by-item accounting of my own (extensive) review
comments, actually.  And then an avalanche of new stuff got sent and I
didn't have time to go through it all at the same level of detail.

So yeah, I don't have a lot of confidence from that POV either.  But otoh,
I'm confident that Ingo and Thomas will competently and promptly address
regressions, so the risk factor isn't too bad.  And changing APIC and
timekeeping code sure is risky.

Yes, I too am wobbly about a 2.6.20 merge.  But otoh I doubt if much will
get changed if it sits in -mm for another two months.  As long as it's
heading in the right direction and doesn't break things when it is
configged-off then OK.

> In the long term IMO this might need a major rework, the basic problem I 
> have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how 
> to dynamically manage multiple timer.

I'm not sure I understand that.  Are you referring to multiple,
concurrently-operating hardware clock sources?  <wonders how that could
work> If so, that's more a clocksource thing than a dynticks/hrtimer thing,
isn't it?


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

* Re: -mm merge plans for 2.6.20
  2006-12-05 14:27 ` Roman Zippel
@ 2006-12-06  3:46   ` Horst Schirmeier
  0 siblings, 0 replies; 61+ messages in thread
From: Horst Schirmeier @ 2006-12-06  3:46 UTC (permalink / raw)
  To: Roman Zippel
  Cc: Andrew Morton, linux-kernel, Andi Kleen, jpdenheijer,
	Daniel Drake, sam, miraze, zzam

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

Hi,

On Tue, 05 Dec 2006, Roman Zippel wrote:
> On Mon, 4 Dec 2006, Andrew Morton wrote:
> > kbuild-dont-put-temp-files-in-the-source-tree.patch
> > actually-delete-the-as-instr-ld-option-tmp-file.patch
> 
> Andi had objections about the mktemp usage and I agree with him.
> The proposed patch in bugzilla didn't have this and no further 
> justification was given for why it's needed.
> Below is a replacement patch with some improvements:
> - kbuild doesn't use $(AS), so use $(CC)
> - tmp dir needs only to be calculated once
> - reformat a bit to keep it under 80 columns and to be more readable
> 
> bye, Roman
> 
> Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

This patch looks good to me, and I'd prefer it over the (twice
corrected) one currently in -mm.

-  It's close to what Daniel Drake proposed recently [1] (main
   difference: corrects the very same problem for ld-option, which might
   otherwise bite us later) and what's already in Gentoo's patchkernel,

-  it abstains from using mktemp, hopefully making Andi happy ;),

-  resolves the current Gentoo sandbox issues without touching more
   kbuild code than necessary.

Kind regards,
 Horst

[1]Message-Id: <20061202194544.D9F057B40A0@zog.reactivated.net>

-- 
PGP-Key 0xD40E0E7A

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (9 preceding siblings ...)
  2006-12-05 21:00 ` Ingo Molnar
@ 2006-12-06  2:59 ` Roman Zippel
  2006-12-06  4:30   ` Andrew Morton
  2006-12-08 14:09 ` Stephen Smalley
  2006-12-09  9:30 ` Randy Dunlap
  12 siblings, 1 reply; 61+ messages in thread
From: Roman Zippel @ 2006-12-06  2:59 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, tglx

Hi,

On Mon, 4 Dec 2006, Andrew Morton wrote:

> [dyntick]
> 
>  Shall merge, I guess.  My confidence is low, but it's Kconfigurable and it
>  needs to get sorted out.

IMO it least at needs one more iteration to address the comments that 
were made (not just mine), in the short term the less it touches 
unconditionally the less I care right now.
In the long term IMO this might need a major rework, the basic problem I 
have is that I don't see how this usable beyond dynticks/hrtimer, e.g. how 
to dynamically manage multiple timer.

bye, Roman

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 20:20           ` Andrew Morton
@ 2006-12-05 21:34             ` James Simmons
  2006-12-06 23:40               ` Andrew Morton
  0 siblings, 1 reply; 61+ messages in thread
From: James Simmons @ 2006-12-05 21:34 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis


> > Ug. Kconfig in drivers/video has all the above drivers enable the 
> > backlight only if PMAC_BACKLIGHT is set.
> 
> erp, I grepped for CONFIG_foo and not foo.  Again.
> 
> > The problem is backlight
> > is after the framebuffer. We should move the backlight menu before
> > the framebuffer configuration.
> 
> OK.  Can you do a patch sometime please?

Here you go. This patch places the backlight before the framebuffers. You
will now be able to select using the backlight with various framebuffer 
drivers.

Signed-off:	James Simmons <jsimmons@infradead.org>

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 7a43020..40f6bea 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -4,20 +4,9 @@
 
 menu "Graphics support"
 
-config FIRMWARE_EDID
-       bool "Enable firmware EDID"
-       default y
-       ---help---
-         This enables access to the EDID transferred from the firmware.
-	 On the i386, this is from the Video BIOS. Enable this if DDC/I2C
-	 transfers do not work for your driver and if you are using
-	 nvidiafb, i810fb or savagefb.
-
-	 In general, choosing Y for this option is safe.  If you
-	 experience extremely long delays while booting before you get
-	 something on your display, try setting this to N.  Matrox cards in
-	 combination with certain motherboards and monitors are known to
-	 suffer from this problem.
+if SYSFS
+	source "drivers/video/backlight/Kconfig"
+endif
 
 config FB
 	tristate "Support for frame buffer devices"
@@ -53,6 +42,22 @@ config FB
 	  (e.g. an accelerated X server) and that are not frame buffer
 	  device-aware may cause unexpected results. If unsure, say N.
 
+config FIRMWARE_EDID
+       bool "Enable firmware EDID"
+       depends on FB
+       default n 
+       ---help---
+         This enables access to the EDID transferred from the firmware.
+	 On the i386, this is from the Video BIOS. Enable this if DDC/I2C
+	 transfers do not work for your driver and if you are using
+	 nvidiafb, i810fb or savagefb.
+
+	 In general, choosing Y for this option is safe.  If you
+	 experience extremely long delays while booting before you get
+	 something on your display, try setting this to N.  Matrox cards in
+	 combination with certain motherboards and monitors are known to
+	 suffer from this problem.
+
 config FB_DDC
        tristate
        depends on FB && I2C && I2C_ALGOBIT
@@ -90,13 +95,6 @@ config FB_MACMODES
        depends on FB
        default n
 
-config FB_BACKLIGHT
-	bool
-	depends on FB
-	select BACKLIGHT_LCD_SUPPORT
-	select BACKLIGHT_CLASS_DEVICE
-	default n
-
 config FB_MODE_HELPERS
         bool "Enable Video Mode Handling Helpers"
         depends on FB
@@ -126,6 +124,9 @@ config FB_TILEBLITTING
 	 This is particularly important to one driver, matroxfb.  If
 	 unsure, say N.
 
+comment "Frambuffer hardware drivers"
+	depends on FB
+
 config FB_CIRRUS
 	tristate "Cirrus Logic support"
 	depends on FB && (ZORRO || PCI)
@@ -728,8 +729,7 @@ config FB_NVIDIA_I2C
 
 config FB_NVIDIA_BACKLIGHT
 	bool "Support for backlight control"
-	depends on FB_NVIDIA && PMAC_BACKLIGHT
-	select FB_BACKLIGHT
+	depends on FB_NVIDIA && BACKLIGHT_CLASS_DEVICE
 	default y
 	help
 	  Say Y here if you want to control the backlight of your display.
@@ -775,8 +775,7 @@ config FB_RIVA_DEBUG
 
 config FB_RIVA_BACKLIGHT
 	bool "Support for backlight control"
-	depends on FB_RIVA && PMAC_BACKLIGHT
-	select FB_BACKLIGHT
+	depends on FB_RIVA && BACKLIGHT_CLASS_DEVICE
 	default y
 	help
 	  Say Y here if you want to control the backlight of your display.
@@ -1049,8 +1048,7 @@ config FB_RADEON_I2C
 
 config FB_RADEON_BACKLIGHT
 	bool "Support for backlight control"
-	depends on FB_RADEON && PMAC_BACKLIGHT
-	select FB_BACKLIGHT
+	depends on FB_RADEON && BACKLIGHT_CLASS_DEVICE 
 	default y
 	help
 	  Say Y here if you want to control the backlight of your display.
@@ -1081,8 +1079,7 @@ config FB_ATY128
 
 config FB_ATY128_BACKLIGHT
 	bool "Support for backlight control"
-	depends on FB_ATY128 && PMAC_BACKLIGHT
-	select FB_BACKLIGHT
+	depends on FB_ATY128 && BACKLIGHT_CLASS_DEVICE 
 	default y
 	help
 	  Say Y here if you want to control the backlight of your display.
@@ -1131,8 +1128,7 @@ config FB_ATY_GX
 
 config FB_ATY_BACKLIGHT
 	bool "Support for backlight control"
-	depends on FB_ATY && PMAC_BACKLIGHT
-	select FB_BACKLIGHT
+	depends on FB_ATY && BACKLIGHT_CLASS_DEVICE 
 	default y
 	help
 	  Say Y here if you want to control the backlight of your display.
@@ -1632,6 +1628,7 @@ config FB_VIRTUAL
 	  the vfb_enable=1 option.
 
 	  If unsure, say N.
+
 if VT
 	source "drivers/video/console/Kconfig"
 endif
@@ -1640,9 +1637,5 @@ if FB || SGI_NEWPORT_CONSOLE
 	source "drivers/video/logo/Kconfig"
 endif
 
-if SYSFS
-	source "drivers/video/backlight/Kconfig"
-endif
-
 endmenu
 
 

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (8 preceding siblings ...)
  2006-12-05 19:18 ` Josef Sipek
@ 2006-12-05 21:00 ` Ingo Molnar
  2006-12-06  2:59 ` Roman Zippel
                   ` (2 subsequent siblings)
  12 siblings, 0 replies; 61+ messages in thread
From: Ingo Molnar @ 2006-12-05 21:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Thomas Gleixner, John Stultz


* Andrew Morton <akpm@osdl.org> wrote:

> gtod-exponential-update_wall_time.patch
> 
>  Roman wanted this dropped, and afaik that's unresolved.

please drop this one for now, we'll rework it. It's an optimization, not 
a showstopper must-have component.

	Ingo

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 18:25     ` James Simmons
  2006-12-05 19:43       ` Andrew Morton
@ 2006-12-05 20:40       ` Miguel Ojeda
  2006-12-06 14:42         ` James Simmons
  1 sibling, 1 reply; 61+ messages in thread
From: Miguel Ojeda @ 2006-12-05 20:40 UTC (permalink / raw)
  To: James Simmons; +Cc: Andrew Morton, linux-kernel, Yu Luming

On 12/5/06, James Simmons <jsimmons@infradead.org> wrote:
>
> > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > >
> > > Does this patch update the fbdev drivers?
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> >
> > Seems not.  Should it?
>
> Yes. Its bizarre. The drivers compile with the wrong method prototype. I
> updated the fbdev drivers to the new backlight_device_register and it
> compiled as expect. There are a few other problems with teh fbdev drivers.
> I will send a patch.
>
> > > > add-display-output-class-support.patch
> > > > add-output-class-document.patch
> > > > drivers-add-lcd-support-3.patch
> > > > drivers-add-lcd-support-3-Kconfig-fix.patch
> > > > drivers-add-lcd-support-update-4.patch
> > > > drivers-add-lcd-support-update-5.patch
> > > > drivers-add-lcd-support-update6.patch
> > > > drivers-add-lcd-support-update-7.patch
> > > > drivers-add-lcd-support-update-8.patch
> > >
> > > Ug. We have alot of interfaces attempting to do the same thing. We also
> > > have the lcd class_dev in drivers/video/backlight. I did some work which I
> > > will post to interested parties in the hopes of getting one interface to
> > > make everyone happy.
> >
> > Well can you please work out what we should do with Miguel?
>
> I sent a email already. The details will be hammered out.
>
>

Right back from exams and with lots of spare time :)

I got your patch, so I'm going to try your patch and exchange all the
"platform_device_*" stuff with your display class and move ks0108,
cfag12864b and cfag12864bfb to drivers/video/display/

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 19:59         ` James Simmons
@ 2006-12-05 20:20           ` Andrew Morton
  2006-12-05 21:34             ` James Simmons
  0 siblings, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2006-12-05 20:20 UTC (permalink / raw)
  To: James Simmons; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis

On Tue, 5 Dec 2006 19:59:01 +0000 (GMT)
James Simmons <jsimmons@infradead.org> wrote:

> 
> > > > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > > > 
> > > > > Does this patch update the fbdev drivers?
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > > 
> > > > Seems not.  Should it?
> > > 
> > > Yes. Its bizarre.
> > 
> > It is.
> > 
> > > The drivers compile with the wrong method prototype.
> > 
> > No, it doesn't get compiled at all.
> > 
> > CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all.
> > 
> > CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all.
> > 
> > CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all.
> > 
> > So this is all dead code.  There is no way to enable any of it within the
> > config system.
> 
> Ug. Kconfig in drivers/video has all the above drivers enable the 
> backlight only if PMAC_BACKLIGHT is set.

erp, I grepped for CONFIG_foo and not foo.  Again.

> The problem is backlight
> is after the framebuffer. We should move the backlight menu before
> the framebuffer configuration.

OK.  Can you do a patch sometime please?

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 19:43       ` Andrew Morton
@ 2006-12-05 19:59         ` James Simmons
  2006-12-05 20:20           ` Andrew Morton
  0 siblings, 1 reply; 61+ messages in thread
From: James Simmons @ 2006-12-05 19:59 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis


> > > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > > 
> > > > Does this patch update the fbdev drivers?
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > 
> > > Seems not.  Should it?
> > 
> > Yes. Its bizarre.
> 
> It is.
> 
> > The drivers compile with the wrong method prototype.
> 
> No, it doesn't get compiled at all.
> 
> CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all.
> 
> CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all.
> 
> CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all.
> 
> So this is all dead code.  There is no way to enable any of it within the
> config system.

Ug. Kconfig in drivers/video has all the above drivers enable the 
backlight only if PMAC_BACKLIGHT is set. The problem is backlight
is after the framebuffer. We should move the backlight menu before
the framebuffer configuration.


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

* Re: -mm merge plans for 2.6.20
  2006-12-05 18:25     ` James Simmons
@ 2006-12-05 19:43       ` Andrew Morton
  2006-12-05 19:59         ` James Simmons
  2006-12-05 20:40       ` Miguel Ojeda
  1 sibling, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2006-12-05 19:43 UTC (permalink / raw)
  To: James Simmons; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis

On Tue, 5 Dec 2006 18:25:58 +0000 (GMT)
James Simmons <jsimmons@infradead.org> wrote:

> > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > > 
> > > Does this patch update the fbdev drivers?
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > 
> > Seems not.  Should it?
> 
> Yes. Its bizarre.

It is.

> The drivers compile with the wrong method prototype.

No, it doesn't get compiled at all.

CONFIG_FB_ATY128_BACKLIGHT has no Kconfig record at all.

CONFIG_FB_NVIDIA_BACKLIGHT has no Kconfig record at all.

CONFIG_FB_RIVA_BACKLIGHT has no Kconfig record at all.

So this is all dead code.  There is no way to enable any of it within the
config system.

> I 
> updated the fbdev drivers to the new backlight_device_register and it 
> compiled as expect. There are a few other problems with teh fbdev drivers. 
> I will send a patch.

It's a start ;)

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (7 preceding siblings ...)
  2006-12-05 17:35 ` James Simmons
@ 2006-12-05 19:18 ` Josef Sipek
  2006-12-05 21:00 ` Ingo Molnar
                   ` (3 subsequent siblings)
  12 siblings, 0 replies; 61+ messages in thread
From: Josef Sipek @ 2006-12-05 19:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:
... 
> fsstack-introduce-fsstack_copy_attrinode_.patch
> fsstack-introduce-fsstack_copy_attrinode_-tidy.patch
> fsstack-introduce-fsstack_copy_attrinode_-fs-stackc-should-include-linux-fs_stackh.patch
> ecryptfs-use-fsstacks-generic-copy-inode-attr.patch
> ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix.patch
> ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix-fix.patch
> struct-path-rename-reiserfss-struct-path.patch
> struct-path-rename-dms-struct-path.patch
> struct-path-move-struct-path-from-fs-nameic-into.patch
> struct-path-make-ecryptfs-a-user-of-struct-path.patch
> vfs-change-struct-file-to-use-struct-path.patch
...
> 
>  Shall merge.  I guess.  Doesn't seem very useful.

I have two more fixes for fsstack/ecryptfs. I'll send them as a reply to
this email...

Josef "Jeff" Sipek.

-- 
FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #19
A:      To be or not to be.
Q:      What is the square root of 4b^2?

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

* Re: -mm merge plans for 2.6.20
  2006-12-05 18:01   ` Andrew Morton
@ 2006-12-05 18:25     ` James Simmons
  2006-12-05 19:43       ` Andrew Morton
  2006-12-05 20:40       ` Miguel Ojeda
  0 siblings, 2 replies; 61+ messages in thread
From: James Simmons @ 2006-12-05 18:25 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis


> > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> > 
> > Does this patch update the fbdev drivers?
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> 
> Seems not.  Should it?

Yes. Its bizarre. The drivers compile with the wrong method prototype. I 
updated the fbdev drivers to the new backlight_device_register and it 
compiled as expect. There are a few other problems with teh fbdev drivers. 
I will send a patch.

> > > add-display-output-class-support.patch
> > > add-output-class-document.patch
> > > drivers-add-lcd-support-3.patch
> > > drivers-add-lcd-support-3-Kconfig-fix.patch
> > > drivers-add-lcd-support-update-4.patch
> > > drivers-add-lcd-support-update-5.patch
> > > drivers-add-lcd-support-update6.patch
> > > drivers-add-lcd-support-update-7.patch
> > > drivers-add-lcd-support-update-8.patch
> > 
> > Ug. We have alot of interfaces attempting to do the same thing. We also 
> > have the lcd class_dev in drivers/video/backlight. I did some work which I 
> > will post to interested parties in the hopes of getting one interface to 
> > make everyone happy. 
> 
> Well can you please work out what we should do with Miguel?

I sent a email already. The details will be hammered out.


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

* Re: -mm merge plans for 2.6.20
  2006-12-05 17:35 ` James Simmons
@ 2006-12-05 18:01   ` Andrew Morton
  2006-12-05 18:25     ` James Simmons
  0 siblings, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2006-12-05 18:01 UTC (permalink / raw)
  To: James Simmons; +Cc: linux-kernel, Yu Luming, Miguel Ojeda Sandonis

On Tue, 5 Dec 2006 17:35:20 +0000 (GMT)
James Simmons <jsimmons@infradead.org> wrote:

> 
> > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
> 
> Does this patch update the fbdev drivers?

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc6/2.6.19-rc6-mm2/broken-out/video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch

Seems not.  Should it?

> > add-display-output-class-support.patch
> > add-output-class-document.patch
> > drivers-add-lcd-support-3.patch
> > drivers-add-lcd-support-3-Kconfig-fix.patch
> > drivers-add-lcd-support-update-4.patch
> > drivers-add-lcd-support-update-5.patch
> > drivers-add-lcd-support-update6.patch
> > drivers-add-lcd-support-update-7.patch
> > drivers-add-lcd-support-update-8.patch
> 
> Ug. We have alot of interfaces attempting to do the same thing. We also 
> have the lcd class_dev in drivers/video/backlight. I did some work which I 
> will post to interested parties in the hopes of getting one interface to 
> make everyone happy. 

Well can you please work out what we should do with Miguel?

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (6 preceding siblings ...)
  2006-12-05 16:02 ` Dave Jones
@ 2006-12-05 17:35 ` James Simmons
  2006-12-05 18:01   ` Andrew Morton
  2006-12-05 19:18 ` Josef Sipek
                   ` (4 subsequent siblings)
  12 siblings, 1 reply; 61+ messages in thread
From: James Simmons @ 2006-12-05 17:35 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel


> video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch

Does this patch update the fbdev drivers?

> add-display-output-class-support.patch
> add-output-class-document.patch
> drivers-add-lcd-support-3.patch
> drivers-add-lcd-support-3-Kconfig-fix.patch
> drivers-add-lcd-support-update-4.patch
> drivers-add-lcd-support-update-5.patch
> drivers-add-lcd-support-update6.patch
> drivers-add-lcd-support-update-7.patch
> drivers-add-lcd-support-update-8.patch

Ug. We have alot of interfaces attempting to do the same thing. We also 
have the lcd class_dev in drivers/video/backlight. I did some work which I 
will post to interested parties in the hopes of getting one interface to 
make everyone happy. 

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (5 preceding siblings ...)
  2006-12-05 14:27 ` Roman Zippel
@ 2006-12-05 16:02 ` Dave Jones
  2006-12-12 17:49   ` Dave Jones
  2006-12-05 17:35 ` James Simmons
                   ` (5 subsequent siblings)
  12 siblings, 1 reply; 61+ messages in thread
From: Dave Jones @ 2006-12-05 16:02 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:
 
 > cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
 > remove-hotplug-cpu-crap-from-cpufreq.patch
 > cpufreq-select-consistently-re-2619-rc5-mm1.patch
 > cpufreq-set-policy-curfreq-on-initialization.patch
 > bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch
 > 
 > Sent to cpufreq maintainer

I'm travelling right now, and somehow managed to oops my home router
3000 miles away making it hard for me to access mail & stuff.
(That "page count went negative" BUG() bit me when I did a killall -9 vpnc)

Full bug report, and processing of this backlog will happen
as soon as I get back on Sunday :)

		Dave

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  5:41   ` Andrew Morton
  2006-12-05  7:04     ` Jens Axboe
@ 2006-12-05 15:00     ` Mark Lord
  2006-12-06 19:19     ` Conke Hu
  2 siblings, 0 replies; 61+ messages in thread
From: Mark Lord @ 2006-12-05 15:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jeff Garzik, linux-kernel, linux-ide, Alan Cox

Andrew Morton wrote:
> On Mon, 04 Dec 2006 23:56:42 -0500
> Jeff Garzik <jeff@garzik.org> wrote:
> 
>> Andrew Morton wrote:
> 
>>> libata_resume_fix.patch
>> I thought this was resolved long ago?  Are there still open reports that 
>> this solves, where upstream doesn't work?
> 
> Heck, I don't know.

You probably pinched it from my website originally, and I nabbed it from
an LKML posting 18 months ago.  It's a patch that was required here back
in the 2.6.12 - 2.6.16 era, and it is no longer needed now.

Drop it.

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (4 preceding siblings ...)
  2006-12-05 13:23 ` John W. Linville
@ 2006-12-05 14:27 ` Roman Zippel
  2006-12-06  3:46   ` Horst Schirmeier
  2006-12-05 16:02 ` Dave Jones
                   ` (6 subsequent siblings)
  12 siblings, 1 reply; 61+ messages in thread
From: Roman Zippel @ 2006-12-05 14:27 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Andi Kleen, Horst Schirmeier, jpdenheijer

Hi,

On Mon, 4 Dec 2006, Andrew Morton wrote:

> kbuild-dont-put-temp-files-in-the-source-tree.patch
> actually-delete-the-as-instr-ld-option-tmp-file.patch

Andi had objections about the mktemp usage and I agree with him.
The proposed patch in bugzilla didn't have this and no further 
justification was given for why it's needed.
Below is a replacement patch with some improvements:
- kbuild doesn't use $(AS), so use $(CC)
- tmp dir needs only to be calculated once
- reformat a bit to keep it under 80 columns and to be more readable

bye, Roman

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

---
 scripts/Kbuild.include |   19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

Index: linux-2.6-git/scripts/Kbuild.include
===================================================================
--- linux-2.6-git.orig/scripts/Kbuild.include	2006-12-05 13:44:50.000000000 +0100
+++ linux-2.6-git/scripts/Kbuild.include	2006-12-05 15:09:09.000000000 +0100
@@ -56,6 +56,9 @@ endef
 # gcc support functions
 # See documentation in Documentation/kbuild/makefiles.txt
 
+# output directory for tests below
+TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/)
+
 # as-option
 # Usage: cflags-y += $(call as-option, -Wa$(comma)-isa=foo,)
 
@@ -66,9 +69,11 @@ as-option = $(shell if $(CC) $(CFLAGS) $
 # as-instr
 # Usage: cflags-y += $(call as-instr, instr, option1, option2)
 
-as-instr = $(shell if echo -e "$(1)" | $(AS) >/dev/null 2>&1 -W -Z -o astest$$$$.out ; \
-		   then echo "$(2)"; else echo "$(3)"; fi; \
-	           rm -f astest$$$$.out)
+as-instr = $(shell if echo -e "$(1)" | \
+		      $(CC) $(AFLAGS) -c -xassembler - \
+			    -o $(TMPOUT)astest$$$$.out > /dev/null 2>&1; \
+		   then rm $(TMPOUT)astest$$$$.out; echo "$(2)"; \
+		   else echo "$(3)"; fi)
 
 # cc-option
 # Usage: cflags-y += $(call cc-option, -march=winchip-c6, -march=i586)
@@ -97,10 +102,10 @@ cc-ifversion = $(shell if [ $(call cc-ve
 
 # ld-option
 # Usage: ldflags += $(call ld-option, -Wl$(comma)--hash-style=both)
-ld-option = $(shell if $(CC) $(1) \
-			     -nostdlib -o ldtest$$$$.out -xc /dev/null \
-             > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi; \
-	     rm -f ldtest$$$$.out)
+ld-option = $(shell if $(CC) $(1) -nostdlib -xc /dev/null \
+			     -o $(TMPOUT)ldtest$$$$.out > /dev/null 2>&1; \
+             then rm $(TMPOUT)ldtest$$$$.out; echo "$(1)"; \
+             else echo "$(2)"; fi)
 
 ###
 # Shorthand for $(Q)$(MAKE) -f scripts/Makefile.build obj=

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (3 preceding siblings ...)
  2006-12-05  8:47 ` Peter Zijlstra
@ 2006-12-05 13:23 ` John W. Linville
  2006-12-05 14:27 ` Roman Zippel
                   ` (7 subsequent siblings)
  12 siblings, 0 replies; 61+ messages in thread
From: John W. Linville @ 2006-12-05 13:23 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, Dec 04, 2006 at 08:40:24PM -0800, Andrew Morton wrote:

> hostap-replace-kmallocmemset-with-kzalloc.patch
> prism54-replace-kmallocmemset-with-kzalloc.patch
> ipw2200-replace-kmallocmemset-with-kcalloc.patch
> softmac-fix-unbalanced-mutex_lock-unlock-in-ieee80211softmac_wx_set_mlme.patch
> 
>  Not sent to John - I forgot.

I've got them, and I plan to merge them.

Thanks,

John
-- 
John W. Linville
linville@tuxdriver.com

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
                   ` (2 preceding siblings ...)
  2006-12-05  8:36 ` Gautham R Shenoy
@ 2006-12-05  8:47 ` Peter Zijlstra
  2006-12-05 13:23 ` John W. Linville
                   ` (8 subsequent siblings)
  12 siblings, 0 replies; 61+ messages in thread
From: Peter Zijlstra @ 2006-12-05  8:47 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel


> mm-call-into-direct-reclaim-without-pf_memalloc-set.patch
> mm-cleanup-and-document-reclaim-recursion.patch

Drop these, I'm not sure of them anymore. And I am starting to grow a
nagging feeling they are wrong.



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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
  2006-12-05  4:56 ` Jeff Garzik
  2006-12-05  5:14 ` Paul Mackerras
@ 2006-12-05  8:36 ` Gautham R Shenoy
  2006-12-05  8:47 ` Peter Zijlstra
                   ` (9 subsequent siblings)
  12 siblings, 0 replies; 61+ messages in thread
From: Gautham R Shenoy @ 2006-12-05  8:36 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, vatsa, dipankar, davej, torvalds

Hi Andrew,

> remove-hotplug-cpu-crap-from-cpufreq.patch
> 
> Sent to cpufreq maintainer

I suspect that Davej posted this patch because he was getting lockdep
warnings-reports from people complaining of ondemand-governor 
performing spurious unlock_cpu_hotplug. 
That problem has been fixed in the mainline by the commit
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4b96b1a10cb00c867103b21f0f2a6c91b705db11

If there are any other issues with cpufreq-cpuhotplug in the mainline,
I'm more than willing to help out fix them. As of now, I cannot seem 
to spot anything serious in the mainline as such.
Hence, merging this isn't an immediate need IMHO.

> hotplug-cpu-clean-up-hotcpu_notifier-use.patch
> hotplug-cpu-clean-up-hotcpu_notifier-use-vs-gregkh-driver-cpu-topology-consider-sysfs_create_group-return-value.patch

> 
> extend-notifier_call_chain-to-count-nr_calls-made.patch
> extend-notifier_call_chain-to-count-nr_calls-made-fixes.patch
> extend-notifier_call_chain-to-count-nr_calls-made-fixes-2.patch
> define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release.patch
> define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release-fix.patch
> eliminate-lock_cpu_hotplug-in-kernel-schedc.patch
> eliminate-lock_cpu_hotplug-in-kernel-schedc-fix.patch
> handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch
> 
>  Shall merge.
>

Merging this would still give the circular-locking dependency warnings
which I posted the other day. Unless we have a clean way to get
cpu-hotplug-protection for cpufreq, I don't see a point in merging this
stuff.

Cpufreq hotplug-interactions can be sorted out.
I have a few patches which I need to test out before posting them.

Other than that, there are issues regarding the 
workqueue-hotplug-"locking" which needs to be addressed,
probably in a seperate thread.

So could you please reconsider this decision to merge the
hotplug-locking rework, and let it stabilize in -mm for sometime ?

Thanks and Regards
gautham.
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  5:41   ` Andrew Morton
@ 2006-12-05  7:04     ` Jens Axboe
  2006-12-05 15:00     ` Mark Lord
  2006-12-06 19:19     ` Conke Hu
  2 siblings, 0 replies; 61+ messages in thread
From: Jens Axboe @ 2006-12-05  7:04 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Jeff Garzik, linux-kernel, linux-ide, Alan Cox

On Mon, Dec 04 2006, Andrew Morton wrote:
> > 
> > > libata_resume_fix.patch
> > 
> > I thought this was resolved long ago?  Are there still open reports that 
> > this solves, where upstream doesn't work?
> 
> Heck, I don't know.

I'm not aware of any, and resume works for me. Did that patch ever get
verified as fixing something for anybody? I think it can be safely
dropped.

-- 
Jens Axboe


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

* Re: -mm merge plans for 2.6.20
  2006-12-05  5:42   ` Andrew Morton
@ 2006-12-05  5:53     ` Nick Piggin
  0 siblings, 0 replies; 61+ messages in thread
From: Nick Piggin @ 2006-12-05  5:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Paul Mackerras, linux-kernel

Andrew Morton wrote:
> On Tue, 5 Dec 2006 16:14:03 +1100
> Paul Mackerras <paulus@samba.org> wrote:
> 
> 
>>>radix-tree-rcu-lockless-readside.patch
>>>
>>> There's no reason to merge this yet.
>>
>>We want to use it in some powerpc arch code.  Currently we use a
>>per-cpu array of spinlocks, and this patch would let us get rid of
>>that array.
> 
> 
> ok, let's merge it then.

Well that wasn't as hard as I thought ;) No arguments from me!

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  5:14 ` Paul Mackerras
  2006-12-05  5:42   ` Andrew Morton
@ 2006-12-05  5:49   ` Nick Piggin
  1 sibling, 0 replies; 61+ messages in thread
From: Nick Piggin @ 2006-12-05  5:49 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Andrew Morton, linux-kernel

Paul Mackerras wrote:
> Andrew Morton writes:

>>radix-tree-rcu-lockless-readside.patch
>>
>> There's no reason to merge this yet.
> 
> 
> We want to use it in some powerpc arch code.  Currently we use a
> per-cpu array of spinlocks, and this patch would let us get rid of
> that array.

I'd like to get another patch in here before going upstream if possible.
It is not a correctness fix, but it is a bit of a rework.

I also wouldn't mind getting the readahead path, if not the full
pagecache readside, out from under tree_lock in -mm kernels to exercise
the radix-tree concurrency a bit more.

It's just been painfully slow, recently because of these more important
buffered write vs deadlock and pagefault vs invalidate problems that
I've been working on. I don't feel I can load up -mm with too much
unrelated stuff that messes with mm/pagecache internals.

I guess the per-cpu spinlocks are pretty reasonable for scalability,
and you are mainly looking to eliminate the lock/unlock cost in your
interrupt path?

Nick

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  5:14 ` Paul Mackerras
@ 2006-12-05  5:42   ` Andrew Morton
  2006-12-05  5:53     ` Nick Piggin
  2006-12-05  5:49   ` Nick Piggin
  1 sibling, 1 reply; 61+ messages in thread
From: Andrew Morton @ 2006-12-05  5:42 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linux-kernel

On Tue, 5 Dec 2006 16:14:03 +1100
Paul Mackerras <paulus@samba.org> wrote:

> > radix-tree-rcu-lockless-readside.patch
> > 
> >  There's no reason to merge this yet.
> 
> We want to use it in some powerpc arch code.  Currently we use a
> per-cpu array of spinlocks, and this patch would let us get rid of
> that array.

ok, let's merge it then.

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:56 ` Jeff Garzik
@ 2006-12-05  5:41   ` Andrew Morton
  2006-12-05  7:04     ` Jens Axboe
                       ` (2 more replies)
  0 siblings, 3 replies; 61+ messages in thread
From: Andrew Morton @ 2006-12-05  5:41 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: linux-kernel, linux-ide, Alan Cox

On Mon, 04 Dec 2006 23:56:42 -0500
Jeff Garzik <jeff@garzik.org> wrote:

> Andrew Morton wrote:
> > via-pata-controller-xfer-fixes.patch
> > via-pata-controller-xfer-fixes-fix.patch
> 
> Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the 
> reporter as fixing things, so these two shouldn't be needed.

OK thanks, I dropped it.

> 
> > libata_resume_fix.patch
> 
> I thought this was resolved long ago?  Are there still open reports that 
> this solves, where upstream doesn't work?

Heck, I don't know.

> 
> > ahci-ati-sb600-sata-support-for-various-modes.patch
> 
> With the PCI quirk, I thought ATI was finally sorted?

Was it?  I don't know that either.

I'll drop these too.

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
  2006-12-05  4:56 ` Jeff Garzik
@ 2006-12-05  5:14 ` Paul Mackerras
  2006-12-05  5:42   ` Andrew Morton
  2006-12-05  5:49   ` Nick Piggin
  2006-12-05  8:36 ` Gautham R Shenoy
                   ` (10 subsequent siblings)
  12 siblings, 2 replies; 61+ messages in thread
From: Paul Mackerras @ 2006-12-05  5:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

Andrew Morton writes:

> ppc-m48t35-add-missing-bracket.patch
> powerpc-replace-kmallocmemset-with-kzalloc.patch

These are already in Linus' tree.

>  Am holding onto these until the powerpc git tree gets un-messied up.

It should be fine now.  Linus has pulled it, so there are currently no
changes in powerpc.git relative to Linus' tree.

> radix-tree-rcu-lockless-readside.patch
> 
>  There's no reason to merge this yet.

We want to use it in some powerpc arch code.  Currently we use a
per-cpu array of spinlocks, and this patch would let us get rid of
that array.

Paul.

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

* Re: -mm merge plans for 2.6.20
  2006-12-05  4:40 Andrew Morton
@ 2006-12-05  4:56 ` Jeff Garzik
  2006-12-05  5:41   ` Andrew Morton
  2006-12-05  5:14 ` Paul Mackerras
                   ` (11 subsequent siblings)
  12 siblings, 1 reply; 61+ messages in thread
From: Jeff Garzik @ 2006-12-05  4:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-ide, Alan Cox

Andrew Morton wrote:
> via-pata-controller-xfer-fixes.patch
> via-pata-controller-xfer-fixes-fix.patch

Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the 
reporter as fixing things, so these two shouldn't be needed.


> libata_resume_fix.patch

I thought this was resolved long ago?  Are there still open reports that 
this solves, where upstream doesn't work?


> ahci-ati-sb600-sata-support-for-various-modes.patch

With the PCI quirk, I thought ATI was finally sorted?

	Jeff



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

* -mm merge plans for 2.6.20
@ 2006-12-05  4:40 Andrew Morton
  2006-12-05  4:56 ` Jeff Garzik
                   ` (12 more replies)
  0 siblings, 13 replies; 61+ messages in thread
From: Andrew Morton @ 2006-12-05  4:40 UTC (permalink / raw)
  To: linux-kernel



add-bottom_half.h.patch
drm-sis-linkage-fix.patch
skip-data-conversion-in-compat_sys_mount-when-data_page-is-null.patch

 Will merge

revert-generic_file_buffered_write-handle-zero-length-iovec-segments.patch
revert-generic_file_buffered_write-deadlock-on-vectored-write.patch
generic_file_buffered_write-cleanup.patch
mm-only-mm-debug-write-deadlocks.patch
mm-fix-pagecache-write-deadlocks.patch
mm-fix-pagecache-write-deadlocks-comment.patch
mm-fix-pagecache-write-deadlocks-xip.patch
mm-fix-pagecache-write-deadlocks-mm-pagecache-write-deadlocks-efault-fix.patch
mm-fix-pagecache-write-deadlocks-zerolength-fix.patch
mm-fix-pagecache-write-deadlocks-stale-holes-fix.patch
fs-prepare_write-fixes.patch
fs-prepare_write-fixes-fuse-fix.patch
fs-prepare_write-fixes-jffs-fix.patch
fs-prepare_write-fixes-fat-fix.patch
fs-fix-cont-vs-deadlock-patches.patch

 This is the writev-speedup and pagefault-in-write() deadlock fix.  Not ready.

acpi-clear-gpe-before-disabling-it.patch
acpi-fix-single-linked-list-manipulation.patch
acpi-processor-prevent-loading-module-on-failures.patch
make-drivers-acpi-baycdrive_bays-static.patch
acpi-replace-kmallocmemset-with-kzalloc.patch
make-drivers-acpi-eccec_ecdt-static.patch
drivers-acpi-oslc-fix-a-null-check.patch
acpi-dont-select-pm.patch
implementation-of-acpi_video_get_next_level.patch
video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register.patch
add-display-output-class-support.patch
add-output-class-document.patch
add-support-for-asus-a6va-m6v-w5f-v6v-laptops-in-asus-acpi.patch
add-support-for-acpi_load_table-acpi_unload_table_id.patch
altix-acpi-ssdt-pci-device-support.patch
altix-add-acpi-ssdt-pci-device-support-hotplug.patch

 Sent to APCI maintainers

cpufreq-fix-bug-in-duplicate-freq-elimination-code-in-acpi-cpufreq.patch
remove-hotplug-cpu-crap-from-cpufreq.patch
cpufreq-select-consistently-re-2619-rc5-mm1.patch
cpufreq-set-policy-curfreq-on-initialization.patch
bug-fix-for-acpi-cpufreq-and-cpufreq_stats-oops-on-frequency-change-notification.patch

Sent to cpufreq maintainer

ppc-m48t35-add-missing-bracket.patch
ppc-cs4218_tdm-remove-extra-brace.patch
powerpc-replace-kmallocmemset-with-kzalloc.patch

 Am holding onto these until the powerpc git tree gets un-messied up.

fix2-gregkh-driver-modules-state.patch
platform_driver_probe-can-save-codespace-save-codespace.patch
driver-core-per-subsystem-multithreaded-probing.patch
driver-core-dont-fail-attaching-the-device-if-it.patch
make-platform_device_add_data-accept-a-const-pointer.patch

 Sent to Greg.

drm-fix-return-value-check.patch
drm-handle-pci_enable_device-failure.patch

 Sent to Dave.

ia64-resolve-name-clash-by-renaming-is_available_memory.patch
ia64-replace-kmallocmemset-with-kzalloc.patch

 Sent to Tony

crash-on-evdev-disconnect.patch

 Sent to Dmitry.

kconfig-new-function-bool-conf_get_changedvoid.patch
kconfig-make-sym_change_count-static-let-it-be-altered-by-2-functions-only.patch
kconfig-add-void-conf_set_changed_callbackvoid-fnvoid-use-it-in-qconfcc.patch
kconfig-set-gconfs-save-widgets-sensitivity-according-to-configs-changed-state.patch
pa-risc-fix-bogus-warnings-from-modpost.patch
kconfig-refactoring-for-better-menu-nesting.patch
kbuild-fix-rr-is-now-default.patch
kbuild-dont-put-temp-files-in-the-source-tree.patch
actually-delete-the-as-instr-ld-option-tmp-file.patch

 Sent to Sam, but Sam's presently busy.  I might need to make some kbuild
 decisions..

pci-move-pci_vdevice-from-libata-to-core.patch
pata_cs5530-suspend-resume-support-tweak.patch
pata_sil680-suspend-resume-tidy.patch
ata-fix-platform_device_register_simple-error-check.patch
initializer-entry-defined-twice-in-pata_rz1000.patch
ata_piix-ide-mode-sata-patch-for-intel-ich9.patch
pata_via-suspend-resume-support-fix.patch
sata_nv-add-suspend-resume-support.patch
trivial-piix-swap-bogus-dot-for-comma-space.patch
pata_ali-small-fixes.patch
pata_via-via-8251-bridged-systems-are-now-out-and-about.patch
pata_it8213-add-new-driver-for-the-it8213-card.patch
pata_it8213-add-new-driver-for-the-it8213-card-tidy.patch

 Sent to Jeff

via-pata-controller-xfer-fixes.patch
via-pata-controller-xfer-fixes-fix.patch
libata_resume_fix.patch
ahci-ati-sb600-sata-support-for-various-modes.patch

 libata random cruft.  Am sitting on these until things get resolved one way
 or the other.

git-mtd-ssfdc-build-fix.patch
mtd-esb2rom-uses-pci.patch
remove-mtd-jffs2-userh.patch
jffs2-replace-kmallocmemset-with-kzalloc.patch

 Sent to David.

libphy-dont-do-that.patch
3x59x-fix-pci-resource-management.patch
update-smc91x-driver-with-arm-versatile-board-info.patch
8139too-force-media-setting-fix.patch
sundance-change-phy-address-search-from-phy=1-to-phy=0.patch
bonding-incorrect-bonding-state-reported-via-ioctl.patch
declance-fix-pmax-and-pmad-support.patch
declance-support-the-i-o-asic-lance-w-o-turbochannel.patch
sk98lin-debug-build-fix.patch
net-smc91x-add-missing-bracket.patch

 Sent to Jeff

nfs-kill-obsolete-nfs_paranoia.patch
nfs-represent-64-bit-fileids-as-64-bit-inode-numbers-on-32-bit-systems.patch
gss_spkm3-fix-error-handling-in-module-init.patch
auth_gss-unregister-gss_domain-when-unloading-module.patch
fix-sunrpc-wakeup-execute-race-condition.patch

 Sent to Trond

8250-uart-backup-timer.patch
serial-trivial-code-flow-simplification.patch
make-sure-uart-is-powered-up-when-dumping-mctrl-status.patch
perle-multimodem-card-pci-ras-detection.patch
serial-replace-kmallocmemset-with-kzalloc.patch

 Serial patches, and we don't have a serial maintainer.  Hopefully Russell
 will have time to comment on these, otherwise I'll take a shot at it.

pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch
pci-introduce-pci_find_present.patch
pci-fix-multiple-problems-with-via-hardware.patch
fix-gregkh-pci-pci-enable-disable-device-is-nestable.patch
pci-check-szhi-when-sz-is-0-when-64-bit-iomem-bigger-than-4g.patch
dont-export-device-ids-to-userspace.patch
sys-bus-pci-drivers-driver-new_id-search-dynamics-ids-first.patch
be-a-bit-defensive-in-quirk_nvidia_ck804-so-we-dont-risk-dereferencing-a-null-pdev.patch

 Sent to Greg.

s390-preparatory-cleanup-in-common-i-o-layer.patch
s390-make-the-per-subchannel-lock-dynamic.patch
s390-dynamic-subchannel-mapping-of-ccw-devices.patch
s390-use-dev-groups-for-subchannel-attributes.patch
s390-update-cio-documentation.patch

 Sent to Martin.

drivers-scsi-small-cleanups.patch
drivers-scsi-aic7xxx-aic79xx_corec-make-ahd_match_scb-static.patch
scsi-clean-up-warnings-in-advansys-driver.patch
drivers-scsi-advansysc-cleanups.patch
megaraid-fix-warnings-when-config_proc_fs=n.patch
drivers-scsi-pcmcia-nsp_csh-removal-of-old.patch
remove-unnecessary-check-in-drivers-scsi-sgc.patch
remove-extra-newline-from-info-message.patch
fix-scsi-scsi_transporth-compile-error.patch
pci_module_init-convertion-in-the-legacy-megaraid-driver.patch
pci_module_init-convertion-in-tmscsimc.patch
drivers-scsi-dpt_i2oc-remove-dead-code.patch
mpt-fusion-handle-pci-layer-error-on-resume.patch
drivers-scsi-ncr5380c-replacing-yield-with-a.patch
drivers-scsi-megaraidc-replacing-yield-with-a.patch
scsi-whitespace-cleanup-in-the-dpt-driver.patch
scsi-fix-uaccess-handling.patch
drivers-scsi-mca_53c9xc-save_flags-cli-removal.patch
drivers-scsi-aic7xxx-make-functions-static.patch
scsi-advansys-wrap-pci-table-inside-ifdef-config_pci.patch
scsi-in2000-scsi_cmnd-convertion.patch
make-qla2x00_reg_remote_port-static.patch
iscsi-fix-crypto_alloc_hash-error-check.patch
scsi-sic7xxx-stray-bracket-fix.patch
scsi-53c7xx-brackets-fix.patch
fix-sense-key-medium-error-processing-and-retry.patch
sym53c8xx_2-claims-cpqarray-device.patch
aic79xx-wrong-max-memory-at-driver-init.patch
drivers-scsi-wd33c93c-cleanups.patch
scsi-megaraid-fix-mmio-casts.patch
scsi-cover-up-bugs-fix-up-compiler-warnings-in-megaraid-driver.patch

 Sent to James.

nokia-e70-is-an-unusual-device.patch
usb-auerswald-replace-kmallocmemset-with-kzalloc.patch
usb-fix-ohcih-over-use-warnings.patch
usb_rtl8150-must-select-mii.patch

 Sent to Greg.

hostap-replace-kmallocmemset-with-kzalloc.patch
prism54-replace-kmallocmemset-with-kzalloc.patch
ipw2200-replace-kmallocmemset-with-kcalloc.patch
softmac-fix-unbalanced-mutex_lock-unlock-in-ieee80211softmac_wx_set_mlme.patch

 Not sent to John - I forgot.

fix-x86_64-mm-patch-inline-replacements-for-section-warnings.patch
fix-x86_64-mm-i386-config-core2.patch
genapic-optimize-fix-apic-mode-setup.patch
mtrr-replace-kmallocmemset-with-kzalloc.patch
i386-correct-documentation-for-bzimage-protocol-v205.patch
fix-asm-constraints-in-i386-atomic_add_return.patch
i386-msr-remove-unused-variable.patch
arch-i386-kernel-remove-remaining-pc98-code.patch
i386-replace-kmallocmemset-with-kzalloc.patch
cleanup-arch-i386-kernel-smpbootcsmp_tune_scheduling.patch
make-i386-default-to-highmem4g-instead-of-nohighmem.patch
convert-i386-pda-code-to-use-%fs.patch
x86_64-check-vector-in-setup_ioapic_dest-to-verify-if-need-setup_io_apic_irq.patch
x86_64-make-the-numa-hash-function-nodemap-allocation.patch
x86_64-make-the-numa-hash-function-nodemap-allocation-fix.patch
include-asm-x86_64-cpufeatureh-isnt-a-userspace-header.patch
i386-kernel-smpc-dont-use-set_irq_regs.patch
fix-numaq-build-error.patch
x86_64-i386-kernel-mode-faults-pollute-current-thead.patch

 Sent to Andi.

memory-page-alloc-minor-cleanups.patch
memory-page-alloc-minor-cleanups-fix.patch
__unmap_hugepage_range-add-comment.patch
get-rid-of-zone_table.patch

 Shall merge.

deal-with-cases-of-zone_dma-meaning-the-first-zone.patch
get-rid-of-zone_table-fix-3.patch
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set-reduce-config_zone_dma-ifdefs.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
set-config_zone_dma-for-arches-with-generic_isa_dma.patch
zoneid-fix-up-calculations-for-zoneid_pgshift.patch

 Might drop, don't know yet.  These make a mess of core MM for dubiuous gain.

memory-page_alloc-zonelist-caching-speedup.patch
memory-page_alloc-zonelist-caching-reorder-structure.patch
oom-dont-kill-unkillable-children-or-siblings.patch
oom-cleanup-messages.patch
oom-less-memdie.patch
mm-incorrect-vm_fault_oom-returns-from-drivers.patch
grab-swap-token-reordered.patch
new-scheme-to-preempt-swap-token.patch
new-scheme-to-preempt-swap-token-tidy.patch
mm-add-arch_alloc_page.patch
balance_pdgat-cleanup.patch
shared-page-table-for-hugetlb-page-v4.patch
htlb-forget-rss-with-pt-sharing.patch
slab-debug-and-arch_slab_minalign-dont-get-along.patch
mm-slab-eliminate-lock_cpu_hotplug-from-slab.patch
add-noaliencache-boot-option-to-disable-numa-alien-caches.patch
mm-arch-do_page_fault-vs-in_atomic.patch
mm-pagefault_disableenable.patch
mm-pagefault_disableenable-s390-fix.patch
mm-kummap_atomic-vs-in_atomic.patch
fix-kunmap_atomics-use-of-kpte_clear_flush.patch
allowing-user-processes-to-rise-their-oom_adj-value.patch
mlock-cleanup.patch
oom-can-panic-due-to-processes-stuck-in-__alloc_pages.patch
always-print-out-the-header-line-in-proc-swaps.patch
leak-tracking-for-kmalloc_node.patch
leak-tracking-for-kmalloc_node-fix.patch
add-numa-node-information-to-struct-device.patch
add-numa-node-information-to-struct-device-tidy.patch
node-aware-skb-allocation.patch
node-aware-skb-allocation-fix-for-device-tree-changes.patch
allow-null-pointers-in-percpu_free.patch
enables-booting-a-numa-system-where-some-nodes-have-no.patch
make-mm-thrashcglobal_faults-static.patch
remove-bio_cachep-from-slabh.patch
move-sighand_cachep-to-include-signalh.patch
move-vm_area_cachep-to-include-mmh.patch
move-files_cachep-to-include-fileh.patch
move-filep_cachep-to-include-fileh.patch
move-fs_cachep-to-linux-fs_structh.patch
move-names_cachep-to-linux-fsh.patch
remove-uses-of-kmem_cache_t-from-mm-and-include-linux-slabh.patch
drain_node_page-drain-pages-in-batch-units.patch
numa-node-ids-are-int-page_to_nid-and-zone_to_nid-should-return-int.patch
silence-unused-pgdat-warning-from-alloc_bootmem_node-and-friends.patch
reject-corrupt-swapfiles-earlier.patch
mm-cleanup-indentation-on-switch-for-cpu-operations.patch
kill-install_file_ptes-pte_val.patch
slab-remove-slab_no_grow.patch
slab-remove-slab_level_mask.patch
slab-remove-slab_noio.patch
slab-remove-slab_nofs.patch
slab-remove-slab_user.patch
slab-remove-slab_atomic.patch
slab-remove-slab_kernel.patch
slab-remove-slab_dma.patch
slab-remove-kmem_cache_t.patch
slab-deprecate-kmem_cache-t.patch
slab-fixup-two-issues-in-kmalloc_node--__cache_alloc_node.patch
gfp_thisnode-must-not-trigger-global-reclaim.patch
slab-better-fallback-allocation-behavior.patch
mm-make-compound-page-destructor-handling-explicit.patch
mm-make-compound-page-destructor-handling-explicit-tidy.patch
save-some-bytes-in-struct-mm_struct.patch

 Memory management queue.  Shall merge, subject to re-review

mm-call-into-direct-reclaim-without-pf_memalloc-set.patch
mm-cleanup-and-document-reclaim-recursion.patch
congestion-wait-dont-wait-when-there-are-no-pages-under-writeback.patch

 Might merge - need to check these out a bit more closely.

radix-tree-rcu-lockless-readside.patch

 There's no reason to merge this yet.

acx1xx-wireless-driver.patch

 This is -mm-only material.

security-keys-user-kmemdup.patch
implement-file-posix-capabilities.patch

 Security - shall merge.

arch-frv-kernel-futexc-must-include-linux-uaccessh.patch
avr32-fixup-kprobes-preemption-handling.patch
h8300-stray-bracket-fix.patch
alpha-switch-to-pci_get-api.patch
m68k-replace-kmallocmemset-with-kzalloc.patch
uml-fix-prototypes.patch
fix-v850-compilation.patch

 Misc arch fixes - shall merge.

uswsusp-add-pmops-prepareenterfinish-support-aka-platform-mode.patch
swsusp-use-partition-device-and-offset-to-identify-swap-areas.patch
swsusp-rearrange-swap-handling-code.patch
swsusp-use-block-device-offsets-to-identify-swap-locations-rev-2.patch
swsusp-add-resume_offset-command-line-parameter-rev-2.patch
swsusp-document-support-for-swap-files-rev-2.patch
swsusp-add-ioctl-for-swap-files-support.patch
swsusp-update-userland-interface-documentation.patch
swsusp-improve-handling-of-highmem.patch
swsusp-improve-handling-of-highmem-fix.patch
swsusp-use-__gfp_wait.patch
swsusp-fix-platform-mode.patch
add-include-linux-freezerh-and-move-definitions-from.patch
add-include-linux-freezerh-and-move-definitions-from-ueagle-fix.patch
add-include-linux-freezerh-and-move-definitions-from-ucb1400_ts-fix.patch
quieten-freezer-if-config_pm_debug.patch
swsusp-cleanup-whitespace-in-freezer-output.patch
swsusp-thaw-userspace-and-kernel-space-separately.patch
swsusp-support-i386-systems-with-pae-or-without-pse.patch
suspend-dont-change-cpus_allowed-for-task-initiating-the-suspend.patch
swsusp-measure-memory-shrinking-time.patch
suspend-to-disk-fails-if-gdb-is-suspended-with-a-traced-child.patch
convert-pm_sem-to-a-mutex.patch
convert-pm_sem-to-a-mutex-fix.patch
swsusp-untangle-thaw_processes.patch
swsusp-untangle-freeze_processes.patch
swsusp-fix-coding-style-in-suspendc.patch
swsusp-fix-labels.patch
s2ram-debugging-documentation.patch
pm-fix-swsusp-debug-mode-testproc.patch
swsusp-kill-write-only-variable.patch
support-for-freezeable-workqueues.patch
use-freezeable-workqueues-in-xfs.patch

 power/swsusp - shall merge.

cciss-version-change.patch
cciss-reference-driver-support.patch
cciss-increase-number-of-commands-on-controller.patch
cciss-fix-pci-ssid-for-the-e500-controller.patch
cciss-disable-dma-prefetch-on-p600.patch
cciss-set-sector_size-to-2048-for-performance.patch
cciss-set-sector_size-to-2048-for-performance-tidy.patch
cciss-change-cciss_open-for-consistency.patch
cciss-remove-unused-revalidate_allvol-function.patch
cciss-add-support-for-1024-logical-volumes.patch
cciss-cleanup-cciss_interrupt-mode.patch

 Shall merge.

deprecate-smbfs-in-favour-of-cifs.patch
deprecate-smbfs-in-favour-of-cifs-docs.patch

 Am still waiting to hear from sfrench on the appropriateness of this.

edac-new-opteron-athlon64-memory-controller-driver.patch
drivers-edac-make-code-static.patch

 This stuff seems to be permanently stalled by Andi/Alan disagreement.

pci_module_init-convertion-for-k8_edacc.patch
fix-rescan_partitions-to-return-errors-properly.patch
fix-check_partition-routines.patch
serial-uartlite-driver.patch
serial-uartlite-driver-fix.patch
fix-serial-uartlite-after-global-pt_regs.patch
serial-uartlite-support-multiple-devices.patch
serial-uartlite-initialize-port-parameters-in-console_setup.patch
ioremap-balanced-with-iounmap-for-drivers-char-rio-rio_linuxc.patch
ioremap-balanced-with-iounmap-for-drivers-char-moxac.patch
ioremap-balanced-with-iounmap-for-drivers-char-istallionc.patch
sound-oss-btaudioc-ioremap-balanced-with-iounmap.patch
lockdep-annotate-nfs-nfsd-in-kernel-sockets.patch
lockdep-annotate-nfs-nfsd-in-kernel-sockets-tidy.patch
honour-mnt_noexec-for-access.patch
ext2-fsid-for-statvfs.patch
ext3-fsid-for-statvfs.patch
ext4-fsid-for-statvfs.patch
kernel-proc-kallsyms-reports-lower-case.patch
i2o-more-error-checking.patch
pnp-handle-sysfs-errors.patch
rtc-handle-sysfs-errors.patch
sound-oss-emu10k1-handle-userspace-copy-errors.patch
spi-improve-sysfs-compiler-complaint-handling.patch
drivers-add-lcd-support-3.patch
drivers-add-lcd-support-3-Kconfig-fix.patch
drivers-add-lcd-support-update-4.patch
drivers-add-lcd-support-update-5.patch
drivers-add-lcd-support-update6.patch
drivers-add-lcd-support-update-7.patch
drivers-add-lcd-support-update-8.patch
constify-inode-accessors.patch
ide-complete-switch-to-pci_get.patch
remove-drivers-pci-searchcpci_find_device_reverse.patch
fuse-update-userspace-interface-to-version-78.patch
fuse-minor-cleanup-in-fuse_dentry_revalidate.patch
fuse-add-support-for-block-device-based-filesystems.patch
fuse-add-blksize-option.patch
fuse-add-bmap-support.patch
fuse-add-destroy-operation.patch
fuse-fix-compile-without-config_block.patch
sysrq-x-show-blocked-tasks.patch
#sysrq-t-broke-and-no-one-noticed.patch
file-kill-unnecessary-timer-in-fdtable_defer.patch
remove-double-cast-to-same-type.patch
io-storage-documentation-update-to-as-ioschedtxt.patch
export-pm_suspend-for-the-shared-apm-emulation.patch
patch-to-fix-reiserfs-bad-path-release-panic-on-2619-rc1.patch
via82cxxx-handle-error-condition-properly.patch
lockdep-fix-ide-proc-interaction.patch
pull-in-necessary-header-files-for-cdevh.patch
cpuset-minor-code-refinements.patch
remove-superfluous-lock_super-in-ext2-and-ext3-xattr-code.patch
correct-bus_num-and-buffer-bug-in-spi-core.patch
spi-set-kset-of-master-class-dev-explicitly.patch
paride-rename-pi_register-and-pi_unregister.patch
paride_register-shuffle-return-values.patch
lockdep-internal-locking-fixes.patch
lockdep-misc-fixes-in-lockdepc.patch
cpuset-remove-sched-domain-hooks-from-cpusets.patch
binfmt_elf-randomize-pie-binaries.patch
handle-ext3-directory-corruption-better.patch
handle-ext4-directory-corruption-better.patch
tifm-fix-null-ptr-and-style.patch
function-v9fs_get_idpool-returns-int-not-u32-as-called-twice.patch
disable-clone_child_cleartid-for-abnormal-exit.patch
binfmt-fix-uaccess-handling.patch
compat-fix-uaccess-handling.patch
profile-fix-uaccess-handling.patch
kconfig-printk_time-depends-on-printk.patch
parport_pc-add-support-for-ox16pci952-parallel-port.patch
probe_kernel_address-needs-to-do-set_fs.patch
slab-use-probe_kernel_address.patch
paride-return-proper-error-code.patch
read_cache_pages-cleanup.patch
taskstats_exit_alloc-optimize-simplify.patch
taskstats-cleanup-do_exit-path.patch
taskstats-cleanup-signal-stats-allocation.patch
taskstats-factor-out-reply-assembling.patch
taskstats-use-nla_reserve-for-reply-assembling.patch
taskstats-cleanup-reply-assembling.patch
cpuset-allow-a-larger-buffer-for-writes-to-cpuset-files.patch
compile-time-check-re-world-writeable-module-params.patch
lockdep-annotate-bcsp-driver.patch
exar-quad-port-serial.patch
exar-quad-port-serial-fix.patch
fs-trivial-vsnprintf-conversion.patch
hpfs-bring-hpfs_error-into-shape.patch
hpfs-fix-printk-format-warnings.patch
drivers-cdrom-trivial-vsnprintf-conversion.patch
vfs-extra-check-inside-dentry_unhash.patch
correct-misc_register-return-code-handling-in-several-drivers.patch
more-list-debugging-context.patch
get_options-to-allow-a-hypenated-range-for-isolcpus.patch
vfs_getattr-remove-dead-code.patch
ext3-uninline-large-functions.patch
ext4-uninline-large-functions.patch
uninline-module_put.patch
i2lib-unused-variable-cleanup.patch
make-initramfs-printk-a-warning-on-incorrect-cpio-type.patch
corrupted-cramfs-filesystems-cause-kernel-oops.patch
lockdep-print-current-locks-on-in_atomic-warnings.patch
lockdep-name-some-old-style-locks.patch
documentation-remount_fs-needs-lock_kernel.patch
sleep-profiling.patch
sleep-profiling-fixes.patch
sleep-profiling-fix.patch
ext4_ext_split-remove-dead-code.patch
debug-workqueue-locking-sanity.patch
debug-workqueue-locking-sanity-fix.patch
hz-300hz-support.patch
pcengines-wrap-led-support.patch
pcengines-wrap-led-support-fix.patch
driver-base-memoryc-remove-warnings-of.patch
remove-kernel-syscalls.patch
remove-kernel-syscalls-x86_64-fix.patch
protect-ext2-ioctl-modifying-append_only-immutable-etc-with-i_mutex.patch
remove-hash_highmem.patch
retries-in-ext3_prepare_write-violate-ordering-requirements.patch
retries-in-ext3_prepare_write-violate-ordering-requirements-fix.patch
ktime-fix-signed--unsigned-mismatch-in-ktime_to_ns.patch
qconf-support-old-qt.patch
remove-the-syslog-interface-when-printk-is-disabled.patch
ver_linux-additions.patch
initrd-remove-unused-false-condition-for.patch
fix-the-size-limit-of-compat-space-msgsize.patch
elf-always-define-elf_addr_t-in-linux-elfh.patch
elf-include-terminating-zero-in-n_namesz.patch
elf-fix-kcore-note-size-calculation.patch
elf-fix-kcore-note-size-calculation-fix.patch
reiserfs-add-missing-d-cache-flushing.patch
reiserfs-add-missing-d-cache-flushing-tweak.patch
the-scheduled-removal-of-some-oss-options.patch
make-1-bit-bitfields-unsigned.patch
hvcs-char-driver-janitoring-move-block-of-code.patch
hvcs-char-driver-janitoring-rm-compiler-warnings.patch
kprobes-enable-booster-on-the-preemptible-kernel.patch
declare-smp_call_function_single-in-generic-code.patch
up-smp_call_function_single-should-disable-interrupts.patch
smp_call_function_single-check-that-local-interrupts-are-enabled.patch
hotplug-cpu-clean-up-hotcpu_notifier-use.patch
hotplug-cpu-clean-up-hotcpu_notifier-use-vs-gregkh-driver-cpu-topology-consider-sysfs_create_group-return-value.patch
ext3-fix-reservation-extension.patch
ext4-fix-reservation-extension.patch
allow-hwrandom-core-to-be-a-module.patch
make-mm-shmemcshmem_xattr_security_handler-static.patch
remove-kernel-lockdepclockdep_internal.patch
make-kernel-signalckill_proc_info-static.patch
i2o-handle-__copy_from_user.patch
i2o-fix-i2o_config-without-adaptec-extension.patch
make-ecryptfs_version_str_map-static.patch
make-fs-jbd-transactionc__journal_temp_unlink_buffer-static.patch
make-fs-jbd2-transactionc__jbd2_journal_temp_unlink_buffer-static.patch
fs-lockd-hostc-make-2-functions-static.patch
make-fs-proc-basecproc_pid_instantiate-static.patch
parport-section-mismatches-with-hotplug=n.patch
agp-amd64-section-mismatches-with-hotplug=n.patch
add-rtc-omap-driver.patch
add-return-value-checking-of-get_user-in.patch
add-return-value-checking-of-get_user-in-fix.patch
ciss-require-same-scsi-module-support.patch
export-toshiba-smm-support-for-neofb-module.patch
kernel-doc-add-fusion-and-i2o-to-kernel-api-book.patch
kernel-doc-fix-fusion-and-i2o-docs.patch
kernel-api-book-remove-videodev-chapter.patch
rcu-add-a-prefetch-in-rcu_do_batch.patch
dont-insert-pipe-dentries-into-dentry_hashtable.patch
dcache-avoid-rcu-for-never-hashed-dentries.patch
net-dont-insert-socket-dentries-into-dentry_hashtable.patch
kernel-core-replace-kmallocmemset-with-kzalloc.patch
kernel-doc-stricter-function-pointer-recognition.patch
fs-reorder-some-struct-inode-fields-to-speedup-i_size-manipulations.patch
add-struct-dev-pointer-to-dma_is_consistent.patch
pass-struct-dev-pointer-to-dma_cache_sync.patch
handle-per-subsystem-mutexes-for-config_hotplug_cpu-not-set.patch
handle-per-subsystem-mutexes-for-config_hotplug_cpu-not-set-tidy.patch
dz-fixes-to-make-it-work.patch
dz-fixes-to-make-it-work-fix.patch
reiser-replace-kmallocmemset-with-kzalloc.patch
futex-init-error-check.patch
spi-check-platform_device_register_simple-error.patch
synclink_gt-fix-init-error-handling.patch
sysctl-string-length-calculated-is-wrong-if-it-contains-negative-numbers.patch
sched-correct-output-of-show_state.patch
reiserfs-do-not-add-save-links-for-o_direct-writes.patch
reiserfs-do-not-add-save-links-for-o_direct-writes-fix.patch
rtc-rs5c372-change-register-reading-method.patch
reporting-bugs-request-config-file.patch
remove-useless-carta_random32h.patch
lib-functions-always-build-hweight-for-loadable-modules.patch
jbd2-wait-for-already-submitted-t_sync_datalist-buffer.patch
ext4-balloc-reset-windowsz-when-full.patch
ext4-balloc-fix-off-by-one-against-grp_goal.patch
ext4-balloc-fix-off-by-one-against-rsv_end.patch
ext4-balloc-say-rb_entry-not-list_entry.patch
ext4-balloc-use-io_error-label.patch
ext4-balloc-fix-_with_rsv-freeze.patch
better-config_w1_slave_ds2433_crc-handling.patch
lockdep-more-chains.patch
lockdep-show-more-details-about-self-test-failures.patch
ide_scsi-allow-it-to-be-used-for-non-cd-only.patch
ide_scsi-allow-it-to-be-used-for-non-cd-only-fix.patch
make-8250_pnp-serial-driver-work-after.patch
make-8250_pnp-serial-driver-work-after-tidy.patch
maintainers-update-the-i2c-and-hwmon-subsystems-info.patch
autofs-fix-error-code-path-in-autofs_fill_sb.patch
autofs-fix-error-code-path-in-autofs_fill_sb-fix.patch
doc-atomic_add_unless-doesnt-imply-mb-on-failure.patch
softirq-remove-bug_ons-which-can-incorrectly-trigger.patch
rtc-ds1743-support.patch
char-ip2-remove-broken-macro.patch
save-some-bytes-in-struct-inode.patch
winbond-ide-depends-on-idedma.patch
readme-updated.patch
amba-pl010-clear-error-flags-on-rx-error.patch
gcc-4-1-0-is-bust.patch
fs-sysv-doc-cleanup.patch
proper-prototype-for-remove_inode_dquot_ref.patch
remove-drivers-char-riscom8cbaud_table.patch
arch-i386-kernel-rebootc-should-include-linux-rebooth.patch
trivial-cleanup-in-the-pci-ids-for-the-cs5535.patch
fs-ufs-add-missing-bracket.patch
m68knommu-scatterlist-add-missing-bracket.patch
fs-reiserfs-add-missing-brackets.patch
kbuild-add-3-more-header-files-to-get-properly-unifdefed.patch
ext3-4-dont-do-orphan-processing-on-readonly-devices.patch
remove-export_unused_symboled-symbols.patch
fs-remove-unused-variable.patch
sys-remove-unused-variable.patch
add-sparse-annotations-to-srcu-wrapper-functions-in-rcutorture.patch
new-updated-devicestxt-lanana.patch
include-asm-cris-extern-inline-static-inline.patch
include-asm-h8300-extern-inline-static-inline.patch
include-asm-powerpc-extern-inline-static-inline.patch
remove-nfsd_optimize_space.patch
generic-hdlc-synclink-config-mismatch-fix.patch
maintainers-remove-the-non-existing-sun3-list.patch
futex-remove-unneeded-barrier.patch
cleanup-include-asm-generic-atomich.patch
paride-remove-parport-ifdefs.patch
remove-drivers-block-paride-jumbo.patch
affs-replace-kmallocmemset-with-kzalloc.patch
arm26-replace-kmallocmemset-with-kzalloc.patch
jffs-replace-kmallocmemset-with-kzalloc.patch
struct-seq_operations-and-struct-file_operations-constification.patch
struct-seq_operations-and-struct-file_operations-constification-fix.patch
struct-seq_operations-and-struct-file_operations-constification-fix-2.patch
fs-make-nls_cp936c-handle-some-u00xy-characters-and-u20ac.patch
cleanup-asm-setuph-userspace-visibility-v2.patch
do_coredump-and-not-stopping-rewrite-attacks.patch
kexec--kdump-unify-elf-note-code.patch
enable-raid-autorun-on-mac-partition-tables.patch
aio-kill-pointless-ki_nbytes-assignment-in-aio_setup_single_vector.patch
aio-remove-ki_retried-debugging-member.patch
ext4-fix-credit-calculation-in-ext4_ext_calc_credits_for_insert.patch
update-ext-mailing-list-address.patch
update-ext-mailing-list-address-fix.patch

 Misc.  Shall merge, subject to re-review.

ipmi-fix-device-model-name.patch
ipmi-remove-interface-number-limits.patch
ipmi-pass-sysfs-name-from-lower-level-driver.patch
ipmi-allow-hot-system-interface-remove.patch
ipmi-add-maintenance-mode.patch
ipmi-fix-request-events.patch
ipmi-add-poll-delay.patch
ipmi-system-interface-hotplug.patch
ipmi-add-pigeonpoint-poweroff.patch
ipmi-fix-pci-warning.patch
ipmi-fix-bt-long-busy.patch
ipmi-increase-kcs-message-size.patch
ipmi-fix-proc_fs=n-warnings.patch

 Shall merge

jbd-wait-for-already-submitted-t_sync_datalist-buffer.patch
ext3-balloc-reset-windowsz-when-full.patch
ext3-balloc-fix-off-by-one-against-grp_goal.patch
ext3-balloc-fix-off-by-one-against-rsv_end.patch
ext3-balloc-say-rb_entry-not-list_entry.patch
ext3-balloc-use-io_error-label.patch
ext3-balloc-fix-_with_rsv-freeze.patch

 Shall merge.

io-accounting-core-statistics.patch
clean-up-__set_page_dirty_nobuffers.patch
io-accounting-write-accounting.patch
io-accounting-write-cancel-accounting.patch
io-accounting-read-accounting-2.patch
io-accounting-read-accounting-nfs-fix.patch
io-accounting-read-accounting-nfs-fix-fix.patch
io-accounting-read-accounting-cifs-fix.patch
io-accounting-direct-io.patch
io-accounting-report-in-procfs.patch
cleanup-taskstatsh.patch
io-accounting-via-taskstats.patch
getdelays-various-fixes.patch
io-accounting-add-to-getdelays.patch

 I need to get these sent out for proper review.  Shall merge, all being well.

move-page-writeback-acounting-out-of-macros.patch
per-backing_dev-dirty-and-writeback-page-accounting.patch

 This is some stuff I'm working on to address writeback latency problems. 
 Not ready yet.

ext2-reservations.patch
ext2-fix-reservation-extension.patch
make-ext2_get_blocks-static.patch
ext2-balloc-fix-_with_rsv-freeze.patch
ext2-balloc-reset-windowsz-when-full.patch
ext2-balloc-fix-off-by-one-against-rsv_end.patch
ext2-balloc-fix-off-by-one-against-grp_goal.patch
ext2-balloc-say-rb_entry-not-list_entry.patch
ext2-balloc-use-io_error-label.patch

 Not for 2.6.20.  In fact it's unclear whether this should ever be merged -
 ext2 is more an "example filesytem" nowadays.  We'll see.

ext4-if-expression-format.patch
ext4-kmalloc-to-kzalloc.patch
ext4-eliminate-inline-functions.patch

 ext4 maintenance.  Shall merge.

tty-signal-tty-locking.patch
tty-signal-tty-locking-3270-fix.patch
do_task_stat-dont-take-tty_mutex.patch
do_acct_process-dont-take-tty_mutex.patch
trivial-make-set_special_pids-static.patch
sys_unshare-remove-a-broken-clone_sighand-code.patch

 tty rework - shall merge

pktcdvd-reusability-of-procfs-functions.patch
pktcdvd-make-procfs-interface-optional.patch
pktcdvd-bio-write-congestion-using-blk_congestion_wait.patch
pktcdvd-bio-write-congestion-using-blk_congestion_wait-fix.patch
pktcdvd-add-sysfs-and-debugfs-interface.patch

 Shall merge

remove-the-old-bd_mutex-lockdep-annotation.patch
new-bd_mutex-lockdep-annotation.patch
remove-lock_key-approach-to-managing-nested-bd_mutex-locks.patch
simplify-some-aspects-of-bd_mutex-nesting.patch
use-mutex_lock_nested-for-bd_mutex-to-avoid-lockdep-warning.patch
avoid-lockdep-warning-in-md.patch
bdev-fix-bd_part_count-leak.patch

 Shall merge.

generic-bug-implementation.patch
generic-bug-implementation-handle-bug=n.patch
generic-bug-implementation-include-linux-bugh-must-always-include-linux-moduleh.patch
generic-bug-for-i386.patch
generic-bug-for-x86-64.patch
uml-add-generic-bug-support.patch
use-generic-bug-for-ppc.patch
fix-generic-warn_on-message.patch

 Shall merge.

#generic-bug-for-powerpc.patch
#generic-bug-for-powerpc-fix.patch

 Shall then send these to the powerpc guys to look at - it crashes for me.

bit-revese-library.patch
crc32-replace-bitreverse-by-bitrev32.patch
video-use-bitrev8.patch
net-use-bitrev8.patch
net-use-bitrev8-tidy.patch
isdn-hisax-use-bitrev8.patch
atm-ambassador-use-bitrev8.patch
isdn-gigaset-use-bitrev8.patch

 Shall merge.

fsstack-introduce-fsstack_copy_attrinode_.patch
fsstack-introduce-fsstack_copy_attrinode_-tidy.patch
fsstack-introduce-fsstack_copy_attrinode_-fs-stackc-should-include-linux-fs_stackh.patch
ecryptfs-use-fsstacks-generic-copy-inode-attr.patch
ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix.patch
ecryptfs-use-fsstacks-generic-copy-inode-attr-tidy-fix-fix.patch
struct-path-rename-reiserfss-struct-path.patch
struct-path-rename-dms-struct-path.patch
struct-path-move-struct-path-from-fs-nameic-into.patch
struct-path-make-ecryptfs-a-user-of-struct-path.patch
vfs-change-struct-file-to-use-struct-path.patch
sysfs-change-uses-of-f_dentry.patch
proc-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ext2-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ext3-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ext4-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
fat-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
isofs-change-uses-of-f_dentry.patch
nfs-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
nfsd-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ntfs-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
i386-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
x86_64-change-uses-of-f_dentry.patch
kernel-change-uses-of-f_dentry.patch
mm-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
9p-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
affs-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
autofs-change-uses-of-f_dentry.patch
autofs4-change-uses-of-f_dentry.patch
configfs-change-uses-of-f_dentry.patch
cifs-change-uses-of-f_dentry-vfsmnt-to-use-f_path.patch
ecryptfs-change-uses-of-f_dentry.patch
xfs-change-uses-of-f_dentryvfsmnt-to-use-f_path.patch
struct-path-convert-adfs.patch
struct-path-convert-afs.patch
struct-path-convert-alpha.patch
struct-path-convert-atm.patch
struct-path-convert-befs.patch
struct-path-convert-bfs.patch
struct-path-convert-block.patch
struct-path-convert-block_drivers.patch
struct-path-convert-char-drivers.patch
struct-path-convert-coda.patch
struct-path-convert-cosa.patch
struct-path-convert-cramfs.patch
struct-path-convert-cris.patch
struct-path-convert-drm.patch
struct-path-convert-efs.patch
struct-path-convert-freevxfs.patch
struct-path-convert-frv.patch
struct-path-convert-fuse.patch
struct-path-convert-gfs2.patch
struct-path-convert-hfs.patch
struct-path-convert-hfsplus.patch
struct-path-convert-hostfs.patch
struct-path-convert-hpfs.patch
struct-path-convert-hppfs.patch
struct-path-convert-hugetlbfs.patch
struct-path-convert-i2c-drivers.patch
struct-path-convert-ia64.patch
struct-path-convert-ieee1394.patch
struct-path-convert-infiniband.patch
struct-path-convert-ipc.patch
struct-path-convert-ipmi.patch
struct-path-convert-isapnp.patch
struct-path-convert-isdn.patch
struct-path-convert-ixj.patch
struct-path-convert-jffs.patch
struct-path-convert-jffs2.patch
struct-path-convert-jfs.patch
struct-path-convert-kernel.patch
struct-path-convert-lockd.patch
struct-path-convert-md.patch
struct-path-convert-minix.patch
struct-path-convert-mips.patch
struct-path-convert-mm.patch
struct-path-convert-nbd.patch
struct-path-convert-ncpfs.patch
struct-path-convert-net.patch
struct-path-convert-netfilter.patch
struct-path-convert-netlink.patch
struct-path-convert-ocfs2.patch
struct-path-convert-openpromfs.patch
struct-path-convert-oprofile.patch
struct-path-convert-parisc.patch
struct-path-convert-pci.patch
struct-path-convert-pcmcia.patch
struct-path-convert-powerpc.patch
struct-path-convert-ppc.patch
struct-path-convert-qnx4.patch
struct-path-convert-ramfs.patch
struct-path-convert-reiserfs.patch
struct-path-convert-romfs.patch
struct-path-convert-s390-drivers.patch
struct-path-convert-s390.patch
struct-path-convert-sbus.patch
struct-path-convert-scsi.patch
struct-path-convert-selinux.patch
struct-path-convert-sh.patch
struct-path-convert-smbfs.patch
struct-path-convert-sound.patch
struct-path-convert-sparc.patch
struct-path-convert-sparc64.patch
struct-path-convert-sunrpc.patch
struct-path-convert-sysv.patch
struct-path-convert-udf.patch
struct-path-convert-ufs.patch
struct-path-convert-unix.patch
struct-path-convert-usb.patch
struct-path-convert-v4l.patch
struct-path-convert-video.patch
struct-path-convert-zorro.patch

 Shall merge.  I guess.  Doesn't seem very useful.

log2-implement-a-general-integer-log2-facility-in-the-kernel.patch
log2-implement-a-general-integer-log2-facility-in-the-kernel-fix.patch
log2-implement-a-general-integer-log2-facility-in-the-kernel-vs-git-cryptodev.patch
log2-implement-a-general-integer-log2-facility-in-the-kernel-ppc-fix.patch
log2-alter-roundup_pow_of_two-so-that-it-can-use-a-ilog2-on-a-constant.patch
log2-alter-get_order-so-that-it-can-make-use-of-ilog2-on-a-constant.patch
log2-provide-ilog2-fallbacks-for-powerpc.patch

 Shall merge.

add-process_session-helper-routine.patch
add-process_session-helper-routine-deprecate-old-field.patch
add-process_session-helper-routine-deprecate-old-field-tidy.patch
add-process_session-helper-routine-deprecate-old-field-fix-warnings.patch
add-process_session-helper-routine-deprecate-old-field-fix-warnings-2.patch
add-process_session-helper-routine-deprecate-old-field-fix-warnings-fix.patch
rename-struct-namespace-to-struct-mnt_namespace.patch
add-an-identifier-to-nsproxy.patch
rename-struct-pspace-to-struct-pid_namespace.patch
add-pid_namespace-to-nsproxy.patch
use-current-nsproxy-pid_ns.patch
add-child-reaper-to-pid_namespace.patch
sys_setpgid-eliminate-unnecessary-do_each_task_pidpidtype_pgid.patch
session_of_pgrp-kill-unnecessary-do_each_task_pidpidtype_pgid.patch

 Shall merge.

generic-ioremap_page_range-mips-conversion.patch
generic-ioremap_page_range-parisc-conversion.patch
generic-ioremap_page_range-s390-conversion.patch
generic-ioremap_page_range-sh-conversion.patch
generic-ioremap_page_range-sh64-conversion.patch

 Shall merge.

mxser-correct-tty-driver-name.patch
pci-mxser-pci-refcounts.patch
mxser-make-an-experimental-clone.patch
mxser-session-warning-fix.patch
char-mxser_new-correct-include-file.patch
char-mxser_new-upgrade-to-191.patch
char-mxser_new-rework-to-allow-dynamic-structs.patch
char-mxser_new-use-__devinit-macros.patch
char-mxser_new-pci_request_region-for-pci-regions.patch
char-mxser_new-check-request_region-retvals.patch
char-mxser_new-kill-unneeded-memsets.patch
char-mxser_new-revert-spin_lock-changes.patch
char-mxser_new-remove-request-for-testers-line.patch
char-mxser_new-debug-printk-dependent-on-debug.patch
char-mxser_new-alter-license-terms.patch
char-mxser_new-code-upside-down.patch
char-mxser_new-cmspar-is-defined.patch
char-remove-unneded-termbits-redefinitions-mxser_new.patch
char-mxser_new-eliminate-tty-ldisc-deref.patch
char-mxser_new-testbit-for-bit-testing.patch
char-mxser_new-correct-fail-paths.patch
char-mxser_new-dont-check-tty_unregister-retval.patch
char-mxser_new-compress-isa-finding.patch
char-mxser_new-register-tty-devices-on-the-fly.patch
char-mxser_new-compact-structures-round2.patch
char-mxser_new-reverse-if-else-paths-patch.patch
char-mxser_new-comments-cleanup.patch
char-mxser_new-correct-intr-handler-proto.patch
char-mxser_new-delete-ttys-and-termios.patch
char-mxser_new-pci-probing.patch
char-mxser_new-clean-macros.patch
maintainers-add-me-to-isicom-mxser.patch
mxser_new-correct-tty-driver-name.patch
char-stallion-use-pr_debug-macro.patch
char-stallion-remove-unneeded-casts.patch
char-stallion-kill-typedefs.patch
char-stallion-move-init-deinit.patch
char-stallion-uninline-functions.patch
char-stallion-mark-functions-as-init.patch
char-stallion-remove-many-prototypes.patch

 Shall merge.

tty-preparatory-structures-for-termios-revamp.patch
tty-preparatory-structures-for-termios-revamp-strip-fix.patch
tty-switch-to-ktermios-and-new-framework.patch
tty-switch-to-ktermios-and-new-framework-warning-fix.patch
tty-switch-to-ktermios-and-new-framework-irda-fix.patch
tty-switch-to-ktermios.patch
tty-switch-to-ktermios-nozomi-fix.patch
tty-switch-to-ktermios-bluetooth-fix.patch
tty-switch-to-ktermios-sclp-fix.patch
tty-switch-to-ktermios-3270-fix.patch
tty-switch-to-ktermios-powerpc-fix.patch
tty-switch-to-ktermios-uml-fix.patch
tty-switch-to-ktermios-uml-fix-2.patch
tty_ioctl-use-termios-for-the-old-structure-and-termios2.patch
tty_ioctl-use-termios-for-the-old-structure-and-termios2-fix.patch
tty_ioctl-use-termios-for-the-old-structure-and-termios2-update.patch
termios-enable-new-style-termios-ioctls-on-x86-64.patch

 termios -> ktermios work.  Shall merge.

char-isicom-expand-function.patch
char-isicom-rename-init-function.patch
char-isicom-remove-isa-code.patch
char-isicom-remove-unneeded-memset.patch
char-isicom-move-to-tty_register_device.patch
char-isicom-use-pci_request_region.patch
char-isicom-check-kmalloc-retval.patch
char-isicom-use-completion.patch
char-isicom-simplify-timer.patch
char-isicom-remove-cvs-stuff.patch
char-isicom-fix-tty-index-check.patch
char-sx-convert-to-pci-probing.patch
char-sx-use-kcalloc.patch
char-sx-mark-functions-as-devinit.patch
char-sx-use-eisa-probing.patch
char-sx-ifdef-isa-code.patch
char-sx-lock-boards-struct.patch
char-sx-remove-duplicite-code.patch
char-sx-whitespace-cleanup.patch
char-sx-simplify-timer-logic.patch
char-sx-fix-return-in-module-init.patch
char-sx-use-pci_iomap.patch
char-sx-request-regions.patch
char-stallion-convert-to-pci-probing.patch
char-stallion-prints-cleanup.patch
char-stallion-implement-fail-paths.patch
char-stallion-correct-__init-macros.patch
char-stallion-functions-cleanup.patch
char-stallion-fix-fail-paths.patch
char-stallion-brd-struct-locking.patch
char-stallion-remove-syntactic-sugar.patch
char-stallion-variables-cleanup.patch
char-stallion-use-dynamic-dev.patch
char-istallion-convert-to-pci-probing.patch
char-istallion-remove-the-mess.patch
char-istallion-eliminate-typedefs.patch
char-istallion-variables-cleanup.patch
char-istallion-ifdef-eisa-code.patch
char-istallion-brdnr-locking.patch
char-istallion-free-only-isa.patch
char-istallion-correct-fail-paths.patch
char-istallion-fix-enabling.patch
char-istallion-move-init-and-exit-code.patch
char-istallion-change-init-sequence.patch
char-istallion-dynamic-tty-device.patch
char-istallion-use-mod_timer.patch
char-cyclades-save-indent-levels.patch
char-cyclades-lindent-the-code.patch
char-cyclades-cleanup.patch
char-cyclades-fix-warnings.patch

 Shall merge.

drivers-isdn-handcrafted-min-max-macro-removal.patch
drivers-isdn-handcrafted-min-max-macro-removal-fix.patch
isdn-fix-missing-unregister_capi_driver.patch
isdn-avoid-a-potential-null-ptr-deref-in-ippp.patch
drivers-isdn-trivial-vsnprintf-conversion.patch
isdn-replace-kmallocmemset-with-kzalloc.patch
i4l-remove-the-broken-hisax_amd7930-option.patch
isdn-fix-warnings.patch

 ISDN.  Shall merge.

lockdep-annotate-nfsd4-recover-code.patch
nfs2-calculate-w-a-bit-later-in-nfsaclsvc_encode_getaclres.patch
nfs3-calculate-w-a-bit-later-in-nfs3svc_encode_getaclres.patch
nfsd-replace-kmallocmemset-with-kcalloc.patch

 nfsd - shall merge.

fault-injection-documentation-and-scripts.patch
fault-injection-capabilities-infrastructure.patch
fault-injection-capabilities-infrastructure-tidy.patch
fault-injection-capabilities-infrastructure-tweaks.patch
fault-injection-capability-for-kmalloc.patch
fault-injection-capability-for-kmalloc-failslab-remove-__gfp_highmem-filtering.patch
fault-injection-capability-for-alloc_pages.patch
fault-injection-capability-for-disk-io.patch
fault-injection-process-filtering-for-fault-injection-capabilities.patch
fault-injection-stacktrace-filtering.patch
fault-injection-stacktrace-filtering-reject-failure-if-any-caller-lies-within-specified-range.patch
fault-injection-Kconfig-cleanup.patch
fault-injection-stacktrace-filtering-kconfig-fix.patch
fault-injection-Kconfig-cleanup-config_fault_injection-help-text.patch

 Shall merge.

schedc-correct-comment-for-this_rq_lock-routine.patch
sched-fix-migration-cost-estimator.patch
sched-domain-move-sched-group-allocations-to-percpu-area.patch
move_task_off_dead_cpu-should-be-called-with-disabled-ints.patch
sched-domain-increase-the-smt-busy-rebalance-interval.patch
#
sched-avoid-taking-rq-lock-in-wake_priority_sleeper.patch
sched-remove-staggering-of-load-balancing.patch
sched-disable-interrupts-for-locking-in-load_balance.patch
sched-extract-load-calculation-from-rebalance_tick.patch
sched-move-idle-status-calculation-into-rebalance_tick.patch
sched-use-softirq-for-load-balancing.patch
sched-call-tasklet-less-frequently.patch
sched-add-option-to-serialize-load-balancing.patch
sched-add-option-to-serialize-load-balancing-fix.patch
sched-improve-migration-accuracy.patch
sched-improve-migration-accuracy-tidy.patch
sched-improve-migration-accuracy-fix.patch
sched-decrease-number-of-load-balances.patch
#
sched-optimize-activate_task-for-rt-task.patch
kernel-schedc-whitespace-cleanups.patch
kernel-schedc-whitespace-cleanups-more.patch

 CPU scheduler - shall merge subject to maintainer re-review.

sysctl-simplify-sysctl_uts_string.patch
sysctl-implement-sysctl_uts_string.patch
sysctl-simplify-ipc-ns-specific-sysctls.patch
sysctl-fix-sys_sysctl-interface-of-ipc-sysctls.patch
sysctl-fix-sys_sysctl-interface-of-ipc-sysctls-fix-2.patch

 sysctl cleanup - shall merge.

readahead-kconfig-options.patch
readahead-kconfig-options-fix.patch
radixtree-introduce-scan-hole-data-functions.patch
mm-introduce-probe_page.patch
mm-introduce-pg_readahead.patch
readahead-add-look-ahead-support-to-__do_page_cache_readahead.patch
readahead-insert-cond_resched-calls.patch
readahead-minmax_ra_pages.patch
readahead-events-accounting.patch
readahead-events-accounting-make-readahead_debug_level-static.patch
readahead-rescue_pages.patch
readahead-sysctl-parameters.patch
readahead-sysctl-parameters-use-ctl_unnumbered.patch
readahead-sysctl-parameters-fix.patch
readahead-min-max-sizes.patch
readahead-state-based-method-aging-accounting.patch
readahead-state-based-method-routines.patch
readahead-state-based-method.patch
readahead-context-based-method.patch
readahead-context-based-method-locking-fix.patch
readahead-context-based-method-locking-fix-2.patch
readahead-initial-method-guiding-sizes.patch
readahead-initial-method-thrashing-guard-size.patch
readahead-initial-method-user-recommended-size.patch
readahead-initial-method.patch
readahead-backward-prefetching-method.patch
readahead-thrashing-recovery-method.patch
readahead-call-scheme.patch
readahead-call-scheme-ifdef-fix.patch
readahead-call-scheme-build-fix.patch
readahead-laptop-mode.patch
readahead-loop-case.patch
readahead-nfsd-case.patch
readahead-nfsd-case-fix.patch
readahead-nfsd-case-fix-uninitialized-ra_min-ra_max.patch
readahead-turn-on-by-default.patch
readahead-remove-size-limit-on-read_ahead_kb.patch
readahead-remove-size-limit-of-max_sectors_kb-on-read_ahead_kb.patch

 Shall hold in -mm.

reiser4-sb_sync_inodes.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-remove_from_page_cache-fix.patch
reiser4-export-radix_tree_preload.patch
reiser4-export-find_get_pages.patch
make-copy_from_user_inatomic-not-zero-the-tail-on-i386-vs-reiser4.patch
reiser4.patch
reiser4-configh.patch
resier4-add-include-linux-freezerh-and-move-definitions-from.patch
reiser4-reiser4_drop_page-dont-call-remove_from_page_cache.patch
make-kmem_cache_destroy-return-void-reiser4.patch
reiser4-hardirq-include-fix.patch
reiser4-fix-trivial-tyops-which-were-hard-to-hit.patch
reiser4-run-truncate_inode_pages-in-reiser4_delete_inode.patch
reiser4-bug-fixes.patch
reiser4-fix-gcc-ws-compains.patch
fs-reiser4-possible-cleanups.patch
reiser4-get_sb_dev-fix.patch
reiser4-vs-zoned-allocator.patch
inode_diet-replace-inodeugeneric_ip-with-inodei_private-reiser4.patch
inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-reiser4.patch
reiser4-vs-streamline-generic_file_-interfaces-and-filemap.patch
reiser4-vs-streamline-generic_file_-interfaces-and-filemap-fix.patch
reiser4-rename-generic_sounding_globalspatch.patch
reiser4-get-rid-of-semaphores-wherever-it-is-possible.patch
reiser4-decribe-new-atom-locking-and-nested-atom-locks-to-lock-validator.patch
reiser4-use-generic-file-read.patch
reiser4-use-generic-file-read-fix-readpages-unix-file.patch
reiser4-simplify-reading-of-partially-converted-files.patch
reiser4-use-page_offset.patch
reiser4-use-reiser4_gfp_mask_get-in-reiser4-inode-allocation.patch
reiser4-re-add-page_count-check-to-reiser4_releasepage.patch
reiser4-restore-fibmap-ioctl-support-for-packed-files.patch
reiser4-possible-cleanups-2.patch
reiser4-format-subversion-numbers-heir-set-and-file-conversion.patch
reiser4-format-subversion-numbers-heir-set-and-file-conversion-fix-readpages-cryptcompress.patch
reiser4-cleanups-in-lzo-compression-library.patch
reiser4-get-rid-of-deprecated-crypto-api.patch
reiser4-get-rid-of-deprecated-crypto-api-build-fix.patch
reiser4-fix-missed-unlock-and-exit_context.patch
reiser4-use-list_head-instead-of-struct-blocknr.patch
reiser4-use-list_empty-instead-of-list_empty_careful-for.patch
reiser4-update-comments-fix-write-and-truncate-cryptcompress.patch
reiser4-temp-fix.patch
fs-reiser4-possible-cleanups-2.patch
fs-reiser4-more-possible-cleanups.patch
reiser4-use-null-for-pointers.patch

 Shall hold in -mm.

ide-hpt3xxn-clocking-fixes.patch
ide-fix-hpt37x-timing-tables.patch
ide-optimize-hpt37x-timing-tables.patch
ide-fix-hpt3xx-hotswap-support.patch
ide-fix-the-case-of-multiple-hpt3xx-chips-present.patch
ide-hpt3xx-fix-pci-clock-detection.patch
ide-hpt3xx-fix-pci-clock-detection-fix-2.patch
piix-fix-82371mx-enablebits.patch
piix-remove-check-for-broken-mw-dma-mode-0.patch
piix-slc90e66-pio-mode-fallback-fix.patch
hpt3xx-rework-rate-filtering.patch
hpt3xx-rework-rate-filtering-tidy.patch
hpt3xx-print-the-real-chip-name-at-startup.patch
hpt3xx-switch-to-using-pci_get_slot.patch
hpt3xx-cache-channels-mcr-address.patch
hpt3x7-merge-speedproc-handlers.patch
hpt370-clean-up-dma-timeout-handling.patch
hpt3xx-init-code-rewrite.patch
jmicron-warning-fix.patch

 Scary IDE changes.  Shall poll Alan again.

ide-more-conversion-to-pci_get-apis.patch
pdc202xx_new-fix-pio-mode-setup.patch
ide-cd-handle-strange-interrupt-on-the-intel-esb2.patch

 Shall merge.

ioremap-balanced-with-iounmap-for-drivers-video-virgefb.patch
ioremap-balanced-with-iounmap-for-drivers-video-vesafb.patch
ioremap-balanced-with-iounmap-for-drivers-video-tridentfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-tgafb.patch
ioremap-balanced-with-iounmap-for-drivers-video-stifb.patch
ioremap-balanced-with-iounmap-for-drivers-video-retz3fb.patch
ioremap-balanced-with-iounmap-for-drivers-video-pvr2fb.patch
ioremap-balanced-with-iounmap-for-drivers-video-platinumfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-offb.patch
ioremap-balanced-with-iounmap-for-drivers-video-macfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-hpfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-fm2fb.patch
ioremap-balanced-with-iounmap-for-drivers-video-ffb.patch
ioremap-balanced-with-iounmap-for-drivers-video-cyberfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-cirrusfb.patch
ioremap-balanced-with-iounmap-for-drivers-video-atyfb_base.patch
ioremap-balanced-with-iounmap-for-drivers-video-atafb.patch
ioremap-balanced-with-iounmap-for-drivers-video-amifb.patch
ioremap-balanced-with-iounmap-for-drivers-video-S3triofb.patch
atyfb-rivafb-minor-fixes.patch
igafb-switch-to-pci_get-api.patch
video-sis-remove-unnecessary-variables-in-sis_ddc2delay.patch
pmagb-b-fb-fix-a-default-clock.patch
video-get-the-default-mode-from-the-right-database.patch
s3c2410fb-add-support-for-stn-displays.patch
fbcmapc-mark-structs-const-or.patch
various-fbdev-files-mark-structs.patch
various-fbdev-files-mark-structs-fix.patch
constify-and-annotate-__read_mostly.patch
annotate-some-variables-in-vesafb.patch
constify-vga16fbc.patch
au1100fb-fix-to-remove-flickering.patch
mbxfb-fix-hscoeff3-register-address.patch
mbxfb-add-more-registers-bits.patch
mbxfb-add-more-registers-to-debugfs.patch
mbxfb-add-yuv-video-overlay-support.patch
mbxfb-document-the-new-ioctl.patch
atyfb-remove-fixme.patch
atyfb-fix-compiler-warnings.patch
atyfb-fix-sparse-warnings.patch
atyfb-fix-blanking-level.patch
atyfb-remove-pointless-aty_init.patch
atyfb-fix-__init-and-__devinit.patch
atyfb-remove-aty_cmap_regs.patch
atyfb-improve-atyfb_atari_probe.patch
atyfb-improve-power-management.patch
drivers-video-use-kmemdup.patch
visws-sgivwfb-is-module-needs-exports.patch
backlight-lcd-remove-dependenct-from-the-framebuffer-layer.patch
backlight-lcd-remove-dependenct-from-the-framebuffer-layer-tidy.patch
softcursorc-avoid-unaligned-accesses.patch
backlight-do-not-power-off-backlight-when-unregistering-try-3.patch
fb-get-the-geode-gx-frambuffer-size-from-the-bios.patch
gxfb-fixups-for-the-amd-geode-gx.patch
gxfb-fixups-for-the-amd-geode-gx-tidy.patch
gxfb-support-flat-panel-timings.patch
gxfb-support-flat-panel-timings-tidy.patch
gxfb-support-command-line-options.patch
gxfb-support-command-line-options-tidy.patch
gxfb-fixup-flatpanel-detection.patch
gxfb-turn-on-the-flatpanel-power-and-data.patch
video-select-set-for-vesa-fb.patch
video-cyberfb-broken-macro-removal.patch
video-neofb-stray-bracket-fix.patch
video-pm3fb-macros-fix.patch

 Shall merge.

dm-io-fix-bi_max_vecs.patch
dm-tidy-core-formatting.patch
dm-suspend-parameter-change.patch
dm-map-and-endio-return-code-clarification.patch
dm-map-and-endio-symbolic-return-codes.patch
dm-ioctl-add-noflush-suspend.patch
dm-suspend-add-noflush-pushback.patch
dm-mpath-use-noflush-suspending.patch
dm-snapshot-abstract-memory-release.patch
dm-log-rename-complete_resync_work.patch
dm-raid1-reset-sync_search-on-resume.patch
make-drivers-md-dm-snapcksnapd-static.patch

 Shall merge.

md-tidy-up-device-change-notification-when-an-md-array-is-stopped.patch
md-define-raid5_mergeable_bvec.patch
md-handle-bypassing-the-read-cache-assuming-nothing-fails.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure-fix.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure-misc-fixes-for-aligned-read-handling-including-raid6-read-corruption.patch
md-allow-reads-that-have-bypassed-the-cache-to-be-retried-on-failure-misc-fixes-for-error-handling-of-aligned-reads.patch
md-enable-bypassing-cache-for-reads.patch
md-fix-innocuous-bug-in-raid6-stripe_to_pdidx.patch
md-conditionalize-some-code.patch

 I have a note here "The MD patches probably broke jurriaan
 <thunder7@xs4all.nl>'s setup".  Need to work out whether that got resolved.

md-change-lifetime-rules-for-md-devices.patch

 This caused oopses for Jiri Kosina <jikos@jikos.cz>

md-dm-reduce-stack-usage-with-stacked-block-devices.patch

 Shall hold in -mm.

statistics-infrastructure-prerequisite-list.patch
statistics-infrastructure-prerequisite-parser.patch
statistics-infrastructure-prerequisite-timestamp.patch
statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution.patch
statistics-infrastructure-make-printk_clock-a-generic-kernel-wide-nsec-resolution-ia64-fix.patch
statistics-infrastructure-documentation.patch
statistics-infrastructure.patch
statistics-infrastructure-fix-buffer-overflow-in-histogram-with-linear.patch
statistics-infrastructure-fix-buffer-overflow-in-histogram-with-linear-tidy.patch
statistics-infrastructure-adapt-output-format-of-utilisation-indicator.patch
statistics-use-the-enhanced-percpu-interface.patch
statistics-replace-inode-ugeneric_ip-with-i_private.patch
statistics-infrastructure-exploitation-zfcp.patch
zfcp-gather-hba-specific-latencies-in-statistics.patch

 Still trying to generate a case for merging this.

extend-notifier_call_chain-to-count-nr_calls-made.patch
extend-notifier_call_chain-to-count-nr_calls-made-fixes.patch
extend-notifier_call_chain-to-count-nr_calls-made-fixes-2.patch
define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release.patch
define-and-use-new-eventscpu_lock_acquire-and-cpu_lock_release-fix.patch
eliminate-lock_cpu_hotplug-in-kernel-schedc.patch
eliminate-lock_cpu_hotplug-in-kernel-schedc-fix.patch
handle-cpu_lock_acquire-and-cpu_lock_release-in-workqueue_cpu_callback.patch

 Shall merge.

mark-pci_module_init-deprecated.patch

 Send to Greg.

dio-centralize-completion-in-dio_complete.patch
dio-call-blk_run_address_space-once-per-op.patch
dio-formalize-bio-counters-as-a-dio-reference-count.patch
dio-remove-duplicate-bio-wait-code.patch
dio-only-call-aio_complete-after-returning-eiocbqueued.patch
dio-lock-refcount-operations.patch

 Shall merge.

fdtable-delete-pointless-code-in-dup_fd.patch
fdtable-make-fdarray-and-fdsets-equal-in-size.patch
fdtable-remove-the-free_files-field.patch
fdtable-implement-new-pagesize-based-fdtable-allocator.patch
fdtable-implement-new-pagesize-based-fdtable-allocator-fix.patch
fdtable-implement-new-pagesize-based-fdtable-allocator-bound-minimum-allocation-size.patch
fdtable-implement-new-pagesize-based-fdtable-allocator-avoid-fdset-cacheline-ping-pong.patch

 Shall merge.

gtod-exponential-update_wall_time.patch

 Roman wanted this dropped, and afaik that's unresolved.

gtod-persistent-clock-support-core.patch
gtod-persistent-clock-support-core-remove-kernel-timercwall_jiffies.patch
gtod-persistent-clock-support-i386.patch
gtod-persistent-clock-support-i386-i386-unexport-read_persistent_clock.patch
time-uninline-jiffiesh.patch
time-uninline-jiffiesh-fix.patch
time-fix-msecs_to_jiffies-bug.patch
time-fix-timeout-overflow.patch
cleanup-uninline-irq_enter-and-move-it-into-a-function.patch
dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie.patch
dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie-remove-incorrect-warning-in-kernel-timerc.patch
dynticks-extend-next_timer_interrupt-to-use-a-reference-jiffie-make-kernel-timerc__next_timer_interrupt-static.patch
hrtimers-namespace-and-enum-cleanup.patch
hrtimers-clean-up-locking.patch
hrtimers-clean-up-locking-fix.patch
updated-hrtimers-state-tracking.patch
updated-hrtimers-clean-up-callback-tracking.patch
updated-hrtimers-move-and-add-documentation.patch
updated-add-a-framework-to-manage-clock-event-devices.patch
updated-acpi-include-apich.patch
updated-acpi-keep-track-of-timer-broadcast.patch
updated-acpi-add-state-propagation-for-dynamic-broadcasting.patch
updated-i386-cleanup-apic-code.patch
updated-i386-convert-to-clock-event-devices.patch
updated-i386-convert-to-clock-event-devices-fix.patch
updated-i386-convert-to-clock-event-devices-arch-i386-kernel-apicc-make-a-function-static.patch
updated-i386-convert-to-clock-event-devices-remove-arch-i386-kernel-time_hpetchpet_reenable.patch
updated-pm_timer-allow-early-access-and-move-externs-to-a-header-file.patch
updated-i386-rework-local-apic-calibration.patch
updated-high-res-timers-core.patch
updated-high-res-timers-core-high-res-timers-do-itimer-rearming-in-process-context.patch
updated-gtod-mark-tsc-unusable-for-highres-timers.patch
high-res-timers-utilize-tsc-clocksource-again.patch
high-res-timers-utilize-tsc-clocksource-again-fix.patch
updated-dynticks-core-code.patch
updated-dynticks-core-code-fix-resume-bug.patch
updated-dyntick-add-nohz-stats-to-proc-stat.patch
updated-dynticks-i386-arch-code.patch
updated-dynticks-fix-nmi-watchdog.patch
updated-high-res-timers-dynticks-enable-i386-support.patch
updated-debugging-feature-timer-stats.patch

 Shall merge, I guess.  My confidence is low, but it's Kconfigurable and it
 needs to get sorted out.

clockevents-core-check-for-clock-event-device-handler-being-non-null-before-calling-it.patch
round_jiffies-infrastructure.patch
round_jiffies-infrastructure-fix.patch
user-of-the-jiffies-rounding-patch-ata-subsystem.patch
user-of-the-jiffies-rounding-code-jbd.patch
user-of-the-jiffies-rounding-code-networking.patch
user-of-the-jiffies-rounding-patch-slab.patch
clocksource-add-usage-of-config_sysfs.patch
clocksource-small-cleanup-2.patch
clocksource-small-cleanup-2-fix.patch
clocksource-small-acpi_pm-cleanup.patch

 Shall merge.

kvm-userspace-interface.patch
kvm-userspace-interface-make-enum-values-in-userspace-interface-explicit.patch
kvm-intel-virtual-mode-extensions-definitions.patch
kvm-kvm-data-structures.patch
kvm-random-accessors-and-constants.patch
kvm-virtualization-infrastructure.patch
kvm-virtualization-infrastructure-kvm-fix-guest-cr4-corruption.patch
kvm-virtualization-infrastructure-include-desch.patch
kvm-virtualization-infrastructure-fix-segment-state-changes-across-processor-mode-switches.patch
kvm-virtualization-infrastructure-fix-asm-constraints-for-segment-loads.patch
kvm-virtualization-infrastructure-fix-mmu-reset-locking-when-setting-cr0.patch
kvm-memory-slot-management.patch
kvm-memory-slot-management-zero-guest-memory-before-use.patch
kvm-vcpu-creation-and-maintenance.patch
kvm-vcpu-creation-and-maintenance-segment-access-cleanup.patch
kvm-workaround-cr0cd-cache-disable-bit-leak-from-guest-to.patch
kvm-vcpu-execution-loop.patch
kvm-define-exit-handlers.patch
kvm-define-exit-handlers-pass-fs-gs-segment-bases-to-x86-emulator.patch
kvm-less-common-exit-handlers.patch
kvm-less-common-exit-handlers-handle-rdmsrmsr_efer.patch
kvm-mmu.patch
kvm-mmu-mmu-honor-global-bit-on-huge-pages.patch
kvm-x86-emulator.patch
kvm-x86-emulator-x86-emulator-handle-smsw.patch
kvm-clarify-licensing.patch
kvm-x86-emulator-fix-emulator-mov-cr-decoding.patch
kvm-plumbing.patch
kvm-dynamically-determine-which-msrs-to-load-and-save.patch
kvm-fix-calculation-of-initial-value-of-rdx-register.patch
kvm-avoid-using-vmx-instruction-directly.patch
kvm-avoid-using-vmx-instruction-directly-fix-asm-constraints.patch
kvm-expose-interrupt-bitmap.patch
kvm-add-time-stamp-counter-msr-and-accessors.patch
kvm-expose-msrs-to-userspace.patch
kvm-expose-msrs-to-userspace-v2.patch
kvm-create-kvm-intelko-module.patch
kvm-make-dev-registration-happen-when-the-arch.patch
kvm-make-hardware-detection-an-arch-operation.patch
kvm-make-the-per-cpu-enable-disable-functions-arch.patch
kvm-make-the-hardware-setup-operations-non-percpu.patch
kvm-make-the-guest-debugger-an-arch-operation.patch
kvm-make-msr-accessors-arch-operations.patch
kvm-make-the-segment-accessors-arch-operations.patch
kvm-cache-guest-cr4-in-vcpu-structure.patch
kvm-cache-guest-cr0-in-vcpu-structure.patch
kvm-add-get_segment_base-arch-accessor.patch
kvm-add-idt-and-gdt-descriptor-accessors.patch
kvm-make-syncing-the-register-file-to-the-vcpu.patch
kvm-make-the-vcpu-execution-loop-an-arch-operation.patch
kvm-make-the-vcpu-execution-loop-an-arch-operation-build-fix.patch
kvm-move-the-vmx-exit-handlers-to-vmxc.patch
kvm-make-vcpu_setup-an-arch-operation.patch
kvm-make-__set_cr0-and-dependencies-arch-operations.patch
kvm-make-__set_cr4-an-arch-operation.patch
kvm-make-__set_efer-an-arch-operation.patch
kvm-make-__set_efer-an-arch-operation-build-fix.patch
kvm-make-set_cr3-and-tlb-flushing-arch-operations.patch
kvm-make-inject_page_fault-an-arch-operation.patch
kvm-make-inject_gp-an-arch-operation.patch
kvm-use-the-idt-and-gdt-accessors-in-realmode-emulation.patch
kvm-use-the-general-purpose-register-accessors-rather.patch
kvm-move-the-vmx-tsc-accessors-to-vmxc.patch
kvm-access-rflags-through-an-arch-operation.patch
kvm-move-the-vmx-segment-field-definitions-to-vmxc.patch
kvm-add-an-arch-accessor-for-cs-d-b-and-l-bits.patch
kvm-add-a-set_cr0_no_modeswitch-arch-accessor.patch
kvm-make-vcpu_load-and-vcpu_put-arch-operations.patch
kvm-make-vcpu-creation-and-destruction-arch-operations.patch
kvm-move-vmcs-static-variables-to-vmxc.patch
kvm-make-is_long_mode-an-arch-operation.patch
kvm-use-the-tlb-flush-arch-operation-instead-of-an.patch
kvm-remove-guest_cpl.patch
kvm-move-vmcs-accessors-to-vmxc.patch
kvm-move-vmx-helper-inlines-to-vmxc.patch
kvm-remove-vmx-includes-from-arch-independent-code.patch
kvm-amd-svm-add-architecture-definitions-for-amd-svm.patch
kvm-amd-svm-enhance-x86-emulator.patch
kvm-amd-svm-enhance-x86-emulator-fix-mov-to-from-control-register-emulation.patch
kvm-amd-svm-add-missing-tlb-flushes-to-the-guest-mmu.patch
kvm-amd-svm-add-data-structures.patch
kvm-amd-svm-implementation.patch
kvm-amd-svm-implementation-avoid-three-more-new-instructions.patch
kvm-amd-svm-implementation-more-i386-fixes.patch
kvm-amd-svm-implementation-printk-log-levels.patch
kvm-amd-svm-plumbing.patch
kvm-fix-null-and-c99-init-sparse-warnings.patch
kvm-load-i386-segment-bases.patch

 Shall fold into a single patch and merge it.

mprotect-patch-for-use-by-slim.patch
integrity-service-api-and-dummy-provider.patch
integrity-service-api-and-dummy-provider-cleanup-use-of-configh.patch
integrity-service-api-and-dummy-provider-compilation-warning-fix.patch
slim-main-patch.patch
slim-main-patch-socket_post_create-hook-return-code.patch
slim-main-patch-misc-cleanups-requested-at-inclusion-time.patch
slim-main-patch-handle-failure-to-register.patch
slim-main-patch-fix-bug-with-mm_users-usage.patch
slim-main-patch-security-slim-slm_mainc-make-2-functions-static.patch
slim-secfs-patch.patch
slim-secfs-patch-slim-correct-use-of-snprintf.patch
slim-secfs-patch-cleanup-use-of-configh.patch
slim-make-and-config-stuff.patch
slim-make-and-config-stuff-makefile-fix.patch
slim-debug-output.patch
slim-fix-security-issue-with-the-task_post_setuid-hook.patch
slim-secfs-inode-i_private-build-fix.patch
slim-documentation.patch
fdtable-make-fdarray-and-fdsets-equal-in-size-slim.patch

 Shall hold in -mm.



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

end of thread, other threads:[~2006-12-19  7:03 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-05 23:55 -mm merge plans for 2.6.20 Alessandro Guido
2006-12-06  0:13 ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2006-12-13  1:09 Chuck Ebbert
2006-12-11  9:32 Chuck Ebbert
2006-12-10  3:18 Chuck Ebbert
2006-12-11  4:19 ` Steve French
2006-12-08 18:32 Steve French
2006-12-08 21:38 ` Andrew Morton
2006-12-05  4:40 Andrew Morton
2006-12-05  4:56 ` Jeff Garzik
2006-12-05  5:41   ` Andrew Morton
2006-12-05  7:04     ` Jens Axboe
2006-12-05 15:00     ` Mark Lord
2006-12-06 19:19     ` Conke Hu
2006-12-06 19:26       ` Randy Dunlap
2006-12-06 19:40       ` Jeff Garzik
2006-12-06 22:36       ` Andrew Morton
2006-12-05  5:14 ` Paul Mackerras
2006-12-05  5:42   ` Andrew Morton
2006-12-05  5:53     ` Nick Piggin
2006-12-05  5:49   ` Nick Piggin
2006-12-05  8:36 ` Gautham R Shenoy
2006-12-05  8:47 ` Peter Zijlstra
2006-12-05 13:23 ` John W. Linville
2006-12-05 14:27 ` Roman Zippel
2006-12-06  3:46   ` Horst Schirmeier
2006-12-05 16:02 ` Dave Jones
2006-12-12 17:49   ` Dave Jones
2006-12-19  5:20     ` Nick Piggin
2006-12-19  6:44       ` Dave Jones
2006-12-19  7:02         ` Nick Piggin
2006-12-05 17:35 ` James Simmons
2006-12-05 18:01   ` Andrew Morton
2006-12-05 18:25     ` James Simmons
2006-12-05 19:43       ` Andrew Morton
2006-12-05 19:59         ` James Simmons
2006-12-05 20:20           ` Andrew Morton
2006-12-05 21:34             ` James Simmons
2006-12-06 23:40               ` Andrew Morton
2006-12-07 14:31                 ` James Simmons
2006-12-05 20:40       ` Miguel Ojeda
2006-12-06 14:42         ` James Simmons
2006-12-05 19:18 ` Josef Sipek
2006-12-05 21:00 ` Ingo Molnar
2006-12-06  2:59 ` Roman Zippel
2006-12-06  4:30   ` Andrew Morton
2006-12-06  8:32     ` Thomas Gleixner
2006-12-06 12:54       ` Roman Zippel
2006-12-06 13:11         ` Ingo Molnar
2006-12-06 14:33           ` Roman Zippel
2006-12-06 15:22             ` Ingo Molnar
2006-12-06 16:42               ` Roman Zippel
2006-12-06 16:58                 ` Ingo Molnar
2006-12-06 16:59                 ` Ingo Molnar
2006-12-06 12:33     ` Roman Zippel
2006-12-08 14:09 ` Stephen Smalley
2006-12-08 20:58   ` Andrew Morton
2006-12-10 15:07     ` Mimi Zohar
2006-12-09  9:30 ` Randy Dunlap
2006-12-09  9:44   ` Andrew Morton
2006-12-10 20:12     ` Randy Dunlap

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