This is a note to let you know that I've just added the patch titled
MIPS: Fix MIPS64 FP save/restore on 32-bit kernels
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:
mips-fix-mips64-fp-save-restore-on-32-bit-kernels.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 22b8ba765a726d90e9830ff6134c32b04f12c10f Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Mon, 3 Jul 2017 23:41:47 +0100
Subject: MIPS: Fix MIPS64 FP save/restore on 32-bit kernels
From: James Hogan <jhogan(a)kernel.org>
commit 22b8ba765a726d90e9830ff6134c32b04f12c10f upstream.
32-bit kernels can be configured to support MIPS64, in which case
neither CONFIG_64BIT or CONFIG_CPU_MIPS32_R* will be set. This causes
the CP0_Status.FR checks at the point of floating point register save
and restore to be compiled out, which results in odd FP registers not
being saved or restored to the task or signal context even when
CP0_Status.FR is set.
Fix the ifdefs to use CONFIG_CPU_MIPSR2 and CONFIG_CPU_MIPSR6, which are
enabled for the relevant revisions of either MIPS32 or MIPS64, along
with some other CPUs such as Octeon (r2), Loongson1 (r2), XLP (r2),
Loongson 3A R2.
The suspect code originates from commit 597ce1723e0f ("MIPS: Support for
64-bit FP with O32 binaries") in v3.14, however the code in
__enable_fpu() was consistent and refused to set FR=1, falling back to
software FPU emulation. This was suboptimal but should be functionally
correct.
Commit fcc53b5f6c38 ("MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6
CPU") in v4.2 (and stable tagged back to 4.0) later introduced the bug
by updating __enable_fpu() to set FR=1 but failing to update the other
similar ifdefs to enable FR=1 state handling.
Fixes: fcc53b5f6c38 ("MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPU")
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Paul Burton <paul.burton(a)imgtec.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16739/
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/include/asm/asmmacro.h | 8 ++++----
arch/mips/kernel/r4k_fpu.S | 20 ++++++++++----------
2 files changed, 14 insertions(+), 14 deletions(-)
--- a/arch/mips/include/asm/asmmacro.h
+++ b/arch/mips/include/asm/asmmacro.h
@@ -130,8 +130,8 @@
.endm
.macro fpu_save_double thread status tmp
-#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPS32_R2) || \
- defined(CONFIG_CPU_MIPS32_R6)
+#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
+ defined(CONFIG_CPU_MIPSR6)
sll \tmp, \status, 5
bgez \tmp, 10f
fpu_save_16odd \thread
@@ -189,8 +189,8 @@
.endm
.macro fpu_restore_double thread status tmp
-#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPS32_R2) || \
- defined(CONFIG_CPU_MIPS32_R6)
+#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
+ defined(CONFIG_CPU_MIPSR6)
sll \tmp, \status, 5
bgez \tmp, 10f # 16 register mode?
--- a/arch/mips/kernel/r4k_fpu.S
+++ b/arch/mips/kernel/r4k_fpu.S
@@ -40,8 +40,8 @@
*/
LEAF(_save_fp)
EXPORT_SYMBOL(_save_fp)
-#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPS32_R2) || \
- defined(CONFIG_CPU_MIPS32_R6)
+#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
+ defined(CONFIG_CPU_MIPSR6)
mfc0 t0, CP0_STATUS
#endif
fpu_save_double a0 t0 t1 # clobbers t1
@@ -52,8 +52,8 @@ EXPORT_SYMBOL(_save_fp)
* Restore a thread's fp context.
*/
LEAF(_restore_fp)
-#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPS32_R2) || \
- defined(CONFIG_CPU_MIPS32_R6)
+#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
+ defined(CONFIG_CPU_MIPSR6)
mfc0 t0, CP0_STATUS
#endif
fpu_restore_double a0 t0 t1 # clobbers t1
@@ -246,11 +246,11 @@ LEAF(_save_fp_context)
cfc1 t1, fcr31
.set pop
-#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPS32_R2) || \
- defined(CONFIG_CPU_MIPS32_R6)
+#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
+ defined(CONFIG_CPU_MIPSR6)
.set push
SET_HARDFLOAT
-#ifdef CONFIG_CPU_MIPS32_R2
+#ifdef CONFIG_CPU_MIPSR2
.set mips32r2
.set fp=64
mfc0 t0, CP0_STATUS
@@ -314,11 +314,11 @@ LEAF(_save_fp_context)
LEAF(_restore_fp_context)
EX lw t1, 0(a1)
-#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPS32_R2) || \
- defined(CONFIG_CPU_MIPS32_R6)
+#if defined(CONFIG_64BIT) || defined(CONFIG_CPU_MIPSR2) || \
+ defined(CONFIG_CPU_MIPSR6)
.set push
SET_HARDFLOAT
-#ifdef CONFIG_CPU_MIPS32_R2
+#ifdef CONFIG_CPU_MIPSR2
.set mips32r2
.set fp=64
mfc0 t0, CP0_STATUS
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.14/mips-fix-an-n32-core-file-generation-regset-support-regression.patch
queue-4.14/mips-cmpxchg64-and-have_virt_cpu_accounting_gen-don-t-work-for-32-bit-smp.patch
queue-4.14/mips-bcm47xx-fix-led-inversion-for-wrt54gsv1.patch
queue-4.14/mips-ralink-fix-mt7628-pinmux.patch
queue-4.14/mips-fix-odd-fp-register-warnings-with-mips64r2.patch
queue-4.14/mips-pci-remove-kern_warn-instance-inside-the-mt7620-driver.patch
queue-4.14/mips-ralink-fix-typo-in-mt7628-pinmux-function.patch
queue-4.14/mips-dts-remove-bogus-bcm96358nb4ser.dtb-from-dtb-y-entry.patch
queue-4.14/mips-fix-mips64-fp-save-restore-on-32-bit-kernels.patch
queue-4.14/mips-math-emu-fix-final-emulation-phase-for-certain-instructions.patch
This is a note to let you know that I've just added the patch titled
MIPS: Fix an n32 core file generation regset support regression
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:
mips-fix-an-n32-core-file-generation-regset-support-regression.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 547da673173de51f73887377eb275304775064ad Mon Sep 17 00:00:00 2001
From: "Maciej W. Rozycki" <macro(a)mips.com>
Date: Tue, 7 Nov 2017 19:09:20 +0000
Subject: MIPS: Fix an n32 core file generation regset support regression
From: Maciej W. Rozycki <macro(a)mips.com>
commit 547da673173de51f73887377eb275304775064ad upstream.
Fix a commit 7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
regression, then activated by commit 6a9c001b7ec3 ("MIPS: Switch ELF
core dumper to use regsets.)", that caused n32 processes to dump o32
core files by failing to set the EF_MIPS_ABI2 flag in the ELF core file
header's `e_flags' member:
$ file tls-core
tls-core: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), [...]
$ ./tls-core
Aborted (core dumped)
$ file core
core: ELF 32-bit MSB core file MIPS, MIPS-I version 1 (SYSV), SVR4-style
$
Previously the flag was set as the result of a:
statement placed in arch/mips/kernel/binfmt_elfn32.c, however in the
regset case, i.e. when CORE_DUMP_USE_REGSET is set, ELF_CORE_EFLAGS is
no longer used by `fill_note_info' in fs/binfmt_elf.c, and instead the
`->e_flags' member of the regset view chosen is. We have the views
defined in arch/mips/kernel/ptrace.c, however only an o32 and an n64
one, and the latter is used for n32 as well. Consequently an o32 core
file is incorrectly dumped from n32 processes (the ELF32 vs ELF64 class
is chosen elsewhere, and the 32-bit one is correctly selected for n32).
Correct the issue then by defining an n32 regset view and using it as
appropriate. Issue discovered in GDB testing.
Fixes: 7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Djordje Todorovic <djordje.todorovic(a)rt-rk.com>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17617/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/kernel/ptrace.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -618,6 +618,19 @@ static const struct user_regset_view use
.n = ARRAY_SIZE(mips64_regsets),
};
+#ifdef CONFIG_MIPS32_N32
+
+static const struct user_regset_view user_mipsn32_view = {
+ .name = "mipsn32",
+ .e_flags = EF_MIPS_ABI2,
+ .e_machine = ELF_ARCH,
+ .ei_osabi = ELF_OSABI,
+ .regsets = mips64_regsets,
+ .n = ARRAY_SIZE(mips64_regsets),
+};
+
+#endif /* CONFIG_MIPS32_N32 */
+
#endif /* CONFIG_64BIT */
const struct user_regset_view *task_user_regset_view(struct task_struct *task)
@@ -629,6 +642,10 @@ const struct user_regset_view *task_user
if (test_tsk_thread_flag(task, TIF_32BIT_REGS))
return &user_mips_view;
#endif
+#ifdef CONFIG_MIPS32_N32
+ if (test_tsk_thread_flag(task, TIF_32BIT_ADDR))
+ return &user_mipsn32_view;
+#endif
return &user_mips64_view;
#endif
}
Patches currently in stable-queue which might be from macro(a)mips.com are
queue-4.14/mips-fix-an-n32-core-file-generation-regset-support-regression.patch
This is a note to let you know that I've just added the patch titled
MIPS: dts: remove bogus bcm96358nb4ser.dtb from dtb-y entry
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:
mips-dts-remove-bogus-bcm96358nb4ser.dtb-from-dtb-y-entry.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 3cad14d56adbf7d621fc5a35db42f3acc0a2d6e8 Mon Sep 17 00:00:00 2001
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Date: Sun, 5 Nov 2017 14:30:52 +0900
Subject: MIPS: dts: remove bogus bcm96358nb4ser.dtb from dtb-y entry
From: Masahiro Yamada <yamada.masahiro(a)socionext.com>
commit 3cad14d56adbf7d621fc5a35db42f3acc0a2d6e8 upstream.
arch/mips/boot/dts/brcm/bcm96358nb4ser.dts does not exist, so
we cannot build bcm96358nb4ser.dtb .
Signed-off-by: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Fixes: 695835511f96 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom")
Acked-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/boot/dts/brcm/Makefile | 1 -
1 file changed, 1 deletion(-)
--- a/arch/mips/boot/dts/brcm/Makefile
+++ b/arch/mips/boot/dts/brcm/Makefile
@@ -23,7 +23,6 @@ dtb-$(CONFIG_DT_NONE) += \
bcm63268-comtrend-vr-3032u.dtb \
bcm93384wvg.dtb \
bcm93384wvg_viper.dtb \
- bcm96358nb4ser.dtb \
bcm96368mvwg.dtb \
bcm9ejtagprb.dtb \
bcm97125cbmb.dtb \
Patches currently in stable-queue which might be from yamada.masahiro(a)socionext.com are
queue-4.14/mips-dts-remove-bogus-bcm96358nb4ser.dtb-from-dtb-y-entry.patch
This is a note to let you know that I've just added the patch titled
MIPS: BCM47XX: Fix LED inversion for WRT54GSv1
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:
mips-bcm47xx-fix-led-inversion-for-wrt54gsv1.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 56a46acf62af5ba44fca2f3f1c7c25a2d5385b19 Mon Sep 17 00:00:00 2001
From: Mirko Parthey <mirko.parthey(a)web.de>
Date: Thu, 18 May 2017 21:30:03 +0200
Subject: MIPS: BCM47XX: Fix LED inversion for WRT54GSv1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Mirko Parthey <mirko.parthey(a)web.de>
commit 56a46acf62af5ba44fca2f3f1c7c25a2d5385b19 upstream.
The WLAN LED on the Linksys WRT54GSv1 is active low, but the software
treats it as active high. Fix the inverted logic.
Fixes: 7bb26b169116 ("MIPS: BCM47xx: Fix LEDs on WRT54GS V1.0")
Signed-off-by: Mirko Parthey <mirko.parthey(a)web.de>
Looks-ok-by: Rafał Miłecki <zajec5(a)gmail.com>
Cc: Hauke Mehrtens <hauke(a)hauke-m.de>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16071/
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/bcm47xx/leds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/bcm47xx/leds.c
+++ b/arch/mips/bcm47xx/leds.c
@@ -331,7 +331,7 @@ bcm47xx_leds_linksys_wrt54g3gv2[] __init
/* Verified on: WRT54GS V1.0 */
static const struct gpio_led
bcm47xx_leds_linksys_wrt54g_type_0101[] __initconst = {
- BCM47XX_GPIO_LED(0, "green", "wlan", 0, LEDS_GPIO_DEFSTATE_OFF),
+ BCM47XX_GPIO_LED(0, "green", "wlan", 1, LEDS_GPIO_DEFSTATE_OFF),
BCM47XX_GPIO_LED(1, "green", "power", 0, LEDS_GPIO_DEFSTATE_ON),
BCM47XX_GPIO_LED(7, "green", "dmz", 1, LEDS_GPIO_DEFSTATE_OFF),
};
Patches currently in stable-queue which might be from mirko.parthey(a)web.de are
queue-4.14/mips-bcm47xx-fix-led-inversion-for-wrt54gsv1.patch
This is a note to let you know that I've just added the patch titled
mfd: lpc_ich: Avoton/Rangeley uses SPI_BYT method
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:
mfd-lpc_ich-avoton-rangeley-uses-spi_byt-method.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 07d70913dce59f3c8e5d0ca76250861158a9ca6c Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <joakim.tjernlund(a)infinera.com>
Date: Wed, 11 Oct 2017 12:40:55 +0200
Subject: mfd: lpc_ich: Avoton/Rangeley uses SPI_BYT method
From: Joakim Tjernlund <joakim.tjernlund(a)infinera.com>
commit 07d70913dce59f3c8e5d0ca76250861158a9ca6c upstream.
Avoton/Rangeley are based on Silvermount micro-architecture, like
Bay Trail, and uses the INTEL_SPI_BYT method to drive SPI.
Signed-off-by: Joakim Tjernlund <joakim.tjernlund(a)infinera.com>
Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mfd/lpc_ich.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/mfd/lpc_ich.c
+++ b/drivers/mfd/lpc_ich.c
@@ -522,6 +522,7 @@ static struct lpc_ich_info lpc_chipset_i
.name = "Avoton SoC",
.iTCO_version = 3,
.gpio_version = AVOTON_GPIO,
+ .spi_type = INTEL_SPI_BYT,
},
[LPC_BAYTRAIL] = {
.name = "Bay Trail SoC",
Patches currently in stable-queue which might be from joakim.tjernlund(a)infinera.com are
queue-4.14/mfd-lpc_ich-avoton-rangeley-uses-spi_byt-method.patch
This is a note to let you know that I've just added the patch titled
md: fix deadlock error in recent patch.
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:
md-fix-deadlock-error-in-recent-patch.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 d47c8ad261f787af22a220ffcc2d07afba809223 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb(a)suse.com>
Date: Thu, 5 Oct 2017 16:23:16 +1100
Subject: md: fix deadlock error in recent patch.
From: NeilBrown <neilb(a)suse.com>
commit d47c8ad261f787af22a220ffcc2d07afba809223 upstream.
A recent patch aimed to cause md_write_start() to fail (rather than
block) when the mddev was suspending, so as to avoid deadlocks.
Unfortunately the test in wait_event() was wrong, and it didn't change
behaviour at all.
We wait_event() must wait until the metadata is written OR the array is
suspending.
Fixes: cc27b0c78c79 ("md: fix deadlock between mddev_suspend() and md_write_start()")
Reported-by: Xiao Ni <xni(a)redhat.com>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/md.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8039,7 +8039,8 @@ bool md_write_start(struct mddev *mddev,
if (did_change)
sysfs_notify_dirent_safe(mddev->sysfs_state);
wait_event(mddev->sb_wait,
- !test_bit(MD_SB_CHANGE_PENDING, &mddev->sb_flags) && !mddev->suspended);
+ !test_bit(MD_SB_CHANGE_PENDING, &mddev->sb_flags) ||
+ mddev->suspended);
if (test_bit(MD_SB_CHANGE_PENDING, &mddev->sb_flags)) {
percpu_ref_put(&mddev->writes_pending);
return false;
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-4.14/md-fix-deadlock-error-in-recent-patch.patch
queue-4.14/autofs-don-t-fail-mount-for-transient-error.patch
queue-4.14/md-bitmap-revert-a-patch.patch
queue-4.14/nfs-revalidate-.-etc-correctly-on-open.patch
This is a note to let you know that I've just added the patch titled
md: don't check MD_SB_CHANGE_CLEAN in md_allow_write
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:
md-don-t-check-md_sb_change_clean-in-md_allow_write.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 b90f6ff080c52e2f05364210733df120e3c4e597 Mon Sep 17 00:00:00 2001
From: Artur Paszkiewicz <artur.paszkiewicz(a)intel.com>
Date: Thu, 26 Oct 2017 15:56:54 +0200
Subject: md: don't check MD_SB_CHANGE_CLEAN in md_allow_write
From: Artur Paszkiewicz <artur.paszkiewicz(a)intel.com>
commit b90f6ff080c52e2f05364210733df120e3c4e597 upstream.
Only MD_SB_CHANGE_PENDING should be used to wait for transition from
clean to dirty. Checking also MD_SB_CHANGE_CLEAN is unnecessary and can
race with e.g. md_do_sync(). This sporadically causes a hang when
changing consistency policy during resync:
INFO: task mdadm:6183 blocked for more than 30 seconds.
Not tainted 4.14.0-rc3+ #391
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
mdadm D12752 6183 6022 0x00000000
Call Trace:
__schedule+0x93f/0x990
schedule+0x6b/0x90
md_allow_write+0x100/0x130 [md_mod]
? do_wait_intr_irq+0x90/0x90
resize_stripes+0x3a/0x5b0 [raid456]
? kernfs_fop_write+0xbe/0x180
raid5_change_consistency_policy+0xa6/0x200 [raid456]
consistency_policy_store+0x2e/0x70 [md_mod]
md_attr_store+0x90/0xc0 [md_mod]
sysfs_kf_write+0x42/0x50
kernfs_fop_write+0x119/0x180
__vfs_write+0x28/0x110
? rcu_sync_lockdep_assert+0x12/0x60
? __sb_start_write+0x15a/0x1c0
? vfs_write+0xa3/0x1a0
vfs_write+0xb4/0x1a0
SyS_write+0x49/0xa0
entry_SYSCALL_64_fastpath+0x18/0xad
Fixes: 2214c260c72b ("md: don't return -EAGAIN in md_allow_write for external metadata arrays")
Signed-off-by: Artur Paszkiewicz <artur.paszkiewicz(a)intel.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/md.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8111,7 +8111,6 @@ void md_allow_write(struct mddev *mddev)
sysfs_notify_dirent_safe(mddev->sysfs_state);
/* wait for the dirty state to be recorded in the metadata */
wait_event(mddev->sb_wait,
- !test_bit(MD_SB_CHANGE_CLEAN, &mddev->sb_flags) &&
!test_bit(MD_SB_CHANGE_PENDING, &mddev->sb_flags));
} else
spin_unlock(&mddev->lock);
Patches currently in stable-queue which might be from artur.paszkiewicz(a)intel.com are
queue-4.14/md-don-t-check-md_sb_change_clean-in-md_allow_write.patch
This is a note to let you know that I've just added the patch titled
md/bitmap: revert a patch
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:
md-bitmap-revert-a-patch.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 938b533d479e7428b7fa1b8179283646d2e2c53d Mon Sep 17 00:00:00 2001
From: Shaohua Li <shli(a)fb.com>
Date: Mon, 16 Oct 2017 19:03:44 -0700
Subject: md/bitmap: revert a patch
From: Shaohua Li <shli(a)fb.com>
commit 938b533d479e7428b7fa1b8179283646d2e2c53d upstream.
This reverts commit 8031c3ddc70a. That patches doesn't work well if PAGE_SIZE >
4k. We will fix the original problem with a different approach.
Fix: 8031c3ddc70a(md/bitmap: copy correct data for bitmap super)
Reported-by: Joshua Kinard <kumba(a)gentoo.org>
Suggested-by: Neil Brown <neilb(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/bitmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/bitmap.c
+++ b/drivers/md/bitmap.c
@@ -625,7 +625,7 @@ re_read:
err = read_sb_page(bitmap->mddev,
offset,
sb_page,
- 0, PAGE_SIZE);
+ 0, sizeof(bitmap_super_t));
}
if (err)
return err;
@@ -2123,7 +2123,7 @@ int bitmap_resize(struct bitmap *bitmap,
if (store.sb_page && bitmap->storage.sb_page)
memcpy(page_address(store.sb_page),
page_address(bitmap->storage.sb_page),
- PAGE_SIZE);
+ sizeof(bitmap_super_t));
bitmap_file_unmap(&bitmap->storage);
bitmap->storage = store;
Patches currently in stable-queue which might be from shli(a)fb.com are
queue-4.14/md-fix-deadlock-error-in-recent-patch.patch
queue-4.14/raid1-prevent-freeze_array-wait_all_barriers-deadlock.patch
queue-4.14/md-bitmap-revert-a-patch.patch
queue-4.14/md-don-t-check-md_sb_change_clean-in-md_allow_write.patch
This is a note to let you know that I've just added the patch titled
mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush sequence
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:
mailbox-bcm-flexrm-mailbox-fix-flexrm-ring-flush-sequence.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 a371c10ea4b38a5f120e86d906d404d50a0f4660 Mon Sep 17 00:00:00 2001
From: Anup Patel <anup.patel(a)broadcom.com>
Date: Tue, 3 Oct 2017 10:51:48 +0530
Subject: mailbox: bcm-flexrm-mailbox: Fix FlexRM ring flush sequence
From: Anup Patel <anup.patel(a)broadcom.com>
commit a371c10ea4b38a5f120e86d906d404d50a0f4660 upstream.
As-per suggestion from FlexRM HW folks, we have to first set
FlexRM ring flush state and then clear it for FlexRM ring flush
to work properly.
Currently, the FlexRM driver has incomplete FlexRM ring flush
sequence which causes repeated insmod+rmmod of mailbox client
drivers to fail.
This patch fixes FlexRM ring flush sequence in flexrm_shutdown()
as described above.
Fixes: dbc049eee730 ("mailbox: Add driver for Broadcom FlexRM
ring manager")
Signed-off-by: Anup Patel <anup.patel(a)broadcom.com>
Reviewed-by: Scott Branden <scott.branden(a)broadcom.com>
Signed-off-by: Jassi Brar <jaswinder.singh(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mailbox/bcm-flexrm-mailbox.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
--- a/drivers/mailbox/bcm-flexrm-mailbox.c
+++ b/drivers/mailbox/bcm-flexrm-mailbox.c
@@ -1365,8 +1365,8 @@ static void flexrm_shutdown(struct mbox_
/* Disable/inactivate ring */
writel_relaxed(0x0, ring->regs + RING_CONTROL);
- /* Flush ring with timeout of 1s */
- timeout = 1000;
+ /* Set ring flush state */
+ timeout = 1000; /* timeout of 1s */
writel_relaxed(BIT(CONTROL_FLUSH_SHIFT),
ring->regs + RING_CONTROL);
do {
@@ -1374,7 +1374,23 @@ static void flexrm_shutdown(struct mbox_
FLUSH_DONE_MASK)
break;
mdelay(1);
- } while (timeout--);
+ } while (--timeout);
+ if (!timeout)
+ dev_err(ring->mbox->dev,
+ "setting ring%d flush state timedout\n", ring->num);
+
+ /* Clear ring flush state */
+ timeout = 1000; /* timeout of 1s */
+ writel_relaxed(0x0, ring + RING_CONTROL);
+ do {
+ if (!(readl_relaxed(ring + RING_FLUSH_DONE) &
+ FLUSH_DONE_MASK))
+ break;
+ mdelay(1);
+ } while (--timeout);
+ if (!timeout)
+ dev_err(ring->mbox->dev,
+ "clearing ring%d flush state timedout\n", ring->num);
/* Abort all in-flight requests */
for (reqid = 0; reqid < RING_MAX_REQ_COUNT; reqid++) {
Patches currently in stable-queue which might be from anup.patel(a)broadcom.com are
queue-4.14/mailbox-bcm-flexrm-mailbox-fix-flexrm-ring-flush-sequence.patch
This is a note to let you know that I've just added the patch titled
lockd: double unregister of inetaddr notifiers
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:
lockd-double-unregister-of-inetaddr-notifiers.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 dc3033e16c59a2c4e62b31341258a5786cbcee56 Mon Sep 17 00:00:00 2001
From: Vasily Averin <vvs(a)virtuozzo.com>
Date: Fri, 20 Oct 2017 17:33:18 +0300
Subject: lockd: double unregister of inetaddr notifiers
From: Vasily Averin <vvs(a)virtuozzo.com>
commit dc3033e16c59a2c4e62b31341258a5786cbcee56 upstream.
lockd_up() can call lockd_unregister_notifiers twice:
inside lockd_start_svc() when it calls lockd_svc_exit_thread()
and then in error path of lockd_up()
Patch forces lockd_start_svc() to unregister notifiers in all error cases
and removes extra unregister in error path of lockd_up().
Fixes: cb7d224f82e4 "lockd: unregister notifier blocks if the service ..."
Signed-off-by: Vasily Averin <vvs(a)virtuozzo.com>
Reviewed-by: Jeff Layton <jlayton(a)kernel.org>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/lockd/svc.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -369,6 +369,7 @@ static int lockd_start_svc(struct svc_se
printk(KERN_WARNING
"lockd_up: svc_rqst allocation failed, error=%d\n",
error);
+ lockd_unregister_notifiers();
goto out_rqst;
}
@@ -459,13 +460,16 @@ int lockd_up(struct net *net)
}
error = lockd_up_net(serv, net);
- if (error < 0)
- goto err_net;
+ if (error < 0) {
+ lockd_unregister_notifiers();
+ goto err_put;
+ }
error = lockd_start_svc(serv);
- if (error < 0)
- goto err_start;
-
+ if (error < 0) {
+ lockd_down_net(serv, net);
+ goto err_put;
+ }
nlmsvc_users++;
/*
* Note: svc_serv structures have an initial use count of 1,
@@ -476,12 +480,6 @@ err_put:
err_create:
mutex_unlock(&nlmsvc_mutex);
return error;
-
-err_start:
- lockd_down_net(serv, net);
-err_net:
- lockd_unregister_notifiers();
- goto err_put;
}
EXPORT_SYMBOL_GPL(lockd_up);
Patches currently in stable-queue which might be from vvs(a)virtuozzo.com are
queue-4.14/lockd-double-unregister-of-inetaddr-notifiers.patch
This is a note to let you know that I've just added the patch titled
libceph: don't WARN() if user tries to add invalid key
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:
libceph-don-t-warn-if-user-tries-to-add-invalid-key.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 b11270853fa3654f08d4a6a03b23ddb220512d8d Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Mon, 6 Nov 2017 21:57:26 -0800
Subject: libceph: don't WARN() if user tries to add invalid key
From: Eric Biggers <ebiggers(a)google.com>
commit b11270853fa3654f08d4a6a03b23ddb220512d8d upstream.
The WARN_ON(!key->len) in set_secret() in net/ceph/crypto.c is hit if a
user tries to add a key of type "ceph" with an invalid payload as
follows (assuming CONFIG_CEPH_LIB=y):
echo -e -n '\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' \
| keyctl padd ceph desc @s
This can be hit by fuzzers. As this is merely bad input and not a
kernel bug, replace the WARN_ON() with return -EINVAL.
Fixes: 7af3ea189a9a ("libceph: stop allocating a new cipher on every crypto request")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Reviewed-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ceph/crypto.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/ceph/crypto.c
+++ b/net/ceph/crypto.c
@@ -37,7 +37,9 @@ static int set_secret(struct ceph_crypto
return -ENOTSUPP;
}
- WARN_ON(!key->len);
+ if (!key->len)
+ return -EINVAL;
+
key->key = kmemdup(buf, key->len, GFP_NOIO);
if (!key->key) {
ret = -ENOMEM;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch
queue-4.14/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch
queue-4.14/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch
queue-4.14/libceph-don-t-warn-if-user-tries-to-add-invalid-key.patch
This is a note to let you know that I've just added the patch titled
iwlwifi: fix firmware names for 9000 and A000 series hw
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:
iwlwifi-fix-firmware-names-for-9000-and-a000-series-hw.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 c2c48ddfc8b03b9ecb51d2832b586497b37531bc Mon Sep 17 00:00:00 2001
From: Thomas Backlund <tmb(a)mageia.org>
Date: Tue, 14 Nov 2017 12:37:51 +0200
Subject: iwlwifi: fix firmware names for 9000 and A000 series hw
From: Thomas Backlund <tmb(a)mageia.org>
commit c2c48ddfc8b03b9ecb51d2832b586497b37531bc upstream.
iwlwifi 9000 and a0000 series hw contains an extra dash in firmware
file name as seeen in modinfo output for kernel 4.14:
firmware: iwlwifi-9260-th-b0-jf-b0--34.ucode
firmware: iwlwifi-9260-th-a0-jf-a0--34.ucode
firmware: iwlwifi-9000-pu-a0-jf-b0--34.ucode
firmware: iwlwifi-9000-pu-a0-jf-a0--34.ucode
firmware: iwlwifi-QuQnj-a0-hr-a0--34.ucode
firmware: iwlwifi-QuQnj-a0-jf-b0--34.ucode
firmware: iwlwifi-QuQnj-f0-hr-a0--34.ucode
firmware: iwlwifi-Qu-a0-jf-b0--34.ucode
firmware: iwlwifi-Qu-a0-hr-a0--34.ucode
Fix that by dropping the extra adding of '"-"'.
Signed-off-by: Thomas Backlund <tmb(a)mageia.org>
Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 6 +++---
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
@@ -79,11 +79,11 @@
#define IWL9000_MODULE_FIRMWARE(api) \
IWL9000_FW_PRE "-" __stringify(api) ".ucode"
#define IWL9000RFB_MODULE_FIRMWARE(api) \
- IWL9000RFB_FW_PRE "-" __stringify(api) ".ucode"
+ IWL9000RFB_FW_PRE __stringify(api) ".ucode"
#define IWL9260A_MODULE_FIRMWARE(api) \
- IWL9260A_FW_PRE "-" __stringify(api) ".ucode"
+ IWL9260A_FW_PRE __stringify(api) ".ucode"
#define IWL9260B_MODULE_FIRMWARE(api) \
- IWL9260B_FW_PRE "-" __stringify(api) ".ucode"
+ IWL9260B_FW_PRE __stringify(api) ".ucode"
#define NVM_HW_SECTION_NUM_FAMILY_9000 10
--- a/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
@@ -80,15 +80,15 @@
#define IWL_A000_HR_A0_FW_PRE "iwlwifi-QuQnj-a0-hr-a0-"
#define IWL_A000_HR_MODULE_FIRMWARE(api) \
- IWL_A000_HR_FW_PRE "-" __stringify(api) ".ucode"
+ IWL_A000_HR_FW_PRE __stringify(api) ".ucode"
#define IWL_A000_JF_MODULE_FIRMWARE(api) \
- IWL_A000_JF_FW_PRE "-" __stringify(api) ".ucode"
+ IWL_A000_JF_FW_PRE __stringify(api) ".ucode"
#define IWL_A000_HR_F0_QNJ_MODULE_FIRMWARE(api) \
- IWL_A000_HR_F0_FW_PRE "-" __stringify(api) ".ucode"
+ IWL_A000_HR_F0_FW_PRE __stringify(api) ".ucode"
#define IWL_A000_JF_B0_QNJ_MODULE_FIRMWARE(api) \
- IWL_A000_JF_B0_FW_PRE "-" __stringify(api) ".ucode"
+ IWL_A000_JF_B0_FW_PRE __stringify(api) ".ucode"
#define IWL_A000_HR_A0_QNJ_MODULE_FIRMWARE(api) \
- IWL_A000_HR_A0_FW_PRE "-" __stringify(api) ".ucode"
+ IWL_A000_HR_A0_FW_PRE __stringify(api) ".ucode"
#define NVM_HW_SECTION_NUM_FAMILY_A000 10
Patches currently in stable-queue which might be from tmb(a)mageia.org are
queue-4.14/iwlwifi-fix-firmware-names-for-9000-and-a000-series-hw.patch
This is a note to let you know that I've just added the patch titled
isofs: fix timestamps beyond 2027
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:
isofs-fix-timestamps-beyond-2027.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 34be4dbf87fc3e474a842305394534216d428f5d Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Thu, 19 Oct 2017 16:47:48 +0200
Subject: isofs: fix timestamps beyond 2027
From: Arnd Bergmann <arnd(a)arndb.de>
commit 34be4dbf87fc3e474a842305394534216d428f5d upstream.
isofs uses a 'char' variable to load the number of years since
1900 for an inode timestamp. On architectures that use a signed
char type by default, this results in an invalid date for
anything beyond 2027.
This changes the function argument to a 'u8' array, which
is defined the same way on all architectures, and unambiguously
lets us use years until 2155.
This should be backported to all kernels that might still be
in use by that date.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/isofs/isofs.h | 2 +-
fs/isofs/rock.h | 2 +-
fs/isofs/util.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- a/fs/isofs/isofs.h
+++ b/fs/isofs/isofs.h
@@ -107,7 +107,7 @@ static inline unsigned int isonum_733(ch
/* Ignore bigendian datum due to broken mastering programs */
return get_unaligned_le32(p);
}
-extern int iso_date(char *, int);
+extern int iso_date(u8 *, int);
struct inode; /* To make gcc happy */
--- a/fs/isofs/rock.h
+++ b/fs/isofs/rock.h
@@ -66,7 +66,7 @@ struct RR_PL_s {
};
struct stamp {
- char time[7];
+ __u8 time[7]; /* actually 6 unsigned, 1 signed */
} __attribute__ ((packed));
struct RR_TF_s {
--- a/fs/isofs/util.c
+++ b/fs/isofs/util.c
@@ -16,7 +16,7 @@
* to GMT. Thus we should always be correct.
*/
-int iso_date(char * p, int flag)
+int iso_date(u8 *p, int flag)
{
int year, month, day, hour, minute, second, tz;
int crtime;
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/rtlwifi-fix-uninitialized-rtlhal-last_suspend_sec-time.patch
queue-4.14/isofs-fix-timestamps-beyond-2027.patch
This is a note to let you know that I've just added the patch titled
iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref
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:
iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.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 ae072726f6109bb1c94841d6fb3a82dde298ea85 Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Date: Fri, 27 Oct 2017 12:32:59 -0700
Subject: iscsi-target: Make TASK_REASSIGN use proper se_cmd->cmd_kref
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
commit ae072726f6109bb1c94841d6fb3a82dde298ea85 upstream.
Since commit 59b6986dbf fixed a potential NULL pointer dereference
by allocating a se_tmr_req for ISCSI_TM_FUNC_TASK_REASSIGN, the
se_tmr_req is currently leaked by iscsit_free_cmd() because no
iscsi_cmd->se_cmd.se_tfo was associated.
To address this, treat ISCSI_TM_FUNC_TASK_REASSIGN like any other
TMR and call transport_init_se_cmd() + target_get_sess_cmd() to
setup iscsi_cmd->se_cmd.se_tfo with se_cmd->cmd_kref of 2.
This will ensure normal release operation once se_cmd->cmd_kref
reaches zero and target_release_cmd_kref() is invoked, se_tmr_req
will be released via existing target_free_cmd_mem() and
core_tmr_release_req() code.
Reported-by: Donald White <dew(a)datera.io>
Cc: Donald White <dew(a)datera.io>
Cc: Mike Christie <mchristi(a)redhat.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target.c | 22 +++++++++-------------
1 file changed, 9 insertions(+), 13 deletions(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -1960,7 +1960,6 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
struct iscsi_tmr_req *tmr_req;
struct iscsi_tm *hdr;
int out_of_order_cmdsn = 0, ret;
- bool sess_ref = false;
u8 function, tcm_function = TMR_UNKNOWN;
hdr = (struct iscsi_tm *) buf;
@@ -1993,22 +1992,23 @@ iscsit_handle_task_mgt_cmd(struct iscsi_
cmd->data_direction = DMA_NONE;
cmd->tmr_req = kzalloc(sizeof(*cmd->tmr_req), GFP_KERNEL);
- if (!cmd->tmr_req)
+ if (!cmd->tmr_req) {
return iscsit_add_reject_cmd(cmd,
ISCSI_REASON_BOOKMARK_NO_RESOURCES,
buf);
+ }
+
+ transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops,
+ conn->sess->se_sess, 0, DMA_NONE,
+ TCM_SIMPLE_TAG, cmd->sense_buffer + 2);
+
+ target_get_sess_cmd(&cmd->se_cmd, true);
/*
* TASK_REASSIGN for ERL=2 / connection stays inside of
* LIO-Target $FABRIC_MOD
*/
if (function != ISCSI_TM_FUNC_TASK_REASSIGN) {
- transport_init_se_cmd(&cmd->se_cmd, &iscsi_ops,
- conn->sess->se_sess, 0, DMA_NONE,
- TCM_SIMPLE_TAG, cmd->sense_buffer + 2);
-
- target_get_sess_cmd(&cmd->se_cmd, true);
- sess_ref = true;
tcm_function = iscsit_convert_tmf(function);
if (tcm_function == TMR_UNKNOWN) {
pr_err("Unknown iSCSI TMR Function:"
@@ -2124,12 +2124,8 @@ attach:
* For connection recovery, this is also the default action for
* TMR TASK_REASSIGN.
*/
- if (sess_ref) {
- pr_debug("Handle TMR, using sess_ref=true check\n");
- target_put_sess_cmd(&cmd->se_cmd);
- }
-
iscsit_add_cmd_to_response_queue(cmd, conn, cmd->i_state);
+ target_put_sess_cmd(&cmd->se_cmd);
return 0;
}
EXPORT_SYMBOL(iscsit_handle_task_mgt_cmd);
Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are
queue-4.14/target-fix-null-pointer-regression-in-core_tmr_drain_tmr_list.patch
queue-4.14/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch
queue-4.14/target-fix-queue_full-scsi-task-attribute-handling.patch
queue-4.14/target-fix-buffer-offset-in-core_scsi3_pri_read_full_status.patch
queue-4.14/iscsi-target-fix-non-immediate-tmr-reference-leak.patch
queue-4.14/target-fix-caw_sem-leak-in-transport_generic_request_failure.patch
queue-4.14/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch
queue-4.14/target-fix-quiese-during-transport_write_pending_qf-endless-loop.patch
This is a note to let you know that I've just added the patch titled
iscsi-target: Fix non-immediate TMR reference leak
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:
iscsi-target-fix-non-immediate-tmr-reference-leak.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 3fc9fb13a4b2576aeab86c62fd64eb29ab68659c Mon Sep 17 00:00:00 2001
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
Date: Fri, 27 Oct 2017 20:52:56 -0700
Subject: iscsi-target: Fix non-immediate TMR reference leak
From: Nicholas Bellinger <nab(a)linux-iscsi.org>
commit 3fc9fb13a4b2576aeab86c62fd64eb29ab68659c upstream.
This patch fixes a se_cmd->cmd_kref reference leak that can
occur when a non immediate TMR is proceeded our of command
sequence number order, and CMDSN_LOWER_THAN_EXP is returned
by iscsit_sequence_cmd().
To address this bug, call target_put_sess_cmd() during this
special case following what iscsit_process_scsi_cmd() does
upon CMDSN_LOWER_THAN_EXP.
Cc: Mike Christie <mchristi(a)redhat.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -2099,12 +2099,14 @@ attach:
if (!(hdr->opcode & ISCSI_OP_IMMEDIATE)) {
int cmdsn_ret = iscsit_sequence_cmd(conn, cmd, buf, hdr->cmdsn);
- if (cmdsn_ret == CMDSN_HIGHER_THAN_EXP)
+ if (cmdsn_ret == CMDSN_HIGHER_THAN_EXP) {
out_of_order_cmdsn = 1;
- else if (cmdsn_ret == CMDSN_LOWER_THAN_EXP)
+ } else if (cmdsn_ret == CMDSN_LOWER_THAN_EXP) {
+ target_put_sess_cmd(&cmd->se_cmd);
return 0;
- else if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER)
+ } else if (cmdsn_ret == CMDSN_ERROR_CANNOT_RECOVER) {
return -1;
+ }
}
iscsit_ack_from_expstatsn(conn, be32_to_cpu(hdr->exp_statsn));
Patches currently in stable-queue which might be from nab(a)linux-iscsi.org are
queue-4.14/target-fix-null-pointer-regression-in-core_tmr_drain_tmr_list.patch
queue-4.14/iscsi-target-make-task_reassign-use-proper-se_cmd-cmd_kref.patch
queue-4.14/target-fix-queue_full-scsi-task-attribute-handling.patch
queue-4.14/target-fix-buffer-offset-in-core_scsi3_pri_read_full_status.patch
queue-4.14/iscsi-target-fix-non-immediate-tmr-reference-leak.patch
queue-4.14/target-fix-caw_sem-leak-in-transport_generic_request_failure.patch
queue-4.14/target-avoid-early-cmd_t_pre_execute-failures-during-abort_task.patch
queue-4.14/target-fix-quiese-during-transport_write_pending_qf-endless-loop.patch
This is a note to let you know that I've just added the patch titled
irqchip/gic-v3: Fix ppi-partitions lookup
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:
irqchip-gic-v3-fix-ppi-partitions-lookup.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 00ee9a1ca5080202bc37b44e998c3b2c74d45817 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Sat, 11 Nov 2017 17:51:25 +0100
Subject: irqchip/gic-v3: Fix ppi-partitions lookup
From: Johan Hovold <johan(a)kernel.org>
commit 00ee9a1ca5080202bc37b44e998c3b2c74d45817 upstream.
Fix child-node lookup during initialisation, which ended up searching
the whole device tree depth-first starting at the parent rather than
just matching on its children.
To make things worse, the parent gic node was prematurely freed, while
the ppi-partitions node was leaked.
Fixes: e3825ba1af3a ("irqchip/gic-v3: Add support for partitioned PPIs")
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1071,18 +1071,18 @@ static void __init gic_populate_ppi_part
int nr_parts;
struct partition_affinity *parts;
- parts_node = of_find_node_by_name(gic_node, "ppi-partitions");
+ parts_node = of_get_child_by_name(gic_node, "ppi-partitions");
if (!parts_node)
return;
nr_parts = of_get_child_count(parts_node);
if (!nr_parts)
- return;
+ goto out_put_node;
parts = kzalloc(sizeof(*parts) * nr_parts, GFP_KERNEL);
if (WARN_ON(!parts))
- return;
+ goto out_put_node;
for_each_child_of_node(parts_node, child_part) {
struct partition_affinity *part;
@@ -1149,6 +1149,9 @@ static void __init gic_populate_ppi_part
gic_data.ppi_descs[i] = desc;
}
+
+out_put_node:
+ of_node_put(parts_node);
}
static void __init gic_of_setup_kvm_info(struct device_node *node)
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.14/serdev-fix-registration-of-second-slave.patch
queue-4.14/irqchip-gic-v3-fix-ppi-partitions-lookup.patch
This is a note to let you know that I've just added the patch titled
genirq: Track whether the trigger type has been set
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:
genirq-track-whether-the-trigger-type-has-been-set.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 4f8413a3a799c958f7a10a6310a451e6b8aef5ad Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 9 Nov 2017 14:17:59 +0000
Subject: genirq: Track whether the trigger type has been set
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 4f8413a3a799c958f7a10a6310a451e6b8aef5ad upstream.
When requesting a shared interrupt, we assume that the firmware
support code (DT or ACPI) has called irqd_set_trigger_type
already, so that we can retrieve it and check that the requester
is being reasonnable.
Unfortunately, we still have non-DT, non-ACPI systems around,
and these guys won't call irqd_set_trigger_type before requesting
the interrupt. The consequence is that we fail the request that
would have worked before.
We can either chase all these use cases (boring), or address it
in core code (easier). Let's have a per-irq_desc flag that
indicates whether irqd_set_trigger_type has been called, and
let's just check it when checking for a shared interrupt.
If it hasn't been set, just take whatever the interrupt
requester asks.
Fixes: 382bd4de6182 ("genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs")
Reported-and-tested-by: Petr Cvek <petrcvekcz(a)gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/irq.h | 11 ++++++++++-
kernel/irq/manage.c | 13 ++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -211,6 +211,7 @@ struct irq_data {
* IRQD_MANAGED_SHUTDOWN - Interrupt was shutdown due to empty affinity
* mask. Applies only to affinity managed irqs.
* IRQD_SINGLE_TARGET - IRQ allows only a single affinity target
+ * IRQD_DEFAULT_TRIGGER_SET - Expected trigger already been set
*/
enum {
IRQD_TRIGGER_MASK = 0xf,
@@ -231,6 +232,7 @@ enum {
IRQD_IRQ_STARTED = (1 << 22),
IRQD_MANAGED_SHUTDOWN = (1 << 23),
IRQD_SINGLE_TARGET = (1 << 24),
+ IRQD_DEFAULT_TRIGGER_SET = (1 << 25),
};
#define __irqd_to_state(d) ACCESS_PRIVATE((d)->common, state_use_accessors)
@@ -260,18 +262,25 @@ static inline void irqd_mark_affinity_wa
__irqd_to_state(d) |= IRQD_AFFINITY_SET;
}
+static inline bool irqd_trigger_type_was_set(struct irq_data *d)
+{
+ return __irqd_to_state(d) & IRQD_DEFAULT_TRIGGER_SET;
+}
+
static inline u32 irqd_get_trigger_type(struct irq_data *d)
{
return __irqd_to_state(d) & IRQD_TRIGGER_MASK;
}
/*
- * Must only be called inside irq_chip.irq_set_type() functions.
+ * Must only be called inside irq_chip.irq_set_type() functions or
+ * from the DT/ACPI setup code.
*/
static inline void irqd_set_trigger_type(struct irq_data *d, u32 type)
{
__irqd_to_state(d) &= ~IRQD_TRIGGER_MASK;
__irqd_to_state(d) |= type & IRQD_TRIGGER_MASK;
+ __irqd_to_state(d) |= IRQD_DEFAULT_TRIGGER_SET;
}
static inline bool irqd_is_level_type(struct irq_data *d)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1245,7 +1245,18 @@ __setup_irq(unsigned int irq, struct irq
* set the trigger type must match. Also all must
* agree on ONESHOT.
*/
- unsigned int oldtype = irqd_get_trigger_type(&desc->irq_data);
+ unsigned int oldtype;
+
+ /*
+ * If nobody did set the configuration before, inherit
+ * the one provided by the requester.
+ */
+ if (irqd_trigger_type_was_set(&desc->irq_data)) {
+ oldtype = irqd_get_trigger_type(&desc->irq_data);
+ } else {
+ oldtype = new->flags & IRQF_TRIGGER_MASK;
+ irqd_set_trigger_type(&desc->irq_data, oldtype);
+ }
if (!((old->flags & new->flags) & IRQF_SHARED) ||
(oldtype != (new->flags & IRQF_TRIGGER_MASK)) ||
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/irqchip-gic-v3-fix-ppi-partitions-lookup.patch
queue-4.14/genirq-track-whether-the-trigger-type-has-been-set.patch
This is a note to let you know that I've just added the patch titled
fsnotify: pin both inode and vfsmount mark
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:
fsnotify-pin-both-inode-and-vfsmount-mark.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 0d6ec079d6aaa098b978d6395973bb027c752a03 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Mon, 30 Oct 2017 21:14:55 +0100
Subject: fsnotify: pin both inode and vfsmount mark
From: Miklos Szeredi <mszeredi(a)redhat.com>
commit 0d6ec079d6aaa098b978d6395973bb027c752a03 upstream.
We may fail to pin one of the marks in fsnotify_prepare_user_wait() when
dropping the srcu read lock, resulting in use after free at the next
iteration.
Solution is to store both marks in iter_info instead of just the one we'll
be sending the event for.
Reviewed-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: 9385a84d7e1f ("fsnotify: Pass fsnotify_iter_info into handle_event handler")
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/notify/fsnotify.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/fs/notify/fsnotify.c
+++ b/fs/notify/fsnotify.c
@@ -335,6 +335,13 @@ int fsnotify(struct inode *to_tell, __u3
struct fsnotify_mark, obj_list);
vfsmount_group = vfsmount_mark->group;
}
+ /*
+ * Need to protect both marks against freeing so that we can
+ * continue iteration from this place, regardless of which mark
+ * we actually happen to send an event for.
+ */
+ iter_info.inode_mark = inode_mark;
+ iter_info.vfsmount_mark = vfsmount_mark;
if (inode_group && vfsmount_group) {
int cmp = fsnotify_compare_groups(inode_group,
@@ -348,9 +355,6 @@ int fsnotify(struct inode *to_tell, __u3
}
}
- iter_info.inode_mark = inode_mark;
- iter_info.vfsmount_mark = vfsmount_mark;
-
ret = send_to_group(to_tell, inode_mark, vfsmount_mark, mask,
data, data_is, cookie, file_name,
&iter_info);
Patches currently in stable-queue which might be from mszeredi(a)redhat.com are
queue-4.14/fsnotify-clean-up-fsnotify_prepare-finish_user_wait.patch
queue-4.14/fsnotify-fix-pinning-group-in-fsnotify_prepare_user_wait.patch
queue-4.14/fanotify-fix-fsnotify_prepare_user_wait-failure.patch
queue-4.14/fsnotify-pin-both-inode-and-vfsmount-mark.patch
queue-4.14/ovl-put-upperdentry-if-ovl_check_origin-fails.patch
This is a note to let you know that I've just added the patch titled
fsnotify: fix pinning group in fsnotify_prepare_user_wait()
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:
fsnotify-fix-pinning-group-in-fsnotify_prepare_user_wait.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 9a31d7ad997f55768c687974ce36b759065b49e5 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Mon, 30 Oct 2017 21:14:56 +0100
Subject: fsnotify: fix pinning group in fsnotify_prepare_user_wait()
From: Miklos Szeredi <mszeredi(a)redhat.com>
commit 9a31d7ad997f55768c687974ce36b759065b49e5 upstream.
Blind increment of group's user_waits is not enough, we could be far enough
in the group's destruction that it isn't taken into account (i.e. grabbing
the mark ref afterwards doesn't guarantee that it was the ref coming from
the _group_ that was grabbed).
Instead we need to check (under lock) that the mark is still attached to
the group after having obtained a ref to the mark. If not, skip it.
Reviewed-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: 9385a84d7e1f ("fsnotify: Pass fsnotify_iter_info into handle_event handler")
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/notify/mark.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
--- a/fs/notify/mark.c
+++ b/fs/notify/mark.c
@@ -255,23 +255,20 @@ void fsnotify_put_mark(struct fsnotify_m
*/
static bool fsnotify_get_mark_safe(struct fsnotify_mark *mark)
{
- struct fsnotify_group *group;
-
if (!mark)
return true;
- group = mark->group;
- /*
- * Since acquisition of mark reference is an atomic op as well, we can
- * be sure this inc is seen before any effect of refcount increment.
- */
- atomic_inc(&group->user_waits);
- if (atomic_inc_not_zero(&mark->refcnt))
- return true;
-
- if (atomic_dec_and_test(&group->user_waits) && group->shutdown)
- wake_up(&group->notification_waitq);
-
+ if (atomic_inc_not_zero(&mark->refcnt)) {
+ spin_lock(&mark->lock);
+ if (mark->flags & FSNOTIFY_MARK_FLAG_ATTACHED) {
+ /* mark is attached, group is still alive then */
+ atomic_inc(&mark->group->user_waits);
+ spin_unlock(&mark->lock);
+ return true;
+ }
+ spin_unlock(&mark->lock);
+ fsnotify_put_mark(mark);
+ }
return false;
}
Patches currently in stable-queue which might be from mszeredi(a)redhat.com are
queue-4.14/fsnotify-clean-up-fsnotify_prepare-finish_user_wait.patch
queue-4.14/fsnotify-fix-pinning-group-in-fsnotify_prepare_user_wait.patch
queue-4.14/fanotify-fix-fsnotify_prepare_user_wait-failure.patch
queue-4.14/fsnotify-pin-both-inode-and-vfsmount-mark.patch
queue-4.14/ovl-put-upperdentry-if-ovl_check_origin-fails.patch
This is a note to let you know that I've just added the patch titled
fsnotify: clean up fsnotify_prepare/finish_user_wait()
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:
fsnotify-clean-up-fsnotify_prepare-finish_user_wait.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 24c20305c7fc8959836211cb8c50aab93ae0e54f Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Mon, 30 Oct 2017 21:14:55 +0100
Subject: fsnotify: clean up fsnotify_prepare/finish_user_wait()
From: Miklos Szeredi <mszeredi(a)redhat.com>
commit 24c20305c7fc8959836211cb8c50aab93ae0e54f upstream.
This patch doesn't actually fix any bug, just paves the way for fixing mark
and group pinning.
Reviewed-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/notify/mark.c | 98 +++++++++++++++++++++++++++----------------------------
1 file changed, 49 insertions(+), 49 deletions(-)
--- a/fs/notify/mark.c
+++ b/fs/notify/mark.c
@@ -109,16 +109,6 @@ void fsnotify_get_mark(struct fsnotify_m
atomic_inc(&mark->refcnt);
}
-/*
- * Get mark reference when we found the mark via lockless traversal of object
- * list. Mark can be already removed from the list by now and on its way to be
- * destroyed once SRCU period ends.
- */
-static bool fsnotify_get_mark_safe(struct fsnotify_mark *mark)
-{
- return atomic_inc_not_zero(&mark->refcnt);
-}
-
static void __fsnotify_recalc_mask(struct fsnotify_mark_connector *conn)
{
u32 new_mask = 0;
@@ -256,32 +246,63 @@ void fsnotify_put_mark(struct fsnotify_m
FSNOTIFY_REAPER_DELAY);
}
-bool fsnotify_prepare_user_wait(struct fsnotify_iter_info *iter_info)
+/*
+ * Get mark reference when we found the mark via lockless traversal of object
+ * list. Mark can be already removed from the list by now and on its way to be
+ * destroyed once SRCU period ends.
+ *
+ * Also pin the group so it doesn't disappear under us.
+ */
+static bool fsnotify_get_mark_safe(struct fsnotify_mark *mark)
{
struct fsnotify_group *group;
- if (WARN_ON_ONCE(!iter_info->inode_mark && !iter_info->vfsmount_mark))
- return false;
-
- if (iter_info->inode_mark)
- group = iter_info->inode_mark->group;
- else
- group = iter_info->vfsmount_mark->group;
+ if (!mark)
+ return true;
+ group = mark->group;
/*
* Since acquisition of mark reference is an atomic op as well, we can
* be sure this inc is seen before any effect of refcount increment.
*/
atomic_inc(&group->user_waits);
+ if (atomic_inc_not_zero(&mark->refcnt))
+ return true;
+
+ if (atomic_dec_and_test(&group->user_waits) && group->shutdown)
+ wake_up(&group->notification_waitq);
+
+ return false;
+}
+
+/*
+ * Puts marks and wakes up group destruction if necessary.
+ *
+ * Pairs with fsnotify_get_mark_safe()
+ */
+static void fsnotify_put_mark_wake(struct fsnotify_mark *mark)
+{
+ if (mark) {
+ struct fsnotify_group *group = mark->group;
- if (iter_info->inode_mark) {
- /* This can fail if mark is being removed */
- if (!fsnotify_get_mark_safe(iter_info->inode_mark))
- goto out_wait;
- }
- if (iter_info->vfsmount_mark) {
- if (!fsnotify_get_mark_safe(iter_info->vfsmount_mark))
- goto out_inode;
+ fsnotify_put_mark(mark);
+ /*
+ * We abuse notification_waitq on group shutdown for waiting for
+ * all marks pinned when waiting for userspace.
+ */
+ if (atomic_dec_and_test(&group->user_waits) && group->shutdown)
+ wake_up(&group->notification_waitq);
+ }
+}
+
+bool fsnotify_prepare_user_wait(struct fsnotify_iter_info *iter_info)
+{
+ /* This can fail if mark is being removed */
+ if (!fsnotify_get_mark_safe(iter_info->inode_mark))
+ return false;
+ if (!fsnotify_get_mark_safe(iter_info->vfsmount_mark)) {
+ fsnotify_put_mark_wake(iter_info->inode_mark);
+ return false;
}
/*
@@ -292,34 +313,13 @@ bool fsnotify_prepare_user_wait(struct f
srcu_read_unlock(&fsnotify_mark_srcu, iter_info->srcu_idx);
return true;
-out_inode:
- if (iter_info->inode_mark)
- fsnotify_put_mark(iter_info->inode_mark);
-out_wait:
- if (atomic_dec_and_test(&group->user_waits) && group->shutdown)
- wake_up(&group->notification_waitq);
- return false;
}
void fsnotify_finish_user_wait(struct fsnotify_iter_info *iter_info)
{
- struct fsnotify_group *group = NULL;
-
iter_info->srcu_idx = srcu_read_lock(&fsnotify_mark_srcu);
- if (iter_info->inode_mark) {
- group = iter_info->inode_mark->group;
- fsnotify_put_mark(iter_info->inode_mark);
- }
- if (iter_info->vfsmount_mark) {
- group = iter_info->vfsmount_mark->group;
- fsnotify_put_mark(iter_info->vfsmount_mark);
- }
- /*
- * We abuse notification_waitq on group shutdown for waiting for all
- * marks pinned when waiting for userspace.
- */
- if (atomic_dec_and_test(&group->user_waits) && group->shutdown)
- wake_up(&group->notification_waitq);
+ fsnotify_put_mark_wake(iter_info->inode_mark);
+ fsnotify_put_mark_wake(iter_info->vfsmount_mark);
}
/*
Patches currently in stable-queue which might be from mszeredi(a)redhat.com are
queue-4.14/fsnotify-clean-up-fsnotify_prepare-finish_user_wait.patch
queue-4.14/fsnotify-fix-pinning-group-in-fsnotify_prepare_user_wait.patch
queue-4.14/fanotify-fix-fsnotify_prepare_user_wait-failure.patch
queue-4.14/fsnotify-pin-both-inode-and-vfsmount-mark.patch
queue-4.14/ovl-put-upperdentry-if-ovl_check_origin-fails.patch
This is a note to let you know that I've just added the patch titled
fscrypt: lock mutex before checking for bounce page pool
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:
fscrypt-lock-mutex-before-checking-for-bounce-page-pool.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 a0b3bc855374c50b5ea85273553485af48caf2f7 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Sun, 29 Oct 2017 06:30:19 -0400
Subject: fscrypt: lock mutex before checking for bounce page pool
From: Eric Biggers <ebiggers(a)google.com>
commit a0b3bc855374c50b5ea85273553485af48caf2f7 upstream.
fscrypt_initialize(), which allocates the global bounce page pool when
an encrypted file is first accessed, uses "double-checked locking" to
try to avoid locking fscrypt_init_mutex. However, it doesn't use any
memory barriers, so it's theoretically possible for a thread to observe
a bounce page pool which has not been fully initialized. This is a
classic bug with "double-checked locking".
While "only a theoretical issue" in the latest kernel, in pre-4.8
kernels the pointer that was checked was not even the last to be
initialized, so it was easily possible for a crash (NULL pointer
dereference) to happen. This was changed only incidentally by the large
refactor to use fs/crypto/.
Solve both problems in a trivial way that can easily be backported: just
always take the mutex. It's theoretically less efficient, but it
shouldn't be noticeable in practice as the mutex is only acquired very
briefly once per encrypted file.
Later I'd like to make this use a helper macro like DO_ONCE(). However,
DO_ONCE() runs in atomic context, so we'd need to add a new macro that
allows blocking.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/crypto/crypto.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/fs/crypto/crypto.c
+++ b/fs/crypto/crypto.c
@@ -410,11 +410,8 @@ int fscrypt_initialize(unsigned int cop_
{
int i, res = -ENOMEM;
- /*
- * No need to allocate a bounce page pool if there already is one or
- * this FS won't use it.
- */
- if (cop_flags & FS_CFLG_OWN_PAGES || fscrypt_bounce_page_pool)
+ /* No need to allocate a bounce page pool if this FS won't use it. */
+ if (cop_flags & FS_CFLG_OWN_PAGES)
return 0;
mutex_lock(&fscrypt_init_mutex);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/lib-mpi-call-cond_resched-from-mpi_powm-loop.patch
queue-4.14/fscrypt-lock-mutex-before-checking-for-bounce-page-pool.patch
queue-4.14/dm-bufio-fix-integer-overflow-when-limiting-maximum-cache-size.patch
queue-4.14/libceph-don-t-warn-if-user-tries-to-add-invalid-key.patch
This is a note to let you know that I've just added the patch titled
fs: guard_bio_eod() needs to consider partitions
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:
fs-guard_bio_eod-needs-to-consider-partitions.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 67f2519fe2903c4041c0e94394d14d372fe51399 Mon Sep 17 00:00:00 2001
From: Greg Edwards <gedwards(a)ddn.com>
Date: Tue, 24 Oct 2017 11:21:48 -0600
Subject: fs: guard_bio_eod() needs to consider partitions
From: Greg Edwards <gedwards(a)ddn.com>
commit 67f2519fe2903c4041c0e94394d14d372fe51399 upstream.
guard_bio_eod() needs to look at the partition capacity, not just the
capacity of the whole device, when determining if truncation is
necessary.
[ 60.268688] attempt to access beyond end of device
[ 60.268690] unknown-block(9,1): rw=0, want=67103509, limit=67103506
[ 60.268693] buffer_io_error: 2 callbacks suppressed
[ 60.268696] Buffer I/O error on dev md1p7, logical block 4524305, async page read
Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index")
Reviewed-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Greg Edwards <gedwards(a)ddn.com>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/buffer.c | 10 +++++++++-
include/linux/genhd.h | 1 +
2 files changed, 10 insertions(+), 1 deletion(-)
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3055,8 +3055,16 @@ void guard_bio_eod(int op, struct bio *b
sector_t maxsector;
struct bio_vec *bvec = &bio->bi_io_vec[bio->bi_vcnt - 1];
unsigned truncated_bytes;
+ struct hd_struct *part;
+
+ rcu_read_lock();
+ part = __disk_get_part(bio->bi_disk, bio->bi_partno);
+ if (part)
+ maxsector = part_nr_sects_read(part);
+ else
+ maxsector = get_capacity(bio->bi_disk);
+ rcu_read_unlock();
- maxsector = get_capacity(bio->bi_disk);
if (!maxsector)
return;
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -243,6 +243,7 @@ static inline dev_t part_devt(struct hd_
return part_to_dev(part)->devt;
}
+extern struct hd_struct *__disk_get_part(struct gendisk *disk, int partno);
extern struct hd_struct *disk_get_part(struct gendisk *disk, int partno);
static inline void disk_put_part(struct hd_struct *part)
Patches currently in stable-queue which might be from gedwards(a)ddn.com are
queue-4.14/fs-guard_bio_eod-needs-to-consider-partitions.patch
This is a note to let you know that I've just added the patch titled
fs/9p: Compare qid.path in v9fs_test_inode
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:
fs-9p-compare-qid.path-in-v9fs_test_inode.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 8ee031631546cf2f7859cc69593bd60bbdd70b46 Mon Sep 17 00:00:00 2001
From: Tuomas Tynkkynen <tuomas(a)tuxera.com>
Date: Wed, 6 Sep 2017 17:59:07 +0300
Subject: fs/9p: Compare qid.path in v9fs_test_inode
From: Tuomas Tynkkynen <tuomas(a)tuxera.com>
commit 8ee031631546cf2f7859cc69593bd60bbdd70b46 upstream.
Commit fd2421f54423 ("fs/9p: When doing inode lookup compare qid details
and inode mode bits.") transformed v9fs_qid_iget() to use iget5_locked()
instead of iget_locked(). However, the test() callback is not checking
fid.path at all, which means that a lookup in the inode cache can now
accidentally locate a completely wrong inode from the same inode hash
bucket if the other fields (qid.type and qid.version) match.
Fixes: fd2421f54423 ("fs/9p: When doing inode lookup compare qid details and inode mode bits.")
Reviewed-by: Latchesar Ionkov <lucho(a)ionkov.net>
Signed-off-by: Tuomas Tynkkynen <tuomas(a)tuxera.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/9p/vfs_inode.c | 3 +++
fs/9p/vfs_inode_dotl.c | 3 +++
2 files changed, 6 insertions(+)
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -483,6 +483,9 @@ static int v9fs_test_inode(struct inode
if (v9inode->qid.type != st->qid.type)
return 0;
+
+ if (v9inode->qid.path != st->qid.path)
+ return 0;
return 1;
}
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -87,6 +87,9 @@ static int v9fs_test_inode_dotl(struct i
if (v9inode->qid.type != st->qid.type)
return 0;
+
+ if (v9inode->qid.path != st->qid.path)
+ return 0;
return 1;
}
Patches currently in stable-queue which might be from tuomas(a)tuxera.com are
queue-4.14/net-9p-switch-to-wait_event_killable.patch
queue-4.14/9p-fix-missing-commas-in-mount-options.patch
queue-4.14/fs-9p-compare-qid.path-in-v9fs_test_inode.patch
This is a note to let you know that I've just added the patch titled
fix a page leak in vhost_scsi_iov_to_sgl() error recovery
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:
fix-a-page-leak-in-vhost_scsi_iov_to_sgl-error-recovery.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 11d49e9d089ccec81be87c2386dfdd010d7f7f6e Mon Sep 17 00:00:00 2001
From: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Sun, 24 Sep 2017 18:36:44 -0400
Subject: fix a page leak in vhost_scsi_iov_to_sgl() error recovery
From: Al Viro <viro(a)zeniv.linux.org.uk>
commit 11d49e9d089ccec81be87c2386dfdd010d7f7f6e upstream.
we are advancing sg as we go, so the pages we need to drop in
case of error are *before* the current sg.
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/vhost/scsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -688,6 +688,7 @@ vhost_scsi_iov_to_sgl(struct vhost_scsi_
struct scatterlist *sg, int sg_count)
{
size_t off = iter->iov_offset;
+ struct scatterlist *p = sg;
int i, ret;
for (i = 0; i < iter->nr_segs; i++) {
@@ -696,8 +697,8 @@ vhost_scsi_iov_to_sgl(struct vhost_scsi_
ret = vhost_scsi_map_to_sgl(cmd, base, len, sg, write);
if (ret < 0) {
- for (i = 0; i < sg_count; i++) {
- struct page *page = sg_page(&sg[i]);
+ while (p < sg) {
+ struct page *page = sg_page(p++);
if (page)
put_page(page);
}
Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are
queue-4.14/net-9p-switch-to-wait_event_killable.patch
queue-4.14/9p-fix-missing-commas-in-mount-options.patch
queue-4.14/fs-9p-compare-qid.path-in-v9fs_test_inode.patch
queue-4.14/fix-a-page-leak-in-vhost_scsi_iov_to_sgl-error-recovery.patch
queue-4.14/arm64-implement-arch-specific-pte_access_permitted.patch
This is a note to let you know that I've just added the patch titled
fanotify: fix fsnotify_prepare_user_wait() failure
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:
fanotify-fix-fsnotify_prepare_user_wait-failure.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 f37650f1c7c71cf5180b43229d13b421d81e7170 Mon Sep 17 00:00:00 2001
From: Miklos Szeredi <mszeredi(a)redhat.com>
Date: Mon, 30 Oct 2017 21:14:56 +0100
Subject: fanotify: fix fsnotify_prepare_user_wait() failure
From: Miklos Szeredi <mszeredi(a)redhat.com>
commit f37650f1c7c71cf5180b43229d13b421d81e7170 upstream.
If fsnotify_prepare_user_wait() fails, we leave the event on the
notification list. Which will result in a warning in
fsnotify_destroy_event() and later use-after-free.
Instead of adding a new helper to remove the event from the list in this
case, I opted to move the prepare/finish up into fanotify_handle_event().
This will allow these to be moved further out into the generic code later,
and perhaps let us move to non-sleeping RCU.
Reviewed-by: Amir Goldstein <amir73il(a)gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi(a)redhat.com>
Fixes: 05f0e38724e8 ("fanotify: Release SRCU lock when waiting for userspace response")
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/notify/fanotify/fanotify.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -65,19 +65,8 @@ static int fanotify_get_response(struct
pr_debug("%s: group=%p event=%p\n", __func__, group, event);
- /*
- * fsnotify_prepare_user_wait() fails if we race with mark deletion.
- * Just let the operation pass in that case.
- */
- if (!fsnotify_prepare_user_wait(iter_info)) {
- event->response = FAN_ALLOW;
- goto out;
- }
-
wait_event(group->fanotify_data.access_waitq, event->response);
- fsnotify_finish_user_wait(iter_info);
-out:
/* userspace responded, convert to something usable */
switch (event->response) {
case FAN_ALLOW:
@@ -212,9 +201,21 @@ static int fanotify_handle_event(struct
pr_debug("%s: group=%p inode=%p mask=%x\n", __func__, group, inode,
mask);
+#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
+ if (mask & FAN_ALL_PERM_EVENTS) {
+ /*
+ * fsnotify_prepare_user_wait() fails if we race with mark
+ * deletion. Just let the operation pass in that case.
+ */
+ if (!fsnotify_prepare_user_wait(iter_info))
+ return 0;
+ }
+#endif
+
event = fanotify_alloc_event(inode, mask, data);
+ ret = -ENOMEM;
if (unlikely(!event))
- return -ENOMEM;
+ goto finish;
fsn_event = &event->fse;
ret = fsnotify_add_event(group, fsn_event, fanotify_merge);
@@ -224,7 +225,8 @@ static int fanotify_handle_event(struct
/* Our event wasn't used in the end. Free it. */
fsnotify_destroy_event(group, fsn_event);
- return 0;
+ ret = 0;
+ goto finish;
}
#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
@@ -233,6 +235,11 @@ static int fanotify_handle_event(struct
iter_info);
fsnotify_destroy_event(group, fsn_event);
}
+finish:
+ if (mask & FAN_ALL_PERM_EVENTS)
+ fsnotify_finish_user_wait(iter_info);
+#else
+finish:
#endif
return ret;
}
Patches currently in stable-queue which might be from mszeredi(a)redhat.com are
queue-4.14/fsnotify-clean-up-fsnotify_prepare-finish_user_wait.patch
queue-4.14/fsnotify-fix-pinning-group-in-fsnotify_prepare_user_wait.patch
queue-4.14/fanotify-fix-fsnotify_prepare_user_wait-failure.patch
queue-4.14/fsnotify-pin-both-inode-and-vfsmount-mark.patch
queue-4.14/ovl-put-upperdentry-if-ovl_check_origin-fails.patch