On Wed, 1 Nov 2023 22:32:54 -0400
Steven Rostedt wrote:
> > Ouch! I thought the file descriptor has been hold by the opened process.
>
> Well, the struct *filp is, but not the filp->private that points to the
> struct trace_event_file *file.
That was supposed to be "struct file *filp"
--
On Thu, 2 Nov 2023 11:14:33 +0900
Masami Hiramatsu (Google) wrote:
> >
> > What happens here is that the kprobe event creates a trace_event_file
> > "file" descriptor that represents the file in tracefs to the event. It
> > maintains state of the event (is it enabled for the given instance?).
>
On Tue, 31 Oct 2023 12:24:53 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The following can crash the kernel:
>
> # cd /sys/kernel/tracing
> # echo 'p:sched schedule' > kprobe_events
> # exec 5>>events/kprobes/sched/enable
> # > kprobe_events
> # exec 5>&-
>
> The
On Wed, 01 Nov 2023 13:25:48 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The top level events directory is no longer special with regards to how it
> should be delete. Remove the extra processing for it in
> eventfs_set_ei_status_free().
>
Looks good to me.
Reviewed-by:
On Thu, 2023-11-02 at 09:16 +0800, Huang, Ying wrote:
> Vishal Verma writes:
>
[..]
> > +
> > +static int create_altmaps_and_memory_blocks(int nid, struct memory_group
> > *group,
> > + u64 start, u64 size)
> > +{
> > + unsigned long memblock_size
Vishal Verma writes:
> The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
> 'memblock_size' chunks of memory being added. Adding a larger span of
> memory precludes memmap_on_memory semantics.
>
> For users of hotplug such as kmem, large amounts of memory might get
> added from
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
tags/libnvdimm-for-6.7
... to get updates to the nvdimm tree. They are a mix of bug fixes and updates
to interfaces used by nvdimm.
Bug fixes include:
Fix a sleep during spinlock in
On Wed, 01 Nov 2023 13:25:46 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The callback function that is used to create inodes and dentries is not
> protected by anything and the data that is passed to it could become
> stale. After eventfs_remove_dir() is called by the
On Thu, 2 Nov 2023 08:43:32 +0900
Masami Hiramatsu (Google) wrote:
> On Tue, 31 Oct 2023 18:33:30 -0400
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > Now that inodes and dentries are created on the fly, they are also
> > reclaimed on memory pressure. Since the
On Tue, 31 Oct 2023 18:33:30 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Now that inodes and dentries are created on the fly, they are also
> reclaimed on memory pressure. Since the ownership and file mode are saved
> in the inode, if they are freed, any changes to the
The dax/kmem driver can potentially hot-add large amounts of memory
originating from CXL memory expanders, or NVDIMMs, or other 'device
memories'. There is a chance there isn't enough regular system memory
available to fit the memmap for this new memory. It's therefore
desirable, if all other
The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
'memblock_size' chunks of memory being added. Adding a larger span of
memory precludes memmap_on_memory semantics.
For users of hotplug such as kmem, large amounts of memory might get
added from the CXL subsystem. In some cases,
Large amounts of memory managed by the kmem driver may come in via CXL,
and it is often desirable to have the memmap for this memory on the new
memory itself.
Enroll kmem-managed memory for memmap_on_memory semantics if the dax
region originates via CXL. For non-CXL dax regions, retain the
A review of the memmap_on_memory modifications to add_memory_resource()
revealed an instance of an open-coded kmemdup(). Replace it with
kmemdup().
Cc: Andrew Morton
Cc: David Hildenbrand
Cc: Michal Hocko
Cc: Oscar Salvador
Cc: Dan Williams
Reported-by: Dan Williams
Reviewed-by: David
The following changes since commit 7d461b291e65938f15f56fe58da2303b07578a76:
Merge tag 'drm-next-2023-10-31-1' of git://anongit.freedesktop.org/drm/drm
(2023-11-01 06:28:35 -1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/
On Mon, 30 Oct 2023 21:57:13 +0530
Mukesh Ojha wrote:
> On 10/30/2023 9:45 PM, Steven Rostedt wrote:
> > From: "Steven Rostedt (Google)"
> >
> > The eventfs_remove_rec() had some missing parameters in the kerneldoc
> > comment above it. Also, rephrase the description a bit more to have a bit
>
On Wed, 1 Nov 2023 18:32:14 +0100
Jiri Olsa wrote:
> hi,
> I'm doing some testing on top of fprobes and noticed that the
> ftrace_test_recursion_trylock allows caller from the same context
> going through twice.
>
> The change below adds extra fprobe on stack_trace_print, which is
> called
hi,
I'm doing some testing on top of fprobes and noticed that the
ftrace_test_recursion_trylock allows caller from the same context
going through twice.
The change below adds extra fprobe on stack_trace_print, which is
called within the sample_entry_handler and I can see it being executed
with
From: "Steven Rostedt (Google)"
Looking at how dentry is removed via the tracefs system, I found that
eventfs does not do everything that it did under tracefs. The tracefs
removal of a dentry calls simple_recursive_removal() that does a lot more
than a simple d_invalidate().
As it should be a
From: "Steven Rostedt (Google)"
Now that inodes and dentries are created on the fly, they are also
reclaimed on memory pressure. Since the ownership and file mode are saved
in the inode, if they are freed, any changes to the ownership and mode
will be lost.
To counter this, if the user changes
From: "Steven Rostedt (Google)"
The callback function that is used to create inodes and dentries is not
protected by anything and the data that is passed to it could become
stale. After eventfs_remove_dir() is called by the tracing system, it is
free to remove the events that are associated to
From: "Steven Rostedt (Google)"
There exists a race between holding a reference of an eventfs_inode dentry
and the freeing of the eventfs_inode. If user space has a dentry held long
enough, it may still be able to access the dentry's eventfs_inode after it
has been freed.
To prevent this, have
From: "Steven Rostedt (Google)"
The eventfs_inode (ei) is protected by SRCU, but the ei->dentry is not. It
is protected by the eventfs_mutex. Anytime the eventfs_mutex is released,
and access to the ei->dentry needs to be done, it should first check if
ei->is_freed is set under the
From: "Steven Rostedt (Google)"
As the eventfs_inode is freed in two different locations, make a helper
function free_ei() to make sure all the allocated fields of the
eventfs_inode is freed.
This requires renaming the existing free_ei() which is called by the srcu
handler to free_rcu_ei() and
From: "Steven Rostedt (Google)"
The eventfs_inode->is_freed was a union with the rcu_head with the
assumption that when it was on the srcu list the head would contain a
pointer which would make "is_freed" true. But that was a wrong assumption
as the rcu head is a single link list where the last
From: "Steven Rostedt (Google)"
The top level events directory is no longer special with regards to how it
should be delete. Remove the extra processing for it in
eventfs_set_ei_status_free().
Cc: Ajay Kaher
Signed-off-by: Steven Rostedt (Google)
---
Changes since v5:
Changes since v5:
https://lore.kernel.org/all/20231031223326.794680...@goodmis.org/
This was originally based on:
[PATCH] eventfs: Process deletion of dentry more thoroughly
https://lore.kernel.org/linux-trace-kernel/20231031144703.71eef...@gandalf.local.home/
But Al Viro asked why I do
Hi Greg,
I see the following build warning / errors everywhere on stable-rc 5.15 branch.
ld.lld: error: undefined symbol: kallsyms_on_each_symbol
>>> referenced by trace_kprobe.c
>>> trace/trace_kprobe.o:(create_local_trace_kprobe) in archive
>>> kernel/built-in.a
>>> referenced
On Wed, 1 Nov 2023 at 20:38, Naresh Kamboju wrote:
>
> Hi Greg,
>
> I see the following build warning / errors everywhere on stable-rc 5.4 branch.
I am sorry,
It is on stable-rc 5.15.
>
> ld.lld: error: undefined symbol: kallsyms_on_each_symbol
> >>> referenced by trace_kprobe.c
> >>>
Hi Greg,
I see the following build warning / errors everywhere on stable-rc 5.4 branch.
ld.lld: error: undefined symbol: kallsyms_on_each_symbol
>>> referenced by trace_kprobe.c
>>> trace/trace_kprobe.o:(create_local_trace_kprobe) in archive
>>> kernel/built-in.a
>>> referenced by
On Wed, 1 Nov 2023 00:16:59 -0400
Steven Rostedt wrote:
> On Wed, 1 Nov 2023 02:25:53 +
> Al Viro wrote:
>
> > Umm... Is there any reason not to use simple_recursive_removal() there?
>
> Hmm, I may be able to (I'm still a newbie with understanding of the vfs).
>
> I did it this way
On 10/31/2023 10:36 PM, Neil Armstrong wrote:
Hi,
On 30/10/2023 14:10, Mukesh Ojha wrote:
On 10/30/2023 3:33 PM, Neil Armstrong wrote:
The current memory region assign only supports a single
memory region.
But new platforms introduces more regions to make the
memory requirements more
On Tue, 31 Oct 2023 18:33:28 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> As the eventfs_inode is freed in two different locations, make a helper
> function free_ei() to make sure all the allocated fields of the
> eventfs_inode is freed.
>
> This requires renaming the
On Tue, 31 Oct 2023 18:33:27 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> The eventfs_inode->is_freed was a union with the rcu_head with the
> assumption that when it was on the srcu list the head would contain a
> pointer which would make "is_freed" true. But that was a
Le 27/10/2023 à 17:56, Kees Cook a écrit :
Solve two ergonomic issues with struct seq_buf;
1) Too much boilerplate is required to initialize:
struct seq_buf s;
char buf[32];
seq_buf_init(s, buf, sizeof(buf));
Instead, we can build this directly on the stack. Provide
35 matches
Mail list logo
