From: Greg Kroah-Hartman Date: Thu, 20 Feb 2014 22:13:26 +0000 (-0800) Subject: 3.4-stable patches X-Git-Tag: v3.4.82~20 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=93bfe9b2e6981c9cdbd7d2ce00e36ec4a536488f;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches 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 --- 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 index 00000000000..b3028c23130 --- /dev/null +++ b/queue-3.4/lockd-send-correct-lock-when-granting-a-delayed-lock.patch @@ -0,0 +1,70 @@ +From 2ec197db1a56c9269d75e965f14c344b58b2a4f6 Mon Sep 17 00:00:00 2001 +From: NeilBrown +Date: Fri, 7 Feb 2014 17:10:26 +1100 +Subject: lockd: send correct lock when granting a delayed lock. + +From: NeilBrown + +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 +Signed-off-by: NeilBrown +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +-- +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 + +--- + 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 index 00000000000..0e8828ea536 --- /dev/null +++ b/queue-3.4/raw-test-against-runtime-value-of-max_raw_minors.patch @@ -0,0 +1,37 @@ +From 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf Mon Sep 17 00:00:00 2001 +From: Paul Bolle +Date: Tue, 4 Feb 2014 23:23:12 +0100 +Subject: raw: test against runtime value of max_raw_minors + +From: Paul Bolle + +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 +Acked-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman + +--- + 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]; diff --git a/queue-3.4/series b/queue-3.4/series index 51df4d47cba..9986c84ad98 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -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 index 00000000000..86e7ee5b2db --- /dev/null +++ b/queue-3.4/tty-n_gsm-fix-for-modems-with-brk-in-modem-status-control.patch @@ -0,0 +1,59 @@ +From 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f Mon Sep 17 00:00:00 2001 +From: Lars Poeschel +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 + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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) {