[PATCH net-next 04/17] rxrpc: Support keys with multiple authentication tokens

rxrpc-type keys can have multiple tokens attached for different security classes. Currently, rxrpc always picks the first one, whether or not the security class it indicates is supported. Add preliminary support for choosing which security class will be used (this will need to be directed from a

[PATCH net-next 03/17] rxrpc: List the held token types in the key description in /proc/keys

When viewing an rxrpc-type key through /proc/keys, display a list of held token types. Signed-off-by: David Howells --- net/rxrpc/key.c | 29 - 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c index

[PATCH net 00/17] rxrpc: Prelude to gssapi support

rxrpc-next-20201123 and can also be found on the following branch: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-next David --- David Howells (17): keys: Provide the original description to the key preparser rxrpc: Remove the rxk5 security class

[PATCH net-next 01/17] keys: Provide the original description to the key preparser

Provide the proposed description (add key) or the original description (update/instantiate key) when preparsing a key so that the key type can validate it against the data. This is important for rxrpc server keys as we need to check that they have the right amount of key material present - and

[PATCH mm v11 41/42] kasan: add documentation for hardware tag-based mode

Add documentation for hardware tag-based KASAN mode and also add some clarifications for software tag-based mode. Signed-off-by: Andrey Konovalov Signed-off-by: Vincenzo Frascino Reviewed-by: Marco Elver Reviewed-by: Alexander Potapenko --- Change-Id: Ib46cb444cfdee44054628940a82f5139e10d0258

[PATCH mm v11 42/42] kselftest/arm64: Check GCR_EL1 after context switch

From: Vincenzo Frascino This test is specific to MTE and verifies that the GCR_EL1 register is context switched correctly. It spawns 1024 processes and each process spawns 5 threads. Each thread writes a random setting of GCR_EL1 through the prctl() system call and reads it back verifying that

[PATCH mm v11 39/42] kasan, mm: reset tags when accessing metadata

Kernel allocator code accesses metadata for slab objects, that may lie out-of-bounds of the object itself, or be accessed when an object is freed. Such accesses trigger tag faults and lead to false-positive reports with hardware tag-based KASAN. Software KASAN modes disable instrumentation for

[PATCH mm v11 40/42] kasan, arm64: enable CONFIG_KASAN_HW_TAGS

Hardware tag-based KASAN is now ready, enable the configuration option. Signed-off-by: Andrey Konovalov Signed-off-by: Vincenzo Frascino Acked-by: Catalin Marinas Reviewed-by: Alexander Potapenko --- Change-Id: I6eb1eea770e6b61ad71c701231b8d815a7ccc853 --- arch/arm64/Kconfig | 1 + 1 file

[PATCH mm v11 35/42] kasan, x86, s390: update undef CONFIG_KASAN

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 trick to #undef CONFIG_KASAN for some of the code that isn't linked with KASAN

[PATCH mm v11 36/42] kasan, arm64: expand CONFIG_KASAN checks

Some #ifdef CONFIG_KASAN checks are only relevant for software KASAN modes (either related to shadow memory or compiler instrumentation). Expand those into CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS. Signed-off-by: Andrey Konovalov Signed-off-by: Vincenzo Frascino Reviewed-by: Catalin Marinas

[PATCH mm v11 32/42] arm64: kasan: Align allocations for HW_TAGS

Hardware tag-based KASAN uses the memory tagging approach, which requires all allocations to be aligned to the memory granule size. Align the allocations to MTE_GRANULE_SIZE via ARCH_SLAB_MINALIGN when CONFIG_KASAN_HW_TAGS is enabled. Signed-off-by: Andrey Konovalov Signed-off-by: Vincenzo

[PATCH mm v11 29/42] arm64: mte: Convert gcr_user into an exclude mask

From: Vincenzo Frascino The gcr_user mask is a per thread mask that represents the tags that are excluded from random generation when the Memory Tagging Extension is present and an 'irg' instruction is invoked. gcr_user affects the behavior on EL0 only. Currently that mask is an include mask

[PATCH mm v11 31/42] kasan, mm: untag page address in free_reserved_area

From: Vincenzo Frascino free_reserved_area() memsets the pages belonging to a given memory area. As that memory hasn't been allocated via page_alloc, the KASAN tags that those pages have are 0x00. As the result the memset might result in a tag mismatch. Untag the address to avoid spurious

[PATCH mm v11 28/42] arm64: kasan: Allow enabling in-kernel MTE

From: Vincenzo Frascino Hardware tag-based KASAN relies on Memory Tagging Extension (MTE) feature and requires it to be enabled. MTE supports This patch adds a new mte_enable_kernel() helper, that enables MTE in Synchronous mode in EL1 and is intended to be called from KASAN runtime during

[PATCH mm v11 24/42] arm64: Enable armv8.5-a asm-arch option

From: Vincenzo Frascino Hardware tag-based KASAN relies on Memory Tagging Extension (MTE) which is an armv8.5-a architecture extension. Enable the correct asm option when the compiler supports it in order to allow the usage of ALTERNATIVE()s with MTE instructions. Signed-off-by: Vincenzo

[PATCH mm v11 26/42] arm64: mte: Reset the page tag in page->flags

From: Vincenzo Frascino The hardware tag-based KASAN for compatibility with the other modes stores the tag associated to a page in page->flags. Due to this the kernel faults on access when it allocates a page with an initial tag and the user changes the tags. Reset the tag associated by the

[PATCH mm v11 23/42] kasan: introduce CONFIG_KASAN_HW_TAGS

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 tag management and access checking. Signed-off-by: Andrey Konovalov

[PATCH mm v11 25/42] arm64: mte: Add in-kernel MTE helpers

From: Vincenzo Frascino Provide helper functions to manipulate allocation and pointer tags for kernel addresses. Low-level helper functions (mte_assign_*, written in assembly) operate tag values from the [0x0, 0xF] range. High-level helper functions (mte_get/set_*) use the [0xF0, 0xFF] range to

[PATCH mm v11 22/42] kasan, arm64: don't allow SW_TAGS with ARM64_MTE

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. Signed-off-by: Andrey Konovalov Signed-off-by: Vincenzo Frascino Reviewed-by: Catalin Marinas Reviewed-by: Alexander Potapenko ---

[PATCH mm v11 19/42] kasan: rename print_shadow_for_address to print_memory_metadata

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-neutral "metadata". No functional changes. Signed-off-by: Andrey

[PATCH mm v11 21/42] kasan: separate metadata_fetch_row for each mode

This is a preparatory commit for the upcoming addition of a new hardware tag-based (MTE-based) KASAN mode. Rework print_memory_metadata() to make it agnostic with regard to the way metadata is stored. Allow providing a separate metadata_fetch_row() implementation for each KASAN mode. Hardware

[PATCH mm v11 20/42] kasan: rename SHADOW layout macros to META

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-neutral "META". No functional changes. Signed-off-by: Andrey Konovalov

[PATCH mm v11 12/42] kasan: hide invalid free check implementation

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 shadow, so hide the implementation of the check in

[PATCH mm v11 14/42] kasan, arm64: only init shadow for software modes

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. Only initialize it when one of the software KASAN modes are enabled. No functional changes for software modes. Signed-off-by: Andrey

[PATCH mm v11 17/42] kasan, arm64: rename kasan_init_tags and mark as __init

Rename kasan_init_tags() to kasan_init_sw_tags() as the upcoming hardware tag-based KASAN mode will have its own initialization routine. Also similarly to kasan_init() mark kasan_init_tags() as __init. Signed-off-by: Andrey Konovalov Reviewed-by: Catalin Marinas Reviewed-by: Alexander Potapenko

[PATCH mm v11 15/42] kasan, arm64: only use kasan_depth for software modes

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 use kasan_depth. Only define and use it when one of the software KASAN modes are enabled. No functional changes for software modes. Signed-off-by: Andrey

[PATCH mm v11 16/42] kasan, arm64: move initialization message

Software tag-based KASAN mode is fully initialized with kasan_init_tags(), while the generic mode only requires kasan_init(). Move the initialization message for tag-based mode into kasan_init_tags(). Also fix pr_fmt() usage for KASAN code: generic.c doesn't need it as it doesn't use any printing

[PATCH mm v11 13/42] kasan: decode stack frame only with KASAN_STACK_ENABLE

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 Signed-off-by: Vincenzo Frascino Reviewed-by: Marco Elver Reviewed-by:

[PATCH mm v11 11/42] kasan: don't duplicate config dependencies

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 Reviewed-by: Alexander Potapenko --- Change-Id: I77e475802e8f1750b9154fe4a6e6da4456054fcd --- lib/Kconfig.kasan | 8

[PATCH mm v11 10/42] kasan: rename report and tags files

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 tag-based mode. No functional changes. Signed-off-by: Andrey

[PATCH mm v11 09/42] kasan: define KASAN_MEMORY_PER_SHADOW_PAGE

Define KASAN_MEMORY_PER_SHADOW_PAGE as (KASAN_GRANULE_SIZE << PAGE_SHIFT), which is the same as (KASAN_GRANULE_SIZE * PAGE_SIZE) for software modes that use shadow memory, and use it across KASAN code to simplify it. Signed-off-by: Andrey Konovalov Signed-off-by: Vincenzo Frascino Reviewed-by:

[PATCH mm v11 08/42] kasan: split out shadow.c from common.c

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 software KASAN modes that use shadow memory. No functional changes for

[PATCH mm v11 07/42] kasan: only build init.c for software modes

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 modes. No functional changes for software modes. Signed-off-by: Andrey

[PATCH mm v11 06/42] kasan: rename KASAN_SHADOW_* to KASAN_GRANULE_*

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 to a single metadata entry: 8 bytes per one shadow byte for generic

[PATCH mm v11 05/42] kasan: rename (un)poison_shadow to (un)poison_range

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. Rename external annotation kasan_unpoison_shadow() to kasan_unpoison_range(), and introduce internal functions (un)poison_range() (without kasan_

[PATCH mm v11 04/42] kasan: shadow declarations only for software modes

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 functional changes for software modes. Signed-off-by: Andrey Konovalov

[PATCH mm v11 02/42] kasan: KASAN_VMALLOC depends on KASAN_GENERIC

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 Reviewed-by: Alexander Potapenko --- Change-Id: I1889e5b3bed28cc5d607802fb6ae43ba461c0dc1 --- lib/Kconfig.kasan | 2 +- 1

[PATCH mm v11 03/42] kasan: group vmalloc code

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.c. No functional changes. Signed-off-by: Andrey Konovalov

[PATCH mm v11 01/42] kasan: drop unnecessary GPL text from comment headers

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 Reviewed-by: Alexander Potapenko --- Change-Id:

[PATCH mm v11 00/42] kasan: add hardware tag-based mode for arm64

This patchset adds a new hardware tag-based mode to KASAN [1]. The new mode is similar to the existing software tag-based KASAN, but relies on arm64 Memory Tagging Extension (MTE) [2] to perform memory and pointer tagging (instead of shadow memory and compiler instrumentation). This patchset is

Re: [PATCH] [RFC] init/main: fix broken buffer_init when DEFERRED_STRUCT_PAGE_INIT set

On Mon, 23 Nov 2020 19:05:00 +0800 Lin Feng wrote: > In the booting phase if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set, > we have following callchain: > > start_kernel > ... > mm_init > mem_init > memblock_free_all >reset_all_zones_managed_pages >

Re: [PATCH 6/6] mm: proc: Avoid fullmm flush for young/dirty bit toggling

On Mon, Nov 23, 2020 at 06:35:55PM +, Will Deacon wrote: > On Fri, Nov 20, 2020 at 01:40:05PM -0700, Yu Zhao wrote: > > On Fri, Nov 20, 2020 at 02:35:57PM +, Will Deacon wrote: > > > clear_refs_write() uses the 'fullmm' API for invalidating TLBs after > > > updating the page-tables for the

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote: > IB/hfi1: Fix fall-through warnings for Clang > IB/mlx4: Fix fall-through warnings for Clang > IB/qedr: Fix fall-through warnings for Clang > RDMA/mlx5: Fix fall-through warnings for Clang I picked these four to the

Re: [PATCH v2 3/6] dt-bindings: ata: tegra: Convert binding documentation to YAML

On 11/23/20 11:01 AM, Sowjanya Komatineni wrote: On 11/20/20 12:17 PM, Rob Herring wrote: On Fri, Nov 13, 2020 at 1:36 PM Sowjanya Komatineni wrote: This patch converts text based dt-binding document to YAML based dt-binding document. Signed-off-by: Sowjanya Komatineni ---  

Re: [patch 14/19] softirq: Make softirq control and processing RT aware

On Mon, Nov 23, 2020 at 08:27:33PM +0100, Thomas Gleixner wrote: > On Mon, Nov 23 2020 at 14:44, Frederic Weisbecker wrote: > > On Fri, Nov 13, 2020 at 03:02:21PM +0100, Thomas Gleixner wrote: > >> + /* > >> + * Adjust softirq count to SOFTIRQ_OFFSET which makes > >> + * in_serving_softirq()

Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers

On 20-11-23 11:32:33, Dan Williams wrote: > On Mon, Nov 23, 2020 at 11:20 AM Ben Widawsky wrote: > [..] > > > -ENXIO is fine with me. I just don't see it as often so I don't > > > really know what it is. > > > > > > Bjorn > > > > Dan, Bjorn, I did a fairly randomized look at various probe

Re: [PATCH v2 tip/core/rcu 1/6] srcu: Make Tiny SRCU use multi-bit grace-period counter

On Mon, Nov 23, 2020 at 10:01:13AM +0530, Neeraj Upadhyay wrote: > On 11/21/2020 6:29 AM, paul...@kernel.org wrote: > > From: "Paul E. McKenney" > > > > There is a need for a polling interface for SRCU grace periods. This > > polling needs to distinguish between an SRCU instance being idle on

Re: [PATCH -next] panic: complete the flush of the hard deadlock log messages to the serial port

On Mon, 23 Nov 2020 13:13:59 + Xu Qiang wrote: > when hardlockup_all_cpu_backtrace is on, and there are > a large number of cores in the system, it takes > a long time to output the hard deadlock logs of all cores > to the serial port. When the console_flush_on_panic function > in panic is

linux-kernel@vger.kernel.org waiting to hear from you

Greetings, I write to solicit for your assistance in a benefiting business proposal and I will be pleased to explain my plans and carried it out legally and transparently, so i want to know if i can trust you to discuss details of the business and send you my proposal and my credentials once

Re: [PATCH v6 0/8] IMA: support for measuring kernel integrity critical data

On Mon, 2020-11-23 at 18:18 +0100, Pavel Machek wrote: > > > Basically every other data structure in kernel is "critical" by your > > > definition, and you can't really measure them all; some of them change > > > rather often. Going piecemeal does not really help here. > > > > Agreed, measuring

Re: [PATCH v24 07/12] landlock: Support filesystem access-control

On Sat, Nov 21, 2020 at 11:06 AM Mickaël Salaün wrote: > On 21/11/2020 08:00, Jann Horn wrote: > > On Thu, Nov 12, 2020 at 9:52 PM Mickaël Salaün wrote: > >> Thanks to the Landlock objects and ruleset, it is possible to identify > >> inodes according to a process's domain. To enable an

[PATCH 4/5] ACPI: EC: Untangle error handling in advance_transaction()

From: "Rafael J. Wysocki" Introduce acpi_ec_spurious_interrupt() for recording spurious interrupts and use it for error handling in advance_transaction(), drop the (now redundant) original error handling block from there along with a frew goto statements that are not necessary any more. No

[PATCH 5/5] ACPI: EC: Clean up status flags checks in advance_transaction()

From: "Rafael J. Wysocki" Eliminate comparisons from the status flags checks in advance_transaction() (especially from the one that is only correct, because the value of the flag checked in there is 1) and rearrange the code for more clarity while at it. No intentional functional impact.

[PATCH 0/5] ACPI: EC: Cleanups in advance_transaction()

Hi All, Just a few cleanups related to the advance_transaction() routine in ec.c. Please see patch changelogs for details. Thanks!

Re: [PATCH 2/2] mm,thp,shm: limit gfp mask to no more than specified

On Thu, 2020-11-19 at 10:38 +0100, Michal Hocko wrote: > On Fri 13-11-20 22:40:40, Rik van Riel wrote: > > On Thu, 2020-11-12 at 12:22 +0100, Michal Hocko wrote: > > > [Cc Chris for i915 and Andray] > > > > > > On Thu 05-11-20 14:15:08, Rik van Riel wrote: > > > > Matthew Wilcox pointed out that

[PATCH 3/5] ACPI: EC: Simplify error handling in advance_transaction()

From: "Rafael J. Wysocki" Notice that the value of t in advance_transaction() does not change after its initialization and: - Initialize t upfront (and rearrange the definitions of local variables while at it). - Check it against NULL in a block executed when it is NULL. - Skip error

[PATCH 2/5] ACPI: EC: Rename acpi_ec_is_gpe_raised()

From: "Rafael J. Wysocki" Rename acpi_ec_is_gpe_raised() into acpi_ec_gpe_status_set(), update its callers accordingly and drop the ternary operator (which isn't really necessary in there) from it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/ec.c | 8

[PATCH 1/5] ACPI: EC: Fold acpi_ec_clear_gpe() into its caller

From: "Rafael J. Wysocki" Fold acpi_ec_clear_gpe() which is only used in one place into its caller and clean up comments related to that function while at it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/ec.c | 35 +-- 1

Re: [PATCH v6 8/8] selinux: measure state and hash of the policy using IMA

Hi James, On 2020-11-20 6:05 p.m., James Morris wrote: On Thu, 19 Nov 2020, Tushar Sugandhi wrote: an impact on the security guarantees provided by SELinux. Measuring such in-memory data structures through IMA subsystem provides a secure way for a remote attestation service to know the state

Re: [PATCH net-next v4 2/5] net/lapb: support netdev events

On Mon, 23 Nov 2020 03:17:54 -0800 Xie He wrote: > On Mon, Nov 23, 2020 at 2:38 AM Martin Schiller wrote: > > Well, one could argue that we would have to repair these drivers, but I > > don't think that will get us anywhere. > > Yeah... One problem I see with the Linux project is the lack of >

Re: linux-next: stall warnings and deadlock on Arm64 (was: [PATCH] kfence: Avoid stalling...)

On Fri, Nov 20, 2020 at 03:03:32PM +0100, Marco Elver wrote: > On Fri, Nov 20, 2020 at 10:30AM +, Mark Rutland wrote: > > On Thu, Nov 19, 2020 at 10:53:53PM +, Will Deacon wrote: > > > FWIW, arm64 is known broken wrt lockdep and irq tracing atm. Mark has been > > > looking at that and I

Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers

On Mon, Nov 23, 2020 at 11:20 AM Ben Widawsky wrote: [..] > > -ENXIO is fine with me. I just don't see it as often so I don't > > really know what it is. > > > > Bjorn > > Dan, Bjorn, I did a fairly randomized look at various probe functions and > ENODEV > seems to be more common. My sort of

Re: [locking/rwsem] 10a59003d2: unixbench.score -25.5% regression

On 11/23/20 10:53 AM, kernel test robot wrote: Greeting, FYI, we noticed a -25.5% regression of unixbench.score due to commit: commit: 10a59003d29fbfa855b2ef4f3534fee9bdf4e575 ("[PATCH v2 5/5] locking/rwsem: Remove reader optimistic spinning") url:

Re: [patch 14/19] softirq: Make softirq control and processing RT aware

On Mon, Nov 23 2020 at 14:44, Frederic Weisbecker wrote: > On Fri, Nov 13, 2020 at 03:02:21PM +0100, Thomas Gleixner wrote: >> +/* >> + * Adjust softirq count to SOFTIRQ_OFFSET which makes >> + * in_serving_softirq() become true. >> + */ >> +cnt = SOFTIRQ_OFFSET; >> +

Re: [PATCH v11 05/14] s390/vfio-ap: implement in-use callback for vfio_ap driver

On 11/23/20 12:03 PM, Cornelia Huck wrote: On Sat, 14 Nov 2020 00:47:22 +0100 Halil Pasic wrote: On Fri, 13 Nov 2020 12:14:22 -0500 Tony Krowiak wrote: [..] } +#define MDEV_SHARING_ERR "Userspace may not re-assign queue %02lx.%04lx " \ +"already assigned

Re: [PATCH 4/6] mm: proc: Invalidate TLB after clearing soft-dirty page state

On Fri, Nov 20, 2020 at 07:49:22PM -0700, Yu Zhao wrote: > On Fri, Nov 20, 2020 at 01:22:53PM -0700, Yu Zhao wrote: > > On Fri, Nov 20, 2020 at 02:35:55PM +, Will Deacon wrote: > > > Since commit 0758cd830494 ("asm-generic/tlb: avoid potential double > > > flush"), > > > TLB invalidation is

Re: [PATCH v12 3/4] selinux: teach SELinux about anonymous inodes

On Sun, Nov 22, 2020 at 3:14 PM Paul Moore wrote: > > On Wed, Nov 18, 2020 at 5:39 PM Lokesh Gidra wrote: > > I have created a cuttlefish build and have tested with the attached > > userfaultfd program: > > Thanks, that's a good place to start, a few comments: > > - While we support Android as a

Re: [PATCHv8 0/8] System Cache support for GPU and required SMMU support

On Mon, Nov 23, 2020 at 9:01 AM Sai Prakash Ranjan wrote: > > On 2020-11-23 20:51, Will Deacon wrote: > > On Tue, Nov 17, 2020 at 08:00:39PM +0530, Sai Prakash Ranjan wrote: > >> Some hardware variants contain a system cache or the last level > >> cache(llc). This cache is typically a large block

Re: [PATCH] zlib: export S390 symbols for zlib modules

On Mon, 2020-11-23 at 11:17 -0800, Randy Dunlap wrote: > Fix build errors when ZLIB_INFLATE=m and ZLIB_DEFLATE=m > and ZLIB_DFLTCC=y by exporting the 2 needed symbols in > dfltcc_inflate.c. > > Fixes these build errors: > > ERROR: modpost: "dfltcc_inflate" [lib/zlib_inflate/zlib_inflate.ko] >

Re: [PATCH v2] btrfs: return EAGAIN when receiving a pending signal in the defrag loops

On Wed, Nov 18, 2020 at 12:02:36PM +0800, xiakaixu1...@gmail.com wrote: > From: Kaixu Xia > > The variable ret is overwritten by the following variable defrag_count. > Actually the code should return EAGAIN when receiving a pending signal > in the defrag loops. This lacks explanation why is

Re: [RFC PATCH 4/9] cxl/mem: Map memory device registers

On 20-11-16 18:23:21, Bjorn Helgaas wrote: > On Mon, Nov 16, 2020 at 03:19:41PM -0800, Dan Williams wrote: > > On Fri, Nov 13, 2020 at 5:12 PM Ben Widawsky wrote: > > > On 20-11-13 12:17:32, Bjorn Helgaas wrote: > > > > On Tue, Nov 10, 2020 at 09:43:51PM -0800, Ben Widawsky wrote: > > > > > >

Re: [PATCH v6 1/2] Add UFFD_USER_MODE_ONLY

On Fri, Nov 20, 2020 at 3:33 PM Andrew Morton wrote: > > On Thu, 19 Nov 2020 19:04:10 -0800 Lokesh Gidra > wrote: > > > userfaultfd handles page faults from both user and kernel code. > > Add a new UFFD_USER_MODE_ONLY flag for userfaultfd(2) that makes > > the resulting userfaultfd object

[PATCH] zlib: export S390 symbols for zlib modules

Fix build errors when ZLIB_INFLATE=m and ZLIB_DEFLATE=m and ZLIB_DFLTCC=y by exporting the 2 needed symbols in dfltcc_inflate.c. Fixes these build errors: ERROR: modpost: "dfltcc_inflate" [lib/zlib_inflate/zlib_inflate.ko] undefined! ERROR: modpost: "dfltcc_can_inflate"

Re: [PATCH mm v3 17/19] kasan: clean up metadata allocation and usage

On Mon, Nov 23, 2020 at 7:54 PM Andrey Konovalov wrote: > > > > @@ -168,6 +173,9 @@ void quarantine_put(struct kmem_cache *cache, void > > > *object) > > > struct qlist_head temp = QLIST_INIT; > > > struct kasan_free_meta *meta = kasan_get_free_meta(cache, object); > > > > > > +

[PATCH net-next v1 2/2] lan743x: replace polling loop by wait_event_timeout()

From: Sven Van Asbroeck The driver's ISR sends a 'software interrupt' event to the probe() thread using the following method: - probe(): write 0 to flag, enable s/w interrupt - probe(): poll on flag, relax using usleep_range() - ISR: write 1 to flag Replace with wake_up() /

[PATCH net-next v1 1/2] lan743x: clean up software_isr function

From: Sven Van Asbroeck For no apparent reason, this function reads the INT_STS register, and checks if the software interrupt bit is set. These things have already been carried out by this function's only caller. Clean up by removing the redundant code. Tested-by: Sven Van Asbroeck # lan7430

Re: [PATCH v2] kcsan: Avoid scheduler recursion by using non-instrumented preempt_{disable,enable}()

On Mon, 23 Nov 2020 at 17:08, Peter Zijlstra wrote: > On Mon, Nov 23, 2020 at 04:57:46PM +0100, Marco Elver wrote: > > Let me know what you prefer. > > > > > @@ -288,27 +288,19 @@ static u32 kcsan_prandom_u32_max(u32 ep_ro) > > u32 res; > > > > /* > > + * Avoid recursion with

Re: [PATCH v6 5/5] regulator: add SCMI driver

On Mon, Nov 23, 2020 at 06:49:56PM +, Cristian Marussi wrote: > On Mon, Nov 23, 2020 at 05:49:41PM +, Mark Brown wrote: > > On Thu, Nov 19, 2020 at 07:10:51PM +, Cristian Marussi wrote: > > > + rinfo->num_doms = num_doms; > > > + /* > > Several places like this with missing blank

[no subject]

ATENÇÃO; Sua caixa de correio excedeu o limite de armazenamento, que é de 5 GB como definido pelo administrador, que está atualmente em execução no 10.9GB, você pode não ser capaz de enviar ou receber novas mensagens até que você re-validar a sua caixa de correio. Para revalidar sua caixa de

Re: [PATCH v4 1/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring driver

On Mon, Nov 23, 2020 at 05:18:32AM -0800, Guenter Roeck wrote: > On Sun, Nov 22, 2020 at 11:45:31PM -0800, rentao.b...@gmail.com wrote: > > From: Tao Ren > > > > Add hardware monitoring driver for the Maxim MAX127 chip. > > > > MAX127 min/max range handling code is inspired by the max197

Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash

On 11/23/20 10:54 AM, Yonghong Song wrote: On 11/23/20 10:46 AM, KP Singh wrote: On Mon, Nov 23, 2020 at 7:36 PM Yonghong Song wrote: On 11/23/20 10:27 AM, KP Singh wrote: [...] Even if a custom policy has been loaded, potentially additional measurements unrelated to this test

Re: [PATCH v3 1/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring driver

On Mon, Nov 23, 2020 at 05:16:41AM -0800, Guenter Roeck wrote: > On Sun, Nov 22, 2020 at 11:54:49PM -0800, Tao Ren wrote: > > On Sun, Nov 22, 2020 at 10:33:42AM -0800, Guenter Roeck wrote: > > > On Thu, Nov 19, 2020 at 09:53:23AM -0800, rentao.b...@gmail.com wrote: > > > > From: Tao Ren > > > >

Re: [PATCH v2 3/6] dt-bindings: ata: tegra: Convert binding documentation to YAML

On 11/20/20 12:17 PM, Rob Herring wrote: On Fri, Nov 13, 2020 at 1:36 PM Sowjanya Komatineni wrote: This patch converts text based dt-binding document to YAML based dt-binding document. Signed-off-by: Sowjanya Komatineni --- .../devicetree/bindings/ata/nvidia,tegra-ahci.yaml | 137

[PATCH v5 1/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring driver

From: Tao Ren Add hardware monitoring driver for the Maxim MAX127 chip. MAX127 min/max range handling code is inspired by the max197 driver. Signed-off-by: Tao Ren --- Changes in v5: - fix i2c_transfer() error handling. Changes in v4: - delete unnecessary "#include" lines. -

Re: [PATCH 5.4 044/158] compiler.h: fix barrier_data() on clang

On Mon, Nov 23, 2020 at 10:50 AM Greg Kroah-Hartman wrote: > > On Mon, Nov 23, 2020 at 10:31:10AM -0800, Nick Desaulniers wrote: > > Doesn't this depend on a v2 of > > https://lore.kernel.org/lkml/fe040988-c076-8dec-8268-3fbaa8b39...@infradead.org/ > > ? Oh, looks like v1 got picked up: > >

[PATCH v5 0/2] hwmon: (max127) Add Maxim MAX127 hardware monitoring

From: Tao Ren The patch series adds hardware monitoring driver for the Maxim MAX127 chip. Patch #1 adds the max127 hardware monitoring driver, and patch #2 adds documentation for the driver. Tao Ren (2): hwmon: (max127) Add Maxim MAX127 hardware monitoring driver docs: hwmon: Document

[PATCH v5 2/2] docs: hwmon: Document max127 driver

From: Tao Ren Add documentation for the max127 hardware monitoring driver. Signed-off-by: Tao Ren Reviewed-by: Guenter Roeck --- Changes in v5: - None. Changes in v4: - None. Changes in v3: - no code change. xdp maintainers were removed from to/cc list. Changes in v2: - add

Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash

On 11/23/20 10:46 AM, KP Singh wrote: On Mon, Nov 23, 2020 at 7:36 PM Yonghong Song wrote: On 11/23/20 10:27 AM, KP Singh wrote: [...] Even if a custom policy has been loaded, potentially additional measurements unrelated to this test would be included the measurement list. One way

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Mon, Nov 23, 2020 at 4:58 PM James Bottomley wrote: > > Well, I used git. It says that as of today in Linus' tree we have 889 > patches related to fall throughs and the first series went in in > october 2017 ... ignoring a couple of outliers back to February. I can see ~10k insertions over

Re: [PATCH mm v3 17/19] kasan: clean up metadata allocation and usage

On Tue, Nov 17, 2020 at 2:12 PM Dmitry Vyukov wrote: > > > void __kasan_poison_slab(struct page *page) > > { > > @@ -272,11 +305,9 @@ void * __must_check __kasan_init_slab_obj(struct > > kmem_cache *cache, > > struct kasan_alloc_meta *alloc_meta; > > > > if

TREAT AND REPLY URGENTLY.

FROM MR. ABDUL KARIM AUDIT & ACCOUNT MANAGER BANK OF AFRICA (B.O.A) OUAGADOUGOU BURKINA FASO WEST AFRICA. Greeting My Dear Friend, With due respect, I have decided to contact you on a business transaction that will be beneficial to both of us. At the bank last account and auditing evaluation, my

Re: [git pull] habanalabs fixes for 5.10-rc6

On Mon, Nov 23, 2020 at 08:14:29PM +0200, Oded Gabbay wrote: > Hello Greg, > > This pull request contains a single small fix for 5.10-rc6. Details are in > the tag. > > Thanks, > Oded > > The following changes since commit ef3f0caf243075ac255b69054cbf48b65eadb0d4: > > Merge tag

Re: [PATCH v6 4/5] dt-bindings: arm: add support for SCMI Regulators

On Mon, Nov 23, 2020 at 05:30:08PM +, Mark Brown wrote: > On Thu, Nov 19, 2020 at 07:10:50PM +, Cristian Marussi wrote: > > > +This binding uses the common regulator binding[6] but, due to SCMI > > abstractions, > > +supports only a subset of its properties as specified below amongst >

Re: [PATCH v6 5/5] regulator: add SCMI driver

Hi Mark On Mon, Nov 23, 2020 at 05:49:41PM +, Mark Brown wrote: > On Thu, Nov 19, 2020 at 07:10:51PM +, Cristian Marussi wrote: > > > + ret = handle->voltage_ops->config_get(handle, sreg->id, > > + ); > > + if (ret) { > > +

Re: [PATCH 5.4 044/158] compiler.h: fix barrier_data() on clang

On Mon, Nov 23, 2020 at 10:31:10AM -0800, Nick Desaulniers wrote: > Doesn't this depend on a v2 of > https://lore.kernel.org/lkml/fe040988-c076-8dec-8268-3fbaa8b39...@infradead.org/ > ? Oh, looks like v1 got picked up: >

[PATCH] habanalabs/gaudi: print ECC type field

We have the ECC type field from the firmware but the driver didn't print it, so we need to add that field to the ECC print message. Signed-off-by: Oded Gabbay --- drivers/misc/habanalabs/gaudi/gaudi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [f2fs-dev] [PATCH 2/2] f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE

On Mon, Nov 23, 2020 at 12:17:51PM +0900, Daeho Jeong wrote: > From: Daeho Jeong > > Added two ioctl to decompress/compress explicitly the compression > enabled file in "compress_mode=user-based" mount option. > > Using these two ioctls, the users can make a control of compression > and

Re: [f2fs-dev] [PATCH 1/2] f2fs: add compress_mode mount option

On Mon, Nov 23, 2020 at 12:17:50PM +0900, Daeho Jeong wrote: > From: Daeho Jeong > > We will add a new "compress_mode" mount option to control file > compression mode. This supports "fs-based" and "user-based". > In "fs-based" mode (default), f2fs does automatic compression on > the compression

Re: [PATCH bpf-next v2 3/3] bpf: Update LSM selftests for bpf_ima_inode_hash

On Mon, Nov 23, 2020 at 7:36 PM Yonghong Song wrote: > > > > On 11/23/20 10:27 AM, KP Singh wrote: > > [...] > > > > Even if a custom policy has been loaded, potentially additional > measurements unrelated to this test would be included the measurement > list. One way of

Re: [PATCH 1/5] soundwire: SDCA: add helper macro to access controls

On Wed, Nov 04, 2020 at 01:22:22AM +0800, Bard Liao wrote: > From: Pierre-Louis Bossart > > The upcoming SDCA (SoundWire Device Class Audio) specification defines > a hierarchical encoding to interface with Class-defined capabilities. Vinod, any thoughts on this? signature.asc Description:

<    2   3   4   5   6   7   8   9   10   11   >