* Re: [PATCH v3 07/13] clk: mmp2: Add the I2S clocks
From: Stephen Boyd @ 2020-05-28 1:01 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, Michael Turquette, linux-kernel, Lubomir Rintel,
Rob Herring, linux-clk, linux-arm-kernel
In-Reply-To: <20200519224151.2074597-8-lkundrak@v3.sk>
Quoting Lubomir Rintel (2020-05-19 15:41:45)
> A pair of fractional clock sources for PLLs and gates.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 06/13] clk: mmp2: Rename mmp2_pll_init() to mmp2_main_clk_init()
From: Stephen Boyd @ 2020-05-28 1:01 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, Michael Turquette, linux-kernel, Lubomir Rintel,
Rob Herring, linux-clk, linux-arm-kernel
In-Reply-To: <20200519224151.2074597-7-lkundrak@v3.sk>
Quoting Lubomir Rintel (2020-05-19 15:41:44)
> This is a trivial rename for a routine that registers more clock sources
> than the PLLs -- there's also a XO.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 05/13] clk: mmp2: Move thermal register defines up a bit
From: Stephen Boyd @ 2020-05-28 1:01 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, Michael Turquette, linux-kernel, Lubomir Rintel,
Rob Herring, linux-clk, linux-arm-kernel
In-Reply-To: <20200519224151.2074597-6-lkundrak@v3.sk>
Quoting Lubomir Rintel (2020-05-19 15:41:43)
> A trivial change to keep the sorting sane. The APBC registers are happier
> when they are grouped together, instead of mixed with the APMU ones.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/13] dt-bindings: marvell, mmp2: Add clock id for the Audio clock
From: Stephen Boyd @ 2020-05-28 1:01 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, Rob Herring, Michael Turquette, linux-kernel,
Lubomir Rintel, Rob Herring, linux-clk, linux-arm-kernel
In-Reply-To: <20200519224151.2074597-5-lkundrak@v3.sk>
Quoting Lubomir Rintel (2020-05-19 15:41:42)
> This clocks the Audio block.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Acked-by: Rob Herring <robh@kernel.org>
>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 03/13] dt-bindings: marvell, mmp2: Add clock id for the I2S clocks
From: Stephen Boyd @ 2020-05-28 1:01 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, Rob Herring, Michael Turquette, linux-kernel,
Lubomir Rintel, Rob Herring, linux-clk, linux-arm-kernel
In-Reply-To: <20200519224151.2074597-4-lkundrak@v3.sk>
Quoting Lubomir Rintel (2020-05-19 15:41:41)
> There are two of these on a MMP2.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> Acked-by: Rob Herring <robh@kernel.org>
>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 02/13] clk: mmp: frac: Allow setting bits other than the numerator/denominator
From: Stephen Boyd @ 2020-05-28 1:01 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, Michael Turquette, linux-kernel, Lubomir Rintel,
Rob Herring, linux-clk, linux-arm-kernel
In-Reply-To: <20200519224151.2074597-3-lkundrak@v3.sk>
Quoting Lubomir Rintel (2020-05-19 15:41:40)
> For the I2S fractional clocks, there are more bits that need to be set
> for the clock to run. Their actual meaning is unknown.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/13] clk: mmp: frac: Do not lose last 4 digits of precision
From: Stephen Boyd @ 2020-05-28 1:01 UTC (permalink / raw)
To: Lubomir Rintel
Cc: devicetree, Michael Turquette, linux-kernel, Lubomir Rintel,
Rob Herring, linux-clk, linux-arm-kernel
In-Reply-To: <20200519224151.2074597-2-lkundrak@v3.sk>
Quoting Lubomir Rintel (2020-05-19 15:41:39)
> While calculating the output rate of a fractional divider clock, the
> value is divided and multipled by 10000, discarding the least
> significant digits -- presumably to fit the intermediate value within 32
> bits.
>
> The precision we're losing is, however, not insignificant for things like
> I2S clock. Maybe also elsewhere, now that since commit ea56ad60260e ("clk:
> mmp2: Stop pretending PLL outputs are constant") the parent rates are more
> precise and no longer rounded to 10000s.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: versatile: undo some dependency changes
From: Stephen Boyd @ 2020-05-28 0:34 UTC (permalink / raw)
To: Arnd Bergmann, Linus Walleij, Michael Turquette
Cc: Rob Herring, Arnd Bergmann, linux-kernel, Sudeep Holla, linux-clk,
linux-arm-kernel
In-Reply-To: <20200527134043.807045-1-arnd@arndb.de>
Quoting Arnd Bergmann (2020-05-27 06:40:33)
> SP810 and ICST are selected by a couple of platforms, most but
> not all in the versatile family:
>
> WARNING: unmet direct dependencies detected for CLK_SP810
> Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_VERSATILE [=n]
> Selected by [y]:
> - ARCH_REALVIEW [=y] && (ARCH_MULTI_V5 [=n] || ARCH_MULTI_V6 [=n] ||
> ARCH_MULTI_V7 [=y])
>
> WARNING: unmet direct dependencies detected for ICST
> Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_VERSATILE [=n]
> Selected by [y]:
> - ARCH_REALVIEW [=y] && (ARCH_MULTI_V5 [=n] || ARCH_MULTI_V6 [=n] || ARCH_MULTI_V7 [=y])
> - ARCH_VEXPRESS [=y] && ARCH_MULTI_V7 [=y]
> - ARCH_ZYNQ [=y] && ARCH_MULTI_V7 [=y]
>
> Change back the Kconfig logic to allow these to be selected
> without the main option.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Is this similar to
https://lore.kernel.org/r/20200527181307.2482167-1-robh@kernel.org
?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Cache flush issue with page_mapping_file() and swap back shmem page ?
From: Jerome Glisse @ 2020-05-28 0:20 UTC (permalink / raw)
To: linux-mm, Andrew Morton, Huang Ying
Cc: Rich Felker, linux-sh, Catalin Marinas, linux-mips,
James E.J. Bottomley, linux-mm, Guo Ren, sparclinux, Paul Burton,
Helge Deller, James Hogan, rmk+kernel, linux-xtensa,
Steven Capper, Rabin Vincent, Ley Foon Tan, Guan Xuetao,
linux-arm-kernel, Chris Zankel, Yoshinori Sato, linux-parisc,
Max Filippov, linux-kernel, Ralf Baechle, nios2-dev,
David S. Miller
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
So any arch code which uses page_mapping_file() might get the wrong
answer, this function will return NULL for a swap backed page which
can be a shmem pages. But shmem pages can still be shared among
multiple process (and possibly at different virtual addresses if
mremap was use).
Attached is a patch that changes page_mapping_file() to return the
shmem mapping for swap backed shmem page. I have not tested it (no
way for me to test all those architecture) and i spotted this while
working on something else. So i hope someone can take a closer look.
Cheers,
Jérôme
[-- Attachment #2: 0001-mm-fix-cache-flush-for-shmem-page-that-are-swap-back.patch --]
[-- Type: text/plain, Size: 2355 bytes --]
From 6c76b9f8baa87ff872f6be5a44805a74c1e07fea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= <jglisse@redhat.com>
Date: Wed, 27 May 2020 20:18:59 -0400
Subject: [PATCH] mm: fix cache flush for shmem page that are swap backed.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This might be a shmem page that is in a sense a file that
can be mapped multiple times in different processes at
possibly different virtual addresses (fork + mremap). So
return the shmem mapping that will allow any arch code to
find all mappings of the page.
Note that even if page is not anonymous then the page might
have a NULL page->mapping field if it is being truncated,
but then it is fine as each pte poiting to the page will be
remove and cache flushing should be handled properly by that
part of the code.
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Cc: "Huang, Ying" <ying.huang@intel.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
---
mm/util.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/mm/util.c b/mm/util.c
index 988d11e6c17c..ec8739ab0cc3 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -685,8 +685,24 @@ EXPORT_SYMBOL(page_mapping);
*/
struct address_space *page_mapping_file(struct page *page)
{
- if (unlikely(PageSwapCache(page)))
+ if (unlikely(PageSwapCache(page))) {
+ /*
+ * This might be a shmem page that is in a sense a file that
+ * can be mapped multiple times in different processes at
+ * possibly different virtual addresses (fork + mremap). So
+ * return the shmem mapping that will allow any arch code to
+ * find all mappings of the page.
+ *
+ * Note that even if page is not anonymous then the page might
+ * have a NULL page->mapping field if it is being truncated,
+ * but then it is fine as each pte poiting to the page will be
+ * remove and cache flushing should be handled properly by that
+ * part of the code.
+ */
+ if (!PageAnon(page))
+ return page->mapping;
return NULL;
+ }
return page_mapping(page);
}
--
2.26.2
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH/RFC] arm64/kernel: Fix return value when cpu_online() fails in __cpu_up()
From: Nobuhiro Iwamatsu @ 2020-05-27 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, catalin.marinas, Nobuhiro Iwamatsu,
Signed-off-by : Gavin Shan, Yuji Ishikawa
If boot_secondary() was successful, and cpu_online() was an error in
__cpu_up(), -EIO was returned, but 0 is returned by commit d22b115cbfbb7
("arm64/kernel: Simplify __cpu_up() by bailing out early").
Therefore, bringup_wait_for_ap() causes the primary core to wait for a
long time, which may cause boot failure.
This commit sets -EIO to return code under the same conditions.
Fixes: d22b115cbfbb7 ("arm64/kernel: Simplify __cpu_up() by bailing out early")
CC: Signed-off-by: Gavin Shan <gshan@redhat.com>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Mark Rutland <mark.rutland@arm.com>
Tested-by: Yuji Ishikawa <yuji2.ishikawa@toshiba.co.jp>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
---
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 061f60fe452f7..ea677680e4277 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -137,6 +137,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
if (cpu_online(cpu))
return 0;
+ ret = -EIO;
pr_crit("CPU%u: failed to come online\n", cpu);
secondary_data.task = NULL;
secondary_data.stack = NULL;
--
2.27.0.rc0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [soc:mediatek/dt-2] BUILD SUCCESS 21eb9ec7c3e6f5c6ddae2e19768fd7eab2cd3b63
From: kbuild test robot @ 2020-05-27 23:33 UTC (permalink / raw)
To: Matthias Brugger; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt-2
branch HEAD: 21eb9ec7c3e6f5c6ddae2e19768fd7eab2cd3b63 arm: dts: mt2712: add uart APDMA to device tree
elapsed time: 2195m
configs tested: 103
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
mips malta_kvm_guest_defconfig
arm socfpga_defconfig
nds32 allnoconfig
mips malta_defconfig
arc alldefconfig
arm orion5x_defconfig
arc nsimosci_hs_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 defconfig
ia64 allnoconfig
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa defconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
arc defconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
arc allyesconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc defconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a001-20200527
i386 randconfig-a004-20200527
i386 randconfig-a003-20200527
i386 randconfig-a006-20200527
i386 randconfig-a002-20200527
i386 randconfig-a005-20200527
x86_64 randconfig-a006-20200527
x86_64 randconfig-a002-20200527
x86_64 randconfig-a005-20200527
x86_64 randconfig-a003-20200527
x86_64 randconfig-a004-20200527
x86_64 randconfig-a001-20200527
i386 randconfig-a013-20200527
i386 randconfig-a015-20200527
i386 randconfig-a012-20200527
i386 randconfig-a011-20200527
i386 randconfig-a016-20200527
i386 randconfig-a014-20200527
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp
From: Chun-Kuang Hu @ 2020-05-27 23:27 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, Bibby Hsieh, srv_heupstream,
David Airlie, huijuan.xie, stonea168, linux-kernel,
DRI Development, cawa.cheng, CK Hu, Rob Herring,
moderated list:ARM/Mediatek SoC support, Daniel Vetter,
Matthias Brugger, yingjoe.chen, eddie.huang, Linux ARM
In-Reply-To: <20200522101225.62571-1-jitao.shi@mediatek.com>
Hi, Jitao:
Jitao Shi <jitao.shi@mediatek.com> 於 2020年5月22日 週五 下午6:12寫道：
>
> If panel has too small hfp or hbp, horizontal_frontporch_byte or
> horizontal_backporch_byte may become very small value or negative
> value. This patch adjusts their values so that they are greater
> than minimum value and keep total of them unchanged.
>
> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0ede69830a9d..aebaafd90ceb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -148,6 +148,9 @@
> (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> (type == MIPI_DSI_DCS_READ))
>
> +#define MIN_HFP_BYTE 0x02
> +#define MIN_HBP_BYTE 0x02
> +
> struct mtk_phy_timing {
> u32 lpx;
> u32 da_hs_prepare;
> @@ -450,6 +453,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> u32 horizontal_sync_active_byte;
> u32 horizontal_backporch_byte;
> u32 horizontal_frontporch_byte;
> + s32 signed_hfp_byte, signed_hbp_byte;
> u32 dsi_tmp_buf_bpp, data_phy_cycles;
> struct mtk_phy_timing *timing = &dsi->phy_timing;
>
> @@ -519,6 +523,20 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> }
> }
>
> + signed_hfp_byte = (s32)horizontal_frontporch_byte;
> + signed_hbp_byte = (s32)horizontal_backporch_byte;
> +
> + if (signed_hfp_byte + signed_hbp_byte < MIN_HFP_BYTE + MIN_HBP_BYTE) {
> + DRM_WARN("Calculated hfp_byte and hbp_byte are too small, "
> + "panel may not work properly.\n");
> + } else if (signed_hfp_byte < MIN_HFP_BYTE) {
> + horizontal_frontporch_byte = MIN_HFP_BYTE;
> + horizontal_backporch_byte -= MIN_HFP_BYTE - signed_hfp_byte;
> + } else if (signed_hbp_byte < MIN_HBP_BYTE) {
> + horizontal_frontporch_byte -= MIN_HBP_BYTE - signed_hbp_byte;
> + horizontal_backporch_byte = MIN_HBP_BYTE;
> + }
> +
I think horizontal_frontporch_byte would never be negtive, and
horizontal_backporch_byte would be negtive when
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
horizontal_backporch_byte =
(vm->hback_porch * dsi_tmp_buf_bpp - 10);
else
horizontal_backporch_byte = ((vm->hback_porch + vm->hsync_len) *
dsi_tmp_buf_bpp - 10);
If this time it's negtive, the calculation of
horizontal_frontporch_byte is so strange.
I think processing negtive value should before here.
Regards,
Chun-Kuang.
> writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
> writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
> writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
> --
> 2.25.1
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics
From: David Ahern @ 2020-05-27 22:21 UTC (permalink / raw)
To: Paolo Bonzini, Jakub Kicinski, Emanuele Giuseppe Esposito
Cc: linux-s390, kvm, linux-doc, netdev, Emanuele Giuseppe Esposito,
linux-kernel, kvm-ppc, Jonathan Adams, Christian Borntraeger,
Andrew Lunn, Alexander Viro, David Rientjes, linux-fsdevel,
linux-mips, linuxppc-dev, linux-arm-kernel, Jim Mattson
In-Reply-To: <af2ba926-73bc-26c3-7ce7-bd45f657fd85@redhat.com>
On 5/27/20 3:07 PM, Paolo Bonzini wrote:
> I see what you meant now. statsfs can also be used to enumerate objects
> if one is so inclined (with the prototype in patch 7, for example, each
> network interface becomes a directory).
there are many use cases that have 100's to 1000's have network devices.
Having a sysfs entry per device already bloats memory usage for these
use cases; another filesystem with an entry per device makes that worse.
Really the wrong direction for large scale systems.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 03/14] PCI: cadence: Convert all r/w accessors to perform only 32-bit accesses
From: Kishon Vijay Abraham I @ 2020-05-27 22:06 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Lorenzo Pieralisi, Arnd Bergmann, PCI,
linux-kernel@vger.kernel.org, Tom Joseph, Greg Kroah-Hartman,
Bjorn Helgaas, linux-omap,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqJMZxOFw-kn5_9bNTPzJuwHybJAi6iQyBq=6BrKSvfTqA@mail.gmail.com>
Hi Rob,
On 5/27/2020 10:07 PM, Rob Herring wrote:
> On Wed, May 27, 2020 at 4:49 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>
>> Hi Rob,
>>
>> On 5/26/2020 8:42 PM, Rob Herring wrote:
>>> On Sun, May 24, 2020 at 9:30 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>
>>>> Hi Rob,
>>>>
>>>> On 5/22/2020 9:24 PM, Rob Herring wrote:
>>>>> On Thu, May 21, 2020 at 9:37 PM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>>>>
>>>>>> Certain platforms like TI's J721E using Cadence PCIe IP can perform only
>>>>>> 32-bit accesses for reading or writing to Cadence registers. Convert all
>>>>>> read and write accesses to 32-bit in Cadence PCIe driver in preparation
>>>>>> for adding PCIe support in TI's J721E SoC.
>>>>>
>>>>> Looking more closely I don't think cdns_pcie_ep_assert_intx is okay
>>>>> with this and never can be given the PCI_COMMAND and PCI_STATUS
>>>>> registers are in the same word (IIRC, that's the main reason 32-bit
>>>>> config space accesses are broken). So this isn't going to work at
>>>>
>>>> right, PCI_STATUS has write '1' to clear bits and there's a chance that it
>>>> could be reset while raising legacy interrupt. While this cannot be avoided for
>>>> TI's J721E, other platforms doesn't have to have this limitation.
>>>>> least for EP accesses. And maybe you need a custom .raise_irq() hook
>>>>> to minimize any problems (such as making the RMW atomic at least from
>>>>> the endpoint's perspective).
>>>>
>>>> This is to make sure EP doesn't update in-consistent state when RC is updating
>>>> the PCI_STATUS register? Since this involves two different systems, how do we
>>>> make this atomic?
>>>
>>> You can't make it atomic WRT both systems, but is there locking around
>>> each RMW? Specifically, are preemption and interrupts disabled to
>>> ensure time between a read and write are minimized? You wouldn't want
>>> interrupts disabled during the delay too though (i.e. around
>>> .raise_irq()).
>>
>> Okay, I'll add spin spin_lock_irqsave() in cdns_pcie_write_sz(). As you also
>> pointed below that delay for legacy interrupt is wrong and it has to be fixed
>> (with a later series).
>
> But you don't need a lock everywhere. You need locks in the callers
> (and only sometimes).
Okay, the locks should be added only for registers where HOST can also write to
the same register? Maybe only raise_irq then..
>
>> How do you want to handle cdns_pcie_ep_fn_writew() now? Because now we are
>> changing the default implementation to perform only 32-bit access (used for
>> legacy interrupt, msi-x interrupt and while writing standard headers) and it's
>> not okay only for legacy interrupts for platforms other than TI.
>
> Now I'm wondering how set_msi is not racy in the current code with the
> host setting/clearing PCI_MSI_FLAGS_ENABLE? Maybe that bit is RO from
> the EP side?
set_msi/set_msix is a one time configuration that is invoked before the host
establishes the link with the endpoint. I don't think we have to consider this
as racy.
Thanks
Kishon
>
> Ultimately I think you're going to have to provide your own endpoint
> functions or you need accessors for specific registers like
> PCI_MSI_FLAGS. Then for example, you just rely on the 2 bytes before
> PCI_MSI_FLAGS being reserved and do a 32-bit access without a RMW.
> Trying to abstract this at the register read/write level is going to
> be fragile
>
> Rob
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] soc/fsl drivers changes for next(v5.8)
From: Li Yang @ 2020-05-27 21:57 UTC (permalink / raw)
To: arm, soc; +Cc: shawnguo, linux-kernel, linux-arm-kernel
Hi soc maintainers,
Please merge the following new changes for soc/fsl drivers.
Regards,
Leo
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git tags/soc-fsl-next-v5.8
for you to fetch changes up to e9e4ef9116b12951eaee3f8447ba9bbb40ab3620:
soc: fsl: dpio: Remove unused inline function qbman_write_eqcr_am_rt_register (2020-05-22 18:11:03 -0500)
----------------------------------------------------------------
NXP/FSL SoC driver updates for v5.8
DPAA2 DPIO driver
- Prefer the CPU affined DPIO
QUICC Engine drivers
- Replace one-element array and use struct_size() helper
Cleanups in various drivers
----------------------------------------------------------------
Colin Ian King (1):
soc: fsl: qe: clean up an indentation issue
Gustavo A. R. Silva (2):
treewide: Replace zero-length array with flexible-array
soc: fsl: qe: Replace one-element array and use struct_size() helper
Roy Pledge (1):
soc: fsl: dpio: Prefer the CPU affine DPIO
YueHaibing (2):
soc: fsl: qbman: Remove unused inline function qm_eqcr_get_ci_stashing
soc: fsl: dpio: Remove unused inline function qbman_write_eqcr_am_rt_register
drivers/soc/fsl/dpio/dpio-service.c | 6 +++++-
drivers/soc/fsl/dpio/qbman-portal.c | 12 ------------
drivers/soc/fsl/qbman/qman.c | 5 -----
drivers/soc/fsl/qe/qe.c | 4 ++--
drivers/soc/fsl/qe/ucc.c | 2 +-
include/linux/fsl/bestcomm/bestcomm.h | 2 +-
include/soc/fsl/qe/qe.h | 2 +-
7 files changed, 10 insertions(+), 23 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: vdso32: force vdso32 to be compiled as -marm
From: Nick Desaulniers @ 2020-05-27 21:47 UTC (permalink / raw)
To: Robin Murphy
Cc: Naohiro Aota, Stephen Boyd, Arnd Bergmann, Catalin Marinas,
Masahiro Yamada, LKML, david.spickett, Peter Smith, Manoj Gupta,
Kristof Beyls, Luis Lozano, Nathan Chancellor, Vincenzo Frascino,
Will Deacon, victor.campos, Linux ARM
In-Reply-To: <CAKwvOd=Zxm9TDPNd4Qvn6Ru==FLasiP1xWXMM7ji08VWRjBu2g@mail.gmail.com>
On Wed, May 27, 2020 at 1:31 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Wed, May 27, 2020 at 1:14 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > On Wed, May 27, 2020 at 12:28 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > >
> > > On 2020-05-27 18:55, Nick Desaulniers wrote:
> > > > On Wed, May 27, 2020 at 6:45 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > >>
> > > >> On 2020-05-26 18:31, Nick Desaulniers wrote:
> > > >>> Custom toolchains that modify the default target to -mthumb cannot
> > > >>> compile the arm64 compat vdso32, as
> > > >>> arch/arm64/include/asm/vdso/compat_gettimeofday.h
> > > >>> contains assembly that's invalid in -mthumb. Force the use of -marm,
> > > >>> always.
> > > >>
> > > >> FWIW, this seems suspicious - the only assembly instructions I see there
> > > >> are SWI(SVC), MRRC, and a MOV, all of which exist in Thumb for the
> > > >> -march=armv7a baseline that we set.
> > > >>
> > > >> On a hunch, I've just bodged "VDSO_CFLAGS += -mthumb" into my tree and
> > > >> built a Thumb VDSO quite happily with Ubuntu 19.04's
> > > >> gcc-arm-linux-gnueabihf. What was the actual failure you saw?
> > > >
> > > > From the link in the commit message: `write to reserved register 'R7'`
> > > > https://godbolt.org/z/zwr7iZ
> > > > IIUC r7 is reserved for the frame pointer in THUMB?
> > >
> > > It can be, if you choose to build with frame pointers and the common
> > > frame pointer ABI for Thumb code that uses r7. However it can also be
> > > for other things like the syscall number in the Arm syscall ABI too.
> >
> > Ah, right, with -fomit-frame-pointer, this error also goes away. Not
> > sure if we prefer either:
> > - build the compat vdso as -marm always or
> > - disable frame pointers for the vdso (does this have unwinding implications?)
> > - other?
> >
> > > I
> > > take it Clang has decided that writing syscall wrappers with minimal
> > > inline asm is not a thing people deserve to do without arbitrary other
> > > restrictions?
> >
> > Was the intent not obvious? We would have gotten away with it, too, if
> > wasn't for you meddling kids and your stupid dog! /s
> > https://www.youtube.com/watch?v=hXUqwuzcGeU
> > Anyways, this seems to explain more the intentions:
> > https://reviews.llvm.org/D76848#1945810
> > + Victor, Kristof (ARM)
>
> And maybe some other useful data points regarding warning on use of r7
> and frame pointers.
> https://github.com/ClangBuiltLinux/linux/issues/701#issuecomment-591325758
> https://bugs.llvm.org/show_bug.cgi?id=45826
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94986
>
> + Peter (ARM)
> + David, Arnd (Linaro)
Also, when I looked into this briefly, I didn't happen to see anything
in AAPCS that mentions r7 is used as the frame pointer for THUMB.
Does AAPCS not cover THUMB? It also states the TPCS is obsolete.
https://developer.arm.com/docs/ihi0042/latest
https://static.docs.arm.com/ihi0042/i/aapcs32.pdf
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics
From: Paolo Bonzini @ 2020-05-27 21:44 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Emanuele Giuseppe Esposito, linux-s390, kvm, linux-doc, netdev,
Emanuele Giuseppe Esposito, linux-kernel, kvm-ppc, Jonathan Adams,
Christian Borntraeger, Andrew Lunn, Alexander Viro,
David Rientjes, linux-fsdevel, linux-mips, linuxppc-dev,
linux-arm-kernel, Jim Mattson
In-Reply-To: <20200527142741.77e7de37@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
On 27/05/20 23:27, Jakub Kicinski wrote:
> On Wed, 27 May 2020 23:07:53 +0200 Paolo Bonzini wrote:
>>> Again, I have little KVM knowledge, but BPF also uses a fd-based API,
>>> and carries stats over the same syscall interface.
>>
>> Can BPF stats (for BPF scripts created by whatever process is running in
>> the system) be collected by an external daemon that does not have access
>> to the file descriptor? For KVM it's of secondary importance to gather
>> stats in the program; it can be nice to have and we are thinking of a
>> way to export the stats over the fd-based API, but it's less useful than
>> system-wide monitoring. Perhaps this is a difference between the two.
>
> Yes, check out bpftool prog list (bpftool code is under tools/bpf/ in
> the kernel tree). BPF statistics are under a static key, so you may not
> see any on your system. My system shows e.g.:
>
> 81: kprobe name abc tag cefaa9376bdaae75 gpl run_time_ns 80941 run_cnt 152
> loaded_at 2020-05-26T13:00:24-0700 uid 0
> xlated 512B jited 307B memlock 4096B map_ids 66,64
> btf_id 16
>
> In this example run_time_ns and run_cnt are stats.
>
> The first number on the left is the program ID. BPF has an IDA, and
> each object gets an integer id. So admin (or CAP_BPF, I think) can
> iterate over the ids and open fds to objects of interest.
Got it, thanks. But then "I'd hope that whatever daemon collects [BPF]
stats doesn't run as root". :)
>> Another case where stats and configuration are separate is CPUs, where
>> CPU enumeration is done in sysfs but statistics are exposed in various
>> procfs files such as /proc/interrupts and /proc/stats.
>
> True, but I'm guessing everyone is just okay living with the legacy
> procfs format there. Otherwise I'd guess the stats would had been added
> to sysfs. I'd be curious to hear the full story there.
Yeah, it's a chicken-and-egg problem in that there's no good place in
sysfs to put statistics right now, which is part of what this filesystem
is trying to solve (the other part is the API).
You can read more about Google's usecase at
http://lkml.iu.edu/hypermail/linux/kernel/2005.0/08056.html, it does
include both network and interrupt stats and it's something that they've
been using in production for quite some time. We'd like the statsfs API
to be the basis for including something akin to that in Linux.
To be honest, it's unlikely that Emanuele (who has just finished his
internship at Red Hat) and I will pursue the networking stats further
than the demo patch at the end of this series. However, we're trying to
make sure that the API is at least ready for that, and to probe whether
any developers from other subsystems would be interested in using
statsfs. So thanks for bringing your point of view!
Thanks,
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 0/7] Statsfs: a new ram-based file system for Linux kernel statistics
From: Jakub Kicinski @ 2020-05-27 21:27 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Emanuele Giuseppe Esposito, linux-s390, kvm, linux-doc, netdev,
Emanuele Giuseppe Esposito, linux-kernel, kvm-ppc, Jonathan Adams,
Christian Borntraeger, Andrew Lunn, Alexander Viro,
David Rientjes, linux-fsdevel, linux-mips, linuxppc-dev,
linux-arm-kernel, Jim Mattson
In-Reply-To: <af2ba926-73bc-26c3-7ce7-bd45f657fd85@redhat.com>
On Wed, 27 May 2020 23:07:53 +0200 Paolo Bonzini wrote:
> > Again, I have little KVM knowledge, but BPF also uses a fd-based API,
> > and carries stats over the same syscall interface.
>
> Can BPF stats (for BPF scripts created by whatever process is running in
> the system) be collected by an external daemon that does not have access
> to the file descriptor? For KVM it's of secondary importance to gather
> stats in the program; it can be nice to have and we are thinking of a
> way to export the stats over the fd-based API, but it's less useful than
> system-wide monitoring. Perhaps this is a difference between the two.
Yes, check out bpftool prog list (bpftool code is under tools/bpf/ in
the kernel tree). BPF statistics are under a static key, so you may not
see any on your system. My system shows e.g.:
81: kprobe name abc tag cefaa9376bdaae75 gpl run_time_ns 80941 run_cnt 152
loaded_at 2020-05-26T13:00:24-0700 uid 0
xlated 512B jited 307B memlock 4096B map_ids 66,64
btf_id 16
In this example run_time_ns and run_cnt are stats.
The first number on the left is the program ID. BPF has an IDA, and
each object gets an integer id. So admin (or CAP_BPF, I think) can
iterate over the ids and open fds to objects of interest.
> Another case where stats and configuration are separate is CPUs, where
> CPU enumeration is done in sysfs but statistics are exposed in various
> procfs files such as /proc/interrupts and /proc/stats.
True, but I'm guessing everyone is just okay living with the legacy
procfs format there. Otherwise I'd guess the stats would had been added
to sysfs. I'd be curious to hear the full story there.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH v2 6/6] prctl.2: Add tagged address ABI control prctls (arm64)
From: Dave Martin @ 2020-05-27 21:17 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-arch, linux-man, Catalin Marinas, Vincenzo Frascino,
Will Deacon, linux-arm-kernel
In-Reply-To: <1590614258-24728-1-git-send-email-Dave.Martin@arm.com>
** This patch is a draft for review and should not be applied before it
has been discussed. **
Add documentation for the the PR_SET_TAGGED_ADDR_CTRL and
PR_GET_TAGGED_ADDR_CTRL prctls added in Linux 5.4 for arm64.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
man2/prctl.2 | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 156 insertions(+)
diff --git a/man2/prctl.2 b/man2/prctl.2
index 3ee2702..062fd51 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -1504,6 +1504,143 @@ For more information, see the kernel source file
(or
.I Documentation/arm64/sve.txt
before Linux 5.3).
+.\" prctl PR_SET_TAGGED_ADDR_CTRL
+.\" commit 63f0c60379650d82250f22e4cf4137ef3dc4f43d
+.TP
+.BR PR_SET_TAGGED_ADDR_CTRL " (since Linux 5.4, only on arm64)"
+Controls support for passing tagged userspace addresses to the kernel
+(i.e., addresses where bits 56\(em63 are not all zero).
+.IP
+The level of support is selected by
+.IR "(unsigned int) arg2" ,
+which can be one of the following:
+.RS
+.TP
+.B 0
+Addresses that are passed
+for the purpose of being dereferenced by the kernel
+must be untagged.
+.TP
+.B PR_TAGGED_ADDR_ENABLE
+Addresses that are passed
+for the purpose of being dereferenced by the kernel
+may be tagged, with the exceptions summarized below.
+.RE
+.IP
+The remaining arguments
+.IR arg3 ", " arg4 " and " arg5
+must all be zero.
+.IP
+On success, the mode specified in
+.I arg2
+is set for the calling thread and the the return value is 0.
+If the arguments are invalid,
+the mode specified in
+.I arg2
+is unrecognized,
+or if this feature is disabled or unsupported by the kernel,
+the call fails with
+.BR EINVAL .
+.IP
+In particular, if
+.BR prctl ( PR_SET_TAGGED_ADDR_CTRL ,
+0, 0, 0, 0)
+fails with
+.B EINVAL
+then all addresses passed to the kernel must be untagged.
+.IP
+Irrespective of which mode is set,
+addresses passed to certain interfaces
+must always be untagged:
+.RS
+.IP \(em
+.BR brk (2),
+.BR mmap (2),
+.BR shmat (2),
+and the
+.I new_address
+argument of
+.BR mremap (2).
+.IP
+(Prior to Linux 5.6 these accepted tagged addresses,
+but the behaviour may not be what you expect.
+Don't rely on it.)
+.IP \(em
+\(oqpolymorphic\(cq interfaces
+that accept pointers to arbitrary types cast to a
+.I void *
+or other generic type, specifically
+.BR prctl (2),
+.BR ioctl (2),
+and in general
+.BR setsockopt (2)
+(only certain specific
+.BR setsockopt (2)
+options allow tagged addresses).
+.IP \(em
+.BR shmdt (2).
+.RE
+.IP
+This list of exclusions may shrink
+when moving from one kernel version to a later kernel version.
+While the kernel may make some guarantees
+for backwards compatibility reasons,
+for the purposes of new software
+the effect of passing tagged addresses to these interfaces
+is unspecified.
+.IP
+The mode set by this call is inherited across
+.BR fork (2)
+and
+.BR clone (2).
+The mode is reset by
+.BR execve (2)
+to 0
+(i.e., tagged addresses not permitted in the user/kernel ABI).
+.IP
+.B Warning:
+Because the compiler or run-time environment
+may make use of address tagging,
+a successful
+.B PR_SET_TAGGED_ADDR_CTRL
+may crash the calling process.
+The conditions for using it safely are complex and system-dependent.
+Don't use it unless you know what you are doing.
+.IP
+For more information, see the kernel source file
+.IR Documentation/arm64/tagged\-address\-abi.rst .
+.\" prctl PR_GET_TAGGED_ADDR_CTRL
+.\" commit 63f0c60379650d82250f22e4cf4137ef3dc4f43d
+.TP
+.BR PR_GET_TAGGED_ADDR_CTRL " (since Linux 5.4, only on arm64)"
+Returns the current tagged address mode
+for the calling thread.
+.IP
+Arguments
+.IR arg2 ", " arg3 ", " arg4 " and " arg5
+must all be zero.
+.IP
+If the arguments are invalid
+or this feature is disabled or unsupported by the kernel,
+the call fails with
+.BR EINVAL .
+In particular, if
+.BR prctl ( PR_GET_TAGGED_ADDR_CTRL ,
+0, 0, 0, 0)
+fails with
+.BR EINVAL ,
+then this feature is definitely unsupported or disabled,
+and all addresses passed to the kernel must be untagged.
+.IP
+Otherwise, the call returns a nonnegative value
+describing the current tagged address mode,
+encoded in the same way as the
+.I arg2
+argument of
+.BR PR_SET_TAGGED_ADDR_CTRL .
+.IP
+For more information, see the kernel source file
+.IR Documentation/arm64/tagged\-address\-abi.rst .
.\"
.\" prctl PR_TASK_PERF_EVENTS_DISABLE
.TP
@@ -1749,6 +1886,7 @@ On success,
.BR PR_GET_SPECULATION_CTRL ,
.BR PR_SVE_GET_VL ,
.BR PR_SVE_SET_VL ,
+.BR PR_GET_TAGGED_ADDR_CTRL ,
.BR PR_GET_THP_DISABLE ,
.BR PR_GET_TIMING ,
.BR PR_GET_TIMERSLACK ,
@@ -2057,6 +2195,24 @@ is
.B PR_SVE_GET_VL
and SVE is not available on this platform.
.TP
+.B EINVAL
+.I option
+is
+.BR PR_SET_TAGGED_ADDR_CTRL
+and the arguments are invalid or unsupported.
+See the description of
+.B PR_SET_TAGGED_ADDR_CTRL
+above for details.
+.TP
+.B EINVAL
+.I option
+is
+.BR PR_GET_TAGGED_ADDR_CTRL
+and the arguments are invalid or unsupported.
+See the description of
+.B PR_GET_TAGGED_ADDR_CTRL
+above for details.
+.TP
.B ENODEV
.I option
was
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/6] prctl.2: Add PR_PAC_RESET_KEYS (arm64)
From: Dave Martin @ 2020-05-27 21:17 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-arch, linux-man, Catalin Marinas, Amit Daniel Kachhap,
Mark Rutland, Will Deacon, linux-arm-kernel
In-Reply-To: <1590614258-24728-1-git-send-email-Dave.Martin@arm.com>
Add documentation for the PR_PAC_RESET_KEYS ioctl added in Linux
5.0 for arm64.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Amit Daniel Kachhap <amit.kachhap@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
Since v1:
* Clarify explicitly that PR_PAC_RESET_KEYS is redundant when combined
with execve().
* Move error condition details into the prctl description, to avoid
excessive duplication while keeping keeping related pieces of text
closer together.
* In lieu of having a separate man page to cross reference for detailed
guidance, cross-reference the kernel documentation.
* Add safety warning. This is deliberately vague, pending ongoing
discussions with libc folks.
---
man2/prctl.2 | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/man2/prctl.2 b/man2/prctl.2
index 91df7c8..3ee2702 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -950,6 +950,77 @@ behavior.
A value of 1 indicates
.BR execve (2)
will operate in the privilege-restricting mode described above.
+.\" prctl PR_PAC_RESET_KEYS
+.\" commit ba830885656414101b2f8ca88786524d4bb5e8c1
+.TP
+.BR PR_PAC_RESET_KEYS " (since Linux 5.0, only on arm64)"
+Securely reset the thread's pointer authentication keys
+to fresh random values generated by the kernel.
+.IP
+The set of keys to be reset is specified by
+.IR arg2 ,
+which must be a logical OR of zero or more of the following:
+.RS
+.TP
+.B PR_PAC_APIAKEY
+instruction authentication key A
+.TP
+.B PR_PAC_APIBKEY
+instruction authentication key B
+.TP
+.B PR_PAC_APDAKEY
+data authentication key A
+.TP
+.B PR_PAC_APDBKEY
+data authentication key B
+.TP
+.B PR_PAC_APGAKEY
+generic authentication \(lqA\(rq key.
+.IP
+(Yes folks, there really is no generic B key.)
+.RE
+.IP
+As a special case, if
+.I arg2
+is zero then all the keys are reset.
+Since new keys could be added in future,
+this is the recommended way to completely wipe the existing keys
+when establishing a clean execution context.
+Note that there is no need to use
+.BR PR_PAC_RESET_KEYS
+in preparation for calling
+.BR execve (2),
+since
+.BR execve (2)
+resets all the pointer authentication keys.
+.IP
+The remaining arguments
+.IR arg3 ", " arg4 " and " arg5
+must all be zero.
+.IP
+If the arguments are invalid,
+and in particular if
+.I arg2
+contains set bits that are unrecognized
+or that correspond to a key not available on this platform,
+the call fails with error
+.BR EINVAL .
+.IP
+.B Warning:
+Because the compiler or run-time environment
+may be using some or all of the keys,
+a successful
+.IP
+For more information, see the kernel source file
+.I Documentation/arm64/pointer\-authentication.rst
+.\"commit b693d0b372afb39432e1c49ad7b3454855bc6bed
+(or
+.I Documentation/arm64/pointer\-authentication.txt
+before Linux 5.3).
+.B PR_PAC_RESET_KEYS
+may crash the calling process.
+The conditions for using it safely are complex and system-dependent.
+Don't use it unless you know what you are doing.
.\" prctl PR_SET_PDEATHSIG
.TP
.BR PR_SET_PDEATHSIG " (since Linux 2.1.57)"
@@ -1964,6 +2035,15 @@ are not 0.
.B EINVAL
.I option
is
+.B PR_PAC_RESET_KEYS
+and the arguments are invalid or unsupported.
+See the description of
+.B PR_PAC_RESET_KEYS
+above for details.
+.TP
+.B EINVAL
+.I option
+is
.B PR_SVE_SET_VL
and the arguments are invalid or unsupported,
or SVE is not available on this platform.
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/6] prctl.2: Add SVE prctls (arm64)
From: Dave Martin @ 2020-05-27 21:17 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-arch, linux-man, Will Deacon, linux-arm-kernel,
Catalin Marinas
In-Reply-To: <1590614258-24728-1-git-send-email-Dave.Martin@arm.com>
Add documentation for the the PR_SVE_SET_VL and PR_SVE_GET_VL
prctls added in Linux 4.15 for arm64.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
---
Since v1:
* Minor rewordings and typo fixes.
* Fix typo'd #define names.
* Add type annotation for PR_SVE_SET_VL arg2.
* Clarify return value semantics of PR_SVE_SET_VL
* Add note to say that the args for PR_SVE_GET_VL are ignored.
* Note for PR_SVE_SET_VL that the PR_SVE_VL_LEN_MASK field specifies
an upper bound on what vector length to set, not an exact value.
* Rework PR_SVE_SET_VL arg2 description to enumerate all possible flag
combinations rather than describing the flags independently.
Coming up with a clear description of each flag that is independent
of the description of the other flag turns out to be hard.
* In lieu of having a separate man page to cross reference for detailed
guidance, cross-reference the kernel documentation.
* Avoid confusing cross-reference to PR_SVE_SET_VL when describing the
return value of PR_SVE_GET_VL.
* Clarify error conditions for PR_SVE_SET_VL and PR_SVE_GET_VL, and
move detail to the individual prctl descriptions to keep related
content close together while minimising duplication.
* Add safety warning. This is deliberately vague, pending ongoing
discussions with libc folks.
---
man2/prctl.2 | 160 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 160 insertions(+)
diff --git a/man2/prctl.2 b/man2/prctl.2
index cab9915..91df7c8 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -1291,6 +1291,148 @@ call failing with the error
.BR ENXIO .
For further details, see the kernel source file
.IR Documentation/admin\-guide/kernel\-parameters.txt .
+.\" prctl PR_SVE_SET_VL
+.\" commit 2d2123bc7c7f843aa9db87720de159a049839862
+.\" linux-5.6/Documentation/arm64/sve.rst
+.TP
+.BR PR_SVE_SET_VL " (since Linux 4.15, only on arm64)"
+Configure the thread's SVE vector length,
+as specified by
+.IR "(int) arg2" .
+Arguments
+.IR arg3 ", " arg4 " and " arg5
+are ignored.
+.IP
+The bits of
+.I arg2
+corresponding to
+.B PR_SVE_VL_LEN_MASK
+must be set to the desired vector length in bytes.
+This is interpreted as an upper bound:
+the kernel will select the greatest available vector length
+that does not exceed the value specified.
+In particular, specifying
+.B SVE_VL_MAX
+(defined in
+.I <asm/sigcontext.h>)
+for the
+.B PR_SVE_VL_LEN_MASK
+bits requests the maximum supported vector length.
+.IP
+In addition,
+.I arg2
+must be set to one of the following combinations of flags:
+.RS
+.TP
+.B 0
+Perform the change immediately.
+At the next
+.BR execve (2)
+in the thread,
+the vector length will be reset to the value configured in
+.IR /proc/sys/abi/sve_default_vector_length .
+.TP
+.B PR_SVE_VL_INHERIT
+Perform the change immediately.
+Subsequent
+.BR execve (2)
+calls will preserve the new vector length.
+.TP
+.B PR_SVE_SET_VL_ONEXEC
+Defer the change, so that it is performed at the next
+.BR execve (2)
+in the thread.
+Further
+.BR execve (2)
+calls will reset the vector length to the value configured in
+.IR /proc/sys/abi/sve_default_vector_length .
+.TP
+.B "PR_SVE_SET_VL_ONEXEC | PR_SVE_VL_INHERIT"
+Defer the change, so that it is performed at the next
+.BR execve (2)
+in the thread.
+Further
+.BR execve (2)
+calls will preserve the new vector length.
+.RE
+.IP
+In all cases,
+any previously pending deferred change is canceled.
+.IP
+The call fails with error
+.B EINVAL
+if SVE is not supported on the platform, if
+.I arg2
+is unrecognized or invalid, or the value in the bits of
+.I arg2
+corresponding to
+.B PR_SVE_VL_LEN_MASK
+is outside the range
+.BR SVE_VL_MIN .. SVE_VL_MAX
+or is not a multiple of 16.
+.IP
+On success,
+a nonnegative value is returned that describes the
+.I selected
+configuration,
+which may differ from the current configuration if
+.B PR_SVE_SET_VL_ONEXEC
+was specified.
+The value is encoded in the same way as the return value of
+.BR PR_SVE_GET_VL .
+.IP
+The configuration (including any pending deferred change)
+is inherited across
+.BR fork (2)
+and
+.BR clone (2).
+.IP
+.B Warning:
+Because the compiler or run-time environment
+may be using SVE, using this call without the
+.B PR_SVE_SET_VL_ONEXEC
+flag may crash the calling process.
+The conditions for using it safely are complex and system-dependent.
+Don't use it unless you really know what you are doing.
+.IP
+For more information, see the kernel source file
+.I Documentation/arm64/sve.rst
+.\"commit b693d0b372afb39432e1c49ad7b3454855bc6bed
+(or
+.I Documentation/arm64/sve.txt
+before Linux 5.3).
+.\" prctl PR_SVE_GET_VL
+.TP
+.BR PR_SVE_GET_VL " (since Linux 4.15, only on arm64)"
+Get the thread's current SVE vector length configuration.
+.IP
+Arguments
+.IR arg2 ", " arg3 ", " arg4 " and " arg5
+are ignored.
+.IP
+Providing that the kernel and platform support SVE
+this operation always succeeds,
+returning a nonnegative value that describes the
+.I current
+configuration.
+The bits corresponding to
+.B PR_SVE_VL_LEN_MASK
+contain the currently configured vector length in bytes.
+The bit corresponding to
+.B PR_SVE_VL_INHERIT
+indicates whether the vector length will be inherited
+across
+.BR execve (2).
+.IP
+Note that there is no way to determine whether there is
+a pending vector length change that has not yet taken effect.
+.IP
+For more information, see the kernel source file
+.I Documentation/arm64/sve.rst
+.\"commit b693d0b372afb39432e1c49ad7b3454855bc6bed
+(or
+.I Documentation/arm64/sve.txt
+before Linux 5.3).
.\"
.\" prctl PR_TASK_PERF_EVENTS_DISABLE
.TP
@@ -1534,6 +1676,8 @@ On success,
.BR PR_GET_NO_NEW_PRIVS ,
.BR PR_GET_SECUREBITS ,
.BR PR_GET_SPECULATION_CTRL ,
+.BR PR_SVE_GET_VL ,
+.BR PR_SVE_SET_VL ,
.BR PR_GET_THP_DISABLE ,
.BR PR_GET_TIMING ,
.BR PR_GET_TIMERSLACK ,
@@ -1817,6 +1961,22 @@ and unused arguments to
.BR prctl ()
are not 0.
.TP
+.B EINVAL
+.I option
+is
+.B PR_SVE_SET_VL
+and the arguments are invalid or unsupported,
+or SVE is not available on this platform.
+See the description of
+.B PR_SVE_SET_VL
+above for details.
+.TP
+.B EINVAL
+.I option
+is
+.B PR_SVE_GET_VL
+and SVE is not available on this platform.
+.TP
.B ENODEV
.I option
was
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/6] prctl.2: Add PR_SPEC_DISABLE_NOEXEC for SPECULATION_CTRL prctls
From: Dave Martin @ 2020-05-27 21:17 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-arch, linux-man, Thomas Gleixner, linux-arm-kernel,
Waiman Long
In-Reply-To: <1590614258-24728-1-git-send-email-Dave.Martin@arm.com>
Add the PR_SPEC_DISABLE_NOEXEC mode added in Linux 5.1
for the PR_SPEC_STORE_BYPASS "misfeature" of
PR_SET_SPECULATION_CTRL and PR_GET_SPECULATION_CTRL.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Waiman Long <longman@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
man2/prctl.2 | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/man2/prctl.2 b/man2/prctl.2
index b6fb51c..cab9915 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -1187,6 +1187,12 @@ The speculation feature is disabled, mitigation is enabled.
Same as
.B PR_SPEC_DISABLE
but cannot be undone.
+.TP
+.BR PR_SPEC_DISABLE_NOEXEC " (since Linux 5.1)"
+Same as
+.BR PR_SPEC_DISABLE ,
+but but the state will be cleared on
+.BR execve (2).
.RE
.IP
If all bits are 0,
@@ -1251,6 +1257,17 @@ with the same value for
.I arg2
will fail with the error
.BR EPERM .
+.\" commit 71368af9027f18fe5d1c6f372cfdff7e4bde8b48
+.TP
+.BR PR_SPEC_DISABLE_NOEXEC " (since Linux 5.1)"
+Same as
+.BR PR_SPEC_DISABLE ,
+but but the state will be cleared on
+.BR execve (2).
+Currently only supported for
+.I arg2
+equal to
+.B PR_SPEC_STORE_BYPASS.
.RE
.IP
Any unsupported value in
@@ -1899,11 +1916,12 @@ was
.BR PR_SET_SPECULATION_CTRL
and
.IR arg3
-is neither
+is not
.BR PR_SPEC_ENABLE ,
.BR PR_SPEC_DISABLE ,
+.BR PR_SPEC_FORCE_DISABLE ,
nor
-.BR PR_SPEC_FORCE_DISABLE .
+.BR PR_SPEC_DISABLE_NOEXEC .
.SH VERSIONS
The
.BR prctl ()
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/6] prctl.2: Add PR_SPEC_INDIRECT_BRANCH for SPECULATION_CTRL prctls
From: Dave Martin @ 2020-05-27 21:17 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-arch, linux-man, Thomas Gleixner, Tim Chen,
linux-arm-kernel
In-Reply-To: <1590614258-24728-1-git-send-email-Dave.Martin@arm.com>
Add the PR_SPEC_INDIRECT_BRANCH "misfeature" added in Linux 4.20
for PR_SET_SPECULATION_CTRL and PR_GET_SPECULATION_CTRL.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
man2/prctl.2 | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/man2/prctl.2 b/man2/prctl.2
index dc99218..b6fb51c 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -1213,11 +1213,20 @@ arguments must be specified as 0; otherwise the call fails with the error
.\" commit 356e4bfff2c5489e016fdb925adbf12a1e3950ee
Sets the state of the speculation misfeature specified in
.IR arg2 .
-Currently, the only permitted value for this argument is
+Currently, this argument must be one of:
+.RS
+.TP
.B PR_SPEC_STORE_BYPASS
-(otherwise the call fails with the error
+speculative store bypass control, or
+.\" commit 9137bb27e60e554dab694eafa4cca241fa3a694f
+.TP
+.BR PR_SPEC_INDIRECT_BRANCH " (since Linux 4.20)"
+indirect branch speculation control.
+.RE
+.IP
+(Otherwise the call fails with the error
.BR ENODEV ).
-This setting is a per-thread attribute.
+These settings are per-thread attributes.
The
.IR arg3
argument is used to hand in the control value,
@@ -1235,13 +1244,16 @@ Same as
.BR PR_SPEC_DISABLE ,
but cannot be undone.
A subsequent
-.B
-prctl(..., PR_SPEC_ENABLE)
+.BR prctl (\c
+.IR arg2 ,
+.BR PR_SPEC_ENABLE )
+with the same value for
+.I arg2
will fail with the error
.BR EPERM .
.RE
.IP
-Any other value in
+Any unsupported value in
.IR arg3
will result in the call failing with the error
.BR ERANGE .
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/6] prctl.2: ffix use literal hyphens when referencing kernel docs
From: Dave Martin @ 2020-05-27 21:17 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: linux-arch, linux-man, linux-arm-kernel
In-Reply-To: <1590614258-24728-1-git-send-email-Dave.Martin@arm.com>
There is one case of a cross-reference to a kernel documentation
filename that uses unescaped hyphens.
To avoid misrendering, escape these as \- similarly to other
instances.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
man2/prctl.2 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man2/prctl.2 b/man2/prctl.2
index 968a75a..dc99218 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -1261,7 +1261,7 @@ This parameter may enforce a read-only policy which will result in the
call failing with the error
.BR ENXIO .
For further details, see the kernel source file
-.IR Documentation/admin-guide/kernel-parameters.txt .
+.IR Documentation/admin\-guide/kernel\-parameters.txt .
.\"
.\" prctl PR_TASK_PERF_EVENTS_DISABLE
.TP
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/6] prctl.2 man page updates for Linux 5.6
From: Dave Martin @ 2020-05-27 21:17 UTC (permalink / raw)
To: Michael Kerrisk
Cc: linux-arch, linux-man, Will Deacon, Catalin Marinas, Dave Hansen,
Amit Daniel Kachhap, Waiman Long, Mark Rutland, Vincenzo Frascino,
Tim Chen, Thomas Gleixner, linux-arm-kernel
A bunch of updates to the prctl(2) man page to fill in missing
prctls (mostly) up to Linux 5.6 (along with a few other tweaks and
fixes).
Patches from the v1 series [1] that have been applied or rejected
already have been dropped.
People not Cc'd on the whole series can find the whole series at
https://lore.kernel.org/linux-man/ .
Patches:
* Patch 1 is a new (but trivial) formatting fix, unrelated to the new
prctls.
* Patches 2-3 relate to the speculation control prctls. These are
unmodified from v1, but need review.
* Patches 4-5 relate to the arm64 prctls from v1, with reviewer
feedback incorporated. (See notes in the patches.)
* Patch 6 is *draft* wording for the arm64 address tagging prctls.
The semantics of address tagging is particularly slippery, so
this needs discussion before merging.
[1] https://lore.kernel.org/linux-man/29a02b16-dd61-6186-1340-fcc7d5225ad0@gmail.com/T/#t
Dave Martin (6):
prctl.2: ffix use literal hyphens when referencing kernel docs
prctl.2: Add PR_SPEC_INDIRECT_BRANCH for SPECULATION_CTRL prctls
prctl.2: Add PR_SPEC_DISABLE_NOEXEC for SPECULATION_CTRL prctls
prctl.2: Add SVE prctls (arm64)
prctl.2: Add PR_PAC_RESET_KEYS (arm64)
prctl.2: Add tagged address ABI control prctls (arm64)
man2/prctl.2 | 444 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 435 insertions(+), 9 deletions(-)
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox