When CONFIG_ARM_LPAE is set, the PMD dump relies on the software
read-only bit to determine whether a page is writable. This
concealed a bug which left the kernel text section writable
(AP2=0) while marked read-only in the software bit.
In a kernel with the AP2 bug, the dump looks like this:
---[ Kernel Mapping ]---
0xc0000000-0xc0200000 2M RW NX SHD
0xc0200000-0xc0600000 4M ro x SHD
0xc0600000-0xc0800000 2M ro NX SHD
0xc0800000-0xc4800000 64M RW NX SHD
The fix is to check that the software and hardware bits are both
set before displaying "ro". The dump then shows the true perms:
---[ Kernel Mapping ]---
0xc0000000-0xc0200000 2M RW NX SHD
0xc0200000-0xc0600000 4M RW x SHD
0xc0600000-0xc0800000 2M RW NX SHD
0xc0800000-0xc4800000 64M RW NX SHD
Fixes: ded947798469 ("ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE")
Signed-off-by: Philip Derrin <philip(a)cog.systems>
Tested-by: Neil Dick <neil(a)cog.systems>
Cc: stable(a)vger.kernel.org
---
arch/arm/mm/dump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/dump.c b/arch/arm/mm/dump.c
index 35ff45470dbf..fc3b44028cfb 100644
--- a/arch/arm/mm/dump.c
+++ b/arch/arm/mm/dump.c
@@ -129,8 +129,8 @@ static const struct prot_bits section_bits[] = {
.val = PMD_SECT_USER,
.set = "USR",
}, {
- .mask = L_PMD_SECT_RDONLY,
- .val = L_PMD_SECT_RDONLY,
+ .mask = L_PMD_SECT_RDONLY | PMD_SECT_AP2,
+ .val = L_PMD_SECT_RDONLY | PMD_SECT_AP2,
.set = "ro",
.clear = "RW",
#elif __LINUX_ARM_ARCH__ >= 6
--
2.15.0
Currently, for ARM kernels with CONFIG_ARM_LPAE and
CONFIG_STRICT_KERNEL_RWX enabled, the 2MiB pages mapping the
kernel code and rodata are writable. They are marked read-only in
a software bit (L_PMD_SECT_RDONLY) but the hardware read-only bit
is not set (PMD_SECT_AP2).
For user mappings, the logic that propagates the software bit
to the hardware bit is in set_pmd_at(); but for the kernel,
section_update() writes the PMDs directly, skipping this logic.
The fix is to set PMD_SECT_AP2 for read-only sections in
section_update(), at the same time as L_PMD_SECT_RDONLY.
Fixes: 1e3479225acb ("ARM: 8275/1: mm: fix PMD_SECT_RDONLY undeclared compile error")
Signed-off-by: Philip Derrin <philip(a)cog.systems>
Reported-by: Neil Dick <neil(a)cog.systems>
Tested-by: Neil Dick <neil(a)cog.systems>
Tested-by: Laura Abbott <labbott(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
arch/arm/mm/init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index ad80548325fe..0f6d1537f330 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -639,8 +639,8 @@ static struct section_perm ro_perms[] = {
.start = (unsigned long)_stext,
.end = (unsigned long)__init_begin,
#ifdef CONFIG_ARM_LPAE
- .mask = ~L_PMD_SECT_RDONLY,
- .prot = L_PMD_SECT_RDONLY,
+ .mask = ~(L_PMD_SECT_RDONLY | PMD_SECT_AP2),
+ .prot = L_PMD_SECT_RDONLY | PMD_SECT_AP2,
#else
.mask = ~(PMD_SECT_APX | PMD_SECT_AP_WRITE),
.prot = PMD_SECT_APX | PMD_SECT_AP_WRITE,
--
2.15.0
On Wed, Nov 08, 2017 at 11:11:11PM +0000, Mark Brown wrote:
>On Wed, Nov 08, 2017 at 10:48:14PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote:
>
>> >expose problems if we start using it. If you look at the history of the
>> >driver there's some quirks were added later on for example, and I didn't
>> >check the DMA controller drivers or anything and obviously can't see any
>> >out of tree code users may have.
>
>> I'm considering these commits to be on the safer side because they're
>> much older than the ones Greg usually grabs. There were no upstream
>> fixes to this commit for 10 months now, and given the code changes
>> upstream in that subsystem, this patch seemed to be safe to backport.
>
>Like I say I'm seeing some potentially relevant variant handling added
>later and you also have to consider the DMA drivers it might be used
>with (imx-dma looks safe but perhaps there's other things, never mind
>out of tree code). It just doesn't feel good.
>
>We have also had problems in the past with SPI performance enhancements
>exposing exising problems elsewhere though not so much with this sort of
>area so I'm less worried about that.
Sure, I'll drop it. Thanks!
--
Thanks,
Sasha
On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote:
>On Wed, Nov 08, 2017 at 09:39:11PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> >On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> >This seems like an optimization not a bug fix...
>
>> Hm, is it? I read it as "DMA is not being used at all even though we
>> thought we're using it".
>
>Yes, that's how I read it too.
>
>> Yes, the impact is "just" performance, but doesn't it result in quite
>> a significat impact?
>
>Only about double according to the initial commit adding DMA support
>which is frankly a bit disappointing although yeah, it's a big win. My
>worry is that if there's a problem with DMA on some device for which a
>fix wasn't backported (or where we're using a fallback) this could
>expose problems if we start using it. If you look at the history of the
>driver there's some quirks were added later on for example, and I didn't
>check the DMA controller drivers or anything and obviously can't see any
>out of tree code users may have.
>
>*Probably* it doesn't break anything but since it's not fixing anything
>and the risk is data corruption I'd be much more comfortable with a more
>thorough risk analysis.
I'm considering these commits to be on the safer side because they're
much older than the ones Greg usually grabs. There were no upstream
fixes to this commit for 10 months now, and given the code changes
upstream in that subsystem, this patch seemed to be safe to backport.
--
Thanks,
Sasha
On Wed, Nov 08, 2017 at 08:57:52PM +0000, Mark Brown wrote:
>On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote:
>> From: Jiada Wang <jiada_wang(a)mentor.com>
>>
>> [ Upstream commit 66459c5a50a787c474b734b586328f7111ab6df0 ]
>>
>> Previously DMA watermark level is configured to fifosize/2,
>> DMA mode can be used only when transfer length can be divided
>> by 'watermark level * bpw', which makes DMA mode not pratical.
>>
>> This patch adjusts watermark level to largest number (no bigger
>> than fifosize/2) which can divide 'tranfer length / bpw' for
>> each transfer.
>
>This seems like an optimization not a bug fix...
Hm, is it? I read it as "DMA is not being used at all even though we
thought we're using it".
Yes, the impact is "just" performance, but doesn't it result in quite
a significat impact?
--
Thanks,
Sasha
Since its introduction, the codec had an inversion of the left and right
channels. It turned out to be pretty simple as it appears that the codec
doesn't have the same polarity on the LRCK signal than the I2S block.
Fix this by inverting our bit value for the LRCK inversion.
Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com>
---
sound/soc/sunxi/sun8i-codec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index 522546e6b153..c8dcb1502d74 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -200,7 +200,7 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV);
regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
BIT(SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV),
- value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV);
+ !value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV);
/* DAI format */
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
--
2.14.3
From: Roger Quadros <rogerq(a)ti.com>
[ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ]
extcon-palmas must be child of palmas and expects parent's
drvdata to be valid. Check for non NULL parent drvdata and
fail if it is NULL. Not doing so will result in a NULL
pointer dereference later in the probe() parent drvdata
is NULL (e.g. misplaced extcon-palmas node in device tree).
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
---
drivers/extcon/extcon-palmas.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 230e1220ce48..1cee9f4909db 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -150,6 +150,11 @@ static int palmas_usb_probe(struct platform_device *pdev)
struct palmas_usb *palmas_usb;
int status;
+ if (!palmas) {
+ dev_err(&pdev->dev, "failed to get valid parent\n");
+ return -EINVAL;
+ }
+
palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL);
if (!palmas_usb)
return -ENOMEM;
--
2.11.0