Now MTD emulated by UBI volumn doesn't allocate wbuf_verify in
jffs2_ubivol_setup(), because UBI can do the verifcation itself,
so when CONFIG_JFFS2_FS_WBUF_VERIFY is enabled and a MTD device
emulated by UBI volumn is used, a Oops will occur as show in the
following trace:
general protection fault: 0000 [#1] SMP KASAN PTI
CPU: 6 PID: 404 Comm: kworker/6:1 Not tainted 4.19.0-rc8
Workqueue: events_long delayed_wbuf_sync
RIP: 0010:ubi_io_read+0x156/0x650
Call Trace:
ubi_eba_read_leb+0x57d/0xba0
ubi_leb_read+0xe5/0x1b0
gluebi_read+0x10c/0x1a0
mtd_read+0x112/0x340
jffs2_verify_write+0xef/0x440
__jffs2_flush_wbuf+0x3fa/0x3540
jffs2_flush_wbuf_gc+0x1b1/0x2e0
process_one_work+0x58b/0x11e0
worker_thread+0x8f/0xfe0
kthread+0x2ae/0x3a0
ret_from_fork+0x35/0x40
Fix the problem by checking the validity of wbuf_verify before
using it in jffs2_verify_write().
Cc: stable(a)vger.kernel.org
Fixes: 0029da3bf430 ("JFFS2: add UBI support")
Signed-off-by: Hou Tao <houtao1(a)huawei.com>
---
fs/jffs2/wbuf.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/fs/jffs2/wbuf.c b/fs/jffs2/wbuf.c
index c6821a509481..3de45f4559d1 100644
--- a/fs/jffs2/wbuf.c
+++ b/fs/jffs2/wbuf.c
@@ -234,6 +234,13 @@ static int jffs2_verify_write(struct jffs2_sb_info *c, unsigned char *buf,
size_t retlen;
char *eccstr;
+ /*
+ * MTD emulated by UBI volume doesn't allocate wbuf_verify,
+ * because it can do the verification itself.
+ */
+ if (!c->wbuf_verify)
+ return 0;
+
ret = mtd_read(c->mtd, ofs, c->wbuf_pagesize, &retlen, c->wbuf_verify);
if (ret && ret != -EUCLEAN && ret != -EBADMSG) {
pr_warn("%s(): Read back of page at %08x failed: %d\n",
--
2.16.2.dirty
commit 1f82de10d6 ("PCI/x86: don't assume prefetchable ranges are
64bit") added probing of bridge support for 64 bit memory
each time bridge is re-enumerated.
Unfortunately this probing is destructive if any device behind
the bridge is in use at this time.
There's no real need to re-probe the bridge features as the
regiters in question never change - detect that using
the memory flag being set and skip the probing.
Avoiding repeated calls to pci_bridge_check_ranges might be even nicer
would be a bigger patch and probably not appropriate on stable.
Reported-by: xuyandong <xuyandong2(a)huawei.com>
Cc: stable(a)vger.kernel.org
Cc: Yinghai Lu <yinghai(a)kernel.org>
Cc: Jesse Barnes <jbarnes(a)virtuousgeek.org>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
---
This issue has been reported on upstream Linux and Centos.
drivers/pci/setup-bus.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index ed960436df5e..7ab42f76579e 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -741,6 +741,13 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
struct resource *b_res;
b_res = &bridge->resource[PCI_BRIDGE_RESOURCES];
+
+ /* Don't re-check after this was called once already:
+ * important since bridge might be in use.
+ */
+ if (b_res[1].flags & IORESOURCE_MEM)
+ return;
+
b_res[1].flags |= IORESOURCE_MEM;
pci_read_config_word(bridge, PCI_IO_BASE, &io);
--
MST
According to my memo at hand and saved records, writing 0x00000001 to
SND_FF_REG_FETCH_PCM_FRAMES disables fetching PCM frames in corresponding
channel, however current implement uses reversed logic. This results in
muted volume in device side during playback.
This commit corrects the bug.
Cc: <stable(a)vger.kernel.org> # v4.12+
Fixes: 76fdb3a9e13a ('ALSA: fireface: add support for Fireface 400')
Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp>
---
sound/firewire/fireface/ff-protocol-ff400.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/firewire/fireface/ff-protocol-ff400.c b/sound/firewire/fireface/ff-protocol-ff400.c
index 8f34174ee813..fd257051d4a4 100644
--- a/sound/firewire/fireface/ff-protocol-ff400.c
+++ b/sound/firewire/fireface/ff-protocol-ff400.c
@@ -86,7 +86,7 @@ static int ff400_switch_fetching_mode(struct snd_ff *ff, bool enable)
if (reg == NULL)
return -ENOMEM;
- if (enable) {
+ if (!enable) {
/*
* Each quadlet is corresponding to data channels in a data
* blocks in reverse order. Precisely, quadlets for available
--
2.19.1
marvell_nfc_wait_op() waits for completion during 'timeout_ms'
milliseconds before throwing an error. While the logic is fine, the
value of 'timeout_ms' is given by the core and actually correspond to
the maximum time the NAND chip will take to complete the
operation. Assuming there is no overhead in the propagation of the
interrupt signal to the the NAND controller (through the Ready/Busy
line), this delay does not take into account the latency of the
operating system. For instance, for a page write, the delay given by
the core is rounded up to 1ms. Hence, when the machine is over loaded,
there is chances that this timeout will be reached.
There are two ways to solve this issue that are not incompatible:
1/ Enlarge the timeout value (if so, how much?).
2/ Check after the waiting method if we did not miss any interrupt
because of the OS latency (an interrupt is still pending). In this
case, we assume the operation exited successfully.
We choose the second approach that is a must in all cases, with the
possibility to also modify the timeout value to be, e.g. at least 1
second in all cases.
Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
Cc: stable(a)vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com>
---
drivers/mtd/nand/raw/marvell_nand.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c
index e6c3739cea73..bc0eef4ade4f 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -514,9 +514,14 @@ static void marvell_nfc_enable_int(struct marvell_nfc *nfc, u32 int_mask)
writel_relaxed(reg & ~int_mask, nfc->regs + NDCR);
}
-static void marvell_nfc_clear_int(struct marvell_nfc *nfc, u32 int_mask)
+static int marvell_nfc_clear_int(struct marvell_nfc *nfc, u32 int_mask)
{
+ u32 reg;
+
+ reg = readl_relaxed(nfc->regs + NDSR);
writel_relaxed(int_mask, nfc->regs + NDSR);
+
+ return reg & int_mask;
}
static void marvell_nfc_force_byte_access(struct nand_chip *chip,
@@ -683,6 +688,7 @@ static int marvell_nfc_wait_cmdd(struct nand_chip *chip)
static int marvell_nfc_wait_op(struct nand_chip *chip, unsigned int timeout_ms)
{
struct marvell_nfc *nfc = to_marvell_nfc(chip->controller);
+ int pending;
int ret;
/* Timeout is expressed in ms */
@@ -695,8 +701,13 @@ static int marvell_nfc_wait_op(struct nand_chip *chip, unsigned int timeout_ms)
ret = wait_for_completion_timeout(&nfc->complete,
msecs_to_jiffies(timeout_ms));
marvell_nfc_disable_int(nfc, NDCR_RDYM);
- marvell_nfc_clear_int(nfc, NDSR_RDY(0) | NDSR_RDY(1));
- if (!ret) {
+ pending = marvell_nfc_clear_int(nfc, NDSR_RDY(0) | NDSR_RDY(1));
+
+ /*
+ * In case the interrupt was not served in the required time frame,
+ * check if the ISR was not served or if something went actually wrong.
+ */
+ if (ret && !pending) {
dev_err(nfc->dev, "Timeout waiting for RB signal\n");
return -ETIMEDOUT;
}
--
2.19.1
Commit 379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
accidentally broke unwinding from userspace, because ld would strip the
.eh_frame sections when linking.
Originally, the compiler would implicitly add --eh-frame-hdr when
invoking the linker, but when this Makefile was converted from invoking
ld via the compiler, to invoking it directly (like vmlinux does),
the flag was missed. (The EH_FRAME section is important for the VDSO
shared libraries, but not for vmlinux.)
Fix the problem by explicitly specifying --eh-frame-hdr, which restores
parity with the old method.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201741
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1659295
Reported-by: Florian Weimer <fweimer(a)redhat.com>
Reported-by: Carlos O'Donell <carlos(a)redhat.com>
Reported-by: "H. J. Lu" <hjl.tools(a)gmail.com>
Tested-by: Laura Abbott <labbott(a)redhat.com>
Fixes: 379d98ddf413 ("x86: vdso: Use $LD instead of $CC to link")
Cc: stable(a)vger.kernel.org
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: "H. Peter Anvin" <hpa(a)zytor.com>
Cc: X86 ML <x86(a)kernel.org>
Cc: Joel Fernandes <joel(a)joelfernandes.org>
Cc: kernel-team(a)android.com
Signed-off-by: Alistair Strachan <astrachan(a)google.com>
---
v2: Updated commit message, no changes to the code
arch/x86/entry/vdso/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 141d415a8c80..c3d7ccd25381 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -171,7 +171,8 @@ quiet_cmd_vdso = VDSO $@
sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
VDSO_LDFLAGS = -shared $(call ld-option, --hash-style=both) \
- $(call ld-option, --build-id) -Bsymbolic
+ $(call ld-option, --build-id) $(call ld-option, --eh-frame-hdr) \
+ -Bsymbolic
GCOV_PROFILE := n
#
--
2.20.0.405.gbc1bbc6f85-goog
