--- /dev/null
+From stable-bounces@linux.kernel.org Wed Oct 10 06:19:13 2007
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 10 Oct 2007 15:18:45 +0200
+Subject: ALSA: emu10k1 - Fix memory corruption
+To: stable@kernel.org
+Message-ID: <s5hsl4jqf9m.wl%tiwai@suse.de>
+
+From: Takashi Iwai <tiwai@suse.de>
+
+patch 7583cb51a1e276591f57a2fae05489c878f8ef54 from mainline.
+
+[ALSA] emu10k1 - Fix memory corruption
+
+The number of mixer elements for SPDIF control don't match with the
+actual array size (3). This may result in a memory corruption that
+overwrites the i2c_capture_source field (ALSA bug#3095).
+
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/pci/emu10k1/emumixer.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/pci/emu10k1/emumixer.c
++++ b/sound/pci/emu10k1/emumixer.c
+@@ -871,7 +871,7 @@ static struct snd_kcontrol_new snd_emu10
+ .access = SNDRV_CTL_ELEM_ACCESS_READ,
+ .iface = SNDRV_CTL_ELEM_IFACE_PCM,
+ .name = SNDRV_CTL_NAME_IEC958("",PLAYBACK,MASK),
+- .count = 4,
++ .count = 3,
+ .info = snd_emu10k1_spdif_info,
+ .get = snd_emu10k1_spdif_get_mask
+ };
+@@ -880,7 +880,7 @@ static struct snd_kcontrol_new snd_emu10
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_PCM,
+ .name = SNDRV_CTL_NAME_IEC958("",PLAYBACK,DEFAULT),
+- .count = 4,
++ .count = 3,
+ .info = snd_emu10k1_spdif_info,
+ .get = snd_emu10k1_spdif_get,
+ .put = snd_emu10k1_spdif_put
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Oct 10 06:17:37 2007
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 10 Oct 2007 15:17:17 +0200
+Subject: ALSA: Fix build error without CONFIG_HAS_DMA
+To: stable@kernel.org
+Message-ID: <s5htzozqfc2.wl%tiwai@suse.de>
+
+From: Takashi Iwai <tiwai@suse.de>
+
+patch 8f11551b1798170dcffdd28475075ca4f1c6c990 in mainline
+
+[ALSA] Fix build error without CONFIG_HAS_DMA
+
+The recent change of include/asm-generic/dma-mapping-broken.h breaks
+the build without CONFIG_HAS_DMA. This patch is an ad hoc fix.
+
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/core/Makefile | 3 ++-
+ sound/core/memalloc.c | 6 ++++++
+ 2 files changed, 8 insertions(+), 1 deletion(-)
+
+--- a/sound/core/Makefile
++++ b/sound/core/Makefile
+@@ -14,7 +14,8 @@ endif
+ snd-pcm-objs := pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o \
+ pcm_memory.o
+
+-snd-page-alloc-objs := memalloc.o sgbuf.o
++snd-page-alloc-y := memalloc.o
++snd-page-alloc-$(CONFIG_HAS_DMA) += sgbuf.o
+
+ snd-rawmidi-objs := rawmidi.o
+ snd-timer-objs := timer.o
+--- a/sound/core/memalloc.c
++++ b/sound/core/memalloc.c
+@@ -206,6 +206,7 @@ void snd_free_pages(void *ptr, size_t si
+ *
+ */
+
++#ifdef CONFIG_HAS_DMA
+ /* allocate the coherent DMA pages */
+ static void *snd_malloc_dev_pages(struct device *dev, size_t size, dma_addr_t *dma)
+ {
+@@ -239,6 +240,7 @@ static void snd_free_dev_pages(struct de
+ dec_snd_pages(pg);
+ dma_free_coherent(dev, PAGE_SIZE << pg, ptr, dma);
+ }
++#endif /* CONFIG_HAS_DMA */
+
+ #ifdef CONFIG_SBUS
+
+@@ -312,12 +314,14 @@ int snd_dma_alloc_pages(int type, struct
+ dmab->area = snd_malloc_sbus_pages(device, size, &dmab->addr);
+ break;
+ #endif
++#ifdef CONFIG_HAS_DMA
+ case SNDRV_DMA_TYPE_DEV:
+ dmab->area = snd_malloc_dev_pages(device, size, &dmab->addr);
+ break;
+ case SNDRV_DMA_TYPE_DEV_SG:
+ snd_malloc_sgbuf_pages(device, size, dmab, NULL);
+ break;
++#endif
+ default:
+ printk(KERN_ERR "snd-malloc: invalid device type %d\n", type);
+ dmab->area = NULL;
+@@ -383,12 +387,14 @@ void snd_dma_free_pages(struct snd_dma_b
+ snd_free_sbus_pages(dmab->dev.dev, dmab->bytes, dmab->area, dmab->addr);
+ break;
+ #endif
++#ifdef CONFIG_HAS_DMA
+ case SNDRV_DMA_TYPE_DEV:
+ snd_free_dev_pages(dmab->dev.dev, dmab->bytes, dmab->area, dmab->addr);
+ break;
+ case SNDRV_DMA_TYPE_DEV_SG:
+ snd_free_sgbuf_pages(dmab);
+ break;
++#endif
+ default:
+ printk(KERN_ERR "snd-malloc: invalid device type %d\n", dmab->dev.type);
+ }
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Oct 10 06:15:38 2007
+From: Russ Cox <rsc@swtch.com>
+Date: Wed, 10 Oct 2007 15:15:12 +0200
+Subject: ALSA: fix selector unit bug affecting some USB speakerphones
+To: stable@kernel.org
+Message-ID: <s5hve9fqffj.wl%tiwai@suse.de>
+
+From: Russ Cox <rsc@swtch.com>
+
+patch 38977e96cb32e658716e11a05ec7f1fc4618e0f3 in mainline.
+
+[ALSA] fix selector unit bug affecting some USB speakerphones
+
+Following the suggestion in this thread:
+https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/26683
+the correct upper bound on desc[0] is 5 + num_ins not 6 + num_ins,
+because the index used later is 5+i, not 6+i.
+This change makes my Vosky Chatterbox speakerphone work.
+Apparently it also helps with the Minivox MV100.
+
+Signed-off-by: Russ Cox <rsc@swtch.com>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/usb/usbmixer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/usb/usbmixer.c
++++ b/sound/usb/usbmixer.c
+@@ -1483,7 +1483,7 @@ static int parse_audio_selector_unit(str
+ struct snd_kcontrol *kctl;
+ char **namelist;
+
+- if (! num_ins || desc[0] < 6 + num_ins) {
++ if (! num_ins || desc[0] < 5 + num_ins) {
+ snd_printk(KERN_ERR "invalid SELECTOR UNIT descriptor %d\n", unitid);
+ return -EINVAL;
+ }
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Oct 10 06:13:31 2007
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 10 Oct 2007 15:13:07 +0200
+Subject: ALSA: hda-codec - Avoid zero NID in line_out_pins[] of STAC codecs
+To: stable@kernel.org
+Message-ID: <s5hwstvqfj0.wl%tiwai@suse.de>
+
+patch c480f79bdca58923e605ff5e4698cfe1779bae70 in mainline
+
+[ALSA] hda-codec - Avoid zero NID in line_out_pins[] of STAC codecs
+
+The STAC codes adds line_out_pins[] for shared mic/line-inputs accordingly.
+But, the current code may give a hole with NID=0 in some setting, which
+results in an error at probe. This patch fixes the problem.
+
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ sound/pci/hda/patch_sigmatel.c | 15 ++++++++++-----
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+--- a/sound/pci/hda/patch_sigmatel.c
++++ b/sound/pci/hda/patch_sigmatel.c
+@@ -1182,7 +1182,8 @@ static int stac92xx_add_dyn_out_pins(str
+ case 3:
+ /* add line-in as side */
+ if (cfg->input_pins[AUTO_PIN_LINE] && num_dacs > 3) {
+- cfg->line_out_pins[3] = cfg->input_pins[AUTO_PIN_LINE];
++ cfg->line_out_pins[cfg->line_outs] =
++ cfg->input_pins[AUTO_PIN_LINE];
+ spec->line_switch = 1;
+ cfg->line_outs++;
+ }
+@@ -1190,12 +1191,14 @@ static int stac92xx_add_dyn_out_pins(str
+ case 2:
+ /* add line-in as clfe and mic as side */
+ if (cfg->input_pins[AUTO_PIN_LINE] && num_dacs > 2) {
+- cfg->line_out_pins[2] = cfg->input_pins[AUTO_PIN_LINE];
++ cfg->line_out_pins[cfg->line_outs] =
++ cfg->input_pins[AUTO_PIN_LINE];
+ spec->line_switch = 1;
+ cfg->line_outs++;
+ }
+ if (cfg->input_pins[AUTO_PIN_MIC] && num_dacs > 3) {
+- cfg->line_out_pins[3] = cfg->input_pins[AUTO_PIN_MIC];
++ cfg->line_out_pins[cfg->line_outs] =
++ cfg->input_pins[AUTO_PIN_MIC];
+ spec->mic_switch = 1;
+ cfg->line_outs++;
+ }
+@@ -1203,12 +1206,14 @@ static int stac92xx_add_dyn_out_pins(str
+ case 1:
+ /* add line-in as surr and mic as clfe */
+ if (cfg->input_pins[AUTO_PIN_LINE] && num_dacs > 1) {
+- cfg->line_out_pins[1] = cfg->input_pins[AUTO_PIN_LINE];
++ cfg->line_out_pins[cfg->line_outs] =
++ cfg->input_pins[AUTO_PIN_LINE];
+ spec->line_switch = 1;
+ cfg->line_outs++;
+ }
+ if (cfg->input_pins[AUTO_PIN_MIC] && num_dacs > 2) {
+- cfg->line_out_pins[2] = cfg->input_pins[AUTO_PIN_MIC];
++ cfg->line_out_pins[cfg->line_outs] =
++ cfg->input_pins[AUTO_PIN_MIC];
+ spec->mic_switch = 1;
+ cfg->line_outs++;
+ }
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 10:15:22 2007
+From: Milan Broz <mbroz@redhat.com>
+Date: Fri, 12 Oct 2007 18:14:55 +0100
+Subject: dm delay: fix status
+To: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: stable@kernel.org, dm-devel@redhat.com, linux-kernel@vger.kernel.org, Milan Broz <mbroz@redhat.com>
+Message-ID: <20071012171455.GR24157@agk.fab.redhat.com>
+Content-Disposition: inline
+
+
+From: Milan Broz <mbroz@redhat.com>
+
+patch 79662d1ea37392651f2cff08626cab6a40ba3adc in mainline.
+
+
+Fix missing space in dm-delay target status output
+if separate read and write delay are configured.
+
+Signed-off-by: Milan Broz <mbroz@redhat.com>
+Signed-off-by: Alasdair G Kergon <agk@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ drivers/md/dm-delay.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/dm-delay.c
++++ b/drivers/md/dm-delay.c
+@@ -305,7 +305,7 @@ static int delay_status(struct dm_target
+ (unsigned long long) dc->start_read,
+ dc->read_delay);
+ if (dc->dev_write)
+- DMEMIT("%s %llu %u", dc->dev_write->name,
++ DMEMIT(" %s %llu %u", dc->dev_write->name,
+ (unsigned long long) dc->start_write,
+ dc->write_delay);
+ break;
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 10:16:03 2007
+From: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
+Date: Fri, 12 Oct 2007 18:15:25 +0100
+Subject: dm: fix thaw_bdev
+To: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>, dm-devel@redhat.com, linux-kernel@vger.kernel.org, stable@kernel.org
+Message-ID: <20071012171525.GS24157@agk.fab.redhat.com>
+Content-Disposition: inline
+
+
+From: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
+
+patch ae9da83f6d800fe1f3b23bfbc8f7222ad1c5bb74 in mainline.
+
+This patch fixes a bd_mount_sem counter corruption bug in device-mapper.
+
+thaw_bdev() should be called only when freeze_bdev() was called for the
+device.
+Otherwise, thaw_bdev() will up bd_mount_sem and corrupt the semaphore counter.
+struct block_device with the corrupted semaphore may remain in slab cache
+and be reused later.
+
+Attached patch will fix it by calling unlock_fs() instead.
+unlock_fs() will determine whether it should call thaw_bdev()
+by checking the device is frozen or not.
+
+Easy reproducer is:
+ #!/bin/sh
+ while [ 1 ]; do
+ dmsetup --notable create a
+ dmsetup --nolockfs suspend a
+ dmsetup remove a
+ done
+
+It's not easy to see the effect of corrupted semaphore.
+So I have tested with putting printk below in bdev_alloc_inode():
+ if (atomic_read(&ei->bdev.bd_mount_sem.count) != 1)
+ printk(KERN_DEBUG "Incorrect semaphore count = %d (%p)\n",
+ atomic_read(&ei->bdev.bd_mount_sem.count),
+ &ei->bdev);
+
+Without the patch, I saw something like:
+ Incorrect semaphore count = 17 (f2ab91c0)
+
+With the patch, the message didn't appear.
+
+The bug was introduced in 2.6.16 with this bug fix:
+
+commit d9dde59ba03095e526640988c0fedd75e93bc8b7
+Date: Fri Feb 24 13:04:24 2006 -0800
+
+ [PATCH] dm: missing bdput/thaw_bdev at removal
+
+ Need to unfreeze and release bdev otherwise the bdev inode with
+ inconsistent state is reused later and cause problem.
+
+and backported to 2.6.15.5.
+
+It occurs only in free_dev(), which is called only when the dm device is
+removed. The buggy code is executed only if md->suspended_bdev is
+non-NULL and that can happen only when the device was suspended without
+noflush.
+
+Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
+Signed-off-by: Alasdair G Kergon <agk@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ drivers/md/dm.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm.c
++++ b/drivers/md/dm.c
+@@ -1064,12 +1064,14 @@ static struct mapped_device *alloc_dev(i
+ return NULL;
+ }
+
++static void unlock_fs(struct mapped_device *md);
++
+ static void free_dev(struct mapped_device *md)
+ {
+ int minor = md->disk->first_minor;
+
+ if (md->suspended_bdev) {
+- thaw_bdev(md->suspended_bdev, NULL);
++ unlock_fs(md);
+ bdput(md->suspended_bdev);
+ }
+ mempool_destroy(md->tio_pool);
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 15:18:07 2007
+From: Tsugikazu Shibata <tshibata@ab.jp.nec.co>
+Date: Fri, 12 Oct 2007 15:16:06 -0700
+Subject: HOWTO: update ja_JP/HOWTO with latest changes
+To: linux-kernel@vger.kernel.org
+Cc: Tsugikazu Shibata <tshibata@ab.jp.nec.com>, Greg Kroah-Hartman <gregkh@suse.de>, stable <stable@kernel.org>
+Message-ID: <11922274441634-git-send-email-gregkh@suse.de>
+
+From: Tsugikazu Shibata <tshibata@ab.jp.nec.co>
+
+patch 3b6662f192fc521b9657f63e68d20ec99979dae6 upstream.
+
+Here is another sync patch of Documentation/ja_JP/HOWTO
+
+Japanese developer sent me some cosmetic changes and also follow
+changes of HOWTO
+ Cross reference URL (sosdg.org/qiyong/lxr)
+ known_regression explanations on kernel dev. process
+
+Signed-off-by: Tsugikazu Shibata <tshibata@ab.jp.nec.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ Documentation/ja_JP/HOWTO | 84 ++++++++++++++++++++++++----------------------
+ 1 file changed, 45 insertions(+), 39 deletions(-)
+
+--- a/Documentation/ja_JP/HOWTO
++++ b/Documentation/ja_JP/HOWTO
+@@ -1,4 +1,4 @@
+-NOTE:
++NOTE:
+ This is a version of Documentation/HOWTO translated into Japanese.
+ This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
+ and the JF Project team <www.linux.or.jp/JF>.
+@@ -11,14 +11,14 @@ for non English (read: Japanese) speaker
+ fork. So if you have any comments or updates for this file, please try
+ to update the original English file first.
+
+-Last Updated: 2007/07/18
++Last Updated: 2007/09/23
+ ==================================
+ これは、
+-linux-2.6.22/Documentation/HOWTO
++linux-2.6.23/Documentation/HOWTO
+ の和訳です。
+
+ 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
+-翻訳日： 2007/07/16
++翻訳日： 2007/09/19
+ 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
+ 校正者： 松倉さん <nbh--mats at nifty dot com>
+ 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
+@@ -27,6 +27,7 @@ linux-2.6.22/Documentation/HOWTO
+ 野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
+ 河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
+ 岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
++ 内田さん (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
+ ==================================
+
+ Linux カーネル開発のやり方
+@@ -40,7 +41,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«é\96\8bç\99ºã\82³ã\83\9fã\83¥ã\83\8bã\83\86ã
+ 手助けになります。
+
+ もし、このドキュメントのどこかが古くなっていた場合には、このドキュメン
+-トの最後にリストしたメンテナーにパッチを送ってください。
++トの最後にリストしたメンテナにパッチを送ってください。
+
+ はじめに
+ ---------
+@@ -59,7 +60,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«é\96\8bç\99ºã\82³ã\83\9fã\83¥ã\83\8bã\83\86ã
+ ネル開発者には必要です。アーキテクチャ向けの低レベル部分の開発をするの
+ でなければ、(どんなアーキテクチャでも)アセンブリ(訳注: 言語)は必要あり
+ ません。以下の本は、C 言語の十分な知識や何年もの経験に取って代わるもの
+-ではありませんが、少なくともリファレンスとしてはいい本です。
++ではありませんが、少なくともリファレンスとしては良い本です。
+ - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
+ -『プログラミング言語Ｃ第2版』(B.W. カーニハン/D.M. リッチー著 石田晴久訳) [共立出版]
+ - "Practical C Programming" by Steve Oualline [O'Reilly]
+@@ -76,7 +77,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«é\96\8bç\99ºã\82³ã\83\9fã\83¥ã\83\8bã\83\86ã
+ ときどき、カーネルがツールチェインや C 言語拡張に置いている前提がどう
+ なっているのかわかりにくいことがあり、また、残念なことに決定的なリファ
+ レンスは存在しません。情報を得るには、gcc の info ページ( info gcc )を
+-みてください。
++見てください。
+
+ あなたは既存の開発コミュニティと一緒に作業する方法を学ぼうとしているこ
+ とに留意してください。そのコミュニティは、コーディング、スタイル、
+@@ -92,7 +93,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«é\96\8bç\99ºã\82³ã\83\9fã\83¥ã\83\8bã\83\86ã
+
+ Linux カーネルのソースコードは GPL ライセンスの下でリリースされていま
+ す。ライセンスの詳細については、ソースツリーのメインディレクトリに存在
+-する、COPYING のファイルをみてください。もしライセンスについてさらに質
++する、COPYING のファイルを見てください。もしライセンスについてさらに質
+ 問があれば、Linux Kernel メーリングリストに質問するのではなく、どうぞ
+ 法律家に相談してください。メーリングリストの人達は法律家ではなく、法的
+ 問題については彼らの声明はあてにするべきではありません。
+@@ -109,7 +110,8 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82½ã\83¼ã\82¹ã\83\84ã\83ªã\83¼ã\81¯å
+ 新しいドキュメントファイルも追加することを勧めます。
+ カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
+ 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
+-をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めます。
++をマニュアルページのメンテナ mtk-manpages@gmx.net に送ることを勧めま
++す。
+
+ 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
+ す-
+@@ -117,7 +119,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82½ã\83¼ã\82¹ã\83\84ã\83ªã\83¼ã\81¯å
+ README
+ このファイルは Linuxカーネルの簡単な背景とカーネルを設定(訳注
+ configure )し、生成(訳注 build )するために必要なことは何かが書かれ
+- ています。カーネルに関して初めての人はここからスタートするとよいで
++ ています。カーネルに関して初めての人はここからスタートすると良いで
+ しょう。
+
+ Documentation/Changes
+@@ -128,7 +130,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82½ã\83¼ã\82¹ã\83\84ã\83ªã\83¼ã\81¯å
+ Documentation/CodingStyle
+ これは Linux カーネルのコーディングスタイルと背景にある理由を記述
+ しています。全ての新しいコードはこのドキュメントにあるガイドライン
+- に従っていることを期待されています。大部分のメンテナーはこれらのルー
++ に従っていることを期待されています。大部分のメンテナはこれらのルー
+ ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
+ だけをレビューします。
+
+@@ -168,16 +170,16 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82½ã\83¼ã\82¹ã\83\84ã\83ªã\83¼ã\81¯å
+ 支援してください。
+
+ Documentation/ManagementStyle
+- このドキュメントは Linux カーネルのメンテナー達がどう行動するか、
++ このドキュメントは Linux カーネルのメンテナ達がどう行動するか、
+ 彼らの手法の背景にある共有されている精神について記述しています。こ
+ れはカーネル開発の初心者なら（もしくは、単に興味があるだけの人でも）
+- 重要です。なぜならこのドキュメントは、カーネルメンテナー達の独特な
++ 重要です。なぜならこのドキュメントは、カーネルメンテナ達の独特な
+ 行動についての多くの誤解や混乱を解消するからです。
+
+ Documentation/stable_kernel_rules.txt
+ このファイルはどのように stable カーネルのリリースが行われるかのルー
+ ルが記述されています。そしてこれらのリリースの中のどこかで変更を取
+- り入れてもらいたい場合に何をすればいいかが示されています。
++ り入れてもらいたい場合に何をすれば良いかが示されています。
+
+ Documentation/kernel-docs.txt
+ カーネル開発に付随する外部ドキュメントのリストです。もしあなたが
+@@ -218,9 +220,9 @@ web サイトには、コードの構成
+ ここには、また、カーネルのコンパイルのやり方やパッチの当て方などの間接
+ 的な基本情報も記述されています。
+
+-あなたがどこからスタートしてよいかわからないが、Linux カーネル開発コミュ
++あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
+ ニティに参加して何かすることをさがしている場合には、Linux kernel
+-Janitor's プロジェクトにいけばよいでしょう -
++Janitor's プロジェクトにいけば良いでしょう -
+ http://janitor.kernelnewbies.org/
+ ここはそのようなスタートをするのにうってつけの場所です。ここには、
+ Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
+@@ -243,7 +245,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82½ã\83¼ã\82¹ã\83\84ã\83ªã\83¼ã\81®ä
+ 自己参照方式で、索引がついた web 形式で、ソースコードを参照することが
+ できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
+ ます-
+- http://sosdg.org/~coywolf/lxr/
++ http://sosdg.org/~qiyong/lxr/
+
+ 開発プロセス
+ -----------------------
+@@ -265,9 +267,9 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\81®é\96\8bç\99ºã\83\97ã\83ã\82»ã\82¹ã
+ 以下のとおり-
+
+ - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
+- この期間中に、メンテナー達は Linus に大きな差分を送ることができま
+- す。このような差分は通常 -mm カーネルに数週間含まれてきたパッチで
+- す。 大きな変更は git(カーネルのソース管理ツール、詳細は
++ この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
++ このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。
++ 大きな変更は git(カーネルのソース管理ツール、詳細は
+ http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ
+ チファイルの形式のまま送るのでも十分です。
+
+@@ -285,6 +287,10 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\81®é\96\8bç\99ºã\83\97ã\83ã\82»ã\82¹ã
+ に安定した状態にあると判断したときにリリースされます。目標は毎週新
+ しい -rc カーネルをリリースすることです。
+
++ - 以下の URL で各 -rc リリースに存在する既知の後戻り問題のリスト
++ が追跡されます-
++ http://kernelnewbies.org/known_regressions
++
+ - このプロセスはカーネルが 「準備ができた」と考えられるまで継続しま
+ す。このプロセスはだいたい 6週間継続します。
+
+@@ -331,8 +337,8 @@ Andrew は個別のサブシステムカ
+ linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
+ とめます。
+ このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
+-が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、メ
+-インラインへ入れるように Linus にプッシュします。
++が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
++メインラインへ入れるように Linus にプッシュします。
+
+ メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
+ チが -mm ツリーでテストされることが強く推奨されます。
+@@ -460,7 +466,7 @@ MAINTAINERS ã\83\95ã\82¡ã\82¤ã\83«ã\81«ã\83ªã\82¹ã\83\88ã\81\8cã
+ せん-
+ 彼らはあなたのパッチの行毎にコメントを入れたいので、そのためにはそうす
+ るしかありません。あなたのメールプログラムが空白やタブを圧縮しないよう
+-に確認した方がいいです。最初の良いテストとしては、自分にメールを送って
++に確認した方が良いです。最初の良いテストとしては、自分にメールを送って
+ みて、そのパッチを自分で当ててみることです。もしそれがうまく行かないな
+ ら、あなたのメールプログラムを直してもらうか、正しく動くように変えるべ
+ きです。
+@@ -507,14 +513,14 @@ MAINTAINERS ã\83\95ã\82¡ã\82¤ã\83«ã\81«ã\83ªã\82¹ã\83\88ã\81\8cã
+ とも普通のことです。これはあなたのパッチが受け入れられないということで
+ は *ありません*、そしてあなた自身に反対することを意味するのでも *ありま
+ せん*。単に自分のパッチに対して指摘された問題を全て修正して再送すれば
+-いいのです。
++良いのです。
+
+
+ カーネルコミュニティと企業組織のちがい
+ -----------------------------------------------------------------
+
+ カーネルコミュニティは大部分の伝統的な会社の開発環境とは異ったやり方で
+-動いています。以下は問題を避けるためにできるとよいことののリストです-
++動いています。以下は問題を避けるためにできると良いことのリストです-
+
+ あなたの提案する変更について言うときのうまい言い方：
+
+@@ -525,7 +531,7 @@ MAINTAINERS ã\83\95ã\82¡ã\82¤ã\83«ã\81«ã\83ªã\82¹ã\83\88ã\81\8cã
+ - "以下は一連の小さなパッチ群ですが..."
+ - "これは典型的なマシンでの性能を向上させます.."
+
+- やめた方がいい悪い言い方：
++ やめた方が良い悪い言い方：
+
+ - このやり方で AIX/ptx/Solaris ではできたので、できるはずだ
+ - 私はこれを20年もの間やってきた、だから
+@@ -575,10 +581,10 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82³ã\83\9fã\83¥ã\83\8bã\83\86ã\82£ã\81¯ã
+
+ 1) 小さいパッチはあなたのパッチが適用される見込みを大きくします、カー
+ ネルの人達はパッチが正しいかどうかを確認する時間や労力をかけないか
+- らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。し
+- かし、500行のパッチは、正しいことをレビューするのに数時間かかるかも
+- しれません(時間はパッチのサイズなどにより指数関数に比例してかかりま
+- す)
++ らです。5行のパッチはメンテナがたった1秒見るだけで適用できます。
++ しかし、500行のパッチは、正しいことをレビューするのに数時間かかるか
++ もしれません(時間はパッチのサイズなどにより指数関数に比例してかかり
++ ます)
+
+ 小さいパッチは何かあったときにデバッグもとても簡単になります。パッ
+ チを1個1個取り除くのは、とても大きなパッチを当てた後に(かつ、何かお
+@@ -587,23 +593,23 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82³ã\83\9fã\83¥ã\83\8bã\83\86ã\82£ã\81¯ã
+ 2) 小さいパッチを送るだけでなく、送るまえに、書き直して、シンプルにす
+ る(もしくは、単に順番を変えるだけでも)ことも、とても重要です。
+
+-以下はカーネル開発者の Al Viro のたとえ話しです：
++以下はカーネル開発者の Al Viro のたとえ話です：
+
+ "生徒の数学の宿題を採点する先生のことを考えてみてください、先
+- 生は生徒が解に到達するまでの試行錯誤をみたいとは思わないでしょ
+- う。先生は簡潔な最高の解をみたいのです。良い生徒はこれを知って
++ 生は生徒が解に到達するまでの試行錯誤を見たいとは思わないでしょ
++ う。先生は簡潔な最高の解を見たいのです。良い生徒はこれを知って
+ おり、そして最終解の前の中間作業を提出することは決してないので
+ す"
+
+- カーネル開発でもこれは同じです。メンテナー達とレビューア達は、
+- 問題を解決する解の背後になる思考プロセスをみたいとは思いません。
+- 彼らは単純であざやかな解決方法をみたいのです。
++ カーネル開発でもこれは同じです。メンテナ達とレビューア達は、
++ 問題を解決する解の背後になる思考プロセスを見たいとは思いません。
++ 彼らは単純であざやかな解決方法を見たいのです。
+
+ あざやかな解を説明するのと、コミュニティと共に仕事をし、未解決の仕事を
+ 議論することのバランスをキープするのは難しいかもしれません。
+ ですから、開発プロセスの早期段階で改善のためのフィードバックをもらうよ
+-うにするのもいいですが、変更点を小さい部分に分割して全体ではまだ完成し
+-ていない仕事を(部分的に)取り込んでもらえるようにすることもいいことです。
++うにするのも良いですが、変更点を小さい部分に分割して全体ではまだ完成し
++ていない仕事を(部分的に)取り込んでもらえるようにすることも良いことです。
+
+ また、でき上がっていないものや、"将来直す" ようなパッチを、本流に含め
+ てもらうように送っても、それは受け付けられないことを理解してください。
+@@ -629,7 +635,7 @@ Linux ã\82«ã\83¼ã\83\8dã\83«ã\82³ã\83\9fã\83¥ã\83\8bã\83\86ã\82£ã\81¯ã
+ - テスト結果
+
+ これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
+-ントの ChangeLog セクションをみてください-
++ントの ChangeLog セクションを見てください-
+ "The Perfect Patch"
+ http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
+
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 14:48:02 2007
+From: Roland Dreier <rdreier@cisco.com>
+Date: Fri, 12 Oct 2007 14:47:25 -0700
+Subject: IB/mthca: Use mmiowb() to avoid firmware commands getting jumbled up
+To: stable@kernel.org
+Message-ID: <adasl4gngya.fsf@cisco.com>
+
+From: Roland Dreier <rdreier@cisco.com>
+
+Upstream as 76d7cc0345a037e8eea426f8abc710abd22946dd
+
+Firmware commands are sent to the HCA by writing multiple words to a
+command register block. Access to this block of registers is
+serialized with a mutex. However, on large SGI systems, problems were
+seen with multiple CPUs issuing FW commands at the same time, because
+the writes to the register block may be reordered within the system
+interconnect and reach the HCA in a different order than they were
+issued (even with the mutex). Fix this by adding an mmiowb() before
+dropping the mutex.
+
+Tested-by: Arthur Kepner <akepner@sgi.com>
+Signed-off-by: Roland Dreier <rolandd@cisco.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/infiniband/hw/mthca/mthca_cmd.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/infiniband/hw/mthca/mthca_cmd.c
++++ b/drivers/infiniband/hw/mthca/mthca_cmd.c
+@@ -290,6 +290,12 @@ static int mthca_cmd_post(struct mthca_d
+ err = mthca_cmd_post_hcr(dev, in_param, out_param, in_modifier,
+ op_modifier, op, token, event);
+
++ /*
++ * Make sure that our HCR writes don't get mixed in with
++ * writes from another CPU starting a FW command.
++ */
++ mmiowb();
++
+ mutex_unlock(&dev->cmd.hcr_mutex);
+ return err;
+ }
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Oct 10 18:55:44 2007
+From: Tejun Heo <htejun@gmail.com>
+Date: Thu, 11 Oct 2007 10:55:15 +0900
+Subject: libata: sync NCQ blacklist with upstream
+To: Jeff Garzik <jeff@garzik.org>, linux-ide@vger.kernel.org, stable@kernel.org
+Message-ID: <20071011015515.GQ12186@htj.dyndns.org>
+Content-Disposition: inline
+
+From: Tejun Heo <htejun@gmail.com>
+
+Synchronize NCQ blacklist with the current upstream. Based on changes
+already in Linus's 2.6.24-rc kernel tree.
+
+Signed-off-by: Tejun Heo <htejun@gmail.com>
+Cc: Jeff Garzik <jeff@garzik.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/ata/libata-core.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -3793,11 +3793,17 @@ static const struct ata_blacklist_entry
+ /* Drives which do spurious command completion */
+ { "HTS541680J9SA00", "SB2IC7EP", ATA_HORKAGE_NONCQ, },
+ { "HTS541612J9SA00", "SBDIC7JP", ATA_HORKAGE_NONCQ, },
++ { "HDT722516DLA380", "V43OA96A", ATA_HORKAGE_NONCQ, },
+ { "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
+ { "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
++ { "WDC WD3200AAJS-00RYA0", "12.01B01", ATA_HORKAGE_NONCQ, },
+ { "FUJITSU MHV2080BH", "00840028", ATA_HORKAGE_NONCQ, },
++ { "ST9120822AS", "3.CLF", ATA_HORKAGE_NONCQ, },
+ { "ST9160821AS", "3.CLF", ATA_HORKAGE_NONCQ, },
+- { "ST3160812AS", "3.AD", ATA_HORKAGE_NONCQ, },
++ { "ST9160821AS", "3.ALD", ATA_HORKAGE_NONCQ, },
++ { "ST9160821AS", "3.CCD", ATA_HORKAGE_NONCQ, },
++ { "ST3160812AS", "3.ADJ", ATA_HORKAGE_NONCQ, },
++ { "ST980813AS", "3.ADB", ATA_HORKAGE_NONCQ, },
+ { "SAMSUNG HD401LJ", "ZZ100-15", ATA_HORKAGE_NONCQ, },
+
+ /* devices which puke on READ_NATIVE_MAX */
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Oct 10 04:13:01 2007
+From: Ralf Baechle <ralf@linux-mips.org>
+Date: Wed, 10 Oct 2007 12:12:36 +0100
+Subject: MIPS: MT: Fix bug in multithreaded kernels.
+To: stable@kernel.org
+Message-ID: <20071010111236.GA5726@linux-mips.org>
+Content-Disposition: inline
+
+From: Ralf Baechle <ralf@linux-mips.org>
+
+patch a76ab5c10d99bdf458067cb495e72c0ee5f09909 in mainline.
+
+When GDB writes a breakpoint into address area of inferior process the
+kernel needs to invalidate the modified memory in the inferior which
+is done by calling flush_cache_page which in turns calls
+r4k_flush_cache_page and local_r4k_flush_cache_page for VSMP or SMTC
+kernel via r4k_on_each_cpu().
+
+As the VSMP and SMTC SMP kernels for 34K are running on a single shared
+caches it is possible to get away without interprocessor function calls.
+This optimization is implemented in r4k_on_each_cpu, so
+local_r4k_flush_cache_page is only ever called on the local CPU.
+
+This is where the following code in local_r4k_flush_cache_page() strikes:
+
+ /*
+ * If ownes no valid ASID yet, cannot possibly have gotten
+ * this page into the cache.
+ */
+ if (cpu_context(smp_processor_id(), mm) == 0)
+ return;
+
+On VSMP and SMTC had a function of cpu_context() for each CPU(TC).
+
+So in case another CPU than the CPU executing local_r4k_cache_flush_page
+has not accessed the mm but one of the other CPUs has there may be data
+to be flushed in the cache yet local_r4k_cache_flush_page will falsely
+return leaving the I-cache inconsistent for the breakpoint.
+
+While the issue was discovered with GDB it also exists in
+local_r4k_flush_cache_range() and local_r4k_flush_cache().
+
+Fixed by introducing a new function has_valid_asid which on MT kernels
+returns true if a mm is active on any processor in the system.
+
+This is relativly expensive since for memory acccesses in that loop
+cache misses have to be assumed but it seems the most viable solution
+for 2.6.23 and older -stable kernels.
+
+Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/mips/mm/c-r4k.c | 21 ++++++++++++++++++---
+ 1 file changed, 18 insertions(+), 3 deletions(-)
+
+--- a/arch/mips/mm/c-r4k.c
++++ b/arch/mips/mm/c-r4k.c
+@@ -360,11 +360,26 @@ static void r4k___flush_cache_all(void)
+ r4k_on_each_cpu(local_r4k___flush_cache_all, NULL, 1, 1);
+ }
+
++static inline int has_valid_asid(const struct mm_struct *mm)
++{
++#if defined(CONFIG_MIPS_MT_SMP) || defined(CONFIG_MIPS_MT_SMTC)
++ int i;
++
++ for_each_online_cpu(i)
++ if (cpu_context(i, mm))
++ return 1;
++
++ return 0;
++#else
++ return cpu_context(smp_processor_id(), mm);
++#endif
++}
++
+ static inline void local_r4k_flush_cache_range(void * args)
+ {
+ struct vm_area_struct *vma = args;
+
+- if (!(cpu_context(smp_processor_id(), vma->vm_mm)))
++ if (!(has_valid_asid(vma->vm_mm)))
+ return;
+
+ r4k_blast_dcache();
+@@ -383,7 +398,7 @@ static inline void local_r4k_flush_cache
+ {
+ struct mm_struct *mm = args;
+
+- if (!cpu_context(smp_processor_id(), mm))
++ if (!has_valid_asid(mm))
+ return;
+
+ /*
+@@ -434,7 +449,7 @@ static inline void local_r4k_flush_cache
+ * If ownes no valid ASID yet, cannot possibly have gotten
+ * this page into the cache.
+ */
+- if (cpu_context(smp_processor_id(), mm) == 0)
++ if (!has_valid_asid(mm))
+ return;
+
+ addr &= PAGE_MASK;
--- /dev/null
+From stable-bounces@linux.kernel.org Wed Oct 10 04:14:55 2007
+From: Ralf Baechle <ralf@linux-mips.org>
+Date: Wed, 10 Oct 2007 12:14:36 +0100
+Subject: MIPS: R1: Fix hazard barriers to make kernels work on R2 also.
+To: stable@kernel.org
+Message-ID: <20071010111436.GA5762@linux-mips.org>
+Content-Disposition: inline
+
+From: Ralf Baechle <ralf@linux-mips.org>
+
+patch 572afc248c33c902760f6f24a72c180f0e4f1719 in mainline.
+
+Tested with Malta; inflates malta_defconfig by 3932 bytes. Ideally there
+should be additional configuration to allow getting rid of this overhead
+but that would be too much complexity at this stage of the release cycle.
+
+Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ include/asm-mips/hazards.h | 54 ++++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 53 insertions(+), 1 deletion(-)
+
+--- a/include/asm-mips/hazards.h
++++ b/include/asm-mips/hazards.h
+@@ -10,11 +10,12 @@
+ #ifndef _ASM_HAZARDS_H
+ #define _ASM_HAZARDS_H
+
+-
+ #ifdef __ASSEMBLY__
+ #define ASMMACRO(name, code...) .macro name; code; .endm
+ #else
+
++#include <asm/cpu-features.h>
++
+ #define ASMMACRO(name, code...) \
+ __asm__(".macro " #name "; " #code "; .endm"); \
+ \
+@@ -86,6 +87,57 @@ do { \
+ : "=r" (tmp)); \
+ } while (0)
+
++#elif defined(CONFIG_CPU_MIPSR1)
++
++/*
++ * These are slightly complicated by the fact that we guarantee R1 kernels to
++ * run fine on R2 processors.
++ */
++ASMMACRO(mtc0_tlbw_hazard,
++ _ssnop; _ssnop; _ehb
++ )
++ASMMACRO(tlbw_use_hazard,
++ _ssnop; _ssnop; _ssnop; _ehb
++ )
++ASMMACRO(tlb_probe_hazard,
++ _ssnop; _ssnop; _ssnop; _ehb
++ )
++ASMMACRO(irq_enable_hazard,
++ _ssnop; _ssnop; _ssnop; _ehb
++ )
++ASMMACRO(irq_disable_hazard,
++ _ssnop; _ssnop; _ssnop; _ehb
++ )
++ASMMACRO(back_to_back_c0_hazard,
++ _ssnop; _ssnop; _ssnop; _ehb
++ )
++/*
++ * gcc has a tradition of misscompiling the previous construct using the
++ * address of a label as argument to inline assembler. Gas otoh has the
++ * annoying difference between la and dla which are only usable for 32-bit
++ * rsp. 64-bit code, so can't be used without conditional compilation.
++ * The alterantive is switching the assembler to 64-bit code which happens
++ * to work right even for 32-bit code ...
++ */
++#define __instruction_hazard() \
++do { \
++ unsigned long tmp; \
++ \
++ __asm__ __volatile__( \
++ " .set mips64r2 \n" \
++ " dla %0, 1f \n" \
++ " jr.hb %0 \n" \
++ " .set mips0 \n" \
++ "1: \n" \
++ : "=r" (tmp)); \
++} while (0)
++
++#define instruction_hazard() \
++do { \
++ if (cpu_has_mips_r2) \
++ __instruction_hazard(); \
++} while (0)
++
+ #elif defined(CONFIG_CPU_R10000)
+
+ /*
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 15:19:06 2007
+From: Greg Kroah-Hartman <gregkh@suse.de>
+Date: Fri, 12 Oct 2007 15:16:16 -0700
+Subject: MSI: Use correct data offset for 32-bit MSI in read_msi_msg()
+To: linux-pci@atrey.karlin.mff.cuni.cz
+Cc: Greg Kroah-Hartman <gregkh@suse.de>, Roland Dreier <roland@digitalvampire.org>, stable <stable@kernel.org>
+Message-ID: <11922275001257-git-send-email-gregkh@suse.de>
+
+
+From: Roland Dreier <roland@digitalvampire.org>
+
+patch cbf5d9e6b9bcf03291cbb51db144b3e2773a8a2d in mainline.
+
+While reading the MSI code trying to find a reason why MSI wouldn't
+work for devices that have a 32-bit MSI address capability, I noticed
+that read_msi_msg() seems to read the message data from the wrong
+offset in this case.
+
+Signed-off-by: Roland Dreier <roland@digitalvampire.org>
+Acked-by: Eric W. Biederman <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/msi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/pci/msi.c
++++ b/drivers/pci/msi.c
+@@ -132,7 +132,7 @@ void read_msi_msg(unsigned int irq, stru
+ pci_read_config_word(dev, msi_data_reg(pos, 1), &data);
+ } else {
+ msg->address_hi = 0;
+- pci_read_config_word(dev, msi_data_reg(pos, 1), &data);
++ pci_read_config_word(dev, msi_data_reg(pos, 0), &data);
+ }
+ msg->data = data;
+ break;
--- /dev/null
+From 4c2a54b09ba35a409afc34bd331a57a994921664 Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Wed, 19 Sep 2007 14:50:22 +1000
+Subject: POWERPC: Fix platinumfb framebuffer
+Message-Id: <1192178832.8476.108.camel@pasglop>
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+Patch 4c2a54b09ba35a409afc34bd331a57a994921664 in mailine.
+
+Current kernels have a non-working platinumfb due to some resource
+management issues. This fixes it.
+
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Paul Mackerras <paulus@samba.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/video/platinumfb.c | 48 ++++++++++++++++++++++++---------------------
+ 1 file changed, 26 insertions(+), 22 deletions(-)
+
+--- a/drivers/video/platinumfb.c
++++ b/drivers/video/platinumfb.c
+@@ -17,6 +17,8 @@
+ * more details.
+ */
+
++#undef DEBUG
++
+ #include <linux/module.h>
+ #include <linux/kernel.h>
+ #include <linux/errno.h>
+@@ -535,33 +537,35 @@ static int __devinit platinumfb_probe(st
+ volatile __u8 *fbuffer;
+ int bank0, bank1, bank2, bank3, rc;
+
+- printk(KERN_INFO "platinumfb: Found Apple Platinum video hardware\n");
++ dev_info(&odev->dev, "Found Apple Platinum video hardware\n");
+
+ info = framebuffer_alloc(sizeof(*pinfo), &odev->dev);
+- if (info == NULL)
++ if (info == NULL) {
++ dev_err(&odev->dev, "Failed to allocate fbdev !\n");
+ return -ENOMEM;
++ }
+ pinfo = info->par;
+
+ if (of_address_to_resource(dp, 0, &pinfo->rsrc_reg) ||
+ of_address_to_resource(dp, 1, &pinfo->rsrc_fb)) {
+- printk(KERN_ERR "platinumfb: Can't get resources\n");
+- framebuffer_release(info);
+- return -ENXIO;
+- }
+- if (!request_mem_region(pinfo->rsrc_reg.start,
+- pinfo->rsrc_reg.start -
+- pinfo->rsrc_reg.end + 1,
+- "platinumfb registers")) {
++ dev_err(&odev->dev, "Can't get resources\n");
+ framebuffer_release(info);
+ return -ENXIO;
+ }
++ dev_dbg(&odev->dev, " registers : 0x%llx...0x%llx\n",
++ (unsigned long long)pinfo->rsrc_reg.start,
++ (unsigned long long)pinfo->rsrc_reg.end);
++ dev_dbg(&odev->dev, " framebuffer: 0x%llx...0x%llx\n",
++ (unsigned long long)pinfo->rsrc_fb.start,
++ (unsigned long long)pinfo->rsrc_fb.end);
++
++ /* Do not try to request register space, they overlap with the
++ * northbridge and that can fail. Only request framebuffer
++ */
+ if (!request_mem_region(pinfo->rsrc_fb.start,
+- pinfo->rsrc_fb.start
+- - pinfo->rsrc_fb.end + 1,
++ pinfo->rsrc_fb.end - pinfo->rsrc_fb.start + 1,
+ "platinumfb framebuffer")) {
+- release_mem_region(pinfo->rsrc_reg.start,
+- pinfo->rsrc_reg.end -
+- pinfo->rsrc_reg.start + 1);
++ printk(KERN_ERR "platinumfb: Can't request framebuffer !\n");
+ framebuffer_release(info);
+ return -ENXIO;
+ }
+@@ -600,7 +604,8 @@ static int __devinit platinumfb_probe(st
+ bank2 = fbuffer[0x200000] == 0x56;
+ bank3 = fbuffer[0x300000] == 0x78;
+ pinfo->total_vram = (bank0 + bank1 + bank2 + bank3) * 0x100000;
+- printk(KERN_INFO "platinumfb: Total VRAM = %dMB (%d%d%d%d)\n", (int) (pinfo->total_vram / 1024 / 1024),
++ printk(KERN_INFO "platinumfb: Total VRAM = %dMB (%d%d%d%d)\n",
++ (unsigned int) (pinfo->total_vram / 1024 / 1024),
+ bank3, bank2, bank1, bank0);
+
+ /*
+@@ -644,16 +649,15 @@ static int __devexit platinumfb_remove(s
+ unregister_framebuffer (info);
+
+ /* Unmap frame buffer and registers */
++ iounmap(pinfo->frame_buffer);
++ iounmap(pinfo->platinum_regs);
++ iounmap(pinfo->cmap_regs);
++
+ release_mem_region(pinfo->rsrc_fb.start,
+ pinfo->rsrc_fb.end -
+ pinfo->rsrc_fb.start + 1);
+- release_mem_region(pinfo->rsrc_reg.start,
+- pinfo->rsrc_reg.end -
+- pinfo->rsrc_reg.start + 1);
+- iounmap(pinfo->frame_buffer);
+- iounmap(pinfo->platinum_regs);
++
+ release_mem_region(pinfo->cmap_regs_phys, 0x1000);
+- iounmap(pinfo->cmap_regs);
+
+ framebuffer_release(info);
+
param_sysfs_builtin-memchr-argument-fix.patch
minixfs-limit-minixfs-printks-on-corrupted-dir-i_size.patch
ib-uverbs-fix-checking-of-userspace-object-ownership.patch
+alsa-hda-codec-avoid-zero-nid-in-line_out_pins-of-stac-codecs.patch
+alsa-fix-selector-unit-bug-affecting-some-usb-speakerphones.patch
+alsa-fix-build-error-without-config_has_dma.patch
+alsa-emu10k1-fix-memory-corruption.patch
+libata-sync-ncq-blacklist-with-upstream.patch
+powerpc-fix-platinumfb-framebuffer.patch
+dm-delay-fix-status.patch
+dm-fix-thaw_bdev.patch
+xen-multicall-callbacks.patch
+xen-handle-lazy-cr3-on-unpin.patch
+xen-fix-register_vcpu_info.patch
+xen-xfs-unmap.patch
+ib-mthca-use-mmiowb-to-avoid-firmware-commands-getting-jumbled-up.patch
+howto-update-ja_jp-howto-with-latest-changes.patch
+msi-use-correct-data-offset-for-32-bit-msi-in-read_msi_msg.patch
+usb-remove-usb_quirk_no_autosuspend.patch
+usb-gadget-ether-prevent-oops-caused-by-error-interrupt-race.patch
+usb-mutual-exclusion-for-ehci-init-and-port-resets.patch
+mips-mt-fix-bug-in-multithreaded-kernels.patch
+mips-r1-fix-hazard-barriers-to-make-kernels-work-on-r2-also.patch
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 15:29:30 2007
+From: Benedikt Spranger <bene@linutronix.de>
+Date: Fri, 12 Oct 2007 15:18:59 -0700
+Subject: usb-gadget-ether: prevent oops caused by error interrupt race
+To: linux-usb-devel@lists.sourceforge.net
+Cc: David Brownell <dbrownell@users.sourceforge.net>, Greg Kroah-Hartman <gregkh@suse.de>, Benedikt Spranger <bene@linutronix.de>, stable <stable@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Andrew Morton <akpm@linux-foundation.org>
+Message-ID: <1192227560-4852-121-git-send-email-gregkh@suse.de>
+
+
+From: Benedikt Spranger <bene@linutronix.de>
+
+patch 5395353e0c8272fe73ac914acd7e4add0da2bef0 in mainline.
+
+Fix a longstanding race in the Ethernet gadget driver, which can cause an
+oops on device disconnect. The fix is just to make the TX path check
+whether its freelist is empty. That check is otherwise not necessary,
+since the queue is always stopped when that list empties (and restarted
+when request completion puts an entry back on that freelist).
+
+The race window starts when the network code decides to transmit a packet,
+and ends when hard_start_xmit() grabs the freelist lock. When disconnect()
+is called inside that window, it shuts down the TX queue and breaks the
+otherwise-solid assumption that packets are never sent through a TX queue
+that's stopped.
+
+Signed-off-by: Benedikt Spranger <bene@linutronix.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/gadget/ether.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/usb/gadget/ether.c
++++ b/drivers/usb/gadget/ether.c
+@@ -1989,8 +1989,20 @@ static int eth_start_xmit (struct sk_buf
+ }
+
+ spin_lock_irqsave(&dev->req_lock, flags);
++ /*
++ * this freelist can be empty if an interrupt triggered disconnect()
++ * and reconfigured the gadget (shutting down this queue) after the
++ * network stack decided to xmit but before we got the spinlock.
++ */
++ if (list_empty(&dev->tx_reqs)) {
++ spin_unlock_irqrestore(&dev->req_lock, flags);
++ return 1;
++ }
++
+ req = container_of (dev->tx_reqs.next, struct usb_request, list);
+ list_del (&req->list);
++
++ /* temporarily stop TX queue when the freelist empties */
+ if (list_empty (&dev->tx_reqs))
+ netif_stop_queue (net);
+ spin_unlock_irqrestore(&dev->req_lock, flags);
--- /dev/null
+From gregkh@suse.de Fri Oct 12 15:30:23 2007
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 12 Oct 2007 15:19:14 -0700
+Subject: USB: mutual exclusion for EHCI init and port resets
+To: linux-usb-devel@lists.sourceforge.net
+Cc: Alan Stern <stern@rowland.harvard.edu>, David Miller <davem@davemloft.net>, Dely L Sy <dely.l.sy@intel.com>, Greg Kroah-Hartman <gregkh@suse.de>
+Message-ID: <1192227560-4852-136-git-send-email-gregkh@suse.de>
+
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+patch 32fe01985aa2cb2562f6fc171e526e279abe10db in mainline.
+
+This patch (as999) fixes a problem that sometimes shows up when host
+controller driver modules are loaded in the wrong order. If ehci-hcd
+happens to initialize an EHCI controller while the companion OHCI or
+UHCI controller is in the middle of a port reset, the reset can fail
+and the companion may get very confused. The patch adds an
+rw-semaphore and uses it to keep EHCI initialization and port resets
+mutually exclusive.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Acked-by: David Brownell <david-b@pacbell.net>
+Cc: David Miller <davem@davemloft.net>
+Cc: Dely L Sy <dely.l.sy@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+---
+ drivers/usb/core/hcd.h | 8 +++++++-
+ drivers/usb/core/hub.c | 15 ++++++++++++++-
+ drivers/usb/host/ehci-hcd.c | 8 ++++++++
+ 3 files changed, 29 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/core/hcd.h
++++ b/drivers/usb/core/hcd.h
+@@ -19,6 +19,8 @@
+
+ #ifdef __KERNEL__
+
++#include <linux/rwsem.h>
++
+ /* This file contains declarations of usbcore internals that are mostly
+ * used or exposed by Host Controller Drivers.
+ */
+@@ -454,5 +456,9 @@ static inline void usbmon_urb_complete(s
+ : (in_interrupt () ? "in_interrupt" : "can sleep"))
+
+
+-#endif /* __KERNEL__ */
++/* This rwsem is for use only by the hub driver and ehci-hcd.
++ * Nobody else should touch it.
++ */
++extern struct rw_semaphore ehci_cf_port_reset_rwsem;
+
++#endif /* __KERNEL__ */
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -125,6 +125,12 @@ MODULE_PARM_DESC(use_both_schemes,
+ "try the other device initialization scheme if the "
+ "first one fails");
+
++/* Mutual exclusion for EHCI CF initialization. This interferes with
++ * port reset on some companion controllers.
++ */
++DECLARE_RWSEM(ehci_cf_port_reset_rwsem);
++EXPORT_SYMBOL_GPL(ehci_cf_port_reset_rwsem);
++
+
+ static inline char *portspeed(int portstatus)
+ {
+@@ -1460,6 +1466,11 @@ static int hub_port_reset(struct usb_hub
+ {
+ int i, status;
+
++ /* Block EHCI CF initialization during the port reset.
++ * Some companion controllers don't like it when they mix.
++ */
++ down_read(&ehci_cf_port_reset_rwsem);
++
+ /* Reset the port */
+ for (i = 0; i < PORT_RESET_TRIES; i++) {
+ status = set_port_feature(hub->hdev,
+@@ -1490,7 +1501,7 @@ static int hub_port_reset(struct usb_hub
+ usb_set_device_state(udev, status
+ ? USB_STATE_NOTATTACHED
+ : USB_STATE_DEFAULT);
+- return status;
++ goto done;
+ }
+
+ dev_dbg (hub->intfdev,
+@@ -1503,6 +1514,8 @@ static int hub_port_reset(struct usb_hub
+ "Cannot enable port %i. Maybe the USB cable is bad?\n",
+ port1);
+
++ done:
++ up_read(&ehci_cf_port_reset_rwsem);
+ return status;
+ }
+
+--- a/drivers/usb/host/ehci-hcd.c
++++ b/drivers/usb/host/ehci-hcd.c
+@@ -570,10 +570,18 @@ static int ehci_run (struct usb_hcd *hcd
+ * are explicitly handed to companion controller(s), so no TT is
+ * involved with the root hub. (Except where one is integrated,
+ * and there's no companion controller unless maybe for USB OTG.)
++ *
++ * Turning on the CF flag will transfer ownership of all ports
++ * from the companions to the EHCI controller. If any of the
++ * companions are in the middle of a port reset at the time, it
++ * could cause trouble. Write-locking ehci_cf_port_reset_rwsem
++ * guarantees that no resets are in progress.
+ */
++ down_write(&ehci_cf_port_reset_rwsem);
+ hcd->state = HC_STATE_RUNNING;
+ ehci_writel(ehci, FLAG_CF, &ehci->regs->configured_flag);
+ ehci_readl(ehci, &ehci->regs->command); /* unblock posted writes */
++ up_write(&ehci_cf_port_reset_rwsem);
+
+ temp = HC_VERSION(ehci_readl(ehci, &ehci->caps->hc_capbase));
+ ehci_info (ehci,
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 15:29:06 2007
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Fri, 12 Oct 2007 15:18:49 -0700
+Subject: USB: remove USB_QUIRK_NO_AUTOSUSPEND
+To: linux-usb-devel@lists.sourceforge.net
+Cc: Greg Kroah-Hartman <gregkh@suse.de>, Alan Stern <stern@rowland.harvard.edu>, stable <stable@kernel.org>
+Message-ID: <1192227560-4852-111-git-send-email-gregkh@suse.de>
+
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+patch a691efa9888e71232dfb4088fb8a8304ffc7b0f9 in mainline.
+
+This patch (as995) cleans up the remains of the former NO_AUTOSUSPEND
+quirk. Since autosuspend is disabled by default, we will let
+userspace worry about which devices can safely be suspended. Thus the
+lengthy series of quirk entries is no longer needed, and neither is
+the quirk ID. I suppose someone might eventually run across a hub
+that can't be suspended; let's ignore the possibility for now.
+
+The patch also cleans up the hasty way in which autosuspend gets
+disabled. Setting udev->autosuspend_delay to -1 wasn't quite right,
+because the value is always supposed to be a multiple of HZ. It's
+better to leave the delay value alone and set autosuspend_disabled,
+which is what the quirk routine used to do.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/core/quirks.c | 81 ---------------------------------------------
+ include/linux/usb/quirks.h | 7 +--
+ 2 files changed, 3 insertions(+), 85 deletions(-)
+
+--- a/drivers/usb/core/quirks.c
++++ b/drivers/usb/core/quirks.c
+@@ -32,52 +32,6 @@ static const struct usb_device_id usb_qu
+ { USB_DEVICE(0x0204, 0x6025), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* HP 5300/5370C scanner */
+ { USB_DEVICE(0x03f0, 0x0701), .driver_info = USB_QUIRK_STRING_FETCH_255 },
+- /* Hewlett-Packard PhotoSmart 720 / PhotoSmart 935 (storage) */
+- { USB_DEVICE(0x03f0, 0x4002), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+- /* SGS Thomson Microelectronics 4in1 card reader */
+- { USB_DEVICE(0x0483, 0x0321), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+- /* Acer Peripherals Inc. (now BenQ Corp.) Prisa 640BU */
+- { USB_DEVICE(0x04a5, 0x207e), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Benq S2W 3300U */
+- { USB_DEVICE(0x04a5, 0x20b0), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Canon, Inc. CanoScan N1240U/LiDE30 */
+- { USB_DEVICE(0x04a9, 0x220e), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Canon, Inc. CanoScan N650U/N656U */
+- { USB_DEVICE(0x04a9, 0x2206), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Canon, Inc. CanoScan 1220U */
+- { USB_DEVICE(0x04a9, 0x2207), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Canon, Inc. CanoScan N670U/N676U/LiDE 20 */
+- { USB_DEVICE(0x04a9, 0x220d), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* old Cannon scanner */
+- { USB_DEVICE(0x04a9, 0x2220), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Seiko Epson Corp. Perfection 1200 */
+- { USB_DEVICE(0x04b8, 0x0104), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Seiko Epson Corp. Perfection 660 */
+- { USB_DEVICE(0x04b8, 0x0114), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Epson Perfection 1260 Photo */
+- { USB_DEVICE(0x04b8, 0x011d), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Seiko Epson Corp - Perfection 1670 */
+- { USB_DEVICE(0x04b8, 0x011f), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* EPSON Perfection 2480 */
+- { USB_DEVICE(0x04b8, 0x0121), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Seiko Epson Corp.*/
+- { USB_DEVICE(0x04b8, 0x0122), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Samsung ML-2010 printer */
+- { USB_DEVICE(0x04e8, 0x326c), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Samsung ML-2510 Series printer */
+- { USB_DEVICE(0x04e8, 0x327e), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Elsa MicroLink 56k (V.250) */
+- { USB_DEVICE(0x05cc, 0x2267), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Ultima Electronics Corp.*/
+- { USB_DEVICE(0x05d8, 0x4005), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+- /* Genesys USB-to-IDE */
+- { USB_DEVICE(0x0503, 0x0702), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+- /* USB Graphical LCD - EEH Datalink GmbH */
+- { USB_DEVICE(0x060c, 0x04eb), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+
+ /* INTEL VALUE SSD */
+ { USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
+@@ -85,44 +39,15 @@ static const struct usb_device_id usb_qu
+ /* M-Systems Flash Disk Pioneers */
+ { USB_DEVICE(0x08ec, 0x1000), .driver_info = USB_QUIRK_RESET_RESUME },
+
+- /* Agfa Snapscan1212u */
+- { USB_DEVICE(0x06bd, 0x2061), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Seagate RSS LLC */
+- { USB_DEVICE(0x0bc2, 0x3000), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- /* Umax [hex] Astra 3400U */
+- { USB_DEVICE(0x1606, 0x0060), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+ /* Philips PSC805 audio device */
+ { USB_DEVICE(0x0471, 0x0155), .driver_info = USB_QUIRK_RESET_RESUME },
+
+- /* Alcor multi-card reader */
+- { USB_DEVICE(0x058f, 0x6366), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+- /* Canon EOS 5D in PC Connection mode */
+- { USB_DEVICE(0x04a9, 0x3101), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+- /* RIM Blackberry */
+- { USB_DEVICE(0x0fca, 0x0001), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- { USB_DEVICE(0x0fca, 0x0004), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+- { USB_DEVICE(0x0fca, 0x0006), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+- /* Apple iPhone */
+- { USB_DEVICE(0x05ac, 0x1290), .driver_info = USB_QUIRK_NO_AUTOSUSPEND },
+-
+ /* SKYMEDI USB_DRIVE */
+ { USB_DEVICE(0x1516, 0x8628), .driver_info = USB_QUIRK_RESET_RESUME },
+
+ { } /* terminating entry must be last */
+ };
+
+-static void usb_autosuspend_quirk(struct usb_device *udev)
+-{
+-#ifdef CONFIG_USB_SUSPEND
+- /* disable autosuspend, but allow the user to re-enable it via sysfs */
+- udev->autosuspend_disabled = 1;
+-#endif
+-}
+-
+ static const struct usb_device_id *find_id(struct usb_device *udev)
+ {
+ const struct usb_device_id *id = usb_quirk_list;
+@@ -149,13 +74,9 @@ void usb_detect_quirks(struct usb_device
+ dev_dbg(&udev->dev, "USB quirks for this device: %x\n",
+ udev->quirks);
+
+- /* do any special quirk handling here if needed */
+- if (udev->quirks & USB_QUIRK_NO_AUTOSUSPEND)
+- usb_autosuspend_quirk(udev);
+-
+ /* By default, disable autosuspend for all non-hubs */
+ #ifdef CONFIG_USB_SUSPEND
+ if (udev->descriptor.bDeviceClass != USB_CLASS_HUB)
+- udev->autosuspend_delay = -1;
++ udev->autosuspend_disabled = 1;
+ #endif
+ }
+--- a/include/linux/usb/quirks.h
++++ b/include/linux/usb/quirks.h
+@@ -4,11 +4,8 @@
+ * belong here.
+ */
+
+-/* device must not be autosuspended */
+-#define USB_QUIRK_NO_AUTOSUSPEND 0x00000001
+-
+ /* string descriptors must not be fetched using a 255-byte read */
+-#define USB_QUIRK_STRING_FETCH_255 0x00000002
++#define USB_QUIRK_STRING_FETCH_255 0x00000001
+
+ /* device can't resume correctly so reset it instead */
+-#define USB_QUIRK_RESET_RESUME 0x00000004
++#define USB_QUIRK_RESET_RESUME 0x00000002
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 14:33:49 2007
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+Date: Fri, 12 Oct 2007 14:11:40 -0700
+Subject: xen: fix incorrect vcpu_register_vcpu_info hypercall argument
+To: LKML <linux-kernel@vger.kernel.org>
+Cc: xen-devel@lists.xensource.com, virtualization@lists.osdl.org, Mark Williamson <mark.williamson@cl.cam.ac.uk>, Morten Bøgeskov <xen-users@morten.bogeskov.dk>, Chris Wright <chrisw@sous-sol.org>, Andi Kleen <ak@muc.de>, Andrew Morton <akpm@linux-foundation.org>, Keir Fraser <keir@xensource.com>, Stable Kernel <stable@kernel.org>
+Message-ID: <20071012211148.610399000@goop.org>
+Content-Disposition: inline; filename=xen-fix-register_vcpu_info.patch
+
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+
+patch e3d2697669abbe26c08dc9b95e2a71c634d096ed in mainline.
+
+The kernel's copy of struct vcpu_register_vcpu_info was out of date,
+at best causing the hypercall to fail and the guest kernel to fall
+back to the old mechanism, or worse, causing random memory corruption.
+
+Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
+Cc: Stable Kernel <stable@kernel.org>
+Cc: Morten =?utf-8?q?B=C3=B8geskov?= <xen-users@morten.bogeskov.dk>
+Cc: Mark Williamson <mark.williamson@cl.cam.ac.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/i386/xen/enlighten.c | 2 +-
+ include/xen/interface/vcpu.h | 5 +++--
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+--- a/arch/i386/xen/enlighten.c
++++ b/arch/i386/xen/enlighten.c
+@@ -116,7 +116,7 @@ static void __init xen_vcpu_setup(int cp
+ info.mfn = virt_to_mfn(vcpup);
+ info.offset = offset_in_page(vcpup);
+
+- printk(KERN_DEBUG "trying to map vcpu_info %d at %p, mfn %x, offset %d\n",
++ printk(KERN_DEBUG "trying to map vcpu_info %d at %p, mfn %llx, offset %d\n",
+ cpu, vcpup, info.mfn, info.offset);
+
+ /* Check to see if the hypervisor will put the vcpu_info
+--- a/include/xen/interface/vcpu.h
++++ b/include/xen/interface/vcpu.h
+@@ -160,8 +160,9 @@ struct vcpu_set_singleshot_timer {
+ */
+ #define VCPUOP_register_vcpu_info 10 /* arg == struct vcpu_info */
+ struct vcpu_register_vcpu_info {
+- uint32_t mfn; /* mfn of page to place vcpu_info */
+- uint32_t offset; /* offset within page */
++ uint64_t mfn; /* mfn of page to place vcpu_info */
++ uint32_t offset; /* offset within page */
++ uint32_t rsvd; /* unused */
+ };
+
+ #endif /* __XEN_PUBLIC_VCPU_H__ */
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 14:33:57 2007
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+Date: Fri, 12 Oct 2007 14:11:37 -0700
+Subject: xen: deal with stale cr3 values when unpinning pagetables
+To: LKML <linux-kernel@vger.kernel.org>
+Cc: xen-devel@lists.xensource.com, virtualization@lists.osdl.org, Chris Wright <chrisw@sous-sol.org>, Andi Kleen <ak@muc.de>, Andrew Morton <akpm@linux-foundation.org>, Keir Fraser <keir@xensource.com>, Stable Kernel <stable@kernel.org>
+Message-ID: <20071012211148.208637000@goop.org>
+Content-Disposition: inline; filename=xen-handle-lazy-cr3-on-unpin.patch
+
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+
+patch 9f79991d4186089e228274196413572cc000143b in mainline.
+
+When a pagetable is no longer in use, it must be unpinned so that its
+pages can be freed. However, this is only possible if there are no
+stray uses of the pagetable. The code currently deals with all the
+usual cases, but there's a rare case where a vcpu is changing cr3, but
+is doing so lazily, and the change hasn't actually happened by the time
+the pagetable is unpinned, even though it appears to have been completed.
+
+This change adds a second per-cpu cr3 variable - xen_current_cr3 -
+which tracks the actual state of the vcpu cr3. It is only updated once
+the actual hypercall to set cr3 has been completed. Other processors
+wishing to unpin a pagetable can check other vcpu's xen_current_cr3
+values to see if any cross-cpu IPIs are needed to clean things up.
+
+Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/i386/xen/enlighten.c | 55 +++++++++++++++++++++++++++++++---------------
+ arch/i386/xen/mmu.c | 29 +++++++++++++++++++++---
+ arch/i386/xen/xen-ops.h | 1
+ 3 files changed, 65 insertions(+), 20 deletions(-)
+
+--- a/arch/i386/xen/enlighten.c
++++ b/arch/i386/xen/enlighten.c
+@@ -56,7 +56,23 @@ DEFINE_PER_CPU(enum paravirt_lazy_mode,
+
+ DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
+ DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info);
+-DEFINE_PER_CPU(unsigned long, xen_cr3);
++
++/*
++ * Note about cr3 (pagetable base) values:
++ *
++ * xen_cr3 contains the current logical cr3 value; it contains the
++ * last set cr3. This may not be the current effective cr3, because
++ * its update may be being lazily deferred. However, a vcpu looking
++ * at its own cr3 can use this value knowing that it everything will
++ * be self-consistent.
++ *
++ * xen_current_cr3 contains the actual vcpu cr3; it is set once the
++ * hypercall to set the vcpu cr3 is complete (so it may be a little
++ * out of date, but it will never be set early). If one vcpu is
++ * looking at another vcpu's cr3 value, it should use this variable.
++ */
++DEFINE_PER_CPU(unsigned long, xen_cr3); /* cr3 stored as physaddr */
++DEFINE_PER_CPU(unsigned long, xen_current_cr3); /* actual vcpu cr3 */
+
+ struct start_info *xen_start_info;
+ EXPORT_SYMBOL_GPL(xen_start_info);
+@@ -632,32 +648,36 @@ static unsigned long xen_read_cr3(void)
+ return x86_read_percpu(xen_cr3);
+ }
+
++static void set_current_cr3(void *v)
++{
++ x86_write_percpu(xen_current_cr3, (unsigned long)v);
++}
++
+ static void xen_write_cr3(unsigned long cr3)
+ {
++ struct mmuext_op *op;
++ struct multicall_space mcs;
++ unsigned long mfn = pfn_to_mfn(PFN_DOWN(cr3));
++
+ BUG_ON(preemptible());
+
+- if (cr3 == x86_read_percpu(xen_cr3)) {
+- /* just a simple tlb flush */
+- xen_flush_tlb();
+- return;
+- }
++ mcs = xen_mc_entry(sizeof(*op)); /* disables interrupts */
+
++ /* Update while interrupts are disabled, so its atomic with
++ respect to ipis */
+ x86_write_percpu(xen_cr3, cr3);
+
++ op = mcs.args;
++ op->cmd = MMUEXT_NEW_BASEPTR;
++ op->arg1.mfn = mfn;
+
+- {
+- struct mmuext_op *op;
+- struct multicall_space mcs = xen_mc_entry(sizeof(*op));
+- unsigned long mfn = pfn_to_mfn(PFN_DOWN(cr3));
+-
+- op = mcs.args;
+- op->cmd = MMUEXT_NEW_BASEPTR;
+- op->arg1.mfn = mfn;
++ MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
+
+- MULTI_mmuext_op(mcs.mc, op, 1, NULL, DOMID_SELF);
++ /* Update xen_update_cr3 once the batch has actually
++ been submitted. */
++ xen_mc_callback(set_current_cr3, (void *)cr3);
+
+- xen_mc_issue(PARAVIRT_LAZY_CPU);
+- }
++ xen_mc_issue(PARAVIRT_LAZY_CPU); /* interrupts restored */
+ }
+
+ /* Early in boot, while setting up the initial pagetable, assume
+@@ -1113,6 +1133,7 @@ asmlinkage void __init xen_start_kernel(
+ /* keep using Xen gdt for now; no urgent need to change it */
+
+ x86_write_percpu(xen_cr3, __pa(pgd));
++ x86_write_percpu(xen_current_cr3, __pa(pgd));
+
+ #ifdef CONFIG_SMP
+ /* Don't do the full vcpu_info placement stuff until we have a
+--- a/arch/i386/xen/mmu.c
++++ b/arch/i386/xen/mmu.c
+@@ -515,20 +515,43 @@ static void drop_other_mm_ref(void *info
+
+ if (__get_cpu_var(cpu_tlbstate).active_mm == mm)
+ leave_mm(smp_processor_id());
++
++ /* If this cpu still has a stale cr3 reference, then make sure
++ it has been flushed. */
++ if (x86_read_percpu(xen_current_cr3) == __pa(mm->pgd)) {
++ load_cr3(swapper_pg_dir);
++ arch_flush_lazy_cpu_mode();
++ }
+ }
+
+ static void drop_mm_ref(struct mm_struct *mm)
+ {
++ cpumask_t mask;
++ unsigned cpu;
++
+ if (current->active_mm == mm) {
+ if (current->mm == mm)
+ load_cr3(swapper_pg_dir);
+ else
+ leave_mm(smp_processor_id());
++ arch_flush_lazy_cpu_mode();
++ }
++
++ /* Get the "official" set of cpus referring to our pagetable. */
++ mask = mm->cpu_vm_mask;
++
++ /* It's possible that a vcpu may have a stale reference to our
++ cr3, because its in lazy mode, and it hasn't yet flushed
++ its set of pending hypercalls yet. In this case, we can
++ look at its actual current cr3 value, and force it to flush
++ if needed. */
++ for_each_online_cpu(cpu) {
++ if (per_cpu(xen_current_cr3, cpu) == __pa(mm->pgd))
++ cpu_set(cpu, mask);
+ }
+
+- if (!cpus_empty(mm->cpu_vm_mask))
+- xen_smp_call_function_mask(mm->cpu_vm_mask, drop_other_mm_ref,
+- mm, 1);
++ if (!cpus_empty(mask))
++ xen_smp_call_function_mask(mask, drop_other_mm_ref, mm, 1);
+ }
+ #else
+ static void drop_mm_ref(struct mm_struct *mm)
+--- a/arch/i386/xen/xen-ops.h
++++ b/arch/i386/xen/xen-ops.h
+@@ -11,6 +11,7 @@ void xen_copy_trap_info(struct trap_info
+
+ DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);
+ DECLARE_PER_CPU(unsigned long, xen_cr3);
++DECLARE_PER_CPU(unsigned long, xen_current_cr3);
+
+ extern struct start_info *xen_start_info;
+ extern struct shared_info *HYPERVISOR_shared_info;
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 14:33:42 2007
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+Date: Fri, 12 Oct 2007 14:11:36 -0700
+Subject: xen: add batch completion callbacks
+To: LKML <linux-kernel@vger.kernel.org>
+Cc: xen-devel@lists.xensource.com, virtualization@lists.osdl.org, Chris Wright <chrisw@sous-sol.org>, Andi Kleen <ak@muc.de>, Andrew Morton <akpm@linux-foundation.org>, Keir Fraser <keir@xensource.com>, Stable Kernel <stable@kernel.org>
+Message-ID: <20071012211148.065483000@goop.org>
+Content-Disposition: inline; filename=xen-multicall-callbacks.patch
+
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+
+patch 91e0c5f3dad47838cb2ecc1865ce789a0b7182b1 in mainline.
+
+This adds a mechanism to register a callback function to be called once
+a batch of hypercalls has been issued. This is typically used to unlock
+things which must remain locked until the hypercall has taken place.
+
+Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/i386/xen/multicalls.c | 29 ++++++++++++++++++++++++++---
+ arch/i386/xen/multicalls.h | 3 +++
+ 2 files changed, 29 insertions(+), 3 deletions(-)
+
+--- a/arch/i386/xen/multicalls.c
++++ b/arch/i386/xen/multicalls.c
+@@ -32,7 +32,11 @@
+ struct mc_buffer {
+ struct multicall_entry entries[MC_BATCH];
+ u64 args[MC_ARGS];
+- unsigned mcidx, argidx;
++ struct callback {
++ void (*fn)(void *);
++ void *data;
++ } callbacks[MC_BATCH];
++ unsigned mcidx, argidx, cbidx;
+ };
+
+ static DEFINE_PER_CPU(struct mc_buffer, mc_buffer);
+@@ -43,6 +47,7 @@ void xen_mc_flush(void)
+ struct mc_buffer *b = &__get_cpu_var(mc_buffer);
+ int ret = 0;
+ unsigned long flags;
++ int i;
+
+ BUG_ON(preemptible());
+
+@@ -51,8 +56,6 @@ void xen_mc_flush(void)
+ local_irq_save(flags);
+
+ if (b->mcidx) {
+- int i;
+-
+ if (HYPERVISOR_multicall(b->entries, b->mcidx) != 0)
+ BUG();
+ for (i = 0; i < b->mcidx; i++)
+@@ -65,6 +68,13 @@ void xen_mc_flush(void)
+
+ local_irq_restore(flags);
+
++ for(i = 0; i < b->cbidx; i++) {
++ struct callback *cb = &b->callbacks[i];
++
++ (*cb->fn)(cb->data);
++ }
++ b->cbidx = 0;
++
+ BUG_ON(ret);
+ }
+
+@@ -88,3 +98,16 @@ struct multicall_space __xen_mc_entry(si
+
+ return ret;
+ }
++
++void xen_mc_callback(void (*fn)(void *), void *data)
++{
++ struct mc_buffer *b = &__get_cpu_var(mc_buffer);
++ struct callback *cb;
++
++ if (b->cbidx == MC_BATCH)
++ xen_mc_flush();
++
++ cb = &b->callbacks[b->cbidx++];
++ cb->fn = fn;
++ cb->data = data;
++}
+--- a/arch/i386/xen/multicalls.h
++++ b/arch/i386/xen/multicalls.h
+@@ -42,4 +42,7 @@ static inline void xen_mc_issue(unsigned
+ local_irq_restore(x86_read_percpu(xen_mc_irq_flags));
+ }
+
++/* Set up a callback to be called when the current batch is flushed */
++void xen_mc_callback(void (*fn)(void *), void *data);
++
+ #endif /* _XEN_MULTICALLS_H */
--- /dev/null
+From stable-bounces@linux.kernel.org Fri Oct 12 14:33:36 2007
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+Date: Fri, 12 Oct 2007 14:11:42 -0700
+Subject: xfs: eagerly remove vmap mappings to avoid upsetting Xen
+To: LKML <linux-kernel@vger.kernel.org>
+Cc: xen-devel@lists.xensource.com, virtualization@lists.osdl.org, Mark Williamson <mark.williamson@cl.cam.ac.uk>, XFS masters <xfs-masters@oss.sgi.com>, Chris Wright <chrisw@sous-sol.org>, Andi Kleen <ak@muc.de>, Morten Bøgeskov <xen-users@morten.bogeskov.dk>, Andrew Morton <akpm@linux-foundation.org>, Keir Fraser <keir@xensource.com>, Stable kernel <stable@kernel.org>
+Message-ID: <20071012211148.864500000@goop.org>
+Content-Disposition: inline; filename=xen-xfs-unmap.patch
+
+From: Jeremy Fitzhardinge <jeremy@goop.org>
+
+patch ace2e92e193126711cb3a83a3752b2c5b8396950 in mainline.
+
+XFS leaves stray mappings around when it vmaps memory to make it
+virtually contigious. This upsets Xen if one of those pages is being
+recycled into a pagetable, since it finds an extra writable mapping of
+the page.
+
+This patch solves the problem in a brute force way, by making XFS
+always eagerly unmap its mappings.
+
+[ Stable: This works around a bug in 2.6.23. We may come up with a
+better solution for mainline, but this seems like a low-impact fix for
+the stable kernel. ]
+
+Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
+Cc: XFS masters <xfs-masters@oss.sgi.com>
+Cc: Morten =?utf-8?q?B=C3=B8geskov?= <xen-users@morten.bogeskov.dk>
+Cc: Mark Williamson <mark.williamson@cl.cam.ac.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+
+---
+ fs/xfs/linux-2.6/xfs_buf.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/fs/xfs/linux-2.6/xfs_buf.c
++++ b/fs/xfs/linux-2.6/xfs_buf.c
+@@ -187,6 +187,19 @@ free_address(
+ {
+ a_list_t *aentry;
+
++#ifdef CONFIG_XEN
++ /*
++ * Xen needs to be able to make sure it can get an exclusive
++ * RO mapping of pages it wants to turn into a pagetable. If
++ * a newly allocated page is also still being vmap()ed by xfs,
++ * it will cause pagetable construction to fail. This is a
++ * quick workaround to always eagerly unmap pages so that Xen
++ * is happy.
++ */
++ vunmap(addr);
++ return;
++#endif
++
+ aentry = kmalloc(sizeof(a_list_t), GFP_NOWAIT);
+ if (likely(aentry)) {
+ spin_lock(&as_lock);
projects / thirdparty / kernel / stable-queue.git / commitdiff
