Re: [PATCH -next] ubifs: remove unused function __ubifs_shash_final
On 3/21/2019 1:39 PM, Richard Weinberger wrote: Am Donnerstag, 21. März 2019, 08:54:55 CET schrieb Mukesh Ojha: Acked-by: Mukesh Ojha I guess you mean Reviewed-by? As i am unsure about future scope of this func. i.e why Acked. Acked-by is usually something I expect from the code author or the person that owns the code. Take it as Reviewed-by then. Thanks. Mukesh Thanks, //richard
[PATCH 3/4] rtc: wm831x: switch to rtc_time64_to_tm/rtc_tm_to_time64
Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-wm831x.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index 1b0c3b3f63e8..d286dd1dfcf9 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -155,7 +155,7 @@ static int wm831x_rtc_readtime(struct device *dev, struct
rtc_time *tm)
if (memcmp(time1, time2, sizeof(time1)) == 0) {
u32 time = (time1[0] << 16) | time1[1];
- rtc_time_to_tm(time, tm);
+ rtc_time64_to_tm(time, tm);
return 0;
}
@@ -215,11 +215,7 @@ static int wm831x_rtc_set_mmss(struct device *dev,
unsigned long time)
if (ret < 0)
return ret;
- ret = rtc_tm_to_time(&new_tm, &new_time);
- if (ret < 0) {
- dev_err(dev, "Failed to convert time: %d\n", ret);
- return ret;
- }
+ new_time = rtc_tm_to_time64(&new_tm);
/* Allow a second of change in case of tick */
if (new_time - time > 1) {
@@ -249,7 +245,7 @@ static int wm831x_rtc_readalarm(struct device *dev, struct
rtc_wkalrm *alrm)
time = (data[0] << 16) | data[1];
- rtc_time_to_tm(time, &alrm->time);
+ rtc_time64_to_tm(time, &alrm->time);
ret = wm831x_reg_read(wm831x_rtc->wm831x, WM831X_RTC_CONTROL);
if (ret < 0) {
@@ -288,11 +284,7 @@ static int wm831x_rtc_setalarm(struct device *dev, struct
rtc_wkalrm *alrm)
int ret;
unsigned long time;
- ret = rtc_tm_to_time(&alrm->time, &time);
- if (ret < 0) {
- dev_err(dev, "Failed to convert time: %d\n", ret);
- return ret;
- }
+ time = rtc_tm_to_time64(&alrm->time);
ret = wm831x_rtc_stop_alarm(wm831x_rtc);
if (ret < 0) {
--
2.20.1
[PATCH 4/4] rtc: wm831x: convert to SPDX identifier
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-wm831x.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c index d286dd1dfcf9..6a0defd16088 100644 --- a/drivers/rtc/rtc-wm831x.c +++ b/drivers/rtc/rtc-wm831x.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Real Time Clock driver for Wolfson Microelectronics WM831x * @@ -5,11 +6,6 @@ * * Author: Mark Brown * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * */ #include -- 2.20.1
[PATCH 2/4] rtc: wm831x: remove unnecessary goto
There is no specific handling in the error path of wm831x_rtc_probe, remove
the unnecessary goto and label.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-wm831x.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index deaffe0eaf2f..1b0c3b3f63e8 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -429,7 +429,7 @@ static int wm831x_rtc_probe(struct platform_device *pdev)
ret = wm831x_reg_read(wm831x, WM831X_RTC_CONTROL);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to read RTC control: %d\n", ret);
- goto err;
+ return ret;
}
if (ret & WM831X_RTC_ALM_ENA)
wm831x_rtc->alarm_enabled = 1;
@@ -459,9 +459,6 @@ static int wm831x_rtc_probe(struct platform_device *pdev)
wm831x_rtc_add_randomness(wm831x);
return 0;
-
-err:
- return ret;
}
static const struct dev_pm_ops wm831x_rtc_pm_ops = {
--
2.20.1
[PATCH 1/4] rtc: wm831x: set range
The wm831x has a 32bit second counter.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-wm831x.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index 7b824dabf104..deaffe0eaf2f 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -436,12 +436,16 @@ static int wm831x_rtc_probe(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, 1);
- wm831x_rtc->rtc = devm_rtc_device_register(&pdev->dev, "wm831x",
- &wm831x_rtc_ops, THIS_MODULE);
- if (IS_ERR(wm831x_rtc->rtc)) {
- ret = PTR_ERR(wm831x_rtc->rtc);
- goto err;
- }
+ wm831x_rtc->rtc = devm_rtc_allocate_device(&pdev->dev);
+ if (IS_ERR(wm831x_rtc->rtc))
+ return PTR_ERR(wm831x_rtc->rtc);
+
+ wm831x_rtc->rtc->ops = &wm831x_rtc_ops;
+ wm831x_rtc->rtc->range_max = U32_MAX;
+
+ ret = rtc_register_device(wm831x_rtc->rtc);
+ if (ret)
+ return ret;
ret = devm_request_threaded_irq(&pdev->dev, alm_irq, NULL,
wm831x_alm_irq,
--
2.20.1
Re: possible deadlock in userfaultfd_release
syzbot has bisected this bug to:
commit bfe4037e722ec672c9dafd5730d9132afeeb76e9
Author: Christoph Hellwig
Date: Mon Jul 16 07:08:20 2018 +
aio: implement IOCB_CMD_POLL
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1382985d20
start commit: bfe4037e aio: implement IOCB_CMD_POLL
git tree: upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=1042985d20
console output: https://syzkaller.appspot.com/x/log.txt?x=1782985d20
kernel config: https://syzkaller.appspot.com/x/.config?x=5c0a49d2b5210087
dashboard link: https://syzkaller.appspot.com/bug?extid=53c0b767f7ca0dc0c451
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=f2eb40
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13e874f540
Reported-by: syzbot+53c0b767f7ca0dc0c...@syzkaller.appspotmail.com
Fixes: bfe4037e722e ("aio: implement IOCB_CMD_POLL")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH 1/4] rtc: wm831x: set range
The wm831x has a 32bit second counter.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-wm831x.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index 7b824dabf104..deaffe0eaf2f 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -436,12 +436,16 @@ static int wm831x_rtc_probe(struct platform_device *pdev)
device_init_wakeup(&pdev->dev, 1);
- wm831x_rtc->rtc = devm_rtc_device_register(&pdev->dev, "wm831x",
- &wm831x_rtc_ops, THIS_MODULE);
- if (IS_ERR(wm831x_rtc->rtc)) {
- ret = PTR_ERR(wm831x_rtc->rtc);
- goto err;
- }
+ wm831x_rtc->rtc = devm_rtc_allocate_device(&pdev->dev);
+ if (IS_ERR(wm831x_rtc->rtc))
+ return PTR_ERR(wm831x_rtc->rtc);
+
+ wm831x_rtc->rtc->ops = &wm831x_rtc_ops;
+ wm831x_rtc->rtc->range_max = U32_MAX;
+
+ ret = rtc_register_device(wm831x_rtc->rtc);
+ if (ret)
+ return ret;
ret = devm_request_threaded_irq(&pdev->dev, alm_irq, NULL,
wm831x_alm_irq,
--
2.20.1
[PATCH 2/4] rtc: wm831x: remove unnecessary goto
There is no specific handling in the error path of wm831x_rtc_probe, remove
the unnecessary goto and label.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-wm831x.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index deaffe0eaf2f..1b0c3b3f63e8 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -429,7 +429,7 @@ static int wm831x_rtc_probe(struct platform_device *pdev)
ret = wm831x_reg_read(wm831x, WM831X_RTC_CONTROL);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to read RTC control: %d\n", ret);
- goto err;
+ return ret;
}
if (ret & WM831X_RTC_ALM_ENA)
wm831x_rtc->alarm_enabled = 1;
@@ -459,9 +459,6 @@ static int wm831x_rtc_probe(struct platform_device *pdev)
wm831x_rtc_add_randomness(wm831x);
return 0;
-
-err:
- return ret;
}
static const struct dev_pm_ops wm831x_rtc_pm_ops = {
--
2.20.1
RE: [PATCH v4 6/6] dt-bindings: fpga: Add bindings for ZynqMP fpga driver
Ping!!
> -Original Message-
> From: Nava kishore Manne [mailto:nava.ma...@xilinx.com]
> Sent: Thursday, March 14, 2019 7:31 PM
> To: at...@kernel.org; m...@kernel.org; robh...@kernel.org;
> mark.rutl...@arm.com; Michal Simek ; Rajan Vaja
> ; Jolly Shah ; Nava kishore Manne
> ; linux-f...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> chinnikishore...@gmail.com
> Subject: [PATCH v4 6/6] dt-bindings: fpga: Add bindings for ZynqMP fpga driver
>
> Add documentation to describe Xilinx ZynqMP fpga driver bindings.
>
> Signed-off-by: Nava kishore Manne
> ---
> Changes for v4:
> -Modified binding description as suggested by Moritz Fischer.
> Changes for v3:
> -Removed PCAP as a child node to the FW and Created
>an independent node since PCAP driver is a consumer
>not a provider.
>
> .../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 11 +++
> 1 file changed, 11 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,zynqmp-
> pcap-fpga.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
> b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
> new file mode 100644
> index ..6d7f10775d9b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
> @@ -0,0 +1,11 @@
> +Devicetree bindings for Zynq Ultrascale MPSoC FPGA Manager.
> +The ZynqMP SoC uses the PCAP (Processor configuration Port) to
> +configure the Programmable Logic (PL). The configuration uses the firmware
> interface.
> +
> +Required properties:
> +- compatible: should contain "xlnx,zynqmp-pcap-fpga"
> +
> +Example:
> + zynqmp_pcap: pcap {
> + compatible = "xlnx,zynqmp-pcap-fpga";
> + };
> --
> 2.18.0
[PATCH 3/4] rtc: wm831x: switch to rtc_time64_to_tm/rtc_tm_to_time64
Call the 64bit versions of rtc_tm time conversion now that the range is
enforced by the core.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-wm831x.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c
index 1b0c3b3f63e8..d286dd1dfcf9 100644
--- a/drivers/rtc/rtc-wm831x.c
+++ b/drivers/rtc/rtc-wm831x.c
@@ -155,7 +155,7 @@ static int wm831x_rtc_readtime(struct device *dev, struct
rtc_time *tm)
if (memcmp(time1, time2, sizeof(time1)) == 0) {
u32 time = (time1[0] << 16) | time1[1];
- rtc_time_to_tm(time, tm);
+ rtc_time64_to_tm(time, tm);
return 0;
}
@@ -215,11 +215,7 @@ static int wm831x_rtc_set_mmss(struct device *dev,
unsigned long time)
if (ret < 0)
return ret;
- ret = rtc_tm_to_time(&new_tm, &new_time);
- if (ret < 0) {
- dev_err(dev, "Failed to convert time: %d\n", ret);
- return ret;
- }
+ new_time = rtc_tm_to_time64(&new_tm);
/* Allow a second of change in case of tick */
if (new_time - time > 1) {
@@ -249,7 +245,7 @@ static int wm831x_rtc_readalarm(struct device *dev, struct
rtc_wkalrm *alrm)
time = (data[0] << 16) | data[1];
- rtc_time_to_tm(time, &alrm->time);
+ rtc_time64_to_tm(time, &alrm->time);
ret = wm831x_reg_read(wm831x_rtc->wm831x, WM831X_RTC_CONTROL);
if (ret < 0) {
@@ -288,11 +284,7 @@ static int wm831x_rtc_setalarm(struct device *dev, struct
rtc_wkalrm *alrm)
int ret;
unsigned long time;
- ret = rtc_tm_to_time(&alrm->time, &time);
- if (ret < 0) {
- dev_err(dev, "Failed to convert time: %d\n", ret);
- return ret;
- }
+ time = rtc_tm_to_time64(&alrm->time);
ret = wm831x_rtc_stop_alarm(wm831x_rtc);
if (ret < 0) {
--
2.20.1
[PATCH 4/4] rtc: wm831x: convert to SPDX identifier
Use SPDX-License-Identifier instead of a verbose license text. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-wm831x.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-wm831x.c b/drivers/rtc/rtc-wm831x.c index d286dd1dfcf9..6a0defd16088 100644 --- a/drivers/rtc/rtc-wm831x.c +++ b/drivers/rtc/rtc-wm831x.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Real Time Clock driver for Wolfson Microelectronics WM831x * @@ -5,11 +6,6 @@ * * Author: Mark Brown * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License as published by the - * Free Software Foundation; either version 2 of the License, or (at your - * option) any later version. - * */ #include -- 2.20.1
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On 21/03/2019 18.02, Nick Desaulniers wrote: > On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton > wrote: >> > > Further, I can drop some of the __GNUC__ < 4 code in > arch/x86/include/asm/string_32.h. Already on its way to Linus: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=88ca66d8540ca26119b1428cddb96b37925bdf01 https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2e905c7abdcd5ff09b9df33d25eb7148c85bed2a
[PATCH 1/3] rtc: sun4v: switch to rtc_time64_to_tm/rtc_tm_to_time64
Call the 64bit versions of rtc_tm time conversion as the hypervisor handles
64bit values.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-sun4v.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-sun4v.c b/drivers/rtc/rtc-sun4v.c
index 11bc562eba5d..378081fffa91 100644
--- a/drivers/rtc/rtc-sun4v.c
+++ b/drivers/rtc/rtc-sun4v.c
@@ -39,7 +39,7 @@ static unsigned long hypervisor_get_time(void)
static int sun4v_read_time(struct device *dev, struct rtc_time *tm)
{
- rtc_time_to_tm(hypervisor_get_time(), tm);
+ rtc_time64_to_tm(hypervisor_get_time(), tm);
return 0;
}
@@ -66,14 +66,7 @@ static int hypervisor_set_time(unsigned long secs)
static int sun4v_set_time(struct device *dev, struct rtc_time *tm)
{
- unsigned long secs;
- int err;
-
- err = rtc_tm_to_time(tm, &secs);
- if (err)
- return err;
-
- return hypervisor_set_time(secs);
+ return hypervisor_set_time(rtc_tm_to_time64(tm));
}
static const struct rtc_class_ops sun4v_rtc_ops = {
--
2.20.1
[PATCH 3/3] rtc: sun4v: switch to SPDX identifier
Use SPDX-License-Identifier to be clearer on the license. Choose the v2 only as this is the default Linux license. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-sun4v.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-sun4v.c b/drivers/rtc/rtc-sun4v.c index 82fb51f79c6e..036463dfa103 100644 --- a/drivers/rtc/rtc-sun4v.c +++ b/drivers/rtc/rtc-sun4v.c @@ -1,7 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 /* rtc-sun4v.c: Hypervisor based RTC for SUN4V systems. * * Author: David S. Miller - * License: GPL * * Copyright (C) 2008 David S. Miller */ -- 2.20.1
[PATCH 2/3] rtc: sun4v: set range
The Sun4v Hypervisor Core API Specification states:
Time is described by a single unsigned 64-bit word equivalent to a time_t
for the POSIX time(2) system call. The word contains the time since the
Epoch (00:00:00 UTC, January 1, 1970), measured in seconds.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-sun4v.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-sun4v.c b/drivers/rtc/rtc-sun4v.c
index 378081fffa91..82fb51f79c6e 100644
--- a/drivers/rtc/rtc-sun4v.c
+++ b/drivers/rtc/rtc-sun4v.c
@@ -78,13 +78,15 @@ static int __init sun4v_rtc_probe(struct platform_device
*pdev)
{
struct rtc_device *rtc;
- rtc = devm_rtc_device_register(&pdev->dev, "sun4v",
- &sun4v_rtc_ops, THIS_MODULE);
+ rtc = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc))
return PTR_ERR(rtc);
+ rtc->ops = &sun4v_rtc_ops;
+ rtc->range_max = U64_MAX;
platform_set_drvdata(pdev, rtc);
- return 0;
+
+ return rtc_register_device(rtc);
}
static struct platform_driver sun4v_rtc_driver = {
--
2.20.1
Re: [PATCH v2] thunderbolt: Fix to check return value of ida_simple_get
On 3/21/2019 11:19 AM, Mika Westerberg wrote:
On Thu, Mar 21, 2019 at 02:09:41AM +0530, Mukesh Ojha wrote:
On 3/20/2019 9:59 PM, Mika Westerberg wrote:
On Wed, Mar 20, 2019 at 11:24:45AM -0500, Aditya Pakki wrote:
In enumerate_services, ida_simple_get on failure can return an error and
leaks memory during device_register failure. The patch ensures that
the dev_set_name is set on non failure cases, and releases memory in
case of failure.
Signed-off-by: Aditya Pakki
---
v1: Missed cleanup of svc in case of allocation failure and
device_register failure.
---
drivers/thunderbolt/xdomain.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/thunderbolt/xdomain.c b/drivers/thunderbolt/xdomain.c
index e27dd8beb94b..eb08275185bf 100644
--- a/drivers/thunderbolt/xdomain.c
+++ b/drivers/thunderbolt/xdomain.c
@@ -740,6 +740,7 @@ static void enumerate_services(struct tb_xdomain *xd)
struct tb_service *svc;
struct tb_property *p;
struct device *dev;
+ int id;
/*
* First remove all services that are not available anymore in
@@ -768,7 +769,12 @@ static void enumerate_services(struct tb_xdomain *xd)
break;
}
- svc->id = ida_simple_get(&xd->service_ids, 0, 0, GFP_KERNEL);
+ id = ida_simple_get(&xd->service_ids, 0, 0, GFP_KERNEL);
+ if (id < 0) {
+ kfree(svc);
+ break;
+ }
+ svc->id = id;
svc->dev.bus = &tb_bus_type;
svc->dev.type = &tb_service_type;
svc->dev.parent = &xd->dev;
@@ -776,6 +782,7 @@ static void enumerate_services(struct tb_xdomain *xd)
if (device_register(&svc->dev)) {
put_device(&svc->dev);
+ kfree(svc);
You can't do this after device_register() is called. The put_device()
above is sufficient.
If device_register fails, how would svc gets freed? we need to kfree svc
here as well.
Please read the comment on top of device_register(). It should explain.
So no kfree here.
Thanks for pointer Mika.
Overlooked the fact that dev is a data member of svc not a pointer, also
noticed there are many places in tree where , it is not
followed.
Thanks,
Mukesh
[PATCH 0/4] Provide generic top-down mmap layout functions
This series introduces generic functions to make top-down mmap layout easily accessible to architectures, in particular riscv which was the initial goal of this series. The generic implementation was taken from arm64 and used successively by arm, mips and finally riscv. Note that in addition the series fixes 2 issues: - stack randomization was taken into account even if not necessary. - [1] fixed an issue with mmap base which did not take into account randomization but did not report it to arm and mips, so by moving arm64 into a generic library, this problem is now fixed for both architectures. This work is an effort to factorize architecture functions to avoid code duplication and oversights as in [1]. [1]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html Alexandre Ghiti (4): arm64, mm: Move generic mmap layout functions to mm arm: Use generic mmap top-down layout mips: Use generic mmap top-down layout riscv: Make mmap allocation top-down by default arch/arm/include/asm/processor.h | 2 +- arch/arm/mm/mmap.c | 52 arch/arm64/include/asm/processor.h | 2 +- arch/arm64/mm/mmap.c | 72 -- arch/mips/include/asm/processor.h | 4 +- arch/mips/mm/mmap.c| 57 - arch/riscv/Kconfig | 12 arch/riscv/include/asm/processor.h | 1 + fs/binfmt_elf.c| 20 -- include/linux/mm.h | 2 + kernel/sysctl.c| 6 +- mm/util.c | 99 +- 12 files changed, 121 insertions(+), 208 deletions(-) -- 2.20.1
Re: [PATCH v4] lib/string.c: implement a basic bcmp
On Fri, Mar 22, 2019 at 8:17 AM Rasmus Villemoes wrote: > > On 21/03/2019 18.02, Nick Desaulniers wrote: > > On Wed, Mar 20, 2019 at 7:11 PM Andrew Morton > > wrote: > >> > > > > Further, I can drop some of the __GNUC__ < 4 code in > > arch/x86/include/asm/string_32.h. > > Already on its way to Linus: > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=88ca66d8540ca26119b1428cddb96b37925bdf01 > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=2e905c7abdcd5ff09b9df33d25eb7148c85bed2a > Upstream: "x86/asm: Remove dead __GNUC__ conditionals" https://git.kernel.org/linus/88ca66d8540ca26119b1428cddb96b37925bdf01 "x86/asm: Remove unused __constant_c_x_memset() macro and inlines" https://git.kernel.org/linus/2e905c7abdcd5ff09b9df33d25eb7148c85bed2a - Sedat -
Re: [PATCHv2] x86/boot/KASLR: skip the specified crashkernel reserved region
On Wed, Mar 20, 2019 at 8:25 AM Baoquan He wrote:
>
> Please change subject as:
>
> "x86/boot/KASLR: skip the specified crashkernel region"
>
OK.
> Don't see why reserved is needed here.
>
> On 03/13/19 at 12:19pm, Pingfan Liu wrote:
> > crashkernel=x@y option may fail to reserve the required memory region if
> > KASLR puts kernel into the region. To avoid this uncertainty, making KASLR
> > skip the required region.
> >
> > Signed-off-by: Pingfan Liu
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: Borislav Petkov
> > Cc: "H. Peter Anvin"
> > Cc: Baoquan He
> > Cc: Will Deacon
> > Cc: Nicolas Pitre
> > Cc: Pingfan Liu
> > Cc: Chao Fan
> > Cc: "Kirill A. Shutemov"
> > Cc: Ard Biesheuvel
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > v1 -> v2: fix some trival format
> >
> > arch/x86/boot/compressed/kaslr.c | 26 --
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/kaslr.c
> > b/arch/x86/boot/compressed/kaslr.c
> > index 9ed9709..e185318 100644
> > --- a/arch/x86/boot/compressed/kaslr.c
> > +++ b/arch/x86/boot/compressed/kaslr.c
> > @@ -109,6 +109,7 @@ enum mem_avoid_index {
> > MEM_AVOID_BOOTPARAMS,
> > MEM_AVOID_MEMMAP_BEGIN,
> > MEM_AVOID_MEMMAP_END = MEM_AVOID_MEMMAP_BEGIN + MAX_MEMMAP_REGIONS -
> > 1,
> > + MEM_AVOID_CRASHKERNEL,
> > MEM_AVOID_MAX,
> > };
> >
> > @@ -240,6 +241,25 @@ static void parse_gb_huge_pages(char *param, char *val)
> > }
> > }
> >
> > +/* parse crashkernel=x@y option */
> > +static void mem_avoid_crashkernel_simple(char *option)
>
> Chao ever mentioned this, I want to ask again, why does it has to be
> xxx_simple()?
>
Seems that I had replied Chao's question in another email. The naming
follows the function parse_crashkernel_simple(), as the notes above
the definition
/*
* That function parses "simple" (old) crashkernel command lines like
*
* crashkernel=size[@offset]
*
* It returns 0 on success and -EINVAL on failure.
*/
static int __init parse_crashkernel_simple(char *cmdline,
Do you have alternative suggestion?
> Except of these, patch looks good to me. It's a nice catch, and only
> need a simple fix based on the current code.
>
Thank you for the kindly review.
Regards,
Pingfan
> Thanks
> Baoquan
>
> > +{
> > + unsigned long long crash_size, crash_base;
> > + char *cur = option;
> > +
> > + crash_size = memparse(option, &cur);
> > + if (option == cur)
> > + return;
> > +
> > + if (*cur == '@') {
> > + option = cur + 1;
> > + crash_base = memparse(option, &cur);
> > + if (option == cur)
> > + return;
> > + mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
> > + mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
> > + }
> > +}
> >
> > static void handle_mem_options(void)
> > {
> > @@ -250,7 +270,7 @@ static void handle_mem_options(void)
> > u64 mem_size;
> >
> > if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
> > - !strstr(args, "hugepages"))
> > + !strstr(args, "hugepages") && !strstr(args, "crashkernel="))
> > return;
> >
> > tmp_cmdline = malloc(len + 1);
> > @@ -286,6 +306,8 @@ static void handle_mem_options(void)
> > goto out;
> >
> > mem_limit = mem_size;
> > + } else if (strstr(param, "crashkernel")) {
> > + mem_avoid_crashkernel_simple(val);
> > }
> > }
> >
> > @@ -414,7 +436,7 @@ static void mem_avoid_init(unsigned long input,
> > unsigned long input_size,
> >
> > /* We don't need to set a mapping for setup_data. */
> >
> > - /* Mark the memmap regions we need to avoid */
> > + /* Mark the regions we need to avoid */
> > handle_mem_options();
> >
> > #ifdef CONFIG_X86_VERBOSE_BOOTUP
> > --
> > 2.7.4
> >
[PATCH 1/4] arm64, mm: Move generic mmap layout functions to mm
arm64 handles top-down mmap layout in a way that can be easily reused
by other architectures, so make it available in mm.
This commit also takes the opportunity to:
- make use of is_compat_task instead of specific arm64 test
test_thread_flag(TIF_32BIT), which allows more genericity and is
equivalent.
- fix the case where stack randomization should not be taken into
account.
It then introduces a new define ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
that can be defined by other architectures to benefit from those functions.
Suggested-by: Christoph Hellwig
Signed-off-by: Alexandre Ghiti
---
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/mm/mmap.c | 72 --
fs/binfmt_elf.c| 20 --
include/linux/mm.h | 2 +
kernel/sysctl.c| 6 +-
mm/util.c | 99 +-
6 files changed, 105 insertions(+), 96 deletions(-)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index 5d9ce62bdebd..2358707c31ff 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -274,7 +274,7 @@ static inline void spin_lock_prefetch(const void *ptr)
"nop") : : "p" (ptr));
}
-#define HAVE_ARCH_PICK_MMAP_LAYOUT
+#define ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
#endif
diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
index 842c8a5fcd53..c74224421216 100644
--- a/arch/arm64/mm/mmap.c
+++ b/arch/arm64/mm/mmap.c
@@ -31,78 +31,6 @@
#include
-/*
- * Leave enough space between the mmap area and the stack to honour ulimit in
- * the face of randomisation.
- */
-#define MIN_GAP (SZ_128M)
-#define MAX_GAP(STACK_TOP/6*5)
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (rlim_stack->rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
-unsigned long arch_mmap_rnd(void)
-{
- unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
- if (test_thread_flag(TIF_32BIT))
- rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
- else
-#endif
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
- return rnd << PAGE_SHIFT;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
- unsigned long gap = rlim_stack->rlim_cur;
- unsigned long pad = (STACK_RND_MASK << PAGE_SHIFT) + stack_guard_gap;
-
- /* Values close to RLIM_INFINITY can overflow. */
- if (gap + pad > gap)
- gap += pad;
-
- if (gap < MIN_GAP)
- gap = MIN_GAP;
- else if (gap > MAX_GAP)
- gap = MAX_GAP;
-
- return PAGE_ALIGN(STACK_TOP - gap - rnd);
-}
-
-/*
- * This function, called very early during the creation of a new process VM
- * image, sets up which VM layout function to use:
- */
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
- unsigned long random_factor = 0UL;
-
- if (current->flags & PF_RANDOMIZE)
- random_factor = arch_mmap_rnd();
-
- /*
-* Fall back to the standard layout if the personality bit is set, or
-* if the expected stack growth is unlimited:
-*/
- if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
- mm->get_unmapped_area = arch_get_unmapped_area;
- } else {
- mm->mmap_base = mmap_base(random_factor, rlim_stack);
- mm->get_unmapped_area = arch_get_unmapped_area_topdown;
- }
-}
-
/*
* You really shouldn't be using read() or write() on /dev/mem. This might go
* away in the future.
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 7d09d125f148..045f3b29d264 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -662,26 +662,6 @@ static unsigned long load_elf_interp(struct elfhdr
*interp_elf_ex,
* libraries. There is no binary dependent code anywhere else.
*/
-#ifndef STACK_RND_MASK
-#define STACK_RND_MASK (0x7ff >> (PAGE_SHIFT - 12))/* 8MB of VA */
-#endif
-
-static unsigned long randomize_stack_top(unsigned long stack_top)
-{
- unsigned long random_variable = 0;
-
- if (current->flags & PF_RANDOMIZE) {
- random_variable = get_random_long();
- random_variable &= STACK_RND_MASK;
- random_variable <<= PAGE_SHIFT;
- }
-#ifdef CONFIG_STACK_GROWSUP
- return PAGE_ALIGN(stack_top) + random_variable;
-#else
- return PAGE_ALIGN(stack_top) - random_variable;
-#endif
-}
-
static int load_elf_binary(struct linux_binprm *bprm)
{
struct file *interpreter = NULL; /* to shut gcc up */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 76769749b5a5..087824a5059f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -23
[PATCH 2/4] arm: Use generic mmap top-down layout
arm uses a top-down layout by default that fits the generic functions. At the same time, this commit allows to fix the following problems: - one uncovered and not fixed for arm here: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html - the use of TASK_SIZE instead of STACK_TOP in mmap_base which, when address space of a task is 26 bits, would assign mmap base way too high. Signed-off-by: Alexandre Ghiti --- arch/arm/include/asm/processor.h | 2 +- arch/arm/mm/mmap.c | 52 2 files changed, 1 insertion(+), 53 deletions(-) diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h index 57fe73ea0f72..03837d325a2f 100644 --- a/arch/arm/include/asm/processor.h +++ b/arch/arm/include/asm/processor.h @@ -143,7 +143,7 @@ static inline void prefetchw(const void *ptr) #endif #endif -#define HAVE_ARCH_PICK_MMAP_LAYOUT +#define ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT #endif diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c index f866870db749..b8d912ac9e61 100644 --- a/arch/arm/mm/mmap.c +++ b/arch/arm/mm/mmap.c @@ -17,33 +17,6 @@ addr)+SHMLBA-1)&~(SHMLBA-1)) + \ (((pgoff)rlim_cur == RLIM_INFINITY) - return 1; - - return sysctl_legacy_va_layout; -} - -static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack) -{ - unsigned long gap = rlim_stack->rlim_cur; - - if (gap < MIN_GAP) - gap = MIN_GAP; - else if (gap > MAX_GAP) - gap = MAX_GAP; - - return PAGE_ALIGN(TASK_SIZE - gap - rnd); -} - /* * We need to ensure that shared mappings are correctly aligned to * avoid aliasing issues with VIPT caches. We need to ensure that @@ -171,31 +144,6 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, return addr; } -unsigned long arch_mmap_rnd(void) -{ - unsigned long rnd; - - rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1); - - return rnd << PAGE_SHIFT; -} - -void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack) -{ - unsigned long random_factor = 0UL; - - if (current->flags & PF_RANDOMIZE) - random_factor = arch_mmap_rnd(); - - if (mmap_is_legacy(rlim_stack)) { - mm->mmap_base = TASK_UNMAPPED_BASE + random_factor; - mm->get_unmapped_area = arch_get_unmapped_area; - } else { - mm->mmap_base = mmap_base(random_factor, rlim_stack); - mm->get_unmapped_area = arch_get_unmapped_area_topdown; - } -} - /* * You really shouldn't be using read() or write() on /dev/mem. This * might go away in the future. -- 2.20.1
[PATCH 3/4] mips: Use generic mmap top-down layout
mips uses a top-down layout by default that fits the generic functions.
At the same time, this commit allows to fix problem uncovered
and not fixed for mips here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1429066.html
Signed-off-by: Alexandre Ghiti
---
arch/mips/include/asm/processor.h | 4 +--
arch/mips/mm/mmap.c | 57 ---
2 files changed, 2 insertions(+), 59 deletions(-)
diff --git a/arch/mips/include/asm/processor.h
b/arch/mips/include/asm/processor.h
index aca909bd7841..f8e04962b52d 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -30,9 +30,9 @@
extern unsigned int vced_count, vcei_count;
/*
- * MIPS does have an arch_pick_mmap_layout()
+ * MIPS uses the default implementation of topdown mmap layout.
*/
-#define HAVE_ARCH_PICK_MMAP_LAYOUT 1
+#define ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
#ifdef CONFIG_32BIT
#ifdef CONFIG_KVM_GUEST
diff --git a/arch/mips/mm/mmap.c b/arch/mips/mm/mmap.c
index 2f616ebeb7e0..61e65a69bb09 100644
--- a/arch/mips/mm/mmap.c
+++ b/arch/mips/mm/mmap.c
@@ -20,33 +20,6 @@
unsigned long shm_align_mask = PAGE_SIZE - 1; /* Sane caches */
EXPORT_SYMBOL(shm_align_mask);
-/* gap between mmap and stack */
-#define MIN_GAP (128*1024*1024UL)
-#define MAX_GAP ((TASK_SIZE)/6*5)
-
-static int mmap_is_legacy(struct rlimit *rlim_stack)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (rlim_stack->rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
-static unsigned long mmap_base(unsigned long rnd, struct rlimit *rlim_stack)
-{
- unsigned long gap = rlim_stack->rlim_cur;
-
- if (gap < MIN_GAP)
- gap = MIN_GAP;
- else if (gap > MAX_GAP)
- gap = MAX_GAP;
-
- return PAGE_ALIGN(TASK_SIZE - gap - rnd);
-}
-
#define COLOUR_ALIGN(addr, pgoff) \
addr) + shm_align_mask) & ~shm_align_mask) +\
(((pgoff) << PAGE_SHIFT) & shm_align_mask))
@@ -144,36 +117,6 @@ unsigned long arch_get_unmapped_area_topdown(struct file
*filp,
addr0, len, pgoff, flags, DOWN);
}
-unsigned long arch_mmap_rnd(void)
-{
- unsigned long rnd;
-
-#ifdef CONFIG_COMPAT
- if (TASK_IS_32BIT_ADDR)
- rnd = get_random_long() & ((1UL << mmap_rnd_compat_bits) - 1);
- else
-#endif /* CONFIG_COMPAT */
- rnd = get_random_long() & ((1UL << mmap_rnd_bits) - 1);
-
- return rnd << PAGE_SHIFT;
-}
-
-void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
-{
- unsigned long random_factor = 0UL;
-
- if (current->flags & PF_RANDOMIZE)
- random_factor = arch_mmap_rnd();
-
- if (mmap_is_legacy(rlim_stack)) {
- mm->mmap_base = TASK_UNMAPPED_BASE + random_factor;
- mm->get_unmapped_area = arch_get_unmapped_area;
- } else {
- mm->mmap_base = mmap_base(random_factor, rlim_stack);
- mm->get_unmapped_area = arch_get_unmapped_area_topdown;
- }
-}
-
static inline unsigned long brk_rnd(void)
{
unsigned long rnd = get_random_long();
--
2.20.1
[PATCH 4/4] riscv: Make mmap allocation top-down by default
In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 16f000-17 rw-p 00:00 0 17-172000 r-xp 00:00 0 [vdso] 174000-176000 rw-p 00:00 0 176000-1555674000 r-xp fe:00 7187 /lib/libc-2.28.so 1555674000-1555678000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so 1555678000-155567a000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so 155567a000-15556a rw-p 00:00 0 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] After: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils 00018000-00039000 rw-p 00:00 0 [heap] 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 3ff7ed8000-3ff7fd6000 r-xp fe:00 7187 /lib/libc-2.28.so 3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so 3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so 3ff7fdc000-3ff7fe2000 rw-p 00:00 0 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] 3ff7fe6000-3ff7ffd000 r-xp fe:00 7193 /lib/ld-2.28.so 3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so 3ff7fff000-3ff800 rw-p 00:00 0 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] Signed-off-by: Alexandre Ghiti --- arch/riscv/Kconfig | 12 arch/riscv/include/asm/processor.h | 1 + 2 files changed, 13 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index eb56c82d8aa1..7661335d1667 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -50,6 +50,18 @@ config RISCV select ARCH_HAS_PTE_SPECIAL select HAVE_EBPF_JIT if 64BIT +config HAVE_ARCH_MMAP_RND_BITS + def_bool y + +config ARCH_MMAP_RND_BITS_MIN + default 18 + +# max bits determined by the following formula: +# VA_BITS - PAGE_SHIFT - 3 +config ARCH_MMAP_RND_BITS_MAX + default 33 if 64BIT # SV48 based + default 18 + config MMU def_bool y diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h index ce70bceb8872..e68a1b1e144a 100644 --- a/arch/riscv/include/asm/processor.h +++ b/arch/riscv/include/asm/processor.h @@ -23,6 +23,7 @@ * space during mmap's. */ #define TASK_UNMAPPED_BASE PAGE_ALIGN(TASK_SIZE / 3) +#define ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT #define STACK_TOP TASK_SIZE #define STACK_TOP_MAX STACK_TOP -- 2.20.1
Re: [PATCHv2] x86/boot/KASLR: skip the specified crashkernel reserved region
On Thu, Mar 21, 2019 at 2:38 PM Chao Fan wrote:
>
> On Wed, Mar 13, 2019 at 12:19:31PM +0800, Pingfan Liu wrote:
>
> I tested it in Qemu test with 12G memory, and set crashkernel=6G@6G.
> Without this PATCH, it successed to reserve memory just 4 times(total
> 10 times).
> With this PATCH, it successed to reserve memory 15 times(total 15
> times).
>
> So I think if you post new version, you can add:
>
> Tested-by: Chao Fan
>
Appreciate for your testing. I had done some test on a real machine
with a private patch to narrow down the KASLR range. I think your test
method is more simple and I will add the tested-by you.
Regards,
Pingfan
> Thanks,
> Chao Fan
>
> >crashkernel=x@y option may fail to reserve the required memory region if
> >KASLR puts kernel into the region. To avoid this uncertainty, making KASLR
> >skip the required region.
> >
> >Signed-off-by: Pingfan Liu
> >Cc: Thomas Gleixner
> >Cc: Ingo Molnar
> >Cc: Borislav Petkov
> >Cc: "H. Peter Anvin"
> >Cc: Baoquan He
> >Cc: Will Deacon
> >Cc: Nicolas Pitre
> >Cc: Pingfan Liu
> >Cc: Chao Fan
> >Cc: "Kirill A. Shutemov"
> >Cc: Ard Biesheuvel
> >Cc: linux-kernel@vger.kernel.org
> >---
> >v1 -> v2: fix some trival format
> >
> > arch/x86/boot/compressed/kaslr.c | 26 --
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/x86/boot/compressed/kaslr.c
> >b/arch/x86/boot/compressed/kaslr.c
> >index 9ed9709..e185318 100644
> >--- a/arch/x86/boot/compressed/kaslr.c
> >+++ b/arch/x86/boot/compressed/kaslr.c
> >@@ -109,6 +109,7 @@ enum mem_avoid_index {
> > MEM_AVOID_BOOTPARAMS,
> > MEM_AVOID_MEMMAP_BEGIN,
> > MEM_AVOID_MEMMAP_END = MEM_AVOID_MEMMAP_BEGIN + MAX_MEMMAP_REGIONS -
> > 1,
> >+ MEM_AVOID_CRASHKERNEL,
> > MEM_AVOID_MAX,
> > };
> >
> >@@ -240,6 +241,25 @@ static void parse_gb_huge_pages(char *param, char *val)
> > }
> > }
> >
> >+/* parse crashkernel=x@y option */
> >+static void mem_avoid_crashkernel_simple(char *option)
> >+{
> >+ unsigned long long crash_size, crash_base;
> >+ char *cur = option;
> >+
> >+ crash_size = memparse(option, &cur);
> >+ if (option == cur)
> >+ return;
> >+
> >+ if (*cur == '@') {
> >+ option = cur + 1;
> >+ crash_base = memparse(option, &cur);
> >+ if (option == cur)
> >+ return;
> >+ mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
> >+ mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
> >+ }
> >+}
> >
> > static void handle_mem_options(void)
> > {
> >@@ -250,7 +270,7 @@ static void handle_mem_options(void)
> > u64 mem_size;
> >
> > if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
> >- !strstr(args, "hugepages"))
> >+ !strstr(args, "hugepages") && !strstr(args, "crashkernel="))
> > return;
> >
> > tmp_cmdline = malloc(len + 1);
> >@@ -286,6 +306,8 @@ static void handle_mem_options(void)
> > goto out;
> >
> > mem_limit = mem_size;
> >+ } else if (strstr(param, "crashkernel")) {
> >+ mem_avoid_crashkernel_simple(val);
> > }
> > }
> >
> >@@ -414,7 +436,7 @@ static void mem_avoid_init(unsigned long input, unsigned
> >long input_size,
> >
> > /* We don't need to set a mapping for setup_data. */
> >
> >- /* Mark the memmap regions we need to avoid */
> >+ /* Mark the regions we need to avoid */
> > handle_mem_options();
> >
> > #ifdef CONFIG_X86_VERBOSE_BOOTUP
> >--
> >2.7.4
> >
> >
> >
>
>
[PATCH] rtc: Fix timestamp value for RTC_TIMESTAMP_BEGIN_1900
Printing "mktime64(1900, 1, 1, 0, 0, 0)" gives -2208988800.
Fixes: 83bbc5ac63326433 ("rtc: Add useful timestamp definitions")
Signed-off-by: Geert Uytterhoeven
---
include/linux/rtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 588120ba372cda57..f3553b7da4d0bd20 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -162,7 +162,7 @@ struct rtc_device {
#define to_rtc_device(d) container_of(d, struct rtc_device, dev)
/* useful timestamps */
-#define RTC_TIMESTAMP_BEGIN_1900 -2208989361LL /* 1900-01-01 00:00:00 */
+#define RTC_TIMESTAMP_BEGIN_1900 -2208988800LL /* 1900-01-01 00:00:00 */
#define RTC_TIMESTAMP_BEGIN_2000 946684800LL /* 2000-01-01 00:00:00 */
#define RTC_TIMESTAMP_END_2099 4102444799LL /* 2099-12-31 23:59:59 */
#define RTC_TIMESTAMP_END_ 253402300799LL /* -12-31 23:59:59 */
--
2.17.1
Re: [PATCHv2] x86/boot/KASLR: skip the specified crashkernel reserved region
On 03/22/19 at 03:43pm, Pingfan Liu wrote:
> > > +/* parse crashkernel=x@y option */
> > > +static void mem_avoid_crashkernel_simple(char *option)
> >
> > Chao ever mentioned this, I want to ask again, why does it has to be
> > xxx_simple()?
> >
> Seems that I had replied Chao's question in another email. The naming
> follows the function parse_crashkernel_simple(), as the notes above
Sorry, I don't get. typo?
> the definition
> /*
> * That function parses "simple" (old) crashkernel command lines like
> *
> * crashkernel=size[@offset]
Hmm, should only crashkernel=size@offset be cared? crashkernel=size will
auto finding a place to reserve, and that is after KASLR.
> *
> * It returns 0 on success and -EINVAL on failure.
> */
> static int __init parse_crashkernel_simple(char *cmdline,
>
> Do you have alternative suggestion?
>
> > Except of these, patch looks good to me. It's a nice catch, and only
> > need a simple fix based on the current code.
> >
> Thank you for the kindly review.
>
> Regards,
> Pingfan
>
> > Thanks
> > Baoquan
> >
> > > +{
> > > + unsigned long long crash_size, crash_base;
> > > + char *cur = option;
> > > +
> > > + crash_size = memparse(option, &cur);
> > > + if (option == cur)
> > > + return;
> > > +
> > > + if (*cur == '@') {
> > > + option = cur + 1;
> > > + crash_base = memparse(option, &cur);
> > > + if (option == cur)
> > > + return;
> > > + mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
> > > + mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
> > > + }
> > > +}
> > >
> > > static void handle_mem_options(void)
> > > {
> > > @@ -250,7 +270,7 @@ static void handle_mem_options(void)
> > > u64 mem_size;
> > >
> > > if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
> > > - !strstr(args, "hugepages"))
> > > + !strstr(args, "hugepages") && !strstr(args, "crashkernel="))
> > > return;
> > >
> > > tmp_cmdline = malloc(len + 1);
> > > @@ -286,6 +306,8 @@ static void handle_mem_options(void)
> > > goto out;
> > >
> > > mem_limit = mem_size;
> > > + } else if (strstr(param, "crashkernel")) {
> > > + mem_avoid_crashkernel_simple(val);
> > > }
> > > }
> > >
> > > @@ -414,7 +436,7 @@ static void mem_avoid_init(unsigned long input,
> > > unsigned long input_size,
> > >
> > > /* We don't need to set a mapping for setup_data. */
> > >
> > > - /* Mark the memmap regions we need to avoid */
> > > + /* Mark the regions we need to avoid */
> > > handle_mem_options();
> > >
> > > #ifdef CONFIG_X86_VERBOSE_BOOTUP
> > > --
> > > 2.7.4
> > >
Re: [PATCH] virt: vbox: Implement passing requestor info to the host for VirtualBox 6.0.x
Hi,
On 20-03-19 19:26, Greg Kroah-Hartman wrote:
On Wed, Mar 20, 2019 at 10:35:19AM +0100, Hans de Goede wrote:
diff --git a/drivers/virt/vboxguest/vboxguest_version.h
b/drivers/virt/vboxguest/vboxguest_version.h
index 77f0c8f8a231..84834dad38d5 100644
--- a/drivers/virt/vboxguest/vboxguest_version.h
+++ b/drivers/virt/vboxguest/vboxguest_version.h
@@ -9,11 +9,10 @@
#ifndef __VBOX_VERSION_H__
#define __VBOX_VERSION_H__
-/* Last synced October 4th 2017 */
We don't care about the date sync anymore?
I did not sync with the latest version, I've picked
the svn revision number from the 6.0.0 release
(6.0.4 is out now) in case one of the 6.0.x releases
have introduced something new which we do not implement
yet.
-#define VBG_VERSION_MAJOR 5
-#define VBG_VERSION_MINOR 2
+#define VBG_VERSION_MAJOR 6
+#define VBG_VERSION_MINOR 0
#define VBG_VERSION_BUILD 0
-#define VBG_SVN_REV 68940
-#define VBG_VERSION_STRING "5.2.0"
+#define VBG_SVN_REV 127566
+#define VBG_VERSION_STRING "6.0.0"
Do we really need to keep track of this?
Unfortunately yes, last time I checked the host has
some code checking the VBG_SVN_REV to determine whether
or not to apply some bug workaround.
#endif
diff --git a/drivers/virt/vboxguest/vmmdev.h b/drivers/virt/vboxguest/vmmdev.h
index 5e2ae978935d..6337b8d75d96 100644
--- a/drivers/virt/vboxguest/vmmdev.h
+++ b/drivers/virt/vboxguest/vmmdev.h
@@ -98,8 +98,8 @@ struct vmmdev_request_header {
s32 rc;
/** Reserved field no.1. MBZ. */
u32 reserved1;
- /** Reserved field no.2. MBZ. */
- u32 reserved2;
+ /** IN: Requestor information (VMMDEV_REQUESTOR_*) */
+ u32 requestor;
They didn't use the first reserved field? Oh well :(
There is another header for a hgcm-call which partly mirrors
this one and there they are using reserved1, I think it has
something to do with this.
--- a/include/uapi/linux/vbox_vmmdev_types.h
+++ b/include/uapi/linux/vbox_vmmdev_types.h
@@ -102,6 +102,37 @@ enum vmmdev_request_type {
#define VMMDEVREQ_HGCM_CALL VMMDEVREQ_HGCM_CALL32
#endif
+/* vmmdev_request_header.requestor defines */
+
+/* Requestor user not given. */
+#define VMMDEV_REQUESTOR_USR_NOT_GIVEN 0x
+/* The kernel driver (VBoxGuest) is the requestor. */
+#define VMMDEV_REQUESTOR_USR_DRV0x0001
+/* Some other kernel driver is the requestor. */
+#define VMMDEV_REQUESTOR_USR_DRV_OTHER 0x0002
+/* The root or a admin user is the requestor. */
+#define VMMDEV_REQUESTOR_USR_ROOT 0x0003
+/* Regular joe user is making the request. */
+#define VMMDEV_REQUESTOR_USR_USER 0x0006
+/* User classification mask. */
+#define VMMDEV_REQUESTOR_USR_MASK 0x0007
+/* Kernel mode request. */
+#define VMMDEV_REQUESTOR_KERNEL 0x
Wait, isn't that the same as VMMDEV_REQUESTOR_USR_NOT_GIVEN?
The call coming directly from the call, rather then through the
/dev/vboxguest or /dev/vboxuser devices is indicated by the
lack of the VMMDEV_REQUESTOR_USERMODE bit. I will add a
#define VMMDEV_REQUESTOR_MODE_MASK 0x0008
To make this more clear for v2 and add blank lines to group the different
items together per mask.
+/* User mode request. */
+#define VMMDEV_REQUESTOR_USERMODE 0x0008
+/* Don't know the physical console association of the requestor. */
+#define VMMDEV_REQUESTOR_CON_DONT_KNOW 0x
And here, why is this number recycled?
VMMDEV_REQUESTOR_USR_NOT_GIVEN (the first 0x000 define) is part of the
which user made this call mask: VMMDEV_REQUESTOR_USR_MASK, this is part
of the is the user behind the physical console info mask:
VMMDEV_REQUESTOR_CON_MASK
I've omitted the other defines since we are not using them, I will add
them to make this more clear.
+/* Console classification mask. */
+#define VMMDEV_REQUESTOR_CON_MASK 0x0040
+/* Requestor is member of special VirtualBox user group. */
+#define VMMDEV_REQUESTOR_GRP_VBOX 0x0080
Can you add a blank line here to make it more obvious it is "TRUST"
stuff here?
Ack.
+/* Requestor trust level: Unspecified */
+#define VMMDEV_REQUESTOR_TRUST_NOT_GIVEN0x
+/* Requestor trust level mask */
+#define VMMDEV_REQUESTOR_TRUST_MASK 0x7000
So those bits are the "trust" values?
Right, again I did not add defines for values we do not use under Linux
(this value comes from some Windows authentication mechanism, so under Linux
it is always VMMDEV_REQUESTOR_TRUST_NOT_GIVEN)
that's odd, oh well, it's their api, not ours :(
+/* Requestor is using the less trusted user device node (/dev/vboxuser) */
+#define VMMDEV_REQUESTOR_USER_DEVICE0x8000
Wait, what is this f
Re:
> On Mar 21, 2019, at 5:04 PM, Maxim Levitsky wrote: > > On Thu, 2019-03-21 at 16:41 +, Felipe Franciosi wrote: >>> On Mar 21, 2019, at 4:21 PM, Keith Busch wrote: >>> >>> On Thu, Mar 21, 2019 at 04:12:39PM +, Stefan Hajnoczi wrote: mdev-nvme seems like a duplication of SPDK. The performance is not better and the features are more limited, so why focus on this approach? One argument might be that the kernel NVMe subsystem wants to offer this functionality and loading the kernel module is more convenient than managing SPDK to some users. Thoughts? >>> >>> Doesn't SPDK bind a controller to a single process? mdev binds to >>> namespaces (or their partitions), so you could have many mdev's assigned >>> to many VMs accessing a single controller. >> >> Yes, it binds to a single process which can drive the datapath of multiple >> virtual controllers for multiple VMs (similar to what you described for >> mdev). >> You can therefore efficiently poll multiple VM submission queues (and >> multiple >> device completion queues) from a single physical CPU. >> >> The same could be done in the kernel, but the code gets complicated as you >> add >> more functionality to it. As this is a direct interface with an untrusted >> front-end (the guest), it's also arguably safer to do in userspace. >> >> Worth noting: you can eventually have a single physical core polling all >> sorts >> of virtual devices (eg. virtual storage or network controllers) very >> efficiently. And this is quite configurable, too. In the interest of >> fairness, >> performance or efficiency, you can choose to dynamically add or remove queues >> to the poll thread or spawn more threads and redistribute the work. >> >> F. > > Note though that SPDK doesn't support sharing the device between host and the > guests, it takes over the nvme device, thus it makes the kernel nvme driver > unbind from it. That is absolutely true. However, I find it not to be a problem in practice. Hypervisor products, specially those caring about performance, efficiency and fairness, will dedicate NVMe devices for a particular purpose (eg. vDisk storage, cache, metadata) and will not share these devices for other use cases. That's because these products want to deterministically control the performance aspects of the device, which you just cannot do if you are sharing the device with a subsystem you do not control. For scenarios where the device must be shared and such fine grained control is not required, it looks like using the kernel driver with io_uring offers very good performance with flexibility. Cheers, Felipe
KASAN: use-after-free Read in addr_resolve
Hello, syzbot found the following crash on: HEAD commit:54c49016 Merge tag 'arc-5.1-rc2' of git://git.kernel.org/p.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16a8323b20 kernel config: https://syzkaller.appspot.com/x/.config?x=9a31fb246de2a622 dashboard link: https://syzkaller.appspot.com/bug?extid=bd034f3fdc0402e942ed compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+bd034f3fdc0402e94...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in addr_resolve+0x14f7/0x1730 drivers/infiniband/core/addr.c:561 Read of size 8 at addr 88809dafeed0 by task kworker/u4:4/2568 CPU: 0 PID: 2568 Comm: kworker/u4:4 Not tainted 5.1.0-rc1+ #31 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: ib_addr process_one_req Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 addr_resolve+0x14f7/0x1730 drivers/infiniband/core/addr.c:561 process_one_req+0x31f/0x680 drivers/infiniband/core/addr.c:628 process_one_work+0x98e/0x1790 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x357/0x430 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Allocated by task 17026: save_stack+0x45/0xd0 mm/kasan/common.c:75 set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc mm/kasan/common.c:497 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:511 kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3621 kmalloc include/linux/slab.h:545 [inline] kzalloc include/linux/slab.h:740 [inline] __rdma_create_id+0x5f/0x4e0 drivers/infiniband/core/cma.c:878 ucma_create_id+0x1de/0x640 drivers/infiniband/core/ucma.c:506 ucma_write+0x2da/0x3c0 drivers/infiniband/core/ucma.c:1696 __vfs_write+0x8d/0x110 fs/read_write.c:485 vfs_write+0x20c/0x580 fs/read_write.c:549 ksys_write+0xea/0x1f0 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 17025: save_stack+0x45/0xd0 mm/kasan/common.c:75 set_track mm/kasan/common.c:87 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459 kasan_slab_free+0xe/0x10 mm/kasan/common.c:467 __cache_free mm/slab.c:3498 [inline] kfree+0xcf/0x230 mm/slab.c:3821 rdma_destroy_id+0x719/0xaa0 drivers/infiniband/core/cma.c:1852 ucma_close+0x115/0x320 drivers/infiniband/core/ucma.c:1777 __fput+0x2e5/0x8d0 fs/file_table.c:278 fput+0x16/0x20 fs/file_table.c:309 task_work_run+0x14a/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] syscall_return_slowpath arch/x86/entry/common.c:268 [inline] do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 88809dafed40 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 400 bytes inside of 2048-byte region [88809dafed40, 88809daff540) The buggy address belongs to the page: page:ea000276bf80 count:1 mapcount:0 mapping:88812c3f0c40 index:0x0 compound_mapcount: 0 flags: 0x1fffc010200(slab|head) raw: 01fffc010200 ea000172c108 ea000173a288 88812c3f0c40 raw: 88809dafe4c0 00010003 page dumped because: kasan: bad access detected Memory state around the buggy address: 88809dafed80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88809dafee00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88809dafee80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 88809dafef00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88809dafef80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[PATCH v2] virt: vbox: Implement passing requestor info to the host for VirtualBox 6.0.x
VirtualBox 6.0.x has a new feature where the guest kernel driver passes info about the origin of the request (e.g. userspace or kernelspace) to the hypervisor. If we do not pass this information then when running the 6.0.x userspace guest-additions tools on a 6.0.x host, some requests will get denied with a VERR_VERSION_MISMATCH error, breaking vboxservice.service and the mounting of shared folders marked to be auto-mounted. This commit implements passing the requestor info to the host, fixing this. Signed-off-by: Hans de Goede --- Changes in v2: -Improve VMMDEV_REQUESTOR_* define comments and add a few VMMDEV_REQUESTOR_*_MASK defines to make it sure that some bits are to be be checked as a group with a mask (while other bits are individual booleans) -Drop Cc: stable --- drivers/virt/vboxguest/vboxguest_core.c| 106 ++--- drivers/virt/vboxguest/vboxguest_core.h| 15 +-- drivers/virt/vboxguest/vboxguest_linux.c | 26 - drivers/virt/vboxguest/vboxguest_utils.c | 32 --- drivers/virt/vboxguest/vboxguest_version.h | 9 +- drivers/virt/vboxguest/vmmdev.h| 8 +- include/linux/vbox_utils.h | 12 ++- include/uapi/linux/vbox_vmmdev_types.h | 60 8 files changed, 197 insertions(+), 71 deletions(-) diff --git a/drivers/virt/vboxguest/vboxguest_core.c b/drivers/virt/vboxguest/vboxguest_core.c index 1475ed5ffcde..2ec5b34ffed7 100644 --- a/drivers/virt/vboxguest/vboxguest_core.c +++ b/drivers/virt/vboxguest/vboxguest_core.c @@ -27,6 +27,10 @@ #define GUEST_MAPPINGS_TRIES 5 +#define VBG_KERNEL_REQUEST \ + (VMMDEV_REQUESTOR_KERNEL | VMMDEV_REQUESTOR_USR_DRV | \ +VMMDEV_REQUESTOR_CON_DONT_KNOW | VMMDEV_REQUESTOR_TRUST_NOT_GIVEN) + /** * Reserves memory in which the VMM can relocate any guest mappings * that are floating around. @@ -48,7 +52,8 @@ static void vbg_guest_mappings_init(struct vbg_dev *gdev) int i, rc; /* Query the required space. */ - req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_GET_HYPERVISOR_INFO); + req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_GET_HYPERVISOR_INFO, + VBG_KERNEL_REQUEST); if (!req) return; @@ -135,7 +140,8 @@ static void vbg_guest_mappings_exit(struct vbg_dev *gdev) * Tell the host that we're going to free the memory we reserved for * it, the free it up. (Leak the memory if anything goes wrong here.) */ - req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_SET_HYPERVISOR_INFO); + req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_SET_HYPERVISOR_INFO, + VBG_KERNEL_REQUEST); if (!req) return; @@ -172,8 +178,10 @@ static int vbg_report_guest_info(struct vbg_dev *gdev) struct vmmdev_guest_info2 *req2 = NULL; int rc, ret = -ENOMEM; - req1 = vbg_req_alloc(sizeof(*req1), VMMDEVREQ_REPORT_GUEST_INFO); - req2 = vbg_req_alloc(sizeof(*req2), VMMDEVREQ_REPORT_GUEST_INFO2); + req1 = vbg_req_alloc(sizeof(*req1), VMMDEVREQ_REPORT_GUEST_INFO, +VBG_KERNEL_REQUEST); + req2 = vbg_req_alloc(sizeof(*req2), VMMDEVREQ_REPORT_GUEST_INFO2, +VBG_KERNEL_REQUEST); if (!req1 || !req2) goto out_free; @@ -187,8 +195,8 @@ static int vbg_report_guest_info(struct vbg_dev *gdev) req2->additions_minor = VBG_VERSION_MINOR; req2->additions_build = VBG_VERSION_BUILD; req2->additions_revision = VBG_SVN_REV; - /* (no features defined yet) */ - req2->additions_features = 0; + req2->additions_features = + VMMDEV_GUEST_INFO2_ADDITIONS_FEATURES_REQUESTOR_INFO; strlcpy(req2->name, VBG_VERSION_STRING, sizeof(req2->name)); @@ -230,7 +238,8 @@ static int vbg_report_driver_status(struct vbg_dev *gdev, bool active) struct vmmdev_guest_status *req; int rc; - req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_REPORT_GUEST_STATUS); + req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_REPORT_GUEST_STATUS, + VBG_KERNEL_REQUEST); if (!req) return -ENOMEM; @@ -423,7 +432,8 @@ static int vbg_heartbeat_host_config(struct vbg_dev *gdev, bool enabled) struct vmmdev_heartbeat *req; int rc; - req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_HEARTBEAT_CONFIGURE); + req = vbg_req_alloc(sizeof(*req), VMMDEVREQ_HEARTBEAT_CONFIGURE, + VBG_KERNEL_REQUEST); if (!req) return -ENOMEM; @@ -457,7 +467,8 @@ static int vbg_heartbeat_init(struct vbg_dev *gdev) gdev->guest_heartbeat_req = vbg_req_alloc( sizeof(*gdev->guest_heartbeat_req), - VMMDEVREQ_GUEST_HEARTBEAT); + VMMDEVREQ_GUEST_HEARTBEAT, +
Re: [PATCH 2/2] drm/omap: simplify getting .driver_data
Hi Wolfram,
Thank you for the patch,
On 19/03/2019 16:36, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
As with the other in this series, looks good to me.
Reviewed-by: Kieran Bingham
> ---
>
> Build tested only. buildbot is happy.
>
> drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> index 29692a5217c5..88d4b0c60689 100644
> --- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
> @@ -412,8 +412,7 @@ static const struct backlight_ops dsicm_bl_ops = {
> static ssize_t dsicm_num_errors_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
> struct omap_dss_device *src = ddata->dssdev.src;
> u8 errors = 0;
> int r;
> @@ -444,8 +443,7 @@ static ssize_t dsicm_num_errors_show(struct device *dev,
> static ssize_t dsicm_hw_revision_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
> struct omap_dss_device *src = ddata->dssdev.src;
> u8 id1, id2, id3;
> int r;
> @@ -476,8 +474,7 @@ static ssize_t dsicm_store_ulps(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
> struct omap_dss_device *src = ddata->dssdev.src;
> unsigned long t;
> int r;
> @@ -511,8 +508,7 @@ static ssize_t dsicm_show_ulps(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
> unsigned int t;
>
> mutex_lock(&ddata->lock);
> @@ -526,8 +522,7 @@ static ssize_t dsicm_store_ulps_timeout(struct device
> *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
> struct omap_dss_device *src = ddata->dssdev.src;
> unsigned long t;
> int r;
> @@ -558,8 +553,7 @@ static ssize_t dsicm_show_ulps_timeout(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> + struct panel_drv_data *ddata = dev_get_drvdata(dev);
> unsigned int t;
>
> mutex_lock(&ddata->lock);
>
Re: [PATCH v7 1/2] PM / sleep: refactor the filesystems sync to reduce duplication
On Mon 2019-02-25 20:36:41, Harry Pan wrote: > This patch creates a common helper to sync filesystems and shares > to the suspend, hibernate, and snapshot. > > Signed-off-by: Harry Pan ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [RESEND PATCH] mm/hotplug: fix notification in offline error path
On Fri 22-03-19 12:20:12, Souptick Joarder wrote: > On Thu, Mar 21, 2019 at 2:13 AM Qian Cai wrote: > > > > When start_isolate_page_range() returned -EBUSY in __offline_pages(), it > > calls memory_notify(MEM_CANCEL_OFFLINE, &arg) with an uninitialized > > "arg". As the result, it triggers warnings below. Also, it is only > > necessary to notify MEM_CANCEL_OFFLINE after MEM_GOING_OFFLINE. > > For my clarification, if test_pages_in_a_zone() failed in __offline_pages(), > we have the similar scenario as well. If yes, do we need to capture it > in change log ? Yes this is the same situation. We can add a note that the same applies to test_pages_in_a_zone failure path but I do not think it is strictly necessary. Thanks for the note anyway. -- Michal Hocko SUSE Labs
Re: [PATCH] mm: page_mkclean vs MADV_DONTNEED race
Andrew Morton writes: > On Thu, 21 Mar 2019 09:36:10 +0530 "Aneesh Kumar K.V" > wrote: > >> MADV_DONTNEED is handled with mmap_sem taken in read mode. >> We call page_mkclean without holding mmap_sem. >> >> MADV_DONTNEED implies that pages in the region are unmapped and subsequent >> access to the pages in that range is handled as a new page fault. >> This implies that if we don't have parallel access to the region when >> MADV_DONTNEED is run we expect those range to be unallocated. >> >> w.r.t page_mkclean we need to make sure that we don't break the MADV_DONTNEED >> semantics. MADV_DONTNEED check for pmd_none without holding pmd_lock. >> This implies we skip the pmd if we temporarily mark pmd none. Avoid doing >> that while marking the page clean. >> >> Keep the sequence same for dax too even though we don't support MADV_DONTNEED >> for dax mapping > > What were the runtime effects of the bug? The bug was noticed by code review and I didn't observe any failures w.r.t test run. This is similar to commit 58ceeb6bec86d9140f9d91d71a710e963523d063 Author: Kirill A. Shutemov Date: Thu Apr 13 14:56:26 2017 -0700 thp: fix MADV_DONTNEED vs. MADV_FREE race commit ced108037c2aa542b3ed8b7afd1576064ad1362a Author: Kirill A. Shutemov Date: Thu Apr 13 14:56:20 2017 -0700 thp: fix MADV_DONTNEED vs. numa balancing race > > Did you consider a -stable backport? Considering nobody reported issues w.r.t MADV_DONTNEED I was not sure. -aneesh
Re: [PATCH] perf: Change PMCR write to read-modify-write
On 21/03/2019 20:02, Sodagudi Prasad wrote: > On 2019-03-21 06:34, Julien Thierry wrote: >> Hi Prasad, >> >> On 21/03/2019 02:07, Prasad Sodagudi wrote: >>> Preserves the bitfields of PMCR_EL0(AArch64) during PMU reset. >>> Reset routine should write a 1 to PMCR.C and PMCR.P fields only >>> to reset the counters. Other fields should not be changed >>> as they could be set before PMU initialization and their >>> value must be preserved even after reset. >>> >> >> Are there any particular bit you are concerned about? Apart from the RO >> ones and the Res0 ones (to which we are already writing 0), I see: >> >> DP -> irrelevant for non-secure >> X -> This one is the only potentially interesting, however it resets to >> an architecturally unknown value, so unless we know for a fact it was >> set before hand, we probably want to clear it >> D -> ignored when we have LC set (and we do) >> E -> Since this is the function we use to reset the PMU on the current >> CPU, we probably want to set this bit to 0 regardless of its previous >> value >> >> So, is there any issue this patch is solving? > > Hi Julien, > > Thanks for taking a look into this patch. Yes. On our Qualcomm > platforms, observed that X bit is getting cleared by kernel. > This bit is getting set by firmware for Qualcomm use cases and > non-secure world is resetting without this patch. > I think, changing that register this register modifications to > read-modify-write style make sense. > Maybe for the X bit, but for the E bit this seems like the wrong thing to do. We want to set the E bit to 0 here. And for platforms that don't have a firmware touching the X bit (or rather the pmcr as a whole), I'd like to understand whether it would be valid to leave this bit set to an architecturally unknown value and preserving that value. Thanks, >>> Signed-off-by: Prasad Sodagudi >>> --- >>> arch/arm64/kernel/perf_event.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/arm64/kernel/perf_event.c >>> b/arch/arm64/kernel/perf_event.c >>> index 4addb38..0c1afdd 100644 >>> --- a/arch/arm64/kernel/perf_event.c >>> +++ b/arch/arm64/kernel/perf_event.c >>> @@ -868,8 +868,8 @@ static void armv8pmu_reset(void *info) >>> * Initialize & Reset PMNC. Request overflow interrupt for >>> * 64 bit cycle counter but cheat in armv8pmu_write_counter(). >>> */ >>> - armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C | >>> - ARMV8_PMU_PMCR_LC); >>> + armv8pmu_pmcr_write(armv8pmu_pmcr_read() | ARMV8_PMU_PMCR_P | >>> + ARMV8_PMU_PMCR_C | ARMV8_PMU_PMCR_LC); >>> } >>> >>> static int __armv8_pmuv3_map_event(struct perf_event *event, >>> > -- Julien Thierry
Re: [PATCH 12/17] afs: Avoid section confusion in CM_NAME
Andi Kleen wrote: > __tracepoint_str cannot be const because the tracepoint_str > section is not read-only. Remove the stray const. > > Cc: dhowe...@redhat.com > Cc: v...@zeniv.linux.org.uk > Signed-off-by: Andi Kleen Acked-by: David Howells
Re: [PATCH 24/25] dt-bindings: an30259a: Add function and color properties
On Sun 2019-03-10 19:28:35, Jacek Anaszewski wrote: > Refer to new "function" and "color" properties and mark "label" > as deprecated. > > Signed-off-by: Jacek Anaszewski > Cc: Simon Shields Patches 6,8,10,14,16,18,20,22: Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH v2 7/8] emvtest: Add ability to run all tests
From: David Jacobson
evmtest tests functionality of different IMA-Appraisal policies.
To simplify testing, this patch defines an evmtest config file. This
allows for running all tests at once, rather than invoking each test
individually. Variables can be set once rather than specifying
parameters at runtime on the command line.
Signed-off-by: David Jacobson
changelog:
* removed [OPTIONS] for runall
* added CONFIGURATION PATHNAME -> configuration file
* shellcheck compliant
---
evmtest/README | 31 +-
evmtest/evmtest | 52
evmtest/example.conf | 14
3 files changed, 96 insertions(+), 1 deletion(-)
create mode 100644 evmtest/example.conf
diff --git a/evmtest/README b/evmtest/README
index 4dddbc0..d202559 100644
--- a/evmtest/README
+++ b/evmtest/README
@@ -13,6 +13,7 @@ SYNOPSIS
evmtest runtest [OPTIONS]
+evmtest runall
DESCRIPTION
---
@@ -34,7 +35,7 @@ OPTIONS
TEST NAMES
---
+-
boot_aggregate - verify the IMA boot-aggregate
env_validate - verify kernel build
@@ -45,6 +46,34 @@ TEST NAMES
xattr_preserve - test metadata preservation on file move
+
+CONFIGURATION PATHNAME
+--
+
+The configuration pathname should point to the runall configuration file.
+
+
+=== Configuration File
+
+The evmtest configuration file allows all tests to be run by executing a single
+command. The configuration file contains all the options that needed for
+various tests and allows tests to be run non-interactively, so they can be
+integrated in a larger testing suite.
+
+The `example.conf` file provides a skeleton configuration file, where the only
+variable that *must* be defined is `IMA_KEY`. Defaults are described below.
+
+* `IMA_KEY` - The private key for the certificate on the IMA Trusted Keyring
+
+* `KBUILD_DIR` - Should point to a kernel build tree. If not provided, the test
+will use `/lib/modules/$(uname -r)/build`.
+
+* `KERN_IMAGE` - Should point towards an unsigned kernel image. If not
provided,
+the test will attempt to use the running kernel.
+
+* `VERBOSE` - If set to 1, will add -v to all tests run
+
+
Introduction
diff --git a/evmtest/evmtest b/evmtest/evmtest
index 18cb98d..d6f46f5 100755
--- a/evmtest/evmtest
+++ b/evmtest/evmtest
@@ -16,6 +16,7 @@ source "$EVMDIR"/files/common.sh
usage (){
echo "Usage:"
echo " evmtest runtest [OPTIONS]"
+ echo " evmtest runall "
echo ""
echo "Options:"
echo " -h Displays this help message"
@@ -67,6 +68,57 @@ elif [ "$1" == "runtest" ]; then
runtest "$@"
exit $?
fi
+elif [ "$1" == "runall" ]; then
+ if [ -z "$2" ] || [ ! -e "$2" ]; then
+ echo "evmtest runall "
+ echo "[!] Please provide a config file"
+ exit 1
+ fi
+ source "$2" # Load in config
+ if [ "$VERBOSE" -eq 1 ]; then
+ V="-v"
+ fi
+
+ # Key is not optional
+ if [ -z "$IMA_KEY" ]; then
+ echo "[*] Please correct your config file"
+ exit 1
+ fi
+
+ EVMTEST_require_root
+ FAIL=0
+ echo "[*] Running tests..."
+ # 1
+ "$EVMDIR"/tests/env_validate.sh -r "$V"
+ FAIL=$((FAIL+$?))
+ # 2
+ if [ -z "$KERN_IMAGE" ]; then
+ "$EVMDIR"/tests/kexec_sig.sh -k "$IMA_KEY" "$V"
+ else
+ "$EVMDIR"/tests/kexec_sig.sh -k "$IMA_KEY" -i \
+ "$KERN_IMAGE" "$V"
+ fi
+ FAIL=$((FAIL+$?))
+ # 3
+ if [ -z "$KBUILD_DIR" ]; then
+ "$EVMDIR"/tests/kmod_sig.sh -k "$IMA_KEY" "$V"
+ else
+ "$EVMDIR"/tests/kmod_sig.sh -b "$KBUILD_DIR" \
+ -k "$IMA_KEY" "$V"
+ fi
+ FAIL=$((FAIL+$?))
+ # 4
+ "$EVMDIR"/tests/policy_sig.sh -k "$IMA_KEY" "$V"
+ FAIL=$((FAIL+$?))
+ # 5
+ "$EVMDIR"/tests/boot_aggregate.sh "$V"
+ FAIL=$((FAIL+$?))
+ # 6
+ "$EVMDIR"/tests/xattr_preserve.sh "$V"
+ FAIL=$((FAIL+$?))
+ echo "..."
+ echo "[*] TESTS PASSED: $((6-FAIL))"
+ echo "[*] TESTS FAILED: $FAIL"
else
usage
fi
diff --git a/evmtest/example.conf b/evmtest/example.conf
new file mode 100644
index 000..fd1c8fe
--- /dev/null
+++ b/evmtest/example.conf
@@ -0,0 +1,14 @@
+# This is an example config file
+# There are three variables that can be set when using evmtest runall
+
+#Set this to 1 for verbose output
+VERBOSE=0
+# Path to the private key for the IMA Trusted Keyring
+# This is required
+IMA_KEY=/path/to/your/ima_key
+
+# If this is not provided, tests will run but attempt to copy the running
kernel
+KERN_IMAGE=/path/to/unsigned/kernel_image
+
+# If this is not defined, tests will try to find build tree
+KBUILD_DIR=/path/to/kernel/build/tree
--
2.20.1
Re: [PATCHv2] x86/boot/KASLR: skip the specified crashkernel reserved region
On 03/22/19 at 03:52pm, Baoquan He wrote:
> On 03/22/19 at 03:43pm, Pingfan Liu wrote:
> > > > +/* parse crashkernel=x@y option */
> > > > +static void mem_avoid_crashkernel_simple(char *option)
> > >
> > > Chao ever mentioned this, I want to ask again, why does it has to be
> > > xxx_simple()?
> > >
> > Seems that I had replied Chao's question in another email. The naming
> > follows the function parse_crashkernel_simple(), as the notes above
>
>
> Sorry, I don't get. typo?
OK, I misunderstood it. We do have parse_crashkernel_simple() to handle
crashkernel=size[@offset] case, to differente with other complicated
cases, like crashkernel=size,[high|low],
Then I am fine with this naming. Soryy about the noise.
By the way, do you think if we should take care of this case:
crashkernel=:[,:,...][@offset]
It can also specify @offset. Not sure if it's too complicated, you may
have a investigation.
These two cases have dependency on your crashkernel=X bug fix patch.
The current code only allow crashkernel= to reserve under 896MB. I
noticed Boris has agreed on the solution. Maybe you can repost a new
version based on the discussion.
http://lkml.kernel.org/r/1548047768-7656-1-git-send-email-kernelf...@gmail.com
[PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with
kaslr
Thanks
Baoquan
>
> > the definition
> > /*
> > * That function parses "simple" (old) crashkernel command lines like
> > *
> > * crashkernel=size[@offset]
>
> Hmm, should only crashkernel=size@offset be cared? crashkernel=size will
> auto finding a place to reserve, and that is after KASLR.
>
> > *
> > * It returns 0 on success and -EINVAL on failure.
> > */
> > static int __init parse_crashkernel_simple(char *cmdline,
> >
> > Do you have alternative suggestion?
> >
> > > Except of these, patch looks good to me. It's a nice catch, and only
> > > need a simple fix based on the current code.
> > >
> > Thank you for the kindly review.
> >
> > Regards,
> > Pingfan
> >
> > > Thanks
> > > Baoquan
> > >
> > > > +{
> > > > + unsigned long long crash_size, crash_base;
> > > > + char *cur = option;
> > > > +
> > > > + crash_size = memparse(option, &cur);
> > > > + if (option == cur)
> > > > + return;
> > > > +
> > > > + if (*cur == '@') {
> > > > + option = cur + 1;
> > > > + crash_base = memparse(option, &cur);
> > > > + if (option == cur)
> > > > + return;
> > > > + mem_avoid[MEM_AVOID_CRASHKERNEL].start = crash_base;
> > > > + mem_avoid[MEM_AVOID_CRASHKERNEL].size = crash_size;
> > > > + }
> > > > +}
> > > >
> > > > static void handle_mem_options(void)
> > > > {
> > > > @@ -250,7 +270,7 @@ static void handle_mem_options(void)
> > > > u64 mem_size;
> > > >
> > > > if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
> > > > - !strstr(args, "hugepages"))
> > > > + !strstr(args, "hugepages") && !strstr(args,
> > > > "crashkernel="))
> > > > return;
> > > >
> > > > tmp_cmdline = malloc(len + 1);
> > > > @@ -286,6 +306,8 @@ static void handle_mem_options(void)
> > > > goto out;
> > > >
> > > > mem_limit = mem_size;
> > > > + } else if (strstr(param, "crashkernel")) {
> > > > + mem_avoid_crashkernel_simple(val);
> > > > }
> > > > }
> > > >
> > > > @@ -414,7 +436,7 @@ static void mem_avoid_init(unsigned long input,
> > > > unsigned long input_size,
> > > >
> > > > /* We don't need to set a mapping for setup_data. */
> > > >
> > > > - /* Mark the memmap regions we need to avoid */
> > > > + /* Mark the regions we need to avoid */
> > > > handle_mem_options();
> > > >
> > > > #ifdef CONFIG_X86_VERBOSE_BOOTUP
> > > > --
> > > > 2.7.4
> > > >
[PATCH v2 1/8] evmtest: Regression testing integrity subsystem
From: David Jacobson As the Linux integrity subsystem matures and new features are added, the number of kernel configuration options (Kconfig) and methods for loading policies have increased. Regression testing of new and existing features is needed to ensure correct behavior. The Linux Test Project (LTP) is a test suite that aims to validate the "reliability, robustness, and stability" of Linux. Currently, the Linux Test Project (LTP) only includes the original IMA-measurement regression tests, not the newer IMA-appraisal or IMA- audit features. This patchset introduces "evmtest" — a standalone Linux integrity regression tool. evmtest can be used to validate individual behaviors by exercising execve, kexec, module load, and other LSM hooks. The initial evmtest regression tests verify the IMA-appraisal behavior based on appending IMA-appraisal policy rules to the custom policy. evmtest uses a combination of unsigned and validly signed files to verify the running system. The custom policy assumes the kernel is properly configured. The first evmtest named "env_validate" validates the kernel is properly configured. For example, CONFIG_IMA_WRITE_POLICY is required for appending to the IMA custom policy. A local-CA certificate needs to either be builtinto the kernel or memory reserved for embedding the certificate post-build. "evmtest" output is consistent, allowing "evmtest" to be plugged into a testing framework/harness. Testing frameworks, such as xfstests, require deterministic output. xfstests runs a test and compares its output to a predefined value, created by running the test script under conditions where it passes. evmtest provides output that can easily be integrated with xfstests. All tests have a verbose mode (-v) that outputs more information for debugging purposes. New tests can be defined by placing them in the functions/ directory. An "example_test.sh" script is provided for reference. Example 1: Successful example test output $ evmtest runtest example_test -h example_test -e [-vh] This is an example of how to structure an evmtest -e -hDisplays this help message -vVerbose logging $ evmtest runtest example_test -e /bin/bash [*] Starting test: example_test [*] TEST: PASSED Example 1a: successful verbose example test output $ evmtest runtest example_test -e /bin/bash -v [*] Starting test: example_test [*] Example file exists [*] TEST: PASSED Example 1b: failed verbose example test output $ evmtest runtest example_test -e /bin/foo -v [*] Starting test: example_test [!] Example file does not exist [!] TEST: FAILED SYNOPSIS: evmtest runtest [OPTIONS] options: -h Displays a help message -v Verbose logging Signed-off-by: David Jacobson Changelog: * Various clean-up to env_validate * Redid loading of running config * Changed comment order in example test * Cleaned up README * Removed notes about VM in env_validate and README * kernel_build_dir -> build_dir * Removed listing of functions/ directory * Added individual name of each test * Rewritten and expanded README * Rewrite validate and validate_defined * shellcheck compliant * example test, fewer comments + shellcheck * clean ups suggested by Mimi * renamed functions -> tests * checkbashishms compliant * removed begin funcion usage * removed long opt names * Notes file has changes in proper commit * switched to using functions for structure * added policy_readable to common.sh --- Makefile.am | 5 +- configure.ac | 1 + evmtest/INSTALL | 11 ++ evmtest/Makefile.am | 23 evmtest/README| 240 ++ evmtest/evmtest | 67 ++ evmtest/files/Notes | 5 + evmtest/files/common.sh | 59 + evmtest/files/load_policy.sh | 37 ++ evmtest/tests/env_validate.sh | 196 +++ evmtest/tests/example_test.sh | 63 + 11 files changed, 706 insertions(+), 1 deletion(-) create mode 100644 evmtest/INSTALL create mode 100644 evmtest/Makefile.am create mode 100644 evmtest/README create mode 100755 evmtest/evmtest create mode 100644 evmtest/files/Notes create mode 100755 evmtest/files/common.sh create mode 100755 evmtest/files/load_policy.sh create mode 100755 evmtest/tests/env_validate.sh create mode 100755 evmtest/tests/example_test.sh diff --git a/Makefile.am b/Makefile.am index dba408d..0cb4111 100644 --- a/Makefile.am +++ b/Makefile.am @@ -36,4 +36,7 @@ rmman: doc: evmctl.1.html rmman evmctl.1 -.PHONY: $(tarname) +evmtest: + $(MAKE) -C evmtest + +.PHONY: $(tarname) evmtest diff --git a/configure.ac b/configure.ac index a5b4288..59ec1d1 100644 --- a/configure.ac +++ b/configure.ac @@ -52,6 +52,7 @@ EVMCTL_MANPAGE_DOCBOOK_XSL AC_CONFIG_FILES([Makefile src/Makefile packaging/ima-evm-utils.spec + evmtest/Makefile ]) AC_OUT
[PATCH v2 8/8] evmtest: virtual machine compatibility
From: David Jacobson
Regression testing kernels is a task that is often virtualized. This
patch adds functionality to evmtest that enables a developer to
determine if their kernel build is suitable for running in a virtual
machine.
Signed-off-by: David Jacobson
changelog:
* shellcheck compliant
* updated patch to work with function restructure
---
evmtest/tests/env_validate.sh | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/evmtest/tests/env_validate.sh b/evmtest/tests/env_validate.sh
index c630a23..09b1a87 100755
--- a/evmtest/tests/env_validate.sh
+++ b/evmtest/tests/env_validate.sh
@@ -4,12 +4,13 @@
TEST="env_validate"
ROOT="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )/.."
source "$ROOT"/files/common.sh
+VM_VALIDATE=0
VERBOSE=0
CONFIG_FILE=""
usage () {
echo ""
- echo "env_validate [-c ]|-r] [-vh]"
+ echo "env_validate [-c ]|-r] [--vm] [-vh]"
echo ""
echo " This test validates that a kernel is properly configured, "
echo " based on either the provided config file or the builtin"
@@ -18,12 +19,13 @@ usage () {
echo " -c Kernel config file"
echo " -r Will attempt to pull running config"
echo " -v Verbose testing"
+ echo " --vmWill validate that the build is VM compatible"
echo " -h Displays this help message"
echo ""
}
parse_args () {
- TEMP=$(getopt -o 'hc:rv' -n 'env_validate' -- "$@")
+ TEMP=$(getopt -o 'hc:rv' -l "vm" -n 'env_validate' -- "$@")
eval set -- "$TEMP"
while true ; do
@@ -32,6 +34,7 @@ parse_args () {
-c) CONFIG="$2"; shift 2;;
-r) RUNNING=1; shift;;
-v) VERBOSE=1; shift;;
+ --vm) VM_VALIDATE=1; shift;;
--) shift; break;;
*) echo "[*] Unrecognized option $1"; exit 1 ;;
esac
@@ -154,6 +157,22 @@ check_config () {
validate_defined "CONFIG_MODULE_SIG_KEY"
validate "CONFIG_MODULE_SIG" "y"
+
+ if [ $VM_VALIDATE == 1 ]; then
+ v_out "Validating VM configuration"
+
+ validate "CONFIG_BLK_MQ_VIRTIO" "y"
+ validate "CONFIG_MEMORY_BALLOON" "y"
+ validate "CONFIG_VIRTIO_BLK" "y"
+ validate "CONFIG_SCSI_VIRTIO" "y"
+ validate "CONFIG_HW_RANDOM_VIRTIO" "y"
+ validate "CONFIG_VIRTIO" "y"
+ validate "CONFIG_VIRTIO_MENU" "y"
+ validate "CONFIG_VIRTIO_PCI" "y"
+ validate "CONFIG_VIRTIO_PCI_LEGACY" "y"
+ validate "CONFIG_VIRTIO_BALLOON" "y"
+ fi
+
if [ ${#INVALID_DEFINITION[@]} != 0 ]; then
v_out "The following Kconfig variables are incorrectly defined:"
for var in "${INVALID_DEFINITION[@]}"; do
--
2.20.1
[PATCH v2 5/8] evmtest: validate boot record
From: David Jacobson
The first record in the IMA runtime measurement list is the boot
aggregate - a hash of PCRs 0-7. This test calculates the boot aggregate
based off the PCRs and compares it to IMA's boot aggregate.
Dependencies: a TPM, IBMTSS2.
Signed-off-by: David Jacobson
Changelog:
* Added boot_aggregate to test list
* shellcheck compliant
* minor fixes
* move from functions to tests
* redid tss parsing
* checkbashisms complaint
* remove begin
* removed long opts
* restructured to use functions
* added changes from Mimi to work with new TSS
* removed searching for TSS locations
---
evmtest/README | 1 +
evmtest/evmtest | 1 +
evmtest/tests/boot_aggregate.sh | 140
3 files changed, 142 insertions(+)
create mode 100755 evmtest/tests/boot_aggregate.sh
diff --git a/evmtest/README b/evmtest/README
index 91c8cda..b2d37e2 100644
--- a/evmtest/README
+++ b/evmtest/README
@@ -36,6 +36,7 @@ OPTIONS
TEST NAMES
--
+ boot_aggregate - verify the IMA boot-aggregate
env_validate - verify kernel build
example_test - example test
policy_sig - verify loading IMA policies
diff --git a/evmtest/evmtest b/evmtest/evmtest
index cd5e238..3c967f9 100755
--- a/evmtest/evmtest
+++ b/evmtest/evmtest
@@ -26,6 +26,7 @@ usage (){
# Any test should be added here manually
# The reason this is manual is to prevent the accidental / malicious
# placement of a script in tests/
+ echo "[R] boot_aggregate"
echo "[R] env_validate"
echo "[ ] examples_test"
echo "[R] kexec_sig"
diff --git a/evmtest/tests/boot_aggregate.sh b/evmtest/tests/boot_aggregate.sh
new file mode 100755
index 000..adecfeb
--- /dev/null
+++ b/evmtest/tests/boot_aggregate.sh
@@ -0,0 +1,140 @@
+#!/bin/bash
+# Author: David Jacobson
+TEST="boot_aggregate"
+
+ROOT="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )/.."
+source "$ROOT"/files/common.sh
+
+VERBOSE=0
+TPM_VERSION="2.0"
+# This test validates the eventlog against the hardware PCRs in the TPM, and
+# the boot aggregate against IMA.
+
+usage (){
+ echo "boot_aggregate [-hv]"
+ echo ""
+ echo " This test must be run as root"
+ echo ""
+ echo " This test validates PCRs 0-7 in the TPM"
+ echo " It also validates the boot_aggregate based those PCRs"
+ echo " against what IMA has recorded"
+ echo ""
+ echo " -h Display this help message"
+ echo " -v Verbose logging"
+}
+
+parse_args () {
+ TEMP=$(getopt -o 'hv' -n 'boot_aggregate' -- "$@")
+ eval set -- "$TEMP"
+
+ while true ; do
+ case "$1" in
+ -h) usage; exit; shift;;
+ -v) VERBOSE=1; shift;;
+ --) shift; break;;
+ *) echo "[*] Unrecognized option $1"; exit 1 ;;
+ esac
+ done
+}
+
+check_requirements () {
+ v_out "Checking if securityfs is mounted..."
+ if [ -z "$EVMTEST_SECFS_EXISTS" ]; then
+ fail "securityfs not found..."
+ fi
+
+ v_out "Verifying TPM is present..."
+ if [ ! -d "$EVMTEST_SECFS/tpm0" ]; then
+ fail "Could not locate TPM in $EVMTEST_SECFS"
+ fi
+
+ v_out "TPM found..."
+
+ v_out "Checking if system supports reading event log..."
+
+ if [ ! -f "$EVMTEST_SECFS"/tpm0/binary_bios_measurements ]; then
+ fail "Kernel does not support reading BIOS measurements,
+ please update to at least 4.16.0"
+ fi
+
+ v_out "Verifying TPM Version"
+ if [ -e /sys/class/tpm/tpm0/device/caps ]; then
+ TPM_VERSION="1.2"
+ fi
+}
+
+check_pcrs () {
+ v_out "Grabbing PCR values..."
+ local pcrs=() # array to store the Hardware PCR values
+ local sim_pcrs=() # What PCRs should be according to the event log
+ local eventextend=tsseventextend
+ local pcrread="tsspcrread -halg sha1"
+ local eventlog=/sys/kernel/security/tpm0/binary_bios_measurements
+
+ if [ "$TPM_VERSION" == "1.2" ]; then
+ eventextend=tss1eventextend
+ pcrread=tss1pcrread
+ fi
+
+ for ((i=0; i<=7; i++)); do
+ pcrs[i]=$(TPM_INTERFACE_TYPE=dev $pcrread -ha "$i" -ns)
+ done
+
+ local output=$(mktemp -u)
+ "$eventextend" -if "$eventlog" -sim -ns > "$output"
+
+ # Some PTT's are using TPM 1.2 event log format. Retry on failure.
+ if [ $? -ne 0 ]; then
+ eventextend=tss1eventextend
+ "$eventextend" -if "$eventlog" -sim -ns > "$output"
+ fi
+
+ IFS=$'\n' read -d '' -r -a lines < "$output"
+ rm "$output"
+
+ for line in "${lines[@]}"
+ do
+ :
+ sim_pcrs+=( "$(echo "$line" | cut -d ':' -f2 | \
+ tr -d '[:space:]'
[PATCH v2 3/8] evmtest: test kernel module loading
From: David Jacobson
The Linux kernel supports two methods of loading kernel modules -
init_module and finit_module syscalls. This test verifies loading kernel
modules with both syscalls, first without an IMA policy, and
subsequently with an IMA policy (that restricts module loading to signed
modules).
This test requires the kernel to be configured with the
"CONFIG_MODULE_SIG" option, but not with "CONFIG_MODULE_SIG_FORCE". For
this reason, the test requires that "module.sig_enforce=1" is supplied
as a boot option to the kernel.
Signed-off-by: David Jacobson
Changelog:
* kernel_build_directory -> build_directory
* Added kmod_sig to test list
* shellcheck compliant
* move from functions to tests
* clean up for readability
* redid order of loading and pushing policy
* added policy check
* checkbashisms complaint
* removed begin
* removed long opts
* Notes file updated in appropriate patch
* Restructured with functions
* Renamed to simple_modload, can now be used in other areas
---
evmtest/Makefile.am | 11 +-
evmtest/README | 11 +
evmtest/evmtest | 1 +
evmtest/files/Notes | 5 +
evmtest/files/policies/kernel_module_policy | 2 +
evmtest/src/Makefile| 5 +
evmtest/src/basic_mod.c | 36 +++
evmtest/src/simple_modload.c| 151 ++
evmtest/tests/kmod_sig.sh | 288
evmtest/tests/policy_sig.sh | 1 -
10 files changed, 507 insertions(+), 4 deletions(-)
create mode 100644 evmtest/files/policies/kernel_module_policy
create mode 100644 evmtest/src/Makefile
create mode 100644 evmtest/src/basic_mod.c
create mode 100644 evmtest/src/simple_modload.c
create mode 100755 evmtest/tests/kmod_sig.sh
diff --git a/evmtest/Makefile.am b/evmtest/Makefile.am
index 496a5de..74a8199 100644
--- a/evmtest/Makefile.am
+++ b/evmtest/Makefile.am
@@ -3,7 +3,7 @@ datarootdir=@datarootdir@
exec_prefix=@exec_prefix@
bindir=@bindir@
-all: evmtest.1
+all: src evmtest.1
evmtest.1:
asciidoc -d manpage -b docbook -o evmtest.1.xsl README
@@ -11,7 +11,10 @@ evmtest.1:
xsltproc --nonet -o $@ $(MANPAGE_DOCBOOK_XSL) evmtest.1.xsl
asciidoc -o evmtest.html README
rm -f evmtest.1.xsl
-install:
+src:
+ cd src && make
+
+install: src
install -m 755 evmtest $(bindir)
install -d $(datarootdir)/evmtest/files/
install -d $(datarootdir)/evmtest/files/policies
@@ -21,7 +24,9 @@ install:
$(datarootdir)/evmtest/files/
install -D ./tests/* $(datarootdir)/evmtest/tests/
install -D ./files/policies/* $(datarootdir)/evmtest/files/policies/
+ cp ./src/basic_mod.ko $(datarootdir)/evmtest/files/
+ cp ./src/basic_modload $(datarootdir)/evmtest/files
cp evmtest.1 $(datarootdir)/man/man1
mandb -q
-.PHONY: install evmtest.1
+.PHONY: src install evmtest.1
diff --git a/evmtest/README b/evmtest/README
index 480f426..8c63630 100644
--- a/evmtest/README
+++ b/evmtest/README
@@ -39,6 +39,7 @@ TEST NAMES
env_validate - verify kernel build
example_test - example test
policy_sig - verify loading IMA policies
+ policy_sig - test IMA-appraise on policies
Introduction
@@ -172,6 +173,9 @@ IMA's behavior is dependent on its policy. The policy
defines which
files are measured, appraised, and audited. Without a policy, IMA does
not do anything.
+When running evmtest, boot with: module.sig_enforce=1. This tells the kernel to
+prevent the loading of any unsigned modules.
+
=== Methods for defining policy rules
@@ -213,6 +217,13 @@ As the regression tests mature and additional tests are
defined, the
regression tests will not make policy assumptions.
+=== Require kernel module appended signatures
+
+Most kernels are configured with CONFIG_MODULE_SIG enabled but without
+CONFIG_MODULE_SIG_FORCE. For testing purposes, require kernel module appended
+signatures by specifying `module.sig_enforce=1` on the boot command line.
+
+
FAQ
---
=== 1. How can an IMA key be loaded without rebuilding dracut?
diff --git a/evmtest/evmtest b/evmtest/evmtest
index 9902e61..49b162d 100755
--- a/evmtest/evmtest
+++ b/evmtest/evmtest
@@ -28,6 +28,7 @@ usage (){
# placement of a script in tests/
echo "[R] env_validate"
echo "[ ] examples_test"
+ echo "[R] kmod_sig"
echo "[R] policy_sig"
echo ""
diff --git a/evmtest/files/Notes b/evmtest/files/Notes
index 8aa2670..574f5d8 100644
--- a/evmtest/files/Notes
+++ b/evmtest/files/Notes
@@ -19,3 +19,8 @@ This is a directory that contains IMA policies with self
explanatory names.
This file was generated such that its corresponding public key could be placed
on the IMA Trusted Keyring, however, it has not. Therefore, any policy (or
file)
signed by this key cannot be verified, and is untrusted.
+
+5. ba
[PATCH v2 4/8] evmtest: test kexec signature policy
From: David Jacobson
With secure boot enabled, the bootloader verifies the kernel image's
signature before transferring control to it. With Linux as the
bootloader running with secure boot enabled, kexec needs to verify the
kernel image's signature.
This patch defined a new test named "kexec_sig", which first attempts to
kexec an unsigned kernel image with an IMA policy that requires
signatures on any kernel image. Then, the test attempts to kexec the
signed kernel image, which should succeed.
Signed-off-by: David Jacobson
Changelog:
* Added policy_sig to test list
* shellcheck compliant
* move from functions to tests
* suggestions from Mimi
* checkbashisms complaint
* removed begin
* removed long opts
* restructed to use functions
---
evmtest/README | 3 +-
evmtest/evmtest | 1 +
evmtest/files/policies/kexec_policy | 3 +
evmtest/tests/kexec_sig.sh | 167
4 files changed, 173 insertions(+), 1 deletion(-)
create mode 100644 evmtest/files/policies/kexec_policy
create mode 100755 evmtest/tests/kexec_sig.sh
diff --git a/evmtest/README b/evmtest/README
index 8c63630..91c8cda 100644
--- a/evmtest/README
+++ b/evmtest/README
@@ -39,7 +39,8 @@ TEST NAMES
env_validate - verify kernel build
example_test - example test
policy_sig - verify loading IMA policies
- policy_sig - test IMA-appraise on policies
+ kexec_sig - test IMA-appraise on kexec image loading
+ kmod_sig - test IMA-appraise on kernel module loading
Introduction
diff --git a/evmtest/evmtest b/evmtest/evmtest
index 49b162d..cd5e238 100755
--- a/evmtest/evmtest
+++ b/evmtest/evmtest
@@ -28,6 +28,7 @@ usage (){
# placement of a script in tests/
echo "[R] env_validate"
echo "[ ] examples_test"
+ echo "[R] kexec_sig"
echo "[R] kmod_sig"
echo "[R] policy_sig"
diff --git a/evmtest/files/policies/kexec_policy
b/evmtest/files/policies/kexec_policy
new file mode 100644
index 000..dc00fa7
--- /dev/null
+++ b/evmtest/files/policies/kexec_policy
@@ -0,0 +1,3 @@
+appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig
+measure func=KEXEC_KERNEL_CHECK
+audit func=KEXEC_KERNEL_CHECK
diff --git a/evmtest/tests/kexec_sig.sh b/evmtest/tests/kexec_sig.sh
new file mode 100755
index 000..3a9459d
--- /dev/null
+++ b/evmtest/tests/kexec_sig.sh
@@ -0,0 +1,167 @@
+#!/bin/bash
+# Author: David Jacobson
+TEST="kexec_sig"
+ROOT="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )/.."
+source "$ROOT"/files/common.sh
+VERBOSE=0
+POLICY_LOAD="$ROOT"/files/load_policy.sh
+
+# This test validates that IMA measures and appraises signatures on kernel
+# images when trying to kexec, if the current policy requires that.
+usage() {
+ echo ""
+ echo "kexec_sig -k [-i > /dev/null; then
+ fail "Could not update policy - verify keys"
+ fi
+}
+
+check_unsigned_KEXEC_FILE_LOAD () {
+ v_out "Testing loading an unsigned kernel image using KEXEC_FILE_LOAD"\
+ "syscall"
+ # -s uses the kexec_file_load syscall
+ if ! kexec -s -l "$KERNEL_IMAGE" &>> /dev/null; then
+ v_out "Correctly prevented kexec of an unsigned image"
+ else
+ kexec -s -u
+ fail "kexec loaded instead of rejecting. Unloading and exiting."
+ fi
+}
+
+check_unsigned_KEXEC_LOAD () {
+ v_out "Testing loading an unsigned kernel image using KEXEC_LOAD"\
+ "syscall"
+ if kexec -l "$KERNEL_IMAGE" &>> /dev/null; then
+ kexec -u
+ fail "Kexec loaded unsigned image - unloading"
+ else
+ v_out "Correctly prevented kexec of an unsigned image"
+ fi
+}
+
+sign_image () {
+ v_out "Signing kernel image with provided key..."
+ evmctl ima_sign -f "$KERNEL_IMAGE" -k "$IMA_KEY"
+}
+
+check_signed_KEXEC_FILE_LOAD () {
+ v_out "Testing loading a signed kernel image using KEXEC_FILE_LOAD"\
+ "syscall"
+ if ! kexec -s -l "$KERNEL_IMAGE" &>> /dev/null; then
+ fail "kexec rejected a signed image - possibly due to PECOFF"\
+ "signature"
+ else
+ v_out "kexec correctly loaded signed image...unloading"
+ fi
+
+ kexec -s -u
+}
+
+check_signed_KEXEC_LOAD () {
+ v_out "Testing loading a signed kernel image \
+ (without file descriptor) using KEXEC_LOAD syscall"
+
+ if kexec -l "$KERNEL_IMAGE" &>> /dev/null; then
+ kexec -u
+ fail "Signed image was allowed to load without file descriptor"\
+ "for appraisal. Unloading."
+ fi
+
+ v_out "Correctly prevented loading"
+}
+
+cleanup () {
+v_out "Cleaning up..."
+if [ -n "$TEMP_LOCATION" ]; then
+ rm "$TEMP_LOCATION"
+fi
+}
+
+
+EVMTEST_require_root
+echo "[*] Starting test: $TEST"
+parse_args "$@"
+get_image
+write_hash
+load_policy
+check_unsigned_KE
[PATCH v2 6/8] evmtest: test the preservation of extended attributes
From: David Jacobson
IMA supports file signatures by storing information in a security.ima
extended file attribute. This test ensures that the attribute is
preserved when a file is copied. This test requires root because only
root can write "security." xattrs to files.
Signed-off-by: David Jacobson
Changelog:
* Clean ups suggested via mailing list
* getfattr used correctly
* more information about which file is created
* added xattr_preserve to test list
* shellcheck compliant
* move from functions to tests
* checkbashisms complaint
* remove begin
* removed long opts
* restructured using functions
---
evmtest/README | 1 +
evmtest/evmtest | 1 +
evmtest/tests/xattr_preserve.sh | 81 +
3 files changed, 83 insertions(+)
create mode 100755 evmtest/tests/xattr_preserve.sh
diff --git a/evmtest/README b/evmtest/README
index b2d37e2..4dddbc0 100644
--- a/evmtest/README
+++ b/evmtest/README
@@ -42,6 +42,7 @@ TEST NAMES
policy_sig - verify loading IMA policies
kexec_sig - test IMA-appraise on kexec image loading
kmod_sig - test IMA-appraise on kernel module loading
+ xattr_preserve - test metadata preservation on file move
Introduction
diff --git a/evmtest/evmtest b/evmtest/evmtest
index 3c967f9..18cb98d 100755
--- a/evmtest/evmtest
+++ b/evmtest/evmtest
@@ -32,6 +32,7 @@ usage (){
echo "[R] kexec_sig"
echo "[R] kmod_sig"
echo "[R] policy_sig"
+ echo "[R] xattr_preserve"
echo ""
echo "Note: Tests may be run directly from the \"tests\" directory"
diff --git a/evmtest/tests/xattr_preserve.sh b/evmtest/tests/xattr_preserve.sh
new file mode 100755
index 000..61f6ded
--- /dev/null
+++ b/evmtest/tests/xattr_preserve.sh
@@ -0,0 +1,81 @@
+#!/bin/bash
+# Author: David Jacobson
+TEST="xattr_preserve"
+ROOT="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )/.."
+source "$ROOT"/files/common.sh
+
+VERBOSE=0
+# This test ensures that extended file attributes are preserved when a file is
+# moved with the correct flag
+
+usage (){
+ echo ""
+ echo "xattr_preserve [-hv]"
+ echo ""
+ echo "This test requires root privileges to write security xattrs"
+ echo ""
+ echo " This test ensures that extended file attributes (specifically"
+ echo " security.ima labels) are preserved when copying"
+ echo "Options"
+ echo " -h Display this help message"
+ echo " -v Verbose logging"
+}
+
+parse_args () {
+ TEMP=$(getopt -o 'hv' -n 'xattr_preserve' -- "$@")
+ eval set -- "$TEMP"
+
+ while true ; do
+ case "$1" in
+ -h) usage; exit; shift;;
+ -v) VERBOSE=1; shift;;
+ --) shift; break;;
+ *) echo "[*] Unrecognized option $1"; exit 1;;
+ esac
+ done
+}
+
+check_xattr_preserve () {
+ LOCATION_1=$(mktemp)
+ LOCATION_2=$(mktemp -u) # Doesn't create the file
+
+ v_out "Creating and labeling file $LOCATION_1..."
+
+ evmctl ima_hash "$LOCATION_1"
+
+ initial_ima_label=$(getfattr --absolute-names -n security.ima \
+ "$LOCATION_1")
+ initial_hash=$(echo "$initial_ima_label" | awk -F '=' '{print $2}')
+ if printf '%s' "$initial_ima_label" | grep -E -q "security.ima"; then
+ v_out "Found hash on initial file... "
+ else
+ fail "Hash not found on initial file"
+ fi
+
+ initial_hash=$(echo "$initial_ima_label" | awk -F '=' '{print $2}')
+
+ v_out "Copying file to $LOCATION_2..."
+ cp --preserve=xattr "$LOCATION_1" "$LOCATION_2"
+ v_out "Checking if extended attribute has been preserved..."
+
+
+ second_ima_label=$(getfattr --absolute-names -n security.ima \
+ "$LOCATION_2")
+ second_hash=$(echo "$second_ima_label" | awk -F '=' '{print $2}')
+ if [ "$initial_hash" != "$second_hash" ]; then
+ fail "security.ima xattr was not preserved!"
+ else
+ v_out "Extended attribute was preserved during copy"
+ fi
+}
+
+cleanup () {
+ v_out "Cleaning up..."
+ rm "$LOCATION_1" "$LOCATION_2"
+}
+
+EVMTEST_require_root
+echo "[*] Starting test: $TEST"
+check_xattr_preserve
+cleanup
+passed
--
2.20.1
Re: [PATCH] tty: fix NULL pointer issue when tty_port ops is not set
Hi Greg,
I do not think that any driver faces this problem.
Nevertheless I found 2 drivers declaring an 'empty' struct (wasted) to
solve this issue:
drivers/char/ttyprintk:
static const struct tty_port_operations null_ops = { };
drivers/tty/vcc.c:
static struct tty_port_operations vcc_port_ops = { 0 };
Please let me know if you prefer I abandon this patch and use an 'empty'
struct in the new code I add.
Or if you think that this patch is safe, feel free to ask me to update
the two drivers listed above.
BR
Fabien
On 21/03/2019 6:38 PM, Greg Kroah-Hartman wrote:
> On Thu, Mar 21, 2019 at 04:43:26PM +0100, Fabien Dessenne wrote:
>> Unlike 'client_ops' which is initialized to 'default_client_ops', the
>> port operations 'ops' may be left to NULL.
>> Check the 'ops' value before checking the 'ops->x' value.
>>
>> Signed-off-by: Fabien Dessenne
>> ---
>> drivers/tty/tty_port.c | 10 +-
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
>> index 044c3cb..a9e12b3 100644
>> --- a/drivers/tty/tty_port.c
>> +++ b/drivers/tty/tty_port.c
>> @@ -325,7 +325,7 @@ static void tty_port_shutdown(struct tty_port *port,
>> struct tty_struct *tty)
>> if (tty && C_HUPCL(tty))
>> tty_port_lower_dtr_rts(port);
>>
>> -if (port->ops->shutdown)
>> +if (port->ops && port->ops->shutdown)
>> port->ops->shutdown(port);
>> }
>> out:
>> @@ -398,7 +398,7 @@ EXPORT_SYMBOL_GPL(tty_port_tty_wakeup);
>>*/
>> int tty_port_carrier_raised(struct tty_port *port)
>> {
>> -if (port->ops->carrier_raised == NULL)
>> +if (!port->ops || !port->ops->carrier_raised)
>> return 1;
>> return port->ops->carrier_raised(port);
>> }
>> @@ -414,7 +414,7 @@ EXPORT_SYMBOL(tty_port_carrier_raised);
>>*/
>> void tty_port_raise_dtr_rts(struct tty_port *port)
>> {
>> -if (port->ops->dtr_rts)
>> +if (port->ops && port->ops->dtr_rts)
>> port->ops->dtr_rts(port, 1);
>> }
>> EXPORT_SYMBOL(tty_port_raise_dtr_rts);
>> @@ -429,7 +429,7 @@ EXPORT_SYMBOL(tty_port_raise_dtr_rts);
>>*/
>> void tty_port_lower_dtr_rts(struct tty_port *port)
>> {
>> -if (port->ops->dtr_rts)
>> +if (port->ops && port->ops->dtr_rts)
>> port->ops->dtr_rts(port, 0);
>> }
>> EXPORT_SYMBOL(tty_port_lower_dtr_rts);
>> @@ -684,7 +684,7 @@ int tty_port_open(struct tty_port *port, struct
>> tty_struct *tty,
>>
>> if (!tty_port_initialized(port)) {
>> clear_bit(TTY_IO_ERROR, &tty->flags);
>> -if (port->ops->activate) {
>> +if (port->ops && port->ops->activate) {
>> int retval = port->ops->activate(port, tty);
>> if (retval) {
>> mutex_unlock(&port->mutex);
>> --
>> 2.7.4
>>
> Can you hit this today with any in-kernel drivers? Or is this only for
> your new code you are adding?
>
> thanks,
>
> greg k-h
Re: [PATCH 04/25] dt-bindings: leds: Add LED_COLOR_NAME definitions
On Sun 2019-03-10 19:28:15, Jacek Anaszewski wrote: > Add common LED color name definitions for use in Device Tree. Could we do "LED_COLOR_NAME_" => "LED_COLOR_"? Pavel > Signed-off-by: Jacek Anaszewski > Cc: Baolin Wang > Cc: Daniel Mack > Cc: Dan Murphy > Cc: Linus Walleij > Cc: Oleh Kravchenko > Cc: Sakari Ailus > Cc: Simon Shields > --- > include/dt-bindings/leds/common.h | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/include/dt-bindings/leds/common.h > b/include/dt-bindings/leds/common.h > index ffcd46317307..0e986bb59391 100644 > --- a/include/dt-bindings/leds/common.h > +++ b/include/dt-bindings/leds/common.h > @@ -57,4 +57,13 @@ > #define LED_FUNCTION_WLAN "wlan" > #define LED_FUNCTION_WPS "wps" > > +/* Standard LED colors */ > +#define LED_COLOR_NAME_WHITE"white" > +#define LED_COLOR_NAME_RED "red" > +#define LED_COLOR_NAME_GREEN"green" > +#define LED_COLOR_NAME_BLUE "blue" > +#define LED_COLOR_NAME_AMBER"amber" > +#define LED_COLOR_NAME_VIOLET "violet" > +#define LED_COLOR_NAME_YELLOW "yellow" > + > #endif /* __DT_BINDINGS_LEDS_H */ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH v2 2/8] evmtest: test loading IMA policies
From: David Jacobson
IMA can be configured to require signatures on policies before loading
them. This test verifies that IMA correctly validates signatures, and
rejects policies that lack signatures or have been signed by an
unauthorized party (i.e. certificate is not on the appropriate keyring).
This test requires root privileges in order to write to securityfs
files.
Signed-off-by: David Jacobson
Changelog:
* Placed policy_sig on list of tests
* make sure key exists
* shellcheck compliant
* Update makefiles with tests instead of functions
* removed begin
* removed long opts
* Notes file is updated in correct patch
* restructure to use functions
* reword usage
* reworded patch title
* Fixed changes in Notes
* renamed key
* Cut down on functions
---
evmtest/Makefile.am | 6 +-
evmtest/README | 1 +
evmtest/evmtest | 1 +
evmtest/files/Notes | 16 +++
evmtest/files/policies/signed_policy | 2 +
evmtest/files/policies/unknown_signed_policy | 1 +
evmtest/files/policies/unsigned_policy | 1 +
evmtest/tests/policy_sig.sh | 110 +++
evmtest/unknown_privkey_ima.pem | 16 +++
9 files changed, 153 insertions(+), 1 deletion(-)
create mode 100644 evmtest/files/policies/signed_policy
create mode 100644 evmtest/files/policies/unknown_signed_policy
create mode 100644 evmtest/files/policies/unsigned_policy
create mode 100755 evmtest/tests/policy_sig.sh
create mode 100644 evmtest/unknown_privkey_ima.pem
diff --git a/evmtest/Makefile.am b/evmtest/Makefile.am
index e74feaf..496a5de 100644
--- a/evmtest/Makefile.am
+++ b/evmtest/Makefile.am
@@ -14,9 +14,13 @@ evmtest.1:
install:
install -m 755 evmtest $(bindir)
install -d $(datarootdir)/evmtest/files/
+ install -d $(datarootdir)/evmtest/files/policies
install -d $(datarootdir)/evmtest/tests/
- install -D $$(find ./files/ -not -type d) $(datarootdir)/evmtest/files/
+ install -D \
+ $$(find ./files/ -not -type d -not -path "./files/policies/*") \
+ $(datarootdir)/evmtest/files/
install -D ./tests/* $(datarootdir)/evmtest/tests/
+ install -D ./files/policies/* $(datarootdir)/evmtest/files/policies/
cp evmtest.1 $(datarootdir)/man/man1
mandb -q
diff --git a/evmtest/README b/evmtest/README
index 5a44070..480f426 100644
--- a/evmtest/README
+++ b/evmtest/README
@@ -38,6 +38,7 @@ TEST NAMES
env_validate - verify kernel build
example_test - example test
+ policy_sig - verify loading IMA policies
Introduction
diff --git a/evmtest/evmtest b/evmtest/evmtest
index d579d03..9902e61 100755
--- a/evmtest/evmtest
+++ b/evmtest/evmtest
@@ -28,6 +28,7 @@ usage (){
# placement of a script in tests/
echo "[R] env_validate"
echo "[ ] examples_test"
+ echo "[R] policy_sig"
echo ""
echo "Note: Tests may be run directly from the \"tests\" directory"
diff --git a/evmtest/files/Notes b/evmtest/files/Notes
index f20a272..8aa2670 100644
--- a/evmtest/files/Notes
+++ b/evmtest/files/Notes
@@ -3,3 +3,19 @@ This file contains a description of the contents of this
directory.
1. common.sh
This file contains useful functions and variables for evmtest scripts.
+
+2. load_policy.sh
+
+This is a script to load policies. The first time this is called, it will
+replace the existing policy. Subsequent calls will append additional rules to
+the existing policy.
+
+3. policies/
+
+This is a directory that contains IMA policies with self explanatory names.
+
+4. unknown_privkey_ima.pem
+
+This file was generated such that its corresponding public key could be placed
+on the IMA Trusted Keyring, however, it has not. Therefore, any policy (or
file)
+signed by this key cannot be verified, and is untrusted.
diff --git a/evmtest/files/policies/signed_policy
b/evmtest/files/policies/signed_policy
new file mode 100644
index 000..87828f0
--- /dev/null
+++ b/evmtest/files/policies/signed_policy
@@ -0,0 +1,2 @@
+measure func=POLICY_CHECK
+appraise func=POLICY_CHECK appraise_type=imasig
diff --git a/evmtest/files/policies/unknown_signed_policy
b/evmtest/files/policies/unknown_signed_policy
new file mode 100644
index 000..1f8f8f4
--- /dev/null
+++ b/evmtest/files/policies/unknown_signed_policy
@@ -0,0 +1 @@
+audit func=POLICY_CHECK
diff --git a/evmtest/files/policies/unsigned_policy
b/evmtest/files/policies/unsigned_policy
new file mode 100644
index 000..1f8f8f4
--- /dev/null
+++ b/evmtest/files/policies/unsigned_policy
@@ -0,0 +1 @@
+audit func=POLICY_CHECK
diff --git a/evmtest/tests/policy_sig.sh b/evmtest/tests/policy_sig.sh
new file mode 100755
index 000..174d111
--- /dev/null
+++ b/evmtest/tests/policy_sig.sh
@@ -0,0 +1,110 @@
+#!/bin/bash
+TEST="policy_sig"
+# Author: David Jacobson
+
+ROOT="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/nu
Re: [PATCH] regulator: axp20x: Mark expected switch fall-throughs
On Thu, Mar 21, 2019 at 12:57 AM Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch > cases where we are expecting to fall through. > > This patch fixes the following warnings: > > drivers/regulator/axp20x-regulator.c: In function ‘axp20x_set_dcdc_freq’: > drivers/regulator/axp20x-regulator.c:1023:7: warning: this statement may fall > through [-Wimplicit-fallthrough=] >reg = AXP803_DCDC_FREQ_CTRL; > drivers/regulator/axp20x-regulator.c:1025:2: note: here > case AXP806_ID: > ^~~~ > drivers/regulator/axp20x-regulator.c: In function ‘axp20x_set_dcdc_workmode’: > drivers/regulator/axp20x-regulator.c:1115:7: warning: this statement may fall > through [-Wimplicit-fallthrough=] >reg = AXP806_DCDC_MODE_CTRL2; > drivers/regulator/axp20x-regulator.c:1121:2: note: here > case AXP221_ID: > ^~~~ > > Notice that in this particular case, I moved the whole comment > "Fall through to the check below.", which contains the "Fall through" > comment, at the bottom of the case, which is what GCC is expecting > to find. > > Warning level 3 was used: -Wimplicit-fallthrough=3 > > This patch is part of the ongoing efforts to enable > -Wimplicit-fallthrough. > > Signed-off-by: Gustavo A. R. Silva Acked-by: Chen-Yu Tsai
Re: [PATCH] mfd: axp20x: Allow the AXP223 to be probed by i2c
On Mon, Mar 18, 2019 at 8:55 PM Maxime Ripard wrote: > > The AXP223 can be used both using the RSB proprietary bus, or a more > traditional I2C bus. The RSB is a faster bus and provides more features > (like some integrity checks on the messages), so it's usually preferrable > to use it, but since it's proprietary, when we want to use the PMIC in a > multi-master setup, the i2c might make sense as well. > > Let's add that possibility. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai
Re: [PATCH] ARM: dts: sun8i: a23/a33: Add R_I2C Controller
On Mon, Mar 18, 2019 at 8:56 PM Maxime Ripard wrote: > > The A23 and A33 both have an I2C controller in the ARISC domain, that share > the same pins with the RSB bus. > > Even if it's an unusual configuration, that device can be used to drive the > PMIC, so let's use it. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai
[PATCH 0/4] phy: ti-pipe3: Match TRM sequence & settings
Hi Kishon, We need to follow the TRM sequence and settings to ensure that the DPLL & PHY operates correctly over the entire temperature range. Tested for SATA and USB. PCIe not tested. Since this is a bug fix, please queue this for v5.1-rc. Thanks. cheers, -roger Roger Quadros (4): phy: ti-pipe3: Introduce mode property in driver data phy: ti-pipe3: improve DPLL stability for SATA & USB phy: ti-pipe3: Fix SATA & USB PHY power up sequence phy: ti-pipe3: Fix PCIe power up sequence drivers/phy/ti/phy-ti-pipe3.c | 362 +- 1 file changed, 265 insertions(+), 97 deletions(-) -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RESEND PATCH v6 01/11] dt-bindings: mfd: add DT bindings for max77650
On Mon 2019-03-18 18:40:30, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add a DT binding document for max77650 ultra-low power PMIC. This > describes the core mfd device and the GPIO module. > > Signed-off-by: Bartosz Golaszewski > Reviewed-by: Rob Herring Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH 1/4] phy: ti-pipe3: Introduce mode property in driver data
Introduce a mode property in the driver data so that
we don't have to keep using "of_device_is_compatible()"
throughtout the driver.
No functional change.
Signed-off-by: Roger Quadros
---
drivers/phy/ti/phy-ti-pipe3.c | 93 +--
1 file changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index 68ce4a082b9b..0913dd55d82a 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -110,6 +110,10 @@
#define PLL_IDLE_TIME 100 /* in milliseconds */
#define PLL_LOCK_TIME 100 /* in milliseconds */
+enum pipe3_mode { PIPE3_MODE_PCIE = 1,
+ PIPE3_MODE_SATA,
+ PIPE3_MODE_USBSS };
+
struct pipe3_dpll_params {
u16 m;
u8 n;
@@ -141,6 +145,7 @@ struct ti_pipe3 {
unsigned intpower_reg; /* power reg. index within syscon */
unsigned intpcie_pcs_reg; /* pcs reg. index in syscon */
boolsata_refclk_enabled;
+ enum pipe3_mode mode;
};
static struct pipe3_dpll_map dpll_map_usb[] = {
@@ -163,6 +168,25 @@ static struct pipe3_dpll_map dpll_map_sata[] = {
{ },/* Terminator */
};
+struct pipe3_data {
+ enum pipe3_mode mode;
+ struct pipe3_dpll_map *dpll_map;
+};
+
+static struct pipe3_data data_usb = {
+ .mode = PIPE3_MODE_USBSS,
+ .dpll_map = dpll_map_usb,
+};
+
+static struct pipe3_data data_sata = {
+ .mode = PIPE3_MODE_SATA,
+ .dpll_map = dpll_map_sata,
+};
+
+static struct pipe3_data data_pcie = {
+ .mode = PIPE3_MODE_PCIE,
+};
+
static inline u32 ti_pipe3_readl(void __iomem *addr, unsigned offset)
{
return __raw_readl(addr + offset);
@@ -340,7 +364,7 @@ static int ti_pipe3_init(struct phy *x)
* as recommended in AM572x TRM SPRUHZ6, section 18.5.2.2, table
* 18-1804.
*/
- if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
+ if (phy->mode == PIPE3_MODE_PCIE) {
if (!phy->pcs_syscon) {
omap_control_pcie_pcs(phy->control_dev, 0x96);
return 0;
@@ -367,8 +391,7 @@ static int ti_pipe3_init(struct phy *x)
/* SATA has issues if re-programmed when locked */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
- if ((val & PLL_LOCK) && of_device_is_compatible(phy->dev->of_node,
- "ti,phy-pipe3-sata"))
+ if ((val & PLL_LOCK) && phy->mode == PIPE3_MODE_SATA)
return ret;
/* Program the DPLL */
@@ -390,12 +413,11 @@ static int ti_pipe3_exit(struct phy *x)
/* If dpll_reset_syscon is not present we wont power down SATA DPLL
* due to Errata i783
*/
- if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata") &&
- !phy->dpll_reset_syscon)
+ if (phy->mode == PIPE3_MODE_SATA && !phy->dpll_reset_syscon)
return 0;
/* PCIe doesn't have internal DPLL */
- if (!of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie")) {
+ if (phy->mode != PIPE3_MODE_PCIE) {
/* Put DPLL in IDLE mode */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
val |= PLL_IDLE;
@@ -418,7 +440,7 @@ static int ti_pipe3_exit(struct phy *x)
}
/* i783: SATA needs control bit toggle after PLL unlock */
- if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata")) {
+ if (phy->mode == PIPE3_MODE_SATA) {
regmap_update_bits(phy->dpll_reset_syscon, phy->dpll_reset_reg,
SATA_PLL_SOFT_RESET, SATA_PLL_SOFT_RESET);
regmap_update_bits(phy->dpll_reset_syscon, phy->dpll_reset_reg,
@@ -443,7 +465,6 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
{
struct clk *clk;
struct device *dev = phy->dev;
- struct device_node *node = dev->of_node;
phy->refclk = devm_clk_get(dev, "refclk");
if (IS_ERR(phy->refclk)) {
@@ -451,11 +472,11 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
/* older DTBs have missing refclk in SATA PHY
* so don't bail out in case of SATA PHY.
*/
- if (!of_device_is_compatible(node, "ti,phy-pipe3-sata"))
+ if (phy->mode != PIPE3_MODE_SATA)
return PTR_ERR(phy->refclk);
}
- if (!of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
+ if (phy->mode != PIPE3_MODE_SATA) {
phy->wkupclk = devm_clk_get(dev, "wkupclk");
if (IS_ERR(phy->wkupclk)) {
dev_err(dev, "unable to get wkupclk\n");
@@ -465,8 +486,7 @@ static int ti_pipe3_get_clk(struct ti_pipe3 *phy)
phy->wkupclk = ERR_PTR(-ENODEV)
[PATCH 4/4] phy: ti-pipe3: Fix PCIe power up sequence
TRM [1] mentions that we need to power up
PCIESS_PHY_TX and PCIESS_PHY_RX before configuring
PCIe_PHY_RX SCP settings.
See "Table 26-81. PCIePHY Subsystem Low-Level Programming Sequence".
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti/phy-ti-pipe3.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index 71a7634c026d..1718ef36d290 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -341,6 +341,8 @@ static int ti_pipe3_power_off(struct phy *x)
return ret;
}
+static void ti_pipe3_calibrate(struct ti_pipe3 *phy);
+
static int ti_pipe3_power_on(struct phy *x)
{
u32 val;
@@ -386,6 +388,9 @@ static int ti_pipe3_power_on(struct phy *x)
mask, val);
}
+ if (phy->mode == PIPE3_MODE_PCIE)
+ ti_pipe3_calibrate(phy);
+
return 0;
}
@@ -520,12 +525,7 @@ static int ti_pipe3_init(struct phy *x)
val = 0x96 << OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT;
ret = regmap_update_bits(phy->pcs_syscon, phy->pcie_pcs_reg,
PCIE_PCS_MASK, val);
- if (ret)
- return ret;
-
- ti_pipe3_calibrate(phy);
-
- return 0;
+ return ret;
}
/* Bring it out of IDLE if it is IDLE */
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 2/4] phy: ti-pipe3: improve DPLL stability for SATA & USB
For increased DPLL stability use the settings recommended in
the TRM [1] for PHY_RX registers for SATA and USB.
For SATA we need to use spread spectrum settings even
though we don't have spread spectrum enabled. The
suggested non-spread spectrum settings don't work.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti/phy-ti-pipe3.c | 215 +++---
1 file changed, 173 insertions(+), 42 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index 0913dd55d82a..cdc994f153b2 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -68,39 +68,61 @@
#define PCIE_PCS_MASK 0xFF
#define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
-#define PCIEPHYRX_ANA_PROGRAMMABILITY 0x000C
+#define PIPE3_PHY_RX_ANA_PROGRAMMABILITY 0x000C
#define INTERFACE_MASK GENMASK(31, 27)
#define INTERFACE_SHIFT27
+#define INTERFACE_MODE_USBSS BIT(4)
+#define INTERFACE_MODE_SATA_1P5BIT(3)
+#define INTERFACE_MODE_SATA_3P0BIT(2)
+#define INTERFACE_MODE_PCIEBIT(0)
+
#define LOSD_MASK GENMASK(17, 14)
#define LOSD_SHIFT 14
#define MEM_PLLDIV GENMASK(6, 5)
-#define PCIEPHYRX_TRIM 0x001C
-#define MEM_DLL_TRIM_SEL GENMASK(31, 30)
+#define PIPE3_PHY_RX_TRIM 0x001C
+#define MEM_DLL_TRIM_SEL_MASK GENMASK(31, 30)
#define MEM_DLL_TRIM_SHIFT 30
-#define PCIEPHYRX_DLL 0x0024
-#define MEM_DLL_PHINT_RATE GENMASK(31, 30)
+#define PIPE3_PHY_RX_DLL 0x0024
+#define MEM_DLL_PHINT_RATE_MASKGENMASK(31, 30)
+#define MEM_DLL_PHINT_RATE_SHIFT 30
-#define PCIEPHYRX_DIGITAL_MODES0x0028
+#define PIPE3_PHY_RX_DIGITAL_MODES 0x0028
+#define MEM_HS_RATE_MASK GENMASK(28, 27)
+#define MEM_HS_RATE_SHIFT 27
+#define MEM_OVRD_HS_RATE BIT(26)
+#define MEM_OVRD_HS_RATE_SHIFT 26
#define MEM_CDR_FASTLOCK BIT(23)
-#define MEM_CDR_LBWGENMASK(22, 21)
-#define MEM_CDR_STEPCNTGENMASK(20, 19)
+#define MEM_CDR_FASTLOCK_SHIFT 23
+#define MEM_CDR_LBW_MASK GENMASK(22, 21)
+#define MEM_CDR_LBW_SHIFT 21
+#define MEM_CDR_STEPCNT_MASK GENMASK(20, 19)
+#define MEM_CDR_STEPCNT_SHIFT 19
#define MEM_CDR_STL_MASK GENMASK(18, 16)
#define MEM_CDR_STL_SHIFT 16
#define MEM_CDR_THR_MASK GENMASK(15, 13)
#define MEM_CDR_THR_SHIFT 13
#define MEM_CDR_THR_MODE BIT(12)
-#define MEM_CDR_CDR_2NDO_SDM_MODE BIT(11)
-#define MEM_OVRD_HS_RATE BIT(26)
-
-#define PCIEPHYRX_EQUALIZER0x0038
-#define MEM_EQLEV GENMASK(31, 16)
-#define MEM_EQFTC GENMASK(15, 11)
-#define MEM_EQCTL GENMASK(10, 7)
+#define MEM_CDR_THR_MODE_SHIFT 12
+#define MEM_CDR_2NDO_SDM_MODE BIT(11)
+#define MEM_CDR_2NDO_SDM_MODE_SHIFT11
+
+#define PIPE3_PHY_RX_EQUALIZER 0x0038
+#define MEM_EQLEV_MASK GENMASK(31, 16)
+#define MEM_EQLEV_SHIFT16
+#define MEM_EQFTC_MASK GENMASK(15, 11)
+#define MEM_EQFTC_SHIFT11
+#define MEM_EQCTL_MASK GENMASK(10, 7)
#define MEM_EQCTL_SHIFT7
#define MEM_OVRD_EQLEV BIT(2)
+#define MEM_OVRD_EQLEV_SHIFT 2
#define MEM_OVRD_EQFTC BIT(1)
+#define MEM_OVRD_EQFTC_SHIFT 1
+
+#define SATA_PHY_RX_IO_AND_A2D_OVERRIDES 0x44
+#define MEM_CDR_LOS_SOURCE_MASKGENMASK(10, 9)
+#define MEM_CDR_LOS_SOURCE_SHIFT 9
/*
* This is an Empirical value that works, need to confirm the actual
@@ -127,6 +149,27 @@ struct pipe3_dpll_map {
struct pipe3_dpll_params params;
};
+struct pipe3_settings {
+ u8 ana_interface;
+ u8 ana_losd;
+ u8 dig_fastlock;
+ u8 dig_lbw;
+ u8 dig_stepcnt;
+ u8 dig_stl;
+ u8 dig_thr;
+ u8 dig_thr_mode;
+ u8 dig_2ndo_sdm_mode;
+ u8 dig_hs_rate;
+ u8 dig_ovrd_hs_rate;
+ u8 dll_trim_sel;
+ u8 dll_phint_rate;
+ u8 eq_lev;
+ u8 eq_ftc;
+ u8 eq_ctl;
+ u8 eq_ovrd_lev;
+ u8 eq_ovrd_ftc;
+};
+
struct ti_pipe3 {
void __iomem*pll_ctrl_base;
void __iomem*phy_rx;
@@ -146,6 +189,7 @@ struct ti_pipe3 {
unsigned intpcie_pcs_reg; /* pcs reg. index in syscon */
boolsata_refclk_enabled;
enum pipe3_mode mode;
+ struct pipe3_settings se
[PATCH 3/4] phy: ti-pipe3: Fix SATA & USB PHY power up sequence
As per "Table 26-7. SATA PHY Subsystem Low-Level Programming Sequence"
in TRM [1] we need to turn on SATA_PHY_TX before SATA_PHY_RX.
[1] DRA75x, DRA74x TRM - http://www.ti.com/lit/ug/sprui30f/sprui30f.pdf
Signed-off-by: Roger Quadros
---
drivers/phy/ti/phy-ti-pipe3.c | 44 ---
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
index cdc994f153b2..71a7634c026d 100644
--- a/drivers/phy/ti/phy-ti-pipe3.c
+++ b/drivers/phy/ti/phy-ti-pipe3.c
@@ -56,14 +56,14 @@
#define SATA_PLL_SOFT_RESETBIT(18)
-#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK 0x003FC000
+#define PIPE3_PHY_PWRCTL_CLK_CMD_MASK GENMASK(21, 14)
#define PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT 14
-#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK 0xFFC0
+#define PIPE3_PHY_PWRCTL_CLK_FREQ_MASK GENMASK(31, 22)
#define PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT22
-#define PIPE3_PHY_TX_RX_POWERON0x3
-#define PIPE3_PHY_TX_RX_POWEROFF 0x0
+#define PIPE3_PHY_RX_POWERON (0x1 << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT)
+#define PIPE3_PHY_TX_POWERON (0x2 << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT)
#define PCIE_PCS_MASK 0xFF
#define PCIE_PCS_DELAY_COUNT_SHIFT 0x10
@@ -328,7 +328,6 @@ static void ti_pipe3_disable_clocks(struct ti_pipe3 *phy);
static int ti_pipe3_power_off(struct phy *x)
{
- u32 val;
int ret;
struct ti_pipe3 *phy = phy_get_drvdata(x);
@@ -337,10 +336,8 @@ static int ti_pipe3_power_off(struct phy *x)
return 0;
}
- val = PIPE3_PHY_TX_RX_POWEROFF << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
-
ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
-PIPE3_PHY_PWRCTL_CLK_CMD_MASK, val);
+PIPE3_PHY_PWRCTL_CLK_CMD_MASK, 0);
return ret;
}
@@ -351,6 +348,7 @@ static int ti_pipe3_power_on(struct phy *x)
int ret;
unsigned long rate;
struct ti_pipe3 *phy = phy_get_drvdata(x);
+ bool rx_pending = false;
if (!phy->phy_power_syscon) {
omap_control_phy_power(phy->control_dev, 1);
@@ -363,14 +361,32 @@ static int ti_pipe3_power_on(struct phy *x)
return -EINVAL;
}
rate = rate / 100;
- mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
- val = PIPE3_PHY_TX_RX_POWERON << PIPE3_PHY_PWRCTL_CLK_CMD_SHIFT;
- val |= rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
-
+ mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_MASK;
+ val = rate << OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_FREQ_SHIFT;
ret = regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
mask, val);
- return ret;
+ /*
+* For PCIe, TX and RX must be powered on simultaneously.
+* For USB and SATA, TX must be powered on before RX
+*/
+ mask = OMAP_CTRL_PIPE3_PHY_PWRCTL_CLK_CMD_MASK;
+ if (phy->mode == PIPE3_MODE_SATA || phy->mode == PIPE3_MODE_USBSS) {
+ val = PIPE3_PHY_TX_POWERON;
+ rx_pending = true;
+ } else {
+ val = PIPE3_PHY_TX_POWERON | PIPE3_PHY_RX_POWERON;
+ }
+
+ regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+ mask, val);
+
+ if (rx_pending) {
+ val = PIPE3_PHY_TX_POWERON | PIPE3_PHY_RX_POWERON;
+ regmap_update_bits(phy->phy_power_syscon, phy->power_reg,
+ mask, val);
+ }
+
+ return 0;
}
static int ti_pipe3_dpll_wait_lock(struct ti_pipe3 *phy)
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RESEND PATCH v6 02/11] dt-bindings: power: supply: add DT bindings for max77650
On Mon 2019-03-18 18:40:31, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add the DT binding document for the battery charger module of max77650. > > Signed-off-by: Bartosz Golaszewski > --- > .../power/supply/max77650-charger.txt | 27 +++ > 1 file changed, 27 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/power/supply/max77650-charger.txt > > diff --git > a/Documentation/devicetree/bindings/power/supply/max77650-charger.txt > b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt > new file mode 100644 > index ..d25c95369616 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/supply/max77650-charger.txt > @@ -0,0 +1,27 @@ > +Battery charger driver for MAX77650 PMIC from Maxim Integrated. > + > +This module is part of the MAX77650 MFD device. For more details > +see Documentation/devicetree/bindings/mfd/max77650.txt. > + > +The charger is represented as a sub-node of the PMIC node on the device tree. > + > +Required properties: > + > +- compatible:Must be "maxim,max77650-charger" > + > +Optional properties: > + > +- min-microvolt: Minimum CHGIN regulation voltage (in microvolts). Must > be > + one of: 400, 410, 420, 430, 440, > + 450, 460, 470. Probably needs "max," prefix. And .. what does this mean? Will charger shutdown if input is less than this? > +- curr-lim-microamp: CHGIN input current limit (in microamps). Must be one > of: > + 95000, 19, 285000, 38, 475000. "current-limit-microamp", I guess. And probably "max,current-limit-microamp". -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [RESEND PATCH v6 03/11] dt-bindings: leds: add DT bindings for max77650
On Mon 2019-03-18 18:40:32, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add the DT binding document for the LEDs module of max77650.
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Rob Herring
Acked-by: Pavel Machek
> + led@0 {
> + reg = <0>;
> + label = "blue:usr0";
> + };
I'd rather not see these "usrX" things... Does it have some kind of
real function?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH 2/2] PM / arch: x86: MSR_IA32_ENERGY_PERF_BIAS sysfs interface
On 3/21/19 11:20 PM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki The Performance and Energy Bias Hint (EPB) is expected to be set by user space through the generic MSR interface, but that interface is not particularly nice and there are security concerns regarding it, so it is not always available. For this reason, add a sysfs interface for reading and updating the EPB, in the form of a new attribute, energy_perf_bias, located under /sys/devices/system/cpu/cpu#/power/ for online CPUs that support the EPB feature. Signed-off-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-devices-system-cpu | 18 Documentation/admin-guide/pm/intel_epb.rst | 27 ++ arch/x86/kernel/cpu/intel_epb.c| 93 - 3 files changed, 134 insertions(+), 4 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH 1/2] PM / arch: x86: Rework the MSR_IA32_ENERGY_PERF_BIAS handling
On 3/21/19 11:18 PM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
The current handling of MSR_IA32_ENERGY_PERF_BIAS in the kernel is
problematic, because it may cause changes made by user space to that
MSR (with the help of the x86_energy_perf_policy tool, for example)
to be lost every time a CPU goes offline and then back online as well
as during system-wide power management transitions into sleep states
and back into the working state.
The first problem is that if the current EPB value for a CPU going
online is 0 ('performance'), the kernel will change it to 6 ('normal')
regardless of whether or not this is the first bring-up of that CPU.
That also happens during system-wide resume from sleep states
(including, but not limited to, hibernation). However, the EPB may
have been adjusted by user space this way and the kernel should not
blindly override that setting.
The second problem is that if the platform firmware resets the EPB
values for any CPUs during system-wide resume from a sleep state,
the kernel will not restore their previous EPB values that may
have been set by user space before the preceding system-wide
suspend transition. Again, that behavior may at least be confusing
from the user space perspective.
In order to address these issues, rework the handling of
MSR_IA32_ENERGY_PERF_BIAS so that the EPB value is saved on CPU
offline and restored on CPU online as well as (for the boot CPU)
during the syscore stages of system-wide suspend and resume
transitions, respectively.
However, retain the policy by which the EPB is set to 6 ('normal')
on the first bring-up of each CPU if its initial value is 0, based
on the observation that 0 may mean 'not initialized' just as well as
'performance' in that case.
While at it, move the MSR_IA32_ENERGY_PERF_BIAS handling code into
a separate file and document it in Documentation/admin-guide.
Fixes: abe48b108247 (x86, intel, power: Initialize MSR_IA32_ENERGY_PERF_BIAS)
Fixes: b51ef52df71c (x86/cpu: Restore MSR_IA32_ENERGY_PERF_BIAS after resume)
Reported-by: Thomas Renninger
Signed-off-by: Rafael J. Wysocki
---
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
[PATCH] ASoC: AMD: Configure wclk and bclk of master codec
With CCF support in da7219, we can now set the correct rate of
wclk and bclk.
Setting bclk at lower rate at 1.53Mhz from its earlier default
rate of 3Mhz, also fixes noise issue observed on some dmics.
Signed-off-by: Akshu Agrawal
---
sound/soc/amd/acp-da7219-max98357a.c | 40 +---
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/sound/soc/amd/acp-da7219-max98357a.c
b/sound/soc/amd/acp-da7219-max98357a.c
index f37a588ba345..1bb5b78b6e10 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -46,7 +46,8 @@
#define DUAL_CHANNEL 2
static struct snd_soc_jack cz_jack;
-static struct clk *da7219_dai_clk;
+static struct clk *da7219_dai_wclk;
+static struct clk *da7219_dai_bclk;
extern int bt_uart_enable;
static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
@@ -72,7 +73,8 @@ static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
return ret;
}
- da7219_dai_clk = clk_get(component->dev, "da7219-dai-bclk");
+ da7219_dai_wclk = clk_get(component->dev, "da7219-dai-wclk");
+ da7219_dai_bclk = clk_get(component->dev, "da7219-dai-bclk");
ret = snd_soc_card_jack_new(card, "Headset Jack",
SND_JACK_HEADSET | SND_JACK_LINEOUT |
@@ -94,12 +96,15 @@ static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
-static int da7219_clk_enable(struct snd_pcm_substream *substream)
+static int da7219_clk_enable(struct snd_pcm_substream *substream,
+int wclk_rate, int bclk_rate)
{
int ret = 0;
struct snd_soc_pcm_runtime *rtd = substream->private_data;
- ret = clk_prepare_enable(da7219_dai_clk);
+ clk_set_rate(da7219_dai_wclk, wclk_rate);
+ clk_set_rate(da7219_dai_bclk, bclk_rate);
+ ret = clk_prepare_enable(da7219_dai_bclk);
if (ret < 0) {
dev_err(rtd->dev, "can't enable master clock %d\n", ret);
return ret;
@@ -110,7 +115,7 @@ static int da7219_clk_enable(struct snd_pcm_substream
*substream)
static void da7219_clk_disable(void)
{
- clk_disable_unprepare(da7219_dai_clk);
+ clk_disable_unprepare(da7219_dai_bclk);
}
static const unsigned int channels[] = {
@@ -151,7 +156,7 @@ static int cz_da7219_play_startup(struct snd_pcm_substream
*substream)
&constraints_rates);
machine->play_i2s_instance = I2S_SP_INSTANCE;
- return da7219_clk_enable(substream);
+ return 0;
}
static int cz_da7219_cap_startup(struct snd_pcm_substream *substream)
@@ -173,7 +178,7 @@ static int cz_da7219_cap_startup(struct snd_pcm_substream
*substream)
machine->cap_i2s_instance = I2S_SP_INSTANCE;
machine->capture_channel = CAP_CHANNEL1;
- return da7219_clk_enable(substream);
+ return 0;
}
static void cz_da7219_shutdown(struct snd_pcm_substream *substream)
@@ -199,7 +204,7 @@ static int cz_max_startup(struct snd_pcm_substream
*substream)
&constraints_rates);
machine->play_i2s_instance = I2S_BT_INSTANCE;
- return da7219_clk_enable(substream);
+ return 0;
}
static void cz_max_shutdown(struct snd_pcm_substream *substream)
@@ -225,7 +230,7 @@ static int cz_dmic0_startup(struct snd_pcm_substream
*substream)
&constraints_rates);
machine->cap_i2s_instance = I2S_BT_INSTANCE;
- return da7219_clk_enable(substream);
+ return 0;
}
static int cz_dmic1_startup(struct snd_pcm_substream *substream)
@@ -247,7 +252,7 @@ static int cz_dmic1_startup(struct snd_pcm_substream
*substream)
machine->cap_i2s_instance = I2S_SP_INSTANCE;
machine->capture_channel = CAP_CHANNEL0;
- return da7219_clk_enable(substream);
+ return 0;
}
static void cz_dmic_shutdown(struct snd_pcm_substream *substream)
@@ -255,29 +260,44 @@ static void cz_dmic_shutdown(struct snd_pcm_substream
*substream)
da7219_clk_disable();
}
+static int cz_da7219_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ int wclk, bclk;
+
+ wclk = params_rate(params);
+ bclk = wclk * params_channels(params) *
+ snd_pcm_format_width(params_format(params));
+ return da7219_clk_enable(substream, wclk, bclk);
+}
static const struct snd_soc_ops cz_da7219_play_ops = {
.startup = cz_da7219_play_startup,
.shutdown = cz_da7219_shutdown,
+ .hw_params = cz_da7219_hw_params,
};
static const struct snd_soc_ops cz_da7219_cap_ops = {
.startup = cz_da7219_cap_startup,
.shutdown = cz_da7219_shutdown,
+ .hw_params = cz_da7219_hw_params,
};
static const struct snd_soc_ops cz_max_play_ops = {
.startup = cz_max_startup,
.shutdown = cz_max_shutdown,
+ .hw_params = cz_da7219_h
Re: [RESEND PATCH v6 04/11] dt-bindings: input: add DT bindings for max77650
On Mon 2019-03-18 18:42:21, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Add the DT binding document for the onkey module of max77650.
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Rob Herring
> + onkey {
> + compatible = "maxim,max77650-onkey";
> + linux,code = ;
> + maxim,onkey-slide;
> + };
This is certainly wrong.
"End" key is normal key on a keyboard, certainly not some kind of
slider.
And this controller is likely to be used for power key, not end key,
right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [RESEND PATCH v6 05/11] mfd: core: document mfd_add_devices()
On Mon 2019-03-18 18:42:22, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add a kernel doc for mfd_add_devices(). > > Signed-off-by: Bartosz Golaszewski Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [RESEND PATCH v6 06/11] mfd: max77650: new core mfd driver
On Mon 2019-03-18 18:42:23, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add the core mfd driver for max77650 PMIC. We define five sub-devices > for which the drivers will be added in subsequent patches. > > Signed-off-by: Bartosz Golaszewski > --- > drivers/mfd/Kconfig | 14 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/max77650.c | 234 +++ > include/linux/mfd/max77650.h | 59 + > 4 files changed, 308 insertions(+) > create mode 100644 drivers/mfd/max77650.c > create mode 100644 include/linux/mfd/max77650.h > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 0ce2d8dfc5f1..ade04e124aa0 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -733,6 +733,20 @@ config MFD_MAX77620 > provides common support for accessing the device; additional drivers > must be enabled in order to use the functionality of the device. > > +config MFD_MAX77650 > + tristate "Maxim MAX77650/77651 PMIC Support" > + depends on I2C > + depends on OF || COMPILE_TEST This says it will compile ok in !OF case. Will it? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH] mfd: sun6i-prcm: Allow to compile with COMPILE_TEST
Since this driver only has a dependency on ARCH_SUNXI just because it doesn't make any sense to run it on something else, we can definitely enable it through COMPILE_TEST as well to get some build coverage. Signed-off-by: Maxime Ripard --- drivers/mfd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 0ce2d8dfc5f1..26ad6468d13a 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1246,7 +1246,7 @@ config MFD_STA2X11 config MFD_SUN6I_PRCM bool "Allwinner A31 PRCM controller" - depends on ARCH_SUNXI + depends on ARCH_SUNXI || COMPILE_TEST select MFD_CORE help Support for the PRCM (Power/Reset/Clock Management) unit available -- 2.20.1
Re: linux-next: build warning after merge of the sunxi tree
Hi,
On Fri, Mar 22, 2019 at 08:30:48AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the sunxi tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> WARNING: unmet direct dependencies detected for MFD_SUN6I_PRCM
> Depends on [n]: HAS_IOMEM [=y] && ARCH_SUNXI
> Selected by [y]:
> - CLK_SUNXI_PRCM_SUN6I [=y] && COMMON_CLK [=y] && CLK_SUNXI [=y]
> - CLK_SUNXI_PRCM_SUN8I [=y] && COMMON_CLK [=y] && CLK_SUNXI [=y]
>
> WARNING: unmet direct dependencies detected for MFD_SUN6I_PRCM
> Depends on [n]: HAS_IOMEM [=y] && ARCH_SUNXI
> Selected by [y]:
> - CLK_SUNXI_PRCM_SUN6I [=y] && COMMON_CLK [=y] && CLK_SUNXI [=y]
> - CLK_SUNXI_PRCM_SUN8I [=y] && COMMON_CLK [=y] && CLK_SUNXI [=y]
>
> WARNING: unmet direct dependencies detected for MFD_SUN6I_PRCM
> Depends on [n]: HAS_IOMEM [=y] && ARCH_SUNXI
> Selected by [y]:
> - CLK_SUNXI_PRCM_SUN6I [=y] && COMMON_CLK [=y] && CLK_SUNXI [=y]
> - CLK_SUNXI_PRCM_SUN8I [=y] && COMMON_CLK [=y] && CLK_SUNXI [=y]
>
> Introduced by commit
>
> 49c726d55c1b ("clk: sunxi: Add Kconfig options")
I've just sent a patch fixing this:
https://lore.kernel.org/lkml/20190322091650.5189-1-maxime.rip...@bootlin.com/
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [RESEND PATCH v6 10/11] input: max77650: add onkey support
On Mon 2019-03-18 18:42:27, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Add support for the push- and slide-button events for max77650. > > Signed-off-by: Bartosz Golaszewski > Acked-by: Dmitry Torokhov Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [RESEND PATCH v6 09/11] leds: max77650: add LEDs support
On Mon 2019-03-18 18:42:26, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> This adds basic support for LEDs for the max77650 PMIC. The device has
> three current sinks for driving LEDs.
>
> Signed-off-by: Bartosz Golaszewski
> Acked-by: Jacek Anaszewski
Acked-by: Pavel Machek
> + label = of_get_property(child, "label", NULL);
> + if (!label) {
> + led->cdev.name = "max77650::";
> + } else {
> + led->cdev.name = devm_kasprintf(dev, GFP_KERNEL,
> + "max77650:%s", label);
> + if (!led->cdev.name)
> + return -ENOMEM;
> + }
I'd rather not have the "max77650:" prefix in the LED name (as it is
useless).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH RT 4.19] rcutorture: Fix oops when selecting non-default torture_type
On 2019-03-21 22:21:21 [-0500], Scott Wood wrote:
> rcu_bh is disabled on PREEMPT_RT via a stub ops that has no name. Thus,
> if a torture_type other than "rcu" is used, rcu_torture_init() will
> pass NULL to strcmp() when iterating over torture_ops[], and oops.
>
> Signed-off-by: Scott Wood
> ---
> With this applied to 4.19.25-rt16 and specifying torture_type=sched,
> similar rcutorture failures are seen as with 5.0.3-rt1 (in which standard
> torture_cype=rcu no longer has .extendables=0 and thus stresses similar
> paths).
Anna-Maria was talking about this to me a long time ago, I though we
fixed that. But since your patch targets v4.19 it is not the case.
As far v4.19 goes, I think it can go in but this is up to Steven now.
Does this still apply to 5.0-RT? The RCU was greatly reworked so it may
no longer apply and just work. However the "random context" in
rcutorture gives me a headache right now…
> kernel/rcu/rcutorture.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index 7d2a615601e7..408d03048911 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -479,6 +479,7 @@ static struct rcu_torture_ops rcu_bh_ops = {
> #else
> static struct rcu_torture_ops rcu_bh_ops = {
> .ttype = INVALID_RCU_FLAVOR,
> + .name = "rcu_bh"
> };
> #endif
>
Sebastian
Re: [PATCH] mm/isolation: Remove redundant pfn_valid_within() in __first_valid_page()
On Thu 21-03-19 09:43:15, Anshuman Khandual wrote:
> pfn_valid_within() calls pfn_valid() when CONFIG_HOLES_IN_ZONE making it
> redundant for both definitions (w/wo CONFIG_MEMORY_HOTPLUG) of the helper
> pfn_to_online_page() which either calls pfn_valid() or pfn_valid_within().
> pfn_valid_within() being 1 when !CONFIG_HOLES_IN_ZONE is irrelevant either
> way. This does not change functionality.
>
> Fixes: 2ce13640b3f4 ("mm: __first_valid_page skip over offline pages")
> Signed-off-by: Anshuman Khandual
Forgot about
Acked-by: Michal Hocko
> ---
> mm/page_isolation.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index ce323e56b34d..d9b02bb13d60 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -150,8 +150,6 @@ __first_valid_page(unsigned long pfn, unsigned long
> nr_pages)
> for (i = 0; i < nr_pages; i++) {
> struct page *page;
>
> - if (!pfn_valid_within(pfn + i))
> - continue;
> page = pfn_to_online_page(pfn + i);
> if (!page)
> continue;
> --
> 2.20.1
>
--
Michal Hocko
SUSE Labs
Re: [PATCH v2] iio: Add driver for TLA202x ADCs
Thanks for the review. I shall make these changes in v3. One comment below.
On Sat, Mar 16, 2019 at 3:48 PM Jonathan Cameron wrote:
>
> On Wed, 13 Mar 2019 12:14:03 +0100
> Ibtsam Ul-Haq wrote:
>
> > Basic driver for Texas Instruments TLA202x series ADCs. Input
> > channels are configurable from the device tree. Input scaling
> > is supported. Trigger buffer support is not yet implemented.
> >
> > Signed-off-by: Ibtsam Ul-Haq
> One quick process thing - and this varies a bit by subsystem
> so worth checking for each one what happened for previous drivers..
>
> Please don't post new versions in replies to old threads.
> They become buried in most email clients and it's not always
> obvious whether different branches of the thread are talking
> about particular versions of the driver.
>
> Much better to just start a fresh thread and rely on the
> consistent naming to make it obvious that it's a new version
> of the same patch.
>
> Anyhow, on to the review.
>
> This needs a devicetree binding document.
>
> Various minor bits inline.
>
> Jonathan
> > ---
> > Changes in v2:
> > - changed commit message
> > - Added mutex to protect channel selection
> > - Removed redundant mutex around i2c transfers
> > - Removed PROCESSED channel output
> > - Added SCALE info
> > - Removed Continuous Mode since continuous read not supported
> > - Removed SAMP_FREQ info since continuous read not supported
> > ---
> > drivers/iio/adc/Kconfig | 11 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/ti-tla2024.c | 463
> > +++
> > 3 files changed, 475 insertions(+)
> > create mode 100644 drivers/iio/adc/ti-tla2024.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 5762565..8c214c8 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -816,6 +816,17 @@ config TI_AM335X_ADC
> > To compile this driver as a module, choose M here: the module will
> > be
> > called ti_am335x_adc.
> >
> > +config TI_TLA2024
> > + tristate "Texas Instruments TLA2024/TLA2022/TLA2021 ADC driver"
> > + depends on OF
> > + depends on I2C
> > + help
> > + Say yes here to build support for Texas Instruments TLA2024,
> > + TLA2022 or TLA2021 I2C Analog to Digital Converters.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called ti-tla2024.
> > +
> > config TI_TLC4541
> > tristate "Texas Instruments TLC4541 ADC driver"
> > depends on SPI
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 9874e05..819f35b 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -75,6 +75,7 @@ obj-$(CONFIG_TI_ADS7950) += ti-ads7950.o
> > obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> > obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> > obj-$(CONFIG_TI_TLC4541) += ti-tlc4541.o
> > +obj-$(CONFIG_TI_TLA2024) += ti-tla2024.o
> > obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> > obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> > obj-$(CONFIG_VF610_ADC) += vf610_adc.o
> > diff --git a/drivers/iio/adc/ti-tla2024.c b/drivers/iio/adc/ti-tla2024.c
> > new file mode 100644
> > index 000..e902eb8
> > --- /dev/null
> > +++ b/drivers/iio/adc/ti-tla2024.c
> > @@ -0,0 +1,463 @@
> > +/* SPDX-License-Identifier: GPL-2.0
> > + *
> > + * Texas Instruments TLA2021/TLA2022/TLA2024 12-bit ADC driver
> > + *
> > + * Copyright (C) 2019 Koninklijke Philips N.V.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define TLA2024_DATA 0x00
> > +#define TLA2024_DATA_RES_MASK GENMASK(15, 4)
> > +#define TLA2024_DATA_RES_SHIFT 4
> > +
> > +#define TLA2024_CONF 0x01
> > +#define TLA2024_CONF_OS_MASK BIT(15)
> > +#define TLA2024_CONF_OS_SHIFT 15
> > +#define TLA2024_CONF_MUX_MASK GENMASK(14, 12)
> > +#define TLA2024_CONF_MUX_SHIFT 12
> > +#define TLA2024_CONF_PGA_MASK GENMASK(11, 9)
> > +#define TLA2024_CONF_PGA_SHIFT 9
> > +#define TLA2024_CONF_MODE_MASK BIT(8)
> > +#define TLA2024_CONF_MODE_SHIFT 8
> > +#define TLA2024_CONF_DR_MASK GENMASK(7, 5)
> > +#define TLA2024_CONF_DR_SHIFT 5
> > +
> > +#define TLA2024_CONV_RETRY 10
> > +
> > +struct tla202x_model {
> > + unsigned int mux_available;
> > + unsigned int pga_available;
> > +};
> > +
> > +struct tla2024 {
> > + struct i2c_client *i2c;
> > + struct tla202x_model *model;
> > + struct mutex lock; /* protect channel selection */
> > + u8 used_mux_channels;
> > +};
> > +
> > +struct tla2024_channel {
> > + int ainp;
> > + int ainn;
> > + const char *datasheet_name;
> > + bool differential;
> > +};
> > +
> > +static const struct tla2024_channel tla2024_all_channels[] = {
> > + {0, 1, "AIN0-AIN1", 1},
> > + {0, 3, "AIN0-AIN3", 1},
> > + {1, 3, "AIN1-AIN3", 1},
> > + {2, 3, "AIN2-AIN3", 1},
> > + {0, -1, "AIN0-GND", 0},
>
> Single ended, so normal convention would just b
Re: KASAN: use-after-free Read in get_mem_cgroup_from_mm
Bisection is inconclusive: the first bad commit could be any of: 2c43838c sched/isolation: Enable CONFIG_CPU_ISOLATION=y by default bf29cb23 sched/isolation: Make CONFIG_NO_HZ_FULL select CONFIG_CPU_ISOLATION d94d1053 sched/isolation: Document boot parameters dependency on CONFIG_CPU_ISOLATION=y 4c470317 Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1592b03720 start commit: 0072a0c1 git tree: upstream dashboard link: https://syzkaller.appspot.com/bug?extid=cbb52e396df3e565ab02 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12835e2540 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172fa5a340 For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH 3/4] rtc: wm831x: switch to rtc_time64_to_tm/rtc_tm_to_time64
On Fri, Mar 22, 2019 at 08:16:10AM +0100, Alexandre Belloni wrote: > Call the 64bit versions of rtc_tm time conversion now that the range is > enforced by the core. > > Signed-off-by: Alexandre Belloni > --- Acked-by: Charles Keepax Thanks, Charles
Re: [PATCH 4/4] rtc: wm831x: convert to SPDX identifier
On Fri, Mar 22, 2019 at 08:16:11AM +0100, Alexandre Belloni wrote: > Use SPDX-License-Identifier instead of a verbose license text. > > Signed-off-by: Alexandre Belloni > --- Acked-by: Charles Keepax Thanks, Charles
Re: [PATCH 2/4] rtc: wm831x: remove unnecessary goto
On Fri, Mar 22, 2019 at 08:16:09AM +0100, Alexandre Belloni wrote: > There is no specific handling in the error path of wm831x_rtc_probe, remove > the unnecessary goto and label. > > Signed-off-by: Alexandre Belloni > --- Acked-by: Charles Keepax Thanks, Charles
Re: [PATCH 1/4] rtc: wm831x: set range
On Fri, Mar 22, 2019 at 08:16:08AM +0100, Alexandre Belloni wrote: > The wm831x has a 32bit second counter. > > Signed-off-by: Alexandre Belloni > --- Acked-by: Charles Keepax Thanks, Charles
[PATCH] staging: olpc_dcon: Add Tabs to define-Macros
Improve Code Readability by adding Tabs after #define-Macro definition. Signed-off-by: Emanuel Bennici --- drivers/staging/olpc_dcon/olpc_dcon.h| 24 ++-- drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c | 8 +++ 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/staging/olpc_dcon/olpc_dcon.h b/drivers/staging/olpc_dcon/olpc_dcon.h index c987aaf894e7..277b19967315 100644 --- a/drivers/staging/olpc_dcon/olpc_dcon.h +++ b/drivers/staging/olpc_dcon/olpc_dcon.h @@ -10,18 +10,18 @@ #define DCON_REG_ID 0 #define DCON_REG_MODE 1 -#define MODE_PASSTHRU BIT(0) -#define MODE_SLEEP BIT(1) -#define MODE_SLEEP_AUTOBIT(2) -#define MODE_BL_ENABLE BIT(3) -#define MODE_BLANK BIT(4) -#define MODE_CSWIZZLE BIT(5) -#define MODE_COL_AABIT(6) -#define MODE_MONO_LUMA BIT(7) -#define MODE_SCAN_INT BIT(8) -#define MODE_CLOCKDIV BIT(9) -#define MODE_DEBUG BIT(14) -#define MODE_SELFTEST BIT(15) +#define MODE_PASSTHRU BIT(0) +#define MODE_SLEEP BIT(1) +#define MODE_SLEEP_AUTOBIT(2) +#define MODE_BL_ENABLE BIT(3) +#define MODE_BLANK BIT(4) +#define MODE_CSWIZZLE BIT(5) +#define MODE_COL_AABIT(6) +#define MODE_MONO_LUMA BIT(7) +#define MODE_SCAN_INT BIT(8) +#define MODE_CLOCKDIV BIT(9) +#define MODE_DEBUG BIT(14) +#define MODE_SELFTEST BIT(15) #define DCON_REG_HRES 0x2 #define DCON_REG_HTOTAL0x3 diff --git a/drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c b/drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c index 838daa2be3ef..7972b591d1b8 100644 --- a/drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c +++ b/drivers/staging/olpc_dcon/olpc_dcon_xo_1_5.c @@ -31,10 +31,10 @@ * DCONSMBCLK connects to VX855 graphics CRTSPCLK */ -#define VX855_GENL_PURPOSE_OUTPUT 0x44c /* PMIO_Rx4c-4f */ -#define VX855_GPI_STATUS_CHG 0x450 /* PMIO_Rx50 */ -#define VX855_GPI_SCI_SMI 0x452 /* PMIO_Rx52 */ -#define BIT_GPIO12 0x40 +#define VX855_GENL_PURPOSE_OUTPUT 0x44c /* PMIO_Rx4c-4f */ +#define VX855_GPI_STATUS_CHG 0x450 /* PMIO_Rx50 */ +#define VX855_GPI_SCI_SMI 0x452 /* PMIO_Rx52 */ +#define BIT_GPIO12 0x40 #define PREFIX "OLPC DCON:" -- 2.19.1
Re: [RESEND PATCH v6 09/11] leds: max77650: add LEDs support
pt., 22 mar 2019 o 10:21 Pavel Machek napisał(a):
>
> On Mon 2019-03-18 18:42:26, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > This adds basic support for LEDs for the max77650 PMIC. The device has
> > three current sinks for driving LEDs.
> >
> > Signed-off-by: Bartosz Golaszewski
> > Acked-by: Jacek Anaszewski
>
> Acked-by: Pavel Machek
>
> > + label = of_get_property(child, "label", NULL);
> > + if (!label) {
> > + led->cdev.name = "max77650::";
> > + } else {
> > + led->cdev.name = devm_kasprintf(dev, GFP_KERNEL,
> > + "max77650:%s", label);
> > + if (!led->cdev.name)
> > + return -ENOMEM;
> > + }
>
> I'd rather not have the "max77650:" prefix in the LED name (as it is
> useless).
>
I was instructed to do so by the LED subsystem maintainer.
Bart
> Best regards,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RESEND PATCH v6 03/11] dt-bindings: leds: add DT bindings for max77650
pt., 22 mar 2019 o 10:02 Pavel Machek napisał(a):
>
> On Mon 2019-03-18 18:40:32, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Add the DT binding document for the LEDs module of max77650.
> >
> > Signed-off-by: Bartosz Golaszewski
> > Reviewed-by: Rob Herring
>
> Acked-by: Pavel Machek
>
> > + led@0 {
> > + reg = <0>;
> > + label = "blue:usr0";
> > + };
>
> I'd rather not see these "usrX" things... Does it have some kind of
> real function?
Not really. In the design we're using it for, it's unused and on the
development kit from MAXIM it's simple three colored leds.
Bart
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RESEND PATCH v6 04/11] dt-bindings: input: add DT bindings for max77650
pt., 22 mar 2019 o 10:09 Pavel Machek napisał(a):
>
> On Mon 2019-03-18 18:42:21, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > Add the DT binding document for the onkey module of max77650.
> >
> > Signed-off-by: Bartosz Golaszewski
> > Reviewed-by: Rob Herring
>
> > + onkey {
> > + compatible = "maxim,max77650-onkey";
> > + linux,code = ;
> > + maxim,onkey-slide;
> > + };
>
> This is certainly wrong.
>
> "End" key is normal key on a keyboard, certainly not some kind of
> slider.
>
> And this controller is likely to be used for power key, not end key,
> right?
But this is just an example of available properties, not a real use-case.
Bart
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH V3] cpufreq: Call transition notifier only once for each policy
On Fri, Mar 22, 2019 at 7:28 AM Viresh Kumar wrote:
>
> On 21-03-19, 16:49, Thomas Gleixner wrote:
> > On Wed, 20 Mar 2019, Viresh Kumar wrote:
> > >
> > > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> > > index 3fae23834069..b2fe665878f7 100644
> > > --- a/arch/x86/kernel/tsc.c
> > > +++ b/arch/x86/kernel/tsc.c
> > > @@ -958,10 +958,15 @@ static int time_cpufreq_notifier(struct
> > > notifier_block *nb, unsigned long val,
> > > struct cpufreq_freqs *freq = data;
> > > unsigned long *lpj;
> > >
> > > + if (WARN_ON_ONCE(cpumask_weight(freq->policy->related_cpus) != 1)) {
> > > + mark_tsc_unstable("cpufreq changes: related CPUs affected");
> > > + return 0;
> > > + }
> >
> > You might add a check which ensures that policy->cpu == smp_processor_id()
> > because if this is not the case
>
> How about something like this ?
>
> if (WARN_ON_ONCE(cpumask_weight(freq->policy->related_cpus) != 1 ||
> freq->policy->cpu != smp_processor_id())) {
> mark_tsc_unstable("cpufreq changes: related CPUs affected");
> return 0;
> }
>
>
> Thanks for your feedback.
Peter suggested something like this IIRC.
Anyway, I'm still concerned that this approach in general
fundamentally doesn't work on SMP with frequency synchronization,
which is the case for the platforms affected by the problem it
attempts to overcome.
The frequency has just been changed on one CPU, presumably to the
requested value (so this cannot work when turbo is enabled anyway),
but then it also has changed for all of the other CPUs in the system
(or at least in the package), so it is not sufficient to update the
single CPU here as it is only a messenger, so to speak. However,
updating the other CPUs from here would be fundamentally racy AFAICS.
Re: [PATCH v2 0/5] drivers: firmware: psci: Some cleanup and refactoring
On Wed, 13 Mar 2019 at 09:37, Ulf Hansson wrote:
>
> Changes in v2:
> - Drop two patches from the series.
> - Added acks and other tags, no other changes.
>
> All of these patches have been sent earlier, but part of a bigger series [1].
> Instead of waiting for that series to get reviewed and accepted, I have split
> it up, such that these trivial independent cleanups can go in as a first step.
>
> The only intentional function change, should be the last patch, where we start
> checking if PSCI OSI mode is supported in the PSCI FW and print a message
> about
> it, as that is quite useful information for the user/developer.
>
> Rafael, discussions between me and Lorenzo for v1 concluded that these are
> ready
> to be queued for v5.2 - and if possible, we would like this to go via your
> linux-pm tree. Can you please pick it up?
Rafael, would you mind picking this up?
Kind regards
Uffe
>
> Kind regards
> Ulf Hansson
>
> [1]
> https://lkml.org/lkml/2018/11/29/1801
>
> Ulf Hansson (5):
> drivers: firmware: psci: Move psci to separate directory
> MAINTAINERS: Update files for PSCI
> drivers: firmware: psci: Split psci_dt_cpu_init_idle()
> drivers: firmware: psci: Simplify error path of psci_dt_init()
> drivers: firmware: psci: Announce support for OS initiated suspend
> mode
>
> MAINTAINERS| 2 +-
> drivers/firmware/Kconfig | 15 +---
> drivers/firmware/Makefile | 3 +-
> drivers/firmware/psci/Kconfig | 13
> drivers/firmware/psci/Makefile | 4 +
> drivers/firmware/{ => psci}/psci.c | 86 +-
> drivers/firmware/{ => psci}/psci_checker.c | 0
> include/uapi/linux/psci.h | 5 ++
> 8 files changed, 78 insertions(+), 50 deletions(-)
> create mode 100644 drivers/firmware/psci/Kconfig
> create mode 100644 drivers/firmware/psci/Makefile
> rename drivers/firmware/{ => psci}/psci.c (93%)
> rename drivers/firmware/{ => psci}/psci_checker.c (100%)
>
> --
> 2.17.1
>
Re: [RESEND PATCH v6 04/11] dt-bindings: input: add DT bindings for max77650
On Fri 2019-03-22 10:55:26, Bartosz Golaszewski wrote:
> pt., 22 mar 2019 o 10:09 Pavel Machek napisał(a):
> >
> > On Mon 2019-03-18 18:42:21, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > >
> > > Add the DT binding document for the onkey module of max77650.
> > >
> > > Signed-off-by: Bartosz Golaszewski
> > > Reviewed-by: Rob Herring
> >
> > > + onkey {
> > > + compatible = "maxim,max77650-onkey";
> > > + linux,code = ;
> > > + maxim,onkey-slide;
> > > + };
> >
> > This is certainly wrong.
> >
> > "End" key is normal key on a keyboard, certainly not some kind of
> > slider.
> >
> > And this controller is likely to be used for power key, not end key,
> > right?
>
> But this is just an example of available properties, not a real use-case.
We can have example that makes sense, right?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH] staging: ralink-gdma: Change uint32_t to u32
On Fri, Mar 22, 2019 at 12:55:02AM +0530, Bharath Vedartham wrote: > This is a follow up on my previous patch. Change occurences of the ^ Put this sort of information under the --- cut off below the Sign off. > stdint type uint32_t to its shortened type u32. This fixed the checkpatch.pl > warning: "Prefer u32 over uint32_t". This line is too long. Limit it to 72 characters. > > Signed-off-by: Bharath Vedartham > --- ^^^ regards, dan carpenter
[PATCH] RISC-V: Fix FIXMAP_TOP to avoid overlap with VMALLOC area
The FIXMAP area overlaps with VMALLOC area in Linux-5.1-rc1 hence we get
below warning in Linux RISC-V 32bit kernel. This warning does not show-up
in Linux RISC-V 64bit kernel due to large VMALLOC area.
WARNING: CPU: 0 PID: 22 at mm/vmalloc.c:150 vmap_page_range_noflush+0x134/0x15c
Modules linked in:
CPU: 0 PID: 22 Comm: kworker/0:1 Not tainted 5.1.0-rc1-5-gebc2f658040e #1
Workqueue: events pcpu_balance_workfn
Call Trace:
[] walk_stackframe+0x0/0xa0
[] show_stack+0x28/0x32
[] dump_stack+0x62/0x7e
[] __warn+0x98/0xce
[] warn_slowpath_null+0x2e/0x3c
[] vmap_page_range_noflush+0x134/0x15c
[] map_kernel_range_noflush+0xc/0x14
[] pcpu_populate_chunk+0x19e/0x236
[] pcpu_balance_workfn+0x448/0x464
[] process_one_work+0x16c/0x2ea
[] worker_thread+0xf2/0x3b2
[] kthread+0xce/0xdc
[] ret_from_exception+0x0/0xc
This patch fixes above warning by placing FIXMAP area below VMALLOC area.
Fixes: f2c17aabc917 ("RISC-V: Implement compile-time fixed mappings")
Signed-off-by: Anup Patel
---
arch/riscv/include/asm/fixmap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
index 5cf53dd882e5..9c66033c3a54 100644
--- a/arch/riscv/include/asm/fixmap.h
+++ b/arch/riscv/include/asm/fixmap.h
@@ -31,7 +31,7 @@ enum fixed_addresses {
};
#define FIXADDR_SIZE (__end_of_fixed_addresses * PAGE_SIZE)
-#define FIXADDR_TOP(PAGE_OFFSET)
+#define FIXADDR_TOP(VMALLOC_START)
#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
#define FIXMAP_PAGE_IO PAGE_KERNEL
--
2.17.1
[PATCH v2] MAINTAINERS: Add mailing list for the interconnect API
Add a mailing list for patch reviews and discussions related to tuning the on-chip interconnects. For now i am not expecting a lot of traffic, so let's use the linux-pm@ list. Acked-by: Rafael J. Wysocki Signed-off-by: Georgi Djakov --- Hi Greg, Can you please pick this fix for the next possible -rc, so people can know where to send patches. Thanks! Georgi Changes since v1 (https://lore.kernel.org/lkml/20190321155050.25847-1-georgi.dja...@linaro.org/) - Picked Rafael's Ack. MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index e17ebf70b548..186439e7f846 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8046,6 +8046,7 @@ F:drivers/gpio/gpio-intel-mid.c INTERCONNECT API M: Georgi Djakov +L: linux...@vger.kernel.org S: Maintained F: Documentation/interconnect/ F: Documentation/devicetree/bindings/interconnect/
Re: [PATCH] ceph: Fix a memory leak in ci->i_head_snapc
Luis Henriques writes: > "Yan, Zheng" writes: > >> On Tue, Mar 19, 2019 at 12:22 AM Luis Henriques wrote: >>> >>> "Yan, Zheng" writes: >>> >>> > On Mon, Mar 18, 2019 at 6:33 PM Luis Henriques >>> > wrote: >>> >> >>> >> "Yan, Zheng" writes: >>> >> >>> >> > On Fri, Mar 15, 2019 at 7:13 PM Luis Henriques >>> >> > wrote: >>> >> >> >>> >> >> I'm occasionally seeing a kmemleak warning in xfstest generic/013: >>> >> >> >>> >> >> unreferenced object 0x8881fccca940 (size 32): >>> >> >> comm "kworker/0:1", pid 12, jiffies 4295005883 (age 130.648s) >>> >> >> hex dump (first 32 bytes): >>> >> >> 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 >>> >> >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> >> >> backtrace: >>> >> >> [] build_snap_context+0x5b/0x2a0 >>> >> >> [<21a00533>] rebuild_snap_realms+0x27/0x90 >>> >> >> [ ] rebuild_snap_realms+0x42/0x90 >>> >> >> [<0e955fac>] ceph_update_snap_trace+0x2ee/0x610 >>> >> >> [ ] ceph_handle_snap+0x317/0x5f3 >>> >> >> [ ] dispatch+0x362/0x176c >>> >> >> [ ] ceph_con_workfn+0x9ce/0x2cf0 >>> >> >> [<4168e3a9>] process_one_work+0x1d4/0x400 >>> >> >> [<2188e9e7>] worker_thread+0x2d/0x3c0 >>> >> >> [ ] kthread+0x112/0x130 >>> >> >> [ ] ret_from_fork+0x35/0x40 >>> >> >> [ ] 0x >>> >> >> >>> >> >> It looks like it is possible that we miss a flush_ack from the MDS >>> >> >> when, >>> >> >> for example, umounting the filesystem. In that case, we can simply >>> >> >> drop >>> >> >> the reference to the ceph_snap_context obtained in >>> >> >> ceph_queue_cap_snap(). >>> >> >> >>> >> >> Link: https://tracker.ceph.com/issues/38224 >>> >> >> Cc: sta...@vger.kernel.org >>> >> >> Signed-off-by: Luis Henriques >>> >> >> --- >>> >> >> fs/ceph/caps.c | 7 +++ >>> >> >> 1 file changed, 7 insertions(+) >>> >> >> >>> >> >> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c >>> >> >> index 36a8dc699448..208f4dc6f574 100644 >>> >> >> --- a/fs/ceph/caps.c >>> >> >> +++ b/fs/ceph/caps.c >>> >> >> @@ -1054,6 +1054,7 @@ int ceph_is_any_caps(struct inode *inode) >>> >> >> static void drop_inode_snap_realm(struct ceph_inode_info *ci) >>> >> >> { >>> >> >> struct ceph_snap_realm *realm = ci->i_snap_realm; >>> >> >> + >>> >> >> spin_lock(&realm->inodes_with_caps_lock); >>> >> >> list_del_init(&ci->i_snap_realm_item); >>> >> >> ci->i_snap_realm_counter++; >>> >> >> @@ -1063,6 +1064,12 @@ static void drop_inode_snap_realm(struct >>> >> >> ceph_inode_info *ci) >>> >> >> spin_unlock(&realm->inodes_with_caps_lock); >>> >> >> >>> >> >> ceph_put_snap_realm(ceph_sb_to_client(ci->vfs_inode.i_sb)->mdsc, >>> >> >> realm); >>> >> >> + /* >>> >> >> +* ci->i_head_snapc should be NULL, but we may still be >>> >> >> waiting for a >>> >> >> +* flush_ack from the MDS. In that case, we still hold a ref >>> >> >> for the >>> >> >> +* ceph_snap_context and we need to drop it. >>> >> >> +*/ >>> >> >> + ceph_put_snap_context(ci->i_head_snapc); >>> >> >> } >>> >> >> >>> >> >> /* >>> >> > >>> >> > This does not seem right. i_head_snapc is cleared when >>> >> > (ci->i_wrbuffer_ref_head == 0 && ci->i_dirty_caps == 0 && >>> >> > ci->i_flushing_caps == 0) . Nothing do with dropping ci->i_snap_realm. >>> >> > Did you see 'reconnect denied' during the test? If you did, the fix >>> >> > should be in iterate_session_caps() >>> >> > >>> >> >>> >> No, I didn't saw any 'reconnect denied' in the test. The test actually >>> >> seems to execute fine, except from the memory leak. >>> >> >>> >> It's very difficult to reproduce this issue, but last time I managed to >>> >> get this memory leak to trigger I actually had some debugging code in >>> >> drop_inode_snap_realm, something like: >>> >> >>> >> if (ci->i_head_snapc) >>> >> printk("i_head_snapc: 0x%px\n", ci->i_head_snapc); >>> > >>> > please add code that prints i_wrbuffer_ref_head, i_dirty_caps, >>> > i_flushing_caps. and try reproducing it again. >>> > >>> >>> Ok, it took me a few hours, but I managed to reproduce the bug, with >>> those extra printks. All those values are set to 0 when the bug >>> triggers (and i_head_snapc != NULL). >>> >> >> Thanks, which test triggers this bug? > > That's generic/013. It usually triggers after a few hours of running it > in a loop (I'm using a vstart cluster for that). > >> >> I searched that code, found we may fail to cleanup i_head_snap in two >> places. One is in ceph_queue_cap_snap, Another is in >> remove_session_caps_cb(). > > Ah, great! I spent a lot of time looking but I couldn't really find it. > My bet was that ceph_queue_cap_snap was doing the ceph_get_snap_context > and that the corresponding ceph_pu
Re: Help on testing ad5933 driver
On Thu, Mar 21, 2019 at 04:39:13PM -0300, Marcelo Schmitt wrote: > Hello, would anyone mind helping me test ad5933 driver on actual > hardware? I went through this > (https://oslongjourney.github.io/linux-kernel/experiment-one-iio-dummy/) > tutorial so I was able to load iio_simple_dummy driver, create and > inspect some dummy devices. Now, as Jonathan has asked me, I would like > to test ad5933 driver on an EVAL-AD5933 board which was donated to FLUSP > (https://flusp.ime.usp.br/). > > So far I've been hesitating to plug this device on my Debian distro > since this > (https://www.analog.com/media/en/technical-documentation/user-guides/UG-364.pdf) > user guide for Windows says not to connect it before driver > installation. Is there something that could harm the board if plugged > on a computer without a proper driver? The kernel shouldn't be bricking hardware... Hardware used to be easier to brick in olden times... regards, dan carpenter
Re: [PATCH v2 0/7] iommu/vt-d: Fix-up device-domain relationship by refactoring to use iommu group default domain.
Hey Lu,
> On 20 Mar 2019, at 01:26, Lu Baolu wrote:
>
> Hi James,
>
> On 3/19/19 9:35 PM, James Sewart wrote:
>> Hey Lu,
>>> On 15 Mar 2019, at 03:13, Lu Baolu wrote:
>>>
>>> Hi James,
>>>
>>> On 3/14/19 7:56 PM, James Sewart wrote:
Patches 1 and 2 are the same as v1.
v1-v2:
Refactored ISA direct mappings to be returned by iommu_get_resv_regions.
Integrated patch by Lu to defer turning on DMAR until iommu.c has mapped
reserved regions.
Integrated patches by Lu to remove more unused code in cleanup.
Lu: I didn't integrate your patch to set the default domain type as it
isn't directly related to the aim of this patchset. Instead patch 4
>>>
>>> Without those patches, user experience will be affected and some devices
>>> will not work on Intel platforms anymore.
>>>
>>> For a long time, Intel IOMMU driver has its own logic to determine
>>> whether a device requires an identity domain. For example, when user
>>> specifies "iommu=pt" in kernel parameter, all device will be attached
>>> with the identity domain. Further more, some quirky devices require
>>> an identity domain to be used before enabling DMA remapping, otherwise,
>>> it will not work. This was done by adding quirk bits in Intel IOMMU
>>> driver.
>>>
>>> So from my point of view, one way is porting all those quirks and kernel
>>> parameters into IOMMU generic layer, or opening a door for vendor IOMMU
>>> driver to determine the default domain type by their own. I prefer the
>>> latter option since it will not impact any behaviors on other
>>> architectures.
>> I see your point. I’m not confident that using the proposed door to set a
>> groups default domain has the desired behaviour. As discussed before the
>> default domain type will be set based on the desired type for only the
>> first device attached to a group. I think to change the default domain
>> type you would need a slightly different door that wasn’t conditioned on
>> device.
>
> I think this as another problem. Just a summarize for the ease of
> discussion. We saw two problems:
>
> 1. When allocating a new group for a device, how should we determine the
> type of the default domain? This is what my proposal patches trying to
> address.
This will work as expected only if all devices within a group get the same
result from is_identity_map. Otherwise wee see issue 2.
>
> 2. If we need to put a device into an existing group which uses a
> different type of domain from what the device desires to use, we might
> break the functionality of the device. For this problem I'd second your
> proposal below if I get your point correctly.
>
>> For situations where individual devices require an identity domain because
>> of quirks then maybe calling is_identity_map per device in
>> iommu_group_get_for_dev is a better solution than the one I proposed.
>
> Do you mean if we see a quirky device requires a different domain type
> other than the default domain type of the group, we will assign a new
> group to it? That looks good to me as far as I can see. I suppose this
> should be done in vt-d's ops callback.
I have thought about this a bit and I think the cleanest approach is to
put devices that require an identity domain into their own group, this can
be done in the device_group callback, avoiding any situation where we have
to deal with creating a new group based on domain type in
iommu_group_get_for_dev. This way we shouldn’t ever be in a situation with
multiple different domain types per group. This way your patches will work
as expected. See below for a possible implementation.
>
> Best regards,
> Lu Baolu
Cheers,
James.
Devices that require an identity map because of quirks or other reasons
should be put in their own IOMMU group so as to not end up with multiple
different domains per group.
Signed-off-by: James Sewart
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3cb8b36abf50..0f5a121d31a0 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -5421,6 +5421,22 @@ struct intel_iommu *intel_svm_device_to_iommu(struct
device *dev)
}
#endif /* CONFIG_INTEL_IOMMU_SVM */
+static struct iommu_group *intel_identity_group;
+
+struct iommu_group *intel_iommu_pci_device_group(struct device *dev)
+{
+ if (iommu_no_mapping(dev)) {
+ if (!intel_identity_group) {
+ intel_identity_group = iommu_group_alloc();
+ if (IS_ERR(intel_identity_group))
+ return NULL;
+ }
+ return intel_identity_group;
+ }
+
+ return pci_device_group(dev);
+}
+
const struct iommu_ops intel_iommu_ops = {
.capable= intel_iommu_capable,
.domain_alloc = intel_iommu_domain_alloc,
@@ -5435,7 +5451,7 @@ const struct iommu_ops intel_iommu_ops = {
.get_resv_regions = intel_iommu_get_resv_regions,
.put_resv_regions
Re: [PATCH 00/25] coresight: Support for ACPI bindings
On 03/20/2019 06:49 PM, Suzuki K Poulose wrote: This series adds the support for CoreSight devices on ACPI based platforms. The device connections are encoded as _DSD graph property[0], with CoreSight specific extensions to indicate the direction of data flow as described in [1]. Components attached to CPUs are listed as child devices of the corresponding CPU, removing explicit links to the CPU like we do in the DT. As a prepartion for the ACPI support, we merge the driver for dynamic and non-programmable replicators. We introduce platform independent helpers to parse the platform supplied information. Thus we rename the platform handling code from: of_coresight.c => coresight-platform.c The CoreSight driver creates shadow devices that appear on the Coresight bus, in addition to the real devices (e.g, AMBA bus devices). The name of these devices match the real device. This makes the device name a bit cryptic for ACPI platform. So this series also introduces a generic platform agnostic device naming scheme for the shadow Coresight devices. Towards this we also make changes to the way we lookup devices to resolve the connections, as we can't use the names to identify the devices. So, we use the "fwnode_handle" of the real device for the device lookups. Towards that we clean up the drivers to keep track of the "CoreSight" device rather than the "real" device. However, all real operations, like DMA allocation, Power management etc. must be performed on the real device which is the parent of the shadow device. Finally we add the support for parsing the ACPI platform data. The power management support is missing in the ACPI (and this is not specific to CoreSight). The firmware must ensure that the respective power domains are turned on. Applies on v5.1-rc1 Tested on a Juno-r0 board with ACPI bindings patch (Patch 26/25) added on top of [2]. You would need to make sure that the debug power domain is turned on before the Linux kernel boots. (e.g, connect the DS-5 to the Juno board while at UEFI). arm32 code is only compile tested. [0] ACPI Device Graphs using _DSD (Not available online yet, approved but awaiting publish and eventually should be linked at). https://uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm [1] https://developer.arm.com/docs/den0067/latest/acpi-for-coresighttm-10-platform-design-document [2] https://github.com/tianocore/edk2-platforms.git The kernel patches are also available here : git://linux-arm.org/linux-skp.git coresight-acpi/v1 Kind regards Suzuki
Re: [PATCH v5 10/19] mm: pagewalk: Add p4d_entry() and pgd_entry()
On 21/03/2019 21:15, Mike Rapoport wrote:
> On Thu, Mar 21, 2019 at 02:19:44PM +, Steven Price wrote:
>> pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
>> ("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were
>> no users. We're about to add users so reintroduce them, along with
>> p4d_entry() as we now have 5 levels of tables.
>>
>> Note that commit a00cc7d9dd93d66a ("mm, x86: add support for
>> PUD-sized transparent hugepages") already re-added pud_entry() but with
>> different semantics to the other callbacks. Since there have never
>> been upstream users of this, revert the semantics back to match the
>> other callbacks. This means pud_entry() is called for all entries, not
>> just transparent huge pages.
>>
>> Signed-off-by: Steven Price
>> ---
>> include/linux/mm.h | 9 ++---
>> mm/pagewalk.c | 27 ---
>> 2 files changed, 22 insertions(+), 14 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 76769749b5a5..2983f2396a72 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -1367,10 +1367,9 @@ void unmap_vmas(struct mmu_gather *tlb, struct
>> vm_area_struct *start_vma,
>>
>> /**
>> * mm_walk - callbacks for walk_page_range
>> + * @pgd_entry: if set, called for each non-empty PGD (top-level) entry
>> + * @p4d_entry: if set, called for each non-empty P4D (1st-level) entry
>
> IMHO, p4d implies the 4th level :)
You have a good point there... I was simply working back from the
existing definitions (below) of PTE:4th, PMD:3rd, PUD:2nd. But it's
already somewhat broken by PGD:0th and my cop-out was calling it "top".
> I think it would make more sense to start counting from PTE rather than
> from PGD. Then it would be consistent across architectures with fewer
> levels.
It would also be the opposite way round to architectures such as Arm
which number their levels, for example [1] refers to levels 0-3 (with 3
being PTE in Linux terms).
[1]
https://developer.arm.com/docs/100940/latest/translation-tables-in-armv8-a
Probably the least confusing thing is to drop the level numbers in
brackets since I don't believe they directly match any architecture, and
hopefully any user of the page walking code is already familiar with the
P?D terms used by the kernel.
Steve
>> * @pud_entry: if set, called for each non-empty PUD (2nd-level) entry
>> - * this handler should only handle pud_trans_huge() puds.
>> - * the pmd_entry or pte_entry callbacks will be used for
>> - * regular PUDs.
>> * @pmd_entry: if set, called for each non-empty PMD (3rd-level) entry
>> * this handler is required to be able to handle
>> * pmd_trans_huge() pmds. They may simply choose to
>> @@ -1390,6 +1389,10 @@ void unmap_vmas(struct mmu_gather *tlb, struct
>> vm_area_struct *start_vma,
>> * (see the comment on walk_page_range() for more details)
>> */
>> struct mm_walk {
>> +int (*pgd_entry)(pgd_t *pgd, unsigned long addr,
>> + unsigned long next, struct mm_walk *walk);
>> +int (*p4d_entry)(p4d_t *p4d, unsigned long addr,
>> + unsigned long next, struct mm_walk *walk);
>> int (*pud_entry)(pud_t *pud, unsigned long addr,
>> unsigned long next, struct mm_walk *walk);
>> int (*pmd_entry)(pmd_t *pmd, unsigned long addr,
>> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
>> index c3084ff2569d..98373a9f88b8 100644
>> --- a/mm/pagewalk.c
>> +++ b/mm/pagewalk.c
>> @@ -90,15 +90,9 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr,
>> unsigned long end,
>> }
>>
>> if (walk->pud_entry) {
>> -spinlock_t *ptl = pud_trans_huge_lock(pud, walk->vma);
>> -
>> -if (ptl) {
>> -err = walk->pud_entry(pud, addr, next, walk);
>> -spin_unlock(ptl);
>> -if (err)
>> -break;
>> -continue;
>> -}
>> +err = walk->pud_entry(pud, addr, next, walk);
>> +if (err)
>> +break;
>> }
>>
>> split_huge_pud(walk->vma, pud, addr);
>> @@ -131,7 +125,12 @@ static int walk_p4d_range(pgd_t *pgd, unsigned long
>> addr, unsigned long end,
>> break;
>> continue;
>> }
>> -if (walk->pmd_entry || walk->pte_entry)
>> +if (walk->p4d_entry) {
>> +err = walk->p4d_entry(p4d, addr, next, walk);
>> +if (err)
>> +break;
>> +}
>> +if (walk->pud_entry || walk->pmd_entry || walk->pte_entry)
>> err = walk_pud_range(p4d, addr, next, walk);
>> if (err)
>> break;
>> @@ -157,7 +156,13 @@ static i
Re: BUG: unable to handle kernel paging request in do_mount
This bug is marked as fixed by commit: vfs: namespace: error pointer dereference in do_remount() But I can't find it in any tested tree for more than 90 days. Is it a correct commit? Please update it by replying: #syz fix: exact-commit-title Until then the bug is still considered open and new crashes with the same signature are ignored.
Re: [PATCH v2 03/15] drm/bridge: tc358767: Simplify polling in tc_link_training()
On 22/03/2019 05:28, Andrey Smirnov wrote: > Replace explicit polling in tc_link_training() with equivalent call to > tc_poll_timeout() for simplicity. No functional change intended (not > including slightly altered debug output). > > Signed-off-by: Andrey Smirnov > Cc: Archit Taneja > Cc: Andrzej Hajda > Cc: Laurent Pinchart > Cc: Tomi Valkeinen > Cc: Andrey Gusakov > Cc: Philipp Zabel > Cc: Chris Healy > Cc: Lucas Stach > Cc: dri-de...@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/gpu/drm/bridge/tc358767.c | 13 + > 1 file changed, 5 insertions(+), 8 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[GIT PULL] MMC fixes for v5.1-rc2
Hi Linus, Here's a PR with a couple of MMC fixes intended for v5.1-rc2. Details about the highlights are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.1-rc1 for you to fetch changes up to c9a9497ccef205ed4ed2e247011382627876d831: mmc: renesas_sdhi: limit block count to 16 bit for old revisions (2019-03-21 11:41:46 +0100) MMC host: - alcor: Fix DMA reads - renesas_sdhi: Limit block count to 16-bit for old revisions - sdhci-omap: Fixup support for read-only pins - mxcmmc: Revert support for highmem pages - davinci/pxamci: Fix clang build warnings Alexander Shiyan (1): mmc: mxcmmc: "Revert mmc: mxcmmc: handle highmem pages" Arnd Bergmann (2): mmc: pxamci: fix enum type confusion mmc: davinci: remove extraneous __init annotation Daniel Drake (1): mmc: alcor: fix DMA reads Kishon Vijay Abraham I (1): mmc: sdhci-omap: Set caps2 to indicate no physical write protect pin Wolfram Sang (1): mmc: renesas_sdhi: limit block count to 16 bit for old revisions drivers/mmc/host/alcor.c | 25 +++-- drivers/mmc/host/davinci_mmc.c | 2 +- drivers/mmc/host/mxcmmc.c| 16 drivers/mmc/host/pxamci.c| 2 +- drivers/mmc/host/renesas_sdhi_core.c | 8 +++- drivers/mmc/host/sdhci-omap.c| 3 +++ 6 files changed, 35 insertions(+), 21 deletions(-)
Re: [PATCH 0/4] Signal: Fix hard lockup problem in flush_sigqueue()
On Thu, Mar 21, 2019 at 05:45:08PM -0400, Waiman Long wrote: > It was found that if a process has accumulated sufficient number of > pending signals, the exiting of that process may cause its parent to > have hard lockup when running on a debug kernel with a slow memory > freeing path (like with KASAN enabled). I appreciate these are "reliable" signals, but why do we accumulate so many signals to a task which will never receive them? Can we detect at signal delivery time that the task is going to die and avoid queueing them in the first place?
[PATCH] svm/avic: Fix invalidate logical APIC id entry
Only clear the valid bit when invalidate logical APIC id entry.
The current logic clear the valid bit, but also set the rest of
the bits (including reserved bits) to 1.
Fixes: 98d90582be2e ('svm: Fix AVIC DFR and LDR handling')
Signed-off-by: Suravee Suthikulpanit
---
arch/x86/kvm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 7a4ce1a22ca0..f4fb766e474c 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -4640,7 +4640,7 @@ static void avic_invalidate_logical_id_entry(struct
kvm_vcpu *vcpu)
u32 *entry = avic_get_logical_id_entry(vcpu, svm->ldr_reg, flat);
if (entry)
- WRITE_ONCE(*entry, (u32) ~AVIC_LOGICAL_ID_ENTRY_VALID_MASK);
+ WRITE_ONCE(*entry, (u32)(*entry &
~AVIC_LOGICAL_ID_ENTRY_VALID_MASK));
}
static int avic_handle_ldr_update(struct kvm_vcpu *vcpu)
--
2.17.1
Re: [PATCH] ARM: dts: imx6qdl-sabresd: change phy-mode to use rgmii-id
On 22. 03. 19 3:24, Fabio Estevam wrote: On Thu, Mar 21, 2019 at 11:15 PM Shawn Guo wrote: Unfortunately, just by looking at the dts files we do not know if a board uses an AR803x PHY or not, so I am afraid we can not do an automatic conversion. At least for those we already know? Yes, I can help preparing a patch that fixes the i.MX boards we know use AR8031 PHY. AFACT this issue is not AR803x specific. I was hit by the same problem with QCA833x switch on imx6dl-yapp4. Though, we are currently the only platform in tree using this chip and Shawn already has the fix in his tree. I am not aware of any other PHY drivers that my cause problems. $ git log --oneline v5.0..v5.1-rc1 --grep=RGMII --author=Vinod -- drivers/net/ 6d4cd041f0af net: phy: at803x: disable delay only for RGMII mode a968b5e9d587 net: dsa: qca8k: Enable delay for RGMII_ID mode 5ecdd77c61c8 net: dsa: qca8k: disable delay for RGMII mode cd28d1d6e52e net: phy: at803x: Disable phy delay for RGMII mode Michal
[GIT PULL] Power management fixes for v5.1-rc2
Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-5.1-rc2 with top-most commit 112a04f653ddf1d4246415e8e0d820002ebe8dca Merge branch 'pm-domains' into pm on top of commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b Linux 5.1-rc1 to receive power management fixes for 5.1-rc2. These rearrange some code in the generic power domains (genpd) framework to avoid a potential deadlock and make the turbostat utility behave more as expected. Specifics: - Rearrange the generic power domains (genpd) code to avoid a potential deadlock possible due to its interactions with the clock framework (Jiada Wang). - Make turbostat return the exit status of the command run under it if that command fails (David Arcari). Thanks! --- David Arcari (1): tools/power turbostat: return the exit status of a command Jiada Wang (1): PM / Domains: Avoid a potential deadlock --- drivers/base/power/domain.c | 13 ++--- tools/power/x86/turbostat/turbostat.c | 3 +++ 2 files changed, 9 insertions(+), 7 deletions(-)
Re: [PATCH v2] thunderbolt: Fix to check for kmemdup failure
On Wed, Mar 20, 2019 at 10:57:54AM -0500, Aditya Pakki wrote: > Memory allocated via kmemdup might fail and return a NULL pointer. > This patch adds a check on the return value of kmemdup and passes the > error upstream. > > Signed-off-by: Aditya Pakki Applied, thanks!
