This is a note to let you know that I've just added the patch titled
usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-move-usb_uhci_big_endian_-out-of-usb_support.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ec897569ad7dbc6d595873a487c3fac23f463f76 Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Wed, 31 Jan 2018 22:24:45 +0000
Subject: usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
From: James Hogan <jhogan(a)kernel.org>
commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream.
Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and
USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is
conditional upon USB && USB_SUPPORT, so that it can be freely selected
by platform Kconfig symbols in architecture code.
For example once the MIPS_GENERIC platform selects are fixed in commit
2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS
32r6_defconfig warns like so:
warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB)
warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB)
Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN")
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Cc: Corentin Labbe <clabbe.montjoie(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Paul Burton <paul.burton(a)mips.com>
Cc: linux-usb(a)vger.kernel.org
Cc: linux-mips(a)linux-mips.org
Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Patchwork: https://patchwork.linux-mips.org/patch/18559/
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/Kconfig | 8 ++++++++
drivers/usb/host/Kconfig | 8 --------
2 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO
config USB_EHCI_BIG_ENDIAN_DESC
bool
+config USB_UHCI_BIG_ENDIAN_MMIO
+ bool
+ default y if SPARC_LEON
+
+config USB_UHCI_BIG_ENDIAN_DESC
+ bool
+ default y if SPARC_LEON
+
menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -625,14 +625,6 @@ config USB_UHCI_ASPEED
bool
default y if ARCH_ASPEED
-config USB_UHCI_BIG_ENDIAN_MMIO
- bool
- default y if SPARC_LEON
-
-config USB_UHCI_BIG_ENDIAN_DESC
- bool
- default y if SPARC_LEON
-
config USB_FHCI_HCD
tristate "Freescale QE USB Host Controller support"
depends on OF_GPIO && QE_GPIO && QUICC_ENGINE
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.15/usb-move-usb_uhci_big_endian_-out-of-usb_support.patch
queue-4.15/mips-fix-typo-big_endian-to-cpu_big_endian.patch
queue-4.15/mips-fix-incorrect-mem-x-y-handling.patch
queue-4.15/mips-cps-fix-mips_isa_level_raw-fallout.patch
This is a note to let you know that I've just added the patch titled
usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
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:
usb-move-usb_uhci_big_endian_-out-of-usb_support.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 ec897569ad7dbc6d595873a487c3fac23f463f76 Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Wed, 31 Jan 2018 22:24:45 +0000
Subject: usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
From: James Hogan <jhogan(a)kernel.org>
commit ec897569ad7dbc6d595873a487c3fac23f463f76 upstream.
Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and
USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is
conditional upon USB && USB_SUPPORT, so that it can be freely selected
by platform Kconfig symbols in architecture code.
For example once the MIPS_GENERIC platform selects are fixed in commit
2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN"), the MIPS
32r6_defconfig warns like so:
warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB)
warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB)
Fixes: 2e6522c56552 ("MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN")
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Cc: Corentin Labbe <clabbe.montjoie(a)gmail.com>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Paul Burton <paul.burton(a)mips.com>
Cc: linux-usb(a)vger.kernel.org
Cc: linux-mips(a)linux-mips.org
Acked-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Patchwork: https://patchwork.linux-mips.org/patch/18559/
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/Kconfig | 8 ++++++++
drivers/usb/host/Kconfig | 8 --------
2 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO
config USB_EHCI_BIG_ENDIAN_DESC
bool
+config USB_UHCI_BIG_ENDIAN_MMIO
+ bool
+ default y if SPARC_LEON
+
+config USB_UHCI_BIG_ENDIAN_DESC
+ bool
+ default y if SPARC_LEON
+
menuconfig USB_SUPPORT
bool "USB support"
depends on HAS_IOMEM
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -637,14 +637,6 @@ config USB_UHCI_ASPEED
bool
default y if ARCH_ASPEED
-config USB_UHCI_BIG_ENDIAN_MMIO
- bool
- default y if SPARC_LEON
-
-config USB_UHCI_BIG_ENDIAN_DESC
- bool
- default y if SPARC_LEON
-
config USB_FHCI_HCD
tristate "Freescale QE USB Host Controller support"
depends on OF_GPIO && QE_GPIO && QUICC_ENGINE
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.14/usb-move-usb_uhci_big_endian_-out-of-usb_support.patch
queue-4.14/mips-fix-typo-big_endian-to-cpu_big_endian.patch
queue-4.14/mips-fix-incorrect-mem-x-y-handling.patch
The patch below does not apply to the 3.18-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 447cae58cecd69392b74a4a42cd0ab9cabd816af Mon Sep 17 00:00:00 2001
From: Kirill Marinushkin <k.marinushkin(a)gmail.com>
Date: Mon, 29 Jan 2018 06:37:55 +0100
Subject: [PATCH] ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE
attribute
The layout of the UAC2 Control request and response varies depending on
the request type. With the current implementation, only the Layout 2
Parameter Block (with the 2-byte sized RANGE attribute) is handled
properly. For the Control requests with the 1-byte sized RANGE attribute
(Bass Control, Mid Control, Tremble Control), the response is parsed
incorrectly.
This commit:
* fixes the wLength field value in the request
* fixes parsing the range values from the response
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 9afb8ab524c7..06b22624ab7a 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -347,17 +347,20 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info *cval, int request,
int validx, int *value_ret)
{
struct snd_usb_audio *chip = cval->head.mixer->chip;
- unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range */
+ /* enough space for one range */
+ unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)];
unsigned char *val;
- int idx = 0, ret, size;
+ int idx = 0, ret, val_size, size;
__u8 bRequest;
+ val_size = uac2_ctl_value_size(cval->val_type);
+
if (request == UAC_GET_CUR) {
bRequest = UAC2_CS_CUR;
- size = uac2_ctl_value_size(cval->val_type);
+ size = val_size;
} else {
bRequest = UAC2_CS_RANGE;
- size = sizeof(buf);
+ size = sizeof(__u16) + 3 * val_size;
}
memset(buf, 0, sizeof(buf));
@@ -390,16 +393,17 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info *cval, int request,
val = buf + sizeof(__u16);
break;
case UAC_GET_MAX:
- val = buf + sizeof(__u16) * 2;
+ val = buf + sizeof(__u16) + val_size;
break;
case UAC_GET_RES:
- val = buf + sizeof(__u16) * 3;
+ val = buf + sizeof(__u16) + val_size * 2;
break;
default:
return -EINVAL;
}
- *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, sizeof(__u16)));
+ *value_ret = convert_signed_value(cval,
+ snd_usb_combine_bytes(val, val_size));
return 0;
}
On Tue, Feb 20, 2018 at 03:32:44PM +0000, James Hogan wrote:
> Hi Greg,
>
> On Tue, Feb 20, 2018 at 12:10:06PM +0100, gregkh(a)linuxfoundation.org wrote:
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN
> >
> > to the 4.15-stable tree which can be found at:
> > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
> >
> > The filename of the patch is:
> > mips-fix-typo-big_endian-to-cpu_big_endian.patch
> > and it can be found in the queue-4.15 subdirectory.
> >
> > If you, or anyone else, feels it should not be added to the stable tree,
> > please let <stable(a)vger.kernel.org> know about it.
>
> FYI this will introduce the following harmless kconfig warnings which
> are fixed by commit ec897569ad7d ("usb: Move USB_UHCI_BIG_ENDIAN_* out
> of USB_SUPPORT"):
>
> warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB)
> warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB)
>
> If anybody cares about such warnings, that patch could be applied also.
I'll go queue that up too, thanks.
greg k-h
This is a note to let you know that I've just added the patch titled
target/iscsi: avoid NULL dereference in CHAP auth error path
to the 4.9-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:
target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch
and it can be found in the queue-4.9 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 ce512d79d0466a604793addb6b769d12ee326822 Mon Sep 17 00:00:00 2001
From: David Disseldorp <ddiss(a)suse.de>
Date: Wed, 13 Dec 2017 18:22:30 +0100
Subject: target/iscsi: avoid NULL dereference in CHAP auth error path
From: David Disseldorp <ddiss(a)suse.de>
commit ce512d79d0466a604793addb6b769d12ee326822 upstream.
If chap_server_compute_md5() fails early, e.g. via CHAP_N mismatch, then
crypto_free_shash() is called with a NULL pointer which gets
dereferenced in crypto_shash_tfm().
Fixes: 69110e3cedbb ("iscsi-target: Use shash and ahash")
Suggested-by: Markus Elfring <elfring(a)users.sourceforge.net>
Signed-off-by: David Disseldorp <ddiss(a)suse.de>
Cc: stable(a)vger.kernel.org # 4.6+
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_auth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/target/iscsi/iscsi_target_auth.c
+++ b/drivers/target/iscsi/iscsi_target_auth.c
@@ -413,7 +413,8 @@ static int chap_server_compute_md5(
auth_ret = 0;
out:
kzfree(desc);
- crypto_free_shash(tfm);
+ if (tfm)
+ crypto_free_shash(tfm);
kfree(challenge);
kfree(challenge_binhex);
return auth_ret;
Patches currently in stable-queue which might be from ddiss(a)suse.de are
queue-4.9/target-iscsi-avoid-null-dereference-in-chap-auth-error-path.patch
This is a note to let you know that I've just added the patch titled
rtlwifi: rtl8821ae: Fix connection lost problem correctly
to the 4.9-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:
rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch
and it can be found in the queue-4.9 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 c713fb071edc0efc01a955f65a006b0e1795d2eb Mon Sep 17 00:00:00 2001
From: Larry Finger <Larry.Finger(a)lwfinger.net>
Date: Mon, 5 Feb 2018 12:38:11 -0600
Subject: rtlwifi: rtl8821ae: Fix connection lost problem correctly
From: Larry Finger <Larry.Finger(a)lwfinger.net>
commit c713fb071edc0efc01a955f65a006b0e1795d2eb upstream.
There has been a coding error in rtl8821ae since it was first introduced,
namely that an 8-bit register was read using a 16-bit read in
_rtl8821ae_dbi_read(). This error was fixed with commit 40b368af4b75
("rtlwifi: Fix alignment issues"); however, this change led to
instability in the connection. To restore stability, this change
was reverted in commit b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection
lost problem").
Unfortunately, the unaligned access causes machine checks in ARM
architecture, and we were finally forced to find the actual cause of the
problem on x86 platforms. Following a suggestion from Pkshih
<pkshih(a)realtek.com>, it was found that increasing the ASPM L1
latency from 0 to 7 fixed the instability. This parameter was varied to
see if a smaller value would work; however, it appears that 7 is the
safest value. A new symbol is defined for this quantity, thus it can be
easily changed if necessary.
Fixes: b8b8b16352cd ("rtlwifi: rtl8821ae: Fix connection lost problem")
Cc: Stable <stable(a)vger.kernel.org> # 4.14+
Fix-suggested-by: Pkshih <pkshih(a)realtek.com>
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
Tested-by: James Cameron <quozl(a)laptop.org> # x86_64 OLPC NL3
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 5 +++--
drivers/net/wireless/realtek/rtlwifi/wifi.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1128,7 +1128,7 @@ static u8 _rtl8821ae_dbi_read(struct rtl
}
if (0 == tmp) {
read_addr = REG_DBI_RDATA + addr % 4;
- ret = rtl_read_word(rtlpriv, read_addr);
+ ret = rtl_read_byte(rtlpriv, read_addr);
}
return ret;
}
@@ -1170,7 +1170,8 @@ static void _rtl8821ae_enable_aspm_back_
}
tmp = _rtl8821ae_dbi_read(rtlpriv, 0x70f);
- _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7));
+ _rtl8821ae_dbi_write(rtlpriv, 0x70f, tmp | BIT(7) |
+ ASPM_L1_LATENCY << 3);
tmp = _rtl8821ae_dbi_read(rtlpriv, 0x719);
_rtl8821ae_dbi_write(rtlpriv, 0x719, tmp | BIT(3) | BIT(4));
--- a/drivers/net/wireless/realtek/rtlwifi/wifi.h
+++ b/drivers/net/wireless/realtek/rtlwifi/wifi.h
@@ -99,6 +99,7 @@
#define RTL_USB_MAX_RX_COUNT 100
#define QBSS_LOAD_SIZE 5
#define MAX_WMMELE_LENGTH 64
+#define ASPM_L1_LATENCY 7
#define TOTAL_CAM_ENTRY 32
Patches currently in stable-queue which might be from Larry.Finger(a)lwfinger.net are
queue-4.9/rtlwifi-rtl8821ae-fix-connection-lost-problem-correctly.patch
This is a note to let you know that I've just added the patch titled
mvpp2: fix multicast address filter
to the 4.9-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:
mvpp2-fix-multicast-address-filter.patch
and it can be found in the queue-4.9 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 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Sun, 11 Feb 2018 18:10:28 -0500
Subject: mvpp2: fix multicast address filter
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3 upstream.
IPv6 doesn't work on the MacchiatoBIN board. It is caused by broken
multicast address filter in the mvpp2 driver.
The driver loads doesn't load any multicast entries if "allmulti" is not
set. This condition should be reversed.
The condition !netdev_mc_empty(dev) is useless (because
netdev_for_each_mc_addr is nop if the list is empty).
This patch also fixes a possible overflow of the multicast list - if
mvpp2_prs_mac_da_accept fails, we set the allmulti flag and retry.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/marvell/mvpp2.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -5657,6 +5657,7 @@ static void mvpp2_set_rx_mode(struct net
int id = port->id;
bool allmulti = dev->flags & IFF_ALLMULTI;
+retry:
mvpp2_prs_mac_promisc_set(priv, id, dev->flags & IFF_PROMISC);
mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_ALL, allmulti);
mvpp2_prs_mac_multi_set(priv, id, MVPP2_PE_MAC_MC_IP6, allmulti);
@@ -5664,9 +5665,13 @@ static void mvpp2_set_rx_mode(struct net
/* Remove all port->id's mcast enries */
mvpp2_prs_mcast_del_all(priv, id);
- if (allmulti && !netdev_mc_empty(dev)) {
- netdev_for_each_mc_addr(ha, dev)
- mvpp2_prs_mac_da_accept(priv, id, ha->addr, true);
+ if (!allmulti) {
+ netdev_for_each_mc_addr(ha, dev) {
+ if (mvpp2_prs_mac_da_accept(priv, id, ha->addr, true)) {
+ allmulti = true;
+ goto retry;
+ }
+ }
}
}
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.9/mvpp2-fix-multicast-address-filter.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: vf610: set correct ooblayout
to the 4.9-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:
mtd-nand-vf610-set-correct-ooblayout.patch
and it can be found in the queue-4.9 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 ea56fb282368ea08c2a313af6b55cb597aec4db1 Mon Sep 17 00:00:00 2001
From: Stefan Agner <stefan(a)agner.ch>
Date: Fri, 9 Feb 2018 13:21:42 +0100
Subject: mtd: nand: vf610: set correct ooblayout
From: Stefan Agner <stefan(a)agner.ch>
commit ea56fb282368ea08c2a313af6b55cb597aec4db1 upstream.
With commit 3cf32d180227 ("mtd: nand: vf610: switch to
mtd_ooblayout_ops") the driver started to use the NAND cores
default large page ooblayout. However, shortly after commit
6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
changed the default layout to the old hamming layout, which is
not what vf610_nfc is using. Specify the default large page
layout explicitly.
Fixes: 6a623e076944 ("mtd: nand: add ooblayout for old hamming layout")
Cc: <stable(a)vger.kernel.org> # v4.12+
Signed-off-by: Stefan Agner <stefan(a)agner.ch>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/vf610_nfc.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -752,10 +752,8 @@ static int vf610_nfc_probe(struct platfo
if (mtd->oobsize > 64)
mtd->oobsize = 64;
- /*
- * mtd->ecclayout is not specified here because we're using the
- * default large page ECC layout defined in NAND core.
- */
+ /* Use default large page ECC layout defined in NAND core */
+ mtd_set_ooblayout(mtd, &nand_ooblayout_lp_ops);
if (chip->ecc.strength == 32) {
nfc->ecc_mode = ECC_60_BYTE;
chip->ecc.bytes = 60;
Patches currently in stable-queue which might be from stefan(a)agner.ch are
queue-4.9/mtd-nand-vf610-set-correct-ooblayout.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix unexpected -EEXIST when creating new inode
to the 4.9-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:
btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
and it can be found in the queue-4.9 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 900c9981680067573671ecc5cbfa7c5770be3a40 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:56 -0700
Subject: Btrfs: fix unexpected -EEXIST when creating new inode
From: Liu Bo <bo.li.liu(a)oracle.com>
commit 900c9981680067573671ecc5cbfa7c5770be3a40 upstream.
The highest objectid, which is assigned to new inode, is decided at
the time of initializing fs roots. However, in cases where log replay
gets processed, the btree which fs root owns might be changed, so we
have to search it again for the highest objectid, otherwise creating
new inode would end up with -EEXIST.
cc: <stable(a)vger.kernel.org> v4.4-rc6+
Fixes: f32e48e92596 ("Btrfs: Initialize btrfs_root->highest_objectid when loading tree root and subvolume roots")
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tree-log.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -28,6 +28,7 @@
#include "hash.h"
#include "compression.h"
#include "qgroup.h"
+#include "inode-map.h"
/* magic values for the inode_only field in btrfs_log_inode:
*
@@ -5661,6 +5662,23 @@ again:
path);
}
+ if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) {
+ struct btrfs_root *root = wc.replay_dest;
+
+ btrfs_release_path(path);
+
+ /*
+ * We have just replayed everything, and the highest
+ * objectid of fs roots probably has changed in case
+ * some inode_item's got replayed.
+ *
+ * root->objectid_mutex is not acquired as log replay
+ * could only happen during mount.
+ */
+ ret = btrfs_find_highest_objectid(root,
+ &root->highest_objectid);
+ }
+
key.offset = found_key.offset - 1;
wc.replay_dest->log_root = NULL;
free_extent_buffer(log->node);
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.9/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.9/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.9/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.9/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.9/btrfs-fix-deadlock-in-run_delalloc_nocow.patch
This is a note to let you know that I've just added the patch titled
Btrfs: fix extent state leak from tree log
to the 4.9-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:
btrfs-fix-extent-state-leak-from-tree-log.patch
and it can be found in the queue-4.9 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 55237a5f2431a72435e3ed39e4306e973c0446b7 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Thu, 25 Jan 2018 11:02:52 -0700
Subject: Btrfs: fix extent state leak from tree log
From: Liu Bo <bo.li.liu(a)oracle.com>
commit 55237a5f2431a72435e3ed39e4306e973c0446b7 upstream.
It's possible that btrfs_sync_log() bails out after one of the two
btrfs_write_marked_extents() which convert extent state's state bit into
EXTENT_NEED_WAIT from EXTENT_DIRTY/EXTENT_NEW, however only EXTENT_DIRTY
and EXTENT_NEW are searched by free_log_tree() so that those extent states
with EXTENT_NEED_WAIT lead to memory leak.
cc: <stable(a)vger.kernel.org>
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Reviewed-by: Josef Bacik <jbacik(a)fb.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/tree-log.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -3013,13 +3013,14 @@ static void free_log_tree(struct btrfs_t
while (1) {
ret = find_first_extent_bit(&log->dirty_log_pages,
- 0, &start, &end, EXTENT_DIRTY | EXTENT_NEW,
+ 0, &start, &end,
+ EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT,
NULL);
if (ret)
break;
clear_extent_bits(&log->dirty_log_pages, start, end,
- EXTENT_DIRTY | EXTENT_NEW);
+ EXTENT_DIRTY | EXTENT_NEW | EXTENT_NEED_WAIT);
}
/*
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.9/btrfs-fix-btrfs_evict_inode-to-handle-abnormal-inodes-correctly.patch
queue-4.9/btrfs-fix-crash-due-to-not-cleaning-up-tree-log-block-s-dirty-bits.patch
queue-4.9/btrfs-fix-extent-state-leak-from-tree-log.patch
queue-4.9/btrfs-fix-unexpected-eexist-when-creating-new-inode.patch
queue-4.9/btrfs-fix-deadlock-in-run_delalloc_nocow.patch