From: Greg Kroah-Hartman Date: Sun, 10 Apr 2016 18:00:47 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v4.5.1~17 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3197abaa8329d5bea7da8ebac39ed62a91a08813;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: bitops-do-not-default-to-__clear_bit-for-__clear_bit_unlock.patch drm-radeon-don-t-drop-dp-2.7-ghz-link-setup-on-some-cards.patch fs-coredump-prevent-fsuid-0-dumps-into-user-controlled-directories.patch ipr-fix-out-of-bounds-null-overwrite.patch ipr-fix-regression-when-loading-firmware.patch kbuild-mkspec-fix-grub2-installkernel-issue.patch md-multipath-don-t-hardcopy-bio-in-.make_request-path.patch md-raid5-compare-apples-to-apples-or-sectors-to-sectors.patch rapidio-rionet-fix-deadlock-on-smp.patch scripts-coccinelle-modernize.patch splice-handle-zero-nr_pages-in-splice_to_pipe.patch target-fix-target_release_cmd_kref-shutdown-comp-leak.patch tracing-fix-crash-from-reading-trace_pipe-with-sendfile.patch tracing-fix-trace_printk-to-print-when-not-using-bprintk.patch tracing-have-preempt-irqs-off-trace-preempt-disabled-functions.patch xfs-fix-two-memory-leaks-in-xfs_attr_list.c-error-paths.patch xtensa-clear-all-dbreakc-registers-on-start.patch xtensa-iss-don-t-hang-if-stdin-eof-is-reached.patch --- diff --git a/queue-3.14/bitops-do-not-default-to-__clear_bit-for-__clear_bit_unlock.patch b/queue-3.14/bitops-do-not-default-to-__clear_bit-for-__clear_bit_unlock.patch new file mode 100644 index 00000000000..5c044c03020 --- /dev/null +++ b/queue-3.14/bitops-do-not-default-to-__clear_bit-for-__clear_bit_unlock.patch @@ -0,0 +1,84 @@ +From f75d48644c56a31731d17fa693c8175328957e1d Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Wed, 9 Mar 2016 12:40:54 +0100 +Subject: bitops: Do not default to __clear_bit() for __clear_bit_unlock() + +From: Peter Zijlstra + +commit f75d48644c56a31731d17fa693c8175328957e1d upstream. + +__clear_bit_unlock() is a special little snowflake. While it carries the +non-atomic '__' prefix, it is specifically documented to pair with +test_and_set_bit() and therefore should be 'somewhat' atomic. + +Therefore the generic implementation of __clear_bit_unlock() cannot use +the fully non-atomic __clear_bit() as a default. + +If an arch is able to do better; is must provide an implementation of +__clear_bit_unlock() itself. + +Specifically, this came up as a result of hackbench livelock'ing in +slab_lock() on ARC with SMP + SLUB + !LLSC. + +The issue was incorrect pairing of atomic ops. + + slab_lock() -> bit_spin_lock() -> test_and_set_bit() + slab_unlock() -> __bit_spin_unlock() -> __clear_bit() + +The non serializing __clear_bit() was getting "lost" + + 80543b8e: ld_s r2,[r13,0] <--- (A) Finds PG_locked is set + 80543b90: or r3,r2,1 <--- (B) other core unlocks right here + 80543b94: st_s r3,[r13,0] <--- (C) sets PG_locked (overwrites unlock) + +Fixes ARC STAR 9000817404 (and probably more). + +Reported-by: Vineet Gupta +Tested-by: Vineet Gupta +Signed-off-by: Peter Zijlstra (Intel) +Cc: Andrew Morton +Cc: Christoph Lameter +Cc: David Rientjes +Cc: Helge Deller +Cc: James E.J. Bottomley +Cc: Joonsoo Kim +Cc: Linus Torvalds +Cc: Noam Camus +Cc: Paul E. McKenney +Cc: Pekka Enberg +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Link: http://lkml.kernel.org/r/20160309114054.GJ6356@twins.programming.kicks-ass.net +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + include/asm-generic/bitops/lock.h | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/include/asm-generic/bitops/lock.h ++++ b/include/asm-generic/bitops/lock.h +@@ -29,16 +29,16 @@ do { \ + * @nr: the bit to set + * @addr: the address to start counting from + * +- * This operation is like clear_bit_unlock, however it is not atomic. +- * It does provide release barrier semantics so it can be used to unlock +- * a bit lock, however it would only be used if no other CPU can modify +- * any bits in the memory until the lock is released (a good example is +- * if the bit lock itself protects access to the other bits in the word). ++ * A weaker form of clear_bit_unlock() as used by __bit_lock_unlock(). If all ++ * the bits in the word are protected by this lock some archs can use weaker ++ * ops to safely unlock. ++ * ++ * See for example x86's implementation. + */ + #define __clear_bit_unlock(nr, addr) \ + do { \ +- smp_mb(); \ +- __clear_bit(nr, addr); \ ++ smp_mb__before_atomic(); \ ++ clear_bit(nr, addr); \ + } while (0) + + #endif /* _ASM_GENERIC_BITOPS_LOCK_H_ */ diff --git a/queue-3.14/drm-radeon-don-t-drop-dp-2.7-ghz-link-setup-on-some-cards.patch b/queue-3.14/drm-radeon-don-t-drop-dp-2.7-ghz-link-setup-on-some-cards.patch new file mode 100644 index 00000000000..aad9d279780 --- /dev/null +++ b/queue-3.14/drm-radeon-don-t-drop-dp-2.7-ghz-link-setup-on-some-cards.patch @@ -0,0 +1,51 @@ +From 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 Mon Sep 17 00:00:00 2001 +From: Mario Kleiner +Date: Sun, 6 Mar 2016 02:39:53 +0100 +Subject: drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards. + +From: Mario Kleiner + +commit 459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 upstream. + +As observed on Apple iMac10,1, DCE-3.2, RV-730, +link rate of 2.7 Ghz is not selected, because +the args.v1.ucConfig flag setting for 2.7 Ghz +gets overwritten by a following assignment of +the transmitter to use. + +Move link rate setup a few lines down to fix this. +In practice this didn't have any positive or +negative effect on display setup on the tested +iMac10,1 so i don't know if backporting to stable +makes sense or not. + +Signed-off-by: Mario Kleiner +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/atombios_encoders.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/radeon/atombios_encoders.c ++++ b/drivers/gpu/drm/radeon/atombios_encoders.c +@@ -895,8 +895,6 @@ atombios_dig_encoder_setup(struct drm_en + else + args.v1.ucLaneNum = 4; + +- if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) && (dp_clock == 270000)) +- args.v1.ucConfig |= ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ; + switch (radeon_encoder->encoder_id) { + case ENCODER_OBJECT_ID_INTERNAL_UNIPHY: + args.v1.ucConfig = ATOM_ENCODER_CONFIG_V2_TRANSMITTER1; +@@ -913,6 +911,10 @@ atombios_dig_encoder_setup(struct drm_en + args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKB; + else + args.v1.ucConfig |= ATOM_ENCODER_CONFIG_LINKA; ++ ++ if (ENCODER_MODE_IS_DP(args.v1.ucEncoderMode) && (dp_clock == 270000)) ++ args.v1.ucConfig |= ATOM_ENCODER_CONFIG_DPLINKRATE_2_70GHZ; ++ + break; + case 2: + case 3: diff --git a/queue-3.14/fs-coredump-prevent-fsuid-0-dumps-into-user-controlled-directories.patch b/queue-3.14/fs-coredump-prevent-fsuid-0-dumps-into-user-controlled-directories.patch new file mode 100644 index 00000000000..5c42533b6ca --- /dev/null +++ b/queue-3.14/fs-coredump-prevent-fsuid-0-dumps-into-user-controlled-directories.patch @@ -0,0 +1,165 @@ +From 378c6520e7d29280f400ef2ceaf155c86f05a71a Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Tue, 22 Mar 2016 14:25:36 -0700 +Subject: fs/coredump: prevent fsuid=0 dumps into user-controlled directories + +From: Jann Horn + +commit 378c6520e7d29280f400ef2ceaf155c86f05a71a upstream. + +This commit fixes the following security hole affecting systems where +all of the following conditions are fulfilled: + + - The fs.suid_dumpable sysctl is set to 2. + - The kernel.core_pattern sysctl's value starts with "/". (Systems + where kernel.core_pattern starts with "|/" are not affected.) + - Unprivileged user namespace creation is permitted. (This is + true on Linux >=3.8, but some distributions disallow it by + default using a distro patch.) + +Under these conditions, if a program executes under secure exec rules, +causing it to run with the SUID_DUMP_ROOT flag, then unshares its user +namespace, changes its root directory and crashes, the coredump will be +written using fsuid=0 and a path derived from kernel.core_pattern - but +this path is interpreted relative to the root directory of the process, +allowing the attacker to control where a coredump will be written with +root privileges. + +To fix the security issue, always interpret core_pattern for dumps that +are written under SUID_DUMP_ROOT relative to the root directory of init. + +Signed-off-by: Jann Horn +Acked-by: Kees Cook +Cc: Al Viro +Cc: "Eric W. Biederman" +Cc: Andy Lutomirski +Cc: Oleg Nesterov +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/um/drivers/mconsole_kern.c | 2 +- + fs/coredump.c | 30 ++++++++++++++++++++++++++---- + fs/fhandle.c | 2 +- + fs/open.c | 6 ++---- + include/linux/fs.h | 2 +- + kernel/sysctl_binary.c | 2 +- + 6 files changed, 32 insertions(+), 12 deletions(-) + +--- a/arch/um/drivers/mconsole_kern.c ++++ b/arch/um/drivers/mconsole_kern.c +@@ -133,7 +133,7 @@ void mconsole_proc(struct mc_request *re + ptr += strlen("proc"); + ptr = skip_spaces(ptr); + +- file = file_open_root(mnt->mnt_root, mnt, ptr, O_RDONLY); ++ file = file_open_root(mnt->mnt_root, mnt, ptr, O_RDONLY, 0); + if (IS_ERR(file)) { + mconsole_reply(req, "Failed to open file", 1, 0); + printk(KERN_ERR "open /proc/%s: %ld\n", ptr, PTR_ERR(file)); +--- a/fs/coredump.c ++++ b/fs/coredump.c +@@ -32,6 +32,9 @@ + #include + #include + #include ++#include ++#include ++#include + + #include + #include +@@ -613,6 +616,8 @@ void do_coredump(const siginfo_t *siginf + } + } else { + struct inode *inode; ++ int open_flags = O_CREAT | O_RDWR | O_NOFOLLOW | ++ O_LARGEFILE | O_EXCL; + + if (cprm.limit < binfmt->min_coredump) + goto fail_unlock; +@@ -651,10 +656,27 @@ void do_coredump(const siginfo_t *siginf + * what matters is that at least one of the two processes + * writes its coredump successfully, not which one. + */ +- cprm.file = filp_open(cn.corename, +- O_CREAT | 2 | O_NOFOLLOW | +- O_LARGEFILE | O_EXCL, +- 0600); ++ if (need_suid_safe) { ++ /* ++ * Using user namespaces, normal user tasks can change ++ * their current->fs->root to point to arbitrary ++ * directories. Since the intention of the "only dump ++ * with a fully qualified path" rule is to control where ++ * coredumps may be placed using root privileges, ++ * current->fs->root must not be used. Instead, use the ++ * root directory of init_task. ++ */ ++ struct path root; ++ ++ task_lock(&init_task); ++ get_fs_root(init_task.fs, &root); ++ task_unlock(&init_task); ++ cprm.file = file_open_root(root.dentry, root.mnt, ++ cn.corename, open_flags, 0600); ++ path_put(&root); ++ } else { ++ cprm.file = filp_open(cn.corename, open_flags, 0600); ++ } + if (IS_ERR(cprm.file)) + goto fail_unlock; + +--- a/fs/fhandle.c ++++ b/fs/fhandle.c +@@ -228,7 +228,7 @@ long do_handle_open(int mountdirfd, + path_put(&path); + return fd; + } +- file = file_open_root(path.dentry, path.mnt, "", open_flag); ++ file = file_open_root(path.dentry, path.mnt, "", open_flag, 0); + if (IS_ERR(file)) { + put_unused_fd(fd); + retval = PTR_ERR(file); +--- a/fs/open.c ++++ b/fs/open.c +@@ -945,14 +945,12 @@ struct file *filp_open(const char *filen + EXPORT_SYMBOL(filp_open); + + struct file *file_open_root(struct dentry *dentry, struct vfsmount *mnt, +- const char *filename, int flags) ++ const char *filename, int flags, umode_t mode) + { + struct open_flags op; +- int err = build_open_flags(flags, 0, &op); ++ int err = build_open_flags(flags, mode, &op); + if (err) + return ERR_PTR(err); +- if (flags & O_CREAT) +- return ERR_PTR(-EINVAL); + if (!filename && (flags & O_DIRECTORY)) + if (!dentry->d_inode->i_op->lookup) + return ERR_PTR(-ENOTDIR); +--- a/include/linux/fs.h ++++ b/include/linux/fs.h +@@ -2078,7 +2078,7 @@ extern long do_sys_open(int dfd, const c + extern struct file *file_open_name(struct filename *, int, umode_t); + extern struct file *filp_open(const char *, int, umode_t); + extern struct file *file_open_root(struct dentry *, struct vfsmount *, +- const char *, int); ++ const char *, int, umode_t); + extern struct file * dentry_open(const struct path *, int, const struct cred *); + extern int filp_close(struct file *, fl_owner_t id); + +--- a/kernel/sysctl_binary.c ++++ b/kernel/sysctl_binary.c +@@ -1320,7 +1320,7 @@ static ssize_t binary_sysctl(const int * + } + + mnt = task_active_pid_ns(current)->proc_mnt; +- file = file_open_root(mnt->mnt_root, mnt, pathname, flags); ++ file = file_open_root(mnt->mnt_root, mnt, pathname, flags, 0); + result = PTR_ERR(file); + if (IS_ERR(file)) + goto out_putname; diff --git a/queue-3.14/ipr-fix-out-of-bounds-null-overwrite.patch b/queue-3.14/ipr-fix-out-of-bounds-null-overwrite.patch new file mode 100644 index 00000000000..e15337587c4 --- /dev/null +++ b/queue-3.14/ipr-fix-out-of-bounds-null-overwrite.patch @@ -0,0 +1,43 @@ +From d63c7dd5bcb9441af0526d370c43a65ca2c980d9 Mon Sep 17 00:00:00 2001 +From: Insu Yun +Date: Wed, 6 Jan 2016 12:44:01 -0500 +Subject: ipr: Fix out-of-bounds null overwrite + +From: Insu Yun + +commit d63c7dd5bcb9441af0526d370c43a65ca2c980d9 upstream. + +Return value of snprintf is not bound by size value, 2nd argument. +(https://www.kernel.org/doc/htmldocs/kernel-api/API-snprintf.html). +Return value is number of printed chars, can be larger than 2nd +argument. Therefore, it can write null byte out of bounds ofbuffer. +Since snprintf puts null, it does not need to put additional null byte. + +Signed-off-by: Insu Yun +Reviewed-by: Shane Seymour +Signed-off-by: Martin K. Petersen +Cc: Ben Hutchings +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/ipr.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/scsi/ipr.c ++++ b/drivers/scsi/ipr.c +@@ -3946,13 +3946,12 @@ static ssize_t ipr_store_update_fw(struc + struct ipr_sglist *sglist; + char fname[100]; + char *src; +- int len, result, dnld_size; ++ int result, dnld_size; + + if (!capable(CAP_SYS_ADMIN)) + return -EACCES; + +- len = snprintf(fname, 99, "%s", buf); +- fname[len-1] = '\0'; ++ snprintf(fname, sizeof(fname), "%s", buf); + + if (request_firmware(&fw_entry, fname, &ioa_cfg->pdev->dev)) { + dev_err(&ioa_cfg->pdev->dev, "Firmware file %s not found\n", fname); diff --git a/queue-3.14/ipr-fix-regression-when-loading-firmware.patch b/queue-3.14/ipr-fix-regression-when-loading-firmware.patch new file mode 100644 index 00000000000..123d9325eea --- /dev/null +++ b/queue-3.14/ipr-fix-regression-when-loading-firmware.patch @@ -0,0 +1,50 @@ +From 21b81716c6bff24cda52dc75588455f879ddbfe9 Mon Sep 17 00:00:00 2001 +From: Gabriel Krisman Bertazi +Date: Thu, 25 Feb 2016 13:54:20 -0300 +Subject: ipr: Fix regression when loading firmware + +From: Gabriel Krisman Bertazi + +commit 21b81716c6bff24cda52dc75588455f879ddbfe9 upstream. + +Commit d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite") removed +the end of line handling when storing the update_fw sysfs attribute. +This changed the userpace API because it started refusing writes +terminated by a line feed, which broke the update tools we already have. + +This patch re-adds that handling, so both a write terminated by a line +feed or not can make it through with the update. + +Fixes: d63c7dd5bcb9 ("ipr: Fix out-of-bounds null overwrite") +Signed-off-by: Gabriel Krisman Bertazi +Cc: Insu Yun +Acked-by: Brian King +Signed-off-by: Martin K. Petersen +Cc: Ben Hutchings +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/ipr.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/scsi/ipr.c ++++ b/drivers/scsi/ipr.c +@@ -3946,6 +3946,7 @@ static ssize_t ipr_store_update_fw(struc + struct ipr_sglist *sglist; + char fname[100]; + char *src; ++ char *endline; + int result, dnld_size; + + if (!capable(CAP_SYS_ADMIN)) +@@ -3953,6 +3954,10 @@ static ssize_t ipr_store_update_fw(struc + + snprintf(fname, sizeof(fname), "%s", buf); + ++ endline = strchr(fname, '\n'); ++ if (endline) ++ *endline = '\0'; ++ + if (request_firmware(&fw_entry, fname, &ioa_cfg->pdev->dev)) { + dev_err(&ioa_cfg->pdev->dev, "Firmware file %s not found\n", fname); + return -EIO; diff --git a/queue-3.14/kbuild-mkspec-fix-grub2-installkernel-issue.patch b/queue-3.14/kbuild-mkspec-fix-grub2-installkernel-issue.patch new file mode 100644 index 00000000000..01e5976c46d --- /dev/null +++ b/queue-3.14/kbuild-mkspec-fix-grub2-installkernel-issue.patch @@ -0,0 +1,52 @@ +From c8b08ca558c0067bc9e15ce3f1e70af260410bb2 Mon Sep 17 00:00:00 2001 +From: Jiri Kosina +Date: Fri, 26 Feb 2016 16:15:17 +0100 +Subject: kbuild/mkspec: fix grub2 installkernel issue + +From: Jiri Kosina + +commit c8b08ca558c0067bc9e15ce3f1e70af260410bb2 upstream. + +mkspec is copying built kernel to temporrary location + + /boot/vmlinuz-$KERNELRELEASE-rpm + +and runs installkernel on it. This however directly leads to grub2 +menuentry for this suffixed binary being generated as well during the run +of installkernel script. + +Later in the process the temporary -rpm suffixed files are removed, and +therefore we end up with spurious (and non-functional) grub2 menu entries +for each installed kernel RPM. + +Fix that by using a different temporary name (prefixed by '.'), so that +the binary is not recognized as an actual kernel binary and no menuentry +is created for it. + +Signed-off-by: Jiri Kosina +Fixes: 3c9c7a14b627 ("rpm-pkg: add %post section to create initramfs and grub hooks") +Signed-off-by: Michal Marek +Signed-off-by: Greg Kroah-Hartman + +--- + scripts/package/mkspec | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/scripts/package/mkspec ++++ b/scripts/package/mkspec +@@ -131,11 +131,11 @@ echo 'rm -rf $RPM_BUILD_ROOT' + echo "" + echo "%post" + echo "if [ -x /sbin/installkernel -a -r /boot/vmlinuz-$KERNELRELEASE -a -r /boot/System.map-$KERNELRELEASE ]; then" +-echo "cp /boot/vmlinuz-$KERNELRELEASE /boot/vmlinuz-$KERNELRELEASE-rpm" +-echo "cp /boot/System.map-$KERNELRELEASE /boot/System.map-$KERNELRELEASE-rpm" ++echo "cp /boot/vmlinuz-$KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm" ++echo "cp /boot/System.map-$KERNELRELEASE /boot/.System.map-$KERNELRELEASE-rpm" + echo "rm -f /boot/vmlinuz-$KERNELRELEASE /boot/System.map-$KERNELRELEASE" +-echo "/sbin/installkernel $KERNELRELEASE /boot/vmlinuz-$KERNELRELEASE-rpm /boot/System.map-$KERNELRELEASE-rpm" +-echo "rm -f /boot/vmlinuz-$KERNELRELEASE-rpm /boot/System.map-$KERNELRELEASE-rpm" ++echo "/sbin/installkernel $KERNELRELEASE /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" ++echo "rm -f /boot/.vmlinuz-$KERNELRELEASE-rpm /boot/.System.map-$KERNELRELEASE-rpm" + echo "fi" + echo "" + echo "%files" diff --git a/queue-3.14/md-multipath-don-t-hardcopy-bio-in-.make_request-path.patch b/queue-3.14/md-multipath-don-t-hardcopy-bio-in-.make_request-path.patch new file mode 100644 index 00000000000..3b881aa9f78 --- /dev/null +++ b/queue-3.14/md-multipath-don-t-hardcopy-bio-in-.make_request-path.patch @@ -0,0 +1,41 @@ +From fafcde3ac1a418688a734365203a12483b83907a Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Sat, 12 Mar 2016 09:29:40 +0800 +Subject: md: multipath: don't hardcopy bio in .make_request path + +From: Ming Lei + +commit fafcde3ac1a418688a734365203a12483b83907a upstream. + +Inside multipath_make_request(), multipath maps the incoming +bio into low level device's bio, but it is totally wrong to +copy the bio into mapped bio via '*mapped_bio = *bio'. For +example, .__bi_remaining is kept in the copy, especially if +the incoming bio is chained to via bio splitting, so .bi_end_io +can't be called for the mapped bio at all in the completing path +in this kind of situation. + +This patch fixes the issue by using clone style. + +Reported-and-tested-by: Andrea Righi +Signed-off-by: Ming Lei +Signed-off-by: Shaohua Li +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/multipath.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/md/multipath.c ++++ b/drivers/md/multipath.c +@@ -131,7 +131,9 @@ static void multipath_make_request(struc + } + multipath = conf->multipaths + mp_bh->path; + +- mp_bh->bio = *bio; ++ bio_init(&mp_bh->bio); ++ __bio_clone_fast(&mp_bh->bio, bio); ++ + mp_bh->bio.bi_iter.bi_sector += multipath->rdev->data_offset; + mp_bh->bio.bi_bdev = multipath->rdev->bdev; + mp_bh->bio.bi_rw |= REQ_FAILFAST_TRANSPORT; diff --git a/queue-3.14/md-raid5-compare-apples-to-apples-or-sectors-to-sectors.patch b/queue-3.14/md-raid5-compare-apples-to-apples-or-sectors-to-sectors.patch new file mode 100644 index 00000000000..263a21cf3e5 --- /dev/null +++ b/queue-3.14/md-raid5-compare-apples-to-apples-or-sectors-to-sectors.patch @@ -0,0 +1,37 @@ +From e7597e69dec59b65c5525db1626b9d34afdfa678 Mon Sep 17 00:00:00 2001 +From: Jes Sorensen +Date: Tue, 16 Feb 2016 16:44:24 -0500 +Subject: md/raid5: Compare apples to apples (or sectors to sectors) + +From: Jes Sorensen + +commit e7597e69dec59b65c5525db1626b9d34afdfa678 upstream. + +'max_discard_sectors' is in sectors, while 'stripe' is in bytes. + +This fixes the problem where DISCARD would get disabled on some larger +RAID5 configurations (6 or more drives in my testing), while it worked +as expected with smaller configurations. + +Fixes: 620125f2bf8 ("MD: raid5 trim support") +Signed-off-by: Jes Sorensen +Signed-off-by: Shaohua Li +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/md/raid5.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -6166,8 +6166,8 @@ static int run(struct mddev *mddev) + } + + if (discard_supported && +- mddev->queue->limits.max_discard_sectors >= stripe && +- mddev->queue->limits.discard_granularity >= stripe) ++ mddev->queue->limits.max_discard_sectors >= (stripe >> 9) && ++ mddev->queue->limits.discard_granularity >= stripe) + queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, + mddev->queue); + else diff --git a/queue-3.14/rapidio-rionet-fix-deadlock-on-smp.patch b/queue-3.14/rapidio-rionet-fix-deadlock-on-smp.patch new file mode 100644 index 00000000000..12151e8d04e --- /dev/null +++ b/queue-3.14/rapidio-rionet-fix-deadlock-on-smp.patch @@ -0,0 +1,48 @@ +From 36915976eca58f2eefa040ba8f9939672564df61 Mon Sep 17 00:00:00 2001 +From: Aurelien Jacquiot +Date: Tue, 22 Mar 2016 14:25:42 -0700 +Subject: rapidio/rionet: fix deadlock on SMP + +From: Aurelien Jacquiot + +commit 36915976eca58f2eefa040ba8f9939672564df61 upstream. + +Fix deadlocking during concurrent receive and transmit operations on SMP +platforms caused by the use of incorrect lock: on transmit 'tx_lock' +spinlock should be used instead of 'lock' which is used for receive +operation. + +This fix is applicable to kernel versions starting from v2.15. + +Signed-off-by: Aurelien Jacquiot +Signed-off-by: Alexandre Bounine +Cc: Matt Porter +Cc: Andre van Herk +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/rionet.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/rionet.c ++++ b/drivers/net/rionet.c +@@ -280,7 +280,7 @@ static void rionet_outb_msg_event(struct + struct net_device *ndev = dev_id; + struct rionet_private *rnet = netdev_priv(ndev); + +- spin_lock(&rnet->lock); ++ spin_lock(&rnet->tx_lock); + + if (netif_msg_intr(rnet)) + printk(KERN_INFO +@@ -299,7 +299,7 @@ static void rionet_outb_msg_event(struct + if (rnet->tx_cnt < RIONET_TX_RING_SIZE) + netif_wake_queue(ndev); + +- spin_unlock(&rnet->lock); ++ spin_unlock(&rnet->tx_lock); + } + + static int rionet_open(struct net_device *ndev) diff --git a/queue-3.14/scripts-coccinelle-modernize.patch b/queue-3.14/scripts-coccinelle-modernize.patch new file mode 100644 index 00000000000..a9507203438 --- /dev/null +++ b/queue-3.14/scripts-coccinelle-modernize.patch @@ -0,0 +1,31 @@ +From 1b669e713f277a4d4b3cec84e13d16544ac8286d Mon Sep 17 00:00:00 2001 +From: Julia Lawall +Date: Thu, 18 Feb 2016 00:16:14 +0100 +Subject: scripts/coccinelle: modernize & + +From: Julia Lawall + +commit 1b669e713f277a4d4b3cec84e13d16544ac8286d upstream. + +& is no longer allowed in column 0, since Coccinelle 1.0.4. + +Signed-off-by: Julia Lawall +Tested-by: Nishanth Menon +Signed-off-by: Michal Marek +Signed-off-by: Greg Kroah-Hartman + +--- + scripts/coccinelle/iterators/use_after_iter.cocci | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/scripts/coccinelle/iterators/use_after_iter.cocci ++++ b/scripts/coccinelle/iterators/use_after_iter.cocci +@@ -123,7 +123,7 @@ list_remove_head(x,c,...) + | + sizeof(<+...c...+>) + | +-&c->member ++ &c->member + | + c = E + | diff --git a/queue-3.14/series b/queue-3.14/series index 46c44867ca6..e6b2f50ce94 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -48,3 +48,21 @@ jbd2-fix-fs-corruption-possibility-in-jbd2_journal_destroy-on-umount-path.patch bcache-fix-cache_set_flush-null-pointer-dereference-on-oom.patch watchdog-rc32434_wdt-fix-ioctl-error-handling.patch bluetooth-add-new-ar3012-id-0489-e095.patch +splice-handle-zero-nr_pages-in-splice_to_pipe.patch +xtensa-iss-don-t-hang-if-stdin-eof-is-reached.patch +xtensa-clear-all-dbreakc-registers-on-start.patch +xfs-fix-two-memory-leaks-in-xfs_attr_list.c-error-paths.patch +md-raid5-compare-apples-to-apples-or-sectors-to-sectors.patch +md-multipath-don-t-hardcopy-bio-in-.make_request-path.patch +fs-coredump-prevent-fsuid-0-dumps-into-user-controlled-directories.patch +rapidio-rionet-fix-deadlock-on-smp.patch +ipr-fix-out-of-bounds-null-overwrite.patch +ipr-fix-regression-when-loading-firmware.patch +drm-radeon-don-t-drop-dp-2.7-ghz-link-setup-on-some-cards.patch +tracing-have-preempt-irqs-off-trace-preempt-disabled-functions.patch +tracing-fix-crash-from-reading-trace_pipe-with-sendfile.patch +tracing-fix-trace_printk-to-print-when-not-using-bprintk.patch +bitops-do-not-default-to-__clear_bit-for-__clear_bit_unlock.patch +scripts-coccinelle-modernize.patch +kbuild-mkspec-fix-grub2-installkernel-issue.patch +target-fix-target_release_cmd_kref-shutdown-comp-leak.patch diff --git a/queue-3.14/splice-handle-zero-nr_pages-in-splice_to_pipe.patch b/queue-3.14/splice-handle-zero-nr_pages-in-splice_to_pipe.patch new file mode 100644 index 00000000000..ed6c8370921 --- /dev/null +++ b/queue-3.14/splice-handle-zero-nr_pages-in-splice_to_pipe.patch @@ -0,0 +1,71 @@ +From d6785d9152147596f60234157da2b02540c3e60f Mon Sep 17 00:00:00 2001 +From: Rabin Vincent +Date: Thu, 10 Mar 2016 21:19:06 +0100 +Subject: splice: handle zero nr_pages in splice_to_pipe() + +From: Rabin Vincent + +commit d6785d9152147596f60234157da2b02540c3e60f upstream. + +Running the following command: + + busybox cat /sys/kernel/debug/tracing/trace_pipe > /dev/null + +with any tracing enabled pretty very quickly leads to various NULL +pointer dereferences and VM BUG_ON()s, such as these: + + BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 + IP: [] generic_pipe_buf_release+0xc/0x40 + Call Trace: + [] splice_direct_to_actor+0x143/0x1e0 + [] ? generic_pipe_buf_nosteal+0x10/0x10 + [] do_splice_direct+0x8f/0xb0 + [] do_sendfile+0x199/0x380 + [] SyS_sendfile64+0x90/0xa0 + [] entry_SYSCALL_64_fastpath+0x12/0x6d + + page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0) + kernel BUG at include/linux/mm.h:367! + invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC + RIP: [] generic_pipe_buf_release+0x3c/0x40 + Call Trace: + [] splice_direct_to_actor+0x143/0x1e0 + [] ? generic_pipe_buf_nosteal+0x10/0x10 + [] do_splice_direct+0x8f/0xb0 + [] do_sendfile+0x199/0x380 + [] SyS_sendfile64+0x90/0xa0 + [] tracesys_phase2+0x84/0x89 + +(busybox's cat uses sendfile(2), unlike the coreutils version) + +This is because tracing_splice_read_pipe() can call splice_to_pipe() +with spd->nr_pages == 0. spd_pages underflows in splice_to_pipe() and +we fill the page pointers and the other fields of the pipe_buffers with +garbage. + +All other callers of splice_to_pipe() avoid calling it when nr_pages == +0, and we could make tracing_splice_read_pipe() do that too, but it +seems reasonable to have splice_to_page() handle this condition +gracefully. + +Signed-off-by: Rabin Vincent +Reviewed-by: Christoph Hellwig +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- + fs/splice.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/splice.c ++++ b/fs/splice.c +@@ -189,6 +189,9 @@ ssize_t splice_to_pipe(struct pipe_inode + unsigned int spd_pages = spd->nr_pages; + int ret, do_wakeup, page_nr; + ++ if (!spd_pages) ++ return 0; ++ + ret = 0; + do_wakeup = 0; + page_nr = 0; diff --git a/queue-3.14/target-fix-target_release_cmd_kref-shutdown-comp-leak.patch b/queue-3.14/target-fix-target_release_cmd_kref-shutdown-comp-leak.patch new file mode 100644 index 00000000000..2a2ff2850ea --- /dev/null +++ b/queue-3.14/target-fix-target_release_cmd_kref-shutdown-comp-leak.patch @@ -0,0 +1,41 @@ +From 5e47f1985d7107331c3f64fb3ec83d66fd73577e Mon Sep 17 00:00:00 2001 +From: Himanshu Madhani +Date: Mon, 14 Mar 2016 22:47:37 -0700 +Subject: target: Fix target_release_cmd_kref shutdown comp leak + +From: Himanshu Madhani + +commit 5e47f1985d7107331c3f64fb3ec83d66fd73577e upstream. + +This patch fixes an active I/O shutdown bug for fabric +drivers using target_wait_for_sess_cmds(), where se_cmd +descriptor shutdown would result in hung tasks waiting +indefinitely for se_cmd->cmd_wait_comp to complete(). + +To address this bug, drop the incorrect list_del_init() +usage in target_wait_for_sess_cmds() and always complete() +during se_cmd target_release_cmd_kref() put, in order to +let caller invoke the final fabric release callback +into se_cmd->se_tfo->release_cmd() code. + +Reported-by: Himanshu Madhani +Tested-by: Himanshu Madhani +Signed-off-by: Himanshu Madhani +Signed-off-by: Nicholas Bellinger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/target/target_core_transport.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/target/target_core_transport.c ++++ b/drivers/target/target_core_transport.c +@@ -2484,8 +2484,6 @@ void target_wait_for_sess_cmds(struct se + + list_for_each_entry_safe(se_cmd, tmp_cmd, + &se_sess->sess_wait_list, se_cmd_list) { +- list_del_init(&se_cmd->se_cmd_list); +- + pr_debug("Waiting for se_cmd: %p t_state: %d, fabric state:" + " %d\n", se_cmd, se_cmd->t_state, + se_cmd->se_tfo->get_cmd_state(se_cmd)); diff --git a/queue-3.14/tracing-fix-crash-from-reading-trace_pipe-with-sendfile.patch b/queue-3.14/tracing-fix-crash-from-reading-trace_pipe-with-sendfile.patch new file mode 100644 index 00000000000..17f44202004 --- /dev/null +++ b/queue-3.14/tracing-fix-crash-from-reading-trace_pipe-with-sendfile.patch @@ -0,0 +1,40 @@ +From a29054d9478d0435ab01b7544da4f674ab13f533 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +Date: Fri, 18 Mar 2016 15:46:48 -0400 +Subject: tracing: Fix crash from reading trace_pipe with sendfile + +From: Steven Rostedt (Red Hat) + +commit a29054d9478d0435ab01b7544da4f674ab13f533 upstream. + +If tracing contains data and the trace_pipe file is read with sendfile(), +then it can trigger a NULL pointer dereference and various BUG_ON within the +VM code. + +There's a patch to fix this in the splice_to_pipe() code, but it's also a +good idea to not let that happen from trace_pipe either. + +Link: http://lkml.kernel.org/r/1457641146-9068-1-git-send-email-rabin@rab.in + +Reported-by: Rabin Vincent +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -4457,7 +4457,10 @@ static ssize_t tracing_splice_read_pipe( + + spd.nr_pages = i; + +- ret = splice_to_pipe(pipe, &spd); ++ if (i) ++ ret = splice_to_pipe(pipe, &spd); ++ else ++ ret = 0; + out: + splice_shrink_spd(&spd); + return ret; diff --git a/queue-3.14/tracing-fix-trace_printk-to-print-when-not-using-bprintk.patch b/queue-3.14/tracing-fix-trace_printk-to-print-when-not-using-bprintk.patch new file mode 100644 index 00000000000..0e4badc9625 --- /dev/null +++ b/queue-3.14/tracing-fix-trace_printk-to-print-when-not-using-bprintk.patch @@ -0,0 +1,78 @@ +From 3debb0a9ddb16526de8b456491b7db60114f7b5e Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +Date: Tue, 22 Mar 2016 17:30:58 -0400 +Subject: tracing: Fix trace_printk() to print when not using bprintk() + +From: Steven Rostedt (Red Hat) + +commit 3debb0a9ddb16526de8b456491b7db60114f7b5e upstream. + +The trace_printk() code will allocate extra buffers if the compile detects +that a trace_printk() is used. To do this, the format of the trace_printk() +is saved to the __trace_printk_fmt section, and if that section is bigger +than zero, the buffers are allocated (along with a message that this has +happened). + +If trace_printk() uses a format that is not a constant, and thus something +not guaranteed to be around when the print happens, the compiler optimizes +the fmt out, as it is not used, and the __trace_printk_fmt section is not +filled. This means the kernel will not allocate the special buffers needed +for the trace_printk() and the trace_printk() will not write anything to the +tracing buffer. + +Adding a "__used" to the variable in the __trace_printk_fmt section will +keep it around, even though it is set to NULL. This will keep the string +from being printed in the debugfs/tracing/printk_formats section as it is +not needed. + +Reported-by: Vlastimil Babka +Fixes: 07d777fe8c398 "tracing: Add percpu buffers for trace_printk()" +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/kernel.h | 6 +++--- + kernel/trace/trace_printk.c | 3 +++ + 2 files changed, 6 insertions(+), 3 deletions(-) + +--- a/include/linux/kernel.h ++++ b/include/linux/kernel.h +@@ -595,7 +595,7 @@ do { \ + + #define do_trace_printk(fmt, args...) \ + do { \ +- static const char *trace_printk_fmt \ ++ static const char *trace_printk_fmt __used \ + __attribute__((section("__trace_printk_fmt"))) = \ + __builtin_constant_p(fmt) ? fmt : NULL; \ + \ +@@ -639,7 +639,7 @@ int __trace_printk(unsigned long ip, con + */ + + #define trace_puts(str) ({ \ +- static const char *trace_printk_fmt \ ++ static const char *trace_printk_fmt __used \ + __attribute__((section("__trace_printk_fmt"))) = \ + __builtin_constant_p(str) ? str : NULL; \ + \ +@@ -661,7 +661,7 @@ extern void trace_dump_stack(int skip); + #define ftrace_vprintk(fmt, vargs) \ + do { \ + if (__builtin_constant_p(fmt)) { \ +- static const char *trace_printk_fmt \ ++ static const char *trace_printk_fmt __used \ + __attribute__((section("__trace_printk_fmt"))) = \ + __builtin_constant_p(fmt) ? fmt : NULL; \ + \ +--- a/kernel/trace/trace_printk.c ++++ b/kernel/trace/trace_printk.c +@@ -292,6 +292,9 @@ static int t_show(struct seq_file *m, vo + const char *str = *fmt; + int i; + ++ if (!*fmt) ++ return 0; ++ + seq_printf(m, "0x%lx : \"", *(unsigned long *)fmt); + + /* diff --git a/queue-3.14/tracing-have-preempt-irqs-off-trace-preempt-disabled-functions.patch b/queue-3.14/tracing-have-preempt-irqs-off-trace-preempt-disabled-functions.patch new file mode 100644 index 00000000000..42547f9c7d8 --- /dev/null +++ b/queue-3.14/tracing-have-preempt-irqs-off-trace-preempt-disabled-functions.patch @@ -0,0 +1,69 @@ +From cb86e05390debcc084cfdb0a71ed4c5dbbec517d Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +Date: Fri, 18 Mar 2016 12:27:43 -0400 +Subject: tracing: Have preempt(irqs)off trace preempt disabled functions + +From: Steven Rostedt (Red Hat) + +commit cb86e05390debcc084cfdb0a71ed4c5dbbec517d upstream. + +Joel Fernandes reported that the function tracing of preempt disabled +sections was not being reported when running either the preemptirqsoff or +preemptoff tracers. This was due to the fact that the function tracer +callback for those tracers checked if irqs were disabled before tracing. But +this fails when we want to trace preempt off locations as well. + +Joel explained that he wanted to see funcitons where interrupts are enabled +but preemption was disabled. The expected output he wanted: + + <...>-2265 1d.h1 3419us : preempt_count_sub <-irq_exit + <...>-2265 1d..1 3419us : __do_softirq <-irq_exit + <...>-2265 1d..1 3419us : msecs_to_jiffies <-__do_softirq + <...>-2265 1d..1 3420us : irqtime_account_irq <-__do_softirq + <...>-2265 1d..1 3420us : __local_bh_disable_ip <-__do_softirq + <...>-2265 1..s1 3421us : run_timer_softirq <-__do_softirq + <...>-2265 1..s1 3421us : hrtimer_run_pending <-run_timer_softirq + <...>-2265 1..s1 3421us : _raw_spin_lock_irq <-run_timer_softirq + <...>-2265 1d.s1 3422us : preempt_count_add <-_raw_spin_lock_irq + <...>-2265 1d.s2 3422us : _raw_spin_unlock_irq <-run_timer_softirq + <...>-2265 1..s2 3422us : preempt_count_sub <-_raw_spin_unlock_irq + <...>-2265 1..s1 3423us : rcu_bh_qs <-__do_softirq + <...>-2265 1d.s1 3423us : irqtime_account_irq <-__do_softirq + <...>-2265 1d.s1 3423us : __local_bh_enable <-__do_softirq + +There's a comment saying that the irq disabled check is because there's a +possible race that tracing_cpu may be set when the function is executed. But +I don't remember that race. For now, I added a check for preemption being +enabled too to not record the function, as there would be no race if that +was the case. I need to re-investigate this, as I'm now thinking that the +tracing_cpu will always be correct. But no harm in keeping the check for +now, except for the slight performance hit. + +Link: http://lkml.kernel.org/r/1457770386-88717-1-git-send-email-agnel.joel@gmail.com + +Fixes: 5e6d2b9cfa3a "tracing: Use one prologue for the preempt irqs off tracer function tracers" +Reported-by: Joel Fernandes +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace_irqsoff.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/kernel/trace/trace_irqsoff.c ++++ b/kernel/trace/trace_irqsoff.c +@@ -118,8 +118,12 @@ static int func_prolog_dec(struct trace_ + return 0; + + local_save_flags(*flags); +- /* slight chance to get a false positive on tracing_cpu */ +- if (!irqs_disabled_flags(*flags)) ++ /* ++ * Slight chance to get a false positive on tracing_cpu, ++ * although I'm starting to think there isn't a chance. ++ * Leave this for now just to be paranoid. ++ */ ++ if (!irqs_disabled_flags(*flags) && !preempt_count()) + return 0; + + *data = per_cpu_ptr(tr->trace_buffer.data, cpu); diff --git a/queue-3.14/xfs-fix-two-memory-leaks-in-xfs_attr_list.c-error-paths.patch b/queue-3.14/xfs-fix-two-memory-leaks-in-xfs_attr_list.c-error-paths.patch new file mode 100644 index 00000000000..d6b938cbcb9 --- /dev/null +++ b/queue-3.14/xfs-fix-two-memory-leaks-in-xfs_attr_list.c-error-paths.patch @@ -0,0 +1,57 @@ +From 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f Mon Sep 17 00:00:00 2001 +From: Mateusz Guzik +Date: Wed, 2 Mar 2016 09:51:09 +1100 +Subject: xfs: fix two memory leaks in xfs_attr_list.c error paths + +From: Mateusz Guzik + +commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f upstream. + +This plugs 2 trivial leaks in xfs_attr_shortform_list and +xfs_attr3_leaf_list_int. + +Signed-off-by: Mateusz Guzik +Reviewed-by: Eric Sandeen +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/xfs_attr_list.c | 19 ++++++++++--------- + 1 file changed, 10 insertions(+), 9 deletions(-) + +--- a/fs/xfs/xfs_attr_list.c ++++ b/fs/xfs/xfs_attr_list.c +@@ -205,8 +205,10 @@ xfs_attr_shortform_list(xfs_attr_list_co + sbp->namelen, + sbp->valuelen, + &sbp->name[sbp->namelen]); +- if (error) ++ if (error) { ++ kmem_free(sbuf); + return error; ++ } + if (context->seen_enough) + break; + cursor->offset++; +@@ -452,14 +454,13 @@ xfs_attr3_leaf_list_int( + args.rmtblkcnt = xfs_attr3_rmt_blocks( + args.dp->i_mount, valuelen); + retval = xfs_attr_rmtval_get(&args); +- if (retval) +- return retval; +- retval = context->put_listent(context, +- entry->flags, +- name_rmt->name, +- (int)name_rmt->namelen, +- valuelen, +- args.value); ++ if (!retval) ++ retval = context->put_listent(context, ++ entry->flags, ++ name_rmt->name, ++ (int)name_rmt->namelen, ++ valuelen, ++ args.value); + kmem_free(args.value); + } else { + retval = context->put_listent(context, diff --git a/queue-3.14/xtensa-clear-all-dbreakc-registers-on-start.patch b/queue-3.14/xtensa-clear-all-dbreakc-registers-on-start.patch new file mode 100644 index 00000000000..d06d710c359 --- /dev/null +++ b/queue-3.14/xtensa-clear-all-dbreakc-registers-on-start.patch @@ -0,0 +1,34 @@ +From 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Thu, 3 Mar 2016 18:34:29 +0300 +Subject: xtensa: clear all DBREAKC registers on start + +From: Max Filippov + +commit 7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab upstream. + +There are XCHAL_NUM_DBREAK registers, clear them all. +This also fixes cryptic assembler error message with binutils 2.25 when +XCHAL_NUM_DBREAK is 0: + + as: out of memory allocating 18446744073709551575 bytes after a total + of 495616 bytes + +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman + +--- + arch/xtensa/kernel/head.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/xtensa/kernel/head.S ++++ b/arch/xtensa/kernel/head.S +@@ -123,7 +123,7 @@ ENTRY(_startup) + wsr a0, icountlevel + + .set _index, 0 +- .rept XCHAL_NUM_DBREAK - 1 ++ .rept XCHAL_NUM_DBREAK + wsr a0, SREG_DBREAKC + _index + .set _index, _index + 1 + .endr diff --git a/queue-3.14/xtensa-iss-don-t-hang-if-stdin-eof-is-reached.patch b/queue-3.14/xtensa-iss-don-t-hang-if-stdin-eof-is-reached.patch new file mode 100644 index 00000000000..c57e375db05 --- /dev/null +++ b/queue-3.14/xtensa-iss-don-t-hang-if-stdin-eof-is-reached.patch @@ -0,0 +1,52 @@ +From 362014c8d9d51d504c167c44ac280169457732be Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Tue, 9 Feb 2016 01:02:38 +0300 +Subject: xtensa: ISS: don't hang if stdin EOF is reached + +From: Max Filippov + +commit 362014c8d9d51d504c167c44ac280169457732be upstream. + +Simulator stdin may be connected to a file, when its end is reached +kernel hangs in infinite loop inside rs_poll, because simc_poll always +signals that descriptor 0 is readable and simc_read always returns 0. +Check simc_read return value and exit loop if it's not positive. Also +don't rewind polling timer if it's zero. + +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman + +--- + arch/xtensa/platforms/iss/console.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/arch/xtensa/platforms/iss/console.c ++++ b/arch/xtensa/platforms/iss/console.c +@@ -100,21 +100,23 @@ static void rs_poll(unsigned long priv) + { + struct tty_port *port = (struct tty_port *)priv; + int i = 0; ++ int rd = 1; + unsigned char c; + + spin_lock(&timer_lock); + + while (simc_poll(0)) { +- simc_read(0, &c, 1); ++ rd = simc_read(0, &c, 1); ++ if (rd <= 0) ++ break; + tty_insert_flip_char(port, c, TTY_NORMAL); + i++; + } + + if (i) + tty_flip_buffer_push(port); +- +- +- mod_timer(&serial_timer, jiffies + SERIAL_TIMER_VALUE); ++ if (rd) ++ mod_timer(&serial_timer, jiffies + SERIAL_TIMER_VALUE); + spin_unlock(&timer_lock); + } +