Hi Vincent,
kernel test robot noticed the following build errors:
[auto build test ERROR on 4f1991a92cfe89096b2d1f5583a2e093bdd55c37]
url:
https://github.com/intel-lab-lkp/linux/commits/Vincent-Donnefort/ring-buffer-Zero-ring-buffer-sub-buffers/20240123-191131
base:
Hi Vincent,
kernel test robot noticed the following build errors:
[auto build test ERROR on 4f1991a92cfe89096b2d1f5583a2e093bdd55c37]
url:
https://github.com/intel-lab-lkp/linux/commits/Vincent-Donnefort/ring-buffer-Zero-ring-buffer-sub-buffers/20240123-191131
base:
On 1/25/2024 3:03 PM, Sohil Mehta wrote:
> On 1/25/2024 10:48 AM, Avadhut Naik wrote:
>> Currently, the microcode field (Microcode Revision) of struct mce is not
>> exported to userspace through the mce_record tracepoint.
>>
>> Export it through the tracepoint as it may provide useful
On Wed, 24 Jan 2024 12:03:45 -0800 Vishal Verma
wrote:
> This series adds sysfs ABI to control memmap_on_memory behavior for DAX
> devices.
Thanks. I'll add this to mm-unstable for some additional testing, but
I do think we should have the evidence of additional review on this
series's four
>Great, thank you for testing! I'll send a proper patch. How would you
>like to be credited with reporting? Just as 'Ubisectech Sirius
>' ?
Hello.
Please use 'Ubisectech Sirius' to credit the
report. Thanks.
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Wed, 24 Jan 2024 22:32:55 +0300 you wrote:
> SOCK_SEQPACKET is supported for virtio transport, so do not interpret
> such type of socket as unknown.
>
> Signed-off-by: Arseniy Krasnov
> ---
>
From: Masami Hiramatsu (Google)
Fix register_snapshot_trigger() to return error code if it failed to
allocate a snapshot instead of 0 (success). Unless that, it will register
snapshot trigger without an error.
Fixes: 0bbe7f719985 ("tracing: Fix the race between registering 'snapshot'
event
Hi Vincent,
On Thu, 25 Jan 2024 14:53:40 +
Vincent Donnefort wrote:
> > > @@ -1470,12 +1483,20 @@ register_snapshot_trigger(char *glob,
> > > struct event_trigger_data *data,
> > > struct trace_event_file *file)
> > > {
> > > - if
On Fri, 2024-01-26 at 09:34 +1100, NeilBrown wrote:
> On Fri, 26 Jan 2024, Chuck Lever wrote:
> > On Thu, Jan 25, 2024 at 05:42:41AM -0500, Jeff Layton wrote:
> > > Long ago, file locks used to hang off of a singly-linked list in struct
> > > inode. Because of this, when leases were added, they
On 1/25/24 22:56, Luca Weiss wrote:
From: Vladimir Lypak
Add the GPU node for the Adreno 506 found on this family of SoCs. The
clock speeds are a bit different per SoC variant, SDM450 maxes out at
600MHz while MSM8953 (= SDM625) goes up to 650MHz and SDM632 goes up to
725MHz.
To achieve
On 1/25/24 23:24, Dmitry Baryshkov wrote:
On 25/01/2024 23:56, Luca Weiss wrote:
From: Vladimir Lypak
Add the IOMMU used for the GPU on MSM8953.
Signed-off-by: Vladimir Lypak
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 31 +++
1 file changed, 31
On Wed, Jan 24, 2024 at 10:32:55PM +0300, Arseniy Krasnov wrote:
> SOCK_SEQPACKET is supported for virtio transport, so do not interpret
> such type of socket as unknown.
>
> Signed-off-by: Arseniy Krasnov
Acked-by: Michael S. Tsirkin
> ---
> tools/testing/vsock/vsock_diag_test.c | 2 ++
>
On Fri, 26 Jan 2024, Chuck Lever wrote:
> On Thu, Jan 25, 2024 at 05:42:41AM -0500, Jeff Layton wrote:
> > Long ago, file locks used to hang off of a singly-linked list in struct
> > inode. Because of this, when leases were added, they were added to the
> > same list and so they had to be tracked
The initialization of trace_seq buffers is done elsewhere and therefore
__trace_seq_init should yield a warning if it has to actually initialize
the buffer.
Suggested-by: Steven Rostedt
Signed-off-by: Ricardo B. Marliere
---
kernel/trace/trace_seq.c | 2 +-
1 file changed, 1 insertion(+), 1
Currently, trace_seq_init may be called many times with the intent of
resetting the buffer. Add a function trace_seq_reset that does that and
replace the relevant occurrences to use it instead.
Suggested-by: Steven Rostedt
Signed-off-by: Ricardo B. Marliere
---
include/linux/trace_seq.h|
In order to extend trace_seq into being dynamic, the struct trace_seq
will no longer be valid if simply set to zero. Call trace_seq_init() for
all trace_seq when they are first created.
Suggested-by: Steven Rostedt
Signed-off-by: Ricardo B. Marliere
---
kernel/trace/trace.c | 14 ++
This series is a prerequisite for a later effort of making trace_seq more
flexible about its buffer size. To achieve that, initializing and resetting
the buffers need to be differentiated.
Changes in v3:
- Reordered commits so it doesn't produce a failing build in-between.
- Improved changelogs.
On 25/01/2024 23:56, Luca Weiss wrote:
From: Vladimir Lypak
Add the GPU node for the Adreno 506 found on this family of SoCs. The
clock speeds are a bit different per SoC variant, SDM450 maxes out at
600MHz while MSM8953 (= SDM625) goes up to 650MHz and SDM632 goes up to
725MHz.
To achieve
On 25/01/2024 23:56, Luca Weiss wrote:
From: Vladimir Lypak
Add the IOMMU used for the GPU on MSM8953.
Signed-off-by: Vladimir Lypak
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git
On Thu, 25 Jan 2024 16:18:37 -0500
Mathieu Desnoyers wrote:
> >
> > This is how you are able to avoid the "before/after" logic I have, as
> > the race is automatically detected. The least significant bits of the
> > timestamp is ignored for the event delta calculation.
>
> Not quite, as I
On Thu, 25 Jan 2024 at 23:36, Luca Weiss wrote:
>
> From: Vladimir Lypak
>
> Add new entries in the gcc driver for some more resets found on MSM8953.
>
> Signed-off-by: Vladimir Lypak
> [luca: expand commit message, move entry, add more entries]
> Signed-off-by: Luca Weiss
> ---
>
On Thu, 25 Jan 2024 at 23:36, Luca Weiss wrote:
>
> From: Vladimir Lypak
>
> With this reset we can avoid situations like IRQ storms from DSI host
> before it even started probing (because boot-loader left DSI IRQs on).
>
> Signed-off-by: Vladimir Lypak
> Reviewed-by: Konrad Dybcio
>
Add the GPU IOMMU and GPU nodes to the msm8953 dtsi so GPU can work.
First of all, functionally this series looks fine, tested on
sdm632-fairphone-fp3.
Secondly and the reason this is marked RFC for now is basically just dt
bindings check fail, and some questions regarding IOMMU compatible.
From: Vladimir Lypak
Add the IOMMU used for the GPU on MSM8953.
Signed-off-by: Vladimir Lypak
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
From: Vladimir Lypak
Add the GPU node for the Adreno 506 found on this family of SoCs. The
clock speeds are a bit different per SoC variant, SDM450 maxes out at
600MHz while MSM8953 (= SDM625) goes up to 650MHz and SDM632 goes up to
725MHz.
To achieve this, create a new sdm450.dtsi to hold the
Hi Steve,
On 25 Jan 15:44, Steven Rostedt wrote:
> On Thu, 25 Jan 2024 17:16:21 -0300
> "Ricardo B. Marliere" wrote:
>
> > Now that trace_seq_reset have been created, correct the places where the
> > buffers need to be initialized.
>
> This patch would need to come first. You don't ever want
It appears to put an outdated coversheet onto this series.
Below is the updated coversheet that reflects changes made:
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or
From: Vladimir Lypak
With this reset we can avoid situations like IRQ storms from DSI host
before it even started probing (because boot-loader left DSI IRQs on).
Signed-off-by: Vladimir Lypak
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 2
From: Vladimir Lypak
Add new entries in the gcc driver for some more resets found on MSM8953.
Signed-off-by: Vladimir Lypak
[luca: expand commit message, move entry, add more entries]
Signed-off-by: Luca Weiss
---
drivers/clk/qcom/gcc-msm8953.c | 4
1 file changed, 4 insertions(+)
diff
From: Vladimir Lypak
Add new defines for some more BCRs found on MSM8953.
Signed-off-by: Vladimir Lypak
[luca: expand commit message, add more resets]
Acked-by: Krzysztof Kozlowski
Signed-off-by: Luca Weiss
---
include/dt-bindings/clock/qcom,gcc-msm8953.h | 4
1 file changed, 4
Add the MDSS_BCR reset that is found in the GCC of MSM8953 so we can
make sure the MDSS gets properly reset before Linux starts using it.
Also add some others that have been found in the LK sources.
Signed-off-by: Luca Weiss
---
Changes in v2:
- Add more resets from LK sources
- Pick up tags
-
On Mittwoch, 24. Jänner 2024 13:10:53 CET Konrad Dybcio wrote:
> On 1/23/24 22:03, Luca Weiss wrote:
> > From: Vladimir Lypak
> >
> > Add an entry in the gcc driver for the MDSS_BCR reset found on MSM8953.
> >
> > Signed-off-by: Vladimir Lypak
> > [luca: expand commit message, move entry]
> >
On 2024-01-20 08:47, Steven Rostedt wrote:
On Fri, 19 Jan 2024 20:49:36 -0500
Mathieu Desnoyers wrote:
Let's say we have the following ktime_get() values (monotonic timestamp value)
for
a sequence of events:
Timestamp (Hex)Encoding in the trace
Le 18/04/2022 à 06:38, Shivaprasad G Bhat a écrit :
> papr_scm and ndtest share common PDSM payload structs like
> nd_papr_pdsm_health. Presently these structs are duplicated across
> papr_pdsm.h and ndtest.h header files. Since 'ndtest' is essentially
> arch independent and can run on platforms
On 1/25/2024 10:48 AM, Avadhut Naik wrote:
> Currently, the microcode field (Microcode Revision) of struct mce is not
> exported to userspace through the mce_record tracepoint.
>
> Export it through the tracepoint as it may provide useful information for
> debug and analysis.
>
> Signed-off-by:
On 1/25/2024 10:48 AM, Avadhut Naik wrote:
> Machine Check Error information from struct mce is exported to userspace
> through the mce_record tracepoint.
>
> Currently, however, the PPIN (Protected Processor Inventory Number) field
> of struct mce is not exported through the tracepoint.
>
>
On Thu, 25 Jan 2024 17:16:21 -0300
"Ricardo B. Marliere" wrote:
> Now that trace_seq_reset have been created, correct the places where the
> buffers need to be initialized.
This patch would need to come first. You don't ever want to intentionally
create a broken kernel.
Also, the change log
Hi,
On 1/25/2024 1:19 PM, Luck, Tony wrote:
>>> The first patch adds PPIN (Protected Processor Inventory Number) field to
>>> the tracepoint.
>>>
>>> The second patch adds the microcode field (Microcode Revision) to the
>>> tracepoint.
>>
>> This is a lot of static information to add to *every*
The initialization of trace_seq buffers are done elsewhere and therefore
__trace_seq_init should yield a warning if it has to actually initialize
the buffer.
Suggested-by: Steven Rostedt
Signed-off-by: Ricardo B. Marliere
---
kernel/trace/trace_seq.c | 2 +-
1 file changed, 1 insertion(+), 1
Now that trace_seq_reset have been created, correct the places where the
buffers need to be initialized.
Suggested-by: Steven Rostedt
Signed-off-by: Ricardo B. Marliere
---
kernel/trace/trace.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/trace/trace.c
Currently, trace_seq_init may be called many times with the intent of
resetting the buffer. Add a function trace_seq_reset that does that and
replace the relevant occurrences to use it instead.
Suggested-by: Steven Rostedt
Signed-off-by: Ricardo B. Marliere
---
include/linux/trace_seq.h|
This series is a prerequisite for a later effort of making trace_seq more
flexible about its buffer size. To achieve that, initializing and resetting
the buffers need to be differentiated.
Ricardo B. Marliere (3):
tracing: add trace_seq_reset function
tracing: initialize trace_seq buffers
> > The first patch adds PPIN (Protected Processor Inventory Number) field to
> > the tracepoint.
> >
> > The second patch adds the microcode field (Microcode Revision) to the
> > tracepoint.
>
> This is a lot of static information to add to *every* MCE.
8 bytes for PPIN, 4 more for microcode.
On Thu, Jan 25, 2024 at 12:48:55PM -0600, Avadhut Naik wrote:
> This patchset updates the mce_record tracepoint so that the recently added
> fields of struct mce are exported through it to userspace.
>
> The first patch adds PPIN (Protected Processor Inventory Number) field to
> the tracepoint.
>
Hi Arnaud,
On Thu, Jan 18, 2024 at 11:04:30AM +0100, Arnaud Pouliquen wrote:
> From: Arnaud Pouliquen
>
> Add a remoteproc TEE (Trusted Execution Environment) device
Device or driver? Seems to be the latter...
> that will be probed by the TEE bus. If the associated Trusted
> application is
On Wed, Jan 24, 2024 at 09:09:08AM -0500, Steven Rostedt wrote:
> I don't think that's a worry anymore. The offsets can change based on
> kernel config. PowerTop needed to have the library ported to it because
> it use to hardcode the offsets but then it broke when running the 32bit
> version on a
Currently, the microcode field (Microcode Revision) of struct mce is not
exported to userspace through the mce_record tracepoint.
Export it through the tracepoint as it may provide useful information for
debug and analysis.
Signed-off-by: Avadhut Naik
---
include/trace/events/mce.h | 7 +--
Machine Check Error information from struct mce is exported to userspace
through the mce_record tracepoint.
Currently, however, the PPIN (Protected Processor Inventory Number) field
of struct mce is not exported through the tracepoint.
Export PPIN through the tracepoint as it may provide useful
This patchset updates the mce_record tracepoint so that the recently added
fields of struct mce are exported through it to userspace.
The first patch adds PPIN (Protected Processor Inventory Number) field to
the tracepoint.
The second patch adds the microcode field (Microcode Revision) to the
On Thu, Jan 25, 2024 at 09:59:03AM +0900, Masami Hiramatsu wrote:
> On Tue, 23 Jan 2024 22:08:41 +
> Beau Belgrave wrote:
>
> > The current code for finding and deleting events assumes that there will
> > never be cases when user_events are registered with the same name, but
> > different
On Thu, 25 Jan 2024 16:42:21 +
Alexandru Elisei wrote:
> include/trace/events/cma.h| 59 ++
> include/trace/events/mmflags.h| 5 +-
I know others like being Cc'd on every patch in a series, but I'm not about
to trudge through 35 patches to review trace
On Thu, 2024-01-25 at 09:57 -0500, Chuck Lever wrote:
> On Thu, Jan 25, 2024 at 05:42:41AM -0500, Jeff Layton wrote:
> > Long ago, file locks used to hang off of a singly-linked list in struct
> > inode. Because of this, when leases were added, they were added to the
> > same list and so they had
Faking a tag storage region for FVP is useful for testing.
Signed-off-by: Alexandru Elisei
---
Changes since rfc v2:
* New patch, not intended to be merged.
arch/arm64/boot/dts/arm/fvp-base-revc.dts | 42 +--
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git
Everything is in place, enable tag storage management.
Signed-off-by: Alexandru Elisei
---
arch/arm64/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 088e30fc6d12..95c153705a2c 100644
--- a/arch/arm64/Kconfig
+++
Tag storage pages mapped by the host in a VM with MTE enabled are migrated
when they are first accessed by the guest. This introduces latency spikes
for memory accesses made by the guest.
Tag storage pages can be mapped in the guest memory when the VM_MTE VMA
flag is not set. Introduce a new VMA
KVM allows MTE enabled VMs to be created when the backing VMA does not have
MTE enabled. As a result, pages allocated for the virtual machine's memory
won't have tag storage reserved. Try to reserve tag storage the first time
the page is accessed by the guest. This is similar to how pages mapped
copy_user_highpage() will do memory allocation if there are saved tags for
the destination page, and the page is missing tag storage.
After commit a349d72fd9ef ("mm/pgtable: add rcu_read_lock() and
rcu_read_unlock()s"), collapse_huge_page() calls
__collapse_huge_page_copy() -> .. ->
A page can end up mapped in a MTE enabled VMA without the corresponding tag
storage block reserved. Tag accesses made by ptrace in this case can lead
to the wrong tags being read or memory corruption for the process that is
using the tag storage memory as data.
Reserve tag storage by treating
There are several situations where copy_highpage() can end up copying
tags to a page which doesn't have its tag storage reserved.
One situation involves migration racing with mprotect(PROT_MTE): VMA is
initially untagged, migration starts and destination page is allocated
as untagged,
Linux restores tags when a page is swapped in and there are tags associated
with the swap entry which the new page will replace. The saved tags are
restored even if the page will not be mapped as tagged, to protect against
cases where the page is shared between different VMAs, and is tagged in
Tag stoarge pages cannot be tagged. When such a page is mapped in a
MTE-enabled VMA, migrate it out directly and don't try to reserve tag
storage for it.
Signed-off-by: Alexandru Elisei
---
arch/arm64/include/asm/mte_tag_storage.h | 1 +
arch/arm64/kernel/mte_tag_storage.c | 15
There are three situations in which a page that is to be mapped as
tagged doesn't have the corresponding tag storage reserved:
* reserve_tag_storage() failed.
* The allocation didn't specifiy __GFP_TAGGED (this can happen during
migration, for example).
* The page was mapped in a non-MTE
On arm64, when a page is mapped as tagged, its tags are zeroed for two
reasons:
* To prevent leakage of tags to userspace.
* To allow userspace to access the contents of the page with having to set
the tags explicitely (bits 59:56 of an userspace pointer are zero, which
correspond to tag
Make sure the contents of the tag storage block is not corrupted by
performing:
1. A tag dcache inval when the associated tagged pages are freed, to avoid
dirty tag cache lines being evicted and corrupting the tag storage
block when it's being used to store data.
2. A data cache inval when
Reserve tag storage for a page that is being allocated as tagged. This
is a best effort approach, and failing to reserve tag storage is
allowed.
When all the associated tagged pages have been freed, return the tag
storage pages back to the page allocator, where they can be used again for
data
Before enabling MTE tag storage management, make sure that the CMA areas
have been successfully activated. If a CMA area fails activation, the pages
are kept as reserved. Reserved pages are never used by the page allocator.
If this happens, the kernel would have to manage tag storage only for
To be able to reserve the tag storage associated with a tagged page
requires that the tag storage can be migrated, if it's in use for data.
The kernel allocates pages in non-preemptible contexts, which makes
migration impossible. The only user of tagged pages in the kernel is HW
KASAN, so don't
Add the MTE tag storage pages to CMA, which allows the page allocator to
manage them like regular pages.
The CMA migratype lends the tag storage pages some very desirable
properties:
* They cannot be longterm pinned, meaning they should always be migratable.
* The pages can be allocated
Allow the kernel to get the base address, size, block size and associated
memory node for tag storage from the device tree blob.
A tag storage region represents the smallest contiguous memory region that
holds all the tags for the associated contiguous memory region which can be
tagged. For
__GFP_ZEROTAGS is used to instruct the page allocator to zero the tags at
the same time as the physical frame is zeroed. The name can be slightly
misleading, because it doesn't mean that the code will zero the tags
unconditionally, but that the tags will be zeroed if and only if the
physical frame
The tag save/restore/copy functions could be more explicit about from where
the tags are coming from and where they are being copied to. Renaming the
functions to make it easier to understand what they are doing:
- Rename the mte_clear_page_tags() 'addr' parameter to 'page_addr', to
match the
According to ARM DDI 0487J.a, page D10-5976, a memory location which
doesn't have the Normal memory attribute is considered Untagged, and
accesses are Tag Unchecked. Tag reads from an Untagged address return
0b, and writes are ignored.
Linux uses VM_PFNMAP VMAs represent device memory, and
Add the function of_flat_read_u32() to return the value of a property as
an u32.
Signed-off-by: Alexandru Elisei
---
Changes since rfc v2:
* New patch, suggested by Rob Herring.
drivers/of/fdt.c | 21 +
include/linux/of_fdt.h | 2 ++
2 files changed, 23
Alongside the base address, arm64 will also need to know the size of a
tag storage region. Teach of_flat_dt_translate_address() to parse and
return the size.
Signed-off-by: Alexandru Elisei
---
Changes since rfc v2:
* New patch, suggested by Rob Herring.
arch/sh/kernel/cpu/sh2/probe.c | 2
Introduce a mechanism that allows an architecture to trigger a page fault,
and add the infrastructure to handle that fault accordingly. To use make
use of this, an arch is expected to mark the table entry as PAGE_NONE (which
will cause a fault next time it is accessed) and to implement an
arm64 uses arch_swap_restore() to restore saved tags before the page is
swapped in and it's called in atomic context (with the ptl lock held).
Introduce arch_swap_prepare_to_restore() that will allow an architecture to
perform extra work during swap in and outside of a critical section.
This will
arm64 uses VM_HIGH_ARCH_0 and VM_HIGH_ARCH_1 for enabling MTE for a VMA.
When VM_HIGH_ARCH_0, which arm64 renames to VM_MTE, is set for a VMA, and
the gfp flag __GFP_ZERO is present, the __GFP_ZEROTAGS gfp flag also gets
set in vma_alloc_zeroed_movable_folio().
Expand this to be more generic by
If the pages to be allocated are free, take them directly off the buddy
allocator, instead of going through alloc_contig_range() and avoiding
costly calls to lru_cache_disable().
Only allocations of the same size as the CMA region order are considered,
to avoid taking the zone spinlock for too
Memory is added to CMA with cma_declare_contiguous_nid() and
cma_init_reserved_mem(). This memory is then put on the MIGRATE_CMA list in
cma_init_reserved_areas(), where the page allocator can make use of it.
If a device manages multiple CMA areas, and there's an error when one of
the areas is
Today, cma_alloc() is used to allocate a contiguous memory region. The
function allows the caller to specify the number of pages to allocate, but
not the starting address. cma_alloc() will walk over the entire CMA region
trying to allocate the first available range of the specified size.
Similar to the two events that relate to CMA allocations, add the
CMA_RELEASE_SUCCESS and CMA_RELEASE_FAIL events that count when CMA pages
are freed.
Signed-off-by: Alexandru Elisei
---
Changes since rfc v2:
* New patch.
include/linux/vm_event_item.h | 2 ++
mm/cma.c |
The CMA_ALLOC_SUCCESS, respectively CMA_ALLOC_FAIL, are increased by one
after each cma_alloc() function call. This is done even though cma_alloc()
can allocate an arbitrary number of CMA pages. When looking at
/proc/vmstat, the number of successful (or failed) cma_alloc() calls
doesn't tell much
cma->name is displayed in several CMA messages. When the name is generated
by the CMA code, don't append a newline to avoid breaking the text across
two lines.
Signed-off-by: Alexandru Elisei
---
Changes since rfc v2:
* New patch. This is a fix, and can be merged independently of the other
The patch f945116e4e19 ("mm: page_alloc: remove stale CMA guard code")
removed the CMA filter when allocating from the MIGRATE_MOVABLE pcp list
because CMA is always allowed when __GFP_MOVABLE is set.
With the introduction of the arch_alloc_cma() function, the above is not
true anymore, so bring
As an architecture might have specific requirements around the allocation
of CMA pages, add an arch hook that can disable allocations from
MIGRATE_CMA, if the allocation was otherwise allowed.
This will be used by arm64, which will put tag storage pages on the
MIGRATE_CMA list, and tag storage
The arm64 MTE code uses the PG_arch_2 page flag, which it renames to
PG_mte_tagged, to track if a page has been mapped with tagging enabled.
That flag is cleared by free_pages_prepare() by doing:
page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
When tag storage management is added, tag storage
Extend the usefulness of arch_alloc_page() by adding the gfp_flags
parameter.
Signed-off-by: Alexandru Elisei
---
Changes since rfc v2:
* New patch.
arch/s390/include/asm/page.h | 2 +-
arch/s390/mm/page-states.c | 2 +-
include/linux/gfp.h | 2 +-
mm/page_alloc.c | 2
The series is based on v6.8-rc1 and can be cloned with:
$ git clone https://gitlab.arm.com/linux-arm/linux-ae.git \
-b arm-mte-dynamic-carveout-rfc-v3
Changelog
=
The changes from the previous version [1] are extensive, so I'll list them
first. Only the major changes are below,
On 1/21/24 11:09, Luca Weiss wrote:
This device has a vibrator attached to the CAMSS_GP0_CLK, use clk-pwm
and pwm-vibrator to make the vibrator work.
Signed-off-by: Luca Weiss
---
now your mainlined smartwatch can wake you up!
Reviewed-by: Konrad Dybcio
Konrad
On 1/24/24 16:31, Luca Weiss wrote:
Add the definitions for the various thermal zones found on the SM6350
SoC. Hooking up GPU and CPU cooling can limit the clock speeds there to
reduce the temperature again to good levels.
Most thermal zones only have one critical temperature configured at
On Fri, Jan 12, 2024 at 07:17:06PM +0900, Masami Hiramatsu (Google) wrote:
SNIP
> * Register @fp to ftrace for enabling the probe on the address given by
> @addrs.
> @@ -298,23 +547,27 @@ EXPORT_SYMBOL_GPL(register_fprobe);
> */
> int register_fprobe_ips(struct fprobe *fp, unsigned long
On Thu, Jan 25, 2024 at 05:42:41AM -0500, Jeff Layton wrote:
> Long ago, file locks used to hang off of a singly-linked list in struct
> inode. Because of this, when leases were added, they were added to the
> same list and so they had to be tracked using the same sort of
> structure.
>
> Several
On Fri, Jan 12, 2024 at 07:10:50PM +0900, Masami Hiramatsu (Google) wrote:
> Hi,
>
> Here is the 6th version of the series to re-implement the fprobe on
> function-graph tracer. The previous version is;
>
> https://lore.kernel.org/all/170290509018.220107.1347127510564358608.stgit@devnote2/
>
>
Hi Masami,
Thanks for taking the time to look at those changes.
On Thu, Jan 25, 2024 at 12:11:49AM +0900, Masami Hiramatsu wrote:
> On Tue, 23 Jan 2024 11:07:54 +
> Vincent Donnefort wrote:
>
> [...]
> > @@ -6592,8 +6641,11 @@ int tracing_set_tracer(struct trace_array *tr, const
> > char
Kalle Valo writes:
> Toke Høiland-Jørgensen writes:
>
>> "Ubisectech Sirius" writes:
>>
Hmm, so from eyeballing the code in question, this looks like it is
another initialisation race along the lines of the one fixed in commit:
8b3046abc99e ("ath9k_htc: fix NULL pointer dereference
Toke Høiland-Jørgensen writes:
> "Ubisectech Sirius" writes:
>
>>>Hmm, so from eyeballing the code in question, this looks like it is
>>>another initialisation race along the lines of the one fixed in commit:
>>>8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at
>>>
"Ubisectech Sirius" writes:
>>Hmm, so from eyeballing the code in question, this looks like it is
>>another initialisation race along the lines of the one fixed in commit:
>>8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at
>>ath9k_htc_tx_get_packet()")
>>Could you please test the patch
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Thursday, January 25, 2024 12:49 PM
> To: wangyunjian
> Cc: m...@redhat.com; willemdebruijn.ker...@gmail.com; k...@kernel.org;
> da...@davemloft.net; magnus.karls...@intel.com; net...@vger.kernel.org;
>
On Sun, 17 Dec 2023, Karel Balej wrote:
> From: Karel Balej
>
> Marvell 88PM880 and 8PM886 are two similar PMICs with mostly matching
> register mapping. They provide various functions such as onkey, battery,
> charger and regulators.
>
> Add support for 88PM886 found for instance in the
> -Original Message-
> From: Willem de Bruijn [mailto:willemdebruijn.ker...@gmail.com]
> Sent: Thursday, January 25, 2024 3:05 AM
> To: wangyunjian ; m...@redhat.com;
> willemdebruijn.ker...@gmail.com; jasow...@redhat.com; k...@kernel.org;
> da...@davemloft.net; magnus.karls...@intel.com
>
1 - 100 of 146 matches
Mail list logo
