--- /dev/null
+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:
--- /dev/null
+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];
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
--- /dev/null
+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) {