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