--- /dev/null
+From gregkh@mini.kroah.org Sat Oct 18 11:51:22 2008
+Message-Id: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:31 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk
+Subject: [patch 00/14] 2.6.25-stable review
+Content-Length: 1829
+Lines: 42
+
+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(-)
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:23 2008
+Message-Id: <20081018185122.956994355@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:32 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Stefan Bader <stefan.bader@canonical.com>,
+ Ingo Molnar <mingo@elte.hu>
+Subject: [patch 01/14] x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.
+Content-Disposition: inline; filename=x86-reserve-first_device_vector-in-used_vectors-bitmap.patch
+Content-Length: 1499
+Lines: 44
+
+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)
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:23 2008
+Message-Id: <20081018185123.112033823@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:33 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org,
+ jejb@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Thomas Gleixner <tglx@linutronix.de>,
+ Ingo Molnar <mingo@elte.hu>
+Subject: [patch 02/14] x86: improve UP kernel when CPU-hotplug and SMP is enabled
+Content-Disposition: inline; filename=x86-improve-up-kernel-when-cpu-hotplug-and-smp-is-enabled.patch
+Content-Length: 1079
+Lines: 35
+
+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
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:23 2008
+Message-Id: <20081018185123.288883744@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:34 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org,
+ jejb@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Alan Cox <alan@rehat.com>,
+ Ingo Molnar <mingo@elte.hu>
+Subject: [patch 03/14] x86, early_ioremap: fix fencepost error
+Content-Disposition: inline; filename=x86-early_ioremap-fix-fencepost-error.patch
+Content-Length: 1223
+Lines: 45
+
+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.
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:23 2008
+Message-Id: <20081018185123.522474187@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:35 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Alan Cox <alan@redhat.com>
+Subject: [patch 04/14] tty: Termios locking - sort out real_tty confusions and lock reads
+Content-Disposition: inline; filename=tty-termios-locking-sort-out-real_tty-confusions-and-lock-reads.patch
+Content-Length: 904
+Lines: 34
+
+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:
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:23 2008
+Message-Id: <20081018185123.698128006@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:36 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org,
+ jejb@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Dario Faggioli <raistlin@linux.it>,
+ Michael Trimarchi <trimarchimichael@yahoo.it>,
+ Peter Zijlstra <a.p.zijlstra@chello.nl>,
+ Ingo Molnar <mingo@elte.hu>
+Subject: [patch 05/14] sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
+Content-Disposition: inline; filename=sched_rt.c-resch-needed-in-rt_rq_enqueue-for-the-root-rt_rq.patch
+Content-Length: 2358
+Lines: 65
+
+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);
+ }
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:24 2008
+Message-Id: <20081018185123.906335474@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:37 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org,
+ jejb@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Jeff Layton <jlayton@redhat.com>,
+ Steve French <sfrench@us.ibm.com>
+Subject: [patch 06/14] CIFS: make sure we have the right resume info before calling CIFSFindNext
+Content-Disposition: inline; filename=cifs-make-sure-we-have-the-right-resume-info-before-calling-cifsfindnext.patch
+Content-Length: 7831
+Lines: 214
+
+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)
+ {
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:24 2008
+Message-Id: <20081018185124.155568406@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:38 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org,
+ jejb@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Larry Finger <Larry.Finger@lwfinger.net>,
+ "John W. Linville" <linville@tuxdriver.com>
+Subject: [patch 07/14] b43legacy: Fix failure in rate-adjustment mechanism
+Content-Disposition: inline; filename=b43legacy-fix-failure-in-rate-adjustment-mechanism.patch
+Content-Length: 1197
+Lines: 35
+
+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);
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:24 2008
+Message-Id: <20081018185124.387258118@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:39 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org,
+ jejb@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Oleg Nesterov <oleg@tv-sign.ru>,
+ Krzysztof Helt <krzysztof.h1@poczta.fm>
+Subject: [patch 08/14] fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles
+Content-Disposition: inline; filename=fbcon_set_all_vcs-fix-kernel-crash-when-switching-the-rotated-consoles.patch
+Content-Length: 4013
+Lines: 89
+
+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);
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:24 2008
+Message-Id: <20081018185124.664539798@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:40 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Jean Delvare <khali@linux-fr.org>
+Subject: [patch 09/14] hwmon: (it87) Prevent power-off on Shuttle SN68PT
+Content-Disposition: inline; filename=hwmon-prevent-power-off-on-shuttle-sn68pt.patch
+Content-Length: 3631
+Lines: 114
+
+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
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:25 2008
+Message-Id: <20081018185124.893378240@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:41 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Jens Axboe <ens.axboe@oracle.com>
+Subject: [patch 10/14] Dont allow splice() to files opened with O_APPEND
+Content-Disposition: inline; filename=don-t-allow-splice-to-files-opened-with-o_append.patch
+Content-Length: 1535
+Lines: 46
+
+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;
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:25 2008
+Message-Id: <20081018185125.056890293@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:42 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Jean Delvare <khali@linux-fr.org>,
+ v4l-dvb maintainer list <v4l-dvb-maintainer@linuxtv.org>,
+ Mauro Carvalho Chehab <mchehab@infradead.org>,
+ Mauro Carvalho Chehab <mchehab@redhat.com>
+Subject: [patch 11/14] V4L: bttv: Prevent NULL pointer dereference in radio_open
+Content-Disposition: inline; filename=v4l-bttv-prevent-null-pointer-dereference-in-radio_open.patch
+Content-Length: 1500
+Lines: 42
+
+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;
+ }
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:25 2008
+Message-Id: <20081018185125.279508531@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:43 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Jean Delvare <khali@linux-fr.org>,
+ v4l-dvb maintainer list <v4l-dvb-maintainer@linuxtv.org>,
+ Trent Piepho <xyzzy@speakeasy.org>,
+ Mauro Carvalho Chehab <mchehab@infradead.org>,
+ Mauro Carvalho Chehab <mchehab@redhat.com>
+Subject: [patch 12/14] V4L: zr36067: Fix RGBR pixel format
+Content-Disposition: inline; filename=v4l-zr36067-fix-rgbr-pixel-format.patch
+Content-Length: 1143
+Lines: 36
+
+
+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,
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:31 2008
+Message-Id: <20081018185131.194748666@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:44 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Dave Airlie <airlied@redhat.com>
+Subject: [patch 13/14] drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831)
+Content-Disposition: inline; filename=drm-i915-fix-ioremap-of-a-user-address-for-non-root.patch
+Content-Length: 1460
+Lines: 37
+
+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);
+
+--
+
+From gregkh@mini.kroah.org Sat Oct 18 11:51:31 2008
+Message-Id: <20081018185131.369077527@mini.kroah.org>
+References: <20081018185031.236868964@mini.kroah.org>
+User-Agent: quilt/0.46-1
+Date: Sat, 18 Oct 2008 11:50:45 -0700
+From: Greg KH <gregkh@suse.de>
+To: linux-kernel@vger.kernel.org,
+ stable@kernel.org
+Cc: Justin Forbes <jmforbes@linuxtx.org>,
+ Zwane Mwaikambo <zwane@arm.linux.org.uk>,
+ Theodore Ts'o <tytso@mit.edu>,
+ Randy Dunlap <rdunlap@xenotime.net>,
+ Dave Jones <davej@redhat.com>,
+ Chuck Wolber <chuckw@quantumlinux.com>,
+ Chris Wedgwood <reviews@ml.cw.f00f.org>,
+ Michael Krufky <mkrufky@linuxtv.org>,
+ Chuck Ebbert <cebbert@redhat.com>,
+ Domenico Andreoli <cavokz@gmail.com>,
+ Willy Tarreau <w@1wt.eu>,
+ Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
+ Jake Edge <jake@lwn.net>,
+ Eugene Teo <eteo@redhat.com>,
+ torvalds@linux-foundation.org,
+ akpm@linux-foundation.org,
+ alan@lxorguk.ukuu.org.uk,
+ Ingo Molnar <mingo@elte.hu>,
+ =?ISO-8859-15?q?S.=C3=87a=C4=9Flar=20Onur?= <caglar@pardus.org.tr>
+Subject: [patch 14/14] x86: work around MTRR mask setting, v2
+Content-Disposition: inline; filename=x86-work-around-mtrr-mask-setting-v2.patch
+Content-Length: 1074
+Lines: 42
+
+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;
+ }
+ }
+
+--
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
