[00/28] 2.6.32.39-longterm review

[00/28] 2.6.32.39-longterm review

[Greg KH]

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

Responses should be made by Thursday, April 21, 2011, 20:00:00 UTC.
Anything received after that time might be too late.

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

thanks,

greg k-h

 MAINTAINERS                                |    1 -
 Makefile                                   |    2 +-
 arch/ia64/kernel/mca.c                     |    3 +-
 arch/ia64/sn/pci/tioca_provider.c          |    2 +-
 arch/x86/include/asm/msr-index.h           |    4 +
 arch/x86/include/asm/processor.h           |   19 ++++++
 arch/x86/kernel/cpu/amd.c                  |   88 ++++++++++++++++++++++++++++
 arch/x86/kernel/process.c                  |   39 +------------
 arch/x86/lib/semaphore_32.S                |    2 +-
 drivers/media/video/sn9c102/sn9c102_core.c |    6 +-
 drivers/net/usb/cdc-phonet.c               |    9 +--
 drivers/usb/core/devices.c                 |   10 ++-
 drivers/usb/host/ehci-q.c                  |   15 +++--
 drivers/usb/host/xhci-mem.c                |   85 +++++++++++++++++++-------
 drivers/usb/host/xhci.h                    |    6 +-
 drivers/usb/serial/ftdi_sio.c              |    5 ++
 drivers/usb/serial/ftdi_sio_ids.h          |   12 ++++
 drivers/usb/serial/option.c                |   12 ++++
 fs/cifs/connect.c                          |    2 +-
 fs/proc/base.c                             |    9 ++-
 fs/ramfs/file-nommu.c                      |    1 +
 fs/ubifs/debug.c                           |    6 +-
 fs/ubifs/file.c                            |    3 +
 include/linux/pid.h                        |    2 +-
 kernel/pid.c                               |    5 +-
 net/ax25/af_ax25.c                         |    2 +-
 net/rds/rdma.c                             |   11 ++++
 27 files changed, 265 insertions(+), 96 deletions(-)

[01/28] cifs: always do is_path_accessible check in cifs_mount

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Jeff Layton <jlayton@redhat.com>

commit 70945643722ffeac779d2529a348f99567fa5c33 upstream.

Currently, we skip doing the is_path_accessible check in cifs_mount if
there is no prefixpath. I have a report of at least one server however
that allows a TREE_CONNECT to a share that has a DFS referral at its
root. The reporter in this case was using a UNC that had no prefixpath,
so the is_path_accessible check was not triggered and the box later hit
a BUG() because we were chasing a DFS referral on the root dentry for
the mount.

This patch fixes this by removing the check for a zero-length
prefixpath.  That should make the is_path_accessible check be done in
this situation and should allow the client to chase the DFS referral at
mount time instead.

Reported-and-Tested-by: Yogesh Sharma <ysharma@cymer.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/cifs/connect.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2532,7 +2532,7 @@ try_mount_again:
 
 remote_path_check:
 	/* check if a whole path (including prepath) is not remote */
-	if (!rc && cifs_sb->prepathlen && tcon) {
+	if (!rc && tcon) {
 		/* build_path_to_root works only when we have a valid tcon */
 		full_path = cifs_build_path_to_root(cifs_sb);
 		if (full_path == NULL) {

[02/28] [media] video: sn9c102: world-wirtable sysfs files

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Vasiliy Kulikov <segoon@openwall.com>

commit 14ddc3188d50855ae2a419a6aced995e2834e5d4 upstream.

Don't allow everybody to change video settings.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/sn9c102/sn9c102_core.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/media/video/sn9c102/sn9c102_core.c
+++ b/drivers/media/video/sn9c102/sn9c102_core.c
@@ -1430,9 +1430,9 @@ static DEVICE_ATTR(i2c_reg, S_IRUGO | S_
 		   sn9c102_show_i2c_reg, sn9c102_store_i2c_reg);
 static DEVICE_ATTR(i2c_val, S_IRUGO | S_IWUSR,
 		   sn9c102_show_i2c_val, sn9c102_store_i2c_val);
-static DEVICE_ATTR(green, S_IWUGO, NULL, sn9c102_store_green);
-static DEVICE_ATTR(blue, S_IWUGO, NULL, sn9c102_store_blue);
-static DEVICE_ATTR(red, S_IWUGO, NULL, sn9c102_store_red);
+static DEVICE_ATTR(green, S_IWUSR, NULL, sn9c102_store_green);
+static DEVICE_ATTR(blue, S_IWUSR, NULL, sn9c102_store_blue);
+static DEVICE_ATTR(red, S_IWUSR, NULL, sn9c102_store_red);
 static DEVICE_ATTR(frame_header, S_IRUGO, sn9c102_show_frame_header, NULL);
 
 

[03/28] UBIFS: restrict world-writable debugfs files

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Vasiliy Kulikov <segoon@openwall.com>

commit 8c559d30b4e59cf6994215ada1fe744928f494bf upstream.

Don't allow everybody to dump sensitive information about filesystems.

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ubifs/debug.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/fs/ubifs/debug.c
+++ b/fs/ubifs/debug.c
@@ -2691,19 +2691,19 @@ int dbg_debugfs_init_fs(struct ubifs_inf
 	}
 
 	fname = "dump_lprops";
-	dent = debugfs_create_file(fname, S_IWUGO, d->dfs_dir, c, &dfs_fops);
+	dent = debugfs_create_file(fname, S_IWUSR, d->dfs_dir, c, &dfs_fops);
 	if (IS_ERR(dent))
 		goto out_remove;
 	d->dfs_dump_lprops = dent;
 
 	fname = "dump_budg";
-	dent = debugfs_create_file(fname, S_IWUGO, d->dfs_dir, c, &dfs_fops);
+	dent = debugfs_create_file(fname, S_IWUSR, d->dfs_dir, c, &dfs_fops);
 	if (IS_ERR(dent))
 		goto out_remove;
 	d->dfs_dump_budg = dent;
 
 	fname = "dump_tnc";
-	dent = debugfs_create_file(fname, S_IWUGO, d->dfs_dir, c, &dfs_fops);
+	dent = debugfs_create_file(fname, S_IWUSR, d->dfs_dir, c, &dfs_fops);
 	if (IS_ERR(dent))
 		goto out_remove;
 	d->dfs_dump_tnc = dent;

[04/28] NET: cdc-phonet, handle empty phonet header

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Jiri Slaby <jslaby@suse.cz>

commit 468c3f924f043cad7a04f4f4d5224a2c9bc886c1 upstream.

Currently, for N 5800 XM I get:
cdc_phonet: probe of 1-6:1.10 failed with error -22

It's because phonet_header is empty. Extra altsetting looks like
there:
E 05 24 00 01 10 03 24 ab 05 24 06 0a 0b 04 24 fd  .$....$..$....$.
E 00                                               .

I don't see the header used anywhere so just check if the phonet
descriptor is there, not the structure itself.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Cc: David S. Miller <davem@davemloft.net>
Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/usb/cdc-phonet.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -325,13 +325,13 @@ int usbpn_probe(struct usb_interface *in
 {
 	static const char ifname[] = "usbpn%d";
 	const struct usb_cdc_union_desc *union_header = NULL;
-	const struct usb_cdc_header_desc *phonet_header = NULL;
 	const struct usb_host_interface *data_desc;
 	struct usb_interface *data_intf;
 	struct usb_device *usbdev = interface_to_usbdev(intf);
 	struct net_device *dev;
 	struct usbpn_dev *pnd;
 	u8 *data;
+	int phonet = 0;
 	int len, err;
 
 	data = intf->altsetting->extra;
@@ -352,10 +352,7 @@ int usbpn_probe(struct usb_interface *in
 					(struct usb_cdc_union_desc *)data;
 				break;
 			case 0xAB:
-				if (phonet_header || dlen < 5)
-					break;
-				phonet_header =
-					(struct usb_cdc_header_desc *)data;
+				phonet = 1;
 				break;
 			}
 		}
@@ -363,7 +360,7 @@ int usbpn_probe(struct usb_interface *in
 		len -= dlen;
 	}
 
-	if (!union_header || !phonet_header)
+	if (!union_header || !phonet)
 		return -EINVAL;
 
 	data_intf = usb_ifnum_to_if(usbdev, union_header->bSlaveInterface0);

[05/28] x86: Fix a bogus unwind annotation in lib/semaphore_32.S

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Jan Beulich <JBeulich@novell.com>

commit e938c287ea8d977e079f07464ac69923412663ce upstream.

'simple' would have required specifying current frame address
and return address location manually, but that's obviously not
the case (and not necessary) here.

Signed-off-by: Jan Beulich <jbeulich@novell.com>
LKML-Reference: <4D6D1082020000780003454C@vpn.id2.novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/lib/semaphore_32.S |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/x86/lib/semaphore_32.S
+++ b/arch/x86/lib/semaphore_32.S
@@ -36,7 +36,7 @@
  */
 #ifdef CONFIG_SMP
 ENTRY(__write_lock_failed)
-	CFI_STARTPROC simple
+	CFI_STARTPROC
 	FRAME
 2: 	LOCK_PREFIX
 	addl	$ RW_LOCK_BIAS,(%eax)

[06/28] [IA64] tioca: Fix assignment from incompatible pointer warnings

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Jeff Mahoney <jeffm@suse.com>

commit b4a6b3436531f6c5256e6d60d388c3c28ff1a0e9 upstream.

The prototype for sn_pci_provider->{dma_map,dma_map_consistent} expects
an unsigned long instead of a u64.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/ia64/sn/pci/tioca_provider.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/ia64/sn/pci/tioca_provider.c
+++ b/arch/ia64/sn/pci/tioca_provider.c
@@ -517,7 +517,7 @@ tioca_dma_unmap(struct pci_dev *pdev, dm
  * use the GART mapped mode.
  */
 static u64
-tioca_dma_map(struct pci_dev *pdev, u64 paddr, size_t byte_count, int dma_flags)
+tioca_dma_map(struct pci_dev *pdev, unsigned long paddr, size_t byte_count, int dma_flags)
 {
 	u64 mapaddr;
 

[07/28] [IA64] mca.c: Fix cast from integer to pointer warning

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Jeff Mahoney <jeffm@suse.com>

commit c1d036c4d1cb00b7e8473a2ad0a78f13e13a8183 upstream.

ia64_mca_cpu_init has a void *data local variable that is assigned
the value from either __get_free_pages() or mca_bootmem(). The problem
is that __get_free_pages returns an unsigned long and mca_bootmem, via
alloc_bootmem(), returns a void *. format_mca_init_stack takes the void *,
and it's also used with __pa(), but that casts it to long anyway.

This results in the following build warning:

arch/ia64/kernel/mca.c:1898: warning: assignment makes pointer from
integer without a cast

Cast the return of __get_free_pages to a void * to avoid
the warning.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/ia64/kernel/mca.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -1850,7 +1850,8 @@ ia64_mca_cpu_init(void *cpu_data)
 			data = mca_bootmem();
 			first_time = 0;
 		} else
-			data = __get_free_pages(GFP_KERNEL, get_order(sz));
+			data = (void *)__get_free_pages(GFP_KERNEL,
+							get_order(sz));
 		if (!data)
 			panic("Could not allocate MCA memory for cpu %d\n",
 					cpu);

[08/28] ramfs: fix memleak on no-mmu arch

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Bob Liu <lliubbo@gmail.com>

commit b836aec53e2bce71de1d5415313380688c851477 upstream.

On no-mmu arch, there is a memleak during shmem test.  The cause of this
memleak is ramfs_nommu_expand_for_mapping() added page refcount to 2
which makes iput() can't free that pages.

The simple test file is like this:

  int main(void)
  {
	int i;
	key_t k = ftok("/etc", 42);

	for ( i=0; i<100; ++i) {
		int id = shmget(k, 10000, 0644|IPC_CREAT);
		if (id == -1) {
			printf("shmget error\n");
		}
		if(shmctl(id, IPC_RMID, NULL ) == -1) {
			printf("shm  rm error\n");
			return -1;
		}
	}
	printf("run ok...\n");
	return 0;
  }

And the result:

  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        17912        42408            0            0
  -/+ buffers:              17912        42408
  root:/> shmem
  run ok...
  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        19096        41224            0            0
  -/+ buffers:              19096        41224
  root:/> shmem
  run ok...
  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        20296        40024            0            0
  -/+ buffers:              20296        40024
  ...

After this patch the test result is:(no memleak anymore)

  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        16668        43652            0            0
  -/+ buffers:              16668        43652
  root:/> shmem
  run ok...
  root:/> free
               total         used         free       shared      buffers
  Mem:         60320        16668        43652            0            0
  -/+ buffers:              16668        43652

Signed-off-by: Bob Liu <lliubbo@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/ramfs/file-nommu.c |    1 +
 1 file changed, 1 insertion(+)

--- a/fs/ramfs/file-nommu.c
+++ b/fs/ramfs/file-nommu.c
@@ -111,6 +111,7 @@ int ramfs_nommu_expand_for_mapping(struc
 		SetPageDirty(page);
 
 		unlock_page(page);
+		put_page(page);
 	}
 
 	return 0;

[09/28] MAINTAINERS: update STABLE BRANCH info

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Randy Dunlap <randy.dunlap@oracle.com>

commit d00ebeac5f24f290636f7a895dafc124b2930a08 upstream.

Drop Chris Wright from STABLE maintainers.  He hasn't done STABLE release
work for quite some time.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 MAINTAINERS |    1 -
 1 file changed, 1 deletion(-)

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5010,7 +5010,6 @@ F:	arch/alpha/kernel/srm_env.c
 
 STABLE BRANCH
 M:	Greg Kroah-Hartman <greg@kroah.com>
-M:	Chris Wright <chrisw@sous-sol.org>
 L:	stable@kernel.org
 S:	Maintained
 

[10/28] UBIFS: fix oops when R/O file-system is fsynced

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>

commit 78530bf7f2559b317c04991b52217c1608d5a58d upstream.

This patch fixes severe UBIFS bug: UBIFS oopses when we 'fsync()' an
file on R/O-mounter file-system. We (the UBIFS authors) incorrectly
thought that VFS would not propagate 'fsync()' down to the file-system
if it is read-only, but this is not the case.

It is easy to exploit this bug using the following simple perl script:

use strict;
use File::Sync qw(fsync sync);

die "File path is not specified" if not defined $ARGV[0];
my $path = $ARGV[0];

open FILE, "<", "$path" or die "Cannot open $path: $!";
fsync(\*FILE) or die "cannot fsync $path: $!";
close FILE or die "Cannot close $path: $!";

Thanks to Reuben Dowle <Reuben.Dowle@navico.com> for reporting about this
issue.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reported-by: Reuben Dowle <Reuben.Dowle@navico.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -1311,6 +1311,9 @@ int ubifs_fsync(struct file *file, struc
 
 	dbg_gen("syncing inode %lu", inode->i_ino);
 
+	if (inode->i_sb->s_flags & MS_RDONLY)
+		return 0;
+
 	/*
 	 * VFS has already synchronized dirty pages for this inode. Synchronize
 	 * the inode unless this is a 'datasync()' call.

[11/28] x86, cpu: AMD errata checking framework

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Hans Rosenfeld <hans.rosenfeld@amd.com>

commit d78d671db478eb8b14c78501c0cee1cc7baf6967 upstream.

Errata are defined using the AMD_LEGACY_ERRATUM() or AMD_OSVW_ERRATUM()
macros. The latter is intended for newer errata that have an OSVW id
assigned, which it takes as first argument. Both take a variable number
of family-specific model-stepping ranges created by AMD_MODEL_RANGE().

Iff an erratum has an OSVW id, OSVW is available on the CPU, and the
OSVW id is known to the hardware, it is used to determine whether an
erratum is present. Otherwise, the model-stepping ranges are matched
against the current CPU to find out whether the erratum applies.

For certain special errata, the code using this framework might have to
conduct further checks to make sure an erratum is really (not) present.

Signed-off-by: Hans Rosenfeld <hans.rosenfeld@amd.com>
LKML-Reference: <1280336972-865982-1-git-send-email-hans.rosenfeld@amd.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/include/asm/processor.h |   18 +++++++++++
 arch/x86/kernel/cpu/amd.c        |   60 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 78 insertions(+)

--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -1029,4 +1029,22 @@ unsigned long calc_aperfmperf_ratio(stru
 	return ratio;
 }
 
+/*
+ * AMD errata checking
+ */
+#ifdef CONFIG_CPU_SUP_AMD
+extern bool cpu_has_amd_erratum(const int *);
+
+#define AMD_LEGACY_ERRATUM(...)		{ -1, __VA_ARGS__, 0 }
+#define AMD_OSVW_ERRATUM(osvw_id, ...)	{ osvw_id, __VA_ARGS__, 0 }
+#define AMD_MODEL_RANGE(f, m_start, s_start, m_end, s_end) \
+	((f << 24) | (m_start << 16) | (s_start << 12) | (m_end << 4) | (s_end))
+#define AMD_MODEL_RANGE_FAMILY(range)	(((range) >> 24) & 0xff)
+#define AMD_MODEL_RANGE_START(range)	(((range) >> 12) & 0xfff)
+#define AMD_MODEL_RANGE_END(range)	((range) & 0xfff)
+
+#else
+#define cpu_has_amd_erratum(x)	(false)
+#endif /* CONFIG_CPU_SUP_AMD */
+
 #endif /* _ASM_X86_PROCESSOR_H */
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -610,3 +610,63 @@ static const struct cpu_dev __cpuinitcon
 };
 
 cpu_dev_register(amd_cpu_dev);
+
+/*
+ * AMD errata checking
+ *
+ * Errata are defined as arrays of ints using the AMD_LEGACY_ERRATUM() or
+ * AMD_OSVW_ERRATUM() macros. The latter is intended for newer errata that
+ * have an OSVW id assigned, which it takes as first argument. Both take a
+ * variable number of family-specific model-stepping ranges created by
+ * AMD_MODEL_RANGE(). Each erratum also has to be declared as extern const
+ * int[] in arch/x86/include/asm/processor.h.
+ *
+ * Example:
+ *
+ * const int amd_erratum_319[] =
+ *	AMD_LEGACY_ERRATUM(AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0x4, 0x2),
+ *			   AMD_MODEL_RANGE(0x10, 0x8, 0x0, 0x8, 0x0),
+ *			   AMD_MODEL_RANGE(0x10, 0x9, 0x0, 0x9, 0x0));
+ */
+
+bool cpu_has_amd_erratum(const int *erratum)
+{
+	struct cpuinfo_x86 *cpu = &current_cpu_data;
+	int osvw_id = *erratum++;
+	u32 range;
+	u32 ms;
+
+	/*
+	 * If called early enough that current_cpu_data hasn't been initialized
+	 * yet, fall back to boot_cpu_data.
+	 */
+	if (cpu->x86 == 0)
+		cpu = &boot_cpu_data;
+
+	if (cpu->x86_vendor != X86_VENDOR_AMD)
+		return false;
+
+	if (osvw_id >= 0 && osvw_id < 65536 &&
+	    cpu_has(cpu, X86_FEATURE_OSVW)) {
+		u64 osvw_len;
+
+		rdmsrl(MSR_AMD64_OSVW_ID_LENGTH, osvw_len);
+		if (osvw_id < osvw_len) {
+			u64 osvw_bits;
+
+			rdmsrl(MSR_AMD64_OSVW_STATUS + (osvw_id >> 6),
+			    osvw_bits);
+			return osvw_bits & (1ULL << (osvw_id & 0x3f));
+		}
+	}
+
+	/* OSVW unavailable or ID unknown, match family-model-stepping range */
+	ms = (cpu->x86_model << 8) | cpu->x86_mask;
+	while ((range = *erratum++))
+		if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range)) &&
+		    (ms >= AMD_MODEL_RANGE_START(range)) &&
+		    (ms <= AMD_MODEL_RANGE_END(range)))
+			return true;
+
+	return false;
+}

[12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Hans Rosenfeld <hans.rosenfeld@amd.com>

commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.

Remove check_c1e_idle() and use the new AMD errata checking framework
instead.

Signed-off-by: Hans Rosenfeld <hans.rosenfeld@amd.com>
LKML-Reference: <1280336972-865982-2-git-send-email-hans.rosenfeld@amd.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/include/asm/processor.h |    1 +
 arch/x86/kernel/cpu/amd.c        |    5 +++++
 arch/x86/kernel/process.c        |   39 ++-------------------------------------
 3 files changed, 8 insertions(+), 37 deletions(-)

--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -1033,6 +1033,7 @@ unsigned long calc_aperfmperf_ratio(stru
  * AMD errata checking
  */
 #ifdef CONFIG_CPU_SUP_AMD
+extern const int amd_erratum_400[];
 extern bool cpu_has_amd_erratum(const int *);
 
 #define AMD_LEGACY_ERRATUM(...)		{ -1, __VA_ARGS__, 0 }
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -629,6 +629,11 @@ cpu_dev_register(amd_cpu_dev);
  *			   AMD_MODEL_RANGE(0x10, 0x9, 0x0, 0x9, 0x0));
  */
 
+const int amd_erratum_400[] =
+	AMD_OSVW_ERRATUM(1, AMD_MODEL_RANGE(0xf, 0x41, 0x2, 0xff, 0xf),
+			    AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf));
+
+
 bool cpu_has_amd_erratum(const int *erratum)
 {
 	struct cpuinfo_x86 *cpu = &current_cpu_data;
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -438,42 +438,6 @@ static int __cpuinit mwait_usable(const
 	return (edx & MWAIT_EDX_C1);
 }
 
-/*
- * Check for AMD CPUs, where APIC timer interrupt does not wake up CPU from C1e.
- * For more information see
- * - Erratum #400 for NPT family 0xf and family 0x10 CPUs
- * - Erratum #365 for family 0x11 (not affected because C1e not in use)
- */
-static int __cpuinit check_c1e_idle(const struct cpuinfo_x86 *c)
-{
-	u64 val;
-	if (c->x86_vendor != X86_VENDOR_AMD)
-		goto no_c1e_idle;
-
-	/* Family 0x0f models < rev F do not have C1E */
-	if (c->x86 == 0x0F && c->x86_model >= 0x40)
-		return 1;
-
-	if (c->x86 == 0x10) {
-		/*
-		 * check OSVW bit for CPUs that are not affected
-		 * by erratum #400
-		 */
-		if (cpu_has(c, X86_FEATURE_OSVW)) {
-			rdmsrl(MSR_AMD64_OSVW_ID_LENGTH, val);
-			if (val >= 2) {
-				rdmsrl(MSR_AMD64_OSVW_STATUS, val);
-				if (!(val & BIT(1)))
-					goto no_c1e_idle;
-			}
-		}
-		return 1;
-	}
-
-no_c1e_idle:
-	return 0;
-}
-
 static cpumask_var_t c1e_mask;
 static int c1e_detected;
 
@@ -551,7 +515,8 @@ void __cpuinit select_idle_routine(const
 		 */
 		printk(KERN_INFO "using mwait in idle threads.\n");
 		pm_idle = mwait_idle;
-	} else if (check_c1e_idle(c)) {
+	} else if (cpu_has_amd_erratum(amd_erratum_400)) {
+		/* E400: APIC timer interrupt does not wake up CPU from C1e */
 		printk(KERN_INFO "using C1E aware idle routine\n");
 		pm_idle = c1e_idle;
 	} else

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> 
> commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> 
> Remove check_c1e_idle() and use the new AMD errata checking framework
> instead.

Clean-up patches are generally not candidates for longterm updates.

However, I notice that the range of procesors considered to have erratum
400 was also changed:

[...]
> +const int amd_erratum_400[] =
> +	AMD_OSVW_ERRATUM(1, AMD_MODEL_RANGE(0xf, 0x41, 0x2, 0xff, 0xf),
> +			    AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf));
[...]
> -	/* Family 0x0f models < rev F do not have C1E */
> -	if (c->x86 == 0x0F && c->x86_model >= 0x40)
> -		return 1;
> -
> -	if (c->x86 == 0x10) {
> -		/*
> -		 * check OSVW bit for CPUs that are not affected
> -		 * by erratum #400
> -		 */
> -		if (cpu_has(c, X86_FEATURE_OSVW)) {
[...]
> -		}
> -		return 1;
[...]

Family 0x0f model 0x40 and model 0x41 stepping 0 and 1 are excluded.
Family 0x10 model 0x00, 0x01 and model 0x02 stepping 0 are excluded.
Is that the real fix here?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Greg KH]

On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote:
> On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> > 
> > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> > 
> > Remove check_c1e_idle() and use the new AMD errata checking framework
> > instead.
> 
> Clean-up patches are generally not candidates for longterm updates.

This was added because a follow-on patch required it.

> However, I notice that the range of procesors considered to have erratum
> 400 was also changed:
> 
> [...]
> > +const int amd_erratum_400[] =
> > +	AMD_OSVW_ERRATUM(1, AMD_MODEL_RANGE(0xf, 0x41, 0x2, 0xff, 0xf),
> > +			    AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf));
> [...]
> > -	/* Family 0x0f models < rev F do not have C1E */
> > -	if (c->x86 == 0x0F && c->x86_model >= 0x40)
> > -		return 1;
> > -
> > -	if (c->x86 == 0x10) {
> > -		/*
> > -		 * check OSVW bit for CPUs that are not affected
> > -		 * by erratum #400
> > -		 */
> > -		if (cpu_has(c, X86_FEATURE_OSVW)) {
> [...]
> > -		}
> > -		return 1;
> [...]
> 
> Family 0x0f model 0x40 and model 0x41 stepping 0 and 1 are excluded.
> Family 0x10 model 0x00, 0x01 and model 0x02 stepping 0 are excluded.
> Is that the real fix here?

In this patch, no, it's just infrastructure for a later one.
And I think the bug you noticed here was also fixed in a later patch in
the series, right?

thanks,

greg k-h

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]

On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote:
> On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote:
> > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > 
> > > ------------------
> > > 
> > > From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> > > 
> > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> > > 
> > > Remove check_c1e_idle() and use the new AMD errata checking framework
> > > instead.
> > 
> > Clean-up patches are generally not candidates for longterm updates.
> 
> This was added because a follow-on patch required it.

Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same
condition.

Of course, that could have been backported by referring to the function
that this removes, rather than pulling in a load of other changes with
consequent risk of regressions.

> > However, I notice that the range of procesors considered to have erratum
> > 400 was also changed:
> > 
> > [...]
> > > +const int amd_erratum_400[] =
> > > +	AMD_OSVW_ERRATUM(1, AMD_MODEL_RANGE(0xf, 0x41, 0x2, 0xff, 0xf),
> > > +			    AMD_MODEL_RANGE(0x10, 0x2, 0x1, 0xff, 0xf));
> > [...]
> > > -	/* Family 0x0f models < rev F do not have C1E */
> > > -	if (c->x86 == 0x0F && c->x86_model >= 0x40)
> > > -		return 1;
> > > -
> > > -	if (c->x86 == 0x10) {
> > > -		/*
> > > -		 * check OSVW bit for CPUs that are not affected
> > > -		 * by erratum #400
> > > -		 */
> > > -		if (cpu_has(c, X86_FEATURE_OSVW)) {
> > [...]
> > > -		}
> > > -		return 1;
> > [...]
> > 
> > Family 0x0f model 0x40 and model 0x41 stepping 0 and 1 are excluded.
> > Family 0x10 model 0x00, 0x01 and model 0x02 stepping 0 are excluded.
> > Is that the real fix here?
> 
> In this patch, no, it's just infrastructure for a later one.
> And I think the bug you noticed here was also fixed in a later patch in
> the series, right?

I don't know that it is a bug.  But if you're referring to patch 26/28
'x86, cpu: Fix regression in AMD errata checking code', that fixes a bug
in range checking in the generic function but does not revert this
change.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Greg KH]

On Wed, Apr 20, 2011 at 03:17:42AM +0100, Ben Hutchings wrote:
> On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote:
> > On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote:
> > > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> > > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> > > > 
> > > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> > > > 
> > > > Remove check_c1e_idle() and use the new AMD errata checking framework
> > > > instead.
> > > 
> > > Clean-up patches are generally not candidates for longterm updates.
> > 
> > This was added because a follow-on patch required it.
> 
> Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same
> condition.
> 
> Of course, that could have been backported by referring to the function
> that this removes, rather than pulling in a load of other changes with
> consequent risk of regressions.

I prefer to take original patches for stable, it makes it easier in the
end.

thanks,

greg k-h

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

On Tue, 2011-04-19 at 20:11 -0700, Greg KH wrote:
> On Wed, Apr 20, 2011 at 03:17:42AM +0100, Ben Hutchings wrote:
> > On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote:
> > > On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote:
> > > > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> > > > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > > > 
> > > > > ------------------
> > > > > 
> > > > > From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> > > > > 
> > > > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> > > > > 
> > > > > Remove check_c1e_idle() and use the new AMD errata checking framework
> > > > > instead.
> > > > 
> > > > Clean-up patches are generally not candidates for longterm updates.
> > > 
> > > This was added because a follow-on patch required it.
> > 
> > Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same
> > condition.
> > 
> > Of course, that could have been backported by referring to the function
> > that this removes, rather than pulling in a load of other changes with
> > consequent risk of regressions.
> 
> I prefer to take original patches for stable, it makes it easier in the
> end.

It makes what easier, when?  What I see here is a bug fix that is much
larger than necessary, with a consequent risk of regression that seems
way out of proportion to the benefit.  (What actually *is* the benefit
of these AMD changes?)  And we have had several serious regressions in
the 2.6.32.y series recently, so I really don't think we are getting the
trade-off right.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Greg KH]

On Wed, Apr 20, 2011 at 05:48:30AM +0100, Ben Hutchings wrote:
> On Tue, 2011-04-19 at 20:11 -0700, Greg KH wrote:
> > On Wed, Apr 20, 2011 at 03:17:42AM +0100, Ben Hutchings wrote:
> > > On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote:
> > > > On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote:
> > > > > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> > > > > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > > > > 
> > > > > > ------------------
> > > > > > 
> > > > > > From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> > > > > > 
> > > > > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> > > > > > 
> > > > > > Remove check_c1e_idle() and use the new AMD errata checking framework
> > > > > > instead.
> > > > > 
> > > > > Clean-up patches are generally not candidates for longterm updates.
> > > > 
> > > > This was added because a follow-on patch required it.
> > > 
> > > Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same
> > > condition.
> > > 
> > > Of course, that could have been backported by referring to the function
> > > that this removes, rather than pulling in a load of other changes with
> > > consequent risk of regressions.
> > 
> > I prefer to take original patches for stable, it makes it easier in the
> > end.
> 
> It makes what easier, when?  What I see here is a bug fix that is much
> larger than necessary, with a consequent risk of regression that seems
> way out of proportion to the benefit.  (What actually *is* the benefit
> of these AMD changes?)  And we have had several serious regressions in
> the 2.6.32.y series recently, so I really don't think we are getting the
> trade-off right.

We got a few new quirks added for AMD hardware platforms that fix
problems.  It took 3 patches to get there, yes, but now, as time goes
on, adding new ones is even easier as the .32 code matches the .39 code
in this area due to these patches being added.

Now if you find problems in these, great, let me know and I will work to
resolve them.

As for regressions, what are you referring to?

thanks,

greg k-h

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Willy Tarreau]

On Tue, Apr 19, 2011 at 10:06:17PM -0700, Greg KH wrote:
> On Wed, Apr 20, 2011 at 05:48:30AM +0100, Ben Hutchings wrote:
> > On Tue, 2011-04-19 at 20:11 -0700, Greg KH wrote:
> > > On Wed, Apr 20, 2011 at 03:17:42AM +0100, Ben Hutchings wrote:
> > > > On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote:
> > > > > On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote:
> > > > > > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> > > > > > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > > > > > 
> > > > > > > ------------------
> > > > > > > 
> > > > > > > From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> > > > > > > 
> > > > > > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> > > > > > > 
> > > > > > > Remove check_c1e_idle() and use the new AMD errata checking framework
> > > > > > > instead.
> > > > > > 
> > > > > > Clean-up patches are generally not candidates for longterm updates.
> > > > > 
> > > > > This was added because a follow-on patch required it.
> > > > 
> > > > Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same
> > > > condition.
> > > > 
> > > > Of course, that could have been backported by referring to the function
> > > > that this removes, rather than pulling in a load of other changes with
> > > > consequent risk of regressions.
> > > 
> > > I prefer to take original patches for stable, it makes it easier in the
> > > end.
> > 
> > It makes what easier, when?  What I see here is a bug fix that is much
> > larger than necessary, with a consequent risk of regression that seems
> > way out of proportion to the benefit.  (What actually *is* the benefit
> > of these AMD changes?)  And we have had several serious regressions in
> > the 2.6.32.y series recently, so I really don't think we are getting the
> > trade-off right.
> 
> We got a few new quirks added for AMD hardware platforms that fix
> problems.  It took 3 patches to get there, yes, but now, as time goes
> on, adding new ones is even easier as the .32 code matches the .39 code
> in this area due to these patches being added.

I totally agree with Greg here. I'd say that sometimes it's even unpleasant
to backport apparently useless fixes, but it's needed to get in sync with
mainline. I've had quite a number of backporting issues in 2.4 because some
fixes were backported so much differently that at one point it was not even
possible to know whether a later fix was needed or not, or how to apply it.

Here if we start remodeling patches to make them smaller before backporting
them, we'll get different code and all subsequent fixes will have to be
adapted to this distinct branch. By doing this, we even risk regressions
because at one point we can introduce stable-specific bugs.

Willy

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 3145 bytes --]

On Tue, 2011-04-19 at 22:06 -0700, Greg KH wrote:
> On Wed, Apr 20, 2011 at 05:48:30AM +0100, Ben Hutchings wrote:
> > On Tue, 2011-04-19 at 20:11 -0700, Greg KH wrote:
> > > On Wed, Apr 20, 2011 at 03:17:42AM +0100, Ben Hutchings wrote:
> > > > On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote:
> > > > > On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote:
> > > > > > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote:
> > > > > > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > > > > > 
> > > > > > > ------------------
> > > > > > > 
> > > > > > > From: Hans Rosenfeld <hans.rosenfeld@amd.com>
> > > > > > > 
> > > > > > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream.
> > > > > > > 
> > > > > > > Remove check_c1e_idle() and use the new AMD errata checking framework
> > > > > > > instead.
> > > > > > 
> > > > > > Clean-up patches are generally not candidates for longterm updates.
> > > > > 
> > > > > This was added because a follow-on patch required it.
> > > > 
> > > > Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same
> > > > condition.
> > > > 
> > > > Of course, that could have been backported by referring to the function
> > > > that this removes, rather than pulling in a load of other changes with
> > > > consequent risk of regressions.
> > > 
> > > I prefer to take original patches for stable, it makes it easier in the
> > > end.
> > 
> > It makes what easier, when?  What I see here is a bug fix that is much
> > larger than necessary, with a consequent risk of regression that seems
> > way out of proportion to the benefit.  (What actually *is* the benefit
> > of these AMD changes?)  And we have had several serious regressions in
> > the 2.6.32.y series recently, so I really don't think we are getting the
> > trade-off right.
> 
> We got a few new quirks added for AMD hardware platforms that fix
> problems.

Maybe, but I still haven't seen anyone explain what those problems are!

> It took 3 patches to get there, yes, but now, as time goes
> on, adding new ones is even easier as the .32 code matches the .39 code
> in this area due to these patches being added.
> 
> Now if you find problems in these, great, let me know and I will work to
> resolve them.
> 
> As for regressions, what are you referring to?

These are the regressions I'm aware of in the last few updates:

2.6.32.36: 'x86: Cleanup highmap after brk is concluded' broke
hibernation on x86-64 and some x86-32 machines (reverted in .37)
2.6.32.36: 'signal: Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from
spoofing the signal code' broke glibc aio (fixed in .37)
2.6.32.34: powerpc kdump/kexec changes didn't compile on UP or 32-bit
(fixed in .37)
2.6.32.30: 'x86 quirk: Fix polarity for IRQ0 pin2 override on SB800
systems' broke the revision check for other quirks (fixed in .34)
2.6.32.29: 'USB: Prevent buggy hubs from crashing the USB stack' broke
MUSB on BeagleBoards (still unfixed?)
 
Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Greg KH]

On Thu, Apr 21, 2011 at 04:29:15AM +0100, Ben Hutchings wrote:
> > We got a few new quirks added for AMD hardware platforms that fix
> > problems.
> 
> Maybe, but I still haven't seen anyone explain what those problems are!

I'll let the AMD people answer this.

> > It took 3 patches to get there, yes, but now, as time goes
> > on, adding new ones is even easier as the .32 code matches the .39 code
> > in this area due to these patches being added.
> > 
> > Now if you find problems in these, great, let me know and I will work to
> > resolve them.
> > 
> > As for regressions, what are you referring to?
> 
> These are the regressions I'm aware of in the last few updates:
> 
> 2.6.32.36: 'x86: Cleanup highmap after brk is concluded' broke
> hibernation on x86-64 and some x86-32 machines (reverted in .37)
> 2.6.32.36: 'signal: Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from
> spoofing the signal code' broke glibc aio (fixed in .37)
> 2.6.32.34: powerpc kdump/kexec changes didn't compile on UP or 32-bit
> (fixed in .37)
> 2.6.32.30: 'x86 quirk: Fix polarity for IRQ0 pin2 override on SB800
> systems' broke the revision check for other quirks (fixed in .34)

Bugs are always a part of life, the fact that we fix them is what is
important.

> 2.6.32.29: 'USB: Prevent buggy hubs from crashing the USB stack' broke
> MUSB on BeagleBoards (still unfixed?)

This woried me, as I don't recall anyone notifying me of it.  Then I saw
your revert, and I noticed that all you really need to resolve this is
commit id ec95d35a6bd0047f05fe8a21e6c52f8bb418da55 to be added to the
tree.  I'll go queue that one up for the next .32-stable tree.

So all should be resolved now, right?

thanks,

greg k-h

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Borislav Petkov]

Hey Ben,

On Thu, May 05, 2011 at 03:53:02PM -0700, Greg KH wrote:
> On Thu, Apr 21, 2011 at 04:29:15AM +0100, Ben Hutchings wrote:
> > > We got a few new quirks added for AMD hardware platforms that fix
> > > problems.
> > 
> > Maybe, but I still haven't seen anyone explain what those problems are!
> 
> I'll let the AMD people answer this.

it's hard to follow back in this thread to what exactly you'd like to
have answered. Can you please repeat your questions concerning the AMD
backports? Is it, per chance, about Erratum 400 CPU f/m/s ranges that
got changed?

Thanks.

-- 
Regards/Gruss,
    Boris.

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

On Fri, 2011-05-06 at 09:41 +0200, Borislav Petkov wrote:
> Hey Ben,
> 
> On Thu, May 05, 2011 at 03:53:02PM -0700, Greg KH wrote:
> > On Thu, Apr 21, 2011 at 04:29:15AM +0100, Ben Hutchings wrote:
> > > > We got a few new quirks added for AMD hardware platforms that fix
> > > > problems.
> > > 
> > > Maybe, but I still haven't seen anyone explain what those problems are!
> > 
> > I'll let the AMD people answer this.
> 
> it's hard to follow back in this thread to what exactly you'd like to
> have answered. Can you please repeat your questions concerning the AMD
> backports? Is it, per chance, about Erratum 400 CPU f/m/s ranges that
> got changed?

I read that:

"
    Support for Always Running APIC timer (ARAT) was introduced in
    commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
    allows us to avoid switching timers from LAPIC to something else
    (e.g. HPET) and go into timer broadcasts when entering deep
    C-states.
    
    AMD processors don't provide a CPUID bit for that feature but
    they also keep APIC timers running in deep C-states (except for
    cases when the processor is affected by erratum 400). Therefore
    we should set ARAT feature bit on AMD CPUs.
"

This implies that the HPET was previously used during deep C-states, and
that all this erratum checking is about deciding whether the CPU has
ARAT.  So what bug is being fixed by using ARAT instead of the HPET?

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Borislav Petkov]

On Tue, May 10, 2011 at 08:58:59AM -0400, Ben Hutchings wrote:
> I read that:
> 
> "
>     Support for Always Running APIC timer (ARAT) was introduced in
>     commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
>     allows us to avoid switching timers from LAPIC to something else
>     (e.g. HPET) and go into timer broadcasts when entering deep
>     C-states.
>     
>     AMD processors don't provide a CPUID bit for that feature but
>     they also keep APIC timers running in deep C-states (except for
>     cases when the processor is affected by erratum 400). Therefore
>     we should set ARAT feature bit on AMD CPUs.
> "
> 
> This implies that the HPET was previously used during deep C-states, and
> that all this erratum checking is about deciding whether the CPU has
> ARAT.  So what bug is being fixed by using ARAT instead of the HPET?

That's a good question, actually. The original upstream commit
b87cf80af3ba4b4c008b4face3c68d604e1715c6 wasn't tagged for stable and
Boris O. didn't send it to stable either, as I'm being told.

Maybe Greg has an idea?

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Greg KH]

On Tue, May 10, 2011 at 04:02:19PM +0200, Borislav Petkov wrote:
> On Tue, May 10, 2011 at 08:58:59AM -0400, Ben Hutchings wrote:
> > I read that:
> > 
> > "
> >     Support for Always Running APIC timer (ARAT) was introduced in
> >     commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
> >     allows us to avoid switching timers from LAPIC to something else
> >     (e.g. HPET) and go into timer broadcasts when entering deep
> >     C-states.
> >     
> >     AMD processors don't provide a CPUID bit for that feature but
> >     they also keep APIC timers running in deep C-states (except for
> >     cases when the processor is affected by erratum 400). Therefore
> >     we should set ARAT feature bit on AMD CPUs.
> > "
> > 
> > This implies that the HPET was previously used during deep C-states, and
> > that all this erratum checking is about deciding whether the CPU has
> > ARAT.  So what bug is being fixed by using ARAT instead of the HPET?
> 
> That's a good question, actually. The original upstream commit
> b87cf80af3ba4b4c008b4face3c68d604e1715c6 wasn't tagged for stable and
> Boris O. didn't send it to stable either, as I'm being told.
> 
> Maybe Greg has an idea?

I added it because it was needed to get another errata patch to apply
properly, and I saw no reason not to apply other "quirks" like this to
older kernels, right?

Or should I not have done that?

thanks,

greg k-h

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Borislav Petkov]

On Tue, May 10, 2011 at 08:13:05AM -0700, Greg KH wrote:
> On Tue, May 10, 2011 at 04:02:19PM +0200, Borislav Petkov wrote:
> > On Tue, May 10, 2011 at 08:58:59AM -0400, Ben Hutchings wrote:
> > > I read that:
> > > 
> > > "
> > >     Support for Always Running APIC timer (ARAT) was introduced in
> > >     commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
> > >     allows us to avoid switching timers from LAPIC to something else
> > >     (e.g. HPET) and go into timer broadcasts when entering deep
> > >     C-states.
> > >     
> > >     AMD processors don't provide a CPUID bit for that feature but
> > >     they also keep APIC timers running in deep C-states (except for
> > >     cases when the processor is affected by erratum 400). Therefore
> > >     we should set ARAT feature bit on AMD CPUs.
> > > "
> > > 
> > > This implies that the HPET was previously used during deep C-states, and
> > > that all this erratum checking is about deciding whether the CPU has
> > > ARAT.  So what bug is being fixed by using ARAT instead of the HPET?
> > 
> > That's a good question, actually. The original upstream commit
> > b87cf80af3ba4b4c008b4face3c68d604e1715c6 wasn't tagged for stable and
> > Boris O. didn't send it to stable either, as I'm being told.
> > 
> > Maybe Greg has an idea?
> 
> I added it because it was needed to get another errata patch to apply
> properly, and I saw no reason not to apply other "quirks" like this to
> older kernels, right?
> 
> Or should I not have done that?

Nah, I wouldn't say that. While this patch doesn't directly fix a
regression, it does away with the erratum 400 workaround where we switch
to HPET so it is more or less a regression fix for current and future
machines which aren't affected by that erratum. Besides reading the
LAPIC is much cheaper so we should be getting even a slight performance
bump with it.

So no, I don't see a problem with the patch being in stable.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [Stable-review] [12/28] x86, cpu: Clean up AMD erratum 400 workaround

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 697 bytes --]

On Thu, 2011-05-05 at 15:53 -0700, Greg KH wrote:
> On Thu, Apr 21, 2011 at 04:29:15AM +0100, Ben Hutchings wrote:
[...]
> > 2.6.32.29: 'USB: Prevent buggy hubs from crashing the USB stack' broke
> > MUSB on BeagleBoards (still unfixed?)
> 
> This woried me, as I don't recall anyone notifying me of it.  Then I saw
> your revert, and I noticed that all you really need to resolve this is
> commit id ec95d35a6bd0047f05fe8a21e6c52f8bb418da55 to be added to the
> tree.  I'll go queue that one up for the next .32-stable tree.
> 
> So all should be resolved now, right?

Yes, thanks.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

[13/28] x86, AMD: Set ARAT feature on AMD processors

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Boris Ostrovsky <boris.ostrovsky@amd.com>

commit b87cf80af3ba4b4c008b4face3c68d604e1715c6 upstream.

Support for Always Running APIC timer (ARAT) was introduced in
commit db954b5898dd3ef3ef93f4144158ea8f97deb058. This feature
allows us to avoid switching timers from LAPIC to something else
(e.g. HPET) and go into timer broadcasts when entering deep
C-states.

AMD processors don't provide a CPUID bit for that feature but
they also keep APIC timers running in deep C-states (except for
cases when the processor is affected by erratum 400). Therefore
we should set ARAT feature bit on AMD CPUs.

Tested-by: Borislav Petkov <borislav.petkov@amd.com>
Acked-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Acked-by: Mark Langsdorf <mark.langsdorf@amd.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
LKML-Reference: <1300205624-4813-1-git-send-email-ostr@amd64.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/cpu/amd.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -566,6 +566,10 @@ static void __cpuinit init_amd(struct cp
 		}
 	}
 #endif
+
+	/* As a rule processors have APIC timer running in deep C states */
+	if (c->x86 >= 0xf && !cpu_has_amd_erratum(amd_erratum_400))
+		set_cpu_cap(c, X86_FEATURE_ARAT);
 }
 
 #ifdef CONFIG_X86_32

[14/28] x86, amd: Disable GartTlbWlkErr when BIOS forgets it

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Joerg Roedel <joerg.roedel@amd.com>

commit 5bbc097d890409d8eff4e3f1d26f11a9d6b7c07e upstream.

This patch disables GartTlbWlk errors on AMD Fam10h CPUs if
the BIOS forgets to do is (or is just too old). Letting
these errors enabled can cause a sync-flood on the CPU
causing a reboot.

The AMD BKDG recommends disabling GART TLB Wlk Error completely.

This patch is the fix for

	https://bugzilla.kernel.org/show_bug.cgi?id=33012

on my machine.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Link: http://lkml.kernel.org/r/20110415131152.GJ18463@8bytes.org
Tested-by: Alexandre Demers <alexandre.f.demers@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/include/asm/msr-index.h |    4 ++++
 arch/x86/kernel/cpu/amd.c        |   19 +++++++++++++++++++
 2 files changed, 23 insertions(+)

--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -81,11 +81,15 @@
 #define MSR_IA32_MC0_ADDR		0x00000402
 #define MSR_IA32_MC0_MISC		0x00000403
 
+#define MSR_AMD64_MC0_MASK		0xc0010044
+
 #define MSR_IA32_MCx_CTL(x)		(MSR_IA32_MC0_CTL + 4*(x))
 #define MSR_IA32_MCx_STATUS(x)		(MSR_IA32_MC0_STATUS + 4*(x))
 #define MSR_IA32_MCx_ADDR(x)		(MSR_IA32_MC0_ADDR + 4*(x))
 #define MSR_IA32_MCx_MISC(x)		(MSR_IA32_MC0_MISC + 4*(x))
 
+#define MSR_AMD64_MCx_MASK(x)		(MSR_AMD64_MC0_MASK + (x))
+
 /* These are consecutive and not in the normal 4er MCE bank block */
 #define MSR_IA32_MC0_CTL2		0x00000280
 #define MSR_IA32_MCx_CTL2(x)		(MSR_IA32_MC0_CTL2 + (x))
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -570,6 +570,25 @@ static void __cpuinit init_amd(struct cp
 	/* As a rule processors have APIC timer running in deep C states */
 	if (c->x86 >= 0xf && !cpu_has_amd_erratum(amd_erratum_400))
 		set_cpu_cap(c, X86_FEATURE_ARAT);
+
+	/*
+	 * Disable GART TLB Walk Errors on Fam10h. We do this here
+	 * because this is always needed when GART is enabled, even in a
+	 * kernel which has no MCE support built in.
+	 */
+	if (c->x86 == 0x10) {
+		/*
+		 * BIOS should disable GartTlbWlk Errors themself. If
+		 * it doesn't do it here as suggested by the BKDG.
+		 *
+		 * Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=33012
+		 */
+		u64 mask;
+
+		rdmsrl(MSR_AMD64_MCx_MASK(4), mask);
+		mask |= (1 << 10);
+		wrmsrl(MSR_AMD64_MCx_MASK(4), mask);
+	}
 }
 
 #ifdef CONFIG_X86_32

[15/28] USB: ftdi_sio: Added IDs for CTI USB Serial Devices

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Christian Simon <simon@swine.de>

commit 5a9443f08c83c294c5c806a689c1184b27cb26b3 upstream.

I added new ProdutIds for two devices from CTI GmbH Leipzig.

Signed-off-by: Christian Simon <simon@swine.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/ftdi_sio.c     |    2 ++
 drivers/usb/serial/ftdi_sio_ids.h |    9 +++++++++
 2 files changed, 11 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -155,6 +155,8 @@ static struct ftdi_sio_quirk ftdi_stmcli
  * /sys/bus/usb/ftdi_sio/new_id, then send patch/report!
  */
 static struct usb_device_id id_table_combined [] = {
+	{ USB_DEVICE(FTDI_VID, FTDI_CTI_MINI_PID) },
+	{ USB_DEVICE(FTDI_VID, FTDI_CTI_NANO_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_AMC232_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_CANUSB_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_CANDAPTER_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1147,3 +1147,12 @@
 #define QIHARDWARE_VID			0x20B7
 #define MILKYMISTONE_JTAGSERIAL_PID	0x0713
 
+/*
+ * CTI GmbH RS485 Converter http://www.cti-lean.com/
+ */
+/* USB-485-Mini*/
+#define FTDI_CTI_MINI_PID	0xF608
+/* USB-Nano-485*/
+#define FTDI_CTI_NANO_PID	0xF60B
+
+

[16/28] USB: ftdi_sio: add PID for OCT DK201 docking station

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Johan Hovold <jhovold@gmail.com>

commit 11a31d84129dc3133417d626643d714c9df5317e upstream.

Add PID 0x0103 for serial port of the OCT DK201 docking station.

Reported-by: Jan Hoogenraad <jan@hoogenraad.net>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/ftdi_sio.c     |    1 +
 drivers/usb/serial/ftdi_sio_ids.h |    1 +
 2 files changed, 2 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -531,6 +531,7 @@ static struct usb_device_id id_table_com
 	{ USB_DEVICE(SEALEVEL_VID, SEALEVEL_2803_8_PID) },
 	{ USB_DEVICE(IDTECH_VID, IDTECH_IDT1221U_PID) },
 	{ USB_DEVICE(OCT_VID, OCT_US101_PID) },
+	{ USB_DEVICE(OCT_VID, OCT_DK201_PID) },
 	{ USB_DEVICE(FTDI_VID, FTDI_HE_TIRA1_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_HE_TIRA1_quirk },
 	{ USB_DEVICE(FTDI_VID, FTDI_USB_UIRT_PID),
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -579,6 +579,7 @@
 /* Note: OCT US101 is also rebadged as Dick Smith Electronics (NZ) XH6381 */
 /* Also rebadged as Dick Smith Electronics (Aus) XH6451 */
 /* Also rebadged as SIIG Inc. model US2308 hardware version 1 */
+#define OCT_DK201_PID		0x0103	/* OCT DK201 USB docking station */
 #define OCT_US101_PID		0x0421	/* OCT US101 USB to RS-232 */
 
 /*

[17/28] USB: ftdi_sio: add ids for Hameg HO720 and HO730

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Paul Friedrich <Paul.Friedrich@hameg.com>

commit c53c2fab40cf16e13af66f40bfd27200cda98d2f upstream.

usb serial: ftdi_sio: add two missing USB ID's for Hameg interfaces HO720
and HO730

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/ftdi_sio.c     |    2 ++
 drivers/usb/serial/ftdi_sio_ids.h |    2 ++
 2 files changed, 4 insertions(+)

--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -793,6 +793,8 @@ static struct usb_device_id id_table_com
 	{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
 	{ USB_DEVICE(FTDI_VID, HAMEG_HO820_PID) },
+	{ USB_DEVICE(FTDI_VID, HAMEG_HO720_PID) },
+	{ USB_DEVICE(FTDI_VID, HAMEG_HO730_PID) },
 	{ USB_DEVICE(FTDI_VID, HAMEG_HO870_PID) },
 	{ USB_DEVICE(FTDI_VID, MJSG_GENERIC_PID) },
 	{ USB_DEVICE(FTDI_VID, MJSG_SR_RADIO_PID) },
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -300,6 +300,8 @@
  * Hameg HO820 and HO870 interface (using VID 0x0403)
  */
 #define        HAMEG_HO820_PID         0xed74
+#define HAMEG_HO730_PID			0xed73
+#define HAMEG_HO720_PID			0xed72
 #define        HAMEG_HO870_PID         0xed71
 
 /*

[18/28] USB: option: Add new ONDA vendor id and product id for ONDA MT825UP

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Enrico Mioso <mrkiko.rs@gmail.com>

commit c6991b6fd2b4201174dc4620d0c8c4f5ff27b36f upstream.

This patch, adds to the option driver the Onda Communication
(http://www.ondacommunication.com) vendor id, and the MT825UP modem
device id.

Note that many variants of this same device are being release here in
Italy (at least one or two per telephony operator).

These devices are perfectly equivalent except for some predefined
settings (which can be changed of course).

It should be noted that most ONDA devices are allready supported (they
used other vendor's ids in the past). The patch seems working fine here,
and the rest of the driver seems uninfluenced.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/option.c |    7 +++++++
 1 file changed, 7 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -388,6 +388,12 @@ static int  option_resume(struct usb_ser
 #define CELOT_VENDOR_ID				0x211f
 #define CELOT_PRODUCT_CT680M			0x6801
 
+/* ONDA Communication vendor id */
+#define ONDA_VENDOR_ID       0x1ee8
+
+/* ONDA MT825UP HSDPA 14.2 modem */
+#define ONDA_MT825UP         0x000b
+
 static struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -917,6 +923,7 @@ static struct usb_device_id option_ids[]
 
 	{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
 	{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA 450 1xEVDO modem */
+	{ USB_DEVICE(ONDA_VENDOR_ID, ONDA_MT825UP) }, /* ONDA MT825UP modem */
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

[19/28] USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem.

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Marius B. Kotsbak <marius@kotsbak.com>

commit 80f9df3e0093ad9f1eeefd2ff7fd27daaa518d25 upstream.

Bind only modem AT command endpoint to option.

Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/serial/option.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -394,6 +394,10 @@ static int  option_resume(struct usb_ser
 /* ONDA MT825UP HSDPA 14.2 modem */
 #define ONDA_MT825UP         0x000b
 
+/* Samsung products */
+#define SAMSUNG_VENDOR_ID                       0x04e8
+#define SAMSUNG_PRODUCT_GT_B3730                0x6889
+
 static struct usb_device_id option_ids[] = {
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
 	{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -924,6 +928,7 @@ static struct usb_device_id option_ids[]
 	{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
 	{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA 450 1xEVDO modem */
 	{ USB_DEVICE(ONDA_VENDOR_ID, ONDA_MT825UP) }, /* ONDA MT825UP modem */
+	{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung GT-B3730/GT-B3710 LTE USB modem.*/
 	{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

[20/28] next_pidmap: fix overflow condition

[Greg KH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2291 bytes --]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

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

commit c78193e9c7bcbf25b8237ad0dec82f805c4ea69b upstream.

next_pidmap() just quietly accepted whatever 'last' pid that was passed
in, which is not all that safe when one of the users is /proc.

Admittedly the proc code should do some sanity checking on the range
(and that will be the next commit), but that doesn't mean that the
helper functions should just do that pidmap pointer arithmetic without
checking the range of its arguments.

So clamp 'last' to PID_MAX_LIMIT.  The fact that we then do "last+1"
doesn't really matter, the for-loop does check against the end of the
pidmap array properly (it's only the actual pointer arithmetic overflow
case we need to worry about, and going one bit beyond isn't going to
overflow).

[ Use PID_MAX_LIMIT rather than pid_max as per Eric Biederman ]

Reported-by: Tavis Ormandy <taviso@cmpxchg8b.com>
Analyzed-by: Robert Święcki <robert@swiecki.net>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/linux/pid.h |    2 +-
 kernel/pid.c        |    5 ++++-
 2 files changed, 5 insertions(+), 2 deletions(-)

--- a/include/linux/pid.h
+++ b/include/linux/pid.h
@@ -117,7 +117,7 @@ extern struct pid *find_vpid(int nr);
  */
 extern struct pid *find_get_pid(int nr);
 extern struct pid *find_ge_pid(int nr, struct pid_namespace *);
-int next_pidmap(struct pid_namespace *pid_ns, int last);
+int next_pidmap(struct pid_namespace *pid_ns, unsigned int last);
 
 extern struct pid *alloc_pid(struct pid_namespace *ns);
 extern void free_pid(struct pid *pid);
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -182,11 +182,14 @@ static int alloc_pidmap(struct pid_names
 	return -1;
 }
 
-int next_pidmap(struct pid_namespace *pid_ns, int last)
+int next_pidmap(struct pid_namespace *pid_ns, unsigned int last)
 {
 	int offset;
 	struct pidmap *map, *end;
 
+	if (last >= PID_MAX_LIMIT)
+		return -1;
+
 	offset = (last + 1) & BITS_PER_PAGE_MASK;
 	map = &pid_ns->pidmap[(last + 1)/BITS_PER_PAGE];
 	end = &pid_ns->pidmap[PIDMAP_ENTRIES];

[21/28] proc: do proper range check on readdir offset

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

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

commit d8bdc59f215e62098bc5b4256fd9928bf27053a1 upstream.

Rather than pass in some random truncated offset to the pid-related
functions, check that the offset is in range up-front.

This is just cleanup, the previous commit fixed the real problem.

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

---
 fs/proc/base.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2806,11 +2806,16 @@ static int proc_pid_fill_cache(struct fi
 /* for the /proc/ directory itself, after non-process stuff has been done */
 int proc_pid_readdir(struct file * filp, void * dirent, filldir_t filldir)
 {
-	unsigned int nr = filp->f_pos - FIRST_PROCESS_ENTRY;
-	struct task_struct *reaper = get_proc_task(filp->f_path.dentry->d_inode);
+	unsigned int nr;
+	struct task_struct *reaper;
 	struct tgid_iter iter;
 	struct pid_namespace *ns;
 
+	if (filp->f_pos >= PID_MAX_LIMIT + TGID_OFFSET)
+		goto out_no_task;
+	nr = filp->f_pos - FIRST_PROCESS_ENTRY;
+
+	reaper = get_proc_task(filp->f_path.dentry->d_inode);
 	if (!reaper)
 		goto out_no_task;
 

[22/28] USB: EHCI: unlink unused QHs when the controller is stopped

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Alan Stern <stern@rowland.harvard.edu>

commit 94ae4976e253757e9b03a44d27d41b20f1829d80 upstream.

This patch (as1458) fixes a problem affecting ultra-reliable systems:
When hardware failover of an EHCI controller occurs, the data
structures do not get released correctly.  This is because the routine
responsible for removing unused QHs from the async schedule assumes
the controller is running properly (the frame counter is used in
determining how long the QH has been idle) -- but when a failover
causes the controller to be electronically disconnected from the PCI
bus, obviously it stops running.

The solution is simple: Allow scan_async() to remove a QH from the
async schedule if it has been idle for long enough _or_ if the
controller is stopped.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-Tested-by: Dan Duval <dan.duval@stratus.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ehci-q.c |   15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1224,24 +1224,27 @@ static void start_unlink_async (struct e
 
 static void scan_async (struct ehci_hcd *ehci)
 {
+	bool			stopped;
 	struct ehci_qh		*qh;
 	enum ehci_timer_action	action = TIMER_IO_WATCHDOG;
 
 	ehci->stamp = ehci_readl(ehci, &ehci->regs->frame_index);
 	timer_action_done (ehci, TIMER_ASYNC_SHRINK);
 rescan:
+	stopped = !HC_IS_RUNNING(ehci_to_hcd(ehci)->state);
 	qh = ehci->async->qh_next.qh;
 	if (likely (qh != NULL)) {
 		do {
 			/* clean any finished work for this qh */
-			if (!list_empty (&qh->qtd_list)
-					&& qh->stamp != ehci->stamp) {
+			if (!list_empty(&qh->qtd_list) && (stopped ||
+					qh->stamp != ehci->stamp)) {
 				int temp;
 
 				/* unlinks could happen here; completion
 				 * reporting drops the lock.  rescan using
 				 * the latest schedule, but don't rescan
-				 * qhs we already finished (no looping).
+				 * qhs we already finished (no looping)
+				 * unless the controller is stopped.
 				 */
 				qh = qh_get (qh);
 				qh->stamp = ehci->stamp;
@@ -1262,9 +1265,9 @@ rescan:
 			 */
 			if (list_empty(&qh->qtd_list)
 					&& qh->qh_state == QH_STATE_LINKED) {
-				if (!ehci->reclaim
-					&& ((ehci->stamp - qh->stamp) & 0x1fff)
-						>= (EHCI_SHRINK_FRAMES * 8))
+				if (!ehci->reclaim && (stopped ||
+					((ehci->stamp - qh->stamp) & 0x1fff)
+						>= EHCI_SHRINK_FRAMES * 8))
 					start_unlink_async(ehci, qh);
 				else
 					action = TIMER_ASYNC_SHRINK;

[23/28] USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Dmitry Torokhov <dtor@vmware.com>

commit 2868a2b1ba8f9c7f6c4170519ebb6c62934df70e upstream.

Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
for decoding bInterval values as HighSpeed ones so adjust the code
accordingly.

Also bandwidth reservation for SuperSpeed matches highspeed, not
low/full speed.

Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/devices.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/usb/core/devices.c
+++ b/drivers/usb/core/devices.c
@@ -211,7 +211,7 @@ static char *usb_dump_endpoint_descripto
 		break;
 	case USB_ENDPOINT_XFER_INT:
 		type = "Int.";
-		if (speed == USB_SPEED_HIGH)
+		if (speed == USB_SPEED_HIGH || speed == USB_SPEED_SUPER)
 			interval = 1 << (desc->bInterval - 1);
 		else
 			interval = desc->bInterval;
@@ -219,7 +219,8 @@ static char *usb_dump_endpoint_descripto
 	default:	/* "can't happen" */
 		return start;
 	}
-	interval *= (speed == USB_SPEED_HIGH) ? 125 : 1000;
+	interval *= (speed == USB_SPEED_HIGH ||
+		     speed == USB_SPEED_SUPER) ? 125 : 1000;
 	if (interval % 1000)
 		unit = 'u';
 	else {
@@ -529,8 +530,9 @@ static ssize_t usb_device_dump(char __us
 	if (level == 0) {
 		int	max;
 
-		/* high speed reserves 80%, full/low reserves 90% */
-		if (usbdev->speed == USB_SPEED_HIGH)
+		/* super/high speed reserves 80%, full/low reserves 90% */
+		if (usbdev->speed == USB_SPEED_HIGH ||
+		    usbdev->speed == USB_SPEED_SUPER)
 			max = 800;
 		else
 			max = FRAME_TIME_MAX_USECS_ALLOC;

[24/28] USB: xhci - fix unsafe macro definitions

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Dmitry Torokhov <dtor@vmware.com>

commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.

Macro arguments used in expressions need to be enclosed in parenthesis
to avoid unpleasant surprises.

This should be queued for kernels back to 2.6.31

Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/xhci.h |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -232,7 +232,7 @@ struct xhci_op_regs {
  * notification type that matches a bit set in this bit field.
  */
 #define	DEV_NOTE_MASK		(0xffff)
-#define ENABLE_DEV_NOTE(x)	(1 << x)
+#define ENABLE_DEV_NOTE(x)	(1 << (x))
 /* Most of the device notification types should only be used for debug.
  * SW does need to pay attention to function wake notifications.
  */
@@ -579,11 +579,11 @@ struct xhci_ep_ctx {
 #define EP_STATE_STOPPED	3
 #define EP_STATE_ERROR		4
 /* Mult - Max number of burtst within an interval, in EP companion desc. */
-#define EP_MULT(p)		((p & 0x3) << 8)
+#define EP_MULT(p)		(((p) & 0x3) << 8)
 /* bits 10:14 are Max Primary Streams */
 /* bit 15 is Linear Stream Array */
 /* Interval - period between requests to an endpoint - 125u increments. */
-#define EP_INTERVAL(p)		((p & 0xff) << 16)
+#define EP_INTERVAL(p)		(((p) & 0xff) << 16)
 #define EP_INTERVAL_TO_UFRAMES(p)		(1 << (((p) >> 16) & 0xff))
 
 /* ep_info2 bitmasks */

Re: [Stable-review] [24/28] USB: xhci - fix unsafe macro definitions

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Tue, 2011-04-19 at 13:31 -0700, Greg KH wrote:
> 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> From: Dmitry Torokhov <dtor@vmware.com>
> 
> commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.
> 
> Macro arguments used in expressions need to be enclosed in parenthesis
> to avoid unpleasant surprises.

Do you know of any specific uses of these macros where the missing
parentheses caused 'unpleasant surprises'?

Ben.

> This should be queued for kernels back to 2.6.31
> 
> Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  drivers/usb/host/xhci.h |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -232,7 +232,7 @@ struct xhci_op_regs {
>   * notification type that matches a bit set in this bit field.
>   */
>  #define	DEV_NOTE_MASK		(0xffff)
> -#define ENABLE_DEV_NOTE(x)	(1 << x)
> +#define ENABLE_DEV_NOTE(x)	(1 << (x))
>  /* Most of the device notification types should only be used for debug.
>   * SW does need to pay attention to function wake notifications.
>   */
> @@ -579,11 +579,11 @@ struct xhci_ep_ctx {
>  #define EP_STATE_STOPPED	3
>  #define EP_STATE_ERROR		4
>  /* Mult - Max number of burtst within an interval, in EP companion desc. */
> -#define EP_MULT(p)		((p & 0x3) << 8)
> +#define EP_MULT(p)		(((p) & 0x3) << 8)
>  /* bits 10:14 are Max Primary Streams */
>  /* bit 15 is Linear Stream Array */
>  /* Interval - period between requests to an endpoint - 125u increments. */
> -#define EP_INTERVAL(p)		((p & 0xff) << 16)
> +#define EP_INTERVAL(p)		(((p) & 0xff) << 16)
>  #define EP_INTERVAL_TO_UFRAMES(p)		(1 << (((p) >> 16) & 0xff))
>  
>  /* ep_info2 bitmasks */
> 
> 
> _______________________________________________
> Stable-review mailing list
> Stable-review@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/stable-review
> 

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [24/28] USB: xhci - fix unsafe macro definitions

[Willy Tarreau]

On Wed, Apr 20, 2011 at 03:02:04AM +0100, Ben Hutchings wrote:
> On Tue, 2011-04-19 at 13:31 -0700, Greg KH wrote:
> > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Dmitry Torokhov <dtor@vmware.com>
> > 
> > commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.
> > 
> > Macro arguments used in expressions need to be enclosed in parenthesis
> > to avoid unpleasant surprises.
> 
> Do you know of any specific uses of these macros where the missing
> parentheses caused 'unpleasant surprises'?

In my opinion, this type of fix should be backported even if the current
code does not appear to be at risk, otherwise a later fix in the kernel
could cause a serious regression when backported to -stable. For instance,
if we later have to backport this patch (cut'n'pasted) :

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1033,7 +1033,7 @@ static inline unsigned int xhci_get_endpoint_interval(struct usb_device *udev,
        default:
                BUG();
        }
-       return EP_INTERVAL(interval);
+       return EP_INTERVAL(interval + 1);
 }

How can you guess that while works in mainline, it breaks -stable ?

As a user, I'd rather have known valid code in -stable and -longterm at the
risk of an occasional *temporary* regression than longterm unexplainable
regressions due to diverging code causing unexpected issues with backported
fixes.

Regards,
Willy

Re: [Stable-review] [24/28] USB: xhci - fix unsafe macro definitions

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Wed, 2011-04-20 at 07:39 +0200, Willy Tarreau wrote:
> On Wed, Apr 20, 2011 at 03:02:04AM +0100, Ben Hutchings wrote:
> > On Tue, 2011-04-19 at 13:31 -0700, Greg KH wrote:
> > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > 
> > > ------------------
> > > 
> > > From: Dmitry Torokhov <dtor@vmware.com>
> > > 
> > > commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.
> > > 
> > > Macro arguments used in expressions need to be enclosed in parenthesis
> > > to avoid unpleasant surprises.
> > 
> > Do you know of any specific uses of these macros where the missing
> > parentheses caused 'unpleasant surprises'?
> 
> In my opinion, this type of fix should be backported even if the current
> code does not appear to be at risk, otherwise a later fix in the kernel
> could cause a serious regression when backported to -stable. For instance,
> if we later have to backport this patch (cut'n'pasted) :
[...]

I agree, but would like to know whether there is an immediate effect.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [Stable-review] [24/28] USB: xhci - fix unsafe macro definitions

[Sarah Sharp]

On Wed, Apr 20, 2011 at 01:34:35PM +0100, Ben Hutchings wrote:
> On Wed, 2011-04-20 at 07:39 +0200, Willy Tarreau wrote:
> > On Wed, Apr 20, 2011 at 03:02:04AM +0100, Ben Hutchings wrote:
> > > On Tue, 2011-04-19 at 13:31 -0700, Greg KH wrote:
> > > > 2.6.32-longterm review patch.  If anyone has any objections, please let us know.
> > > > 
> > > > ------------------
> > > > 
> > > > From: Dmitry Torokhov <dtor@vmware.com>
> > > > 
> > > > commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.
> > > > 
> > > > Macro arguments used in expressions need to be enclosed in parenthesis
> > > > to avoid unpleasant surprises.
> > > 
> > > Do you know of any specific uses of these macros where the missing
> > > parentheses caused 'unpleasant surprises'?
> > 
> > In my opinion, this type of fix should be backported even if the current
> > code does not appear to be at risk, otherwise a later fix in the kernel
> > could cause a serious regression when backported to -stable. For instance,
> > if we later have to backport this patch (cut'n'pasted) :
> [...]
> 
> I agree, but would like to know whether there is an immediate effect.

No immediate breakage, AFAIK.  Dmitry found the issue by inspection.

Sarah Sharp

Re: [Stable-review] [24/28] USB: xhci - fix unsafe macro definitions

[Dmitry Torokhov]

On Wednesday, April 20, 2011 10:32:52 AM Sarah Sharp wrote:
> On Wed, Apr 20, 2011 at 01:34:35PM +0100, Ben Hutchings wrote:
> > On Wed, 2011-04-20 at 07:39 +0200, Willy Tarreau wrote:
> > > On Wed, Apr 20, 2011 at 03:02:04AM +0100, Ben Hutchings wrote:
> > > > On Tue, 2011-04-19 at 13:31 -0700, Greg KH wrote:
> > > > > 2.6.32-longterm review patch.  If anyone has any objections,
> > > > > please let us know.
> > > > > 
> > > > > ------------------
> > > > > 
> > > > > From: Dmitry Torokhov <dtor@vmware.com>
> > > > > 
> > > > > commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.
> > > > > 
> > > > > Macro arguments used in expressions need to be enclosed in
> > > > > parenthesis to avoid unpleasant surprises.
> > > > 
> > > > Do you know of any specific uses of these macros where the missing
> > > > parentheses caused 'unpleasant surprises'?
> > > 
> > > In my opinion, this type of fix should be backported even if the
> > > current code does not appear to be at risk, otherwise a later fix
> > > in the kernel could cause a serious regression when backported to
> > > -stable. For instance,
> > 
> > > if we later have to backport this patch (cut'n'pasted) :
> > [...]
> > 
> > I agree, but would like to know whether there is an immediate effect.
> 
> No immediate breakage, AFAIK.  Dmitry found the issue by inspection.

Right, mainline (and next) appear to be safe at the moment.

Thanks,
Dmitry

[25/28] USB: xhci - fix math in xhci_get_endpoint_interval()

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Dmitry Torokhov <dtor@vmware.com>

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: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/xhci-mem.c |   85 ++++++++++++++++++++++++++++++++------------
 1 file changed, 62 insertions(+), 23 deletions(-)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -439,6 +439,47 @@ int xhci_setup_addressable_virt_dev(stru
 	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
@@ -456,40 +497,38 @@ static inline unsigned int xhci_get_endp
 	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\n",
-						ep->desc.bEndpointAddress, 1 << interval);
+		    usb_endpoint_xfer_isoc(&ep->desc)) {
+
+			interval = xhci_parse_frame_interval(udev, ep);
 		}
 		break;
+
 	default:
 		BUG();
 	}

[26/28] x86, cpu: Fix regression in AMD errata checking code

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Hans Rosenfeld <hans.rosenfeld@amd.com>

commit 07a7795ca2e6e66d00b184efb46bd0e23d90d3fe upstream.

A bug in the family-model-stepping matching code caused the presence of
errata to go undetected when OSVW was not used. This causes hangs on
some K8 systems because the E400 workaround is not enabled.

Signed-off-by: Hans Rosenfeld <hans.rosenfeld@amd.com>
LKML-Reference: <1282141190-930137-1-git-send-email-hans.rosenfeld@amd.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -689,7 +689,7 @@ bool cpu_has_amd_erratum(const int *erra
 	}
 
 	/* OSVW unavailable or ID unknown, match family-model-stepping range */
-	ms = (cpu->x86_model << 8) | cpu->x86_mask;
+	ms = (cpu->x86_model << 4) | cpu->x86_mask;
 	while ((range = *erratum++))
 		if ((cpu->x86 == AMD_MODEL_RANGE_FAMILY(range)) &&
 		    (ms >= AMD_MODEL_RANGE_START(range)) &&

[27/28] net: ax25: fix information leak to userland harder

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

From: Kees Cook <kees.cook@canonical.com>

commit 5b919f833d9d60588d026ad82d17f17e8872c7a9 upstream.

Commit fe10ae53384e48c51996941b7720ee16995cbcb7 adds a memset() to clear
the structure being sent back to userspace, but accidentally used the
wrong size.

Reported-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Kees Cook <kees.cook@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/ax25/af_ax25.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1391,7 +1391,7 @@ static int ax25_getname(struct socket *s
 	ax25_cb *ax25;
 	int err = 0;
 
-	memset(fsa, 0, sizeof(fsa));
+	memset(fsa, 0, sizeof(*fsa));
 	lock_sock(sk);
 	ax25 = ax25_sk(sk);
 

[28/28] net: fix rds_iovec page count overflow

[Greg KH]

2.6.32-longterm review patch.  If anyone has any objections, please let us know.

------------------

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

commit 1b1f693d7ad6d193862dcb1118540a030c5e761f upstream.

As reported by Thomas Pollet, the rdma page counting can overflow.  We
get the rdma sizes in 64-bit unsigned entities, but then limit it to
UINT_MAX bytes and shift them down to pages (so with a possible "+1" for
an unaligned address).

So each individual page count fits comfortably in an 'unsigned int' (not
even close to overflowing into signed), but as they are added up, they
might end up resulting in a signed return value. Which would be wrong.

Catch the case of tot_pages turning negative, and return the appropriate
error code.

Reported-by: Thomas Pollet <thomas.pollet@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andy Grover <andy.grover@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[v2: nr is unsigned in the old code]
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/rds/rdma.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

--- a/net/rds/rdma.c
+++ b/net/rds/rdma.c
@@ -473,6 +473,17 @@ static struct rds_rdma_op *rds_rdma_prep
 
 		max_pages = max(nr, max_pages);
 		nr_pages += nr;
+
+		/*
+		 * nr for one entry in limited to (UINT_MAX>>PAGE_SHIFT)+1
+		 * so nr_pages cannot overflow without becoming bigger than
+		 * INT_MAX first. If nr cannot overflow then max_pages should
+		 * be ok.
+		 */
+		if (nr_pages > INT_MAX) {
+			ret = -EINVAL;
+			goto out;
+		}
 	}
 
 	pages = kcalloc(max_pages, sizeof(struct page *), GFP_KERNEL);