]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 20 Feb 2014 22:13:26 +0000 (14:13 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 20 Feb 2014 22:13:26 +0000 (14:13 -0800)
added patches:
lockd-send-correct-lock-when-granting-a-delayed-lock.patch
raw-test-against-runtime-value-of-max_raw_minors.patch
tty-n_gsm-fix-for-modems-with-brk-in-modem-status-control.patch

queue-3.4/lockd-send-correct-lock-when-granting-a-delayed-lock.patch [new file with mode: 0644]
queue-3.4/raw-test-against-runtime-value-of-max_raw_minors.patch [new file with mode: 0644]
queue-3.4/series
queue-3.4/tty-n_gsm-fix-for-modems-with-brk-in-modem-status-control.patch [new file with mode: 0644]

diff --git a/queue-3.4/lockd-send-correct-lock-when-granting-a-delayed-lock.patch b/queue-3.4/lockd-send-correct-lock-when-granting-a-delayed-lock.patch
new file mode 100644 (file)
index 0000000..b3028c2
--- /dev/null
@@ -0,0 +1,70 @@
+From 2ec197db1a56c9269d75e965f14c344b58b2a4f6 Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Fri, 7 Feb 2014 17:10:26 +1100
+Subject: lockd: send correct lock when granting a delayed lock.
+
+From: NeilBrown <neilb@suse.de>
+
+commit 2ec197db1a56c9269d75e965f14c344b58b2a4f6 upstream.
+
+If an NFS client attempts to get a lock (using NLM) and the lock is
+not available, the server will remember the request and when the lock
+becomes available it will send a GRANT request to the client to
+provide the lock.
+
+If the client already held an adjacent lock, the GRANT callback will
+report the union of the existing and new locks, which can confuse the
+client.
+
+This happens because __posix_lock_file (called by vfs_lock_file)
+updates the passed-in file_lock structure when adjacent or
+over-lapping locks are found.
+
+To avoid this problem we take a copy of the two fields that can
+be changed (fl_start and fl_end) before the call and restore them
+afterwards.
+An alternate would be to allocate a 'struct file_lock', initialise it,
+use locks_copy_lock() to take a copy, then locks_release_private()
+after the vfs_lock_file() call.  But that is a lot more work.
+
+Reported-by: Olaf Kirch <okir@suse.com>
+Signed-off-by: NeilBrown <neilb@suse.de>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+--
+v1 had a couple of issues (large on-stack struct and didn't really work properly).
+This version is much better tested.
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+
+---
+ fs/lockd/svclock.c |    8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/fs/lockd/svclock.c
++++ b/fs/lockd/svclock.c
+@@ -769,6 +769,7 @@ nlmsvc_grant_blocked(struct nlm_block *b
+       struct nlm_file         *file = block->b_file;
+       struct nlm_lock         *lock = &block->b_call->a_args.lock;
+       int                     error;
++      loff_t                  fl_start, fl_end;
+       dprintk("lockd: grant blocked lock %p\n", block);
+@@ -786,9 +787,16 @@ nlmsvc_grant_blocked(struct nlm_block *b
+       }
+       /* Try the lock operation again */
++      /* vfs_lock_file() can mangle fl_start and fl_end, but we need
++       * them unchanged for the GRANT_MSG
++       */
+       lock->fl.fl_flags |= FL_SLEEP;
++      fl_start = lock->fl.fl_start;
++      fl_end = lock->fl.fl_end;
+       error = vfs_lock_file(file->f_file, F_SETLK, &lock->fl, NULL);
+       lock->fl.fl_flags &= ~FL_SLEEP;
++      lock->fl.fl_start = fl_start;
++      lock->fl.fl_end = fl_end;
+       switch (error) {
+       case 0:
diff --git a/queue-3.4/raw-test-against-runtime-value-of-max_raw_minors.patch b/queue-3.4/raw-test-against-runtime-value-of-max_raw_minors.patch
new file mode 100644 (file)
index 0000000..0e8828e
--- /dev/null
@@ -0,0 +1,37 @@
+From 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf Mon Sep 17 00:00:00 2001
+From: Paul Bolle <pebolle@tiscali.nl>
+Date: Tue, 4 Feb 2014 23:23:12 +0100
+Subject: raw: test against runtime value of max_raw_minors
+
+From: Paul Bolle <pebolle@tiscali.nl>
+
+commit 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf upstream.
+
+bind_get() checks the device number it is called with. It uses
+MAX_RAW_MINORS for the upper bound. But MAX_RAW_MINORS is set at compile
+time while the actual number of raw devices can be set at runtime. This
+means the test can either be too strict or too lenient. And if the test
+ends up being too lenient bind_get() might try to access memory beyond
+what was allocated for "raw_devices".
+
+So check against the runtime value (max_raw_minors) in this function.
+
+Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
+Acked-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/char/raw.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/raw.c
++++ b/drivers/char/raw.c
+@@ -190,7 +190,7 @@ static int bind_get(int number, dev_t *d
+       struct raw_device_data *rawdev;
+       struct block_device *bdev;
+-      if (number <= 0 || number >= MAX_RAW_MINORS)
++      if (number <= 0 || number >= max_raw_minors)
+               return -EINVAL;
+       rawdev = &raw_devices[number];
index 51df4d47cba26b74636da13056d65a4fc04aedd1..9986c84ad986d5c9485a6455a25b84544030ff2f 100644 (file)
@@ -4,3 +4,6 @@ mac80211-fix-fragmentation-code-particularly-for-encryption.patch
 s390-dump-fix-dump-memory-detection.patch
 s390-fix-kernel-crash-due-to-linkage-stack-instructions.patch
 spi-fix-crash-with-double-message-finalisation-on-error-handling.patch
+raw-test-against-runtime-value-of-max_raw_minors.patch
+lockd-send-correct-lock-when-granting-a-delayed-lock.patch
+tty-n_gsm-fix-for-modems-with-brk-in-modem-status-control.patch
diff --git a/queue-3.4/tty-n_gsm-fix-for-modems-with-brk-in-modem-status-control.patch b/queue-3.4/tty-n_gsm-fix-for-modems-with-brk-in-modem-status-control.patch
new file mode 100644 (file)
index 0000000..86e7ee5
--- /dev/null
@@ -0,0 +1,59 @@
+From 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f Mon Sep 17 00:00:00 2001
+From: Lars Poeschel <poeschel@lemonage.de>
+Date: Tue, 7 Jan 2014 13:34:37 +0100
+Subject: tty: n_gsm: Fix for modems with brk in modem status control
+
+From: Lars Poeschel <poeschel@lemonage.de>
+
+commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream.
+
+3GPP TS 07.10 states in section 5.4.6.3.7:
+"The length byte contains the value 2 or 3 ... depending on the break
+signal." The break byte is optional and if it is sent, the length is
+3. In fact the driver was not able to work with modems that send this
+break byte in their modem status control message. If the modem just
+sends the break byte if it is really set, then weird things might
+happen.
+The code for deconding the modem status to the internal linux
+presentation in gsm_process_modem has already a big comment about
+this 2 or 3 byte length thing and it is already able to decode the
+brk, but the code calling the gsm_process_modem function in
+gsm_control_modem does not encode it and hand it over the right way.
+This patch fixes this.
+Without this fix if the modem sends the brk byte in it's modem status
+control message the driver will hang when opening a muxed channel.
+
+Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/n_gsm.c |   11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/drivers/tty/n_gsm.c
++++ b/drivers/tty/n_gsm.c
+@@ -1091,6 +1091,7 @@ static void gsm_control_modem(struct gsm
+ {
+       unsigned int addr = 0;
+       unsigned int modem = 0;
++      unsigned int brk = 0;
+       struct gsm_dlci *dlci;
+       int len = clen;
+       u8 *dp = data;
+@@ -1117,6 +1118,16 @@ static void gsm_control_modem(struct gsm
+               if (len == 0)
+                       return;
+       }
++      len--;
++      if (len > 0) {
++              while (gsm_read_ea(&brk, *dp++) == 0) {
++                      len--;
++                      if (len == 0)
++                              return;
++              }
++              modem <<= 7;
++              modem |= (brk & 0x7f);
++      }
+       tty = tty_port_tty_get(&dlci->port);
+       gsm_process_modem(tty, dlci, modem, clen);
+       if (tty) {