[patch 00/14] 2.6.25-stable review

[patch 00/14] 2.6.25-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.25.19 release.
There are 14 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let us know.  If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the
Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
to add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Wed, October 22, 2008 19:00:00 UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.19-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

----------

 Makefile                                |    2 
 arch/x86/kernel/alternative.c           |    2 
 arch/x86/kernel/cpu/mtrr/generic.c      |    7 +
 arch/x86/kernel/io_apic_32.c            |    3 
 arch/x86/mm/ioremap.c                   |    2 
 drivers/char/drm/i915_dma.c             |    2 
 drivers/char/tty_io.c                   |    2 
 drivers/hwmon/it87.c                    |   39 ++++++++-
 drivers/media/video/bt8xx/bttv-driver.c |    2 
 drivers/media/video/zoran_driver.c      |    2 
 drivers/net/wireless/b43legacy/xmit.c   |    2 
 drivers/video/console/fbcon.c           |    4 -
 fs/cifs/cifsglob.h                      |    1 
 fs/cifs/cifssmb.c                       |    4 +
 fs/cifs/readdir.c                       |  128 ++++++++++++++++----------------
 fs/splice.c                             |    3 
 kernel/sched_rt.c                       |    8 +-
 17 files changed, 129 insertions(+), 84 deletions(-)

[patch 01/14] x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.

[Greg KH]

[-- Attachment #1: x86-reserve-first_device_vector-in-used_vectors-bitmap.patch --]
[-- Type: text/plain, Size: 1499 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Stefan Bader <stefan.bader@canonical.com>

Not in upstream above 2.6.27 due to change in the way this code works
(has been fixed differently there.)

Someone from the community found out, that after repeatedly unloading
and loading a device driver that uses MSI IRQs, the system eventually
assigned the vector initially reserved for IRQ0 to the device driver.

The reason for this is, that although IRQ0 is tied to the
FIRST_DEVICE_VECTOR when declaring the irq_vector table, the
corresponding bit in the used_vectors map is not set. So, if vectors are
released and assigned often enough, the vector will get assigned to
another interrupt. This happens more often with MSI interrupts as those
are exclusively using a vector.

Fix this by setting the bit for the FIRST_DEVICE_VECTOR in the bitmap.

Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/io_apic_32.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/arch/x86/kernel/io_apic_32.c
+++ b/arch/x86/kernel/io_apic_32.c
@@ -2305,6 +2305,9 @@ void __init setup_IO_APIC(void)
 	for (i = FIRST_SYSTEM_VECTOR; i < NR_VECTORS; i++)
 		set_bit(i, used_vectors);
 
+	/* Mark FIRST_DEVICE_VECTOR which is assigned to IRQ0 as used. */
+	set_bit(FIRST_DEVICE_VECTOR, used_vectors);
+
 	enable_IO_APIC();
 
 	if (acpi_ioapic)

-- 

[patch 02/14] x86: improve UP kernel when CPU-hotplug and SMP is enabled

[Greg KH]

[-- Attachment #1: x86-improve-up-kernel-when-cpu-hotplug-and-smp-is-enabled.patch --]
[-- Type: text/plain, Size: 1079 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Thomas Gleixner <tglx@linutronix.de>

commit 649c6653fa94ec8f3ea32b19c97b790ec4e8e4ac upstream

num_possible_cpus() can be > 1 when disabled CPUs have been accounted.

Disabled CPUs are not in the cpu_present_map, so we can use
num_present_cpus() as a safe indicator to switch to UP alternatives.

Reported-by: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/alternative.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -457,7 +457,7 @@ void __init alternative_instructions(voi
 					    _text, _etext);
 
 		/* Only switch to UP mode if we don't immediately boot others */
-		if (num_possible_cpus() == 1 || setup_max_cpus <= 1)
+		if (num_present_cpus() == 1 || setup_max_cpus <= 1)
 			alternatives_smp_switch(0);
 	}
 #endif

-- 

[patch 03/14] x86, early_ioremap: fix fencepost error

[Greg KH]

[-- Attachment #1: x86-early_ioremap-fix-fencepost-error.patch --]
[-- Type: text/plain, Size: 1223 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Alan Cox <alan@redhat.com>

commit c613ec1a7ff3714da11c7c48a13bab03beb5c376 upstream

The x86 implementation of early_ioremap has an off by one error. If we get
an object which ends on the first byte of a page we undermap by one page and
this causes a crash on boot with the ASUS P5QL whose DMI table happens to fit
this alignment.

The size computation is currently

	last_addr = phys_addr + size - 1;
	npages = (PAGE_ALIGN(last_addr) - phys_addr)

(Consider a request for 1 byte at alignment 0...)

Closes #11693

Debugging work by Ian Campbell/Felix Geyer

Signed-off-by: Alan Cox <alan@rehat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/mm/ioremap.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -438,7 +438,7 @@ void __init *early_ioremap(unsigned long
 	 */
 	offset = phys_addr & ~PAGE_MASK;
 	phys_addr &= PAGE_MASK;
-	size = PAGE_ALIGN(last_addr) - phys_addr;
+	size = PAGE_ALIGN(last_addr + 1) - phys_addr;
 
 	/*
 	 * Mappings have to fit in the FIX_BTMAP area.

-- 

[patch 04/14] tty: Termios locking - sort out real_tty confusions and lock reads

[Greg KH]

[-- Attachment #1: tty-termios-locking-sort-out-real_tty-confusions-and-lock-reads.patch --]
[-- Type: text/plain, Size: 904 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Alan Cox <alan@redhat.com>

commit 8f520021837d45c47d0ab57e7271f8d88bf7f3a4 upstream

(only the tty_io.c portion of this commit)

This moves us towards sanity and should mean our termios locking is now
complete and comprehensive.

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/tty_io.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -3373,7 +3373,7 @@ int tty_ioctl(struct inode *inode, struc
 	case TIOCSTI:
 		return tiocsti(tty, p);
 	case TIOCGWINSZ:
-		return tiocgwinsz(tty, p);
+		return tiocgwinsz(real_tty, p);
 	case TIOCSWINSZ:
 		return tiocswinsz(tty, real_tty, p);
 	case TIOCCONS:

-- 

[patch 05/14] sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq

[Greg KH]

[-- Attachment #1: sched_rt.c-resch-needed-in-rt_rq_enqueue-for-the-root-rt_rq.patch --]
[-- Type: text/plain, Size: 2358 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Dario Faggioli <raistlin@linux.it>

commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream

While working on the new version of the code for SCHED_SPORADIC I
noticed something strange in the present throttling mechanism. More
specifically in the throttling timer handler in sched_rt.c
(do_sched_rt_period_timer()) and in rt_rq_enqueue().

The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
asks for rescheduling if the runqueue has a sched_entity associated to
it (i.e., rt_rq->rt_se != NULL).
Now, if the runqueue is the root rq (which has a rt_se = NULL)
rescheduling does not take place, and it is delayed to some undefined
instant in the future.

This imply some random bandwidth usage by the RT tasks under throttling.
For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
task will get less than 95%. In our tests we got something varying
between 70% to 95%.
Using smaller time values, e.g., 95ms/100ms, things are even worse, and
I can see values also going down to 20-25%!!

The tests we performed are simply running 'yes' as a SCHED_FIFO task,
and checking the CPU usage with top, but we can investigate thoroughly
if you think it is needed.

Things go much better, for us, with the attached patch... Don't know if
it is the best approach, but it solved the issue for us.

Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Michael Trimarchi <trimarchimichael@yahoo.it>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/sched_rt.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -91,12 +91,12 @@ static void dequeue_rt_entity(struct sch
 
 static void sched_rt_rq_enqueue(struct rt_rq *rt_rq)
 {
+	struct task_struct *curr = rq_of_rt_rq(rt_rq)->curr;
 	struct sched_rt_entity *rt_se = rt_rq->rt_se;
 
-	if (rt_se && !on_rt_rq(rt_se) && rt_rq->rt_nr_running) {
-		struct task_struct *curr = rq_of_rt_rq(rt_rq)->curr;
-
-		enqueue_rt_entity(rt_se);
+	if (rt_rq->rt_nr_running) {
+		if (rt_se && !on_rt_rq(rt_se))
+			enqueue_rt_entity(rt_se);
 		if (rt_rq->highest_prio < curr->prio)
 			resched_task(curr);
 	}

-- 

[patch 06/14] CIFS: make sure we have the right resume info before calling CIFSFindNext

[Greg KH]

[-- Attachment #1: cifs-make-sure-we-have-the-right-resume-info-before-calling-cifsfindnext.patch --]
[-- Type: text/plain, Size: 7831 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Steve French <sfrench@us.ibm.com>

commit 0752f1522a9120f731232919f7ad904e9e22b8ce upstream

When we do a seekdir() or equivalent, we usually end up doing a
FindFirst call and then call FindNext until we get to the offset that we
want. The problem is that when we call FindNext, the code usually
doesn't have the proper info (mostly, the filename of the entry from the
last search) to resume the search.

Add a "last_entry" field to the cifs_search_info that points to the last
entry in the search. We calculate this pointer by using the
LastNameOffset field from the search parms that are returned. We then
use that info to do a cifs_save_resume_key before we call CIFSFindNext.

This patch allows CIFS to reliably pass the "telldir" connectathon test.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/cifs/cifsglob.h |    1 
 fs/cifs/cifssmb.c  |    4 +
 fs/cifs/readdir.c  |  128 ++++++++++++++++++++++++++---------------------------
 3 files changed, 70 insertions(+), 63 deletions(-)

--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -315,6 +315,7 @@ struct cifs_search_info {
 	__u32 resume_key;
 	char *ntwrk_buf_start;
 	char *srch_entries_start;
+	char *last_entry;
 	char *presume_name;
 	unsigned int resume_name_len;
 	unsigned endOfSearch:1;
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -3598,6 +3598,8 @@ findFirstRetry:
 					le16_to_cpu(parms->SearchCount);
 			psrch_inf->index_of_last_entry = 2 /* skip . and .. */ +
 				psrch_inf->entries_in_buffer;
+			psrch_inf->last_entry = psrch_inf->srch_entries_start +
+					le16_to_cpu(parms->LastNameOffset);
 			*pnetfid = parms->SearchHandle;
 		} else {
 			cifs_buf_release(pSMB);
@@ -3712,6 +3714,8 @@ int CIFSFindNext(const int xid, struct c
 						le16_to_cpu(parms->SearchCount);
 			psrch_inf->index_of_last_entry +=
 				psrch_inf->entries_in_buffer;
+			psrch_inf->last_entry = psrch_inf->srch_entries_start +
+					le16_to_cpu(parms->LastNameOffset);
 /*  cFYI(1,("fnxt2 entries in buf %d index_of_last %d",
 	    psrch_inf->entries_in_buffer, psrch_inf->index_of_last_entry)); */
 
--- a/fs/cifs/readdir.c
+++ b/fs/cifs/readdir.c
@@ -633,6 +633,70 @@ static int is_dir_changed(struct file *f
 
 }
 
+static int cifs_save_resume_key(const char *current_entry,
+	struct cifsFileInfo *cifsFile)
+{
+	int rc = 0;
+	unsigned int len = 0;
+	__u16 level;
+	char *filename;
+
+	if ((cifsFile == NULL) || (current_entry == NULL))
+		return -EINVAL;
+
+	level = cifsFile->srch_inf.info_level;
+
+	if (level == SMB_FIND_FILE_UNIX) {
+		FILE_UNIX_INFO *pFindData = (FILE_UNIX_INFO *)current_entry;
+
+		filename = &pFindData->FileName[0];
+		if (cifsFile->srch_inf.unicode) {
+			len = cifs_unicode_bytelen(filename);
+		} else {
+			/* BB should we make this strnlen of PATH_MAX? */
+			len = strnlen(filename, PATH_MAX);
+		}
+		cifsFile->srch_inf.resume_key = pFindData->ResumeKey;
+	} else if (level == SMB_FIND_FILE_DIRECTORY_INFO) {
+		FILE_DIRECTORY_INFO *pFindData =
+			(FILE_DIRECTORY_INFO *)current_entry;
+		filename = &pFindData->FileName[0];
+		len = le32_to_cpu(pFindData->FileNameLength);
+		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
+	} else if (level == SMB_FIND_FILE_FULL_DIRECTORY_INFO) {
+		FILE_FULL_DIRECTORY_INFO *pFindData =
+			(FILE_FULL_DIRECTORY_INFO *)current_entry;
+		filename = &pFindData->FileName[0];
+		len = le32_to_cpu(pFindData->FileNameLength);
+		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
+	} else if (level == SMB_FIND_FILE_ID_FULL_DIR_INFO) {
+		SEARCH_ID_FULL_DIR_INFO *pFindData =
+			(SEARCH_ID_FULL_DIR_INFO *)current_entry;
+		filename = &pFindData->FileName[0];
+		len = le32_to_cpu(pFindData->FileNameLength);
+		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
+	} else if (level == SMB_FIND_FILE_BOTH_DIRECTORY_INFO) {
+		FILE_BOTH_DIRECTORY_INFO *pFindData =
+			(FILE_BOTH_DIRECTORY_INFO *)current_entry;
+		filename = &pFindData->FileName[0];
+		len = le32_to_cpu(pFindData->FileNameLength);
+		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
+	} else if (level == SMB_FIND_FILE_INFO_STANDARD) {
+		FIND_FILE_STANDARD_INFO *pFindData =
+			(FIND_FILE_STANDARD_INFO *)current_entry;
+		filename = &pFindData->FileName[0];
+		/* one byte length, no name conversion */
+		len = (unsigned int)pFindData->FileNameLength;
+		cifsFile->srch_inf.resume_key = pFindData->ResumeKey;
+	} else {
+		cFYI(1, ("Unknown findfirst level %d", level));
+		return -EINVAL;
+	}
+	cifsFile->srch_inf.resume_name_len = len;
+	cifsFile->srch_inf.presume_name = filename;
+	return rc;
+}
+
 /* find the corresponding entry in the search */
 /* Note that the SMB server returns search entries for . and .. which
    complicates logic here if we choose to parse for them and we do not
@@ -694,6 +758,7 @@ static int find_cifs_entry(const int xid
 	while ((index_to_find >= cifsFile->srch_inf.index_of_last_entry) &&
 	      (rc == 0) && (cifsFile->srch_inf.endOfSearch == FALSE)) {
 		cFYI(1, ("calling findnext2"));
+		cifs_save_resume_key(cifsFile->srch_inf.last_entry, cifsFile);
 		rc = CIFSFindNext(xid, pTcon, cifsFile->netfid,
 				  &cifsFile->srch_inf);
 		if (rc)
@@ -910,69 +975,6 @@ static int cifs_filldir(char *pfindEntry
 	return rc;
 }
 
-static int cifs_save_resume_key(const char *current_entry,
-	struct cifsFileInfo *cifsFile)
-{
-	int rc = 0;
-	unsigned int len = 0;
-	__u16 level;
-	char *filename;
-
-	if ((cifsFile == NULL) || (current_entry == NULL))
-		return -EINVAL;
-
-	level = cifsFile->srch_inf.info_level;
-
-	if (level == SMB_FIND_FILE_UNIX) {
-		FILE_UNIX_INFO *pFindData = (FILE_UNIX_INFO *)current_entry;
-
-		filename = &pFindData->FileName[0];
-		if (cifsFile->srch_inf.unicode) {
-			len = cifs_unicode_bytelen(filename);
-		} else {
-			/* BB should we make this strnlen of PATH_MAX? */
-			len = strnlen(filename, PATH_MAX);
-		}
-		cifsFile->srch_inf.resume_key = pFindData->ResumeKey;
-	} else if (level == SMB_FIND_FILE_DIRECTORY_INFO) {
-		FILE_DIRECTORY_INFO *pFindData =
-			(FILE_DIRECTORY_INFO *)current_entry;
-		filename = &pFindData->FileName[0];
-		len = le32_to_cpu(pFindData->FileNameLength);
-		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
-	} else if (level == SMB_FIND_FILE_FULL_DIRECTORY_INFO) {
-		FILE_FULL_DIRECTORY_INFO *pFindData =
-			(FILE_FULL_DIRECTORY_INFO *)current_entry;
-		filename = &pFindData->FileName[0];
-		len = le32_to_cpu(pFindData->FileNameLength);
-		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
-	} else if (level == SMB_FIND_FILE_ID_FULL_DIR_INFO) {
-		SEARCH_ID_FULL_DIR_INFO *pFindData =
-			(SEARCH_ID_FULL_DIR_INFO *)current_entry;
-		filename = &pFindData->FileName[0];
-		len = le32_to_cpu(pFindData->FileNameLength);
-		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
-	} else if (level == SMB_FIND_FILE_BOTH_DIRECTORY_INFO) {
-		FILE_BOTH_DIRECTORY_INFO *pFindData =
-			(FILE_BOTH_DIRECTORY_INFO *)current_entry;
-		filename = &pFindData->FileName[0];
-		len = le32_to_cpu(pFindData->FileNameLength);
-		cifsFile->srch_inf.resume_key = pFindData->FileIndex;
-	} else if (level == SMB_FIND_FILE_INFO_STANDARD) {
-		FIND_FILE_STANDARD_INFO *pFindData =
-			(FIND_FILE_STANDARD_INFO *)current_entry;
-		filename = &pFindData->FileName[0];
-		/* one byte length, no name conversion */
-		len = (unsigned int)pFindData->FileNameLength;
-		cifsFile->srch_inf.resume_key = pFindData->ResumeKey;
-	} else {
-		cFYI(1, ("Unknown findfirst level %d", level));
-		return -EINVAL;
-	}
-	cifsFile->srch_inf.resume_name_len = len;
-	cifsFile->srch_inf.presume_name = filename;
-	return rc;
-}
 
 int cifs_readdir(struct file *file, void *direntry, filldir_t filldir)
 {

-- 

[patch 07/14] b43legacy: Fix failure in rate-adjustment mechanism

[Greg KH]

[-- Attachment #1: b43legacy-fix-failure-in-rate-adjustment-mechanism.patch --]
[-- Type: text/plain, Size: 1197 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Larry Finger <Larry.Finger@lwfinger.net>

commit c6a2afdacccd56cc0be8e9a7977f0ed1509069f6 upstream
Date: Sat, 6 Sep 2008 16:51:22 -0500
Subject: [patch 07/14] b43legacy: Fix failure in rate-adjustment mechanism

A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using the rate-setting mechanism
of mac80211. The driver has been forced to remain at a 1 Mb/s rate.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/b43legacy/xmit.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/b43legacy/xmit.c
+++ b/drivers/net/wireless/b43legacy/xmit.c
@@ -624,7 +624,7 @@ void b43legacy_handle_hwtxstatus(struct 
 	tmp = hw->count;
 	status.frame_count = (tmp >> 4);
 	status.rts_count = (tmp & 0x0F);
-	tmp = hw->flags;
+	tmp = hw->flags << 1;
 	status.supp_reason = ((tmp & 0x1C) >> 2);
 	status.pm_indicated = !!(tmp & 0x80);
 	status.intermediate = !!(tmp & 0x40);

-- 

[patch 08/14] fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles

[Greg KH]

[-- Attachment #1: fbcon_set_all_vcs-fix-kernel-crash-when-switching-the-rotated-consoles.patch --]
[-- Type: text/plain, Size: 4013 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Oleg Nesterov <oleg@tv-sign.ru>

commit 232fb69a53a5ec3f22a8104d447abe4806848a8f upstream

echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another
console. Result:

	BUG: unable to handle kernel paging request at ffffc20005d00000
	IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
	PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0
	Oops: 0002 [1] SMP
	CPU 1
	Modules linked in: [...a lot...]
	Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1
	RIP: 0010:[bitfill_aligned+149/265]  [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
	RSP: 0018:ffff81007d811bc8  EFLAGS: 00010216
	RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400
	RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff
	RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040
	R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000
	R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400
	FS:  0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000
	CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
	CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0
	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
	Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000)
	Stack:  ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80
	 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000
	 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000
	Call Trace:
	 [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e
	 [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4
	 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107
	 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d
	 [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba
	 [redraw_screen+261/481] redraw_screen+0x105/0x1e1
	 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d
	 [complete_change_console+48/190] complete_change_console+0x30/0xbe
	 [change_console+115/120] change_console+0x73/0x78
	 [console_callback+0/292] ? console_callback+0x0/0x124
	 [console_callback+97/292] console_callback+0x61/0x124
	 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e
	 [run_workqueue+139/282] run_workqueue+0x8b/0x11a
	 [worker_thread+221/238] worker_thread+0xdd/0xee
	 [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38
	 [worker_thread+0/238] ? worker_thread+0x0/0xee
	 [kthread+73/118] kthread+0x49/0x76
	 [child_rip+10/18] child_rip+0xa/0x12
	 [kthread+0/118] ? kthread+0x0/0x76
	 [child_rip+0/18] ? child_rip+0x0/0x12

Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead
of fbcon_ops->rotate, and vc_resize() has no effect because it is called with
new_cols/rows == ->vc_cols/rows.

Tested on 2.6.26.5-45.fc9.x86_64, but
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to
have the same problem.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/console/fbcon.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -2974,8 +2974,8 @@ static void fbcon_set_all_vcs(struct fb_
 		p = &fb_display[vc->vc_num];
 		set_blitting_type(vc, info);
 		var_to_display(p, &info->var, info);
-		cols = FBCON_SWAP(p->rotate, info->var.xres, info->var.yres);
-		rows = FBCON_SWAP(p->rotate, info->var.yres, info->var.xres);
+		cols = FBCON_SWAP(ops->rotate, info->var.xres, info->var.yres);
+		rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
 		cols /= vc->vc_font.width;
 		rows /= vc->vc_font.height;
 		vc_resize(vc, cols, rows);

-- 

[patch 09/14] hwmon: (it87) Prevent power-off on Shuttle SN68PT

[Greg KH]

[-- Attachment #1: hwmon-prevent-power-off-on-shuttle-sn68pt.patch --]
[-- Type: text/plain, Size: 3631 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Jean Delvare <khali@linux-fr.org>

based on commit 98dd22c3e086d76058083432d4d8fb85f04bab90 upstream

On the Shuttle SN68PT, FAN_CTL2 is apparently not connected to a fan,
but to something else. One user has reported instant system power-off
when changing the PWM2 duty cycle, so we disable it.

I use the board name string as the trigger in case the same board is
ever used in other systems.

This closes lm-sensors ticket #2349:
pwmconfig causes a hard poweroff
http://www.lm-sensors.org/ticket/2349

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/hwmon/it87.c |   39 +++++++++++++++++++++++++++++++++------
 1 file changed, 33 insertions(+), 6 deletions(-)

--- a/drivers/hwmon/it87.c
+++ b/drivers/hwmon/it87.c
@@ -46,6 +46,8 @@
 #include <linux/err.h>
 #include <linux/mutex.h>
 #include <linux/sysfs.h>
+#include <linux/string.h>
+#include <linux/dmi.h>
 #include <asm/io.h>
 
 #define DRVNAME "it87"
@@ -235,6 +237,8 @@ struct it87_sio_data {
 	enum chips type;
 	/* Values read from Super-I/O config space */
 	u8 vid_value;
+	/* Values set based on DMI strings */
+	u8 skip_pwm;
 };
 
 /* For each registered chip, we need to keep some data in memory.
@@ -952,6 +956,7 @@ static int __init it87_find(unsigned sho
 {
 	int err = -ENODEV;
 	u16 chip_type;
+	const char *board_vendor, *board_name;
 
 	superio_enter();
 	chip_type = force_id ? force_id : superio_inw(DEVID);
@@ -1009,6 +1014,25 @@ static int __init it87_find(unsigned sho
 			pr_info("it87: in7 is VCCH (+5V Stand-By)\n");
 	}
 
+	sio_data->skip_pwm = 0;
+	/* Disable specific features based on DMI strings */
+	board_vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
+	board_name = dmi_get_system_info(DMI_BOARD_NAME);
+	if (board_vendor && board_name) {
+		if (strcmp(board_vendor, "nVIDIA") == 0
+		 && strcmp(board_name, "FN68PT") == 0) {
+			/* On the Shuttle SN68PT, FAN_CTL2 is apparently not
+			   connected to a fan, but to something else. One user
+			   has reported instant system power-off when changing
+			   the PWM2 duty cycle, so we disable it.
+			   I use the board name string as the trigger in case
+			   the same board is ever used in other systems. */
+			pr_info("it87: Disabling pwm2 due to "
+				"hardware constraints\n");
+			sio_data->skip_pwm = (1 << 1);
+		}
+	}
+
 exit:
 	superio_exit();
 	return err;
@@ -1157,22 +1181,25 @@ static int __devinit it87_probe(struct p
 		if ((err = device_create_file(dev,
 		     &sensor_dev_attr_pwm1_enable.dev_attr))
 		 || (err = device_create_file(dev,
-		     &sensor_dev_attr_pwm2_enable.dev_attr))
-		 || (err = device_create_file(dev,
 		     &sensor_dev_attr_pwm3_enable.dev_attr))
 		 || (err = device_create_file(dev,
 		     &sensor_dev_attr_pwm1.dev_attr))
 		 || (err = device_create_file(dev,
-		     &sensor_dev_attr_pwm2.dev_attr))
-		 || (err = device_create_file(dev,
 		     &sensor_dev_attr_pwm3.dev_attr))
 		 || (err = device_create_file(dev,
 		     &dev_attr_pwm1_freq))
 		 || (err = device_create_file(dev,
-		     &dev_attr_pwm2_freq))
-		 || (err = device_create_file(dev,
 		     &dev_attr_pwm3_freq)))
 			goto ERROR4;
+		if (!(sio_data->skip_pwm & (1 << 1))) {
+			if ((err = device_create_file(dev,
+			     &sensor_dev_attr_pwm2_enable.dev_attr))
+			 || (err = device_create_file(dev,
+			     &sensor_dev_attr_pwm2.dev_attr))
+			 || (err = device_create_file(dev,
+			     &dev_attr_pwm2_freq)))
+				goto ERROR4;
+		}
 	}
 
 	if (data->type == it8712 || data->type == it8716

-- 

[patch 10/14] Dont allow splice() to files opened with O_APPEND

[Greg KH]

[-- Attachment #1: don-t-allow-splice-to-files-opened-with-o_append.patch --]
[-- Type: text/plain, Size: 1535 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Linus Torvalds <torvalds@linux-foundation.org>

commit efc968d450e013049a662d22727cf132618dcb2f upstream

This is debatable, but while we're debating it, let's disallow the
combination of splice and an O_APPEND destination.

It's not entirely clear what the semantics of O_APPEND should be, and
POSIX apparently expects pwrite() to ignore O_APPEND, for example.  So
we could make up any semantics we want, including the old ones.

But Miklos convinced me that we should at least give it some thought,
and that accepting writes at arbitrary offsets is wrong at least for
IS_APPEND() files (which always have O_APPEND set, even if the reverse
isn't true: you can obviously have O_APPEND set on a regular file).

So disallow O_APPEND entirely for now.  I doubt anybody cares, and this
way we have one less gray area to worry about.

Reported-and-argued-for-by: Miklos Szeredi <miklos@szeredi.hu>
Acked-by: Jens Axboe <ens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/splice.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/fs/splice.c
+++ b/fs/splice.c
@@ -891,6 +891,9 @@ static long do_splice_from(struct pipe_i
 	if (unlikely(!(out->f_mode & FMODE_WRITE)))
 		return -EBADF;
 
+	if (unlikely(out->f_flags & O_APPEND))
+		return -EINVAL;
+
 	ret = rw_verify_area(WRITE, out, ppos, len);
 	if (unlikely(ret < 0))
 		return ret;

-- 

[patch 11/14] V4L: bttv: Prevent NULL pointer dereference in radio_open

[Greg KH]

[-- Attachment #1: v4l-bttv-prevent-null-pointer-dereference-in-radio_open.patch --]
[-- Type: text/plain, Size: 1500 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Jean Delvare <khali@linux-fr.org>

cherry picked from commit c37396c19403e249f12626187d51e92c915f2bc9

Fix the following crash in the bttv driver:

BUG: unable to handle kernel NULL pointer dereference at 000000000000036c
IP: [<ffffffffa037860a>] radio_open+0x3a/0x170 [bttv]

This happens because radio_open assumes that all present bttv devices
have a radio function. If a bttv device without radio and one with
radio are installed on the same system, and the one without radio is
registered first, then radio_open checks for the radio device number
of a bttv device that has no radio function, and this breaks. All we
have to do to fix it is to skip bttv devices without a radio function.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/bt8xx/bttv-driver.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -3422,7 +3422,7 @@ static int radio_open(struct inode *inod
 	dprintk("bttv: open minor=%d\n",minor);
 
 	for (i = 0; i < bttv_num; i++) {
-		if (bttvs[i].radio_dev->minor == minor) {
+		if (bttvs[i].radio_dev && bttvs[i].radio_dev->minor == minor) {
 			btv = &bttvs[i];
 			break;
 		}

-- 

[patch 12/14] V4L: zr36067: Fix RGBR pixel format

[Greg KH]

[-- Attachment #1: v4l-zr36067-fix-rgbr-pixel-format.patch --]
[-- Type: text/plain, Size: 1143 bytes --]


2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Jean Delvare <khali@linux-fr.org>

(cherry picked from commit a30ee3c747728f9151664118ffcbdeefd202c332)

The zr36067 driver is improperly declaring pixel format RGBP twice,
once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
actually RGBR. Fix the code to properly map both pixel formats.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/zoran_driver.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/media/video/zoran_driver.c
+++ b/drivers/media/video/zoran_driver.c
@@ -139,7 +139,7 @@ const struct zoran_format zoran_formats[
 	}, {
 		.name = "16-bit RGB BE",
 		ZFMT(-1,
-		     V4L2_PIX_FMT_RGB565, V4L2_COLORSPACE_SRGB),
+		     V4L2_PIX_FMT_RGB565X, V4L2_COLORSPACE_SRGB),
 		.depth = 16,
 		.flags = ZORAN_FORMAT_CAPTURE |
 			 ZORAN_FORMAT_OVERLAY,

-- 

[patch 13/14] drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)

[Greg KH]

[-- Attachment #1: drm-i915-fix-ioremap-of-a-user-address-for-non-root.patch --]
[-- Type: text/plain, Size: 1460 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Matthias Hopf <mhopf@suse.de>

commit 4b40893918203ee1a1f6a114316c2a19c072e9bd upstream

Olaf Kirch noticed that the i915_set_status_page() function of the i915
kernel driver calls ioremap with an address offset that is supplied by
userspace via ioctl. The function zeroes the mapped memory via memset
and tells the hardware about the address. Turns out that access to that
ioctl is not restricted to root so users could probably exploit that to
do nasty things. We haven't tried to write actual exploit code though.

It only affects the Intel G33 series and newer.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/drm/i915_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/char/drm/i915_dma.c
+++ b/drivers/char/drm/i915_dma.c
@@ -836,7 +836,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
 	DRM_IOCTL_DEF(DRM_I915_SET_VBLANK_PIPE,  i915_vblank_pipe_set, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY ),
 	DRM_IOCTL_DEF(DRM_I915_GET_VBLANK_PIPE,  i915_vblank_pipe_get, DRM_AUTH ),
 	DRM_IOCTL_DEF(DRM_I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
-	DRM_IOCTL_DEF(DRM_I915_HWS_ADDR, i915_set_status_page, DRM_AUTH),
+	DRM_IOCTL_DEF(DRM_I915_HWS_ADDR, i915_set_status_page, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
 };
 
 int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);

-- 

[patch 14/14] x86: work around MTRR mask setting, v2

[Greg KH]

[-- Attachment #1: x86-work-around-mtrr-mask-setting-v2.patch --]
[-- Type: text/plain, Size: 1074 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Ingo Molnar <mingo@elte.hu>

commit 9754a5b840a209bc1f192d59f63e81b698a55ac8 upstream

improve the debug printout:

- make it actually display something
- print it only once

would be nice to have a WARN_ONCE() facility, to feed such things to
kerneloops.org.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: S.Çağlar Onur <caglar@pardus.org.tr>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/cpu/mtrr/generic.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -251,7 +251,12 @@ static void generic_get_mtrr(unsigned in
 		tmp |= ~((1<<(hi - 1)) - 1);
 
 		if (tmp != mask_lo) {
-			WARN_ON("mtrr: your BIOS has set up an incorrect mask, fixing it up.\n");
+			static int once = 1;
+
+			if (once) {
+				printk(KERN_INFO "mtrr: your BIOS has set up an incorrect mask, fixing it up.\n");
+				once = 0;
+			}
 			mask_lo = tmp;
 		}
 	}

--