The form of "print" should be consistent with "parses".
Signed-off-by: Ba Jing
---
tools/verification/rv/src/in_kernel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/verification/rv/src/in_kernel.c
b/tools/verification/rv/src/in_kernel.c
index f04479ecc96c..f2bb
Hi, Oleg
Kindly ping.
This series have been pending for a month. Is thre any issue I overlook?
Thanks.
在 2024/8/15 9:46, Liao Chang 写道:
> The profiling result of BPF selftest on ARM64 platform reveals the
> significant contention on the current->sighand->siglock is the
> scalability bottleneck.
On Tue, 10 Sep 2024 10:43:12 -0700
Andrii Nakryiko wrote:
> This patch switches uprobes SRCU usage to RCU Tasks Trace flavor, which
> is optimized for more lightweight and quick readers (at the expense of
> slower writers, which for uprobes is a fine tradeof) and has better
> performance and scal
On Wed, Sep 11, 2024 at 2:31 AM Vincent Donnefort wrote:
>
> Configure the hypervisor tracing clock before starting tracing. For
> tracing purpose, the boot clock is interesting as it doesn't stop on
> suspend. However, it is corrected on a regular basis, which implies we
> need to re-evaluate it
On Wed, Sep 11, 2024 at 2:31 AM 'Vincent Donnefort' via kernel-team
wrote:
>
> By default, the arm64 host kernel is using the arch timer as a source
> for sched_clock. Conveniently, EL2 has access to that same counter,
> allowing to generate clock values that are synchronized.
>
> The clock needs
On Wed, Sep 11, 2024 at 2:30 AM Vincent Donnefort wrote:
>
> For tracing purpose, the boot clock is interesting as it doesn't stop on
> suspend. Export it as part of the time snapshot. This will later allow
> the hypervisor to add boot clock timestamps to its events.
>
> Cc: John Stultz
> Cc: Tho
On Tue, Sep 10, 2024 at 10:43 AM Andrii Nakryiko wrote:
>
> This patch switches uprobes SRCU usage to RCU Tasks Trace flavor, which
> is optimized for more lightweight and quick readers (at the expense of
> slower writers, which for uprobes is a fine tradeof) and has better
> performance and scala
Hi Liao,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.11-rc7 next-20240913]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as doc
On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:
> This series introduces core KVM functionality necessary to emulate Hyper-V's
> Virtual Secure Mode in a Virtual Machine Monitor (VMM).
...
> As discussed at LPC2023 and in our previous RFC [2], we decided to model each
> VTL as a distinct KVM
On Fri, Sep 13, 2024 at 12:06 PM Jeff Layton wrote:
> On Fri, 2024-09-13 at 11:59 -0700, John Stultz wrote:
> > > +/**
> > > + * ktime_get_real_ts64_mg - attempt to update floor value and return
> > > result
> > > + * @ts:pointer to the timespec to be set
> > > + * @cookie:opa
On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:
> In preparation to introducing RWX memory attributes, make sure
> user-space is attempting to install a memory attribute with
> KVM_MEMORY_ATTRIBUTE_PRIVATE before throwing a warning on systems with
> no private memory support.
>
> Signed-off-by
On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:
> In order to simplify Hyper-V VSM secure memory intercept generation in
> user-space (it avoids the need of implementing an x86 instruction
> decoder and the actual decoding). Pass the instruction length being run
> at the time of the guest exit
On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:
> Both VMX and SVM provide the length of the instruction
> being run at the time of the page fault. Save it within 'struct
> kvm_page_fault', as it'll become useful in the future.
Nit, please wrap closer to 75 characters.
> Signed-off-by: Nicola
On Fri, 2024-09-13 at 11:59 -0700, John Stultz wrote:
> On Fri, Sep 13, 2024 at 6:54 AM Jeff Layton wrote:
> >
> > For multigrain timestamps, we must keep track of the latest timestamp
> > that has ever been handed out, and never hand out a coarse time below
> > that value.
> >
> > Add a static
On Fri, Sep 13, 2024 at 11:59 AM John Stultz wrote:
>
> On Fri, Sep 13, 2024 at 6:54 AM Jeff Layton wrote:
> >
> > For multigrain timestamps, we must keep track of the latest timestamp
> > that has ever been handed out, and never hand out a coarse time below
> > that value.
> >
> > Add a static s
On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:
> Model inactive VTL vCPUs' behaviour with a new MP state.
>
> Inactive VTLs are in an artificial halt state. They enter into this
> state in response to invoking HvCallVtlCall, HvCallVtlReturn.
> User-space, which is VTL aware, can processes the
On Fri, Sep 13, 2024 at 6:54 AM Jeff Layton wrote:
>
> For multigrain timestamps, we must keep track of the latest timestamp
> that has ever been handed out, and never hand out a coarse time below
> that value.
>
> Add a static singleton atomic64_t into timekeeper.c that we can use to
> keep track
On Thu Aug 22, 2024 at 4:58 PM UTC, Sean Christopherson wrote:
> On Thu, Aug 22, 2024, Nicolas Saenz Julienne wrote:
> > On Sun Jun 9, 2024 at 3:49 PM UTC, Nicolas Saenz Julienne wrote:
> > > Take into account access restrictions memory attributes when faulting
> > > guest memory. Prohibited memory
On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:
> HvCallSendSyntheticClusterIpi and HvCallSendSyntheticClusterIpiEx allow
> sending VTL-aware IPIs. Honour the hcall by exiting to user-space upon
> receiving a request with a valid VTL target. This behaviour is only
> available if the VSM CPUID f
Hi Mike,
On Mon, 9 Sept 2024 at 08:51, Mike Rapoport wrote:
>
> From: "Mike Rapoport (Microsoft)"
>
> Using large pages to map text areas reduces iTLB pressure and improves
> performance.
>
> Extend execmem_alloc() with an ability to use huge pages with ROX
> permissions as a cache for smaller a
On 13/09/2024 14:57, Daniel Gomez wrote:
I am just saying that the information already present in the block trace
point can be used to get this "alignment" info, right? And userspace can do
the work of reading those trace events to find this "alignment" info.
So, maybe this is better to have int
On Fri, 2024-09-13 at 09:54 -0400, Jeff Layton wrote:
> Add some tracepoints around various multigrain timestamp events.
>
> Reviewed-by: Josef Bacik
> Reviewed-by: Darrick J. Wong
> Reviewed-by: Jan Kara
> Signed-off-by: Jeff Layton
> ---
> fs/inode.c | 6 ++
> fs/sta
On Fri, Sep 13, 2024 at 01:08:34PM +0100, John Garry wrote:
> On 13/09/2024 12:26, Daniel Gomez wrote:
> > On Fri, Sep 13, 2024 at 09:59:08AM +0100, John Garry wrote:
> > > On 12/09/2024 21:48, Daniel Gomez via B4 Relay wrote:
> > > > From: Daniel Gomez
> > > >
> > > > Report block alignment in t
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
tmpfs only requires the FS_MGTIME flag.
Reviewed-by: Josef Bacik
Reviewed-by: Jan Kara
Signed-off-by: Jeff Layton
---
mm/
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
Beyond enabling the FS_MGTIME flag, this patch eliminates
update_time_for_write, which goes to great pains to avoid in-memory
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
For ext4, we only need to enable the FS_MGTIME flag.
Reviewed-by: Josef Bacik
Reviewed-by: Jan Kara
Signed-off-by: Jeff Lay
Enable multigrain timestamps, which should ensure that there is an
apparent change to the timestamp whenever it has been written after
being actively observed via getattr.
Also, anytime the mtime changes, the ctime must also change, and those
are now the only two options for xfs_trans_ichgtime. Ha
Add a high-level document that describes how multigrain timestamps work,
rationale for them, and some info about implementation and tradeoffs.
Reviewed-by: Josef Bacik
Reviewed-by: Darrick J. Wong
Reviewed-by: Randy Dunlap
Reviewed-by: Jan Kara
Signed-off-by: Jeff Layton
---
Documentation/fi
New percpu counters for counting various stats around mgtimes, and a new
debugfs file for displaying them when CONFIG_DEBUG_FS is enabled:
- number of attempted ctime updates
- number of successful i_ctime_nsec swaps
- number of fine-grained timestamp fetches
Reviewed-by: Josef Bacik
Reviewed-by
Add some tracepoints around various multigrain timestamp events.
Reviewed-by: Josef Bacik
Reviewed-by: Darrick J. Wong
Reviewed-by: Jan Kara
Signed-off-by: Jeff Layton
---
fs/inode.c | 6 ++
fs/stat.c| 3 +
include/trace/events/timestamp.h | 1
When updating the ctime on an inode for a SETATTR with a multigrain
filesystem, we usually want to take the latest time we can get for the
ctime. The exception to this rule is when there is a nfsd write
delegation and the server is proxying timestamps from the client.
When nfsd gets a CB_GETATTR r
The setattr codepath is still using coarse-grained timestamps, even on
multigrain filesystems. To fix this, we need to fetch the timestamp for
ctime updates later, at the point where the assignment occurs in
setattr_copy.
On a multigrain inode, ignore the ia_ctime in the attrs, and always
update t
The VFS has always used coarse-grained timestamps when updating the
ctime and mtime after a change. This has the benefit of allowing
filesystems to optimize away a lot metadata updates, down to around 1
per jiffy, even when a file is under heavy writes.
Unfortunately, this has always been an issue
For multigrain timestamps, we must keep track of the latest timestamp
that has ever been handed out, and never hand out a coarse time below
that value.
Add a static singleton atomic64_t into timekeeper.c that we can use to
keep track of the latest fine-grained time ever handed out. This is
tracked
| 4 +
include/trace/events/timestamp.h| 124 +
kernel/time/timekeeping.c | 81 +
mm/shmem.c | 2 +-
16 files changed, 717 insertions(+), 73 deletions(-)
---
base-commit: da3ea35007d0af457a0afc87e84fdd
On Thu, Sep 12, 2024 at 06:58:02PM GMT, Muhammad Usama Anjum wrote:
> We are running rt-tests on KernelCI. I'm looking at failures and I found
> out that rtla osnoise and rtla timerlat are failing. We have just
> enabled these tests and they are failing from day one.
Thanks a lot on working on thi
When using function_graph tracer to analyze the flow of kernel function
execution, it is often necessary to quickly locate the exact line of code
where the call occurs. While this may be easy at times, it can be more
time-consuming when some functions are inlined or the flow is too long.
This feat
On 13/09/2024 12:26, Daniel Gomez wrote:
On Fri, Sep 13, 2024 at 09:59:08AM +0100, John Garry wrote:
On 12/09/2024 21:48, Daniel Gomez via B4 Relay wrote:
From: Daniel Gomez
Report block alignment in terms of LBA and size during block tracing for
block_rq. Calculate alignment only for read/wr
On 09/09, Jiri Olsa wrote:
>
> @@ -37,13 +37,16 @@ struct uprobe_consumer {
>* for the current process. If filter() is omitted or returns true,
>* UPROBE_HANDLER_REMOVE is effectively ignored.
>*/
> - int (*handler)(struct uprobe_consumer *self, struct pt_regs *regs);
>
On 09/13, Jiri Olsa wrote:
>
> On Fri, Sep 13, 2024 at 12:57:51PM +0200, Oleg Nesterov wrote:
>
> > static void handler_chain(struct uprobe *uprobe, struct pt_regs *regs)
> > {
> > ...
> > struct return_instance *ri = NULL;
> > int push_idx = 0;
> >
> > list_for_each_entry_rcu(uc, &
On Fri, Sep 13, 2024 at 12:57:51PM +0200, Oleg Nesterov wrote:
> On 09/13, Jiri Olsa wrote:
> >
> > I'm not sure the realloc will help, I feel like we need to allocate return
> > consumer for each called handler separately to be safe
>
> How about something like the (pseudo) code below? Note that
On Fri, Sep 13, 2024 at 09:59:08AM +0100, John Garry wrote:
> On 12/09/2024 21:48, Daniel Gomez via B4 Relay wrote:
> > From: Daniel Gomez
> >
> > Report block alignment in terms of LBA and size during block tracing for
> > block_rq. Calculate alignment only for read/writes where the length is
>
On 09/13, Jiri Olsa wrote:
>
> I'm not sure the realloc will help, I feel like we need to allocate return
> consumer for each called handler separately to be safe
How about something like the (pseudo) code below? Note that this way
we do not need uprobe->consumers_cnt. Note also that krealloc() sh
On Fri, Sep 13, 2024 at 11:32:01AM +0200, Oleg Nesterov wrote:
> On 09/13, Jiri Olsa wrote:
> >
> > On Thu, Sep 12, 2024 at 06:35:39PM +0200, Oleg Nesterov wrote:
> > > > list_for_each_entry_srcu(uc, &uprobe->consumers, cons_node,
> > > > srcu_read_lock_held
On 09/13, Jiri Olsa wrote:
>
> On Thu, Sep 12, 2024 at 06:20:29PM +0200, Oleg Nesterov wrote:
> > > +
> > > + if (rc == 0 && uc->ret_handler) {
> >
> > should we enter this block if uc->handler == NULL?
>
> yes, consumer can have just ret_handler defined
Sorry, I meant we do not need to pu
On 12/09/2024 21:48, Daniel Gomez via B4 Relay wrote:
From: Daniel Gomez
Report block alignment in terms of LBA and size during block tracing for
block_rq. Calculate alignment only for read/writes where the length is
greater than 0. Otherwise, report 0 to indicate no alignment calculated.
Sugg
On 09/13, Jiri Olsa wrote:
>
> On Thu, Sep 12, 2024 at 06:35:39PM +0200, Oleg Nesterov wrote:
> > > list_for_each_entry_srcu(uc, &uprobe->consumers, cons_node,
> > >srcu_read_lock_held(&uprobes_srcu)) {
> > > + /*
> > > + * If we don't find return cons
On Thu, Sep 12, 2024 at 06:35:39PM +0200, Oleg Nesterov wrote:
> On 09/09, Jiri Olsa wrote:
> >
> > handle_uretprobe_chain(struct return_instance *ri, struct pt_regs *regs)
> > {
> > + struct return_consumer *ric = NULL;
> > struct uprobe *uprobe = ri->uprobe;
> > struct uprobe_consumer
On Thu, Sep 12, 2024 at 06:20:29PM +0200, Oleg Nesterov wrote:
> On 09/09, Jiri Olsa wrote:
> >
> > static void handler_chain(struct uprobe *uprobe, struct pt_regs *regs)
> > {
> > struct uprobe_consumer *uc;
> > int remove = UPROBE_HANDLER_REMOVE;
> > - bool need_prep = false; /* prepa
49 matches
Mail list logo