This is a note to let you know that I've just added the patch titled
mtd: nand: pxa3xx: Fix READOOB implementation
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-pxa3xx-fix-readoob-implementation.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 fee4380f368e84ed216b62ccd2fbc4126f2bf40b Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Date: Mon, 18 Dec 2017 11:32:45 +0100
Subject: mtd: nand: pxa3xx: Fix READOOB implementation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Boris Brezillon <boris.brezillon(a)free-electrons.com>
commit fee4380f368e84ed216b62ccd2fbc4126f2bf40b upstream.
In the current driver, OOB bytes are accessed in raw mode, and when a
page access is done with NDCR_SPARE_EN set and NDCR_ECC_EN cleared, the
driver must read the whole spare area (64 bytes in case of a 2k page,
16 bytes for a 512 page). The driver was only reading the free OOB
bytes, which was leaving some unread data in the FIFO and was somehow
leading to a timeout.
We could patch the driver to read ->spare_size + ->ecc_size instead of
just ->spare_size when READOOB is requested, but we'd better make
in-band and OOB accesses consistent.
Since the driver is always accessing in-band data in non-raw mode (with
the ECC engine enabled), we should also access OOB data in this mode.
That's particularly useful when using the BCH engine because in this
mode the free OOB bytes are also ECC protected.
Fixes: 43bcfd2bb24a ("mtd: nand: pxa3xx: Add driver-specific ECC BCH support")
Reported-by: Sean Nyekjær <sean.nyekjaer(a)prevas.dk>
Tested-by: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Acked-by: Ezequiel Garcia <ezequiel(a)vanguardiasur.com.ar>
Tested-by: Sean Nyekjaer <sean.nyekjaer(a)prevas.dk>
Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/pxa3xx_nand.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -950,6 +950,7 @@ static void prepare_start_command(struct
switch (command) {
case NAND_CMD_READ0:
+ case NAND_CMD_READOOB:
case NAND_CMD_PAGEPROG:
info->use_ecc = 1;
break;
Patches currently in stable-queue which might be from boris.brezillon(a)free-electrons.com are
queue-4.9/mtd-nand-pxa3xx-fix-readoob-implementation.patch
Hi Pavlos!
On Mon, Jan 08, 2018 at 04:19:17PM +0100, Pavlos Parissis wrote:
> Hi,
>
> The 4.14 kernel is listed as a 'Stable' but not as 'Longterm' in the kernel releases feed[1], is
> this expected?
Normally kernels are only listed as LTS once they leave their regular
"stable" status, often after next kernel version is issued. I think this
leaves a last minute chance to Greg to change his mind if the kernel he
elected is too damaged ;-)
Cheers,
Willy
Hi Greg,
sorry, I lost the overview -- the KPTI 4.14, 4.9 and 4.4 patch set is
diverging...
I am missing patches like
x86/pti: Switch to kernel CR3 at early in entry_SYSCALL_compat()
x86/pti: Make sure the user/kernel PTEs match
in 4.9.
The first one was really important but the problem might be hidden now
due to
x86/cpu, x86/pti: Do not enable PTI on AMD processors
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
The patch
ASoC: rockchip: i2s: fix playback after runtime resume
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From c66234cfedfc3e6e3b62563a5f2c1562be09a35d Mon Sep 17 00:00:00 2001
From: John Keeping <john(a)metanate.com>
Date: Mon, 8 Jan 2018 16:01:04 +0000
Subject: [PATCH] ASoC: rockchip: i2s: fix playback after runtime resume
When restoring registers during runtime resume, we must not write to
I2S_TXDR which is the transmit FIFO as this queues up a sample to be
output and pushes all of the output channels down by one.
This can be demonstrated with the speaker-test utility:
for i in a b c; do speaker-test -c 2 -s 1; done
which should play a test through the left speaker three times but if the
I2S hardware starts runtime suspended the first sample will be played
through the right speaker.
Fix this by marking I2S_TXDR as volatile (which also requires marking it
as readble, even though it technically isn't). This seems to be the
most robust fix, the alternative of giving I2S_TXDR a default value is
more fragile since it does not prevent regcache writing to the register
in all circumstances.
While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
are not writable so they do not suffer from the same problem as I2S_TXDR
but reading from I2S_RXDR does suffer from a similar problem.
Fixes: f0447f6cbb20 ("ASoC: rockchip: i2s: restore register during runtime_suspend/resume cycle", 2016-09-07)
Signed-off-by: John Keeping <john(a)metanate.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/rockchip/rockchip_i2s.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 908211e1d6fc..eb27f6c24bf7 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -504,6 +504,7 @@ static bool rockchip_i2s_rd_reg(struct device *dev, unsigned int reg)
case I2S_INTCR:
case I2S_XFER:
case I2S_CLR:
+ case I2S_TXDR:
case I2S_RXDR:
case I2S_FIFOLR:
case I2S_INTSR:
@@ -518,6 +519,9 @@ static bool rockchip_i2s_volatile_reg(struct device *dev, unsigned int reg)
switch (reg) {
case I2S_INTSR:
case I2S_CLR:
+ case I2S_FIFOLR:
+ case I2S_TXDR:
+ case I2S_RXDR:
return true;
default:
return false;
@@ -527,6 +531,8 @@ static bool rockchip_i2s_volatile_reg(struct device *dev, unsigned int reg)
static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
+ case I2S_RXDR:
+ return true;
default:
return false;
}
--
2.15.1
On 01/08/2018 07:28 AM, Yves-Alexis Perez wrote:
> On Mon, 2018-01-08 at 15:19 +0000, Ben Hutchings wrote:
>>> I tried this on a ThinkPad X230 (Ivy Bridge CPU, i7 3520M, so pcid but not
>>> invpcid) on full UEFI mode and it doesn't boot at all. grub-efi loads the
>>> kernel and initrd, but I don't have any message after “Loading initial
>>> ramdisk” (even with debug earlyprintk=vga).
>> If you boot with EFI you need to use earlyprintk=efi.
> Thanks! With that, I can see the last few log lines before it hangs:
>
> Kernel/User page tables isolation: enabled
> […]
> bootconsole [earlyefi0] disabled
Does "earlyprintk=efi,keep" help get more out to the console?
> Also I must have done something wrong earlier today, because when booting with
> 'nopcid' it does work (which is consistent with other people tests, afaict).
If I had to guess, I'd say we're probably putting a PCID value into the
low bits of CR3 before we've _enabled_ PCID support in the CPU.
On Mon, Jan 08, 2018 at 04:19:17PM +0100, Pavlos Parissis wrote:
> Hi,
>
> The 4.14 kernel is listed as a 'Stable' but not as 'Longterm' in the kernel releases feed[1], is
> this expected?
Yes. A kernel can not become "LTS" until it has a chance to be that,
right now it is still just a "Stable" release as 4.15 is not released.
thanks,
greg k-h
On 05/01/18 00:06, Kevin Hilman wrote:
> kernelci.org bot <bot(a)kernelci.org> writes:
>
>> stable-rc/linux-4.4.y boot: 100 boots: 4 failed, 93 passed with 1 offline, 2 conflicts (v4.4.109-38-g99abd6cdd65e)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.…
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.109-38-…
>>
>> Tree: stable-rc
>> Branch: linux-4.4.y
>> Git Describe: v4.4.109-38-g99abd6cdd65e
>> Git Commit: 99abd6cdd65e984d89c8565508a7a96ea0fce179
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 53 unique boards, 19 SoC families, 16 builds out of 178
>
> TL;DR; All is well.
>
>> Boot Regressions Detected:
>>
>> arm:
>>
>> exynos_defconfig:
>> exynos5422-odroidxu3:
>> lab-collabora: failing since 58 days (last pass: v4.4.95-21-g32458fcb7bd6 - first fail: v4.4.96-41-g336421367b9c)
>
> Long standing issue in lab-collabora (passing in other labs) Guillaume?
This should be fixed now, with a tweak to the device config to
enable relocating the ramdisk and dtb:
https://review.linaro.org/#/c/23238/
>> multi_v7_defconfig:
>> armada-xp-linksys-mamba:
>> lab-free-electrons: new failure (last pass: v4.4.109-36-g8b381424010c)
>
> Not a kerel issue, bootROM fails to start bootloader. I pinged lab
> owners (Free Electrons)
>
>> tegra124-nyan-big:
>> lab-collabora: failing since 1 day (last pass: v4.4.109 - first fail: v4.4.109-36-g8b381424010c)
>>
>> tegra_defconfig:
>> tegra124-nyan-big:
>> lab-collabora: failing since 1 day (last pass: v4.4.108-65-g57856049c0f8 - first fail: v4.4.109)
>
> This one is booting fine, but the command to power-off the board is
> timing out, resulting in a failure report.
Indeed, this was due to a crash of the lavapdu daemon - it's back
on track now.
(On a side note, the tegra124-nyan-big is still failing to boot
in mainline due to a genuine kernel driver issue.)
Guillaume
+Sjoerd
On 05/01/18 00:12, Kevin Hilman wrote:
> kernelci.org bot <bot(a)kernelci.org> writes:
>
>> stable-rc/linux-4.14.y boot: 118 boots: 4 failed, 113 passed with 1 offline (v4.14.11-15-g732141e47ee6)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1…
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.11-15…
>>
>> Tree: stable-rc
>> Branch: linux-4.14.y
>> Git Describe: v4.14.11-15-g732141e47ee6
>> Git Commit: 732141e47ee614d70aeb8ad828a977ad19447e87
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 68 unique boards, 23 SoC families, 16 builds out of 185
>>
>> Boot Regressions Detected:
>
> TL;DR; All is well.
>
> Same issues as reported for stable-rc/linux-4.4.y, but...
>
>> arm:
>>
>> multi_v7_defconfig:
>> armada-xp-linksys-mamba:
>> lab-free-electrons: new failure (last pass: v4.14.11)
>> tegra124-nyan-big:
>> lab-collabora: failing since 1 day (last pass: v4.14.10-147-g61f3176f64e3 - first fail: v4.14.11)
>>
>> omap2plus_defconfig:
>> am335x-boneblack:
>> lab-collabora: new failure (last pass: v4.14.11)
>
> ... this one is unique to 4.14, but is still a lab issue: bootloader
> fails to DHCP.
Turns out this is a known hardware issue with the ethernet phy on
this type of board. It's possible to work around it (retry...),
we'll take a look.
Guillaume
Quoting the original report:
It looks like there is a double-free vulnerability in Linux usbtv driver on an error path of usbtv_probe function. When audio registration fails, usbtv_video_free function ends up freeing usbtv data structure, which gets freed the second time under usbtv_video_fail label.
usbtv_audio_fail:
usbtv_video_free(usbtv); =>
v4l2_device_put(&usbtv->v4l2_dev);
=> v4l2_device_put
=> kref_put
=> v4l2_device_release
=> usbtv_release (CALLBACK)
=> kfree(usbtv) (1st time)
usbtv_video_fail:
usb_set_intfdata(intf, NULL);
usb_put_dev(usbtv->udev);
kfree(usbtv); (2nd time)
So, as we have refcounting, use it
Reported-by: Yavuz, Tuba <tuba(a)ece.ufl.edu>
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
CC: stable(a)vger.kernel.org
---
drivers/media/usb/usbtv/usbtv-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c
index 127f8a0c098b..0c2e628e8723 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -112,6 +112,8 @@ static int usbtv_probe(struct usb_interface *intf,
return 0;
usbtv_audio_fail:
+ /* we must not free at this point */
+ usb_get_dev(usbtv->udev);
usbtv_video_free(usbtv);
usbtv_video_fail:
--
2.13.6