On Thu, Oct 1, 2020 at 3:25 AM Jiri Olsa wrote:
>
> On Thu, Oct 01, 2020 at 11:25:34AM +0200, Jiri Olsa wrote:
> > On Wed, Sep 30, 2020 at 07:00:05PM -0700, Ian Rogers wrote:
> > > On Wed, Sep 30, 2020 at 10:15 AM Jiri Olsa wrote:
> > > >
> > > > Adding test for build id cache that adds binary
>
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: a0947081af2ac9549e6ba19877456730713bde23
Gitweb:
https://git.kernel.org/tip/a0947081af2ac9549e6ba19877456730713bde23
Author:Gustavo A. R. Silva
AuthorDate:Thu, 01 Oct 2020 09:56:08 -05:00
Hi.
On Wed, Sep 30, 2020 at 05:27:10PM -0700, Roman Gushchin wrote:
> @@ -369,8 +371,12 @@ enum page_memcg_data_flags {
> */
> static inline struct mem_cgroup *page_memcg(struct page *page)
> {
> + unsigned long memcg_data = page->memcg_data;
> +
> VM_BUG_ON_PAGE(PageSlab(page), pag
On Thu, Oct 01, 2020 at 09:28:49AM -0400, Qian Cai wrote:
> When CONFIG_PCIEASPM=n,
>
> drivers/pci/pci.c:3098:12: warning: 'pci_ltr_encode' defined but not used
> [-Wunused-function]
> static u16 pci_ltr_encode(u64 val)
> ^~
> drivers/pci/pci.c:3076:12: warning: 'pci_ltr
On Sat, Sep 26, 2020 at 02:55:42PM +0200, khol...@gmail.com wrote:
> AngeloGioacchino Del Regno (7):
> regulator: core: Enlarge max OF property name length to 64 chars
> regulator: qcom_spmi: Add support for new regulator types
> regulator: qcom_spmi: Add PM660/PM660L regulators
> regulato
On Thu, Oct 01, 2020 at 05:47:54PM +0200, Jann Horn via Containers wrote:
> On Thu, Oct 1, 2020 at 2:54 PM Christian Brauner
> wrote:
> > On Wed, Sep 30, 2020 at 05:53:46PM +0200, Jann Horn via Containers wrote:
> > > On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
> > > wrote:
> > >
From: Mickaël Salaün
Wire up trusted_for(2) for all architectures.
Signed-off-by: Mickaël Salaün
Reviewed-by: Thibaut Sautereau
Cc: Al Viro
Cc: Andrew Morton
Cc: Arnd Bergmann
Cc: Kees Cook
Cc: Vincent Strubel
---
Changes since v9:
* Rename introspect_access(2) to trusted_for(2).
* Incre
From: Mickaël Salaün
The trusted_for() syscall enables user space tasks to check that files
are trusted to be executed or interpreted by user space. This may allow
script interpreters to check execution permission before reading
commands from a file, or dynamic linkers to allow shared object loa
On Thu, Oct 01, 2020 at 05:47:54PM +0200, Jann Horn wrote:
> On Thu, Oct 1, 2020 at 2:54 PM Christian Brauner
> wrote:
> > On Wed, Sep 30, 2020 at 05:53:46PM +0200, Jann Horn via Containers wrote:
> > > On Wed, Sep 30, 2020 at 1:07 PM Michael Kerrisk (man-pages)
> > > wrote:
> > > > NOTES
> > > >
Document and adjust the compatibles for i.MX6QP based boards.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/fsl.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl
Hi,
This is a continuation of my series:
https://lore.kernel.org/linux-arm-kernel/20200930190143.27032-1-k...@kernel.org/
It is rebased on top of it and finally fixes remaining i.MX2 - i.MX8
boards compatibles.
There is ongoing discussion in my previous patchset about imx6q-pico
(Technexion) boa
Document and adjust the compatibles for i.MX6SL based boards.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl.yaml
Document the binding for the Element14, a Premier Farnell company.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetre
Document and adjust the compatibles for i.MX6Q based boards.
The Toradex and the Armadeus boards use multiple compatibles.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/arm/fsl.yaml | 83 +--
1 file changed, 77 insertions(+), 6 deletions(-)
diff --git a
Document and adjust the compatibles for i.MX6SX based boards.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/fsl.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bindings/arm/fsl
There are four flavors of TechNexion PICO-IMX6 boards. They have their
own DTSes, even though in Dwarf, Nymph and Pi are exactly the same.
They also have their own bindings so adjust the compatibles to match the
bindings.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/imx6q-pico-dwarf
The WaRP board (Wearable Development Platform) was apparently made by
Revolution Robotics, Inc (brand: Revotics), not by "Warp". Correct the
vendor in compatible to reflect this. The compatibles were not
documented in the bindings before.
Link: https://revotics.com/warp
Signed-off-by: Krzysztof
The WaRP7 board (Wearable Development Platform) was apparently made by
Element14, not by "Warp". Correct the vendor in compatible to reflect
this. The compatibles were not documented in the bindings before.
Link: https://www.element14.com/community/docs/DOC-79058
Signed-off-by: Krzysztof Kozlow
Document and adjust the compatibles for i.MX7D based boards.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/fsl.yaml | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
b/Documentation/devicetree/bi
On Thu, Oct 1, 2020 at 12:25 AM Alexei Starovoitov
wrote:
>
> On Wed, Sep 30, 2020 at 10:28:33AM +0100, Lorenz Bauer wrote:
> > On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov
> > wrote:
> >
> > ...
> >
> > > There was a warning. I noticed it while applying and fixed it up.
> > > Lorenz, please
Document and adjust the compatibles for i.MX7S based boards.
The Toradex boards use multiple compatibles.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/fsl.yaml | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetre
Document and adjust the compatibles for i.MX6UL based boards.
The Armadeus boards use multiple compatibles.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/arm/fsl.yaml | 25 +--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/
Document and adjust the compatibles for i.MX6ULL based boards.
The Armadeus boards use multiple compatibles.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/
On Thu, Oct 1, 2020 at 10:09 AM Andrii Nakryiko
wrote:
>
> On Thu, Oct 1, 2020 at 12:25 AM Alexei Starovoitov
> wrote:
> >
> > On Wed, Sep 30, 2020 at 10:28:33AM +0100, Lorenz Bauer wrote:
> > > On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov
> > > wrote:
> > >
> > > ...
> > >
> > > > There was
Hi,
This eleventh patch series brings small fixes.
Andrew, should this be merged with your tree?
The final goal of this patch series is to enable the kernel to be a
global policy manager by entrusting processes with access control at
their level. To reach this goal, two complementary parts are
On Mon, Sep 21, 2020 at 06:36:02PM +0200, Peter Zijlstra wrote:
[...]
> +
> + [CPUHP_AP_SCHED_WAIT_EMPTY] = {
> + .name = "sched:waitempty",
> + .startup.single = NULL,
> + .teardown.single= sched_cpu_wait_empty,
> + },
From: Mickaël Salaün
Test that checks performed by trusted_for(2) on file descriptors are
consistent with noexec mount points and file execute permissions,
according to the policy configured with the fs.trust_policy sysctl.
Signed-off-by: Mickaël Salaün
Reviewed-by: Thibaut Sautereau
Cc: Al Vi
On Thu, Oct 01, 2020 at 10:58:50AM -0600, Tycho Andersen wrote:
> On Thu, Oct 01, 2020 at 05:47:54PM +0200, Jann Horn via Containers wrote:
> > On Thu, Oct 1, 2020 at 2:54 PM Christian Brauner
> > wrote:
> > > On Wed, Sep 30, 2020 at 05:53:46PM +0200, Jann Horn via Containers wrote:
> > > > On Wed
On Thu, Oct 01, 2020 at 07:53:53PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> include/acpi/acpi_numa.h
>
> between commit:
>
> 4849bc777049 ("ACPI / NUMA: Add stub function for pxm_to_node()")
>
> from the pm tree a
Hi Andy,
Customers using BMC with complex i2c topology asked us to support
changing bus frequency at run time, for example same device will
communicate with one slave at 100Kbp/s and another with 400kbp/s and
maybe also with smae device at different speed (for example an i2c
mux).
This is not only
Hi Nicolas,
Thanks for putting this together.
On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 4602e467ca8b..cd0d115ef329 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -25,6 +25,7 @@
> #include
>
Hi guys,
On 17/09/2020 09:40, Borislav Petkov wrote:
> On Thu, Sep 10, 2020 at 03:29:56PM +, Shiju Jose wrote:
> You can't know what exactly you wanna do if you don't have a use case
> you're trying to address.
>
>> According to the ARM Processor CPER definition the error types
>> reported a
On Tue, Sep 15, 2020 at 02:05:13PM +0300, Jarkko Sakkinen wrote:
> +/**
> + * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_PROVISION
> + * @filep: open file to /dev/sgx
> + * @arg: userspace pointer to a struct sgx_enclave_provision instance
> + *
> + * Mark the enclave as bei
On 10/1/20 9:49 AM, Thomas Gleixner wrote:
>>> This is really a hack. TWA_SIGNAL is a misnomer with the new
>>> functionality and combined with the above
>>>
>>> if (!ret && !notify)
>>> wake_up_process(tsk);
>>>
>>> there is not really a big difference between TWA_RESUME and T
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Don't mention "GNU General Public License version 2" text explicitly,
> as it's already covered by the SPDX-License-Identifier.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Marco Elver
> --
On Thu, Oct 01, 2020 at 06:17:39PM +0200, Nicolas Saenz Julienne wrote:
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e1a69a618832..3c3f462466eb 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -43,8 +43,6 @@
> #include
> #include
>
> -#define ARM64_Z
Checkpatch.pl doesn't have a check for excluding while (...) {...}
blocks from MULTISTATEMENT_MACRO_USE_DO_WHILE error.
For example, running checkpatch.pl on the file mm/maccess.c in the
kernel generates the following error:
ERROR: Macros with complex values should be enclosed in parentheses
+#de
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Currently only generic KASAN mode supports vmalloc, reflect that
> in the config.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Marco Elver
> ---
> Change-Id: I1889e5b3bed28cc5d607802fb6ae43
On Thu, Oct 01, 2020 at 06:17:40PM +0200, Nicolas Saenz Julienne wrote:
> The default behavior for arm64 changed, so reflect that.
>
> Signed-off-by: Nicolas Saenz Julienne
Acked-by: Catalin Marinas
On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> Hi Nicolas,
>
> Thanks for putting this together.
>
> On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 4602e467ca8b..cd0d115ef329 100644
> > ---
On Thu, 2020-10-01 at 22:49 +0530, Dwaipayan Ray wrote:
> Checkpatch.pl doesn't have a check for excluding while (...) {...}
> blocks from MULTISTATEMENT_MACRO_USE_DO_WHILE error.
>
> For example, running checkpatch.pl on the file mm/maccess.c in the
> kernel generates the following error:
>
> ER
On Thu, Oct 1, 2020 at 6:30 AM Thomas Gleixner wrote:
>
> On Thu, Oct 01 2020 at 11:13, Thomas Gleixner wrote:
> > Yes, it's ugly and I haven't figured out a proper way to deal with
> > that. There are quite some mbox formats out there and they all are
> > incompatible with each other and all of t
On Thu, Oct 1, 2020 at 9:51 AM Yu, Yu-cheng wrote:
>
> On 9/30/2020 6:10 PM, Andy Lutomirski wrote:
> > On Wed, Sep 30, 2020 at 6:01 PM H.J. Lu wrote:
> >>
> >> On Wed, Sep 30, 2020 at 4:44 PM Andy Lutomirski wrote:
>
> [...]
>
> >>>From 09803e66dca38d7784e32687d0693550948199ed Mon Sep 1
On 10/1/20 10:27 AM, Oleg Nesterov wrote:
> Jens,
>
> I'll read this version tomorrow, but:
>
> On 10/01, Jens Axboe wrote:
>>
>> static inline int signal_pending(struct task_struct *p)
>> {
>> -return unlikely(test_tsk_thread_flag(p,TIF_SIGPENDING));
>> +#ifdef TIF_TASKWORK
>> +/*
>> +
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> Group all vmalloc-related function declarations in include/linux/kasan.h,
> and their implementations in mm/kasan/common
Hi Daniel,
On 10/1/20 10:48 AM, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 01:53:46PM +0200, Alexandre Bailon wrote:
This adds a RPMsg driver that implements communication between the CPU and an
APU.
This uses VirtIO buffer to exchange messages but for sharing data, this uses
a dmabuf, mapped
On Thu, Oct 01, 2020 at 07:00:36PM +0200, Michal Koutný wrote:
> Hi.
>
> On Wed, Sep 30, 2020 at 05:27:10PM -0700, Roman Gushchin wrote:
> > @@ -369,8 +371,12 @@ enum page_memcg_data_flags {
> > */
> > static inline struct mem_cgroup *page_memcg(struct page *page)
> > {
> > + unsigned long
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> Group shadow-related KASAN function declarations and only define them
> for the two existing software modes.
>
> No fun
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> The new mode won't be using shadow memory, but will reuse the same
> functions. Rename kasan_unpoison_shadow to kasan_un
The pull request you sent on Thu, 1 Oct 2020 16:10:22 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-10-01-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fcadab740480e0e0e9fa9bd272acd409884d431a
Thank you!
--
Deet-doot-dot, I am a bot.
https://
The pull request you sent on Wed, 30 Sep 2020 19:53:59 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
> trace-v5.9-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aa5ff93523ebc9f4cfd9fb37d021b5204ce14657
Thank you!
--
Deet-doot-do
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> The new mode won't be using shadow memory, but will still use the concept
> of memory granules. Each memory granule maps
On Thu, 2020-10-01 at 18:23 +0100, Catalin Marinas wrote:
> On Thu, Oct 01, 2020 at 06:15:01PM +0100, Catalin Marinas wrote:
> > Hi Nicolas,
> >
> > Thanks for putting this together.
> >
> > On Thu, Oct 01, 2020 at 06:17:37PM +0200, Nicolas Saenz Julienne wrote:
> > > diff --git a/drivers/of/fdt.
On Thu, Oct 01, 2020 at 06:16:03PM +0100, James Morse wrote:
> If the corrected-count is available somewhere, can't this policy be
> made in user-space?
You mean rasdaemon goes and offlines CPUs when certain thresholds are
reached? Sure. It would be much more flexible too.
--
Regards/Gruss,
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> The new mode won't be using shadow memory, so only build init.c that
> contains shadow initialization code for software
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> The new mode won't be using shadow memory. Move all shadow-related code
> to shadow.c, which is only enabled for softwar
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Define KASAN_GRANULE_PAGE as (KASAN_GRANULE_SIZE << PAGE_SHIFT), which is
> the same as (KASAN_GRANULE_SIZE * PAGE_SIZE), and use it across KASAN code
> to simplify it.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo F
The "prefix" can be defined in DAI link node or it can be specified as
part of the component node itself. Currently "sound-name-prefix" defined
in a component is not taking effect. Actually the property is not getting
parsed. It can be fixed by parsing "sound-name-prefix" property whenever
"prefix"
Summary of changes:
* Support multiple instances of a component. For example there can be
multiple I2S devices which can use the same component driver.
* Support open platforms with empty Codec endpoint. Customers can plug
their own HW and can populate codec endpoint.
* In a component mo
dpcm_end_walk_at_be() stops the graph walk when first BE is found for
the given FE component. In a component model we may want to connect
multiple DAIs from different components. A new flag is introduced in
'snd_soc_card', which when set allows DAI/component chaining. Later
PCM operations can be ca
PCM devices are created for FE dai links with 'no-pcm' flag as '0'.
Such DAI links have CPU component which implement either pcm_construct()
or pcm_new() at component or dai level respectively. Based on this,
current patch exposes a helper function to identify such components
and populate 'no_pcm'
As per the members exposed earlier in the series, audio graph driver
is updated to make use of these. Functionally there is no change
in behavior if these are not populated. So following changes are made
as part of this.
- Update 'dai_link->ops' for DPCM links if a custom 'snd_soc_ops'
is defi
Add new members in struct 'asoc_simple_priv'. Idea is to leverage
simple or graph card driver as much as possible and vendor can
maintain a thin driver to control the behavior by populating these
newly exposed members.
Following are the members added in 'asoc_simple_priv':
- 'ops' struct: In so
For multiple instances of components, using DAI name alone for DAI links
is causing conflicts. Components can define multiple DAIs and hence using
just a device name won't help either. Thus DT device node reference and
DAI names are used to uniquely represent DAI link names.
Signed-off-by: Sameer
For open platforms, which can support pluggable audio cards, Codec
endpoint is not fixed always. It actually depends on the compatible
HW module that is going to be connected. From SoC side the given I/O
interface is always available. Hence such links have fixed CPU endpoint
but no Codec endpoint.
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 75df529bec9110dad43ab30e2d9490242529e8b8:
arm64: paravirt: Initialize steal time when cpu is online (2020-09-17
18:12:18 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/
Add Tegra audio machine driver which is based on generic audio graph card
driver. It re-uses most of the common stuff from audio graph driver and
uses the same DT binding. Required Tegra specific customizations are done
in the driver.
Details on the customizations done:
- Update PLL rates at run
This commit enables Tegra audio graph card driver which is based on
the generic audio-graph card driver. This is intended to be used
on platforms based on Tegra210 and later chips.
Signed-off-by: Sameer Pujar
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/ar
Add YAML schema for Tegra audio graph sound card DT bindings. It uses the
same DT bindings provided by generic audio graph driver. Along with this
few standard clock DT bindings are added which are specifically required
for Tegra audio.
Signed-off-by: Sameer Pujar
---
.../sound/nvidia,tegra-audi
This commit exposes following functions which can be used by a sound
card driver based on audio graph driver. Idea is vendors can have a
thin driver and re-use common stuff from audio graph driver.
- graph_card_probe()
- graph_get_dais_count()
- graph_parse_of()
In doing so a new header file i
Enable support for audio-graph based sound card on Jetson-Nano and
Jetson-TX1. Depending on the platform, required I/O interfaces are
enabled.
* Jetson-Nano: Enable I2S3, I2S4, DMIC1 and DMIC2.
* Jetson-TX1: Enable all I2S and DMIC interfaces.
Signed-off-by: Sameer Pujar
---
arch/arm64/boot/d
Expose a header which describes DT bindings required to use audio-graph
based sound card. All Tegra210 based platforms can include this header
and add platform specific information. Currently, from SoC point of view,
all links are exposed for ADMAIF, AHUB, I2S and DMIC components.
Signed-off-by: S
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Rename generic_report.c to report_generic.c and tags_report.c to
> report_sw_tags.c, as their content is more relevant to report.c file.
> Also rename tags.c to sw_tags.c to better reflect that this file contains
> code for software t
On Tue, Sep 15, 2020 at 02:28:29PM +0300, Jarkko Sakkinen wrote:
> +int __init sgx_drv_init(void)
> +{
> + unsigned int eax, ebx, ecx, edx;
> + u64 attr_mask, xfrm_mask;
> + int ret;
> + int i;
> +
> + if (!boot_cpu_has(X86_FEATURE_SGX_LC)) {
> + pr_info("The public
On Thu, Oct 01, 2020 at 10:33:26AM +0100, Daniel Scally wrote:
Awesome work!
My, almost minor, comments below.
> Currently on platforms designed for Windows, connections between CIO2 and
> sensors are not properly defined in DSDT. This patch extends the ipu3-cio2
> driver to compensate by buildin
On 01.10.20 18:54, Dan Williams wrote:
> On Thu, Oct 1, 2020 at 1:41 AM David Hildenbrand wrote:
>>
>> On 25.09.20 21:11, Dan Williams wrote:
>>> The passed in dev_pagemap is only required in the pmem case as the
>>> libnvdimm core may have reserved a vmem_altmap for dev_memremap_pages() to
>>> pl
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Both KASAN_GENERIC and KASAN_SW_TAGS have common dependencies, move
> those to KASAN.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Marco Elver
But see comment below:
> ---
> Change-Id: I77
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> For software KASAN modes the check is based on the value in the shadow
> memory. Hardware tag-based KASAN won't be using
On Thu, Oct 01, 2020 at 08:13:49PM +0300, Avi Fishman wrote:
> Hi Andy,
>
> Customers using BMC with complex i2c topology asked us to support
> changing bus frequency at run time, for example same device will
> communicate with one slave at 100Kbp/s and another with 400kbp/s and
> maybe also with
On Wed, Sep 30, 2020 at 05:07:20PM -0700, Stephen Boyd wrote:
> Quoting David Collins (2020-09-22 15:04:18)
> > This helps to disambiguate SPMI device regmaps from I2C ones
> > at /sys/kernel/debug/regmap since I2C devices use a very
> > similar naming scheme: 0-.
> Can regmap debugfs prepend
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Decoding routines aren't needed when CONFIG_KASAN_STACK_ENABLE is not
> enabled. Currently only generic KASAN mode implements stack error
> reporting.
>
> No functional changes for software modes.
>
> Signed-off-by: Andrey Konovalov
Our current handling of illegal task FPU state is currently rather
simplistic. We basically ignore the issue with this extable code:
/*
* Handler for when we fail to restore a task's FPU state. We should never get
* here because the FPU state of a task using the FPU (task->thread.fpu.state)
*
On Thu, Oct 1, 2020 at 9:26 AM Andy Shevchenko
wrote:
>
> On Thu, Oct 1, 2020 at 4:43 AM David E. Box
> wrote:
> >
> > From: Alexander Duyck
> >
> > Intel Platform Monitoring Technology is meant to provide a common way to
> > access telemetry and system metrics.
> >
> > Register mappings are no
On Fri, Sep 04, 2020 at 09:31:05PM -0400, Lenny Szubowicz wrote:
> Because of system-specific EFI firmware limitations, EFI volatile
> variables may not be capable of holding the required contents of
> the Machine Owner Key (MOK) certificate store when the certificate
> list grows above some size.
On Fri, Sep 25, 2020 at 12:50AM +0200, 'Andrey Konovalov' via kasan-dev wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> Hardware tag-based KASAN won't be using shadow memory, but will reuse
> this function. Rename "shadow" t
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> Hardware tag-based KASAN won't be using shadow memory, but will reuse
> this function. Rename "shadow" to implementation
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> kasan_non_canonical_hook() is only applicable to KASAN modes that use
> shadow memory, and won't be needed for hardware
> https://github.com/0day-ci/linux/commits/Scott-Branden/Add-Broadcom-VK-driver/20201001-093119
> base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
> c471bf4b11c7df0f0f9f42b5aeec424dc62d0c7e
> config: powerpc-allyesconfig (attached as .config)
>
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> Hardware tag-based KASAN won't be using shadow memory, but will reuse
> these macros. Rename "SHADOW" to implementation-
On Thu, Oct 01, 2020 at 10:33:26AM +0100, Daniel Scally wrote:
...
> This patch is dependent on another (which implements the software node graph
> family of functions):
>
> https://lore.kernel.org/linux-media/20200915232827.3416-1-djrsca...@gmail.com/
More thoughts about the (future) series. C
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
Not sure why I've only noticed this now, but all these patches seem to
say "This is a preparatory commit" -- I don't think "
On Thu, Oct 1, 2020 at 7:46 PM Alexander Duyck
wrote:
> On Thu, Oct 1, 2020 at 9:03 AM Andy Shevchenko
> wrote:
> > > +static struct platform_driver pmt_telem_driver = {
> > > + .driver = {
> > > + .name = TELEM_DEV_NAME,
> >
> > I'm not sure I have interpreted this:
> >
Does that patch title need an ", arm64" in it, like the others?
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Software tag-based KASAN provides its own tag checking machinery that
> can conflict with MTE. Don't allow enabling software tag-based KASAN
> when MTE is enabled.
>
>
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> This patch adds a configuration option for a new KASAN mode called
> hardware tag-based KASAN. This mode uses the memory tagging approach
> like the software tag-based mode, but relies on arm64 Memory Tagging
> Extension feature for t
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Hardware tag-based KASAN has granules of MTE_GRANULE_SIZE. Define
> KASAN_GRANULE_SIZE to MTE_GRANULE_SIZE for CONFIG_KASAN_HW_TAGS.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
Reviewed-by: Marco Elver
On Thu, Oct 01, 2020 at 01:24:49PM +0200, Alexander Potapenko wrote:
> Mark,
>
> > If you need virt_to_page() to work, the address has to be part of the
> > linear/direct map.
> >
> > If you need to find the struct page for something that's part of the
> > kernel image you can use virt_to_page(lm_
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> With the intoduction of hardware tag-based KASAN some kernel checks of
> this kind:
>
> ifdef CONFIG_KASAN
>
> will be updated to:
>
> if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
>
> x86 and s390 use a tr
On Thu, Oct 01, 2020 at 09:56:08AM -0500, Gustavo A. R. Silva wrote:
> There is a regular need in the kernel to provide a way to declare having
> a dynamically sized set of trailing elements in a structure. Kernel code
> should always use “flexible array members”[1] for these cases. The older
> sty
On Fri, Sep 25, 2020 at 12:50AM +0200, Andrey Konovalov wrote:
> Provide implementation of KASAN functions required for the hardware
> tag-based mode. Those include core functions for memory and pointer
> tagging (tags_hw.c) and bug reporting (report_tags_hw.c). Also adapt
> common KASAN code to su
Hi Henrik,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Henrik-Bjoernlund/net-bridge-cfm-Add-support-for-Connectivity-Fault-Management-CFM/20201001-184031
base: https://git.kernel.org/pub
701 - 800 of 1340 matches
Mail list logo
