[PATCH] in_kernel: Correct the grammatical errors in the comments

2024-09-13 Thread Ba Jing
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

Re: [PATCH v3 0/2] uprobes: Improve scalability by reducing the contention on siglock

2024-09-13 Thread Liao, Chang
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.

Re: [PATCH] uprobes: switch to RCU Tasks Trace flavor for better performance

2024-09-13 Thread Google
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

Re: [PATCH 09/13] KVM: arm64: Add clock for hyp tracefs

2024-09-13 Thread John Stultz
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

Re: [PATCH 06/13] KVM: arm64: Add clock support in the nVHE hyp

2024-09-13 Thread John Stultz
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

Re: [PATCH 04/13] timekeeping: Add the boot clock to system time snapshot

2024-09-13 Thread John Stultz
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

Re: [PATCH] uprobes: switch to RCU Tasks Trace flavor for better performance

2024-09-13 Thread Andrii Nakryiko
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

Re: [PATCH] function_graph: Simplify the initialization of fgraph LRU data

2024-09-13 Thread kernel test robot
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

Re: [PATCH 00/18] Introducing Core Building Blocks for Hyper-V VSM Emulation

2024-09-13 Thread Sean Christopherson
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

Re: [PATCH v7 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

2024-09-13 Thread John Stultz
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

Re: [PATCH 13/18] KVM: x86/mmu: Avoid warning when installing non-private memory attributes

2024-09-13 Thread Sean Christopherson
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

Re: [PATCH 11/18] KVM: x86: Pass the instruction length on memory fault user-space exits

2024-09-13 Thread Sean Christopherson
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

Re: [PATCH 10/18] KVM: x86: Keep track of instruction length during faults

2024-09-13 Thread Sean Christopherson
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

Re: [PATCH v7 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

2024-09-13 Thread Jeff Layton
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

Re: [PATCH v7 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

2024-09-13 Thread John Stultz
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

Re: [PATCH 05/18] KVM: x86: hyper-v: Introduce MP_STATE_HV_INACTIVE_VTL

2024-09-13 Thread Sean Christopherson
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

Re: [PATCH v7 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

2024-09-13 Thread John Stultz
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

Re: [PATCH 16/18] KVM: x86: Take mem attributes into account when faulting memory

2024-09-13 Thread Nicolas Saenz Julienne
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

Re: [PATCH 04/18] KVM: x86: hyper-v: Introduce VTL awareness to Hyper-V's PV-IPIs

2024-09-13 Thread Sean Christopherson
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

Re: [PATCH v3 7/8] execmem: add support for cache of large ROX pages

2024-09-13 Thread Ard Biesheuvel
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

Re: [PATCH RFC] block: trace: add block alignment information

2024-09-13 Thread John Garry
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

Re: [PATCH v7 05/11] fs: tracepoints around multigrain timestamp events

2024-09-13 Thread Jeff Layton
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

Re: [PATCH RFC] block: trace: add block alignment information

2024-09-13 Thread Daniel Gomez
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

[PATCH v7 11/11] tmpfs: add support for multigrain timestamps

2024-09-13 Thread Jeff Layton
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/

[PATCH v7 10/11] btrfs: convert to multigrain timestamps

2024-09-13 Thread Jeff Layton
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

[PATCH v7 09/11] ext4: switch to multigrain timestamps

2024-09-13 Thread Jeff Layton
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

[PATCH v7 08/11] xfs: switch to multigrain timestamps

2024-09-13 Thread Jeff Layton
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

[PATCH v7 07/11] Documentation: add a new file documenting multigrain timestamps

2024-09-13 Thread Jeff Layton
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

[PATCH v7 06/11] fs: add percpu counters for significant multigrain timestamp events

2024-09-13 Thread Jeff Layton
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

[PATCH v7 05/11] fs: tracepoints around multigrain timestamp events

2024-09-13 Thread Jeff Layton
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

[PATCH v7 04/11] fs: handle delegated timestamps in setattr_copy_mgtime

2024-09-13 Thread Jeff Layton
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

[PATCH v7 03/11] fs: have setattr_copy handle multigrain timestamps appropriately

2024-09-13 Thread Jeff Layton
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

[PATCH v7 02/11] fs: add infrastructure for multigrain timestamps

2024-09-13 Thread Jeff Layton
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

[PATCH v7 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper

2024-09-13 Thread Jeff Layton
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

[PATCH v7 00/11] fs: multigrain timestamp redux

2024-09-13 Thread Jeff Layton
| 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

Re: [Report] rtla: Failed to set runtime and/or period

2024-09-13 Thread Daniel Wagner
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

[PATCH v1] function_graph: Support recording and printing the function return address

2024-09-13 Thread Donglin Peng
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

Re: [PATCH RFC] block: trace: add block alignment information

2024-09-13 Thread John Garry
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

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Oleg Nesterov
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); >

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Oleg Nesterov
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, &

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Jiri Olsa
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

Re: [PATCH RFC] block: trace: add block alignment information

2024-09-13 Thread Daniel Gomez
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 >

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Oleg Nesterov
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

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Jiri Olsa
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

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Oleg Nesterov
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

Re: [PATCH RFC] block: trace: add block alignment information

2024-09-13 Thread John Garry
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

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Oleg Nesterov
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

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Jiri Olsa
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

Re: [PATCHv3 1/7] uprobe: Add support for session consumer

2024-09-13 Thread Jiri Olsa
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