On Sat, 1 Jun 2024 01:01:26 +0800
kernel test robot wrote:
> Hi Masami,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v6.10-rc1 next-20240531]
> [cannot apply to rostedt-trace/for-next r
quot;);
MODULE_LICENSE("GPL");
---
base-commit: b050496579632f86ee1ef7e7501906db579f3457
change-id: 20240531-md-lib-test_kmod-83bf2ee7e725
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, 31 May 2024 23:50:23 +0900
Masami Hiramatsu (Google) wrote:
> So is it similar to the fprobe/kprobe, use shared signle ftrace_ops,
> but keep each fgraph has own hash table?
Sort of.
I created helper functions in ftrace that lets you have a "manager
ftrace_ops" that will be used to
With different cgroups, the script starts one or multiple concurrent SGX
selftests (test_sgx), each to run the unclobbered_vdso_oversubscribed
test case, which loads an enclave of EPC size equal to the EPC capacity
available on the platform. The script checks results against the
expectation set
From: Sean Christopherson
Add initial documentation of how to regulate the distribution of
SGX Enclave Page Cache (EPC) memory via the Miscellaneous cgroup
controller.
Signed-off-by: Sean Christopherson
Co-developed-by: Kristen Carlson Accardi
Signed-off-by: Kristen Carlson Accardi
From: Kristen Carlson Accardi
Previous patches have implemented all infrastructure needed for
per-cgroup EPC page tracking and reclaiming. But all reclaimable EPC
pages are still tracked in the global LRU as sgx_epc_page_lru() always
returns reference to the global LRU.
Change
Enclave Page Cache(EPC) memory can be swapped out to regular system
memory, and the consumed memory should be charged to a proper
mem_cgroup. Currently the selection of mem_cgroup to charge is done in
sgx_encl_get_mem_cgroup(). But it considers all contexts other than the
ksgxd thread are user
From: Kristen Carlson Accardi
In cases EPC pages need be allocated during a page fault and the cgroup
usage is near its limit, an asynchronous reclamation needs be triggered
to avoid blocking the page fault handling.
Create a workqueue, corresponding work item and function definitions
for EPC
From: Kristen Carlson Accardi
Currently in the EPC page allocation, the kernel simply fails the
allocation when the current EPC cgroup fails to charge due to its usage
reaching limit. This is not ideal. When that happens, a better way is
to reclaim EPC page(s) from the current EPC cgroup
From: Kristen Carlson Accardi
For the global reclaimer to determine if any page available for
reclamation at the global level, it currently only checks for emptiness
of the global LRU. That will be inadequate when pages are tracked in
multiple LRUs, one per cgroup. For this purpose, create a new
From: Kristen Carlson Accardi
The SGX driver tracks reclaimable EPC pages by adding a newly allocated
page into the global LRU list in sgx_mark_page_reclaimable(), and doing
the opposite in sgx_unmark_page_reclaimable().
To support SGX EPC cgroup, the SGX driver will need to maintain an LRU
From: Sean Christopherson
Introduce a data structure to wrap the existing reclaimable list and its
spinlock. Each cgroup later will have one instance of this structure to
track EPC pages allocated for processes associated with the same cgroup.
Just like the global SGX reclaimer (ksgxd), an EPC
From: Kristen Carlson Accardi
SGX Enclave Page Cache (EPC) memory allocations are separate from normal
RAM allocations, and are managed solely by the SGX subsystem. The
existing cgroup memory controller cannot be used to limit or account for
SGX EPC memory, which is a desirable feature in some
From: Kristen Carlson Accardi
Add SGX EPC memory, MISC_CG_RES_SGX_EPC, to be a valid resource type
for the misc controller.
Signed-off-by: Kristen Carlson Accardi
Co-developed-by: Haitao Huang
Signed-off-by: Haitao Huang
Reviewed-by: Jarkko Sakkinen
Reviewed-by: Kai Huang
Tested-by: Jarkko
From: Kristen Carlson Accardi
The misc cgroup controller (subsystem) currently does not perform
resource type specific action for Cgroups Subsystem State (CSS) events:
the 'css_alloc' event when a cgroup is created and the 'css_free' event
when a cgroup is destroyed.
Define callbacks for those
From: Kristen Carlson Accardi
The SGX EPC cgroup will reclaim EPC pages when usage in a cgroup reaches
its or ancestor's limit. This requires a walk from the current cgroup up
to the root similar to misc_cg_try_charge(). Export misc_cg_parent() to
enable this walk.
The SGX driver also needs
Replace boolean parameters for 'reclaim' in the function
sgx_alloc_epc_page() and its callers with an enum.
Also opportunistically remove non-static declaration of
__sgx_alloc_epc_page() and a typo
Signed-off-by: Haitao Huang
Suggested-by: Jarkko Sakkinen
Suggested-by: Dave Hansen
SGX Enclave Page Cache (EPC) memory allocations are separate from normal
RAM allocations, and are managed solely by the SGX subsystem. The existing
cgroup memory controller cannot be used to limit or account for SGX EPC
memory, which is a desirable feature in some environments, e.g., support
for
Hi Tal,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on horms-ipvs/master v6.10-rc1 next-20240531]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
On 5/31/24 07:23, Miroslav Benes wrote:
> Hi,
>
> On Tue, 21 Jul 2020, Joe Lawrence wrote:
>
>> In light of [PATCH] Revert "kbuild: use -flive-patching when
>> CONFIG_LIVEPATCH is enabled" [1], we should add some loud disclaimers
>> and explanation of the impact compiler optimizations have on
>>
On Tue, May 21, 2024 at 08:34:46AM +0200, Miroslav Benes wrote:
> Hello,
>
> On Mon, 20 May 2024, zhang warden wrote:
>
> >
> >
> > > On May 20, 2024, at 14:46, Miroslav Benes wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 20 May 2024, Wardenjohn wrote:
> > >
> > >> Livepatch module usually
Dmitry Baryshkov writes:
> Make the driver use qcom_fw_helper to autodetect the path to the
> calibration data file.
>
> Signed-off-by: Dmitry Baryshkov
Not a fan of one sentence commit messages. It would be nice to explain a
bit more in the commit message, for instance answering to the
Bjorn Andersson writes:
> On Mon, May 27, 2024 at 02:42:44PM GMT, Dmitry Baryshkov wrote:
>
>> On Thu, 23 May 2024 at 01:48, Bjorn Andersson
>> wrote:
>> >
>> > On Tue, May 21, 2024 at 03:08:31PM +0200, Dmitry Baryshkov wrote:
>> > > On Tue, 21 May 2024 at 13:20, Kalle Valo wrote:
>> > > >
>>
On Thu, May 23, 2024 at 5:11 AM Jiri Olsa wrote:
>
> hi,
> as part of the effort on speeding up the uprobes [0] coming with
> return uprobe optimization by using syscall instead of the trap
> on the uretprobe trampoline.
>
> The speed up depends on instruction type that uprobe is installed
> and
Add an entry to MAINTAINERS for the Marvell 88PM886 PMIC MFD, onkey and
regulator drivers.
Signed-off-by: Karel Balej
---
Notes:
RFC v3:
- Remove onkey bindings file.
RFC v2:
- Only mention 88PM886 in the commit message.
- Add regulator driver.
- Rename the entry.
Support the LDO and buck regulators of the Marvell 88PM886 PMIC.
Signed-off-by: Karel Balej
---
Notes:
v7:
- Address Mark's feedback:
- Drop get_current_limit op, max_uA values and thus unneeded struct
pm886_regulator and adapt the code accordingly.
v6:
- Remove
Marvell 88PM886 PMIC provides onkey among other things. Add client
driver to handle it. The driver currently only provides a basic support
omitting additional functions found in the vendor version, such as long
onkey and GPIO integration.
Acked-by: Dmitry Torokhov
Signed-off-by: Karel Balej
---
Marvell 88PM886 is a PMIC which provides various functions such as
onkey, battery, charger and regulators. It is found for instance in the
samsung,coreprimevelte smartphone with which this was tested. Implement
basic support to allow for the use of regulators and onkey.
Signed-off-by: Karel Balej
Marvell 88PM886 is a PMIC with several subdevices such as onkey,
regulators or battery and charger. It comes in at least two revisions,
A0 and A1 -- only A1 is described here at the moment.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Karel Balej
---
Notes:
RFC v4:
- Address
Hello,
the following implements basic support for Marvell's 88PM886 PMIC which
is found for instance as a component of the samsung,coreprimevelte
smartphone which inspired this and also serves as a testing platform.
The code for the MFD is based primarily on this old series [1] with the
addition
On Thu, May 30, 2024 at 09:42:26AM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 5/29/24 22:35, Mathieu Poirier wrote:
> > On Wed, May 29, 2024 at 09:13:26AM +0200, Arnaud POULIQUEN wrote:
> >> Hello Mathieu,
> >>
> >> On 5/28/24 23:30, Mathieu Poirier wrote:
> >>> On Tue, May 21, 2024
fp_t flags)
> > @@ -3889,8 +3891,10 @@ struct kmem_cache *slab_pre_alloc_hook(struct
> > kmem_cache *s, gfp_t flags)
> >
> > might_alloc(flags);
> >
> > - if (unlikely(should_failslab(s, flags)))
> > - return NULL;
> > + if (static_branch_unlikely(_failslab_active)) {
> > + if (should_failslab(s, flags))
> > + return NULL;
> > + }
>
> makes sense.
> Acked-by: Alexei Starovoitov
>
> Do you have any microbenchmark numbers before/after this optimization?
There are numbers in the cover letter for the entire series:
https://lore.kernel.org/lkml/20240531-fault-injection-statickeys-v1-0-a513fd0a9...@suse.cz/
Hi Masami,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.10-rc1 next-20240531]
[cannot apply to rostedt-trace/for-next rostedt-trace/for-next-urgent]
[If your patch is applied to the wrong git tree, kindly drop us
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
On Fri, 31 May 2024 02:03:46 -0400
Steven Rostedt wrote:
> On Fri, 31 May 2024 12:12:41 +0900
> Masami Hiramatsu (Google) wrote:
>
> > On Thu, 30 May 2024 22:30:57 -0400
> > Steven Rostedt wrote:
> >
> > > On Fri, 24 May 2024 22:37:02 -0400
> > > Steven Rostedt wrote:
> > >
> > > > From:
On Fri, 31 May 2024 03:24:25 -0400
Steven Rostedt wrote:
> On Fri, 31 May 2024 11:37:21 +0900
> Masami Hiramatsu (Google) wrote:
>
> > So, in summary, it is designed to be a module. Steve, I think these tests
> > should be kept as modules. There are many reason to do so.
> >
> > - This test
> And for the unlikely branch, isn’t the complier will compile this branch
> into a cold branch that will do no harm to the function performance?
The test (cmp insn or something like that) still needs to be there. Since
there is only a simple assignment in the branch, the compiler may just
> On May 31, 2024, at 15:21, Miroslav Benes wrote:
>
> Hi,
>
> On Fri, 31 May 2024, zhang warden wrote:
>
> you have not replied to my questions/feedback yet.
>
> Also, I do not think that unlikely changes anything here. It is a simple
> branch after all.
>
> Miroslav
Hi Miroslav,
Sorry
Lee Jones, 2024-05-31T11:24:52+01:00:
> Are you planning on seeing to Mark's review comments?
Indeed, I'm hoping that I will be able to send it over the weekend.
K. B.
On 30.05.2024 5:05 PM, Luca Weiss wrote:
> Add the required DTS node for the USB VBUS output regulator, which is
> available on PM7250B. This will provide the VBUS source to connected
> peripherals.
>
> Reviewed-by: Bryan O'Donoghue
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Konrad Dybcio
On 31/05/2024 14:05, David Wronek wrote:
> It looks like "cdsp_mem" was pasted in the license header by accident.
> Fix the typo by removing it.
>
> Signed-off-by: David Wronek
> ---
> arch/arm64/boot/dts/qcom/sm8550-samsung-q5q.dts | 2 +-
Fixes: ba2c082a401f ("arm64: dts: qcom: sm8550: Add
ier: BSD-3-Clause
/*
* Copyright (c) 2024, Alexandru Marc Serdeliuc
* Copyright (c) 2024, David Wronek
---
base-commit: 0e1980c40b6edfa68b6acf926bab22448a6e40c9
change-id: 20240531-fix-typo-q5q-5d34423b7bb4
Best regards,
--
David Wronek
Hi,
On Tue, 21 Jul 2020, Joe Lawrence wrote:
> In light of [PATCH] Revert "kbuild: use -flive-patching when
> CONFIG_LIVEPATCH is enabled" [1], we should add some loud disclaimers
> and explanation of the impact compiler optimizations have on
> livepatching.
>
> The first commit provides
On Sat, 04 May 2024, Karel Balej wrote:
> Marvell 88PM886 is a PMIC which provides various functions such as
> onkey, battery, charger and regulators. It is found for instance in the
> samsung,coreprimevelte smartphone with which this was tested. Implement
> basic support to allow for the use of
From: Masami Hiramatsu (Google)
Support raw tracepoint event on module by fprobe events.
Since it only uses for_each_kernel_tracepoint() to find a tracepoint,
the tracepoints on modules are not handled. Thus if user specified a
tracepoint on a module, it shows an error.
This adds new
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 30/05/2024 18:48, Hari Nagalla wrote:
> The C7xv-dsp on AM62A have 32KB L1 I-cache and a 64KB L1 D-cache. It
> does not have an addressable l1dram . So, remove this optional sram
> property from the bindings to fix device tree build warnings.
>
> Signed-off-by: Hari Nagalla
> ---
> Changes
On Fri, 31 May 2024 11:37:21 +0900
Masami Hiramatsu (Google) wrote:
> So, in summary, it is designed to be a module. Steve, I think these tests
> should be kept as modules. There are many reason to do so.
>
> - This test is designed to be used as module.
> - This can conflict with other boot
Hi,
On Fri, 31 May 2024, zhang warden wrote:
>
> Hi Bros,
>
> How about my patch? I do think it is a viable feature to show the state
> of the patched function. If we add an unlikely branch test before we set
> the 'called' state, once this function is called, there maybe no
> negative
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.315-rt135-rc1.
Please scream at me if I messed something up. Please test the patches
too.
The -rc release is also available on kernel.org
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
on the
v4.19.315-rt135-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 6067da4c8c99..e3026053f01e 100644
Hello trace maintainers/developers,
This is a 31-day syzbot report for the trace subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/trace
During the period, 1 new issues were detected and 0 were fixed.
In total, 10 issues are still open and 35
On 2024-05-30 12:10:44 [+0100], Qais Yousef wrote:
> > This is not consistent because IMHO the clock setup & slack should be
> > handled equally. So I am asking the sched folks for a policy and I am
> > leaning towards looking at task-policy in this case instead of prio
> > because you shouldn't
On Fri, 31 May 2024 12:12:41 +0900
Masami Hiramatsu (Google) wrote:
> On Thu, 30 May 2024 22:30:57 -0400
> Steven Rostedt wrote:
>
> > On Fri, 24 May 2024 22:37:02 -0400
> > Steven Rostedt wrote:
> >
> > > From: "Steven Rostedt (VMware)"
> > >
> > > Allow for instances to have their own
62 matches
Mail list logo
