This is a note to let you know that I've just added the patch titled
ovl: fix failure to fsync lower dir
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ovl-fix-failure-to-fsync-lower-dir.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d796e77f1dd541fe34481af2eee6454688d13982 Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il(a)gmail.com>
Date: Wed, 8 Nov 2017 09:39:46 +0200
Subject: ovl: fix failure to fsync lower dir
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Amir Goldstein <amir73il(a)gmail.com>
commit d796e77f1dd541fe34481af2eee6454688d13982 upstream.
As a writable mount, it is not expected for overlayfs to return
EINVAL/EROFS for fsync, even if dir/file is not changed.
This commit fixes the case of fsync of directory, which is easier to
address, because overlayfs already implements fsync file operation for
directories.
The problem reported by Raphael is that new PostgreSQL 10.0 with a
database in overlayfs where lower layer in squashfs fails to start.
The failure is due to fsync error, when PostgreSQL does fsync on all
existing db directories on startup and a specific directory exists
lower layer with no changes.
Reported-by: Raphael Hertzog <raphael(a)ouaza.com>
Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
Tested-by: Raphaël Hertzog <hertzog(a)debian.org>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/overlayfs/readdir.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -769,10 +769,14 @@ static int ovl_dir_fsync(struct file *fi
struct dentry *dentry = file->f_path.dentry;
struct file *realfile = od->realfile;
+ /* Nothing to sync for lower */
+ if (!OVL_TYPE_UPPER(ovl_path_type(dentry)))
+ return 0;
+
/*
* Need to check if we started out being a lower dir, but got copied up
*/
- if (!od->is_upper && OVL_TYPE_UPPER(ovl_path_type(dentry))) {
+ if (!od->is_upper) {
struct inode *inode = file_inode(file);
realfile = READ_ONCE(od->upperfile);
Patches currently in stable-queue which might be from amir73il(a)gmail.com are
queue-4.15/ovl-take-mnt_want_write-for-removing-impure-xattr.patch
queue-4.15/ovl-take-mnt_want_write-for-work-index-dir-setup.patch
queue-4.15/ovl-hash-directory-inodes-for-fsnotify.patch
queue-4.15/ovl-force-r-o-mount-when-index-dir-creation-fails.patch
queue-4.15/ovl-fix-failure-to-fsync-lower-dir.patch
This is a note to let you know that I've just added the patch titled
objtool: Fix switch-table detection
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
objtool-fix-switch-table-detection.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 99ce7962d52d1948ad6f2785e308d48e76e0a6ef Mon Sep 17 00:00:00 2001
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Thu, 8 Feb 2018 14:02:32 +0100
Subject: objtool: Fix switch-table detection
From: Peter Zijlstra <peterz(a)infradead.org>
commit 99ce7962d52d1948ad6f2785e308d48e76e0a6ef upstream.
Linus reported that GCC-7.3 generated a switch-table construct that
confused objtool. It turns out that, in particular due to KASAN, it is
possible to have unrelated .rodata usage in between the .rodata setup
for the switch-table and the following indirect jump.
The simple linear reverse search from the indirect jump would hit upon
the KASAN .rodata usage first and fail to find a switch_table,
resulting in a spurious 'sibling call with modified stack frame'
warning.
Fix this by creating a 'jump-stack' which we can 'unwind' during
reversal, thereby skipping over much of the in-between code.
This is not fool proof by any means, but is sufficient to make the
known cases work. Future work would be to construct more comprehensive
flow analysis code.
Reported-and-tested-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Acked-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/20180208130232.GF25235@hirez.programming.kicks-ass…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/objtool/check.c | 41 +++++++++++++++++++++++++++++++++++++++--
tools/objtool/check.h | 1 +
2 files changed, 40 insertions(+), 2 deletions(-)
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -851,8 +851,14 @@ static int add_switch_table(struct objto
* This is a fairly uncommon pattern which is new for GCC 6. As of this
* writing, there are 11 occurrences of it in the allmodconfig kernel.
*
+ * As of GCC 7 there are quite a few more of these and the 'in between' code
+ * is significant. Esp. with KASAN enabled some of the code between the mov
+ * and jmpq uses .rodata itself, which can confuse things.
+ *
* TODO: Once we have DWARF CFI and smarter instruction decoding logic,
* ensure the same register is used in the mov and jump instructions.
+ *
+ * NOTE: RETPOLINE made it harder still to decode dynamic jumps.
*/
static struct rela *find_switch_table(struct objtool_file *file,
struct symbol *func,
@@ -874,12 +880,25 @@ static struct rela *find_switch_table(st
text_rela->addend + 4);
if (!rodata_rela)
return NULL;
+
file->ignore_unreachables = true;
return rodata_rela;
}
/* case 3 */
- func_for_each_insn_continue_reverse(file, func, insn) {
+ /*
+ * Backward search using the @first_jump_src links, these help avoid
+ * much of the 'in between' code. Which avoids us getting confused by
+ * it.
+ */
+ for (insn = list_prev_entry(insn, list);
+
+ &insn->list != &file->insn_list &&
+ insn->sec == func->sec &&
+ insn->offset >= func->offset;
+
+ insn = insn->first_jump_src ?: list_prev_entry(insn, list)) {
+
if (insn->type == INSN_JUMP_DYNAMIC)
break;
@@ -909,14 +928,32 @@ static struct rela *find_switch_table(st
return NULL;
}
+
static int add_func_switch_tables(struct objtool_file *file,
struct symbol *func)
{
- struct instruction *insn, *prev_jump = NULL;
+ struct instruction *insn, *last = NULL, *prev_jump = NULL;
struct rela *rela, *prev_rela = NULL;
int ret;
func_for_each_insn(file, func, insn) {
+ if (!last)
+ last = insn;
+
+ /*
+ * Store back-pointers for unconditional forward jumps such
+ * that find_switch_table() can back-track using those and
+ * avoid some potentially confusing code.
+ */
+ if (insn->type == INSN_JUMP_UNCONDITIONAL && insn->jump_dest &&
+ insn->offset > last->offset &&
+ insn->jump_dest->offset > insn->offset &&
+ !insn->jump_dest->first_jump_src) {
+
+ insn->jump_dest->first_jump_src = insn;
+ last = insn->jump_dest;
+ }
+
if (insn->type != INSN_JUMP_DYNAMIC)
continue;
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -47,6 +47,7 @@ struct instruction {
bool alt_group, visited, dead_end, ignore, hint, save, restore, ignore_alts;
struct symbol *call_dest;
struct instruction *jump_dest;
+ struct instruction *first_jump_src;
struct list_head alts;
struct symbol *func;
struct stack_op stack_op;
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.15/clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
queue-4.15/objtool-fix-switch-table-detection.patch
queue-4.15/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.15/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 05:02:38 -0500
Subject: mn10300/misalignment: Use SIGSEGV SEGV_MAPERR to report a failed user copy
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 6ac1dc736b323011a55ecd1fc5897c24c4f77cbd upstream.
Setting si_code to 0 is the same a setting si_code to SI_USER which is definitely
not correct. With si_code set to SI_USER si_pid and si_uid will be copied to
userspace instead of si_addr. Which is very wrong.
So fix this by using a sensible si_code (SEGV_MAPERR) for this failure.
Fixes: b920de1b77b7 ("mn10300: add the MN10300/AM33 architecture to the kernel")
Cc: David Howells <dhowells(a)redhat.com>
Cc: Masakazu Urade <urade.masakazu(a)jp.panasonic.com>
Cc: Koichi Yasutake <yasutake.koichi(a)jp.panasonic.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mn10300/mm/misalignment.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mn10300/mm/misalignment.c
+++ b/arch/mn10300/mm/misalignment.c
@@ -437,7 +437,7 @@ transfer_failed:
info.si_signo = SIGSEGV;
info.si_errno = 0;
- info.si_code = 0;
+ info.si_code = SEGV_MAPERR;
info.si_addr = (void *) regs->pc;
force_sig_info(SIGSEGV, &info, current);
return;
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-4.15/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.15/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
queue-4.15/mn10300-misalignment-use-sigsegv-segv_maperr-to-report-a-failed-user-copy.patch
This is a note to let you know that I've just added the patch titled
ftrace: Remove incorrect setting of glob search field
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ftrace-remove-incorrect-setting-of-glob-search-field.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7b6586562708d2b3a04fe49f217ddbadbbbb0546 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Mon, 5 Feb 2018 22:05:31 -0500
Subject: ftrace: Remove incorrect setting of glob search field
From: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
commit 7b6586562708d2b3a04fe49f217ddbadbbbb0546 upstream.
__unregister_ftrace_function_probe() will incorrectly parse the glob filter
because it resets the search variable that was setup by filter_parse_regex().
Al Viro reported this:
After that call of filter_parse_regex() we could have func_g.search not
equal to glob only if glob started with '!' or '*'. In the former case
we would've buggered off with -EINVAL (not = 1). In the latter we
would've set func_g.search equal to glob + 1, calculated the length of
that thing in func_g.len and proceeded to reset func_g.search back to
glob.
Suppose the glob is e.g. *foo*. We end up with
func_g.type = MATCH_MIDDLE_ONLY;
func_g.len = 3;
func_g.search = "*foo";
Feeding that to ftrace_match_record() will not do anything sane - we
will be looking for names containing "*foo" (->len is ignored for that
one).
Link: http://lkml.kernel.org/r/20180127031706.GE13338@ZenIV.linux.org.uk
Fixes: 3ba009297149f ("ftrace: Introduce ftrace_glob structure")
Reviewed-by: Dmitry Safonov <0x7f454c46(a)gmail.com>
Reviewed-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/trace/ftrace.c | 1 -
1 file changed, 1 deletion(-)
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -4456,7 +4456,6 @@ unregister_ftrace_function_probe_func(ch
func_g.type = filter_parse_regex(glob, strlen(glob),
&func_g.search, ¬);
func_g.len = strlen(func_g.search);
- func_g.search = glob;
/* we do not support '!' for function probes */
if (WARN_ON(not))
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-4.15/sched-rt-use-container_of-to-get-root-domain-in-rto_push_irq_work_func.patch
queue-4.15/ftrace-remove-incorrect-setting-of-glob-search-field.patch
queue-4.15/sched-rt-up-the-root-domain-ref-count-when-passing-it-around-via-ipis.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Avoid PPS HW/SW state mismatch due to rounding
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5643205c6340b565a3be0fe0e7305dc4aa551c74 Mon Sep 17 00:00:00 2001
From: Imre Deak <imre.deak(a)intel.com>
Date: Wed, 29 Nov 2017 19:51:37 +0200
Subject: drm/i915: Avoid PPS HW/SW state mismatch due to rounding
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Imre Deak <imre.deak(a)intel.com>
commit 5643205c6340b565a3be0fe0e7305dc4aa551c74 upstream.
We store a SW state of the t11_t12 timing in 100usec units but have to
program it in 100msec as required by HW. The rounding used during
programming means there will be a mismatch between the SW and HW states
of this value triggering a "PPS state mismatch" error. Avoid this by
storing the already rounded-up value in the SW state.
Note that we still calculate panel_power_cycle_delay with the finer
100usec granularity to avoid any needless waits using that version of
the delay.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103903
Cc: joks <joks(a)linux.pl>
Signed-off-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129175137.2889-1-imre.de…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5336,6 +5336,12 @@ intel_dp_init_panel_power_sequencer(stru
*/
final->t8 = 1;
final->t9 = 1;
+
+ /*
+ * HW has only a 100msec granularity for t11_t12 so round it up
+ * accordingly.
+ */
+ final->t11_t12 = roundup(final->t11_t12, 100 * 10);
}
static void
Patches currently in stable-queue which might be from imre.deak(a)intel.com are
queue-4.15/drm-i915-avoid-pps-hw-sw-state-mismatch-due-to-rounding.patch
This is a note to let you know that I've just added the patch titled
devpts: fix error handling in devpts_mntget()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
devpts-fix-error-handling-in-devpts_mntget.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c9cc8d01fb04117928830449388512a5047569c9 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 31 Jan 2018 00:49:18 -0800
Subject: devpts: fix error handling in devpts_mntget()
From: Eric Biggers <ebiggers(a)google.com>
commit c9cc8d01fb04117928830449388512a5047569c9 upstream.
If devpts_ptmx_path() returns an error code, then devpts_mntget()
dereferences an ERR_PTR():
BUG: unable to handle kernel paging request at fffffffffffffff5
IP: devpts_mntget+0x13f/0x280 fs/devpts/inode.c:173
Fix it by returning early in the error paths.
Reproducer:
#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <sys/ioctl.h>
#define TIOCGPTPEER _IO('T', 0x41)
int main()
{
for (;;) {
int fd = open("/dev/ptmx", 0);
unshare(CLONE_NEWNS);
ioctl(fd, TIOCGPTPEER, 0);
}
}
Fixes: 311fc65c9fb9 ("pty: Repair TIOCGPTPEER")
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/devpts/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -168,11 +168,11 @@ struct vfsmount *devpts_mntget(struct fi
dput(path.dentry);
if (err) {
mntput(path.mnt);
- path.mnt = ERR_PTR(err);
+ return ERR_PTR(err);
}
if (DEVPTS_SB(path.mnt->mnt_sb) != fsi) {
mntput(path.mnt);
- path.mnt = ERR_PTR(-ENODEV);
+ return ERR_PTR(-ENODEV);
}
return path.mnt;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.15/kernel-relay.c-revert-kernel-relay.c-fix-potential-memory-leak.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.15/crypto-poly1305-remove-setkey-method.patch
queue-4.15/crypto-sha512-mb-initialize-pending-lengths-correctly.patch
queue-4.15/devpts-fix-error-handling-in-devpts_mntget.patch
queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: marvell: add Ethernet aliases
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
arm64-dts-marvell-add-ethernet-aliases.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 474c5885582c4a79c21bcf01ed98f98c935f1f4a Mon Sep 17 00:00:00 2001
From: Yan Markman <ymarkman(a)marvell.com>
Date: Wed, 3 Jan 2018 16:18:52 +0100
Subject: arm64: dts: marvell: add Ethernet aliases
From: Yan Markman <ymarkman(a)marvell.com>
commit 474c5885582c4a79c21bcf01ed98f98c935f1f4a upstream.
This patch adds Ethernet aliases in the Marvell Armada 7040 DB, 8040 DB
and 8040 mcbin device trees so that the bootloader setup the MAC
addresses correctly.
Signed-off-by: Yan Markman <ymarkman(a)marvell.com>
[Antoine: commit message, small fixes]
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 6 ++++++
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 7 +++++++
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 6 ++++++
3 files changed, 19 insertions(+)
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -61,6 +61,12 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth1;
+ ethernet2 = &cpm_eth2;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "usb3h0-vbus";
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -61,6 +61,13 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cpm_eth2;
+ ethernet2 = &cps_eth0;
+ ethernet3 = &cps_eth1;
+ };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "cpm-usb3h0-vbus";
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -62,6 +62,12 @@
reg = <0x0 0x0 0x0 0x80000000>;
};
+ aliases {
+ ethernet0 = &cpm_eth0;
+ ethernet1 = &cps_eth0;
+ ethernet2 = &cps_eth1;
+ };
+
/* Regulator labels correspond with schematics */
v_3_3: regulator-3-3v {
compatible = "regulator-fixed";
Patches currently in stable-queue which might be from ymarkman(a)marvell.com are
queue-4.15/arm64-dts-marvell-add-ethernet-aliases.patch
This is a note to let you know that I've just added the patch titled
acpi, nfit: fix register dimm error handling
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
acpi-nfit-fix-register-dimm-error-handling.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 23fbd7c70aec7600e3227eb24259fc55bf6e4881 Mon Sep 17 00:00:00 2001
From: Toshi Kani <toshi.kani(a)hpe.com>
Date: Fri, 2 Feb 2018 14:00:36 -0700
Subject: acpi, nfit: fix register dimm error handling
From: Toshi Kani <toshi.kani(a)hpe.com>
commit 23fbd7c70aec7600e3227eb24259fc55bf6e4881 upstream.
A NULL pointer reference kernel bug was observed when
acpi_nfit_add_dimm() called in acpi_nfit_register_dimms() failed. This
error path does not set nfit_mem->nvdimm, but the 2nd
list_for_each_entry() loop in the function assumes it's always set. Add
a check to nfit_mem->nvdimm.
Fixes: ba9c8dd3c222 ("acpi, nfit: add dimm device notification support")
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/acpi/nfit/core.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -1867,6 +1867,9 @@ static int acpi_nfit_register_dimms(stru
struct kernfs_node *nfit_kernfs;
nvdimm = nfit_mem->nvdimm;
+ if (!nvdimm)
+ continue;
+
nfit_kernfs = sysfs_get_dirent(nvdimm_kobj(nvdimm)->sd, "nfit");
if (nfit_kernfs)
nfit_mem->flags_attr = sysfs_get_dirent(nfit_kernfs,
Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are
queue-4.15/acpi-nfit-fix-register-dimm-error-handling.patch
This is a note to let you know that I've just added the patch titled
scsi: lpfc: Fix crash after bad bar setup on driver attachment
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-lpfc-fix-crash-after-bad-bar-setup-on-driver-attachment.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e4b9794efdce13242f4af6682f3ed48ce3864a87 Mon Sep 17 00:00:00 2001
From: James Smart <jsmart2021(a)gmail.com>
Date: Mon, 20 Nov 2017 16:00:31 -0800
Subject: scsi: lpfc: Fix crash after bad bar setup on driver attachment
From: James Smart <jsmart2021(a)gmail.com>
commit e4b9794efdce13242f4af6682f3ed48ce3864a87 upstream.
In test cases where an instance of the driver is detached and
reattached, the driver will crash on reattachment. There is a compound
if statement that will skip over the bar setup if the pci_resource_start
call is not successful. The driver erroneously returns success to its
bar setup in this scenario even though the bars aren't properly
configured.
Rework the offending code segment for proper initialization steps. If
the pci_resource_start call fails, -ENOMEM is now returned.
Sample stack:
rport-5:0-10: blocked FC remote port time out: removing rport
BUG: unable to handle kernel NULL pointer dereference at (null)
... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
...
... RIP: 0010:... ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc]
Call Trace:
... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc]
... ? __alloc_pages_nodemask+0x176/0x420
... ? __kmalloc+0x2e/0x230
... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc]
... ? mempool_alloc+0x69/0x170
... ? dma_generic_alloc_coherent+0x8f/0x140
... lpfc_sli_issue_mbox+0xf/0x20 [lpfc]
... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc]
... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc]
... lpfc_pci_probe_one+0x445/0x16f0 [lpfc]
... local_pci_probe+0x45/0xa0
... work_for_cpu_fn+0x14/0x20
... process_one_work+0x17a/0x440
Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com>
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/lpfc/lpfc_init.c | 84 +++++++++++++++++++++++++-----------------
1 file changed, 51 insertions(+), 33 deletions(-)
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -9413,44 +9413,62 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba
lpfc_sli4_bar0_register_memmap(phba, if_type);
}
- if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) &&
- (pci_resource_start(pdev, PCI_64BIT_BAR2))) {
- /*
- * Map SLI4 if type 0 HBA Control Register base to a kernel
- * virtual address and setup the registers.
- */
- phba->pci_bar1_map = pci_resource_start(pdev, PCI_64BIT_BAR2);
- bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2);
- phba->sli4_hba.ctrl_regs_memmap_p =
- ioremap(phba->pci_bar1_map, bar1map_len);
- if (!phba->sli4_hba.ctrl_regs_memmap_p) {
- dev_printk(KERN_ERR, &pdev->dev,
- "ioremap failed for SLI4 HBA control registers.\n");
+ if (if_type == LPFC_SLI_INTF_IF_TYPE_0) {
+ if (pci_resource_start(pdev, PCI_64BIT_BAR2)) {
+ /*
+ * Map SLI4 if type 0 HBA Control Register base to a
+ * kernel virtual address and setup the registers.
+ */
+ phba->pci_bar1_map = pci_resource_start(pdev,
+ PCI_64BIT_BAR2);
+ bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2);
+ phba->sli4_hba.ctrl_regs_memmap_p =
+ ioremap(phba->pci_bar1_map,
+ bar1map_len);
+ if (!phba->sli4_hba.ctrl_regs_memmap_p) {
+ dev_err(&pdev->dev,
+ "ioremap failed for SLI4 HBA "
+ "control registers.\n");
+ error = -ENOMEM;
+ goto out_iounmap_conf;
+ }
+ phba->pci_bar2_memmap_p =
+ phba->sli4_hba.ctrl_regs_memmap_p;
+ lpfc_sli4_bar1_register_memmap(phba);
+ } else {
+ error = -ENOMEM;
goto out_iounmap_conf;
}
- phba->pci_bar2_memmap_p = phba->sli4_hba.ctrl_regs_memmap_p;
- lpfc_sli4_bar1_register_memmap(phba);
}
- if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) &&
- (pci_resource_start(pdev, PCI_64BIT_BAR4))) {
- /*
- * Map SLI4 if type 0 HBA Doorbell Register base to a kernel
- * virtual address and setup the registers.
- */
- phba->pci_bar2_map = pci_resource_start(pdev, PCI_64BIT_BAR4);
- bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4);
- phba->sli4_hba.drbl_regs_memmap_p =
- ioremap(phba->pci_bar2_map, bar2map_len);
- if (!phba->sli4_hba.drbl_regs_memmap_p) {
- dev_printk(KERN_ERR, &pdev->dev,
- "ioremap failed for SLI4 HBA doorbell registers.\n");
- goto out_iounmap_ctrl;
- }
- phba->pci_bar4_memmap_p = phba->sli4_hba.drbl_regs_memmap_p;
- error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0);
- if (error)
+ if (if_type == LPFC_SLI_INTF_IF_TYPE_0) {
+ if (pci_resource_start(pdev, PCI_64BIT_BAR4)) {
+ /*
+ * Map SLI4 if type 0 HBA Doorbell Register base to
+ * a kernel virtual address and setup the registers.
+ */
+ phba->pci_bar2_map = pci_resource_start(pdev,
+ PCI_64BIT_BAR4);
+ bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4);
+ phba->sli4_hba.drbl_regs_memmap_p =
+ ioremap(phba->pci_bar2_map,
+ bar2map_len);
+ if (!phba->sli4_hba.drbl_regs_memmap_p) {
+ dev_err(&pdev->dev,
+ "ioremap failed for SLI4 HBA"
+ " doorbell registers.\n");
+ error = -ENOMEM;
+ goto out_iounmap_ctrl;
+ }
+ phba->pci_bar4_memmap_p =
+ phba->sli4_hba.drbl_regs_memmap_p;
+ error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0);
+ if (error)
+ goto out_iounmap_all;
+ } else {
+ error = -ENOMEM;
goto out_iounmap_all;
+ }
}
return 0;
Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are
queue-4.14/scsi-lpfc-fix-crash-after-bad-bar-setup-on-driver-attachment.patch