[34-longterm 000/196] v2.6.34.11 longterm review
Posted by Paul Gortmaker
|
Paul Gortmaker
[34-longterm 028/196] x86, mtrr, pat: Fix one cpu getting out of sync during resume March 13, 2012 02:20AM |
From: Suresh Siddha <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 84ac7cdbdd0f04df6b96153f7a79127fd6e45467 upstream.
On laptops with core i5/i7, there were reports that after resume
graphics workloads were performing poorly on a specific AP, while
the other cpu's were ok. This was observed on a 32bit kernel
specifically.
Debug showed that the PAT init was not happening on that AP
during resume and hence it contributing to the poor workload
performance on that cpu.
On this system, resume flow looked like this:
1. BP starts the resume sequence and we reinit BP's MTRR's/PAT
early on using mtrr_bp_restore()
2. Resume sequence brings all AP's online
3. Resume sequence now kicks off the MTRR reinit on all the AP's.
4. For some reason, between point 2 and 3, we moved from BP
to one of the AP's. My guess is that printk() during resume
sequence is contributing to this. We don't see similar
behavior with the 64bit kernel but there is no guarantee that
at this point the remaining resume sequence (after AP's bringup)
has to happen on BP.
5. set_mtrr() was assuming that we are still on BP and skipped the
MTRR/PAT init on that cpu (because of 1 above)
6. But we were on an AP and this led to not reprogramming PAT
on this cpu leading to bad performance.
Fix this by doing unconditional mtrr_if->set_all() in set_mtrr()
during MTRR/PAT init. This might be unnecessary if we are still
running on BP. But it is of no harm and will guarantee that after
resume, all the cpu's will be in sync with respect to the
MTRR/PAT registers.
Signed-off-by: Suresh Siddha <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Tested-by: Keith Packard <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
arch/x86/kernel/cpu/mtrr/main.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index e253288..34b4e2f 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -263,14 +263,24 @@ set_mtrr(unsigned int reg, unsigned long base, unsigned long size, mtrr_type typ
/*
* HACK!
- * We use this same function to initialize the mtrrs on boot.
- * The state of the boot cpu's mtrrs has been saved, and we want
- * to replicate across all the APs.
- * If we're doing that @reg is set to something special...
+ *
+ * We use this same function to initialize the mtrrs during boot,
+ * resume, runtime cpu online and on an explicit request to set a
+ * specific MTRR.
+ *
+ * During boot or suspend, the state of the boot cpu's mtrrs has been
+ * saved, and we want to replicate that across all the cpus that come
+ * online (either at the end of boot or resume or during a runtime cpu
+ * online). If we're doing that, @reg is set to something special and on
+ * this cpu we still do mtrr_if->set_all(). During boot/resume, this
+ * is unnecessary if at this point we are still on the cpu that started
+ * the boot/resume sequence. But there is no guarantee that we are still
+ * on the same cpu. So we do mtrr_if->set_all() on this cpu aswell to be
+ * sure that we are in sync with everyone else.
*/
if (reg != ~0U)
mtrr_if->set(reg, base, size, type);
- else if (!mtrr_aps_delayed_init)
+ else
mtrr_if->set_all();
/* Wait for the others */
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 84ac7cdbdd0f04df6b96153f7a79127fd6e45467 upstream.
On laptops with core i5/i7, there were reports that after resume
graphics workloads were performing poorly on a specific AP, while
the other cpu's were ok. This was observed on a 32bit kernel
specifically.
Debug showed that the PAT init was not happening on that AP
during resume and hence it contributing to the poor workload
performance on that cpu.
On this system, resume flow looked like this:
1. BP starts the resume sequence and we reinit BP's MTRR's/PAT
early on using mtrr_bp_restore()
2. Resume sequence brings all AP's online
3. Resume sequence now kicks off the MTRR reinit on all the AP's.
4. For some reason, between point 2 and 3, we moved from BP
to one of the AP's. My guess is that printk() during resume
sequence is contributing to this. We don't see similar
behavior with the 64bit kernel but there is no guarantee that
at this point the remaining resume sequence (after AP's bringup)
has to happen on BP.
5. set_mtrr() was assuming that we are still on BP and skipped the
MTRR/PAT init on that cpu (because of 1 above)
6. But we were on an AP and this led to not reprogramming PAT
on this cpu leading to bad performance.
Fix this by doing unconditional mtrr_if->set_all() in set_mtrr()
during MTRR/PAT init. This might be unnecessary if we are still
running on BP. But it is of no harm and will guarantee that after
resume, all the cpu's will be in sync with respect to the
MTRR/PAT registers.
Signed-off-by: Suresh Siddha <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Tested-by: Keith Packard <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
arch/x86/kernel/cpu/mtrr/main.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index e253288..34b4e2f 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -263,14 +263,24 @@ set_mtrr(unsigned int reg, unsigned long base, unsigned long size, mtrr_type typ
/*
* HACK!
- * We use this same function to initialize the mtrrs on boot.
- * The state of the boot cpu's mtrrs has been saved, and we want
- * to replicate across all the APs.
- * If we're doing that @reg is set to something special...
+ *
+ * We use this same function to initialize the mtrrs during boot,
+ * resume, runtime cpu online and on an explicit request to set a
+ * specific MTRR.
+ *
+ * During boot or suspend, the state of the boot cpu's mtrrs has been
+ * saved, and we want to replicate that across all the cpus that come
+ * online (either at the end of boot or resume or during a runtime cpu
+ * online). If we're doing that, @reg is set to something special and on
+ * this cpu we still do mtrr_if->set_all(). During boot/resume, this
+ * is unnecessary if at this point we are still on the cpu that started
+ * the boot/resume sequence. But there is no guarantee that we are still
+ * on the same cpu. So we do mtrr_if->set_all() on this cpu aswell to be
+ * sure that we are in sync with everyone else.
*/
if (reg != ~0U)
mtrr_if->set(reg, base, size, type);
- else if (!mtrr_aps_delayed_init)
+ else
mtrr_if->set_all();
/* Wait for the others */
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 025/196] ALSA: ens1371: fix Creative Ectiva support March 13, 2012 02:20AM |
From: Clemens Ladisch <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 6ebb8a4a43e34f999ab36f27f972f3cd751cda4f upstream.
To make the EV1938 chip work, add a magic bit and an extra delay.
Signed-off-by: Clemens Ladisch <[email protected]>
Tested-by: Tino Schmidt <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
sound/pci/ens1370.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c
index c7fba53..d6a40e2 100644
--- a/sound/pci/ens1370.c
+++ b/sound/pci/ens1370.c
@@ -229,6 +229,7 @@ MODULE_PARM_DESC(lineio, "Line In to Rear Out (0 = auto, 1 = force).");
#define ES_REG_1371_CODEC 0x14 /* W/R: Codec Read/Write register address */
#define ES_1371_CODEC_RDY (1<<31) /* codec ready */
#define ES_1371_CODEC_WIP (1<<30) /* codec register access in progress */
+#define EV_1938_CODEC_MAGIC (1<<26)
#define ES_1371_CODEC_PIRD (1<<23) /* codec read/write select register */
#define ES_1371_CODEC_WRITE(a,d) ((((a)&0x7f)<<16)|(((d)&0xffff)<<0))
#define ES_1371_CODEC_READS(a) ((((a)&0x7f)<<16)|ES_1371_CODEC_PIRD)
@@ -603,12 +604,18 @@ static void snd_es1370_codec_write(struct snd_ak4531 *ak4531,
#ifdef CHIP1371
+static inline bool is_ev1938(struct ensoniq *ensoniq)
+{
+ return ensoniq->pci->device == 0x8938;
+}
+
static void snd_es1371_codec_write(struct snd_ac97 *ac97,
unsigned short reg, unsigned short val)
{
struct ensoniq *ensoniq = ac97->private_data;
- unsigned int t, x;
+ unsigned int t, x, flag;
+ flag = is_ev1938(ensoniq) ? EV_1938_CODEC_MAGIC : 0;
mutex_lock(&ensoniq->src_mutex);
for (t = 0; t < POLL_COUNT; t++) {
if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP)) {
@@ -630,7 +637,8 @@ static void snd_es1371_codec_write(struct snd_ac97 *ac97,
0x00010000)
break;
}
- outl(ES_1371_CODEC_WRITE(reg, val), ES_REG(ensoniq, 1371_CODEC));
+ outl(ES_1371_CODEC_WRITE(reg, val) | flag,
+ ES_REG(ensoniq, 1371_CODEC));
/* restore SRC reg */
snd_es1371_wait_src_ready(ensoniq);
outl(x, ES_REG(ensoniq, 1371_SMPRATE));
@@ -647,8 +655,9 @@ static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
unsigned short reg)
{
struct ensoniq *ensoniq = ac97->private_data;
- unsigned int t, x, fail = 0;
+ unsigned int t, x, flag, fail = 0;
+ flag = is_ev1938(ensoniq) ? EV_1938_CODEC_MAGIC : 0;
__again:
mutex_lock(&ensoniq->src_mutex);
for (t = 0; t < POLL_COUNT; t++) {
@@ -671,7 +680,8 @@ static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
0x00010000)
break;
}
- outl(ES_1371_CODEC_READS(reg), ES_REG(ensoniq, 1371_CODEC));
+ outl(ES_1371_CODEC_READS(reg) | flag,
+ ES_REG(ensoniq, 1371_CODEC));
/* restore SRC reg */
snd_es1371_wait_src_ready(ensoniq);
outl(x, ES_REG(ensoniq, 1371_SMPRATE));
@@ -683,6 +693,11 @@ static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
/* now wait for the stinkin' data (RDY) */
for (t = 0; t < POLL_COUNT; t++) {
if ((x = inl(ES_REG(ensoniq, 1371_CODEC))) & ES_1371_CODEC_RDY) {
+ if (is_ev1938(ensoniq)) {
+ for (t = 0; t < 100; t++)
+ inl(ES_REG(ensoniq, CONTROL));
+ x = inl(ES_REG(ensoniq, 1371_CODEC));
+ }
mutex_unlock(&ensoniq->src_mutex);
return ES_1371_CODEC_READ(x);
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 6ebb8a4a43e34f999ab36f27f972f3cd751cda4f upstream.
To make the EV1938 chip work, add a magic bit and an extra delay.
Signed-off-by: Clemens Ladisch <[email protected]>
Tested-by: Tino Schmidt <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
sound/pci/ens1370.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/sound/pci/ens1370.c b/sound/pci/ens1370.c
index c7fba53..d6a40e2 100644
--- a/sound/pci/ens1370.c
+++ b/sound/pci/ens1370.c
@@ -229,6 +229,7 @@ MODULE_PARM_DESC(lineio, "Line In to Rear Out (0 = auto, 1 = force).");
#define ES_REG_1371_CODEC 0x14 /* W/R: Codec Read/Write register address */
#define ES_1371_CODEC_RDY (1<<31) /* codec ready */
#define ES_1371_CODEC_WIP (1<<30) /* codec register access in progress */
+#define EV_1938_CODEC_MAGIC (1<<26)
#define ES_1371_CODEC_PIRD (1<<23) /* codec read/write select register */
#define ES_1371_CODEC_WRITE(a,d) ((((a)&0x7f)<<16)|(((d)&0xffff)<<0))
#define ES_1371_CODEC_READS(a) ((((a)&0x7f)<<16)|ES_1371_CODEC_PIRD)
@@ -603,12 +604,18 @@ static void snd_es1370_codec_write(struct snd_ak4531 *ak4531,
#ifdef CHIP1371
+static inline bool is_ev1938(struct ensoniq *ensoniq)
+{
+ return ensoniq->pci->device == 0x8938;
+}
+
static void snd_es1371_codec_write(struct snd_ac97 *ac97,
unsigned short reg, unsigned short val)
{
struct ensoniq *ensoniq = ac97->private_data;
- unsigned int t, x;
+ unsigned int t, x, flag;
+ flag = is_ev1938(ensoniq) ? EV_1938_CODEC_MAGIC : 0;
mutex_lock(&ensoniq->src_mutex);
for (t = 0; t < POLL_COUNT; t++) {
if (!(inl(ES_REG(ensoniq, 1371_CODEC)) & ES_1371_CODEC_WIP)) {
@@ -630,7 +637,8 @@ static void snd_es1371_codec_write(struct snd_ac97 *ac97,
0x00010000)
break;
}
- outl(ES_1371_CODEC_WRITE(reg, val), ES_REG(ensoniq, 1371_CODEC));
+ outl(ES_1371_CODEC_WRITE(reg, val) | flag,
+ ES_REG(ensoniq, 1371_CODEC));
/* restore SRC reg */
snd_es1371_wait_src_ready(ensoniq);
outl(x, ES_REG(ensoniq, 1371_SMPRATE));
@@ -647,8 +655,9 @@ static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
unsigned short reg)
{
struct ensoniq *ensoniq = ac97->private_data;
- unsigned int t, x, fail = 0;
+ unsigned int t, x, flag, fail = 0;
+ flag = is_ev1938(ensoniq) ? EV_1938_CODEC_MAGIC : 0;
__again:
mutex_lock(&ensoniq->src_mutex);
for (t = 0; t < POLL_COUNT; t++) {
@@ -671,7 +680,8 @@ static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
0x00010000)
break;
}
- outl(ES_1371_CODEC_READS(reg), ES_REG(ensoniq, 1371_CODEC));
+ outl(ES_1371_CODEC_READS(reg) | flag,
+ ES_REG(ensoniq, 1371_CODEC));
/* restore SRC reg */
snd_es1371_wait_src_ready(ensoniq);
outl(x, ES_REG(ensoniq, 1371_SMPRATE));
@@ -683,6 +693,11 @@ static unsigned short snd_es1371_codec_read(struct snd_ac97 *ac97,
/* now wait for the stinkin' data (RDY) */
for (t = 0; t < POLL_COUNT; t++) {
if ((x = inl(ES_REG(ensoniq, 1371_CODEC))) & ES_1371_CODEC_RDY) {
+ if (is_ev1938(ensoniq)) {
+ for (t = 0; t < 100; t++)
+ inl(ES_REG(ensoniq, CONTROL));
+ x = inl(ES_REG(ensoniq, 1371_CODEC));
+ }
mutex_unlock(&ensoniq->src_mutex);
return ES_1371_CODEC_READ(x);
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 027/196] Btrfs: Fix uninitialized root flags for subvolumes March 13, 2012 02:20AM |
From: Li Zefan <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 08fe4db170b4193603d9d31f40ebaf652d07ac9c upstream.
root_item->flags and root_item->byte_limit are not initialized when
a subvolume is created. This bug is not revealed until we added
readonly snapshot support - now you mount a btrfs filesystem and you
may find the subvolumes in it are readonly.
To work around this problem, we steal a bit from root_item->inode_item->flags,
and use it to indicate if those fields have been properly initialized.
When we read a tree root from disk, we check if the bit is set, and if
not we'll set the flag and initialize the two fields of the root item.
Reported-by: Andreas Philipp <[email protected]>
Signed-off-by: Li Zefan <[email protected]>
Tested-by: Andreas Philipp <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
fs/btrfs/ctree.h | 4 ++++
fs/btrfs/disk-io.c | 4 +++-
fs/btrfs/ioctl.c | 4 ++++
fs/btrfs/root-tree.c | 18 ++++++++++++++++++
fs/btrfs/transaction.c | 1 +
5 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 746a724..a79a910 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1184,6 +1184,8 @@ struct btrfs_root {
#define BTRFS_INODE_NOATIME (1 << 9)
#define BTRFS_INODE_DIRSYNC (1 << 10)
+#define BTRFS_INODE_ROOT_ITEM_INIT (1 << 31)
+
/* some macros to generate set/get funcs for the struct fields. This
* assumes there is a lefoo_to_cpu for every type, so lets make a simple
* one for u8:
@@ -2185,6 +2187,8 @@ int btrfs_find_dead_roots(struct btrfs_root *root, u64 objectid);
int btrfs_find_orphan_roots(struct btrfs_root *tree_root);
int btrfs_set_root_node(struct btrfs_root_item *item,
struct extent_buffer *node);
+void btrfs_check_and_init_root_item(struct btrfs_root_item *item);
+
/* dir-item.c */
int btrfs_insert_dir_item(struct btrfs_trans_handle *trans,
struct btrfs_root *root, const char *name,
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index feca041..fa46c2d 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1146,8 +1146,10 @@ struct btrfs_root *btrfs_read_fs_root_no_radix(struct btrfs_root *tree_root,
root->commit_root = btrfs_root_node(root);
BUG_ON(!root->node);
out:
- if (location->objectid != BTRFS_TREE_LOG_OBJECTID)
+ if (location->objectid != BTRFS_TREE_LOG_OBJECTID) {
root->ref_cows = 1;
+ btrfs_check_and_init_root_item(&root->root_item);
+ }
return root;
}
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index e9d0535..e624555 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -286,6 +286,10 @@ static noinline int create_subvol(struct btrfs_root *root,
inode_item->nbytes = cpu_to_le64(root->leafsize);
inode_item->mode = cpu_to_le32(S_IFDIR | 0755);
+ root_item.flags = 0;
+ root_item.byte_limit = 0;
+ inode_item->flags = cpu_to_le64(BTRFS_INODE_ROOT_ITEM_INIT);
+
btrfs_set_root_bytenr(&root_item, leaf->start);
btrfs_set_root_generation(&root_item, trans->transid);
btrfs_set_root_level(&root_item, 0);
diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
index 67fa2d2..3174255 100644
--- a/fs/btrfs/root-tree.c
+++ b/fs/btrfs/root-tree.c
@@ -459,3 +459,21 @@ again:
btrfs_free_path(path);
return 0;
}
+
+/*
+ * Old btrfs forgets to init root_item->flags and root_item->byte_limit
+ * for subvolumes. To work around this problem, we steal a bit from
+ * root_item->inode_item->flags, and use it to indicate if those fields
+ * have been properly initialized.
+ */
+void btrfs_check_and_init_root_item(struct btrfs_root_item *root_item)
+{
+ u64 inode_flags = le64_to_cpu(root_item->inode.flags);
+
+ if (!(inode_flags & BTRFS_INODE_ROOT_ITEM_INIT)) {
+ inode_flags |= BTRFS_INODE_ROOT_ITEM_INIT;
+ root_item->inode.flags = cpu_to_le64(inode_flags);
+ root_item->flags = 0;
+ root_item->byte_limit = 0;
+ }
+}
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 2cb1160..5110e70 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -805,6 +805,7 @@ static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans,
record_root_in_trans(trans, root);
btrfs_set_root_last_snapshot(&root->root_item, trans->transid);
memcpy(new_root_item, &root->root_item, sizeof(*new_root_item));
+ btrfs_check_and_init_root_item(new_root_item);
old = btrfs_lock_root_node(root);
btrfs_cow_block(trans, root, old, NULL, 0, &old);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 08fe4db170b4193603d9d31f40ebaf652d07ac9c upstream.
root_item->flags and root_item->byte_limit are not initialized when
a subvolume is created. This bug is not revealed until we added
readonly snapshot support - now you mount a btrfs filesystem and you
may find the subvolumes in it are readonly.
To work around this problem, we steal a bit from root_item->inode_item->flags,
and use it to indicate if those fields have been properly initialized.
When we read a tree root from disk, we check if the bit is set, and if
not we'll set the flag and initialize the two fields of the root item.
Reported-by: Andreas Philipp <[email protected]>
Signed-off-by: Li Zefan <[email protected]>
Tested-by: Andreas Philipp <[email protected]>
Signed-off-by: Chris Mason <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
fs/btrfs/ctree.h | 4 ++++
fs/btrfs/disk-io.c | 4 +++-
fs/btrfs/ioctl.c | 4 ++++
fs/btrfs/root-tree.c | 18 ++++++++++++++++++
fs/btrfs/transaction.c | 1 +
5 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 746a724..a79a910 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -1184,6 +1184,8 @@ struct btrfs_root {
#define BTRFS_INODE_NOATIME (1 << 9)
#define BTRFS_INODE_DIRSYNC (1 << 10)
+#define BTRFS_INODE_ROOT_ITEM_INIT (1 << 31)
+
/* some macros to generate set/get funcs for the struct fields. This
* assumes there is a lefoo_to_cpu for every type, so lets make a simple
* one for u8:
@@ -2185,6 +2187,8 @@ int btrfs_find_dead_roots(struct btrfs_root *root, u64 objectid);
int btrfs_find_orphan_roots(struct btrfs_root *tree_root);
int btrfs_set_root_node(struct btrfs_root_item *item,
struct extent_buffer *node);
+void btrfs_check_and_init_root_item(struct btrfs_root_item *item);
+
/* dir-item.c */
int btrfs_insert_dir_item(struct btrfs_trans_handle *trans,
struct btrfs_root *root, const char *name,
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index feca041..fa46c2d 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1146,8 +1146,10 @@ struct btrfs_root *btrfs_read_fs_root_no_radix(struct btrfs_root *tree_root,
root->commit_root = btrfs_root_node(root);
BUG_ON(!root->node);
out:
- if (location->objectid != BTRFS_TREE_LOG_OBJECTID)
+ if (location->objectid != BTRFS_TREE_LOG_OBJECTID) {
root->ref_cows = 1;
+ btrfs_check_and_init_root_item(&root->root_item);
+ }
return root;
}
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index e9d0535..e624555 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -286,6 +286,10 @@ static noinline int create_subvol(struct btrfs_root *root,
inode_item->nbytes = cpu_to_le64(root->leafsize);
inode_item->mode = cpu_to_le32(S_IFDIR | 0755);
+ root_item.flags = 0;
+ root_item.byte_limit = 0;
+ inode_item->flags = cpu_to_le64(BTRFS_INODE_ROOT_ITEM_INIT);
+
btrfs_set_root_bytenr(&root_item, leaf->start);
btrfs_set_root_generation(&root_item, trans->transid);
btrfs_set_root_level(&root_item, 0);
diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
index 67fa2d2..3174255 100644
--- a/fs/btrfs/root-tree.c
+++ b/fs/btrfs/root-tree.c
@@ -459,3 +459,21 @@ again:
btrfs_free_path(path);
return 0;
}
+
+/*
+ * Old btrfs forgets to init root_item->flags and root_item->byte_limit
+ * for subvolumes. To work around this problem, we steal a bit from
+ * root_item->inode_item->flags, and use it to indicate if those fields
+ * have been properly initialized.
+ */
+void btrfs_check_and_init_root_item(struct btrfs_root_item *root_item)
+{
+ u64 inode_flags = le64_to_cpu(root_item->inode.flags);
+
+ if (!(inode_flags & BTRFS_INODE_ROOT_ITEM_INIT)) {
+ inode_flags |= BTRFS_INODE_ROOT_ITEM_INIT;
+ root_item->inode.flags = cpu_to_le64(inode_flags);
+ root_item->flags = 0;
+ root_item->byte_limit = 0;
+ }
+}
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 2cb1160..5110e70 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -805,6 +805,7 @@ static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans,
record_root_in_trans(trans, root);
btrfs_set_root_last_snapshot(&root->root_item, trans->transid);
memcpy(new_root_item, &root->root_item, sizeof(*new_root_item));
+ btrfs_check_and_init_root_item(new_root_item);
old = btrfs_lock_root_node(root);
btrfs_cow_block(trans, root, old, NULL, 0, &old);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 018/196] staging: usbip: bugfix for isochronous packets and optimization March 13, 2012 02:20AM |
From: Arjan Mels <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 28276a28d8b3cd19f4449991faad4945fe557656 upstream.
For isochronous packets the actual_length is the sum of the actual
length of each of the packets, however between the packets might be
padding, so it is not sufficient to just send the first actual_length
bytes of the buffer. To fix this and simultanesouly optimize the
bandwidth the content of the isochronous packets are send without the
padding, the padding is restored on the receiving end.
Signed-off-by: Arjan Mels <[email protected]>
Cc: Takahiro Hirofuchi <[email protected]>
Cc: Max Vozeler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/staging/usbip/stub_tx.c | 74 +++++++++++++++++++++++++++-------
drivers/staging/usbip/usbip_common.c | 57 ++++++++++++++++++++++++++
drivers/staging/usbip/usbip_common.h | 2 +
drivers/staging/usbip/vhci_rx.c | 3 ++
4 files changed, 122 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/usbip/stub_tx.c b/drivers/staging/usbip/stub_tx.c
index d7136e2..b7a493c 100644
--- a/drivers/staging/usbip/stub_tx.c
+++ b/drivers/staging/usbip/stub_tx.c
@@ -169,7 +169,6 @@ static int stub_send_ret_submit(struct stub_device *sdev)
struct stub_priv *priv, *tmp;
struct msghdr msg;
- struct kvec iov[3];
size_t txsize;
size_t total_size = 0;
@@ -179,28 +178,73 @@ static int stub_send_ret_submit(struct stub_device *sdev)
struct urb *urb = priv->urb;
struct usbip_header pdu_header;
void *iso_buffer = NULL;
+ struct kvec *iov = NULL;
+ int iovnum = 0;
txsize = 0;
memset(&pdu_header, 0, sizeof(pdu_header));
memset(&msg, 0, sizeof(msg));
- memset(&iov, 0, sizeof(iov));
- usbip_dbg_stub_tx("setup txdata urb %p\n", urb);
+ if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
+ iovnum = 2 + urb->number_of_packets;
+ else
+ iovnum = 2;
+
+ iov = kzalloc(iovnum * sizeof(struct kvec), GFP_KERNEL);
+ if (!iov) {
+ usbip_event_add(&sdev->ud, SDEV_EVENT_ERROR_MALLOC);
+ return -1;
+ }
+
+ iovnum = 0;
/* 1. setup usbip_header */
setup_ret_submit_pdu(&pdu_header, urb);
+ usbip_dbg_stub_tx("setup txdata seqnum: %d urb: %p\n",
+ pdu_header.base.seqnum, urb);
+ /*usbip_dump_header(pdu_header);*/
usbip_header_correct_endian(&pdu_header, 1);
- iov[0].iov_base = &pdu_header;
- iov[0].iov_len = sizeof(pdu_header);
+ iov[iovnum].iov_base = &pdu_header;
+ iov[iovnum].iov_len = sizeof(pdu_header);
+ iovnum++;
txsize += sizeof(pdu_header);
/* 2. setup transfer buffer */
- if (usb_pipein(urb->pipe) && urb->actual_length > 0) {
- iov[1].iov_base = urb->transfer_buffer;
- iov[1].iov_len = urb->actual_length;
+ if (usb_pipein(urb->pipe) &&
+ usb_pipetype(urb->pipe) != PIPE_ISOCHRONOUS &&
+ urb->actual_length > 0) {
+ iov[iovnum].iov_base = urb->transfer_buffer;
+ iov[iovnum].iov_len = urb->actual_length;
+ iovnum++;
txsize += urb->actual_length;
+ } else if (usb_pipein(urb->pipe) &&
+ usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS) {
+ /*
+ * For isochronous packets: actual length is the sum of
+ * the actual length of the individual, packets, but as
+ * the packet offsets are not changed there will be
+ * padding between the packets. To optimally use the
+ * bandwidth the padding is not transmitted.
+ */
+
+ int i;
+ for (i = 0; i < urb->number_of_packets; i++) {
+ iov[iovnum].iov_base = urb->transfer_buffer + urb->iso_frame_desc.offset;
+ iov[iovnum].iov_len = urb->iso_frame_desc.actual_length;
+ iovnum++;
+ txsize += urb->iso_frame_desc.actual_length;
+ }
+
+ if (txsize != sizeof(pdu_header) + urb->actual_length) {
+ dev_err(&sdev->interface->dev,
+ "actual length of urb (%d) does not match iso packet sizes (%d)\n",
+ urb->actual_length, txsize-sizeof(pdu_header));
+ kfree(iov);
+ usbip_event_add(&sdev->ud, SDEV_EVENT_ERROR_TCP);
+ return -1;
+ }
}
/* 3. setup iso_packet_descriptor */
@@ -211,32 +255,34 @@ static int stub_send_ret_submit(struct stub_device *sdev)
if (!iso_buffer) {
usbip_event_add(&sdev->ud,
SDEV_EVENT_ERROR_MALLOC);
+ kfree(iov);
return -1;
}
- iov[2].iov_base = iso_buffer;
- iov[2].iov_len = len;
+ iov[iovnum].iov_base = iso_buffer;
+ iov[iovnum].iov_len = len;
txsize += len;
+ iovnum++;
}
- ret = kernel_sendmsg(sdev->ud.tcp_socket, &msg, iov,
- 3, txsize);
+ ret = kernel_sendmsg(sdev->ud.tcp_socket, &msg,
+ iov, iovnum, txsize);
if (ret != txsize) {
dev_err(&sdev->interface->dev,
"sendmsg failed!, retval %d for %zd\n",
ret, txsize);
+ kfree(iov);
kfree(iso_buffer);
usbip_event_add(&sdev->ud, SDEV_EVENT_ERROR_TCP);
return -1;
}
+ kfree(iov);
kfree(iso_buffer);
- usbip_dbg_stub_tx("send txdata\n");
total_size += txsize;
}
-
spin_lock_irqsave(&sdev->priv_lock, flags);
list_for_each_entry_safe(priv, tmp, &sdev->priv_free, list) {
diff --git a/drivers/staging/usbip/usbip_common.c b/drivers/staging/usbip/usbip_common.c
index 4d0eb92..707b57d 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -815,6 +815,7 @@ int usbip_recv_iso(struct usbip_device *ud, struct urb *urb)
int size = np * sizeof(*iso);
int i;
int ret;
+ int total_length = 0;
if (!usb_pipeisoc(urb->pipe))
return 0;
@@ -844,19 +845,75 @@ int usbip_recv_iso(struct usbip_device *ud, struct urb *urb)
return -EPIPE;
}
+
for (i = 0; i < np; i++) {
iso = buff + (i * sizeof(*iso));
usbip_iso_pakcet_correct_endian(iso, 0);
usbip_pack_iso(iso, &urb->iso_frame_desc, 0);
+ total_length += urb->iso_frame_desc.actual_length;
}
kfree(buff);
+ if (total_length != urb->actual_length) {
+ dev_err(&urb->dev->dev,
+ "total length of iso packets (%d) not equal to actual length of buffer (%d)\n",
+ total_length, urb->actual_length);
+
+ if (ud->side == USBIP_STUB)
+ usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
+ else
+ usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
+
+ return -EPIPE;
+ }
+
return ret;
}
EXPORT_SYMBOL_GPL(usbip_recv_iso);
+/*
+ * This functions restores the padding which was removed for optimizing
+ * the bandwidth during transfer over tcp/ip
+ *
+ * buffer and iso packets need to be stored and be in propeper endian in urb
+ * before calling this function
+ */
+int usbip_pad_iso(struct usbip_device *ud, struct urb *urb)
+{
+ int np = urb->number_of_packets;
+ int i;
+ int ret;
+ int actualoffset = urb->actual_length;
+
+ if (!usb_pipeisoc(urb->pipe))
+ return 0;
+
+ /* if no packets or length of data is 0, then nothing to unpack */
+ if (np == 0 || urb->actual_length == 0)
+ return 0;
+
+ /*
+ * if actual_length is transfer_buffer_length then no padding is
+ * present.
+ */
+ if (urb->actual_length == urb->transfer_buffer_length)
+ return 0;
+
+ /*
+ * loop over all packets from last to first (to prevent overwritting
+ * memory when padding) and move them into the proper place
+ */
+ for (i = np-1; i > 0; i--) {
+ actualoffset -= urb->iso_frame_desc.actual_length;
+ memmove(urb->transfer_buffer + urb->iso_frame_desc.offset,
+ urb->transfer_buffer + actualoffset,
+ urb->iso_frame_desc.actual_length);
+ }
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usbip_pad_iso);
/* some members of urb must be substituted before. */
int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb)
diff --git a/drivers/staging/usbip/usbip_common.h b/drivers/staging/usbip/usbip_common.h
index 6f1dcb1..c7c6c81 100644
--- a/drivers/staging/usbip/usbip_common.h
+++ b/drivers/staging/usbip/usbip_common.h
@@ -393,6 +393,8 @@ void usbip_header_correct_endian(struct usbip_header *pdu, int send);
int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb);
/* some members of urb must be substituted before. */
int usbip_recv_iso(struct usbip_device *ud, struct urb *urb);
+/* some members of urb must be substituted before. */
+int usbip_pad_iso(struct usbip_device *ud, struct urb *urb);
void *usbip_alloc_iso_desc_pdu(struct urb *urb, ssize_t *bufflen);
diff --git a/drivers/staging/usbip/vhci_rx.c b/drivers/staging/usbip/vhci_rx.c
index bdbedd2..a1ac1b8 100644
--- a/drivers/staging/usbip/vhci_rx.c
+++ b/drivers/staging/usbip/vhci_rx.c
@@ -99,6 +99,9 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev,
if (usbip_recv_iso(ud, urb) < 0)
return;
+ /* restore the padding in iso packets */
+ if (usbip_pad_iso(ud, urb) < 0)
+ return;
if (usbip_dbg_flag_vhci_rx)
usbip_dump_urb(urb);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 28276a28d8b3cd19f4449991faad4945fe557656 upstream.
For isochronous packets the actual_length is the sum of the actual
length of each of the packets, however between the packets might be
padding, so it is not sufficient to just send the first actual_length
bytes of the buffer. To fix this and simultanesouly optimize the
bandwidth the content of the isochronous packets are send without the
padding, the padding is restored on the receiving end.
Signed-off-by: Arjan Mels <[email protected]>
Cc: Takahiro Hirofuchi <[email protected]>
Cc: Max Vozeler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/staging/usbip/stub_tx.c | 74 +++++++++++++++++++++++++++-------
drivers/staging/usbip/usbip_common.c | 57 ++++++++++++++++++++++++++
drivers/staging/usbip/usbip_common.h | 2 +
drivers/staging/usbip/vhci_rx.c | 3 ++
4 files changed, 122 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/usbip/stub_tx.c b/drivers/staging/usbip/stub_tx.c
index d7136e2..b7a493c 100644
--- a/drivers/staging/usbip/stub_tx.c
+++ b/drivers/staging/usbip/stub_tx.c
@@ -169,7 +169,6 @@ static int stub_send_ret_submit(struct stub_device *sdev)
struct stub_priv *priv, *tmp;
struct msghdr msg;
- struct kvec iov[3];
size_t txsize;
size_t total_size = 0;
@@ -179,28 +178,73 @@ static int stub_send_ret_submit(struct stub_device *sdev)
struct urb *urb = priv->urb;
struct usbip_header pdu_header;
void *iso_buffer = NULL;
+ struct kvec *iov = NULL;
+ int iovnum = 0;
txsize = 0;
memset(&pdu_header, 0, sizeof(pdu_header));
memset(&msg, 0, sizeof(msg));
- memset(&iov, 0, sizeof(iov));
- usbip_dbg_stub_tx("setup txdata urb %p\n", urb);
+ if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
+ iovnum = 2 + urb->number_of_packets;
+ else
+ iovnum = 2;
+
+ iov = kzalloc(iovnum * sizeof(struct kvec), GFP_KERNEL);
+ if (!iov) {
+ usbip_event_add(&sdev->ud, SDEV_EVENT_ERROR_MALLOC);
+ return -1;
+ }
+
+ iovnum = 0;
/* 1. setup usbip_header */
setup_ret_submit_pdu(&pdu_header, urb);
+ usbip_dbg_stub_tx("setup txdata seqnum: %d urb: %p\n",
+ pdu_header.base.seqnum, urb);
+ /*usbip_dump_header(pdu_header);*/
usbip_header_correct_endian(&pdu_header, 1);
- iov[0].iov_base = &pdu_header;
- iov[0].iov_len = sizeof(pdu_header);
+ iov[iovnum].iov_base = &pdu_header;
+ iov[iovnum].iov_len = sizeof(pdu_header);
+ iovnum++;
txsize += sizeof(pdu_header);
/* 2. setup transfer buffer */
- if (usb_pipein(urb->pipe) && urb->actual_length > 0) {
- iov[1].iov_base = urb->transfer_buffer;
- iov[1].iov_len = urb->actual_length;
+ if (usb_pipein(urb->pipe) &&
+ usb_pipetype(urb->pipe) != PIPE_ISOCHRONOUS &&
+ urb->actual_length > 0) {
+ iov[iovnum].iov_base = urb->transfer_buffer;
+ iov[iovnum].iov_len = urb->actual_length;
+ iovnum++;
txsize += urb->actual_length;
+ } else if (usb_pipein(urb->pipe) &&
+ usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS) {
+ /*
+ * For isochronous packets: actual length is the sum of
+ * the actual length of the individual, packets, but as
+ * the packet offsets are not changed there will be
+ * padding between the packets. To optimally use the
+ * bandwidth the padding is not transmitted.
+ */
+
+ int i;
+ for (i = 0; i < urb->number_of_packets; i++) {
+ iov[iovnum].iov_base = urb->transfer_buffer + urb->iso_frame_desc.offset;
+ iov[iovnum].iov_len = urb->iso_frame_desc.actual_length;
+ iovnum++;
+ txsize += urb->iso_frame_desc.actual_length;
+ }
+
+ if (txsize != sizeof(pdu_header) + urb->actual_length) {
+ dev_err(&sdev->interface->dev,
+ "actual length of urb (%d) does not match iso packet sizes (%d)\n",
+ urb->actual_length, txsize-sizeof(pdu_header));
+ kfree(iov);
+ usbip_event_add(&sdev->ud, SDEV_EVENT_ERROR_TCP);
+ return -1;
+ }
}
/* 3. setup iso_packet_descriptor */
@@ -211,32 +255,34 @@ static int stub_send_ret_submit(struct stub_device *sdev)
if (!iso_buffer) {
usbip_event_add(&sdev->ud,
SDEV_EVENT_ERROR_MALLOC);
+ kfree(iov);
return -1;
}
- iov[2].iov_base = iso_buffer;
- iov[2].iov_len = len;
+ iov[iovnum].iov_base = iso_buffer;
+ iov[iovnum].iov_len = len;
txsize += len;
+ iovnum++;
}
- ret = kernel_sendmsg(sdev->ud.tcp_socket, &msg, iov,
- 3, txsize);
+ ret = kernel_sendmsg(sdev->ud.tcp_socket, &msg,
+ iov, iovnum, txsize);
if (ret != txsize) {
dev_err(&sdev->interface->dev,
"sendmsg failed!, retval %d for %zd\n",
ret, txsize);
+ kfree(iov);
kfree(iso_buffer);
usbip_event_add(&sdev->ud, SDEV_EVENT_ERROR_TCP);
return -1;
}
+ kfree(iov);
kfree(iso_buffer);
- usbip_dbg_stub_tx("send txdata\n");
total_size += txsize;
}
-
spin_lock_irqsave(&sdev->priv_lock, flags);
list_for_each_entry_safe(priv, tmp, &sdev->priv_free, list) {
diff --git a/drivers/staging/usbip/usbip_common.c b/drivers/staging/usbip/usbip_common.c
index 4d0eb92..707b57d 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -815,6 +815,7 @@ int usbip_recv_iso(struct usbip_device *ud, struct urb *urb)
int size = np * sizeof(*iso);
int i;
int ret;
+ int total_length = 0;
if (!usb_pipeisoc(urb->pipe))
return 0;
@@ -844,19 +845,75 @@ int usbip_recv_iso(struct usbip_device *ud, struct urb *urb)
return -EPIPE;
}
+
for (i = 0; i < np; i++) {
iso = buff + (i * sizeof(*iso));
usbip_iso_pakcet_correct_endian(iso, 0);
usbip_pack_iso(iso, &urb->iso_frame_desc, 0);
+ total_length += urb->iso_frame_desc.actual_length;
}
kfree(buff);
+ if (total_length != urb->actual_length) {
+ dev_err(&urb->dev->dev,
+ "total length of iso packets (%d) not equal to actual length of buffer (%d)\n",
+ total_length, urb->actual_length);
+
+ if (ud->side == USBIP_STUB)
+ usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
+ else
+ usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
+
+ return -EPIPE;
+ }
+
return ret;
}
EXPORT_SYMBOL_GPL(usbip_recv_iso);
+/*
+ * This functions restores the padding which was removed for optimizing
+ * the bandwidth during transfer over tcp/ip
+ *
+ * buffer and iso packets need to be stored and be in propeper endian in urb
+ * before calling this function
+ */
+int usbip_pad_iso(struct usbip_device *ud, struct urb *urb)
+{
+ int np = urb->number_of_packets;
+ int i;
+ int ret;
+ int actualoffset = urb->actual_length;
+
+ if (!usb_pipeisoc(urb->pipe))
+ return 0;
+
+ /* if no packets or length of data is 0, then nothing to unpack */
+ if (np == 0 || urb->actual_length == 0)
+ return 0;
+
+ /*
+ * if actual_length is transfer_buffer_length then no padding is
+ * present.
+ */
+ if (urb->actual_length == urb->transfer_buffer_length)
+ return 0;
+
+ /*
+ * loop over all packets from last to first (to prevent overwritting
+ * memory when padding) and move them into the proper place
+ */
+ for (i = np-1; i > 0; i--) {
+ actualoffset -= urb->iso_frame_desc.actual_length;
+ memmove(urb->transfer_buffer + urb->iso_frame_desc.offset,
+ urb->transfer_buffer + actualoffset,
+ urb->iso_frame_desc.actual_length);
+ }
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usbip_pad_iso);
/* some members of urb must be substituted before. */
int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb)
diff --git a/drivers/staging/usbip/usbip_common.h b/drivers/staging/usbip/usbip_common.h
index 6f1dcb1..c7c6c81 100644
--- a/drivers/staging/usbip/usbip_common.h
+++ b/drivers/staging/usbip/usbip_common.h
@@ -393,6 +393,8 @@ void usbip_header_correct_endian(struct usbip_header *pdu, int send);
int usbip_recv_xbuff(struct usbip_device *ud, struct urb *urb);
/* some members of urb must be substituted before. */
int usbip_recv_iso(struct usbip_device *ud, struct urb *urb);
+/* some members of urb must be substituted before. */
+int usbip_pad_iso(struct usbip_device *ud, struct urb *urb);
void *usbip_alloc_iso_desc_pdu(struct urb *urb, ssize_t *bufflen);
diff --git a/drivers/staging/usbip/vhci_rx.c b/drivers/staging/usbip/vhci_rx.c
index bdbedd2..a1ac1b8 100644
--- a/drivers/staging/usbip/vhci_rx.c
+++ b/drivers/staging/usbip/vhci_rx.c
@@ -99,6 +99,9 @@ static void vhci_recv_ret_submit(struct vhci_device *vdev,
if (usbip_recv_iso(ud, urb) < 0)
return;
+ /* restore the padding in iso packets */
+ if (usbip_pad_iso(ud, urb) < 0)
+ return;
if (usbip_dbg_flag_vhci_rx)
usbip_dump_urb(urb);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 026/196] ROSE: prevent heap corruption with bad facilities March 13, 2012 02:20AM |
From: Dan Rosenberg <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit be20250c13f88375345ad99950190685eda51eb8 upstream.
When parsing the FAC_NATIONAL_DIGIS facilities field, it's possible for
a remote host to provide more digipeaters than expected, resulting in
heap corruption. Check against ROSE_MAX_DIGIS to prevent overflows, and
abort facilities parsing on failure.
Additionally, when parsing the FAC_CCITT_DEST_NSAP and
FAC_CCITT_SRC_NSAP facilities fields, a remote host can provide a length
of less than 10, resulting in an underflow in a memcpy size, causing a
kernel panic due to massive heap corruption. A length of greater than
20 results in a stack overflow of the callsign array. Abort facilities
parsing on these invalid length values.
Signed-off-by: Dan Rosenberg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
net/rose/rose_subr.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/rose/rose_subr.c b/net/rose/rose_subr.c
index 1734abb..174d51c 100644
--- a/net/rose/rose_subr.c
+++ b/net/rose/rose_subr.c
@@ -290,10 +290,15 @@ static int rose_parse_national(unsigned char *p, struct rose_facilities_struct *
facilities->source_ndigis = 0;
facilities->dest_ndigis = 0;
for (pt = p + 2, lg = 0 ; lg < l ; pt += AX25_ADDR_LEN, lg += AX25_ADDR_LEN) {
- if (pt[6] & AX25_HBIT)
+ if (pt[6] & AX25_HBIT) {
+ if (facilities->dest_ndigis >= ROSE_MAX_DIGIS)
+ return -1;
memcpy(&facilities->dest_digis[facilities->dest_ndigis++], pt, AX25_ADDR_LEN);
- else
+ } else {
+ if (facilities->source_ndigis >= ROSE_MAX_DIGIS)
+ return -1;
memcpy(&facilities->source_digis[facilities->source_ndigis++], pt, AX25_ADDR_LEN);
+ }
}
}
p += l + 2;
@@ -333,6 +338,11 @@ static int rose_parse_ccitt(unsigned char *p, struct rose_facilities_struct *fac
case 0xC0:
l = p[1];
+
+ /* Prevent overflows*/
+ if (l < 10 || l > 20)
+ return -1;
+
if (*p == FAC_CCITT_DEST_NSAP) {
memcpy(&facilities->source_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
@@ -373,12 +383,16 @@ int rose_parse_facilities(unsigned char *p,
switch (*p) {
case FAC_NATIONAL: /* National */
len = rose_parse_national(p + 1, facilities, facilities_len - 1);
+ if (len < 0)
+ return 0;
facilities_len -= len + 1;
p += len + 1;
break;
case FAC_CCITT: /* CCITT */
len = rose_parse_ccitt(p + 1, facilities, facilities_len - 1);
+ if (len < 0)
+ return 0;
facilities_len -= len + 1;
p += len + 1;
break;
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit be20250c13f88375345ad99950190685eda51eb8 upstream.
When parsing the FAC_NATIONAL_DIGIS facilities field, it's possible for
a remote host to provide more digipeaters than expected, resulting in
heap corruption. Check against ROSE_MAX_DIGIS to prevent overflows, and
abort facilities parsing on failure.
Additionally, when parsing the FAC_CCITT_DEST_NSAP and
FAC_CCITT_SRC_NSAP facilities fields, a remote host can provide a length
of less than 10, resulting in an underflow in a memcpy size, causing a
kernel panic due to massive heap corruption. A length of greater than
20 results in a stack overflow of the callsign array. Abort facilities
parsing on these invalid length values.
Signed-off-by: Dan Rosenberg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
net/rose/rose_subr.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/rose/rose_subr.c b/net/rose/rose_subr.c
index 1734abb..174d51c 100644
--- a/net/rose/rose_subr.c
+++ b/net/rose/rose_subr.c
@@ -290,10 +290,15 @@ static int rose_parse_national(unsigned char *p, struct rose_facilities_struct *
facilities->source_ndigis = 0;
facilities->dest_ndigis = 0;
for (pt = p + 2, lg = 0 ; lg < l ; pt += AX25_ADDR_LEN, lg += AX25_ADDR_LEN) {
- if (pt[6] & AX25_HBIT)
+ if (pt[6] & AX25_HBIT) {
+ if (facilities->dest_ndigis >= ROSE_MAX_DIGIS)
+ return -1;
memcpy(&facilities->dest_digis[facilities->dest_ndigis++], pt, AX25_ADDR_LEN);
- else
+ } else {
+ if (facilities->source_ndigis >= ROSE_MAX_DIGIS)
+ return -1;
memcpy(&facilities->source_digis[facilities->source_ndigis++], pt, AX25_ADDR_LEN);
+ }
}
}
p += l + 2;
@@ -333,6 +338,11 @@ static int rose_parse_ccitt(unsigned char *p, struct rose_facilities_struct *fac
case 0xC0:
l = p[1];
+
+ /* Prevent overflows*/
+ if (l < 10 || l > 20)
+ return -1;
+
if (*p == FAC_CCITT_DEST_NSAP) {
memcpy(&facilities->source_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
@@ -373,12 +383,16 @@ int rose_parse_facilities(unsigned char *p,
switch (*p) {
case FAC_NATIONAL: /* National */
len = rose_parse_national(p + 1, facilities, facilities_len - 1);
+ if (len < 0)
+ return 0;
facilities_len -= len + 1;
p += len + 1;
break;
case FAC_CCITT: /* CCITT */
len = rose_parse_ccitt(p + 1, facilities, facilities_len - 1);
+ if (len < 0)
+ return 0;
facilities_len -= len + 1;
p += len + 1;
break;
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 024/196] ASoC: Explicitly say registerless widgets have no register March 13, 2012 02:20AM |
From: Mark Brown <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 0ca03cd7d0fa3bfbd56958136a10f19733c4ce12 upstream.
This stops code that handles widgets generically from attempting to access
registers for these widgets.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
include/sound/soc-dapm.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index c0922a0..b93c659 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -46,25 +46,25 @@
/* platform domain */
#define SND_SOC_DAPM_INPUT(wname) \
{ .id = snd_soc_dapm_input, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0}
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM }
#define SND_SOC_DAPM_OUTPUT(wname) \
{ .id = snd_soc_dapm_output, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0}
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM }
#define SND_SOC_DAPM_MIC(wname, wevent) \
{ .id = snd_soc_dapm_mic, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD}
#define SND_SOC_DAPM_HP(wname, wevent) \
{ .id = snd_soc_dapm_hp, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD}
#define SND_SOC_DAPM_SPK(wname, wevent) \
{ .id = snd_soc_dapm_spk, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD}
#define SND_SOC_DAPM_LINE(wname, wevent) \
{ .id = snd_soc_dapm_line, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD}
/* path domain */
@@ -161,11 +161,11 @@
/* events that are pre and post DAPM */
#define SND_SOC_DAPM_PRE(wname, wevent) \
{ .id = snd_soc_dapm_pre, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_PRE_PMD}
#define SND_SOC_DAPM_POST(wname, wevent) \
{ .id = snd_soc_dapm_post, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD}
/* stream domain */
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 0ca03cd7d0fa3bfbd56958136a10f19733c4ce12 upstream.
This stops code that handles widgets generically from attempting to access
registers for these widgets.
Signed-off-by: Mark Brown <[email protected]>
Acked-by: Liam Girdwood <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
include/sound/soc-dapm.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index c0922a0..b93c659 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -46,25 +46,25 @@
/* platform domain */
#define SND_SOC_DAPM_INPUT(wname) \
{ .id = snd_soc_dapm_input, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0}
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM }
#define SND_SOC_DAPM_OUTPUT(wname) \
{ .id = snd_soc_dapm_output, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0}
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM }
#define SND_SOC_DAPM_MIC(wname, wevent) \
{ .id = snd_soc_dapm_mic, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD}
#define SND_SOC_DAPM_HP(wname, wevent) \
{ .id = snd_soc_dapm_hp, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD}
#define SND_SOC_DAPM_SPK(wname, wevent) \
{ .id = snd_soc_dapm_spk, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD}
#define SND_SOC_DAPM_LINE(wname, wevent) \
{ .id = snd_soc_dapm_line, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD}
/* path domain */
@@ -161,11 +161,11 @@
/* events that are pre and post DAPM */
#define SND_SOC_DAPM_PRE(wname, wevent) \
{ .id = snd_soc_dapm_pre, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_PRE_PMD}
#define SND_SOC_DAPM_POST(wname, wevent) \
{ .id = snd_soc_dapm_post, .name = wname, .kcontrols = NULL, \
- .num_kcontrols = 0, .event = wevent, \
+ .num_kcontrols = 0, .reg = SND_SOC_NOPM, .event = wevent, \
.event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD}
/* stream domain */
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 017/196] staging: usbip: bugfix add number of packets for isochronous frames March 13, 2012 02:20AM |
From: Arjan Mels <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 1325f85fa49f57df034869de430f7c302ae23109 upstream.
The number_of_packets was not transmitted for RET_SUBMIT packets. The
linux client used the stored number_of_packet from the submitted
request. The windows userland client does not do this however and needs
to know the number_of_packets to determine the size of the transmission.
Signed-off-by: Arjan Mels <[email protected]>
Cc: Takahiro Hirofuchi <[email protected]>
Cc: Max Vozeler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/staging/usbip/usbip_common.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/usbip_common.c b/drivers/staging/usbip/usbip_common.c
index e3fa421..4d0eb92 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -334,10 +334,11 @@ void usbip_dump_header(struct usbip_header *pdu)
usbip_udbg("CMD_UNLINK: seq %u\n", pdu->u.cmd_unlink.seqnum);
break;
case USBIP_RET_SUBMIT:
- usbip_udbg("RET_SUBMIT: st %d al %u sf %d ec %d\n",
+ usbip_udbg("RET_SUBMIT: st %d al %u sf %d #p %d ec %d\n",
pdu->u.ret_submit.status,
pdu->u.ret_submit.actual_length,
pdu->u.ret_submit.start_frame,
+ pdu->u.ret_submit.number_of_packets,
pdu->u.ret_submit.error_count);
case USBIP_RET_UNLINK:
usbip_udbg("RET_UNLINK: status %d\n", pdu->u.ret_unlink.status);
@@ -605,6 +606,7 @@ static void usbip_pack_ret_submit(struct usbip_header *pdu, struct urb *urb,
rpdu->status = urb->status;
rpdu->actual_length = urb->actual_length;
rpdu->start_frame = urb->start_frame;
+ rpdu->number_of_packets = urb->number_of_packets;
rpdu->error_count = urb->error_count;
} else {
/* vhci_rx.c */
@@ -612,6 +614,7 @@ static void usbip_pack_ret_submit(struct usbip_header *pdu, struct urb *urb,
urb->status = rpdu->status;
urb->actual_length = rpdu->actual_length;
urb->start_frame = rpdu->start_frame;
+ urb->number_of_packets = rpdu->number_of_packets;
urb->error_count = rpdu->error_count;
}
}
@@ -680,11 +683,13 @@ static void correct_endian_ret_submit(struct usbip_header_ret_submit *pdu,
cpu_to_be32s(&pdu->status);
cpu_to_be32s(&pdu->actual_length);
cpu_to_be32s(&pdu->start_frame);
+ cpu_to_be32s(&pdu->number_of_packets);
cpu_to_be32s(&pdu->error_count);
} else {
be32_to_cpus(&pdu->status);
be32_to_cpus(&pdu->actual_length);
be32_to_cpus(&pdu->start_frame);
+ cpu_to_be32s(&pdu->number_of_packets);
be32_to_cpus(&pdu->error_count);
}
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 1325f85fa49f57df034869de430f7c302ae23109 upstream.
The number_of_packets was not transmitted for RET_SUBMIT packets. The
linux client used the stored number_of_packet from the submitted
request. The windows userland client does not do this however and needs
to know the number_of_packets to determine the size of the transmission.
Signed-off-by: Arjan Mels <[email protected]>
Cc: Takahiro Hirofuchi <[email protected]>
Cc: Max Vozeler <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/staging/usbip/usbip_common.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/usbip_common.c b/drivers/staging/usbip/usbip_common.c
index e3fa421..4d0eb92 100644
--- a/drivers/staging/usbip/usbip_common.c
+++ b/drivers/staging/usbip/usbip_common.c
@@ -334,10 +334,11 @@ void usbip_dump_header(struct usbip_header *pdu)
usbip_udbg("CMD_UNLINK: seq %u\n", pdu->u.cmd_unlink.seqnum);
break;
case USBIP_RET_SUBMIT:
- usbip_udbg("RET_SUBMIT: st %d al %u sf %d ec %d\n",
+ usbip_udbg("RET_SUBMIT: st %d al %u sf %d #p %d ec %d\n",
pdu->u.ret_submit.status,
pdu->u.ret_submit.actual_length,
pdu->u.ret_submit.start_frame,
+ pdu->u.ret_submit.number_of_packets,
pdu->u.ret_submit.error_count);
case USBIP_RET_UNLINK:
usbip_udbg("RET_UNLINK: status %d\n", pdu->u.ret_unlink.status);
@@ -605,6 +606,7 @@ static void usbip_pack_ret_submit(struct usbip_header *pdu, struct urb *urb,
rpdu->status = urb->status;
rpdu->actual_length = urb->actual_length;
rpdu->start_frame = urb->start_frame;
+ rpdu->number_of_packets = urb->number_of_packets;
rpdu->error_count = urb->error_count;
} else {
/* vhci_rx.c */
@@ -612,6 +614,7 @@ static void usbip_pack_ret_submit(struct usbip_header *pdu, struct urb *urb,
urb->status = rpdu->status;
urb->actual_length = rpdu->actual_length;
urb->start_frame = rpdu->start_frame;
+ urb->number_of_packets = rpdu->number_of_packets;
urb->error_count = rpdu->error_count;
}
}
@@ -680,11 +683,13 @@ static void correct_endian_ret_submit(struct usbip_header_ret_submit *pdu,
cpu_to_be32s(&pdu->status);
cpu_to_be32s(&pdu->actual_length);
cpu_to_be32s(&pdu->start_frame);
+ cpu_to_be32s(&pdu->number_of_packets);
cpu_to_be32s(&pdu->error_count);
} else {
be32_to_cpus(&pdu->status);
be32_to_cpus(&pdu->actual_length);
be32_to_cpus(&pdu->start_frame);
+ cpu_to_be32s(&pdu->number_of_packets);
be32_to_cpus(&pdu->error_count);
}
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 011/196] mac80211: initialize sta->last_rx in sta_info_alloc March 13, 2012 02:20AM |
From: Felix Fietkau <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 8bc8aecdc5e26cfda12dbd6867af4aa67836da6a upstream.
This field is used to determine the inactivity time. When in AP mode,
hostapd uses it for kicking out inactive clients after a while. Without this
patch, hostapd immediately deauthenticates a new client if it checks the
inactivity time before the client sends its first data frame.
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
net/mac80211/sta_info.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index fb12cec..8899c78 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -239,6 +239,7 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
memcpy(sta->sta.addr, addr, ETH_ALEN);
sta->local = local;
sta->sdata = sdata;
+ sta->last_rx = jiffies;
if (sta_prepare_rate_control(local, sta, gfp)) {
kfree(sta);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 8bc8aecdc5e26cfda12dbd6867af4aa67836da6a upstream.
This field is used to determine the inactivity time. When in AP mode,
hostapd uses it for kicking out inactive clients after a while. Without this
patch, hostapd immediately deauthenticates a new client if it checks the
inactivity time before the client sends its first data frame.
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
net/mac80211/sta_info.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index fb12cec..8899c78 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -239,6 +239,7 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
memcpy(sta->sta.addr, addr, ETH_ALEN);
sta->local = local;
sta->sdata = sdata;
+ sta->last_rx = jiffies;
if (sta_prepare_rate_control(local, sta, gfp)) {
kfree(sta);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 019/196] staging: hv: Fix GARP not sent after Quick Migration March 13, 2012 02:20AM |
From: Haiyang Zhang <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit c996edcf1c451b81740abbcca5257ed7e353fcc6 upstream.
After Quick Migration, the network is not immediately operational in the
current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, I added
another netif_notify_peers() into a scheduled work, otherwise GARP packet will
not be sent after quick migration, and cause network disconnection.
Thanks to Mike Surcouf <[email protected]> for reporting the bug and
testing the patch.
Reported-by: Mike Surcouf <[email protected]>
Tested-by: Mike Surcouf <[email protected]>
Signed-off-by: Haiyang Zhang <[email protected]>
Signed-off-by: Hank Janssen <[email protected]>
Signed-off-by: Abhishek Kane <[email protected]>
Signed-off-by: K. Y. Srinivasan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/staging/hv/netvsc_drv.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/hv/netvsc_drv.c b/drivers/staging/hv/netvsc_drv.c
index d6940f4..5d77f11 100644
--- a/drivers/staging/hv/netvsc_drv.c
+++ b/drivers/staging/hv/netvsc_drv.c
@@ -44,6 +44,7 @@ struct net_device_context {
/* point back to our device context */
struct vm_device *device_ctx;
struct net_device_stats stats;
+ struct work_struct work;
};
struct netvsc_driver_context {
@@ -274,6 +275,7 @@ static void netvsc_linkstatus_callback(struct hv_device *device_obj,
{
struct vm_device *device_ctx = to_vm_device(device_obj);
struct net_device *net = dev_get_drvdata(&device_ctx->device);
+ struct net_device_context *ndev_ctx;
DPRINT_ENTER(NETVSC_DRV);
@@ -287,6 +289,8 @@ static void netvsc_linkstatus_callback(struct hv_device *device_obj,
netif_carrier_on(net);
netif_wake_queue(net);
netif_notify_peers(net);
+ ndev_ctx = netdev_priv(net);
+ schedule_work(&ndev_ctx->work);
} else {
netif_carrier_off(net);
netif_stop_queue(net);
@@ -388,6 +392,25 @@ static const struct net_device_ops device_ops = {
.ndo_set_mac_address = eth_mac_addr,
};
+/*
+ * Send GARP packet to network peers after migrations.
+ * After Quick Migration, the network is not immediately operational in the
+ * current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, add
+ * another netif_notify_peers() into a scheduled work, otherwise GARP packet
+ * will not be sent after quick migration, and cause network disconnection.
+ */
+static void netvsc_send_garp(struct work_struct *w)
+{
+ struct net_device_context *ndev_ctx;
+ struct net_device *net;
+
+ msleep(20);
+ ndev_ctx = container_of(w, struct net_device_context, work);
+ net = dev_get_drvdata(&ndev_ctx->device_ctx->device);
+ netif_notify_peers(net);
+}
+
+
static int netvsc_probe(struct device *device)
{
struct driver_context *driver_ctx =
@@ -418,6 +441,7 @@ static int netvsc_probe(struct device *device)
net_device_ctx = netdev_priv(net);
net_device_ctx->device_ctx = device_ctx;
dev_set_drvdata(device, net);
+ INIT_WORK(&net_device_ctx->work, netvsc_send_garp);
/* Notify the netvsc driver of the new device */
ret = net_drv_obj->Base.OnDeviceAdd(device_obj, &device_info);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit c996edcf1c451b81740abbcca5257ed7e353fcc6 upstream.
After Quick Migration, the network is not immediately operational in the
current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, I added
another netif_notify_peers() into a scheduled work, otherwise GARP packet will
not be sent after quick migration, and cause network disconnection.
Thanks to Mike Surcouf <[email protected]> for reporting the bug and
testing the patch.
Reported-by: Mike Surcouf <[email protected]>
Tested-by: Mike Surcouf <[email protected]>
Signed-off-by: Haiyang Zhang <[email protected]>
Signed-off-by: Hank Janssen <[email protected]>
Signed-off-by: Abhishek Kane <[email protected]>
Signed-off-by: K. Y. Srinivasan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/staging/hv/netvsc_drv.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/hv/netvsc_drv.c b/drivers/staging/hv/netvsc_drv.c
index d6940f4..5d77f11 100644
--- a/drivers/staging/hv/netvsc_drv.c
+++ b/drivers/staging/hv/netvsc_drv.c
@@ -44,6 +44,7 @@ struct net_device_context {
/* point back to our device context */
struct vm_device *device_ctx;
struct net_device_stats stats;
+ struct work_struct work;
};
struct netvsc_driver_context {
@@ -274,6 +275,7 @@ static void netvsc_linkstatus_callback(struct hv_device *device_obj,
{
struct vm_device *device_ctx = to_vm_device(device_obj);
struct net_device *net = dev_get_drvdata(&device_ctx->device);
+ struct net_device_context *ndev_ctx;
DPRINT_ENTER(NETVSC_DRV);
@@ -287,6 +289,8 @@ static void netvsc_linkstatus_callback(struct hv_device *device_obj,
netif_carrier_on(net);
netif_wake_queue(net);
netif_notify_peers(net);
+ ndev_ctx = netdev_priv(net);
+ schedule_work(&ndev_ctx->work);
} else {
netif_carrier_off(net);
netif_stop_queue(net);
@@ -388,6 +392,25 @@ static const struct net_device_ops device_ops = {
.ndo_set_mac_address = eth_mac_addr,
};
+/*
+ * Send GARP packet to network peers after migrations.
+ * After Quick Migration, the network is not immediately operational in the
+ * current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, add
+ * another netif_notify_peers() into a scheduled work, otherwise GARP packet
+ * will not be sent after quick migration, and cause network disconnection.
+ */
+static void netvsc_send_garp(struct work_struct *w)
+{
+ struct net_device_context *ndev_ctx;
+ struct net_device *net;
+
+ msleep(20);
+ ndev_ctx = container_of(w, struct net_device_context, work);
+ net = dev_get_drvdata(&ndev_ctx->device_ctx->device);
+ netif_notify_peers(net);
+}
+
+
static int netvsc_probe(struct device *device)
{
struct driver_context *driver_ctx =
@@ -418,6 +441,7 @@ static int netvsc_probe(struct device *device)
net_device_ctx = netdev_priv(net);
net_device_ctx->device_ctx = device_ctx;
dev_set_drvdata(device, net);
+ INIT_WORK(&net_device_ctx->work, netvsc_send_garp);
/* Notify the netvsc driver of the new device */
ret = net_drv_obj->Base.OnDeviceAdd(device_obj, &device_info);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 012/196] ses: show devices for enclosures with no page 7 March 13, 2012 02:20AM |
From: John Hughes <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 877a55979c189c590e819a61cbbe2b7947875f17 upstream.
enclosure page 7 gives us the "pretty" names of the enclosure slots.
Without a page 7, we can still use the enclosure code as long as we
make up numeric names for the slots. Unfortunately, the current code
fails to add any devices because the check for page 10 is in the wrong
place if we have no page 7. Fix it so that devices show up even if
the enclosure has no page 7.
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/scsi/ses.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 7f5a6a8..3b00e90 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -390,9 +390,9 @@ static void ses_enclosure_data_process(struct enclosure_device *edev,
len = (desc_ptr[2] << 8) + desc_ptr[3];
/* skip past overall descriptor */
desc_ptr += len + 4;
- if (ses_dev->page10)
- addl_desc_ptr = ses_dev->page10 + 8;
}
+ if (ses_dev->page10)
+ addl_desc_ptr = ses_dev->page10 + 8;
type_ptr = ses_dev->page1 + 12 + ses_dev->page1[11];
components = 0;
for (i = 0; i < types; i++, type_ptr += 4) {
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 877a55979c189c590e819a61cbbe2b7947875f17 upstream.
enclosure page 7 gives us the "pretty" names of the enclosure slots.
Without a page 7, we can still use the enclosure code as long as we
make up numeric names for the slots. Unfortunately, the current code
fails to add any devices because the check for page 10 is in the wrong
place if we have no page 7. Fix it so that devices show up even if
the enclosure has no page 7.
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/scsi/ses.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 7f5a6a8..3b00e90 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -390,9 +390,9 @@ static void ses_enclosure_data_process(struct enclosure_device *edev,
len = (desc_ptr[2] << 8) + desc_ptr[3];
/* skip past overall descriptor */
desc_ptr += len + 4;
- if (ses_dev->page10)
- addl_desc_ptr = ses_dev->page10 + 8;
}
+ if (ses_dev->page10)
+ addl_desc_ptr = ses_dev->page10 + 8;
type_ptr = ses_dev->page1 + 12 + ses_dev->page1[11];
components = 0;
for (i = 0; i < types; i++, type_ptr += 4) {
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 013/196] ses: Avoid kernel panic when lun 0 is not mapped March 13, 2012 02:20AM |
From: "Krishnasamy, Somasundaram" <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit d1e12de804f9d8ad114786ca7c2ce593cba79891 upstream.
During device discovery, scsi mid layer sends INQUIRY command to LUN
0. If the LUN 0 is not mapped to host, it creates a temporary
scsi_device with LUN id 0 and sends REPORT_LUNS command to it. After
the REPORT_LUNS succeeds, it walks through the LUN table and adds each
LUN found to sysfs. At the end of REPORT_LUNS lun table scan, it will
delete the temporary scsi_device of LUN 0.
When scsi devices are added to sysfs, it calls add_dev function of all
the registered class interfaces. If ses driver has been registered,
ses_intf_add() of ses module will be called. This function calls
scsi_device_enclosure() to check the inquiry data for EncServ
bit. Since inquiry was not allocated for temporary LUN 0 scsi_device,
it will cause NULL pointer exception.
To fix the problem, sdev->inquiry is checked for NULL before reading it.
Signed-off-by: Somasundaram Krishnasamy <[email protected]>
Signed-off-by: Babu Moger <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
include/scsi/scsi_device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index d80b6db..558fa2f 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -451,7 +451,7 @@ static inline int scsi_device_qas(struct scsi_device *sdev)
}
static inline int scsi_device_enclosure(struct scsi_device *sdev)
{
- return sdev->inquiry[6] & (1<<6);
+ return sdev->inquiry ? (sdev->inquiry[6] & (1<<6)) : 1;
}
static inline int scsi_device_protection(struct scsi_device *sdev)
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit d1e12de804f9d8ad114786ca7c2ce593cba79891 upstream.
During device discovery, scsi mid layer sends INQUIRY command to LUN
0. If the LUN 0 is not mapped to host, it creates a temporary
scsi_device with LUN id 0 and sends REPORT_LUNS command to it. After
the REPORT_LUNS succeeds, it walks through the LUN table and adds each
LUN found to sysfs. At the end of REPORT_LUNS lun table scan, it will
delete the temporary scsi_device of LUN 0.
When scsi devices are added to sysfs, it calls add_dev function of all
the registered class interfaces. If ses driver has been registered,
ses_intf_add() of ses module will be called. This function calls
scsi_device_enclosure() to check the inquiry data for EncServ
bit. Since inquiry was not allocated for temporary LUN 0 scsi_device,
it will cause NULL pointer exception.
To fix the problem, sdev->inquiry is checked for NULL before reading it.
Signed-off-by: Somasundaram Krishnasamy <[email protected]>
Signed-off-by: Babu Moger <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
include/scsi/scsi_device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index d80b6db..558fa2f 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -451,7 +451,7 @@ static inline int scsi_device_qas(struct scsi_device *sdev)
}
static inline int scsi_device_enclosure(struct scsi_device *sdev)
{
- return sdev->inquiry[6] & (1<<6);
+ return sdev->inquiry ? (sdev->inquiry[6] & (1<<6)) : 1;
}
static inline int scsi_device_protection(struct scsi_device *sdev)
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 014/196] eCryptfs: Unlock page in write_begin error path March 13, 2012 02:20AM |
From: Tyler Hicks <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 50f198ae16ac66508d4b8d5a40967a8507ad19ee upstream.
Unlock the page in error path of ecryptfs_write_begin(). This may
happen, for example, if decryption fails while bring the page
up-to-date.
Signed-off-by: Tyler Hicks <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
fs/ecryptfs/mmap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 2ee9a3a..eb1a0c9 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -377,6 +377,11 @@ static int ecryptfs_write_begin(struct file *file,
&& (pos != 0))
zero_user(page, 0, PAGE_CACHE_SIZE);
out:
+ if (unlikely(rc)) {
+ unlock_page(page);
+ page_cache_release(page);
+ *pagep = NULL;
+ }
return rc;
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 50f198ae16ac66508d4b8d5a40967a8507ad19ee upstream.
Unlock the page in error path of ecryptfs_write_begin(). This may
happen, for example, if decryption fails while bring the page
up-to-date.
Signed-off-by: Tyler Hicks <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
fs/ecryptfs/mmap.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 2ee9a3a..eb1a0c9 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -377,6 +377,11 @@ static int ecryptfs_write_begin(struct file *file,
&& (pos != 0))
zero_user(page, 0, PAGE_CACHE_SIZE);
out:
+ if (unlikely(rc)) {
+ unlock_page(page);
+ page_cache_release(page);
+ *pagep = NULL;
+ }
return rc;
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 010/196] sound/oss/opl3: validate voice and channel indexes March 13, 2012 02:20AM |
From: Dan Rosenberg <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 4d00135a680727f6c3be78f8befaac009030e4df upstream.
User-controllable indexes for voice and channel values may cause reading
and writing beyond the bounds of their respective arrays, leading to
potentially exploitable memory corruption. Validate these indexes.
Signed-off-by: Dan Rosenberg <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
sound/oss/opl3.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/sound/oss/opl3.c b/sound/oss/opl3.c
index 938c48c..f4ffdff 100644
--- a/sound/oss/opl3.c
+++ b/sound/oss/opl3.c
@@ -849,6 +849,10 @@ static int opl3_load_patch(int dev, int format, const char __user *addr,
static void opl3_panning(int dev, int voice, int value)
{
+
+ if (voice < 0 || voice >= devc->nr_voice)
+ return;
+
devc->voc[voice].panning = value;
}
@@ -1066,8 +1070,15 @@ static int opl3_alloc_voice(int dev, int chn, int note, struct voice_alloc_info
static void opl3_setup_voice(int dev, int voice, int chn)
{
- struct channel_info *info =
- &synth_devs[dev]->chn_info[chn];
+ struct channel_info *info;
+
+ if (voice < 0 || voice >= devc->nr_voice)
+ return;
+
+ if (chn < 0 || chn > 15)
+ return;
+
+ info = &synth_devs[dev]->chn_info[chn];
opl3_set_instr(dev, voice, info->pgm_num);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit 4d00135a680727f6c3be78f8befaac009030e4df upstream.
User-controllable indexes for voice and channel values may cause reading
and writing beyond the bounds of their respective arrays, leading to
potentially exploitable memory corruption. Validate these indexes.
Signed-off-by: Dan Rosenberg <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
sound/oss/opl3.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/sound/oss/opl3.c b/sound/oss/opl3.c
index 938c48c..f4ffdff 100644
--- a/sound/oss/opl3.c
+++ b/sound/oss/opl3.c
@@ -849,6 +849,10 @@ static int opl3_load_patch(int dev, int format, const char __user *addr,
static void opl3_panning(int dev, int voice, int value)
{
+
+ if (voice < 0 || voice >= devc->nr_voice)
+ return;
+
devc->voc[voice].panning = value;
}
@@ -1066,8 +1070,15 @@ static int opl3_alloc_voice(int dev, int chn, int note, struct voice_alloc_info
static void opl3_setup_voice(int dev, int voice, int chn)
{
- struct channel_info *info =
- &synth_devs[dev]->chn_info[chn];
+ struct channel_info *info;
+
+ if (voice < 0 || voice >= devc->nr_voice)
+ return;
+
+ if (chn < 0 || chn > 15)
+ return;
+
+ info = &synth_devs[dev]->chn_info[chn];
opl3_set_instr(dev, voice, info->pgm_num);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 008/196] myri10ge: fix rmmod crash March 13, 2012 02:20AM |
From: Stanislaw Gruszka <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit cda6587c21a887254c8ed4b58da8fcc4040ab557 upstream.
Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because napi
structures are already deallocated. To fix call netif_napi_del() before
kfree() at myri10ge_free_slices().
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/net/myri10ge/myri10ge.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index ecde087..649b8db6 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -3600,6 +3600,7 @@ static void myri10ge_free_slices(struct myri10ge_priv *mgp)
dma_free_coherent(&pdev->dev, bytes,
ss->fw_stats, ss->fw_stats_bus);
ss->fw_stats = NULL;
+ netif_napi_del(&ss->napi);
}
}
kfree(mgp->ss);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit cda6587c21a887254c8ed4b58da8fcc4040ab557 upstream.
Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because napi
structures are already deallocated. To fix call netif_napi_del() before
kfree() at myri10ge_free_slices().
Signed-off-by: Stanislaw Gruszka <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
drivers/net/myri10ge/myri10ge.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index ecde087..649b8db6 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -3600,6 +3600,7 @@ static void myri10ge_free_slices(struct myri10ge_priv *mgp)
dma_free_coherent(&pdev->dev, bytes,
ss->fw_stats, ss->fw_stats_bus);
ss->fw_stats = NULL;
+ netif_napi_del(&ss->napi);
}
}
kfree(mgp->ss);
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 004/196] aio: wake all waiters when destroying ctx March 13, 2012 02:20AM |
From: Roland Dreier <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit e91f90bb0bb10be9cc8efd09a3cf4ecffcad0db1 upstream.
The test program below will hang because io_getevents() uses
add_wait_next_round_exclusive(), which means the wake_up() in io_destroy() only
wakes up one of the threads. Fix this by using wake_up_all() in the aio
code paths where we want to make sure no one gets stuck.
// t.c -- compile with gcc -lpthread -laio t.c
#include <libaio.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static const int nthr = 2;
void *getev(void *ctx)
{
struct io_event ev;
io_getevents(ctx, 1, 1, &ev, NULL);
printf("io_getevents returned\n");
return NULL;
}
int main(int argc, char *argv[])
{
io_context_t ctx = 0;
pthread_t thread[nthr];
int i;
io_setup(1024, &ctx);
for (i = 0; i < nthr; ++i)
pthread_create(&thread, NULL, getev, ctx);
sleep(1);
io_destroy(ctx);
for (i = 0; i < nthr; ++i)
pthread_join(thread, NULL);
return 0;
}
Signed-off-by: Roland Dreier <[email protected]>
Reviewed-by: Jeff Moyer <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
fs/aio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 94b6cd6..2600146 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -512,7 +512,7 @@ static inline void really_put_req(struct kioctx *ctx, struct kiocb *req)
ctx->reqs_active--;
if (unlikely(!ctx->reqs_active && ctx->dead))
- wake_up(&ctx->wait);
+ wake_up_all(&ctx->wait);
}
static void aio_fput_routine(struct work_struct *data)
@@ -1225,7 +1225,7 @@ static void io_destroy(struct kioctx *ioctx)
* by other CPUs at this point. Right now, we rely on the
* locking done by the above calls to ensure this consistency.
*/
- wake_up(&ioctx->wait);
+ wake_up_all(&ioctx->wait);
put_ioctx(ioctx); /* once for the lookup */
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit e91f90bb0bb10be9cc8efd09a3cf4ecffcad0db1 upstream.
The test program below will hang because io_getevents() uses
add_wait_next_round_exclusive(), which means the wake_up() in io_destroy() only
wakes up one of the threads. Fix this by using wake_up_all() in the aio
code paths where we want to make sure no one gets stuck.
// t.c -- compile with gcc -lpthread -laio t.c
#include <libaio.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
static const int nthr = 2;
void *getev(void *ctx)
{
struct io_event ev;
io_getevents(ctx, 1, 1, &ev, NULL);
printf("io_getevents returned\n");
return NULL;
}
int main(int argc, char *argv[])
{
io_context_t ctx = 0;
pthread_t thread[nthr];
int i;
io_setup(1024, &ctx);
for (i = 0; i < nthr; ++i)
pthread_create(&thread, NULL, getev, ctx);
sleep(1);
io_destroy(ctx);
for (i = 0; i < nthr; ++i)
pthread_join(thread, NULL);
return 0;
}
Signed-off-by: Roland Dreier <[email protected]>
Reviewed-by: Jeff Moyer <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
fs/aio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 94b6cd6..2600146 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -512,7 +512,7 @@ static inline void really_put_req(struct kioctx *ctx, struct kiocb *req)
ctx->reqs_active--;
if (unlikely(!ctx->reqs_active && ctx->dead))
- wake_up(&ctx->wait);
+ wake_up_all(&ctx->wait);
}
static void aio_fput_routine(struct work_struct *data)
@@ -1225,7 +1225,7 @@ static void io_destroy(struct kioctx *ioctx)
* by other CPUs at this point. Right now, we rely on the
* locking done by the above calls to ensure this consistency.
*/
- wake_up(&ioctx->wait);
+ wake_up_all(&ioctx->wait);
put_ioctx(ioctx); /* once for the lookup */
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
[34-longterm 003/196] shmem: let shared anonymous be nonlinear again March 13, 2012 02:20AM |
From: Hugh Dickins <[email protected]>
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit bee4c36a5cf5c9f63ce1d7372aa62045fbd16d47 upstream.
Up to 2.6.22, you could use remap_file_pages(2) on a tmpfs file or a
shared mapping of /dev/zero or a shared anonymous mapping. In 2.6.23 we
disabled it by default, but set VM_CAN_NONLINEAR to enable it on safe
mappings. We made sure to set it in shmem_mmap() for tmpfs files, but
missed it in shmem_zero_setup() for the others. Fix that at last.
Reported-by: Kenny Simpson <[email protected]>
Signed-off-by: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
mm/shmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index eef4ebe..0203cda 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2701,5 +2701,6 @@ int shmem_zero_setup(struct vm_area_struct *vma)
fput(vma->vm_file);
vma->vm_file = file;
vma->vm_ops = &shmem_vm_ops;
+ vma->vm_flags |= VM_CAN_NONLINEAR;
return 0;
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-------------------
This is a commit scheduled for the next v2.6.34 longterm release.
If you see a problem with using this for longterm, please comment.
-------------------
commit bee4c36a5cf5c9f63ce1d7372aa62045fbd16d47 upstream.
Up to 2.6.22, you could use remap_file_pages(2) on a tmpfs file or a
shared mapping of /dev/zero or a shared anonymous mapping. In 2.6.23 we
disabled it by default, but set VM_CAN_NONLINEAR to enable it on safe
mappings. We made sure to set it in shmem_mmap() for tmpfs files, but
missed it in shmem_zero_setup() for the others. Fix that at last.
Reported-by: Kenny Simpson <[email protected]>
Signed-off-by: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Paul Gortmaker <[email protected]>
---
mm/shmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/shmem.c b/mm/shmem.c
index eef4ebe..0203cda 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2701,5 +2701,6 @@ int shmem_zero_setup(struct vm_area_struct *vma)
fput(vma->vm_file);
vma->vm_file = file;
vma->vm_ops = &shmem_vm_ops;
+ vma->vm_flags |= VM_CAN_NONLINEAR;
return 0;
}
--
1.7.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Olaf Hering
Re: [34-longterm 020/196] staging: hv: use sync_bitops when interacting with the hypervisor March 13, 2012 08:10AM |
On Mon, Mar 12, Paul Gortmaker wrote:
> From: Olaf Hering <[email protected]>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit 22356585712d1ff08fbfed152edd8b386873b238 upstream.
Unless there is a happy user of the hv drivers in this old kernel, it
makes no sense to backport just this one patch.
I suggest to leave drivers/staging/hv alone in longterm releases, or
backport the entire history of drivers/staging/hv up to 3.4.
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> From: Olaf Hering <[email protected]>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit 22356585712d1ff08fbfed152edd8b386873b238 upstream.
Unless there is a happy user of the hv drivers in this old kernel, it
makes no sense to backport just this one patch.
I suggest to leave drivers/staging/hv alone in longterm releases, or
backport the entire history of drivers/staging/hv up to 3.4.
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Stephane Eranian
Re: [34-longterm 007/196] perf: Better fit max unprivileged mlock pages for tools needs March 13, 2012 12:00PM |
On Tue, Mar 13, 2012 at 1:12 AM, Paul Gortmaker
<[email protected]> wrote:
> From: Frederic Weisbecker <[email protected]>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit 880f57318450dbead6a03f9e31a1468924d6dd88 upstream.
>
> The maximum kilobytes of locked memory that an unprivileged user
> can reserve is of 512 kB = 128 pages by default, scaled to the
> number of onlined CPUs, which fits well with the tools that use
> 128 data pages by default.
>
> However tools actually use 129 pages, because they need one more
> for the user control page. Thus the default mlock threshold is
> not sufficient for the default tools needs and we always end up
> to evaluate the constant mlock rlimit policy, which doesn't have
> this scaling with the number of online CPUs.
>
> Hence, on systems that have more than 16 CPUs, we overlap the
> rlimit threshold and fail to mmap:
>
> $ perf record ls
> Error: failed to mmap with 1 (Operation not permitted)
>
But isn't that simply coming from the fact that perf chose to request
128 pages by default? I don't know how this size was chosen. If perf
were to allocate 127 (data) pages, you would not have that problem
with the current default limit, would you?
> Just increase the max unprivileged mlock threshold by one page
> so that it supports well perf tools even after 16 CPUs.
>
> Reported-by: Han Pingtian <[email protected]>
> Reported-by: Peter Zijlstra <[email protected]>
> Reported-by: Arnaldo Carvalho de Melo <[email protected]>
> Signed-off-by: Frederic Weisbecker <[email protected]>
> Acked-by: Arnaldo Carvalho de Melo <[email protected]>
> Cc: Stephane Eranian <[email protected]>
> LKML-Reference: <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: Paul Gortmaker <[email protected]>
> ---
> kernel/perf_event.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/perf_event.c b/kernel/perf_event.c
> index 2357b19..b203546 100644
> --- a/kernel/perf_event.c
> +++ b/kernel/perf_event.c
> @@ -57,7 +57,8 @@ static atomic_t nr_task_events __read_mostly;
> */
> int sysctl_perf_event_paranoid __read_mostly = 1;
>
> -int sysctl_perf_event_mlock __read_mostly = 512; /* 'free' kb per user */
> +/* Minimum for 128 pages + 1 for the user control page */
> +int sysctl_perf_event_mlock __read_mostly = 516; /* 'free' kb per user */
>
> /*
> * max perf event sample rate
> --
> 1.7.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
<[email protected]> wrote:
> From: Frederic Weisbecker <[email protected]>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit 880f57318450dbead6a03f9e31a1468924d6dd88 upstream.
>
> The maximum kilobytes of locked memory that an unprivileged user
> can reserve is of 512 kB = 128 pages by default, scaled to the
> number of onlined CPUs, which fits well with the tools that use
> 128 data pages by default.
>
> However tools actually use 129 pages, because they need one more
> for the user control page. Thus the default mlock threshold is
> not sufficient for the default tools needs and we always end up
> to evaluate the constant mlock rlimit policy, which doesn't have
> this scaling with the number of online CPUs.
>
> Hence, on systems that have more than 16 CPUs, we overlap the
> rlimit threshold and fail to mmap:
>
> $ perf record ls
> Error: failed to mmap with 1 (Operation not permitted)
>
But isn't that simply coming from the fact that perf chose to request
128 pages by default? I don't know how this size was chosen. If perf
were to allocate 127 (data) pages, you would not have that problem
with the current default limit, would you?
> Just increase the max unprivileged mlock threshold by one page
> so that it supports well perf tools even after 16 CPUs.
>
> Reported-by: Han Pingtian <[email protected]>
> Reported-by: Peter Zijlstra <[email protected]>
> Reported-by: Arnaldo Carvalho de Melo <[email protected]>
> Signed-off-by: Frederic Weisbecker <[email protected]>
> Acked-by: Arnaldo Carvalho de Melo <[email protected]>
> Cc: Stephane Eranian <[email protected]>
> LKML-Reference: <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
> Signed-off-by: Paul Gortmaker <[email protected]>
> ---
> kernel/perf_event.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/perf_event.c b/kernel/perf_event.c
> index 2357b19..b203546 100644
> --- a/kernel/perf_event.c
> +++ b/kernel/perf_event.c
> @@ -57,7 +57,8 @@ static atomic_t nr_task_events __read_mostly;
> */
> int sysctl_perf_event_paranoid __read_mostly = 1;
>
> -int sysctl_perf_event_mlock __read_mostly = 512; /* 'free' kb per user */
> +/* Minimum for 128 pages + 1 for the user control page */
> +int sysctl_perf_event_mlock __read_mostly = 516; /* 'free' kb per user */
>
> /*
> * max perf event sample rate
> --
> 1.7.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
Re: [34-longterm 020/196] staging: hv: use sync_bitops when interacting with the hypervisor March 13, 2012 02:40PM |
On 12-03-13 03:00 AM, Olaf Hering wrote:
> On Mon, Mar 12, Paul Gortmaker wrote:
>
>> From: Olaf Hering <[email protected]>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>> -------------------
>>
>> commit 22356585712d1ff08fbfed152edd8b386873b238 upstream.
>
> Unless there is a happy user of the hv drivers in this old kernel, it
> makes no sense to backport just this one patch.
There is no real way any of can tell just exactly who is using what
feature in what release.
>
> I suggest to leave drivers/staging/hv alone in longterm releases, or
> backport the entire history of drivers/staging/hv up to 3.4.
I had actually thought of this in the past myself as well, but
in the end, decided to follow Greg's lead so at least it would
be consistent with what is/was done for 2.6.32
P.
>
> Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> On Mon, Mar 12, Paul Gortmaker wrote:
>
>> From: Olaf Hering <[email protected]>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>> -------------------
>>
>> commit 22356585712d1ff08fbfed152edd8b386873b238 upstream.
>
> Unless there is a happy user of the hv drivers in this old kernel, it
> makes no sense to backport just this one patch.
There is no real way any of can tell just exactly who is using what
feature in what release.
>
> I suggest to leave drivers/staging/hv alone in longterm releases, or
> backport the entire history of drivers/staging/hv up to 3.4.
I had actually thought of this in the past myself as well, but
in the end, decided to follow Greg's lead so at least it would
be consistent with what is/was done for 2.6.32
P.
>
> Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Olaf Hering
Re: [34-longterm 020/196] staging: hv: use sync_bitops when interacting with the hypervisor March 13, 2012 02:50PM |
On Tue, Mar 13, Paul Gortmaker wrote:
> On 12-03-13 03:00 AM, Olaf Hering wrote:
> > On Mon, Mar 12, Paul Gortmaker wrote:
> >
> >> From: Olaf Hering <[email protected]>
> >>
> >> -------------------
> >> This is a commit scheduled for the next v2.6.34 longterm release.
> >> If you see a problem with using this for longterm, please comment.
> >> -------------------
> >>
> >> commit 22356585712d1ff08fbfed152edd8b386873b238 upstream.
> >
> > Unless there is a happy user of the hv drivers in this old kernel, it
> > makes no sense to backport just this one patch.
>
> There is no real way any of can tell just exactly who is using what
> feature in what release.
Sure.
As it stands, the hv drivers in this version are not very stable, more
backports are needed. So whoever is using .34 as a base will most likely
have many more changes in his patchset.
If you want to apply this change, go ahead. I just wanted to point out
the state of the drivers.
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> On 12-03-13 03:00 AM, Olaf Hering wrote:
> > On Mon, Mar 12, Paul Gortmaker wrote:
> >
> >> From: Olaf Hering <[email protected]>
> >>
> >> -------------------
> >> This is a commit scheduled for the next v2.6.34 longterm release.
> >> If you see a problem with using this for longterm, please comment.
> >> -------------------
> >>
> >> commit 22356585712d1ff08fbfed152edd8b386873b238 upstream.
> >
> > Unless there is a happy user of the hv drivers in this old kernel, it
> > makes no sense to backport just this one patch.
>
> There is no real way any of can tell just exactly who is using what
> feature in what release.
Sure.
As it stands, the hv drivers in this version are not very stable, more
backports are needed. So whoever is using .34 as a base will most likely
have many more changes in his patchset.
If you want to apply this change, go ahead. I just wanted to point out
the state of the drivers.
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Boris Ostrovsky
Re: [34-longterm 181/196] x86, AMD: Fix ARAT feature setting again March 13, 2012 03:00PM |
On 03/12/12 20:21, Paul Gortmaker wrote:
> From: Borislav Petkov<[email protected]>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
Paul, please use e9cdd343a5e42c43bcda01e609fa23089e026470 instead of the
one below.
-boris
> -------------------
>
> commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
>
> Trying to enable the local APIC timer on early K8 revisions
> uncovers a number of other issues with it, in conjunction with
> the C1E enter path on AMD. Fixing those causes much more churn
> and troubles than the benefit of using that timer brings so
> don't enable it on K8 at all, falling back to the original
> functionality the kernel had wrt to that.
>
> Reported-and-bisected-by: Nick Bowler<[email protected]>
> Cc: Boris Ostrovsky<[email protected]>
> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
> Cc: Greg Kroah-Hartman<greg@kroah.com>
> Cc: Hans Rosenfeld<hans.rosenfeld@amd.com>
> Cc: Nick Bowler<nbowler@elliptictech.com>
> Cc: Joerg-Volker-Peetz<jvpeetz@web.de>
> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
> Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org
> Signed-off-by: Ingo Molnar<mingo@elte.hu>
> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
> ---
> arch/x86/kernel/cpu/amd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index d618dc1..76a7f76 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -567,7 +567,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
> #endif
>
> /* As a rule processors have APIC timer running in deep C states */
> - if (c->x86>= 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
> + if (c->x86> 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
> set_cpu_cap(c, X86_FEATURE_ARAT);
>
> /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> From: Borislav Petkov<[email protected]>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
Paul, please use e9cdd343a5e42c43bcda01e609fa23089e026470 instead of the
one below.
-boris
> -------------------
>
> commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
>
> Trying to enable the local APIC timer on early K8 revisions
> uncovers a number of other issues with it, in conjunction with
> the C1E enter path on AMD. Fixing those causes much more churn
> and troubles than the benefit of using that timer brings so
> don't enable it on K8 at all, falling back to the original
> functionality the kernel had wrt to that.
>
> Reported-and-bisected-by: Nick Bowler<[email protected]>
> Cc: Boris Ostrovsky<[email protected]>
> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
> Cc: Greg Kroah-Hartman<greg@kroah.com>
> Cc: Hans Rosenfeld<hans.rosenfeld@amd.com>
> Cc: Nick Bowler<nbowler@elliptictech.com>
> Cc: Joerg-Volker-Peetz<jvpeetz@web.de>
> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
> Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org
> Signed-off-by: Ingo Molnar<mingo@elte.hu>
> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
> ---
> arch/x86/kernel/cpu/amd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index d618dc1..76a7f76 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -567,7 +567,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
> #endif
>
> /* As a rule processors have APIC timer running in deep C states */
> - if (c->x86>= 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
> + if (c->x86> 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
> set_cpu_cap(c, X86_FEATURE_ARAT);
>
> /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Sarah Sharp
Re: [34-longterm 077/196] USB: xhci - fix math in xhci_get_endpoint_interval() March 13, 2012 05:30PM |
This commit introduced a bug, so you will need this fix as well:
commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Mon Feb 13 14:42:11 2012 -0800
xhci: Fix encoding for HS bulk/control NAK rate.
The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
be encoded as an exponent of two number of microframes. The endpoint
descriptor has the NAK rate encoded in number of microframes. We were
just copying the value from the endpoint descriptor into the endpoint
context interval field, which was not correct. This lead to the VIA
host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
storage device.
The fix is to use the correct encoding. Refactor the code to convert
number of frames to an exponential number of microframes, and make sure
we convert the number of microframes in HS bulk and control endpoints to
an exponent.
This should be back ported to kernels as old as 2.6.31, that contain the
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math
in xhci_get_endpoint_interval"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Felipe Contreras <felipe.contreras@gmail.com>
Suggested-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
Why are you hand-picking which of the xHCI commits marked for stable to
apply to this new 2.6.34 stable tree? On top of this patch, you're
probably missing twenty or so other required bug fix patches. I'm very
careful about saying which patches should apply to which stable kernels,
so it should be easy for you to go through the current -rc git log and
grep for changes to the xHCI driver that are marked for stable.
Sarah Sharp
On Mon, Mar 12, 2012 at 08:19:50PM -0400, Paul Gortmaker wrote:
> From: Dmitry Torokhov <dtor@vmware.com>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream.
>
> When parsing exponent-expressed intervals we subtract 1 from the
> value and then expect it to match with original + 1, which is
> highly unlikely, and we end with frequent spew:
>
> usb 3-4: ep 0x83 - rounding interval to 512 microframes
>
> Also, parsing interval for fullspeed isochronous endpoints was
> incorrect - according to USB spec they use exponent-based
> intervals (but xHCI spec claims frame-based intervals). I trust
> USB spec more, especially since USB core agrees with it.
>
> This should be queued for stable kernels back to 2.6.31.
>
> Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
> Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> drivers/usb/host/xhci-mem.c | 90 +++++++++++++++++++++++++++++--------------
> 1 file changed, 62 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index e560dd4..e1dbcc2 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -520,6 +520,47 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *ud
> return 0;
> }
>
> +/*
> + * Convert interval expressed as 2^(bInterval - 1) == interval into
> + * straight exponent value 2^n == interval.
> + *
> + */
> +static unsigned int xhci_parse_exponent_interval(struct usb_device *udev,
> + struct usb_host_endpoint *ep)
> +{
> + unsigned int interval;
> +
> + interval = clamp_val(ep->desc.bInterval, 1, 16) - 1;
> + if (interval != ep->desc.bInterval - 1)
> + dev_warn(&udev->dev,
> + "ep %#x - rounding interval to %d microframes\n",
> + ep->desc.bEndpointAddress,
> + 1 << interval);
> +
> + return interval;
> +}
> +
> +/*
> + * Convert bInterval expressed in frames (in 1-255 range) to exponent of
> + * microframes, rounded down to nearest power of 2.
> + */
> +static unsigned int xhci_parse_frame_interval(struct usb_device *udev,
> + struct usb_host_endpoint *ep)
> +{
> + unsigned int interval;
> +
> + interval = fls(8 * ep->desc.bInterval) - 1;
> + interval = clamp_val(interval, 3, 10);
> + if ((1 << interval) != 8 * ep->desc.bInterval)
> + dev_warn(&udev->dev,
> + "ep %#x - rounding interval to %d microframes, ep desc says %d microframes\n",
> + ep->desc.bEndpointAddress,
> + 1 << interval,
> + 8 * ep->desc.bInterval);
> +
> + return interval;
> +}
> +
> /* Return the polling or NAK interval.
> *
> * The polling interval is expressed in "microframes". If xHCI's Interval field
> @@ -537,45 +578,38 @@ static inline unsigned int xhci_get_endpoint_interval(struct usb_device *udev,
> case USB_SPEED_HIGH:
> /* Max NAK rate */
> if (usb_endpoint_xfer_control(&ep->desc) ||
> - usb_endpoint_xfer_bulk(&ep->desc))
> + usb_endpoint_xfer_bulk(&ep->desc)) {
> interval = ep->desc.bInterval;
> + break;
> + }
> /* Fall through - SS and HS isoc/int have same decoding */
> +
> case USB_SPEED_SUPER:
> if (usb_endpoint_xfer_int(&ep->desc) ||
> - usb_endpoint_xfer_isoc(&ep->desc)) {
> - if (ep->desc.bInterval == 0)
> - interval = 0;
> - else
> - interval = ep->desc.bInterval - 1;
> - if (interval > 15)
> - interval = 15;
> - if (interval != ep->desc.bInterval + 1)
> - dev_warn(&udev->dev, "ep %#x - rounding interval to %d microframes\n",
> - ep->desc.bEndpointAddress, 1 << interval);
> + usb_endpoint_xfer_isoc(&ep->desc)) {
> + interval = xhci_parse_exponent_interval(udev, ep);
> }
> break;
> - /* Convert bInterval (in 1-255 frames) to microframes and round down to
> - * nearest power of 2.
> - */
> +
> case USB_SPEED_FULL:
> + if (usb_endpoint_xfer_int(&ep->desc)) {
> + interval = xhci_parse_exponent_interval(udev, ep);
> + break;
> + }
> + /*
> + * Fall through for isochronous endpoint interval decoding
> + * since it uses the same rules as low speed interrupt
> + * endpoints.
> + */
> +
> case USB_SPEED_LOW:
> if (usb_endpoint_xfer_int(&ep->desc) ||
> - usb_endpoint_xfer_isoc(&ep->desc)) {
> - interval = fls(8*ep->desc.bInterval) - 1;
> - if (interval > 10)
> - interval = 10;
> - if (interval < 3)
> - interval = 3;
> - if ((1 << interval) != 8*ep->desc.bInterval)
> - dev_warn(&udev->dev,
> - "ep %#x - rounding interval"
> - " to %d microframes, "
> - "ep desc says %d microframes\n",
> - ep->desc.bEndpointAddress,
> - 1 << interval,
> - 8*ep->desc.bInterval);
> + usb_endpoint_xfer_isoc(&ep->desc)) {
> +
> + interval = xhci_parse_frame_interval(udev, ep);
> }
> break;
> +
> default:
> BUG();
> }
> --
> 1.7.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Mon Feb 13 14:42:11 2012 -0800
xhci: Fix encoding for HS bulk/control NAK rate.
The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
be encoded as an exponent of two number of microframes. The endpoint
descriptor has the NAK rate encoded in number of microframes. We were
just copying the value from the endpoint descriptor into the endpoint
context interval field, which was not correct. This lead to the VIA
host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
storage device.
The fix is to use the correct encoding. Refactor the code to convert
number of frames to an exponential number of microframes, and make sure
we convert the number of microframes in HS bulk and control endpoints to
an exponent.
This should be back ported to kernels as old as 2.6.31, that contain the
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math
in xhci_get_endpoint_interval"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Felipe Contreras <felipe.contreras@gmail.com>
Suggested-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
Why are you hand-picking which of the xHCI commits marked for stable to
apply to this new 2.6.34 stable tree? On top of this patch, you're
probably missing twenty or so other required bug fix patches. I'm very
careful about saying which patches should apply to which stable kernels,
so it should be easy for you to go through the current -rc git log and
grep for changes to the xHCI driver that are marked for stable.
Sarah Sharp
On Mon, Mar 12, 2012 at 08:19:50PM -0400, Paul Gortmaker wrote:
> From: Dmitry Torokhov <dtor@vmware.com>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream.
>
> When parsing exponent-expressed intervals we subtract 1 from the
> value and then expect it to match with original + 1, which is
> highly unlikely, and we end with frequent spew:
>
> usb 3-4: ep 0x83 - rounding interval to 512 microframes
>
> Also, parsing interval for fullspeed isochronous endpoints was
> incorrect - according to USB spec they use exponent-based
> intervals (but xHCI spec claims frame-based intervals). I trust
> USB spec more, especially since USB core agrees with it.
>
> This should be queued for stable kernels back to 2.6.31.
>
> Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
> Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> drivers/usb/host/xhci-mem.c | 90 +++++++++++++++++++++++++++++--------------
> 1 file changed, 62 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index e560dd4..e1dbcc2 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -520,6 +520,47 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *ud
> return 0;
> }
>
> +/*
> + * Convert interval expressed as 2^(bInterval - 1) == interval into
> + * straight exponent value 2^n == interval.
> + *
> + */
> +static unsigned int xhci_parse_exponent_interval(struct usb_device *udev,
> + struct usb_host_endpoint *ep)
> +{
> + unsigned int interval;
> +
> + interval = clamp_val(ep->desc.bInterval, 1, 16) - 1;
> + if (interval != ep->desc.bInterval - 1)
> + dev_warn(&udev->dev,
> + "ep %#x - rounding interval to %d microframes\n",
> + ep->desc.bEndpointAddress,
> + 1 << interval);
> +
> + return interval;
> +}
> +
> +/*
> + * Convert bInterval expressed in frames (in 1-255 range) to exponent of
> + * microframes, rounded down to nearest power of 2.
> + */
> +static unsigned int xhci_parse_frame_interval(struct usb_device *udev,
> + struct usb_host_endpoint *ep)
> +{
> + unsigned int interval;
> +
> + interval = fls(8 * ep->desc.bInterval) - 1;
> + interval = clamp_val(interval, 3, 10);
> + if ((1 << interval) != 8 * ep->desc.bInterval)
> + dev_warn(&udev->dev,
> + "ep %#x - rounding interval to %d microframes, ep desc says %d microframes\n",
> + ep->desc.bEndpointAddress,
> + 1 << interval,
> + 8 * ep->desc.bInterval);
> +
> + return interval;
> +}
> +
> /* Return the polling or NAK interval.
> *
> * The polling interval is expressed in "microframes". If xHCI's Interval field
> @@ -537,45 +578,38 @@ static inline unsigned int xhci_get_endpoint_interval(struct usb_device *udev,
> case USB_SPEED_HIGH:
> /* Max NAK rate */
> if (usb_endpoint_xfer_control(&ep->desc) ||
> - usb_endpoint_xfer_bulk(&ep->desc))
> + usb_endpoint_xfer_bulk(&ep->desc)) {
> interval = ep->desc.bInterval;
> + break;
> + }
> /* Fall through - SS and HS isoc/int have same decoding */
> +
> case USB_SPEED_SUPER:
> if (usb_endpoint_xfer_int(&ep->desc) ||
> - usb_endpoint_xfer_isoc(&ep->desc)) {
> - if (ep->desc.bInterval == 0)
> - interval = 0;
> - else
> - interval = ep->desc.bInterval - 1;
> - if (interval > 15)
> - interval = 15;
> - if (interval != ep->desc.bInterval + 1)
> - dev_warn(&udev->dev, "ep %#x - rounding interval to %d microframes\n",
> - ep->desc.bEndpointAddress, 1 << interval);
> + usb_endpoint_xfer_isoc(&ep->desc)) {
> + interval = xhci_parse_exponent_interval(udev, ep);
> }
> break;
> - /* Convert bInterval (in 1-255 frames) to microframes and round down to
> - * nearest power of 2.
> - */
> +
> case USB_SPEED_FULL:
> + if (usb_endpoint_xfer_int(&ep->desc)) {
> + interval = xhci_parse_exponent_interval(udev, ep);
> + break;
> + }
> + /*
> + * Fall through for isochronous endpoint interval decoding
> + * since it uses the same rules as low speed interrupt
> + * endpoints.
> + */
> +
> case USB_SPEED_LOW:
> if (usb_endpoint_xfer_int(&ep->desc) ||
> - usb_endpoint_xfer_isoc(&ep->desc)) {
> - interval = fls(8*ep->desc.bInterval) - 1;
> - if (interval > 10)
> - interval = 10;
> - if (interval < 3)
> - interval = 3;
> - if ((1 << interval) != 8*ep->desc.bInterval)
> - dev_warn(&udev->dev,
> - "ep %#x - rounding interval"
> - " to %d microframes, "
> - "ep desc says %d microframes\n",
> - ep->desc.bEndpointAddress,
> - 1 << interval,
> - 8*ep->desc.bInterval);
> + usb_endpoint_xfer_isoc(&ep->desc)) {
> +
> + interval = xhci_parse_frame_interval(udev, ep);
> }
> break;
> +
> default:
> BUG();
> }
> --
> 1.7.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Bjørn Mork
Re: [34-longterm 098/196] iwlagn: Support new 5000 microcode. March 13, 2012 05:30PM |
Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> From: "Fry, Donald H" <donald.h.fry@intel.com>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit 41504cce240f791f1e16561db95728c5537fbad9 upstream.
>
> New iwlwifi-5000 microcode requires driver support for API version 5.
>
> Signed-off-by: Don Fry <donald.h.fry@intel.com>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
> index d05fad4..dc191b8 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-5000.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
> @@ -48,7 +48,7 @@
> #include "iwl-6000-hw.h"
>
> /* Highest firmware API version supported */
> -#define IWL5000_UCODE_API_MAX 2
> +#define IWL5000_UCODE_API_MAX 5
> #define IWL5150_UCODE_API_MAX 2
This looks like the patch which broke the driver in stable-2.6.32.y and
was later reverted by:
commit 2a96ae707525ef00a85bf374e56f0219c07eac5a
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date: Wed Jun 15 13:12:35 2011 -0700
Revert "iwlagn: Support new 5000 microcode."
This reverts commit 6f63415fc1b690cb50c2ad48ba6e9e6e88e271b4.
It turns out this is not what we want to have happen for the .32 and
.33-longterm kernels as it does not work properly at all.
This was reported by Gentoo, Arch, and Canonical developers as causing
problems for their users:
https://bugs.archlinux.org/task/24302
http://bugs.gentoo.org/show_bug.cgi?id=359445
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Cc: Gordon Malm <gengor@gentoo.org>
Cc: Don Fry <donald.h.fry@intel.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> From: "Fry, Donald H" <donald.h.fry@intel.com>
>
> -------------------
> This is a commit scheduled for the next v2.6.34 longterm release.
> If you see a problem with using this for longterm, please comment.
> -------------------
>
> commit 41504cce240f791f1e16561db95728c5537fbad9 upstream.
>
> New iwlwifi-5000 microcode requires driver support for API version 5.
>
> Signed-off-by: Don Fry <donald.h.fry@intel.com>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
> index d05fad4..dc191b8 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-5000.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
> @@ -48,7 +48,7 @@
> #include "iwl-6000-hw.h"
>
> /* Highest firmware API version supported */
> -#define IWL5000_UCODE_API_MAX 2
> +#define IWL5000_UCODE_API_MAX 5
> #define IWL5150_UCODE_API_MAX 2
This looks like the patch which broke the driver in stable-2.6.32.y and
was later reverted by:
commit 2a96ae707525ef00a85bf374e56f0219c07eac5a
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date: Wed Jun 15 13:12:35 2011 -0700
Revert "iwlagn: Support new 5000 microcode."
This reverts commit 6f63415fc1b690cb50c2ad48ba6e9e6e88e271b4.
It turns out this is not what we want to have happen for the .32 and
.33-longterm kernels as it does not work properly at all.
This was reported by Gentoo, Arch, and Canonical developers as causing
problems for their users:
https://bugs.archlinux.org/task/24302
http://bugs.gentoo.org/show_bug.cgi?id=359445
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Cc: Gordon Malm <gengor@gentoo.org>
Cc: Don Fry <donald.h.fry@intel.com>
Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
Re: [34-longterm 077/196] USB: xhci - fix math in xhci_get_endpoint_interval() March 13, 2012 06:00PM |
On 12-03-13 12:20 PM, Sarah Sharp wrote:
> This commit introduced a bug, so you will need this fix as well:
Thanks.
>
> commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2
> Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Date: Mon Feb 13 14:42:11 2012 -0800
>
> xhci: Fix encoding for HS bulk/control NAK rate.
>
> The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
> be encoded as an exponent of two number of microframes. The endpoint
> descriptor has the NAK rate encoded in number of microframes. We were
> just copying the value from the endpoint descriptor into the endpoint
> context interval field, which was not correct. This lead to the VIA
> host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
> storage device.
>
> The fix is to use the correct encoding. Refactor the code to convert
> number of frames to an exponential number of microframes, and make sure
> we convert the number of microframes in HS bulk and control endpoints to
> an exponent.
>
> This should be back ported to kernels as old as 2.6.31, that contain the
> commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math
> in xhci_get_endpoint_interval"
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Tested-by: Felipe Contreras <felipe.contreras@gmail.com>
> Suggested-by: Andiry Xu <andiry.xu@amd.com>
> Cc: stable@vger.kernel.org
>
> Why are you hand-picking which of the xHCI commits marked for stable to
> apply to this new 2.6.34 stable tree? On top of this patch, you're
I've been using the commits applied to 2.6.32.x versions as a reference.
I can't do a release with 1000 commits, so I have to chunkify things
somewhat, and doing roughly parallels of the individual 2.6.32.x releases
is a good starting point. Most times the commits for stable are independent
bugfixes chosen for high value and low risk of regression, so this typically
works fine. If there are dependencies and regressions in the xHCI stable
content that I should be trying to avoid, I'm fine with taking that input.
Paul.
> probably missing twenty or so other required bug fix patches. I'm very
> careful about saying which patches should apply to which stable kernels,
> so it should be easy for you to go through the current -rc git log and
> grep for changes to the xHCI driver that are marked for stable.
>
> Sarah Sharp
>
> On Mon, Mar 12, 2012 at 08:19:50PM -0400, Paul Gortmaker wrote:
>> From: Dmitry Torokhov <dtor@vmware.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>> -------------------
>>
>> commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream.
>>
>> When parsing exponent-expressed intervals we subtract 1 from the
>> value and then expect it to match with original + 1, which is
>> highly unlikely, and we end with frequent spew:
>>
>> usb 3-4: ep 0x83 - rounding interval to 512 microframes
>>
>> Also, parsing interval for fullspeed isochronous endpoints was
>> incorrect - according to USB spec they use exponent-based
>> intervals (but xHCI spec claims frame-based intervals). I trust
>> USB spec more, especially since USB core agrees with it.
>>
>> This should be queued for stable kernels back to 2.6.31.
>>
>> Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
>> Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
>> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> drivers/usb/host/xhci-mem.c | 90 +++++++++++++++++++++++++++++--------------
>> 1 file changed, 62 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index e560dd4..e1dbcc2 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>> @@ -520,6 +520,47 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *ud
>> return 0;
>> }
>>
>> +/*
>> + * Convert interval expressed as 2^(bInterval - 1) == interval into
>> + * straight exponent value 2^n == interval.
>> + *
>> + */
>> +static unsigned int xhci_parse_exponent_interval(struct usb_device *udev,
>> + struct usb_host_endpoint *ep)
>> +{
>> + unsigned int interval;
>> +
>> + interval = clamp_val(ep->desc.bInterval, 1, 16) - 1;
>> + if (interval != ep->desc.bInterval - 1)
>> + dev_warn(&udev->dev,
>> + "ep %#x - rounding interval to %d microframes\n",
>> + ep->desc.bEndpointAddress,
>> + 1 << interval);
>> +
>> + return interval;
>> +}
>> +
>> +/*
>> + * Convert bInterval expressed in frames (in 1-255 range) to exponent of
>> + * microframes, rounded down to nearest power of 2.
>> + */
>> +static unsigned int xhci_parse_frame_interval(struct usb_device *udev,
>> + struct usb_host_endpoint *ep)
>> +{
>> + unsigned int interval;
>> +
>> + interval = fls(8 * ep->desc.bInterval) - 1;
>> + interval = clamp_val(interval, 3, 10);
>> + if ((1 << interval) != 8 * ep->desc.bInterval)
>> + dev_warn(&udev->dev,
>> + "ep %#x - rounding interval to %d microframes, ep desc says %d microframes\n",
>> + ep->desc.bEndpointAddress,
>> + 1 << interval,
>> + 8 * ep->desc.bInterval);
>> +
>> + return interval;
>> +}
>> +
>> /* Return the polling or NAK interval.
>> *
>> * The polling interval is expressed in "microframes". If xHCI's Interval field
>> @@ -537,45 +578,38 @@ static inline unsigned int xhci_get_endpoint_interval(struct usb_device *udev,
>> case USB_SPEED_HIGH:
>> /* Max NAK rate */
>> if (usb_endpoint_xfer_control(&ep->desc) ||
>> - usb_endpoint_xfer_bulk(&ep->desc))
>> + usb_endpoint_xfer_bulk(&ep->desc)) {
>> interval = ep->desc.bInterval;
>> + break;
>> + }
>> /* Fall through - SS and HS isoc/int have same decoding */
>> +
>> case USB_SPEED_SUPER:
>> if (usb_endpoint_xfer_int(&ep->desc) ||
>> - usb_endpoint_xfer_isoc(&ep->desc)) {
>> - if (ep->desc.bInterval == 0)
>> - interval = 0;
>> - else
>> - interval = ep->desc.bInterval - 1;
>> - if (interval > 15)
>> - interval = 15;
>> - if (interval != ep->desc.bInterval + 1)
>> - dev_warn(&udev->dev, "ep %#x - rounding interval to %d microframes\n",
>> - ep->desc.bEndpointAddress, 1 << interval);
>> + usb_endpoint_xfer_isoc(&ep->desc)) {
>> + interval = xhci_parse_exponent_interval(udev, ep);
>> }
>> break;
>> - /* Convert bInterval (in 1-255 frames) to microframes and round down to
>> - * nearest power of 2.
>> - */
>> +
>> case USB_SPEED_FULL:
>> + if (usb_endpoint_xfer_int(&ep->desc)) {
>> + interval = xhci_parse_exponent_interval(udev, ep);
>> + break;
>> + }
>> + /*
>> + * Fall through for isochronous endpoint interval decoding
>> + * since it uses the same rules as low speed interrupt
>> + * endpoints.
>> + */
>> +
>> case USB_SPEED_LOW:
>> if (usb_endpoint_xfer_int(&ep->desc) ||
>> - usb_endpoint_xfer_isoc(&ep->desc)) {
>> - interval = fls(8*ep->desc.bInterval) - 1;
>> - if (interval > 10)
>> - interval = 10;
>> - if (interval < 3)
>> - interval = 3;
>> - if ((1 << interval) != 8*ep->desc.bInterval)
>> - dev_warn(&udev->dev,
>> - "ep %#x - rounding interval"
>> - " to %d microframes, "
>> - "ep desc says %d microframes\n",
>> - ep->desc.bEndpointAddress,
>> - 1 << interval,
>> - 8*ep->desc.bInterval);
>> + usb_endpoint_xfer_isoc(&ep->desc)) {
>> +
>> + interval = xhci_parse_frame_interval(udev, ep);
>> }
>> break;
>> +
>> default:
>> BUG();
>> }
>> --
>> 1.7.9.3
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> This commit introduced a bug, so you will need this fix as well:
Thanks.
>
> commit 340a3504fd39dad753ba908fb6f894ee81fc3ae2
> Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Date: Mon Feb 13 14:42:11 2012 -0800
>
> xhci: Fix encoding for HS bulk/control NAK rate.
>
> The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
> be encoded as an exponent of two number of microframes. The endpoint
> descriptor has the NAK rate encoded in number of microframes. We were
> just copying the value from the endpoint descriptor into the endpoint
> context interval field, which was not correct. This lead to the VIA
> host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
> storage device.
>
> The fix is to use the correct encoding. Refactor the code to convert
> number of frames to an exponential number of microframes, and make sure
> we convert the number of microframes in HS bulk and control endpoints to
> an exponent.
>
> This should be back ported to kernels as old as 2.6.31, that contain the
> commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math
> in xhci_get_endpoint_interval"
>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Tested-by: Felipe Contreras <felipe.contreras@gmail.com>
> Suggested-by: Andiry Xu <andiry.xu@amd.com>
> Cc: stable@vger.kernel.org
>
> Why are you hand-picking which of the xHCI commits marked for stable to
> apply to this new 2.6.34 stable tree? On top of this patch, you're
I've been using the commits applied to 2.6.32.x versions as a reference.
I can't do a release with 1000 commits, so I have to chunkify things
somewhat, and doing roughly parallels of the individual 2.6.32.x releases
is a good starting point. Most times the commits for stable are independent
bugfixes chosen for high value and low risk of regression, so this typically
works fine. If there are dependencies and regressions in the xHCI stable
content that I should be trying to avoid, I'm fine with taking that input.
Paul.
> probably missing twenty or so other required bug fix patches. I'm very
> careful about saying which patches should apply to which stable kernels,
> so it should be easy for you to go through the current -rc git log and
> grep for changes to the xHCI driver that are marked for stable.
>
> Sarah Sharp
>
> On Mon, Mar 12, 2012 at 08:19:50PM -0400, Paul Gortmaker wrote:
>> From: Dmitry Torokhov <dtor@vmware.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>> -------------------
>>
>> commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream.
>>
>> When parsing exponent-expressed intervals we subtract 1 from the
>> value and then expect it to match with original + 1, which is
>> highly unlikely, and we end with frequent spew:
>>
>> usb 3-4: ep 0x83 - rounding interval to 512 microframes
>>
>> Also, parsing interval for fullspeed isochronous endpoints was
>> incorrect - according to USB spec they use exponent-based
>> intervals (but xHCI spec claims frame-based intervals). I trust
>> USB spec more, especially since USB core agrees with it.
>>
>> This should be queued for stable kernels back to 2.6.31.
>>
>> Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
>> Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
>> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> drivers/usb/host/xhci-mem.c | 90 +++++++++++++++++++++++++++++--------------
>> 1 file changed, 62 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index e560dd4..e1dbcc2 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>> @@ -520,6 +520,47 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *ud
>> return 0;
>> }
>>
>> +/*
>> + * Convert interval expressed as 2^(bInterval - 1) == interval into
>> + * straight exponent value 2^n == interval.
>> + *
>> + */
>> +static unsigned int xhci_parse_exponent_interval(struct usb_device *udev,
>> + struct usb_host_endpoint *ep)
>> +{
>> + unsigned int interval;
>> +
>> + interval = clamp_val(ep->desc.bInterval, 1, 16) - 1;
>> + if (interval != ep->desc.bInterval - 1)
>> + dev_warn(&udev->dev,
>> + "ep %#x - rounding interval to %d microframes\n",
>> + ep->desc.bEndpointAddress,
>> + 1 << interval);
>> +
>> + return interval;
>> +}
>> +
>> +/*
>> + * Convert bInterval expressed in frames (in 1-255 range) to exponent of
>> + * microframes, rounded down to nearest power of 2.
>> + */
>> +static unsigned int xhci_parse_frame_interval(struct usb_device *udev,
>> + struct usb_host_endpoint *ep)
>> +{
>> + unsigned int interval;
>> +
>> + interval = fls(8 * ep->desc.bInterval) - 1;
>> + interval = clamp_val(interval, 3, 10);
>> + if ((1 << interval) != 8 * ep->desc.bInterval)
>> + dev_warn(&udev->dev,
>> + "ep %#x - rounding interval to %d microframes, ep desc says %d microframes\n",
>> + ep->desc.bEndpointAddress,
>> + 1 << interval,
>> + 8 * ep->desc.bInterval);
>> +
>> + return interval;
>> +}
>> +
>> /* Return the polling or NAK interval.
>> *
>> * The polling interval is expressed in "microframes". If xHCI's Interval field
>> @@ -537,45 +578,38 @@ static inline unsigned int xhci_get_endpoint_interval(struct usb_device *udev,
>> case USB_SPEED_HIGH:
>> /* Max NAK rate */
>> if (usb_endpoint_xfer_control(&ep->desc) ||
>> - usb_endpoint_xfer_bulk(&ep->desc))
>> + usb_endpoint_xfer_bulk(&ep->desc)) {
>> interval = ep->desc.bInterval;
>> + break;
>> + }
>> /* Fall through - SS and HS isoc/int have same decoding */
>> +
>> case USB_SPEED_SUPER:
>> if (usb_endpoint_xfer_int(&ep->desc) ||
>> - usb_endpoint_xfer_isoc(&ep->desc)) {
>> - if (ep->desc.bInterval == 0)
>> - interval = 0;
>> - else
>> - interval = ep->desc.bInterval - 1;
>> - if (interval > 15)
>> - interval = 15;
>> - if (interval != ep->desc.bInterval + 1)
>> - dev_warn(&udev->dev, "ep %#x - rounding interval to %d microframes\n",
>> - ep->desc.bEndpointAddress, 1 << interval);
>> + usb_endpoint_xfer_isoc(&ep->desc)) {
>> + interval = xhci_parse_exponent_interval(udev, ep);
>> }
>> break;
>> - /* Convert bInterval (in 1-255 frames) to microframes and round down to
>> - * nearest power of 2.
>> - */
>> +
>> case USB_SPEED_FULL:
>> + if (usb_endpoint_xfer_int(&ep->desc)) {
>> + interval = xhci_parse_exponent_interval(udev, ep);
>> + break;
>> + }
>> + /*
>> + * Fall through for isochronous endpoint interval decoding
>> + * since it uses the same rules as low speed interrupt
>> + * endpoints.
>> + */
>> +
>> case USB_SPEED_LOW:
>> if (usb_endpoint_xfer_int(&ep->desc) ||
>> - usb_endpoint_xfer_isoc(&ep->desc)) {
>> - interval = fls(8*ep->desc.bInterval) - 1;
>> - if (interval > 10)
>> - interval = 10;
>> - if (interval < 3)
>> - interval = 3;
>> - if ((1 << interval) != 8*ep->desc.bInterval)
>> - dev_warn(&udev->dev,
>> - "ep %#x - rounding interval"
>> - " to %d microframes, "
>> - "ep desc says %d microframes\n",
>> - ep->desc.bEndpointAddress,
>> - 1 << interval,
>> - 8*ep->desc.bInterval);
>> + usb_endpoint_xfer_isoc(&ep->desc)) {
>> +
>> + interval = xhci_parse_frame_interval(udev, ep);
>> }
>> break;
>> +
>> default:
>> BUG();
>> }
>> --
>> 1.7.9.3
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
Re: [34-longterm 098/196] iwlagn: Support new 5000 microcode. March 13, 2012 06:00PM |
On 12-03-13 12:24 PM, Bjørn Mork wrote:
> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
>
>> From: "Fry, Donald H" <donald.h.fry@intel.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>> -------------------
>>
>> commit 41504cce240f791f1e16561db95728c5537fbad9 upstream.
>>
>> New iwlwifi-5000 microcode requires driver support for API version 5.
>>
>> Signed-off-by: Don Fry <donald.h.fry@intel.com>
>> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
>> index d05fad4..dc191b8 100644
>> --- a/drivers/net/wireless/iwlwifi/iwl-5000.c
>> +++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
>> @@ -48,7 +48,7 @@
>> #include "iwl-6000-hw.h"
>>
>> /* Highest firmware API version supported */
>> -#define IWL5000_UCODE_API_MAX 2
>> +#define IWL5000_UCODE_API_MAX 5
>> #define IWL5150_UCODE_API_MAX 2
>
> This looks like the patch which broke the driver in stable-2.6.32.y and
> was later reverted by:
Thanks for the heads up. I'll be sure to drop this.
Paul.
--
>
>
> commit 2a96ae707525ef00a85bf374e56f0219c07eac5a
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date: Wed Jun 15 13:12:35 2011 -0700
>
> Revert "iwlagn: Support new 5000 microcode."
>
> This reverts commit 6f63415fc1b690cb50c2ad48ba6e9e6e88e271b4.
>
> It turns out this is not what we want to have happen for the .32 and
> .33-longterm kernels as it does not work properly at all.
>
> This was reported by Gentoo, Arch, and Canonical developers as causing
> problems for their users:
> https://bugs.archlinux.org/task/24302
> http://bugs.gentoo.org/show_bug.cgi?id=359445
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
>
> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
> Cc: Gordon Malm <gengor@gentoo.org>
> Cc: Don Fry <donald.h.fry@intel.com>
> Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
>
>
>
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
>
>> From: "Fry, Donald H" <donald.h.fry@intel.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>> -------------------
>>
>> commit 41504cce240f791f1e16561db95728c5537fbad9 upstream.
>>
>> New iwlwifi-5000 microcode requires driver support for API version 5.
>>
>> Signed-off-by: Don Fry <donald.h.fry@intel.com>
>> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
>> index d05fad4..dc191b8 100644
>> --- a/drivers/net/wireless/iwlwifi/iwl-5000.c
>> +++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
>> @@ -48,7 +48,7 @@
>> #include "iwl-6000-hw.h"
>>
>> /* Highest firmware API version supported */
>> -#define IWL5000_UCODE_API_MAX 2
>> +#define IWL5000_UCODE_API_MAX 5
>> #define IWL5150_UCODE_API_MAX 2
>
> This looks like the patch which broke the driver in stable-2.6.32.y and
> was later reverted by:
Thanks for the heads up. I'll be sure to drop this.
Paul.
--
>
>
> commit 2a96ae707525ef00a85bf374e56f0219c07eac5a
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date: Wed Jun 15 13:12:35 2011 -0700
>
> Revert "iwlagn: Support new 5000 microcode."
>
> This reverts commit 6f63415fc1b690cb50c2ad48ba6e9e6e88e271b4.
>
> It turns out this is not what we want to have happen for the .32 and
> .33-longterm kernels as it does not work properly at all.
>
> This was reported by Gentoo, Arch, and Canonical developers as causing
> problems for their users:
> https://bugs.archlinux.org/task/24302
> http://bugs.gentoo.org/show_bug.cgi?id=359445
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796336
>
> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
> Cc: Gordon Malm <gengor@gentoo.org>
> Cc: Don Fry <donald.h.fry@intel.com>
> Cc: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
>
>
>
> Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
Re: [34-longterm 181/196] x86, AMD: Fix ARAT feature setting again March 13, 2012 07:50PM |
On 12-03-13 09:55 AM, Boris Ostrovsky wrote:
> On 03/12/12 20:21, Paul Gortmaker wrote:
>> From: Borislav Petkov<borislav.petkov@amd.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>
>
> Paul, please use e9cdd343a5e42c43bcda01e609fa23089e026470 instead of the
> one below.
Thanks, I'll make the exchange.
P.
>
> -boris
>
>> -------------------
>>
>> commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
>>
>> Trying to enable the local APIC timer on early K8 revisions
>> uncovers a number of other issues with it, in conjunction with
>> the C1E enter path on AMD. Fixing those causes much more churn
>> and troubles than the benefit of using that timer brings so
>> don't enable it on K8 at all, falling back to the original
>> functionality the kernel had wrt to that.
>>
>> Reported-and-bisected-by: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Boris Ostrovsky<Boris.Ostrovsky@amd.com>
>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>> Cc: Greg Kroah-Hartman<greg@kroah.com>
>> Cc: Hans Rosenfeld<hans.rosenfeld@amd.com>
>> Cc: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Joerg-Volker-Peetz<jvpeetz@web.de>
>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>> Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org
>> Signed-off-by: Ingo Molnar<mingo@elte.hu>
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
>> ---
>> arch/x86/kernel/cpu/amd.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index d618dc1..76a7f76 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -567,7 +567,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>> #endif
>>
>> /* As a rule processors have APIC timer running in deep C states */
>> - if (c->x86>= 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> + if (c->x86> 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> set_cpu_cap(c, X86_FEATURE_ARAT);
>>
>> /*
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> On 03/12/12 20:21, Paul Gortmaker wrote:
>> From: Borislav Petkov<borislav.petkov@amd.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>
>
> Paul, please use e9cdd343a5e42c43bcda01e609fa23089e026470 instead of the
> one below.
Thanks, I'll make the exchange.
P.
>
> -boris
>
>> -------------------
>>
>> commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
>>
>> Trying to enable the local APIC timer on early K8 revisions
>> uncovers a number of other issues with it, in conjunction with
>> the C1E enter path on AMD. Fixing those causes much more churn
>> and troubles than the benefit of using that timer brings so
>> don't enable it on K8 at all, falling back to the original
>> functionality the kernel had wrt to that.
>>
>> Reported-and-bisected-by: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Boris Ostrovsky<Boris.Ostrovsky@amd.com>
>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>> Cc: Greg Kroah-Hartman<greg@kroah.com>
>> Cc: Hans Rosenfeld<hans.rosenfeld@amd.com>
>> Cc: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Joerg-Volker-Peetz<jvpeetz@web.de>
>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>> Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org
>> Signed-off-by: Ingo Molnar<mingo@elte.hu>
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
>> ---
>> arch/x86/kernel/cpu/amd.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index d618dc1..76a7f76 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -567,7 +567,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>> #endif
>>
>> /* As a rule processors have APIC timer running in deep C states */
>> - if (c->x86>= 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> + if (c->x86> 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> set_cpu_cap(c, X86_FEATURE_ARAT);
>>
>> /*
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
|
Paul Gortmaker
Re: [34-longterm 181/196] x86, AMD: Fix ARAT feature setting again March 14, 2012 03:10PM |
On 12-03-13 09:55 AM, Boris Ostrovsky wrote:
> On 03/12/12 20:21, Paul Gortmaker wrote:
>> From: Borislav Petkov<borislav.petkov@amd.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>
>
> Paul, please use e9cdd343a5e42c43bcda01e609fa23089e026470 instead of the
> one below.
It turns out that the e9cdd wants to apply on top of (vs instead of) the
14fb57dccb commit.
So I will queue it directly after the 14fb57dcc commit.
Thanks,
Paul.
>
> -boris
>
>> -------------------
>>
>> commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
>>
>> Trying to enable the local APIC timer on early K8 revisions
>> uncovers a number of other issues with it, in conjunction with
>> the C1E enter path on AMD. Fixing those causes much more churn
>> and troubles than the benefit of using that timer brings so
>> don't enable it on K8 at all, falling back to the original
>> functionality the kernel had wrt to that.
>>
>> Reported-and-bisected-by: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Boris Ostrovsky<Boris.Ostrovsky@amd.com>
>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>> Cc: Greg Kroah-Hartman<greg@kroah.com>
>> Cc: Hans Rosenfeld<hans.rosenfeld@amd.com>
>> Cc: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Joerg-Volker-Peetz<jvpeetz@web.de>
>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>> Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org
>> Signed-off-by: Ingo Molnar<mingo@elte.hu>
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
>> ---
>> arch/x86/kernel/cpu/amd.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index d618dc1..76a7f76 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -567,7 +567,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>> #endif
>>
>> /* As a rule processors have APIC timer running in deep C states */
>> - if (c->x86>= 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> + if (c->x86> 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> set_cpu_cap(c, X86_FEATURE_ARAT);
>>
>> /*
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> On 03/12/12 20:21, Paul Gortmaker wrote:
>> From: Borislav Petkov<borislav.petkov@amd.com>
>>
>> -------------------
>> This is a commit scheduled for the next v2.6.34 longterm release.
>> If you see a problem with using this for longterm, please comment.
>
>
> Paul, please use e9cdd343a5e42c43bcda01e609fa23089e026470 instead of the
> one below.
It turns out that the e9cdd wants to apply on top of (vs instead of) the
14fb57dccb commit.
So I will queue it directly after the 14fb57dcc commit.
Thanks,
Paul.
>
> -boris
>
>> -------------------
>>
>> commit 14fb57dccb6e1defe9f89a66f548fcb24c374c1d upstream.
>>
>> Trying to enable the local APIC timer on early K8 revisions
>> uncovers a number of other issues with it, in conjunction with
>> the C1E enter path on AMD. Fixing those causes much more churn
>> and troubles than the benefit of using that timer brings so
>> don't enable it on K8 at all, falling back to the original
>> functionality the kernel had wrt to that.
>>
>> Reported-and-bisected-by: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Boris Ostrovsky<Boris.Ostrovsky@amd.com>
>> Cc: Andreas Herrmann<andreas.herrmann3@amd.com>
>> Cc: Greg Kroah-Hartman<greg@kroah.com>
>> Cc: Hans Rosenfeld<hans.rosenfeld@amd.com>
>> Cc: Nick Bowler<nbowler@elliptictech.com>
>> Cc: Joerg-Volker-Peetz<jvpeetz@web.de>
>> Signed-off-by: Borislav Petkov<borislav.petkov@amd.com>
>> Link: http://lkml.kernel.org/r/1305636919-31165-3-git-send-email-bp@amd64.org
>> Signed-off-by: Ingo Molnar<mingo@elte.hu>
>> Signed-off-by: Paul Gortmaker<paul.gortmaker@windriver.com>
>> ---
>> arch/x86/kernel/cpu/amd.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index d618dc1..76a7f76 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -567,7 +567,7 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c)
>> #endif
>>
>> /* As a rule processors have APIC timer running in deep C states */
>> - if (c->x86>= 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> + if (c->x86> 0xf&& !cpu_has_amd_erratum(amd_erratum_400))
>> set_cpu_cap(c, X86_FEATURE_ARAT);
>>
>> /*
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sorry, only registered users may post in this forum.