Skip to contentSkip to conversation

2.6.32.56-longterm review

PATCH In review Greg KH 3 participants 25 messages Feb 1, 2012 – Feb 2, 2012

Subsystems (14)
Stable branch DRM drivers SCSI USB +10 more subsystems
lore
Share & tools
lore

Greg KH

author maintainer
#0 lore raw

cover 2.6.32.56-longterm review

This is the start of the longterm review cycle for the 2.6.32.56 release. There are 20 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 Friday, February 3, 2012, 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.56-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

 Makefile                          |    2 +-
 block/scsi_ioctl.c                |   45 ++++++++++++++++++++++++++
 crypto/sha512_generic.c           |   62 ++++++++++++++++++++----------------
 drivers/gpu/drm/drm_auth.c        |    6 +++-
 drivers/gpu/drm/drm_fops.c        |    5 +++
 drivers/hwmon/f71805f.c           |   10 +++---
 drivers/hwmon/sht15.c             |    3 +-
 drivers/md/dm-linear.c            |   12 ++++++-
 drivers/md/dm-mpath.c             |    6 +++
 drivers/mmc/host/mmci.c           |    6 +---
 drivers/scsi/sd.c                 |   11 +++++-
 drivers/usb/class/cdc-wdm.c       |    2 +
 drivers/usb/misc/usbsevseg.c      |    2 +-
 drivers/usb/serial/cp210x.c       |    5 ++-
 drivers/usb/serial/ftdi_sio.c     |    7 +++-
 drivers/usb/serial/ftdi_sio_ids.h |   19 +++++++++++
 drivers/usb/serial/io_ti.c        |   10 +-----
 fs/ecryptfs/crypto.c              |    9 +++--
 fs/ecryptfs/miscdev.c             |   56 ++++++++++++++++++++++-----------
 fs/ecryptfs/read_write.c          |   19 ++++++++---
 include/drm/drmP.h                |    1 +
 include/linux/blkdev.h            |    1 +
 22 files changed, 216 insertions(+), 83 deletions(-)
author maintainer
#1 lore raw

PATCH 1/20 eCryptfs: Sanitize write counts of /dev/ecryptfs

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

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

From: Tyler Hicks <[email protected]>

commit db10e556518eb9d21ee92ff944530d84349684f4 upstream.

A malicious count value specified when writing to /dev/ecryptfs may result in a a very large kernel memory allocation.

This patch peeks at the specified packet payload size, adds that to the size of the packet headers and compares the result with the write count value. The resulting maximum memory allocation size is approximately 532 bytes.

---
 fs/ecryptfs/miscdev.c |   56 +++++++++++++++++++++++++++++++++-----------------
 1 file changed, 38 insertions(+), 18 deletions(-)
fs/ecryptfs/miscdev.c +38 -18
@@ -408,11 +408,47 @@ ecryptfs_miscdev_write(struct file *file
 	ssize_t sz = 0;
 	char *data;
 	uid_t euid = current_euid();
+	unsigned char packet_size_peek[3];
 	int rc;
 
-	if (count == 0)
+	if (count == 0) {
 		goto out;
+	} else if (count == (1 + 4)) {
+		/* Likely a harmless MSG_HELO or MSG_QUIT - no packet length */
+		goto memdup;
+	} else if (count < (1 + 4 + 1)
+		   || count > (1 + 4 + 2 + sizeof(struct ecryptfs_message) + 4
+			       + ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES)) {
+		printk(KERN_WARNING "%s: Acceptable packet size range is "
+		       "[%d-%lu], but amount of data written is [%zu].",
+		       __func__, (1 + 4 + 1),
+		       (1 + 4 + 2 + sizeof(struct ecryptfs_message) + 4
+			+ ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES), count);
+		return -EINVAL;
+	}
+
+	if (copy_from_user(packet_size_peek, (buf + 1 + 4),
+			   sizeof(packet_size_peek))) {
+		printk(KERN_WARNING "%s: Error while inspecting packet size\n",
+		       __func__);
+		return -EFAULT;
+	}
 
+	rc = ecryptfs_parse_packet_length(packet_size_peek, &packet_size,
+					  &packet_size_length);
+	if (rc) {
+		printk(KERN_WARNING "%s: Error parsing packet length; "
+		       "rc = [%d]\n", __func__, rc);
+		return rc;
+	}
+
+	if ((1 + 4 + packet_size_length + packet_size) != count) {
+		printk(KERN_WARNING "%s: Invalid packet size [%zu]\n", __func__,
+		       packet_size);
+		return -EINVAL;
+	}
+
+memdup:
 	data = memdup_user(buf, count);
 	if (IS_ERR(data)) {
 		printk(KERN_ERR "%s: memdup_user returned error [%ld]\n",
@@ -434,23 +470,7 @@ ecryptfs_miscdev_write(struct file *file
 		}
 		memcpy(&counter_nbo, &data[i], 4);
 		seq = be32_to_cpu(counter_nbo);
-		i += 4;
-		rc = ecryptfs_parse_packet_length(&data[i], &packet_size,
-						  &packet_size_length);
-		if (rc) {
-			printk(KERN_WARNING "%s: Error parsing packet length; "
-			       "rc = [%d]\n", __func__, rc);
-			goto out_free;
-		}
-		i += packet_size_length;
-		if ((1 + 4 + packet_size_length + packet_size) != count) {
-			printk(KERN_WARNING "%s: (1 + packet_size_length([%zd])"
-			       " + packet_size([%zd]))([%zd]) != "
-			       "count([%zd]). Invalid packet format.\n",
-			       __func__, packet_size_length, packet_size,
-			       (1 + packet_size_length + packet_size), count);
-			goto out_free;
-		}
+		i += 4 + packet_size_length;
 		rc = ecryptfs_miscdev_response(&data[i], packet_size,
 					       euid, current_user_ns(),
 					       task_pid(current), seq);
author maintainer
#2 lore raw

PATCH 2/20 ecryptfs: Improve metadata read failure logging

In reply to Greg KH

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

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

From: Tim Gardner <[email protected]>

commit 30373dc0c87ffef68d5628e77d56ffb1fa22e1ee upstream.

Print inode on metadata read failure. The only real way of dealing with metadata read failures is to delete the underlying file system file. Having the inode allows one to 'find . -inum INODE`.

---
 fs/ecryptfs/crypto.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)
fs/ecryptfs/crypto.c +6 -3
@@ -1609,7 +1609,8 @@ int ecryptfs_read_metadata(struct dentry
 		rc = ecryptfs_read_xattr_region(page_virt, ecryptfs_inode);
 		if (rc) {
 			printk(KERN_DEBUG "Valid eCryptfs headers not found in "
-			       "file header region or xattr region\n");
+			       "file header region or xattr region, inode %lu\n",
+				ecryptfs_inode->i_ino);
 			rc = -EINVAL;
 			goto out;
 		}
@@ -1618,7 +1619,8 @@ int ecryptfs_read_metadata(struct dentry
 						ECRYPTFS_DONT_VALIDATE_HEADER_SIZE);
 		if (rc) {
 			printk(KERN_DEBUG "Valid eCryptfs headers not found in "
-			       "file xattr region either\n");
+			       "file xattr region either, inode %lu\n",
+				ecryptfs_inode->i_ino);
 			rc = -EINVAL;
 		}
 		if (crypt_stat->mount_crypt_stat->flags
@@ -1629,7 +1631,8 @@ int ecryptfs_read_metadata(struct dentry
 			       "crypto metadata only in the extended attribute "
 			       "region, but eCryptfs was mounted without "
 			       "xattr support enabled. eCryptfs will not treat "
-			       "this like an encrypted file.\n");
+			       "this like an encrypted file, inode %lu\n",
+				ecryptfs_inode->i_ino);
 			rc = -EINVAL;
 		}
 	}
author maintainer
#3 lore raw

PATCH 3/20 eCryptfs: Make truncate path killable

In reply to Greg KH

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

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

From: Tyler Hicks <[email protected]>

commit 5e6f0d769017cc49207ef56996e42363ec26c1f0 upstream.

ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a page, zeroes out the appropriate portions, and then encrypts the page before writing it to the lower filesystem. It was unkillable and due to the lack of sparse file support could result in tying up a large portion of system resources, while encrypting pages of zeros, with no way for the truncate operation to be stopped from userspace.

This patch adds the ability for ecryptfs_write() to detect a pending fatal signal and return as gracefully as possible. The intent is to leave the lower file in a useable state, while still allowing a user to break out of the encryption loop. If a pending fatal signal is detected, the eCryptfs inode size is updated to reflect the modified inode size and then -EINTR is returned.

---
 fs/ecryptfs/read_write.c |   19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)
fs/ecryptfs/read_write.c +14 -5
@@ -136,6 +136,11 @@ int ecryptfs_write(struct file *ecryptfs
 		size_t num_bytes = (PAGE_CACHE_SIZE - start_offset_in_page);
 		size_t total_remaining_bytes = ((offset + size) - pos);
 
+		if (fatal_signal_pending(current)) {
+			rc = -EINTR;
+			break;
+		}
+
 		if (num_bytes > total_remaining_bytes)
 			num_bytes = total_remaining_bytes;
 		if (pos < offset) {
@@ -197,15 +202,19 @@ int ecryptfs_write(struct file *ecryptfs
 		}
 		pos += num_bytes;
 	}
-	if ((offset + size) > ecryptfs_file_size) {
-		i_size_write(ecryptfs_inode, (offset + size));
+	if (pos > ecryptfs_file_size) {
+		i_size_write(ecryptfs_inode, pos);
 		if (crypt_stat->flags & ECRYPTFS_ENCRYPTED) {
-			rc = ecryptfs_write_inode_size_to_metadata(
+			int rc2;
+
+			rc2 = ecryptfs_write_inode_size_to_metadata(
 								ecryptfs_inode);
-			if (rc) {
+			if (rc2) {
 				printk(KERN_ERR	"Problem with "
 				       "ecryptfs_write_inode_size_to_metadata; "
-				       "rc = [%d]\n", rc);
+				       "rc = [%d]\n", rc2);
+				if (!rc)
+					rc = rc2;
 				goto out;
 			}
 		}
author maintainer
#4 lore raw

PATCH 4/20 drm: Fix authentication kernel crash

In reply to Greg KH

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

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

From: Thomas Hellstrom <[email protected]>

commit 598781d71119827b454fd75d46f84755bca6f0c6 upstream.

If the master tries to authenticate a client using drm_authmagic and that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory and corrupt it.

Typically this results in a hard system hang.

This patch fixes that problem by removing any authentication tokens (struct drm_magic_entry) open for a file descriptor when that file descriptor is closed.

---
 drivers/gpu/drm/drm_auth.c |    6 +++++-
 drivers/gpu/drm/drm_fops.c |    5 +++++
 include/drm/drmP.h         |    1 +
 3 files changed, 11 insertions(+), 1 deletion(-)
drivers/gpu/drm/drm_auth.c +5 -1
@@ -102,7 +102,7 @@ static int drm_add_magic(struct drm_mast
  * Searches and unlinks the entry in drm_device::magiclist with the magic
  * number hash key, while holding the drm_device::struct_mutex lock.
  */
-static int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
+int drm_remove_magic(struct drm_master *master, drm_magic_t magic)
 {
 	struct drm_magic_entry *pt;
 	struct drm_hash_item *hash;
@@ -137,6 +137,8 @@ static int drm_remove_magic(struct drm_m
  * If there is a magic number in drm_file::magic then use it, otherwise
  * searches an unique non-zero magic number and add it associating it with \p
  * file_priv.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_getmagic(struct drm_device *dev, void *data, struct drm_file *file_priv)
 {
@@ -174,6 +176,8 @@ int drm_getmagic(struct drm_device *dev,
  * \return zero if authentication successed, or a negative number otherwise.
  *
  * Checks if \p file_priv is associated with the magic number passed in \arg.
+ * This ioctl needs protection by the drm_global_mutex, which protects
+ * struct drm_file::magic and struct drm_magic_entry::priv.
  */
 int drm_authmagic(struct drm_device *dev, void *data,
 		  struct drm_file *file_priv)
drivers/gpu/drm/drm_fops.c +5 -0
@@ -449,6 +449,11 @@ int drm_release(struct inode *inode, str
 		  (long)old_encode_dev(file_priv->minor->device),
 		  dev->open_count);
 
+	/* Release any auth tokens that might point to this file_priv,
+	   (do that under the drm_global_mutex) */
+	if (file_priv->magic)
+		(void) drm_remove_magic(file_priv->master, file_priv->magic);
+
 	/* if the master has gone away we can't do anything with the lock */
 	if (file_priv->minor->master)
 		drm_master_release(dev, filp);
include/drm/drmP.h +1 -0
@@ -1221,6 +1221,7 @@ extern int drm_getmagic(struct drm_devic
 			struct drm_file *file_priv);
 extern int drm_authmagic(struct drm_device *dev, void *data,
 			 struct drm_file *file_priv);
+extern int drm_remove_magic(struct drm_master *master, drm_magic_t magic);
 
 /* Cache management (drm_cache.c) */
 void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
author maintainer
#5 lore raw

PATCH 5/20 crypto: sha512 - make it work, undo percpu message schedule

In reply to Greg KH

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

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

From: Alexey Dobriyan <[email protected]>

commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.

commit f9e2bca6c22d75a289a349f869701214d63b5060
aka "crypto: sha512 - Move message schedule W[80] to static percpu area" created global message schedule area.

If sha512_update will ever be entered twice, hash will be silently calculated incorrectly.

Probably the easiest way to notice incorrect hashes being calculated is to run 2 ping floods over AH with hmac(sha512):

	#!/usr/sbin/setkey -f
	flush;
	spdflush;
	add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
	add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
	spdadd IP1 IP2 any -P out ipsec ah/transport//require;
	spdadd IP2 IP1 any -P in  ipsec ah/transport//require;

XfrmInStateProtoError will start ticking with -EBADMSG being returned from ah_input(). This never happens with, say, hmac(sha1).

With patch applied (on BOTH sides), XfrmInStateProtoError does not tick with multiple bidirectional ping flood streams like it doesn't tick with SHA-1.

After this patch sha512_transform() will start using ~750 bytes of stack on x86_64. This is OK for simple loads, for something more heavy, stack reduction will be done separatedly.

---
 crypto/sha512_generic.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)
crypto/sha512_generic.c +1 -5
@@ -21,8 +21,6 @@
 #include <linux/percpu.h>
 #include <asm/byteorder.h>
 
-static DEFINE_PER_CPU(u64[80], msg_schedule);
-
 static inline u64 Ch(u64 x, u64 y, u64 z)
 {
         return z ^ (x & (y ^ z));
@@ -89,7 +87,7 @@ sha512_transform(u64 *state, const u8 *i
 	u64 a, b, c, d, e, f, g, h, t1, t2;
 
 	int i;
-	u64 *W = get_cpu_var(msg_schedule);
+	u64 W[80];
 
 	/* load the input */
         for (i = 0; i < 16; i++)
@@ -128,8 +126,6 @@ sha512_transform(u64 *state, const u8 *i
 
 	/* erase our data */
 	a = b = c = d = e = f = g = h = t1 = t2 = 0;
-	memset(W, 0, sizeof(__get_cpu_var(msg_schedule)));
-	put_cpu_var(msg_schedule);
 }
 
 static int
author maintainer
#6 lore raw

PATCH 6/20 crypto: sha512 - reduce stack usage to safe number

In reply to Greg KH

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

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

From: Alexey Dobriyan <[email protected]>

commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.

For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16]. Consequently, keeping all W[80] array on stack is unnecessary,
only 16 values are really needed.

Using W[16] instead of W[80] greatly reduces stack usage (~750 bytes to ~340 bytes on x86_64).

Line by line explanation:
* BLEND_OP
array is "circular" now, all indexes have to be modulo 16. Round number is positive, so remainder operation should be without surprises.

* initial full message scheduling is trimmed to first 16 values which come from data block, the rest is calculated before it's needed.

* original loop body is unrolled version of new SHA512_0_15 and SHA512_16_79 macros, unrolling was done to not do explicit variable renaming. Otherwise it's the very same code after preprocessing. See sha1_transform() code which does the same trick.

Patch survives in-tree crypto test and original bugreport test (ping flood with hmac(sha512).

See FIPS 180-2 for SHA-512 definition
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

---
 crypto/sha512_generic.c |   58 ++++++++++++++++++++++++++++--------------------
 1 file changed, 34 insertions(+), 24 deletions(-)
crypto/sha512_generic.c +34 -24
@@ -78,7 +78,7 @@ static inline void LOAD_OP(int I, u64 *W
 
 static inline void BLEND_OP(int I, u64 *W)
 {
-	W[I] = s1(W[I-2]) + W[I-7] + s0(W[I-15]) + W[I-16];
+	W[I % 16] += s1(W[(I-2) % 16]) + W[(I-7) % 16] + s0(W[(I-15) % 16]);
 }
 
 static void
@@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
 	u64 a, b, c, d, e, f, g, h, t1, t2;
 
 	int i;
-	u64 W[80];
+	u64 W[16];
 
 	/* load the input */
         for (i = 0; i < 16; i++)
                 LOAD_OP(i, W, input);
 
-        for (i = 16; i < 80; i++) {
-                BLEND_OP(i, W);
-        }
-
 	/* load the state into our registers */
 	a=state[0];   b=state[1];   c=state[2];   d=state[3];
 	e=state[4];   f=state[5];   g=state[6];   h=state[7];
 
-	/* now iterate */
-	for (i=0; i<80; i+=8) {
-		t1 = h + e1(e) + Ch(e,f,g) + sha512_K[i  ] + W[i  ];
-		t2 = e0(a) + Maj(a,b,c);    d+=t1;    h=t1+t2;
-		t1 = g + e1(d) + Ch(d,e,f) + sha512_K[i+1] + W[i+1];
-		t2 = e0(h) + Maj(h,a,b);    c+=t1;    g=t1+t2;
-		t1 = f + e1(c) + Ch(c,d,e) + sha512_K[i+2] + W[i+2];
-		t2 = e0(g) + Maj(g,h,a);    b+=t1;    f=t1+t2;
-		t1 = e + e1(b) + Ch(b,c,d) + sha512_K[i+3] + W[i+3];
-		t2 = e0(f) + Maj(f,g,h);    a+=t1;    e=t1+t2;
-		t1 = d + e1(a) + Ch(a,b,c) + sha512_K[i+4] + W[i+4];
-		t2 = e0(e) + Maj(e,f,g);    h+=t1;    d=t1+t2;
-		t1 = c + e1(h) + Ch(h,a,b) + sha512_K[i+5] + W[i+5];
-		t2 = e0(d) + Maj(d,e,f);    g+=t1;    c=t1+t2;
-		t1 = b + e1(g) + Ch(g,h,a) + sha512_K[i+6] + W[i+6];
-		t2 = e0(c) + Maj(c,d,e);    f+=t1;    b=t1+t2;
-		t1 = a + e1(f) + Ch(f,g,h) + sha512_K[i+7] + W[i+7];
-		t2 = e0(b) + Maj(b,c,d);    e+=t1;    a=t1+t2;
+#define SHA512_0_15(i, a, b, c, d, e, f, g, h)			\
+	t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i];	\
+	t2 = e0(a) + Maj(a, b, c);				\
+	d += t1;						\
+	h = t1 + t2
+
+#define SHA512_16_79(i, a, b, c, d, e, f, g, h)			\
+	BLEND_OP(i, W);						\
+	t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[(i)%16];	\
+	t2 = e0(a) + Maj(a, b, c);				\
+	d += t1;						\
+	h = t1 + t2
+
+	for (i = 0; i < 16; i += 8) {
+		SHA512_0_15(i, a, b, c, d, e, f, g, h);
+		SHA512_0_15(i + 1, h, a, b, c, d, e, f, g);
+		SHA512_0_15(i + 2, g, h, a, b, c, d, e, f);
+		SHA512_0_15(i + 3, f, g, h, a, b, c, d, e);
+		SHA512_0_15(i + 4, e, f, g, h, a, b, c, d);
+		SHA512_0_15(i + 5, d, e, f, g, h, a, b, c);
+		SHA512_0_15(i + 6, c, d, e, f, g, h, a, b);
+		SHA512_0_15(i + 7, b, c, d, e, f, g, h, a);
+	}
+	for (i = 16; i < 80; i += 8) {
+		SHA512_16_79(i, a, b, c, d, e, f, g, h);
+		SHA512_16_79(i + 1, h, a, b, c, d, e, f, g);
+		SHA512_16_79(i + 2, g, h, a, b, c, d, e, f);
+		SHA512_16_79(i + 3, f, g, h, a, b, c, d, e);
+		SHA512_16_79(i + 4, e, f, g, h, a, b, c, d);
+		SHA512_16_79(i + 5, d, e, f, g, h, a, b, c);
+		SHA512_16_79(i + 6, c, d, e, f, g, h, a, b);
+		SHA512_16_79(i + 7, b, c, d, e, f, g, h, a);
 	}
 
 	state[0] += a; state[1] += b; state[2] += c; state[3] += d;
#7 lore raw

Re: [06/20] crypto: sha512 - reduce stack usage to safe number

crypto/sha512_generic.c sha512_transform(u64 *state, const u8 *i · line 90

Quoted 6 lines · Greg KH
crypto/sha512_generic.c +1 -1
@@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
 	u64 a, b, c, d, e, f, g, h, t1, t2;
 
 	int i;
-	u64 W[80];
+	u64 W[16];

This needs 3rd companion patch which does stack reduction even on i386. Patch which removes excessive loop unrolling and thus fixes the problem has been posted. Maybe there is some other way to maintain low stack space on i386 but I haven't found it.

http://marc.info/?l=linux-netdev&m=132768692525017&w=4

If you apply only 2, original bug will be fixed, but on at least i386 stack usage could go in 900-byte region.

author maintainer
#8 lore raw

Re: [06/20] crypto: sha512 - reduce stack usage to safe number

Quoted 13 lines · Alexey Dobriyan

crypto/sha512_generic.c sha512_transform(u64 *state, const u8 *i · line 90

Quoted 6 lines · Greg KH
crypto/sha512_generic.c +1 -1
@@ -87,38 +87,48 @@ sha512_transform(u64 *state, const u8 *i
 	u64 a, b, c, d, e, f, g, h, t1, t2;
 
 	int i;
-	u64 W[80];
+	u64 W[16];

This needs 3rd companion patch which does stack reduction even on i386. Patch which removes excessive loop unrolling and thus fixes the problem has been posted. Maybe there is some other way to maintain low stack space on i386 but I haven't found it.

Quoted 4 lines

http://marc.info/?l=linux-netdev&m=132768692525017&w=4

If you apply only 2, original bug will be fixed, but on at least i386 stack usage could go in 900-byte region.

But this patch isn't in Linus's tree yet, right?

So, should I just drop this one for now (well both of them) or just wait for the above referenced patch to hit Linus's tree and handle it then?

thanks,

greg k-h

#9 lore raw

Re: [06/20] crypto: sha512 - reduce stack usage to safe number

Quoted 5 lines · Greg KH

But this patch isn't in Linus's tree yet, right?

So, should I just drop this one for now (well both of them) or just wait for the above referenced patch to hit Linus's tree and handle it then?

We're still working on the i386 issue. However, I'd say that you should take these two patches now since the problem they fix is far worse than the potential stack issue on i386.

Cheers,

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
author maintainer
#10 lore raw

Re: [06/20] crypto: sha512 - reduce stack usage to safe number

Quoted 10 lines · Herbert Xu
Quoted 5 lines · Greg KH

But this patch isn't in Linus's tree yet, right?

So, should I just drop this one for now (well both of them) or just wait for the above referenced patch to hit Linus's tree and handle it then?

We're still working on the i386 issue. However, I'd say that you should take these two patches now since the problem they fix is far worse than the potential stack issue on i386.

Ok, thanks for letting me know, I'll leave these patches in.

greg k-h

author maintainer
#11 lore raw

PATCH 7/20 Revert "ARM: 7220/1: mmc: mmci: Fixup error handling for dma"

In reply to Greg KH

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

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

From: Herton Ronaldo Krzesinski <[email protected]>

This reverts commit c8cdf3f97d34d906e0519d5cbc2ab3f81269d0b4, applied on linux 2.6.32.53 stable release, as it can introduce the following build error while building 2.6.32.y on armel:

linux-2.6.32/drivers/mmc/host/mmci.c: In function 'mmci_cmd_irq':
linux-2.6.32/drivers/mmc/host/mmci.c:237: error: implicit declaration of function 'dma_inprogress' linux-2.6.32/drivers/mmc/host/mmci.c:238: error: implicit declaration of function 'mmci_dma_data_error'

Aparently the commit was wrongly pushed into 2.6.32, since it depends on commit c8ebae37 ("ARM: mmci: add dmaengine-based DMA support"), not present on 2.6.32.

---
 drivers/mmc/host/mmci.c |    6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/mmc/host/mmci.c +1 -5
@@ -232,12 +232,8 @@ mmci_cmd_irq(struct mmci_host *host, str
 	}
 
 	if (!cmd->data || cmd->error) {
-		if (host->data) {
-			/* Terminate the DMA transfer */
-			if (dma_inprogress(host))
-				mmci_dma_data_error(host);
+		if (host->data)
 			mmci_stop_data(host);
-		}
 		mmci_request_end(host, cmd->mrq);
 	} else if (!(cmd->data->flags & MMC_DATA_READ)) {
 		mmci_start_data(host, cmd->data);
author maintainer
#12 lore raw

PATCH 8/20 block: fail SCSI passthrough ioctls on partition devices

In reply to Greg KH

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

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

From: Paolo Bonzini <[email protected]>

commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream.

[ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl
and -ENOIOCTLCMD from sd_compat_ioctl. ]

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and will pass the command to the underlying block device. This is well-known, but it is also a large security problem when (via Unix permissions, ACLs, SELinux or a combination thereof) a program or user needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls; others are logged with printk so that we can see which ioctls are actually sent. In my tests only CDROM_GET_CAPABILITY actually occurred. Of course it was being sent to a (partition on a) hard disk, so it would have failed with ENOTTY and the patch isn't changing anything in practice. Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with CAP_SYS_RAWIO. If for example I let a program access /dev/sda2 and /dev/sdb, it still should not be able to read/write outside the boundaries of /dev/sda2 independent of the capabilities. However, for now programs with CAP_SYS_RAWIO will still be allowed to send the ioctls. Their actions will still be logged.

This patch does not affect the non-libata IDE driver. That driver however already tests for bd != bd->bd_contains before issuing some ioctl; it could be restricted further to forbid these ioctls even for programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc Jens Axboe <[email protected]>
Cc James Bottomley <[email protected]>
[ Make it also print the command name when warning - Linus ]

[bwh: Backport to 2.6.32 - ENOIOCTLCMD does not get converted to
ENOTTY, so we must return ENOTTY directly]

---
 block/scsi_ioctl.c     |   45 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/scsi/sd.c      |   11 +++++++++--
 include/linux/blkdev.h |    1 +
 3 files changed, 55 insertions(+), 2 deletions(-)
block/scsi_ioctl.c +45 -0
@@ -24,6 +24,7 @@
 #include <linux/capability.h>
 #include <linux/completion.h>
 #include <linux/cdrom.h>
+#include <linux/ratelimit.h>
 #include <linux/slab.h>
 #include <linux/times.h>
 #include <asm/uaccess.h>
@@ -689,9 +690,53 @@ int scsi_cmd_ioctl(struct request_queue
 }
 EXPORT_SYMBOL(scsi_cmd_ioctl);
 
+int scsi_verify_blk_ioctl(struct block_device *bd, unsigned int cmd)
+{
+	if (bd && bd == bd->bd_contains)
+		return 0;
+
+	/* Actually none of these is particularly useful on a partition,
+	 * but they are safe.
+	 */
+	switch (cmd) {
+	case SCSI_IOCTL_GET_IDLUN:
+	case SCSI_IOCTL_GET_BUS_NUMBER:
+	case SCSI_IOCTL_GET_PCI:
+	case SCSI_IOCTL_PROBE_HOST:
+	case SG_GET_VERSION_NUM:
+	case SG_SET_TIMEOUT:
+	case SG_GET_TIMEOUT:
+	case SG_GET_RESERVED_SIZE:
+	case SG_SET_RESERVED_SIZE:
+	case SG_EMULATED_HOST:
+		return 0;
+	case CDROM_GET_CAPABILITY:
+		/* Keep this until we remove the printk below.  udev sends it
+		 * and we do not want to spam dmesg about it.   CD-ROMs do
+		 * not have partitions, so we get here only for disks.
+		 */
+		return -ENOTTY;
+	default:
+		break;
+	}
+
+	/* In particular, rule out all resets and host-specific ioctls.  */
+	printk_ratelimited(KERN_WARNING
+			   "%s: sending ioctl %x to a partition!\n", current->comm, cmd);
+
+	return capable(CAP_SYS_RAWIO) ? 0 : -ENOTTY;
+}
+EXPORT_SYMBOL(scsi_verify_blk_ioctl);
+
 int scsi_cmd_blk_ioctl(struct block_device *bd, fmode_t mode,
 		       unsigned int cmd, void __user *arg)
 {
+	int ret;
+
+	ret = scsi_verify_blk_ioctl(bd, cmd);
+	if (ret < 0)
+		return ret;
+
 	return scsi_cmd_ioctl(bd->bd_disk->queue, bd->bd_disk, mode, cmd, arg);
 }
 EXPORT_SYMBOL(scsi_cmd_blk_ioctl);
drivers/scsi/sd.c +9 -2
@@ -817,6 +817,10 @@ static int sd_ioctl(struct block_device
 	SCSI_LOG_IOCTL(1, printk("sd_ioctl: disk=%s, cmd=0x%x\n",
 						disk->disk_name, cmd));
 
+	error = scsi_verify_blk_ioctl(bdev, cmd);
+	if (error < 0)
+		return error;
+
 	/*
 	 * If we are in the middle of error recovery, don't let anyone
 	 * else try and use this device.  Also, if error recovery fails, it
@@ -996,6 +1000,11 @@ static int sd_compat_ioctl(struct block_
 			   unsigned int cmd, unsigned long arg)
 {
 	struct scsi_device *sdev = scsi_disk(bdev->bd_disk)->device;
+	int ret;
+
+	ret = scsi_verify_blk_ioctl(bdev, cmd);
+	if (ret < 0)
+		return -ENOIOCTLCMD;
 
 	/*
 	 * If we are in the middle of error recovery, don't let anyone
@@ -1007,8 +1016,6 @@ static int sd_compat_ioctl(struct block_
 		return -ENODEV;
 	       
 	if (sdev->host->hostt->compat_ioctl) {
-		int ret;
-
 		ret = sdev->host->hostt->compat_ioctl(sdev, cmd, (void __user *)arg);
 
 		return ret;
include/linux/blkdev.h +1 -0
@@ -777,6 +777,7 @@ extern void blk_plug_device(struct reque
 extern void blk_plug_device_unlocked(struct request_queue *);
 extern int blk_remove_plug(struct request_queue *);
 extern void blk_recount_segments(struct request_queue *, struct bio *);
+extern int scsi_verify_blk_ioctl(struct block_device *, unsigned int);
 extern int scsi_cmd_blk_ioctl(struct block_device *, fmode_t,
 			      unsigned int, void __user *);
 extern int scsi_cmd_ioctl(struct request_queue *, struct gendisk *, fmode_t,
author maintainer
#13 lore raw

PATCH 9/20 dm: do not forward ioctls from logical volumes to the underlying device

In reply to Greg KH

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

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

From: Paolo Bonzini <[email protected]>

commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream.

A logical volume can map to just part of underlying physical volume. In this case, it must be treated like a partition.

Based on a patch from Alasdair G Kergon.

Cc Alasdair G Kergon <[email protected]>
[bwh: Backport to 2.6.32 - drop change to drivers/md/dm-flakey.c]
---
 drivers/md/dm-linear.c |   12 +++++++++++-
 drivers/md/dm-mpath.c  |    6 ++++++
 2 files changed, 17 insertions(+), 1 deletion(-)
drivers/md/dm-linear.c +11 -1
@@ -116,7 +116,17 @@ static int linear_ioctl(struct dm_target
 			unsigned long arg)
 {
 	struct linear_c *lc = (struct linear_c *) ti->private;
-	return __blkdev_driver_ioctl(lc->dev->bdev, lc->dev->mode, cmd, arg);
+	struct dm_dev *dev = lc->dev;
+	int r = 0;
+
+	/*
+	 * Only pass ioctls through if the device sizes match exactly.
+	 */
+	if (lc->start ||
+	    ti->len != i_size_read(dev->bdev->bd_inode) >> SECTOR_SHIFT)
+		r = scsi_verify_blk_ioctl(NULL, cmd);
+
+	return r ? : __blkdev_driver_ioctl(dev->bdev, dev->mode, cmd, arg);
 }
 
 static int linear_merge(struct dm_target *ti, struct bvec_merge_data *bvm,
drivers/md/dm-mpath.c +6 -0
@@ -1464,6 +1464,12 @@ static int multipath_ioctl(struct dm_tar
 
 	spin_unlock_irqrestore(&m->lock, flags);
 
+	/*
+	 * Only pass ioctls through if the device sizes match exactly.
+	 */
+	if (!r && ti->len != i_size_read(bdev->bd_inode) >> SECTOR_SHIFT)
+		r = scsi_verify_blk_ioctl(NULL, cmd);
+
 	return r ? : __blkdev_driver_ioctl(bdev, mode, cmd, arg);
 }
 
author maintainer
#14 lore raw

PATCH 10/20 USB: ftdi_sio: fix TIOCSSERIAL baud_base handling

In reply to Greg KH

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

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

From: Johan Hovold <[email protected]>

commit eb833a9e0972f60beb4ab8104ad7ef6bf30f02fc upstream.

Return EINVAL if new baud_base does not match the current one.

The baud_base is device specific and can not be changed. This restores the old (pre-2005) behaviour which was changed due to a misunderstanding regarding this fact (see
https://lkml.org/lkml/2005/1/20/84).

---
 drivers/usb/serial/ftdi_sio.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/usb/serial/ftdi_sio.c +1 -2
@@ -1351,8 +1351,7 @@ static int set_serial_info(struct tty_st
 		goto check_and_exit;
 	}
 
-	if ((new_serial.baud_base != priv->baud_base) &&
-	    (new_serial.baud_base < 9600)) {
+	if (new_serial.baud_base != priv->baud_base) {
 	    	unlock_kernel();
 		return -EINVAL;
 	}
author maintainer
#15 lore raw

PATCH 11/20 USB: ftdi_sio: add PID for TI XDS100v2 / BeagleBone A3

In reply to Greg KH

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

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

From: Peter Korsgaard <[email protected]>

commit 55f13aeae0346f0c89bfface91ad9a97653dc433 upstream.

Port A for JTAG, port B for serial.

---
 drivers/usb/serial/ftdi_sio.c     |    2 ++
 drivers/usb/serial/ftdi_sio_ids.h |    7 +++++++
 2 files changed, 9 insertions(+)
drivers/usb/serial/ftdi_sio.c +2 -0
@@ -806,6 +806,8 @@ static struct usb_device_id id_table_com
 	{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
 	{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+	{ USB_DEVICE(FTDI_VID, TI_XDS100V2_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) },
drivers/usb/serial/ftdi_sio_ids.h +7 -0
@@ -38,6 +38,13 @@
 /* www.candapter.com Ewert Energy Systems CANdapter device */
 #define FTDI_CANDAPTER_PID 0x9F80 /* Product Id */
 
+/*
+ * Texas Instruments XDS100v2 JTAG / BeagleBone A3
+ * http://processors.wiki.ti.com/index.php/XDS100
+ * http://beagleboard.org/bone
+ */
+#define TI_XDS100V2_PID		0xa6d0
+
 #define FTDI_NXTCAM_PID		0xABB8 /* NXTCam for Mindstorms NXT */
 
 /* US Interface Navigator (http://www.usinterface.com/) */
author maintainer
#16 lore raw

PATCH 12/20 USB: serial: ftdi additional IDs

In reply to Greg KH

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

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

From: Peter Naulls <[email protected]>

commit fc216ec363f4d174932df90bbf35c77d0540e561 upstream.

I tested this against 2.6.39 in the Ubuntu kernel, however I see the IDs are not in latest 3.2 git.

This adds IDs for the FTDI controller in the Rainforest Automation Zigbee dongle.

---
 drivers/usb/serial/ftdi_sio.c     |    1 +
 drivers/usb/serial/ftdi_sio_ids.h |    6 ++++++
 2 files changed, 7 insertions(+)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -844,6 +844,7 @@ static struct usb_device_id id_table_com
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
 	{ USB_DEVICE(ST_VID, ST_STMCLT1030_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_stmclite_quirk },
+	{ USB_DEVICE(FTDI_VID, FTDI_RF_R106) },
 	{ },					/* Optional parameter entry */
 	{ }					/* Terminating entry */
 };
drivers/usb/serial/ftdi_sio_ids.h +6 -0
@@ -1180,3 +1180,9 @@
  */
 /* TagTracer MIFARE*/
 #define FTDI_ZEITCONTROL_TAGTRACE_MIFARE_PID	0xF7C0
+
+/*
+ * Rainforest Automation
+ */
+/* ZigBee controller */
+#define FTDI_RF_R106		0x8A28
author maintainer
#17 lore raw

PATCH 13/20 USB: ftdi_sio: Add more identifiers

In reply to Greg KH

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

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

From: Alan Cox <[email protected]>

commit 2353f806c97020d4c7709f15eebb49b591f7306d upstream.

0x04d8, 0x000a: Hornby Elite

---
 drivers/usb/serial/ftdi_sio.c     |    1 +
 drivers/usb/serial/ftdi_sio_ids.h |    6 ++++++
 2 files changed, 7 insertions(+)
drivers/usb/serial/ftdi_sio.c +1 -0
@@ -798,6 +798,7 @@ static struct usb_device_id id_table_com
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
 	{ USB_DEVICE(ADI_VID, ADI_GNICEPLUS_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
+	{ USB_DEVICE(HORNBY_VID, HORNBY_ELITE_PID) },
 	{ USB_DEVICE(JETI_VID, JETI_SPC1201_PID) },
 	{ USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
 		.driver_info = (kernel_ulong_t)&ftdi_jtag_quirk },
drivers/usb/serial/ftdi_sio_ids.h +6 -0
@@ -531,6 +531,12 @@
 #define ADI_GNICEPLUS_PID 	0xF001
 
 /*
+ * Hornby Elite
+ */
+#define HORNBY_VID		0x04D8
+#define HORNBY_ELITE_PID	0x000A
+
+/*
  * RATOC REX-USB60F
  */
 #define RATOC_VENDOR_ID		0x0584
author maintainer
#18 lore raw

PATCH 14/20 USB: cdc-wdm: updating desc->length must be protected by spin_lock

In reply to Greg KH

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

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

From: Bjørn Mork <[email protected]>

commit c428b70c1e115c5649707a602742e34130d19428 upstream.

wdm_in_callback() will also touch this field, so we cannot change it without locking

---
 drivers/usb/class/cdc-wdm.c |    2 ++
 1 file changed, 2 insertions(+)
drivers/usb/class/cdc-wdm.c +2 -0
@@ -458,7 +458,9 @@ retry:
 	for (i = 0; i < desc->length - cntr; i++)
 		desc->ubuf[i] = desc->ubuf[i + cntr];
 
+	spin_lock_irq(&desc->iuspin);
 	desc->length -= cntr;
+	spin_unlock_irq(&desc->iuspin);
 	/* in case we had outstanding data */
 	if (!desc->length)
 		clear_bit(WDM_READ, &desc->flags);
author maintainer
#19 lore raw

PATCH 15/20 usb: io_ti: Make edge_remove_sysfs_attrs the port_remove method.

In reply to Greg KH

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

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

From: "Eric W. Biederman" <[email protected]>

commit 6d443d8499e4e59ffb949759cdded32730f8d2f6 upstream.

Calling edge_remove_sysfs_attrs from edge_disconnect is too late as the device has already been removed from sysfs.

Do the simple and obvious thing and make edge_remove_sysfs_attrs the port_remove method.

---
 drivers/usb/serial/io_ti.c |   10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)
drivers/usb/serial/io_ti.c +2 -8
@@ -2664,15 +2664,7 @@ cleanup:
 
 static void edge_disconnect(struct usb_serial *serial)
 {
-	int i;
-	struct edgeport_port *edge_port;
-
 	dbg("%s", __func__);
-
-	for (i = 0; i < serial->num_ports; ++i) {
-		edge_port = usb_get_serial_port_data(serial->port[i]);
-		edge_remove_sysfs_attrs(edge_port->port);
-	}
 }
 
 static void edge_release(struct usb_serial *serial)
@@ -2927,6 +2919,7 @@ static struct usb_serial_driver edgeport
 	.disconnect		= edge_disconnect,
 	.release		= edge_release,
 	.port_probe		= edge_create_sysfs_attrs,
+	.port_remove		= edge_remove_sysfs_attrs,
 	.ioctl			= edge_ioctl,
 	.set_termios		= edge_set_termios,
 	.tiocmget		= edge_tiocmget,
@@ -2957,6 +2950,7 @@ static struct usb_serial_driver edgeport
 	.disconnect		= edge_disconnect,
 	.release		= edge_release,
 	.port_probe		= edge_create_sysfs_attrs,
+	.port_remove		= edge_remove_sysfs_attrs,
 	.ioctl			= edge_ioctl,
 	.set_termios		= edge_set_termios,
 	.tiocmget		= edge_tiocmget,
author maintainer
#20 lore raw

PATCH 16/20 USB: usbsevseg: fix max length

In reply to Greg KH

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

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

From: Harrison Metzger <[email protected]>

commit 1097ccebe630170080c41df0edcf88e0626e9c75 upstream.

This changes the max length for the usb seven segment delcom device to 8 from 6. Delcom has both 6 and 8 variants and having 8 works fine with devices which are only 6.

---
 drivers/usb/misc/usbsevseg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/misc/usbsevseg.c +1 -1
@@ -24,7 +24,7 @@
 
 #define VENDOR_ID	0x0fc5
 #define PRODUCT_ID	0x1227
-#define MAXLEN		6
+#define MAXLEN		8
 
 /* table of devices that work with this driver */
 static struct usb_device_id id_table[] = {
author maintainer
#21 lore raw

PATCH 17/20 hwmon: (f71805f) Fix clamping of temperature limits

In reply to Greg KH

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

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

From: Jean Delvare <[email protected]>

commit 86b2bbfdbd1fcc4a3aa62ccd3f245c40c5ad5b85 upstream.

Properly clamp temperature limits set by the user. Without this fix, attempts to write temperature limits above the maximum supported by the chip (255 degrees Celsius) would arbitrarily and unexpectedly result in the limit being set to 0 degree Celsius.

---
 drivers/hwmon/f71805f.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
drivers/hwmon/f71805f.c +5 -5
@@ -281,11 +281,11 @@ static inline long temp_from_reg(u8 reg)
 
 static inline u8 temp_to_reg(long val)
 {
-	if (val < 0)
-		val = 0;
-	else if (val > 1000 * 0xff)
-		val = 0xff;
-	return ((val + 500) / 1000);
+	if (val <= 0)
+		return 0;
+	if (val >= 1000 * 0xff)
+		return 0xff;
+	return (val + 500) / 1000;
 }
 
 /*
author maintainer
#22 lore raw

PATCH 18/20 hwmon: (sht15) fix bad error code

In reply to Greg KH

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

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

From: Vivien Didelot <[email protected]>

commit 6edf3c30af01854c416f8654d3d5d2652470afd4 upstream.

When no platform data was supplied, returned error code was 0.

---
 drivers/hwmon/sht15.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/hwmon/sht15.c +2 -1
@@ -515,7 +515,7 @@ static int sht15_invalidate_voltage(stru
 
 static int __devinit sht15_probe(struct platform_device *pdev)
 {
-	int ret = 0;
+	int ret;
 	struct sht15_data *data = kzalloc(sizeof(*data), GFP_KERNEL);
 
 	if (!data) {
@@ -532,6 +532,7 @@ static int __devinit sht15_probe(struct
 	init_waitqueue_head(&data->wait_queue);
 
 	if (pdev->dev.platform_data == NULL) {
+		ret = -EINVAL;
 		dev_err(&pdev->dev, "no platform data supplied");
 		goto err_free_data;
 	}
author maintainer
#23 lore raw

PATCH 19/20 USB: serial: CP210x: Added USB-ID for the Link Instruments MSO-19

In reply to Greg KH

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

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

From: Renato Caldas <[email protected]>

commit 791b7d7cf69de11275e4dccec2f538eec02cbff6 upstream.

This device is a Oscilloscope/Logic Analizer/Pattern Generator/TDR, using a Silabs CP2103 USB to UART Bridge.

---
 drivers/usb/serial/cp210x.c |    1 +
 1 file changed, 1 insertion(+)
drivers/usb/serial/cp210x.c +1 -0
@@ -140,6 +140,7 @@ static struct usb_device_id id_table []
 	{ USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */
 	{ USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */
 	{ USB_DEVICE(0x1BE3, 0x07A6) }, /* WAGO 750-923 USB Service Cable */
+	{ USB_DEVICE(0x3195, 0xF190) }, /* Link Instruments MSO-19 */
 	{ USB_DEVICE(0x413C, 0x9500) }, /* DW700 GPS USB interface */
 	{ } /* Terminating Entry */
 };
author maintainer
#24 lore raw

PATCH 20/20 USB: cp210x: do not map baud rates to B0

In reply to Greg KH

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

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

From: Johan Hovold <[email protected]>

commit be125d9c8d59560e7cc2d6e2b65c8fd233498ab7 upstream.

We do not implement B0 hangup yet so map low baudrates to 300bps.

---
 drivers/usb/serial/cp210x.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/usb/serial/cp210x.c +2 -2
@@ -361,8 +361,8 @@ static inline int cp210x_set_config_sing
  * Quantises the baud rate as per AN205 Table 1
  */
 static unsigned int cp210x_quantise_baudrate(unsigned int baud) {
-	if      (baud <= 56)       baud = 0;
-	else if (baud <= 300)      baud = 300;
+	if (baud <= 300)
+		baud = 300;
 	else if (baud <= 600)      baud = 600;
 	else if (baud <= 1200)     baud = 1200;
 	else if (baud <= 1800)     baud = 1800;