On 6/2/24 10:47 PM, David Rientjes wrote:
> On Fri, 31 May 2024, Vlastimil Babka wrote:
>
>> Patches 3 and 4 implement the static keys for the two mm fault injection
>> sites in slab and page allocators. For a quick demonstration I've run a
>> VM and the simple test from [1] that stresses the
On Fri, 31 May 2024, Vlastimil Babka wrote:
> Patches 3 and 4 implement the static keys for the two mm fault injection
> sites in slab and page allocators. For a quick demonstration I've run a
> VM and the simple test from [1] that stresses the slab allocator and got
> this time before the
On Sat, Jun 1, 2024 at 1:57 PM Vlastimil Babka wrote:
>
> On 5/31/24 6:43 PM, Alexei Starovoitov wrote:
> > On Fri, May 31, 2024 at 2:33 AM Vlastimil Babka wrote:
> >> might_alloc(flags);
> >>
> >> - if (unlikely(should_failslab(s, flags)))
> >> - return NULL;
> >> +
On Fri, 31 May 2024 11:33:33 +0200
Vlastimil Babka wrote:
> Error injectable functions cannot be inlined and since some are called
> from hot paths, this incurrs overhead even if no error injection is
> enabled for them.
>
> To remove this overhead when disabled, allow the callsites of error
>
On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
>Incomplete, help needed from ftrace/kprobe and bpf folks.
>
>As previously mentioned by myself [1] and others [2] the functions
>designed for error injection can bring visible overhead in fastpaths
>such as slab or page allocation,
On 5/31/24 6:43 PM, Alexei Starovoitov wrote:
> On Fri, May 31, 2024 at 2:33 AM Vlastimil Babka wrote:
>> might_alloc(flags);
>>
>> - if (unlikely(should_failslab(s, flags)))
>> - return NULL;
>> + if (static_branch_unlikely(_failslab_active)) {
>> +
On 6/1/24 1:39 AM, Roman Gushchin wrote:
> On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
>> Incomplete, help needed from ftrace/kprobe and bpf folks.
>>
>> As previously mentioned by myself [1] and others [2] the functions
>> designed for error injection can bring visible
On 5/31/24 5:31 PM, Mark Rutland wrote:
> Hi,
>
> On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
>> Incomplete, help needed from ftrace/kprobe and bpf folks.
>
>> - the generic error injection using kretprobes with
>> override_function_with_return is handled in patch 2. The
On Fri, May 31, 2024 at 11:33:35AM +0200, Vlastimil Babka wrote:
> Similarly to should_failslab(), remove the overhead of calling the
> noinline function should_fail_alloc_page() with a static key that guards
> the allocation hotpath callsite and is controlled by the fault and error
> injection
On Fri, May 31, 2024 at 11:33:34AM +0200, Vlastimil Babka wrote:
> Since commit 4f6923fbb352 ("mm: make should_failslab always available for
> fault injection") should_failslab() is unconditionally a noinline
> function. This adds visible overhead to the slab allocation hotpath,
> even if the
On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
> Incomplete, help needed from ftrace/kprobe and bpf folks.
>
> As previously mentioned by myself [1] and others [2] the functions
> designed for error injection can bring visible overhead in fastpaths
> such as slab or page
On Fri, May 31, 2024 at 9:44 AM Alexei Starovoitov
wrote:
>
> On Fri, May 31, 2024 at 2:33 AM Vlastimil Babka wrote:
> >
> > Since commit 4f6923fbb352 ("mm: make should_failslab always available for
> > fault injection") should_failslab() is unconditionally a noinline
> > function. This adds
On Fri, May 31, 2024 at 2:33 AM Vlastimil Babka wrote:
>
> Since commit 4f6923fbb352 ("mm: make should_failslab always available for
> fault injection") should_failslab() is unconditionally a noinline
> function. This adds visible overhead to the slab allocation hotpath,
> even if the function is
Hi,
On Fri, May 31, 2024 at 11:33:31AM +0200, Vlastimil Babka wrote:
> Incomplete, help needed from ftrace/kprobe and bpf folks.
> - the generic error injection using kretprobes with
> override_function_with_return is handled in patch 2. The
> ALLOW_ERROR_INJECTION() annotation is extended
Similarly to should_failslab(), remove the overhead of calling the
noinline function should_fail_alloc_page() with a static key that guards
the allocation hotpath callsite and is controlled by the fault and error
injection frameworks.
Signed-off-by: Vlastimil Babka
---
mm/fail_page_alloc.c | 3
Incomplete, help needed from ftrace/kprobe and bpf folks.
As previously mentioned by myself [1] and others [2] the functions
designed for error injection can bring visible overhead in fastpaths
such as slab or page allocation, because even if nothing hooks into them
at a given moment, they are
Error injectable functions cannot be inlined and since some are called
from hot paths, this incurrs overhead even if no error injection is
enabled for them.
To remove this overhead when disabled, allow the callsites of error
injectable functions to put the calls behind a static key, which the
Since commit 4f6923fbb352 ("mm: make should_failslab always available for
fault injection") should_failslab() is unconditionally a noinline
function. This adds visible overhead to the slab allocation hotpath,
even if the function is empty. With CONFIG_FAILSLAB=y there's additional
overhead when
Some fault injection sites are placed in hotpaths and incur overhead
even if not enabled, due to one or more function calls leading up to
should_fail_ex() that returns false due to attr->probability == 0.
This overhead can be eliminated if the outermost call into the checks is
guarded with a
On Samstag, 25. Mai 2024 18:47:08 MESZ Krzysztof Kozlowski wrote:
> On 24/05/2024 19:55, Luca Weiss wrote:
> > On Donnerstag, 23. Mai 2024 08:19:11 MESZ Krzysztof Kozlowski wrote:
> >> On 23/05/2024 08:16, Luca Weiss wrote:
> >>> On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
On 24/05/2024 19:55, Luca Weiss wrote:
> On Donnerstag, 23. Mai 2024 08:19:11 MESZ Krzysztof Kozlowski wrote:
>> On 23/05/2024 08:16, Luca Weiss wrote:
>>> On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
On 22/05/2024 19:34, Luca Weiss wrote:
> On Mittwoch, 22. Mai
On Donnerstag, 23. Mai 2024 08:19:11 MESZ Krzysztof Kozlowski wrote:
> On 23/05/2024 08:16, Luca Weiss wrote:
> > On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
> >> On 22/05/2024 19:34, Luca Weiss wrote:
> >>> On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski
On 23/05/2024 08:16, Luca Weiss wrote:
> On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
>> On 22/05/2024 19:34, Luca Weiss wrote:
>>> On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
On 21/05/2024 22:35, Luca Weiss wrote:
> On Dienstag, 21. Mai 2024
On Donnerstag, 23. Mai 2024 08:02:13 MESZ Krzysztof Kozlowski wrote:
> On 22/05/2024 19:34, Luca Weiss wrote:
> > On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
> >> On 21/05/2024 22:35, Luca Weiss wrote:
> >>> On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
On 22/05/2024 19:34, Luca Weiss wrote:
> On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
>> On 21/05/2024 22:35, Luca Weiss wrote:
>>> On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
On 20/05/2024 17:11, Luca Weiss wrote:
> Hi Krzysztof
>
>
On Mittwoch, 22. Mai 2024 08:49:43 MESZ Krzysztof Kozlowski wrote:
> On 21/05/2024 22:35, Luca Weiss wrote:
> > On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
> >> On 20/05/2024 17:11, Luca Weiss wrote:
> >>> Hi Krzysztof
> >>>
> >>> Ack, sounds good.
> >>>
> >>> Maybe also
On 21/05/2024 22:35, Luca Weiss wrote:
> On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
>> On 20/05/2024 17:11, Luca Weiss wrote:
>>> Hi Krzysztof
>>>
>>> Ack, sounds good.
>>>
>>> Maybe also from you, any opinion between these two binding styles?
>>>
>>> So first using index
On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
> On 20/05/2024 17:11, Luca Weiss wrote:
> > Hi Krzysztof
> >
> > Ack, sounds good.
> >
> > Maybe also from you, any opinion between these two binding styles?
> >
> > So first using index of mboxes for the numbering, where for
On 20/05/2024 17:11, Luca Weiss wrote:
> Hi Krzysztof
>
> Ack, sounds good.
>
> Maybe also from you, any opinion between these two binding styles?
>
> So first using index of mboxes for the numbering, where for the known
> usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
>
On Montag, 20. Mai 2024 08:46:39 MESZ Krzysztof Kozlowski wrote:
> On 15/05/2024 17:06, Luca Weiss wrote:
> > Hi Rob,
> >
> > Any feedback on the below topic?
>
> Can be explained in description, like
> mboxes:
> description: Each entry corresponds to one remote processor
> maxItems: 5
Hi
On 15/05/2024 17:06, Luca Weiss wrote:
> Hi Rob,
>
> Any feedback on the below topic?
Can be explained in description, like
mboxes:
description: Each entry corresponds to one remote processor
maxItems: 5
Best regards,
Krzysztof
Hi Rob,
Any feedback on the below topic?
Regards
Luca
On Donnerstag, 25. April 2024 20:54:40 MESZ Luca Weiss wrote:
> On Donnerstag, 25. April 2024 18:17:15 MESZ Rob Herring wrote:
> > On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> > > The qcom,ipc-N properties are essentially
On Wed, Apr 24, 2024 at 5:02 PM Andrii Nakryiko wrote:
>
> At the lowest level, rethook-based kretprobes on x86-64 architecture go
> through arch_rethoook_trampoline() function, manually written in
> assembly, which calls into a simple arch_rethook_trampoline_callback()
> function, written in C,
On Donnerstag, 25. April 2024 18:17:15 MESZ Rob Herring wrote:
> On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> > The qcom,ipc-N properties are essentially providing a reference to a
> > mailbox, so allow using the mboxes property to do the same in a more
> > structured way.
>
>
On Wed, Apr 24, 2024 at 07:21:51PM +0200, Luca Weiss wrote:
> The qcom,ipc-N properties are essentially providing a reference to a
> mailbox, so allow using the mboxes property to do the same in a more
> structured way.
Can we mark qcom,ipc-N as deprecated then?
> Since multiple SMSM hosts are
At the lowest level, rethook-based kretprobes on x86-64 architecture go
through arch_rethoook_trampoline() function, manually written in
assembly, which calls into a simple arch_rethook_trampoline_callback()
function, written in C, and only doing a few straightforward field
assignments, before
On 4/24/24 19:21, Luca Weiss wrote:
Add support for using the mbox interface instead of manually writing to
the syscon. With this change the driver will attempt to get the mailbox
first, and if that fails it will fall back to the existing way of using
qcom,ipc-* properties and converting to
Add support for using the mbox interface instead of manually writing to
the syscon. With this change the driver will attempt to get the mailbox
first, and if that fails it will fall back to the existing way of using
qcom,ipc-* properties and converting to syscon.
Signed-off-by: Luca Weiss
---
Take a shot at converting the last driver that requires direct
"qcom,ipc*" syscon references in devicetree by allowing the smsm driver
to use the mailbox interface to achieve the same effect.
I'm not very happy about how the devicetree change looks in the end.
Perhaps it's better to use
The qcom,ipc-N properties are essentially providing a reference to a
mailbox, so allow using the mboxes property to do the same in a more
structured way.
Since multiple SMSM hosts are supported, we need to be able to provide
the correct mailbox for each host. The old qcom,ipc-N properties map to
On Wed, Apr 03, 2024 at 03:29:12PM -0400, Steven Rostedt wrote:
> On Wed, 3 Apr 2024 11:53:14 -0700
> "Paul E. McKenney" wrote:
>
> > @@ -5366,6 +5366,13 @@ static void remove_direct_functions_hash(struct
> > ftrace_hash *hash, unsigned long
> > }
> > }
> >
> > +static void
On Wed, 3 Apr 2024 11:53:14 -0700
"Paul E. McKenney" wrote:
> @@ -5366,6 +5366,13 @@ static void remove_direct_functions_hash(struct
> ftrace_hash *hash, unsigned long
> }
> }
>
> +static void register_ftrace_direct_cb(struct rcu_head *rhp)
> +{
> + struct ftrace_hash *fhp =
Note that the immediate pressure for this patch should be relieved by the
NAPI patch series [1], but this sort of problem could easily arise again.
So would this change make sense?
When running heavy test workloads with KASAN enabled, RCU Tasks grace
periods can extend for many tens of seconds,
Currently most of the API for page_frag API is returning
'virtual address' as output or expecting 'virtual address'
as input, in order to differentiate the API handling between
'virtual address' and 'struct page', add '_va' suffix to the
corresponding API mirroring the page_pool_alloc_va() API of
On Fri, Mar 01, 2024 at 03:30:01PM -0500, Steven Rostedt wrote:
> On Fri, 1 Mar 2024 12:25:10 -0800
> "Paul E. McKenney" wrote:
>
> > > That would work for me. If there are no objections, I will make this
> > > change.
> >
> > But I did check the latency of synchronize_rcu_tasks_rude()
On Fri, 1 Mar 2024 12:25:10 -0800
"Paul E. McKenney" wrote:
> > That would work for me. If there are no objections, I will make this
> > change.
>
> But I did check the latency of synchronize_rcu_tasks_rude() (about 100ms)
> and synchronize_rcu() (about 20ms). This is on a
On Wed, Feb 28, 2024 at 01:16:04PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:
> > On Wed, 28 Feb 2024 11:38:29 -0800
> > "Paul E. McKenney" wrote:
> >
> > > The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> > > even
On Wed, Feb 28, 2024 at 03:22:36PM -0500, Steven Rostedt wrote:
> On Wed, 28 Feb 2024 11:38:29 -0800
> "Paul E. McKenney" wrote:
>
> > The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> > even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
> > might see
On Wed, 28 Feb 2024 11:38:29 -0800
"Paul E. McKenney" wrote:
> The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
> even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
> might see the occasional preemption, and that this preemption just might
> happen
The advent of CONFIG_PREEMPT_AUTO, AKA lazy preemption, will mean that
even kernels built with CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY
might see the occasional preemption, and that this preemption just might
happen within a trampoline.
Therefore, update ftrace_shutdown() to invoke
On Wed, Feb 21, 2024 at 6:01 PM John Garry wrote:
>
> On 08/02/2024 10:08, John Garry wrote:
> > On 05/02/2024 23:10, Masahiro Yamada wrote:
> I think what you can contribute are:
>
> - Explore the UTS_RELEASE users, and check if you can get rid of it.
> >>> Unfortunately I
On 08/02/2024 10:08, John Garry wrote:
On 05/02/2024 23:10, Masahiro Yamada wrote:
I think what you can contribute are:
- Explore the UTS_RELEASE users, and check if you can get rid of it.
Unfortunately I expect resistance for this. I also expect places like FW
loader it is necessary. And
Let me pick this patch because this is a real bugfix.
On Wed, 14 Feb 2024 22:22:23 +0900
"Masami Hiramatsu (Google)" wrote:
> From: Masami Hiramatsu (Google)
>
> Fix to search a field from the structure which has anonymous union
> correctly.
> Since the reference `type` pointer was updated in
From: Masami Hiramatsu (Google)
Support accessing $argN in the return probe events. This will help users to
record entry data in function return (exit) event for simplfing the function
entry/exit information in one event, and record the result values (e.g.
allocated object/initialized object) at
From: Masami Hiramatsu (Google)
Instead of incrementing the trace_probe::nr_args, init it at trace_probe_init().
This is a cleanup, so the behavior is not changed.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_eprobe.c |2 +-
kernel/trace/trace_probe.c | 10 ++
From: Masami Hiramatsu (Google)
Cleanup traceprobe_parse_probe_arg_body() to split out the
type parser and post-processing part of fetch_insn.
This makes no functional change.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_probe.c | 230
From: Masami Hiramatsu (Google)
Despite the fprobe event, "Kretprobe" was commented. So fix it.
Signed-off-by: Masami Hiramatsu (Google)
---
kernel/trace/trace_fprobe.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace_fprobe.c
From: Masami Hiramatsu (Google)
Fix to search a field from the structure which has anonymous union
correctly.
Since the reference `type` pointer was updated in the loop, the search
loop suddenly aborted where it hits an anonymous union. Thus it can not
find the field after the anonymous union.
Hi,
Here is a series of patches to support accessing function entry data from
function *return* probes (including kretprobe and fprobe-exit event).
This allows us to access the results of some functions, which returns the
error code and its results are passed via function parameter, such as an
On 05/02/2024 23:10, Masahiro Yamada wrote:
I think what you can contribute are:
- Explore the UTS_RELEASE users, and check if you can get rid of it.
Unfortunately I expect resistance for this. I also expect places like FW
loader it is necessary. And when this is used in sysfs, people will
On Thu, 25 Jan 2024 22:56:24 +0100, Luca Weiss wrote:
> 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
>
On Mon, Feb 5, 2024 at 5:25 PM John Garry wrote:
>
> On 02/02/2024 15:01, Masahiro Yamada wrote:
> >> --
> >> 2.35.3
> >
> > As you see, several drivers store UTS_RELEASE in their driver data,
> > and even print it in debug print.
> >
> >
> > I do not see why it is useful.
>
> I would tend to
Hi Evgenii,
On Fri, Feb 02, 2024 at 02:30:00PM -0800, Evgenii Stepanov wrote:
> On Thu, Jan 25, 2024 at 8:44 AM Alexandru Elisei
> wrote:
> >
> > Before enabling MTE tag storage management, make sure that the CMA areas
> > have been successfully activated. If a CMA area fails activation, the
On 02/02/2024 15:01, Masahiro Yamada wrote:
--
2.35.3
As you see, several drivers store UTS_RELEASE in their driver data,
and even print it in debug print.
I do not see why it is useful.
I would tend to agree, and mentioned that earlier.
As you discussed in 3/4, if UTS_RELEASE is
On Fri, Feb 2, 2024 at 6:56 AM Alexandru Elisei
wrote:
>
> Hi Peter,
>
> On Thu, Feb 01, 2024 at 08:02:40PM -0800, Peter Collingbourne wrote:
> > On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
> > wrote:
> > >
> > > Linux restores tags when a page is swapped in and there are tags
> > >
On Fri, Feb 2, 2024 at 6:56 AM Alexandru Elisei
wrote:
>
> Hi Peter,
>
> On Thu, Feb 01, 2024 at 08:02:40PM -0800, Peter Collingbourne wrote:
> > On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
> > wrote:
> > >
> > > Linux restores tags when a page is swapped in and there are tags
> > >
On Thu, Jan 25, 2024 at 8:44 AM Alexandru Elisei
wrote:
>
> 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
On Sat, 3 Feb 2024 00:01:26 +0900 Masahiro Yamada wrote:
> I do not see why it is useful.
> As you discussed in 3/4, if UTS_RELEASE is unneeded,
> it is better to get rid of it.
To be clear - the discussion on 3/4 was about the fact that netdev
already prints UTS_RELEASE into the version member
On Wed, Jan 31, 2024 at 7:49 PM John Garry wrote:
>
> When hacking it is a waste of time and compute energy that we need to
> rebuild much kernel code just for changing the head git commit, like this:
>
> > touch include/generated/utsrelease.h
> > time make -j3
> mkdir -p
Hi Peter,
On Thu, Feb 01, 2024 at 08:02:40PM -0800, Peter Collingbourne wrote:
> On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
> wrote:
> >
> > 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
On 27.01.2024 18:32, Luca Weiss wrote:
> On Freitag, 26. Jänner 2024 00:50:43 CET Konrad Dybcio wrote:
>> 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
On 27.01.2024 18:24, Luca Weiss wrote:
> On Freitag, 26. Jänner 2024 00:49:55 CET Konrad Dybcio wrote:
>> 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:
On Thu, Jan 25, 2024 at 8:45 AM Alexandru Elisei
wrote:
>
> 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
On Thu, Feb 01, 2024 at 01:42:08PM +0530, Anshuman Khandual wrote:
>
>
> On 1/25/24 22:12, Alexandru Elisei wrote:
> > 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
Hi,
On Thu, Feb 01, 2024 at 02:51:39PM +0530, Anshuman Khandual wrote:
>
>
> On 1/25/24 22:12, Alexandru Elisei wrote:
> > 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
Hi,
On Thu, Feb 01, 2024 at 11:22:13AM +0530, Anshuman Khandual wrote:
> On 1/25/24 22:12, Alexandru Elisei wrote:
> > 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
Hi,
On Thu, Feb 01, 2024 at 09:00:23AM +0530, Anshuman Khandual wrote:
>
>
> On 1/25/24 22:12, Alexandru Elisei wrote:
> > 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
On 01/02/2024 16:09, Jakub Kicinski wrote:
On Thu, 1 Feb 2024 14:20:23 +0100 Jiri Pirko wrote:
BTW, I assume that changes like this are also ok:
8<-
net: team: Don't bother filling in ethtool driver version
Yup, just to be clear - you can send this independently from the
On Thu, 1 Feb 2024 14:20:23 +0100 Jiri Pirko wrote:
> >BTW, I assume that changes like this are also ok:
> >
> >8<-
> >
> > net: team: Don't bother filling in ethtool driver version
Yup, just to be clear - you can send this independently from the series,
tag is as
[PATCH
Thu, Feb 01, 2024 at 01:57:16PM CET, john.g.ga...@oracle.com wrote:
>On 31/01/2024 19:24, Jakub Kicinski wrote:
>> On Wed, 31 Jan 2024 10:48:50 + John Garry wrote:
>> > Instead of using UTS_RELEASE, use uts_release, which means that we don't
>> > need to rebuild the code just for the git head
On 31/01/2024 19:24, Jakub Kicinski wrote:
On Wed, 31 Jan 2024 10:48:50 + John Garry wrote:
Instead of using UTS_RELEASE, use uts_release, which means that we don't
need to rebuild the code just for the git head commit changing.
Signed-off-by: John Garry
Yes, please!
Acked-by: Jakub
On 1/25/24 22:12, Alexandru Elisei wrote:
> 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
On 1/25/24 22:12, Alexandru Elisei wrote:
> 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()
On 1/25/24 22:12, Alexandru Elisei wrote:
> 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
On 1/25/24 22:12, Alexandru Elisei wrote:
> 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
On Wed, Jan 31, 2024 at 05:16:09PM +, John Garry wrote:
> On 31/01/2024 16:22, Greg KH wrote:
> > > before:
> > > real0m53.591s
> > > user1m1.842s
> > > sys 0m9.161s
> > >
> > > after:
> > > real0m37.481s
> > > user0m46.461s
> > > sys 0m7.199s
> > >
> > > Sending as
On Wed, 31 Jan 2024 10:48:49 +
John Garry wrote:
> Instead of using UTS_RELEASE, use uts_release, which means that we don't
> need to rebuild the code just for the git head commit changing.
>
> Signed-off-by: John Garry
Acked-by: Steven Rostedt (Google)
-- Steve
> ---
>
On Wed, 31 Jan 2024 10:48:50 + John Garry wrote:
> Instead of using UTS_RELEASE, use uts_release, which means that we don't
> need to rebuild the code just for the git head commit changing.
>
> Signed-off-by: John Garry
Yes, please!
Acked-by: Jakub Kicinski
On 31/01/2024 16:22, Greg KH wrote:
before:
real0m53.591s
user1m1.842s
sys 0m9.161s
after:
real0m37.481s
user0m46.461s
sys 0m7.199s
Sending as an RFC as I need to test more of the conversions and I would
like to also convert more UTS_RELEASE users to prove this is
On Wed, Jan 31, 2024 at 10:48:47AM +, John Garry wrote:
> When hacking it is a waste of time and compute energy that we need to
> rebuild much kernel code just for changing the head git commit, like this:
>
> > touch include/generated/utsrelease.h
> > time make -j3
> mkdir -p
Hi,
On Wed, Jan 31, 2024 at 11:54:17AM +0530, Anshuman Khandual wrote:
>
>
> On 1/30/24 17:05, Alexandru Elisei wrote:
> > Hi,
> >
> > On Tue, Jan 30, 2024 at 10:50:00AM +0530, Anshuman Khandual wrote:
> >>
> >> On 1/25/24 22:12, Alexandru Elisei wrote:
> >>> Today, cma_alloc() is used to
Hi,
On Wed, Jan 31, 2024 at 06:49:34PM +0530, Anshuman Khandual wrote:
> On 1/30/24 17:03, Alexandru Elisei wrote:
> > Hi,
> >
> > I really appreciate the feedback you have given me so far. I believe the
> > commit message isn't clear enough and there has been a confusion.
> >
> > A CMA user
Hi,
On Wed, Jan 31, 2024 at 10:10:05AM +0530, Anshuman Khandual wrote:
>
>
> On 1/30/24 17:28, Alexandru Elisei wrote:
> > Hi,
> >
> > On Tue, Jan 30, 2024 at 10:22:11AM +0530, Anshuman Khandual wrote:
> >>
> >> On 1/29/24 17:21, Alexandru Elisei wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jan 29,
On 1/30/24 17:03, Alexandru Elisei wrote:
> Hi,
>
> I really appreciate the feedback you have given me so far. I believe the
> commit message isn't clear enough and there has been a confusion.
>
> A CMA user adds a CMA area to the cma_areas array with
> cma_declare_contiguous_nid() or
Hi,
On Wed, Jan 31, 2024 at 12:23:51PM +0530, Anshuman Khandual wrote:
>
>
> On 1/30/24 17:04, Alexandru Elisei wrote:
> > Hi,
> >
> > On Tue, Jan 30, 2024 at 03:25:20PM +0530, Anshuman Khandual wrote:
> >>
> >> On 1/25/24 22:12, Alexandru Elisei wrote:
> >>> arm64 uses VM_HIGH_ARCH_0 and
Add a char [] for UTS_RELEASE so that we don't need to rebuild code which
references UTS_RELEASE.
Signed-off-by: John Garry
---
include/linux/utsname.h | 1 +
init/version.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index
When hacking it is a waste of time and compute energy that we need to
rebuild much kernel code just for changing the head git commit, like this:
> touch include/generated/utsrelease.h
> time make -j3
mkdir -p /home/john/mnt_sda4/john/kernel-dev2/tools/objtool && make
Instead of using UTS_RELEASE, use uts_release, which means that we don't
need to rebuild the code just for the git head commit changing.
Since UTS_RELEASE was used for fw_path and this points to const data,
append uts_release dynamically to an intermediate string.
Signed-off-by: John Garry
---
Instead of using UTS_RELEASE, use uts_release, which means that we don't
need to rebuild the code just for the git head commit changing.
Signed-off-by: John Garry
---
net/ethtool/ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ethtool/ioctl.c
Instead of using UTS_RELEASE, use uts_release, which means that we don't
need to rebuild the code just for the git head commit changing.
Signed-off-by: John Garry
---
kernel/trace/trace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace.c
1 - 100 of 40503 matches
Mail list logo
