--- /dev/null
+From jejb@kernel.org Wed Oct 15 14:35:35 2008
+From: Steve French <sfrench@us.ibm.com>
+Date: Sat, 11 Oct 2008 16:55:11 GMT
+Subject: CIFS: make sure we have the right resume info before calling CIFSFindNext
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200810111655.m9BGtBTL013214@hera.kernel.org>
+
+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
+@@ -309,6 +309,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;
+ bool endOfSearch:1;
+--- a/fs/cifs/cifssmb.c
++++ b/fs/cifs/cifssmb.c
+@@ -3636,6 +3636,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);
+@@ -3751,6 +3753,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
+@@ -640,6 +640,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
+@@ -703,6 +767,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) {
+ 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)
+@@ -919,69 +984,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)
+ {
--- /dev/null
+From 73f6aa4d44ab6157badc456ddfa05b31e58de5f0 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Fri, 10 Oct 2008 17:28:29 +1100
+Subject: Fix barrier fail detection in XFS
+
+From: Christoph Hellwig <hch@lst.de>
+
+commit 73f6aa4d44ab6157badc456ddfa05b31e58de5f0 upstream.
+
+Currently we disable barriers as soon as we get a buffer in xlog_iodone
+that has the XBF_ORDERED flag cleared. But this can be the case not only
+for buffers where the barrier failed, but also the first buffer of a
+split log write in case of a log wraparound. Due to the disabled
+barriers we can easily get directory corruption on unclean shutdowns.
+So instead of using this check add a new buffer flag for failed barrier
+writes.
+
+This is a regression vs 2.6.26 caused by patch to use the right macro
+to check for the ORDERED flag, as we previously got true returned for
+every buffer.
+
+Thanks to Toei Rei for reporting the bug.
+
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
+Reviewed-by: David Chinner <david@fromorbit.com>
+Signed-off-by: Tim Shimmin <tes@sgi.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/xfs/linux-2.6/xfs_buf.c | 3 ++-
+ fs/xfs/linux-2.6/xfs_buf.h | 8 ++++++++
+ fs/xfs/xfs_log.c | 7 ++++---
+ 3 files changed, 14 insertions(+), 4 deletions(-)
+
+--- a/fs/xfs/linux-2.6/xfs_buf.c
++++ b/fs/xfs/linux-2.6/xfs_buf.c
+@@ -1001,12 +1001,13 @@ xfs_buf_iodone_work(
+ * We can get an EOPNOTSUPP to ordered writes. Here we clear the
+ * ordered flag and reissue them. Because we can't tell the higher
+ * layers directly that they should not issue ordered I/O anymore, they
+- * need to check if the ordered flag was cleared during I/O completion.
++ * need to check if the _XFS_BARRIER_FAILED flag was set during I/O completion.
+ */
+ if ((bp->b_error == EOPNOTSUPP) &&
+ (bp->b_flags & (XBF_ORDERED|XBF_ASYNC)) == (XBF_ORDERED|XBF_ASYNC)) {
+ XB_TRACE(bp, "ordered_retry", bp->b_iodone);
+ bp->b_flags &= ~XBF_ORDERED;
++ bp->b_flags |= _XFS_BARRIER_FAILED;
+ xfs_buf_iorequest(bp);
+ } else if (bp->b_iodone)
+ (*(bp->b_iodone))(bp);
+--- a/fs/xfs/linux-2.6/xfs_buf.h
++++ b/fs/xfs/linux-2.6/xfs_buf.h
+@@ -85,6 +85,14 @@ typedef enum {
+ * modifications being lost.
+ */
+ _XBF_PAGE_LOCKED = (1 << 22),
++
++ /*
++ * If we try a barrier write, but it fails we have to communicate
++ * this to the upper layers. Unfortunately b_error gets overwritten
++ * when the buffer is re-issued so we have to add another flag to
++ * keep this information.
++ */
++ _XFS_BARRIER_FAILED = (1 << 23),
+ } xfs_buf_flags_t;
+
+ typedef enum {
+--- a/fs/xfs/xfs_log.c
++++ b/fs/xfs/xfs_log.c
+@@ -1033,11 +1033,12 @@ xlog_iodone(xfs_buf_t *bp)
+ l = iclog->ic_log;
+
+ /*
+- * If the ordered flag has been removed by a lower
+- * layer, it means the underlyin device no longer supports
++ * If the _XFS_BARRIER_FAILED flag was set by a lower
++ * layer, it means the underlying device no longer supports
+ * barrier I/O. Warn loudly and turn off barriers.
+ */
+- if ((l->l_mp->m_flags & XFS_MOUNT_BARRIER) && !XFS_BUF_ISORDERED(bp)) {
++ if (bp->b_flags & _XFS_BARRIER_FAILED) {
++ bp->b_flags &= ~_XFS_BARRIER_FAILED;
+ l->l_mp->m_flags &= ~XFS_MOUNT_BARRIER;
+ xfs_fs_cmn_err(CE_WARN, l->l_mp,
+ "xlog_iodone: Barriers are no longer supported"
--- /dev/null
+From johannes@sipsolutions.net Wed Oct 15 14:25:41 2008
+From: Johannes Berg <johannes@sipsolutions.net>
+Date: Fri, 10 Oct 2008 17:52:49 +0200
+Subject: mac80211: fix two issues in debugfs
+To: stable <stable@kernel.org>
+Cc: linux-wireless <linux-wireless@vger.kernel.org>, John Linville <linville@tuxdriver.com>
+Message-ID: <1223653970.3748.23.camel@johannes.berg>
+
+From: Johannes Berg <johannes@sipsolutions.net>
+
+Not in trees above 2.6.27 as it is fixed differently in .28.
+
+This fixes RHBZ 466264, whenever the master interface is
+renamed this code would BUG_ON. Also fixes a separately
+reported bug with the debugfs dir being NULL.
+
+This patch is not applicable to the next kernel version
+because both these issues have been fixed, the first one
+by not having the master interface have a ieee80211_ptr
+at all, and the second one by also leaving the function
+early.
+
+Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
+Cc: John Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/mac80211/debugfs_netdev.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/net/mac80211/debugfs_netdev.c
++++ b/net/mac80211/debugfs_netdev.c
+@@ -537,6 +537,7 @@ static int netdev_notify(struct notifier
+ {
+ struct net_device *dev = ndev;
+ struct dentry *dir;
++ struct ieee80211_local *local;
+ struct ieee80211_sub_if_data *sdata;
+ char buf[10+IFNAMSIZ];
+
+@@ -549,10 +550,19 @@ static int netdev_notify(struct notifier
+ if (dev->ieee80211_ptr->wiphy->privid != mac80211_wiphy_privid)
+ return 0;
+
+- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
++ /*
++ * Do not use IEEE80211_DEV_TO_SUB_IF because that
++ * BUG_ONs for the master netdev which we need to
++ * handle here.
++ */
++ sdata = netdev_priv(dev);
+
+- sprintf(buf, "netdev:%s", dev->name);
+ dir = sdata->debugfsdir;
++
++ if (!dir)
++ return 0;
++
++ sprintf(buf, "netdev:%s", dev->name);
+ if (!debugfs_rename(dir->d_parent, dir, dir->d_parent, buf))
+ printk(KERN_ERR "mac80211: debugfs: failed to rename debugfs "
+ "dir to %s\n", buf);
--- /dev/null
+From jejb@kernel.org Wed Oct 15 14:36:09 2008
+From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
+Date: Sat, 11 Oct 2008 16:55:13 GMT
+Subject: rfkill: update LEDs for all state changes
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200810111655.m9BGtDQf013236@hera.kernel.org>
+
+From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
+
+commit 417bd25ac4c6f76c8aafe8a584f3620f4a936b72 upstream
+
+The LED state was not being updated by rfkill_force_state(), which
+will cause regressions in wireless drivers that had old-style rfkill
+support and are updated to use rfkill_force_state().
+
+The LED state was not being updated when a change was detected through
+the rfkill->get_state() hook, either.
+
+Move the LED trigger update calls into notify_rfkill_state_change(),
+where it should have been in the first place. This takes care of both
+issues above.
+
+Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
+Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/rfkill/rfkill.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/net/rfkill/rfkill.c
++++ b/net/rfkill/rfkill.c
+@@ -117,6 +117,7 @@ static void rfkill_led_trigger_activate(
+
+ static void notify_rfkill_state_change(struct rfkill *rfkill)
+ {
++ rfkill_led_trigger(rfkill, rfkill->state);
+ blocking_notifier_call_chain(&rfkill_notifier_list,
+ RFKILL_STATE_CHANGED,
+ rfkill);
+@@ -204,10 +205,8 @@ static int rfkill_toggle_radio(struct rf
+ rfkill->state = state;
+ }
+
+- if (force || rfkill->state != oldstate) {
+- rfkill_led_trigger(rfkill, rfkill->state);
++ if (force || rfkill->state != oldstate)
+ notify_rfkill_state_change(rfkill);
+- }
+
+ return retval;
+ }
--- /dev/null
+From jejb@kernel.org Wed Oct 15 14:19:33 2008
+From: Dario Faggioli <raistlin@linux.it>
+Date: Fri, 10 Oct 2008 20:15:02 GMT
+Subject: sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
+To: jejb@kernel.org, stable@kernel.org
+Message-ID: <200810102015.m9AKF27B014753@hera.kernel.org>
+
+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
+@@ -102,12 +102,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);
+ }
--- /dev/null
+sched_rt.c-resch-needed-in-rt_rq_enqueue-for-the-root-rt_rq.patch
+x86-reserve-first_device_vector-in-used_vectors-bitmap.patch
+mac80211-fix-two-issues-in-debugfs.patch
+fix-barrier-fail-detection-in-xfs.patch
+tty-termios-locking-sort-out-real_tty-confusions-and-lock-reads.patch
+cifs-make-sure-we-have-the-right-resume-info-before-calling-cifsfindnext.patch
+rfkill-update-leds-for-all-state-changes.patch
--- /dev/null
+From 8f520021837d45c47d0ab57e7271f8d88bf7f3a4 Mon Sep 17 00:00:00 2001
+From: Alan Cox <alan@redhat.com>
+Date: Mon, 13 Oct 2008 10:38:46 +0100
+Subject: tty: Termios locking - sort out real_tty confusions and lock reads
+
+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
+@@ -2996,7 +2996,7 @@ long tty_ioctl(struct file *file, unsign
+ 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:
--- /dev/null
+From a272a28f520c58a84853e098b4ee565486ca5062 Mon Sep 17 00:00:00 2001
+From: Stefan Bader <stefan.bader@canonical.com>
+Date: Sat, 27 Sep 2008 11:07:30 -0400
+Subject: x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap.
+
+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
+@@ -2314,6 +2314,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();
+
+ io_apic_irqs = ~PIC_IRQS;
projects / thirdparty / kernel / stable-queue.git / commitdiff
