On 01/10/24 8:23 pm, Alexei Starovoitov wrote:
On Tue, Oct 1, 2024 at 12:18 AM Hari Bathini wrote:
On 30/09/24 6:25 pm, Alexei Starovoitov wrote:
On Sun, Sep 29, 2024 at 10:33 PM Hari Bathini wrote:
On 17/09/24 1:20 pm, Alexei Starovoitov wrote:
On Sun, Sep 15, 2024 at 10:58 PM Har
On Wed, Oct 02, 2024 at 10:11:14PM -0400, Steven Rostedt wrote:
> On Wed, 2 Oct 2024 18:31:17 -0700
> Alison Schofield wrote:
>
> > Hi Steve,
> >
> > Using 6.12-rc1 hitting this on every trace attempt.
> > Is this a known issue?
>
> No, but the backtrace looks funny.
>
Removing tp_printk from
Hi Nathan,
Thanks for your review! See some of my responses below inline. Other
comments, including those to [1/4] and [4/4], are acknowledged and will be
updated in v3.
On 2024-10-01 20:10, Nathan Chancellor wrote:
> ...
> > maximum value supported by Clang is 32767. According to local experimen
On Wed, 2 Oct 2024 18:31:17 -0700
Alison Schofield wrote:
> Hi Steve,
>
> Using 6.12-rc1 hitting this on every trace attempt.
> Is this a known issue?
No, but the backtrace looks funny.
>
> --Alison
>
> [ 110.689666] BUG: kernel NULL pointer dereference, address: 0058
> [ 110.6
Hi Steve,
Using 6.12-rc1 hitting this on every trace attempt.
Is this a known issue?
--Alison
[ 110.689666] BUG: kernel NULL pointer dereference, address: 0058
[ 110.691694] #PF: supervisor read access in kernel mode
[ 110.693058] #PF: error_code(0x) - not-present page
[ 110.
Due to an apparent copy-paste bug, the parisc implementation of
ftrace_disable_ftrace_graph_caller() doesn't actually do anything. It
enables the (already-enabled) static key rather than disabling it.
The result is that after function graph tracing has been "disabled", any
subsequent (non-graph)
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
Tested-by: Randy Dunlap # documenta
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
Tested-by: Randy Dunlap
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
Tested-by: Randy Dunlap # documentation bits
Sig
New percpu counters for counting various stats around multigrain
timestamp events, 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
- number of floor
Add some tracepoints around various multigrain timestamp events.
Reviewed-by: Josef Bacik
Reviewed-by: Darrick J. Wong
Reviewed-by: Jan Kara
Reviewed-by: Steven Rostedt (Google)
Tested-by: Randy Dunlap # documentation bits
Signed-off-by: Jeff Layton
---
fs/inode.c |
An update to the inode ctime typically requires the latest clock
value possible. 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 response, update the timestamp value in the
inode to the values th
The setattr codepath is still using coarse-grained timestamps, even on
multigrain filesystems. To fix this, 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 the ctime to
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
The mgtime_floor value is a global variable for tracking the latest
fine-grained timestamp handed out. Because it's a global, track the
number of times that a new floor value is assigned.
Add a new percpu counter to the timekeeping code to track the number of
floor swap events that have occurred.
Multigrain timestamps allow the kernel to use fine-grained timestamps
when an inode's attributes is being actively observed via ->getattr().
With this support, it's possible for a file to get a fine-grained
timestamp, and another modified after it to get a coarse-grained stamp
that is earlier than
ries
- Better separate timekeeping and fs changes
- add data_race annotations to per_cpu fetches
- get rid of pointless test for unsigned long to go negative
- better spacing for declarations and definitions in timekeeping_internal.h
- minor style cleanups
- Link to v9:
https://lore.kernel.org/r/20
On Wed, Oct 2, 2024 at 12:25 AM Oleg Nesterov wrote:
>
> On 10/01, Andrii Nakryiko wrote:
> >
> > +static struct uprobe *find_active_uprobe_speculative(unsigned long
> > bp_vaddr)
> > +{
> > + struct mm_struct *mm = current->mm;
> > + struct uprobe *uprobe = NULL;
> > + struct vm_area
Add debugging.rst to the relevant toctree to fix warning
about missing documentation inclusion in toctree.
Signed-off-by: SurajSonawane2415
---
Documentation/trace/index.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
index 0b
On Wed, Oct 02 2024 at 14:49, Jeff Layton wrote:
> ---
> fs/inode.c | 5 +++--
Grmbl. I explicitely asked to split this into timekeeping and fs
patches, no?
That allows me to pick the timekeeping patches up myself and give
Christian a stable tag to pull them from. That le
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
Tested-by: Randy Dunlap # documenta
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
Tested-by: Randy Dunlap
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
Tested-by: Randy Dunlap # documentation bits
Sig
The mgtime_floor value is a global variable for tracking the latest
fine-grained timestamp handed out. Because it's a global, track the
number of times that a new floor value is assigned.
Add a new percpu counter to the timekeeping code to track the number of
floor swap events that have occurred.
New percpu counters for counting various stats around multigrain
timestamp events, 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: Jose
Add some tracepoints around various multigrain timestamp events.
Reviewed-by: Josef Bacik
Reviewed-by: Darrick J. Wong
Reviewed-by: Jan Kara
Reviewed-by: Steven Rostedt (Google)
Tested-by: Randy Dunlap # documentation bits
Signed-off-by: Jeff Layton
---
fs/inode.c |
An update to the inode ctime typically requires the latest clock
value possible. 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 response, update the timestamp value in the
inode to the values th
The setattr codepath is still using coarse-grained timestamps, even on
multigrain filesystems. To fix this, 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 the ctime to
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
Multigrain timestamps allow the kernel to use fine-grained timestamps
when an inode's attributes is being actively observed via ->getattr().
With this support, it's possible for a file to get a fine-grained
timestamp, and another modified after it to get a coarse-grained stamp
that is earlier than
This is a replacement for the v6 series sitting in Christian's
vfs.mgtime branch. The main changes here are to the changelogs,
documentation and comments. The code itself is largely unchanged.
The pipe1_threads test shows these averages on my test rig with this
series:
v6.11:
On 10/2/2024 11:29, Steven Rostedt wrote:
> On Wed, 2 Oct 2024 11:06:41 -0400
> Steven Rostedt wrote:
>
>> I'm currently adding code where I need this patch too ;-)
>>
>> I can make a branch that only has this patch based off of v6.12-rc1 where
>> we can both use it. Can we do that?
>
> I tak
On Wed, 2 Oct 2024 11:06:41 -0400
Steven Rostedt wrote:
> I'm currently adding code where I need this patch too ;-)
>
> I can make a branch that only has this patch based off of v6.12-rc1 where
> we can both use it. Can we do that?
I take this back. I'm doing something a little different (updat
This is simple test and playground useful kstate subsystem development.
It contains some structure with different kind of data which migrated
across kexec to the new kernel using kstate.
Signed-off-by: Andrey Ryabinin
---
include/linux/kstate.h | 1 +
lib/Makefile | 2 +
lib/test_kst
This is a demonstration of kstate capabilities to migrate across
kexec something more complex rather than simple structure like
in the lib/test_kstate.c module.
Here we migrate tracing_on/current_trace and content of the
trace buffers to the new kernel
The 'global_trace_state' describes 'tracing_
This adds functionality to preserve memory pages across kexec.
kstate_register_page() stores struct page in the special list of
'struct page_state's. At kexec reboot stage this list iterated, pfns
saved into kstate's migrate stream. The new kernel after kexec reads
pfns from the stream and marks me
Add MEMBLOCK_PRSRV flag indicating that we don't need to initialize
'struct page' at all. The flag will be used in the following patches
to mark memory intended to be kept intact across kexec.
The 'struct page' for such region assumed to be initialized by the old
kernel, so the new one shouldn't to
Kstate changes data in kexec segments after the calculation
of the checksum, so we don't pass purgatroy verification stage.
Disable it for now. Proper solution will be later, in next versions of
the patchset.
Signed-off-by: Andrey Ryabinin
---
arch/x86/purgatory/purgatory.c | 2 ++
1 file chang
This is an early ugly hack just for now. Will be completely redone later.
This abuses crashkernel segment of memory for the kstate purposes to
save and restore object descriptions.
The proper solution probably would be using segments in ordinary kexec
mechanism, however since kstate requires such
kstate (kernel state) is a mechanism to describe internal kernel state
(partially), save it into the memory and restore the state after kexec
in new kernel.
The end goal here and the main use case for this is to be able to
update host kernel under VMs with VFIO pass-through devices running
on that
kstate (kernel state) is a mechanism to describe internal some part of the
kernel state, save it into the memory and restore the state after kexec
in the new kernel.
This is a very early RFC with a lot of hacks and cut corners with
the purpose to demonstrate the concept itself. Some parts
of this
On Thu, 3 Oct 2024 00:28:28 +0900
Tatsuya S wrote:
> > Tatsuya S wrote:
> >
> >> A extra entry is shown on stack trace(CONFIG_UNWINDER_ORC=y).
> >>
> >> [003] . 110.171589: vfs_write <-__x64_sys_write
> >> [003] . 110.171600:
> >> => X (Wrong function name)
> >
> > B
On 10/2/24 10:56 PM, Steven Rostedt wrote:
On Wed, 2 Oct 2024 14:13:48 +0900
Tatsuya S wrote:
A extra entry is shown on stack trace(CONFIG_UNWINDER_ORC=y).
[003] . 110.171589: vfs_write <-__x64_sys_write
[003] . 110.171600:
=> X (Wrong function name)
BTW, instead of
On Wed, Sep 11 2024 at 10:30, 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: Thomas G
On Wed, 02 Oct 2024 14:55:54 +
jeff@linux.dev wrote:
> September 10, 2024 at 9:36 PM, "Jeff Xie" wrote:
>
> Kindly ping...
Thanks for the reminder. It's in my queue so it should be picked up for 6.13.
https://patchwork.kernel.org/project/linux-trace-kernel/patch/20240910133620.19711
On Tue, 1 Oct 2024 18:12:26 +
Avadhut Naik wrote:
> From: Steven Rostedt
>
> When printing a dynamic array in a trace event, the method is rather ugly.
> It has the format of:
>
> __print_array(__get_dynamic_array(array),
> __get_dynmaic_array_len(array) / el_size, el_size)
>
September 10, 2024 at 9:36 PM, "Jeff Xie" wrote:
Kindly ping...
>
> When using both function tracer and function graph simultaneously,
>
> it is found that function tracer sometimes captures a fake parent ip
>
> (return_to_handler) instead of the true parent ip.
>
> This issue is easy to rep
On Tue, 1 Oct 2024 19:32:34 -0400
Steven Rostedt wrote:
> On Wed, 2 Oct 2024 08:10:37 +0900
> Masami Hiramatsu (Google) wrote:
> > >
> > > I may add some compiler hacks to enforce this. Something like:
> > >
> > > struct ftrace_regs {
> > > void *nothing_to_see_here;
> > > };
> >
> > Yeah
On Tue, Oct 01 2024 at 06:58, Jeff Layton wrote:
V8 ? I remember that I reviewed v* already :)
Also the sentence after the susbsystem prefix starts with an uppercase
letter.
> Multigrain timestamps allow the kernel to use fine-grained timestamps
> when an inode's attributes is being actively obs
On Wed, 2 Oct 2024 15:43:35 +0900
Tatsuya S wrote:
>
>
> On 10/1/24 10:47 PM, Steven Rostedt wrote:
> > On Tue, 1 Oct 2024 22:27:03 +0900
> > ts wrote:
> >
> >>> ...
> >>> sh-140 [001] ...1.18.352601: myevent:
> >>> (vfs_write+0x4/0x560)
> >>> sh-140
On Wed, 2 Oct 2024 14:13:48 +0900
Tatsuya S wrote:
> A extra entry is shown on stack trace(CONFIG_UNWINDER_ORC=y).
>
> [003] . 110.171589: vfs_write <-__x64_sys_write
> [003] . 110.171600:
> => X (Wrong function name)
BTW, instead of X'ing it out, can you show what that ex
On Tue, Oct 01, 2024 at 10:11:13AM -0700, Andrii Nakryiko wrote:
> On Tue, Oct 1, 2024 at 6:17 AM Jiri Olsa wrote:
> >
> > On Mon, Sep 30, 2024 at 02:36:08PM -0700, Andrii Nakryiko wrote:
> >
> > SNIP
> >
> > > > struct bpf_uprobe_multi_link {
> > > > @@ -3248,9 +3260,13 @@ uprobe_multi_link_hand
On Tue, 2024-10-01 at 14:45 +0200, Thomas Gleixner wrote:
> On Tue, Oct 01 2024 at 05:45, Jeff Layton wrote:
> > On Mon, 2024-09-30 at 23:35 +0200, Thomas Gleixner wrote:
> > > > I certainly wouldn't rule out a workqueue job calling that function,
> > > > but this is something we do while dirtying
On Wed, 2024-10-02 at 11:14 +0200, Jan Kara wrote:
> On Tue 01-10-24 09:34:18, Jeff Layton wrote:
> > On Tue, 2024-10-01 at 15:20 +0200, Jan Kara wrote:
> > > > diff --git a/fs/stat.c b/fs/stat.c
> > > > index 41e598376d7e..381926fb405f 100644
> > > > --- a/fs/stat.c
> > > > +++ b/fs/stat.c
> > > >
On Tue 01-10-24 09:34:18, Jeff Layton wrote:
> On Tue, 2024-10-01 at 15:20 +0200, Jan Kara wrote:
> > > diff --git a/fs/stat.c b/fs/stat.c
> > > index 41e598376d7e..381926fb405f 100644
> > > --- a/fs/stat.c
> > > +++ b/fs/stat.c
> > > @@ -26,6 +26,35 @@
> > > #include "internal.h"
> > > #include
On 10/01, Andrii Nakryiko wrote:
>
> +static struct uprobe *find_active_uprobe_speculative(unsigned long bp_vaddr)
> +{
> + struct mm_struct *mm = current->mm;
> + struct uprobe *uprobe = NULL;
> + struct vm_area_struct *vma;
> + struct file *vm_file;
> + loff_t offset;
> +
60 matches
Mail list logo
