On Tue, 30 Jan 2024 14:58:26 -0800
Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 14:55, Steven Rostedt wrote:
> >
> > Remember, the files don't have an ei allocated. Only directories.
>
> Crossed emails.
>
> > I then counted the length of the string - 7 bytes (which is the same as the
> > l
On Tue, 30 Jan 2024 at 14:56, Linus Torvalds
wrote:
>
> With that, the base size of 'struct eventfs_inode' actually becomes 96
> bytes for me.
It can be shrunk some more.
The field ordering is suboptimal. Pointers are 8 bytes and 8-byte
aligned, but 'struct kref' is just 4 bytes, and 'struct eve
On Tue, 30 Jan 2024 15:06:13 -0800
Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 14:56, Linus Torvalds
> wrote:
> >
> > With that, the base size of 'struct eventfs_inode' actually becomes 96
> > bytes for me.
>
> It can be shrunk some more.
>
> The field ordering is suboptimal. Pointers are
On Tue, 30 Jan 2024 at 15:10, Steven Rostedt wrote:
> >
> > At which point a name pointer would *just* fit in 96 bytes.
>
> Does that mean I should keep the kstrdup_const()?
You should check that my math matches reality and relevant
configurations, but yes, at 96 bytes that should fit exactly in
On Tue, Jan 30, 2024 at 11:03:52AM -0800, Linus Torvalds wrote:
> The dentry lookup for eventfs files was very broken, and had lots of
> signs of the old situation where the filesystem names were all created
> statically in the dentry tree, rather than being looked up dynamically
> based on the eve
On Tue, 30 Jan 2024 23:26:21 +
Al Viro wrote:
> On Tue, Jan 30, 2024 at 11:03:52AM -0800, Linus Torvalds wrote:
> > The dentry lookup for eventfs files was very broken, and had lots of
> > signs of the old situation where the filesystem names were all created
> > statically in the dentry tree
On Tue, Jan 30, 2024 at 06:55:36PM -0500, Steven Rostedt wrote:
> Actually it's the tracefs_start_creating() locks the inode, the
> eventfs_start_creating() doesn't.
Right.
> >
> > > if (unlikely(!inode))
> > > return eventfs_failed_creating(dentry);
> >
> > ... and that still un
On Tue, Jan 30, 2024 at 10:52:56PM +0800, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed
> "UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c" on:
>
> commit: 660787b56e6e97ddc34c7882cbe1228f4040ef74 ("overflow: Reintroduce
> signed and unsigned overflow sanitizers")
>
On Tue, Jan 30, 2024 at 11:03:52AM -0800, Linus Torvalds wrote:
> {
> struct eventfs_inode *ei;
>
> - mutex_lock(&eventfs_mutex);
> do {
> // The parent is stable because we do not do renames
> dentry = dentry->d_parent;
> @@ -247,7 +246,6 @@ static st
On Tue, 30 Jan 2024 at 16:23, Al Viro wrote:
>
> On Tue, Jan 30, 2024 at 11:03:52AM -0800, Linus Torvalds wrote:
> > {
> > struct eventfs_inode *ei;
> >
> > - mutex_lock(&eventfs_mutex);
> > do {
> > // The parent is stable because we do not do renames
> >
On Tue, Jan 30, 2024 at 11:03:54AM -0800, Linus Torvalds wrote:
> inode = tracefs_get_inode(dentry->d_sb);
> if (unlikely(!inode))
> - return eventfs_failed_creating(dentry);
> + return ERR_PTR(-ENOMEM);
That belongs in the lookup crapectomy patch - bisect haza
On Tue, Jan 30, 2024 at 11:03:55AM -0800, Linus Torvalds wrote:
> +void eventfs_d_release(struct dentry *dentry)
> {
> - struct eventfs_inode *ei;
> -
> - mutex_lock(&eventfs_mutex);
> - ei = dentry->d_fsdata;
> - if (ei) {
> - dentry->d_fsdata = NULL;
> -
hi, Kees,
On Tue, Jan 30, 2024 at 04:23:06PM -0800, Kees Cook wrote:
> On Tue, Jan 30, 2024 at 10:52:56PM +0800, kernel test robot wrote:
> >
...
> > while testing, we observed below different (and same part) between parent
> > and
> > this commit:
> >
> > ea804316c9db5148 660787b56e6e97ddc3
On Tue, 30 Jan 2024 09:39:44 -0600, Huang, Kai wrote:
+ * @lru: The LRU from which pages are reclaimed.
+ * @nr_to_scan: Pointer to the target number of pages to scan, must be
less
than
+ * SGX_NR_TO_SCAN.
+ * Return: Number of pages reclaimed.
*/
-static void sgx_rec
From: Linus Torvalds
The dentry lookup for eventfs files was very broken, and had lots of
signs of the old situation where the filesystem names were all created
statically in the dentry tree, rather than being looked up dynamically
based on the eventfs data structures.
You could see it in the na
On 1/30/2024 1:41 PM, Manivannan Sadhasivam wrote:
On Fri, Jan 05, 2024 at 05:53:03PM +0530, Krishna chaitanya chundru wrote:
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive dat
On 1/30/2024 11:56 PM, Manivannan Sadhasivam wrote:
On Tue, Jan 30, 2024 at 09:22:52AM -0500, Steven Rostedt wrote:
On Tue, 30 Jan 2024 13:41:52 +0530
Manivannan Sadhasivam wrote:
So same trace will get printed for both mhi_channel_command_start() and
mhi_channel_command_end()?
The trace
On Tue, 30 Jan 2024 09:22:14 -0600, Huang, Kai wrote:
struct sgx_epc_page *sgx_alloc_epc_page(void *owner, bool reclaim) {
+ struct sgx_epc_cgroup *epc_cg;
struct sgx_epc_page *page;
+ int ret;
+
+ epc_cg = sgx_get_current_epc_cg();
+ ret = sgx_epc_cgroup_try_c
On Tue, 30 Jan 2024 at 17:12, Al Viro wrote:
>
> > + *
> > + * Note that d_revalidate is called potentially under RCU,
> > + * so it can't take the eventfs mutex etc. It's fine - if
> > + * we open a file just as it's marked dead, things will
> > + * still work just fine, and just see the old stal
On Tue, Jan 30, 2024 at 11:52:48AM -0500, Mathieu Desnoyers wrote:
> Introduce a new dax_is_supported() static inline to check whether the
> architecture supports DAX.
>
> This replaces the following fs/Kconfig:FS_DAX dependency:
>
> depends on !(ARM || MIPS || SPARC)
>
> This is done in prepa
On Tue, Jan 30, 2024 at 06:37:49PM -0800, Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 17:12, Al Viro wrote:
> >
> > > + *
> > > + * Note that d_revalidate is called potentially under RCU,
> > > + * so it can't take the eventfs mutex etc. It's fine - if
> > > + * we open a file just as it's mark
On Tue, Jan 30, 2024 at 11:52:54AM -0500, Mathieu Desnoyers wrote:
> Introduce a generic way to query whether the dcache is virtually aliased
> on all architectures. Its purpose is to ensure that subsystems which
> are incompatible with virtually aliased data caches (e.g. FS_DAX) can
> reliably que
On Tue, Jan 30, 2024 at 7:53 PM Xuan Zhuo wrote:
>
> On Thu, 25 Jan 2024 18:19:12 +0800, Liang Chen
> wrote:
> > The RSS hash report is a feature that's part of the virtio specification.
> > Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
> > (still a work in progress as
On Tue, Jan 30, 2024 at 11:52:55AM -0500, Mathieu Desnoyers wrote:
> commit d92576f1167c ("dax: does not work correctly with virtual aliasing
> caches")
> prevents DAX from building on architectures with virtually aliased
> dcache with:
>
> depends on !(ARM || MIPS || SPARC)
>
> This check is
Dave Chinner wrote:
> On Tue, Jan 30, 2024 at 11:52:55AM -0500, Mathieu Desnoyers wrote:
> > commit d92576f1167c ("dax: does not work correctly with virtual aliasing
> > caches")
> > prevents DAX from building on architectures with virtually aliased
> > dcache with:
> >
> > depends on !(ARM ||
On 1/30/24 17:27, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 10:04:02AM +0530, Anshuman Khandual wrote:
>>
>>
>> On 1/29/24 17:16, Alexandru Elisei wrote:
>>> Hi,
>>>
>>> On Mon, Jan 29, 2024 at 02:31:23PM +0530, Anshuman Khandual wrote:
On 1/25/24 22:12, Alexandru
On Tue, 30 Jan 2024 at 18:46, Al Viro wrote:
>
> What's to stop ->d_revalidate() from being called in parallel with
> __dentry_kill()?
Oh, you're right.
For some reason I thought we did the d_release() _after_ the RCU grace
period, but we don't.
Why don't we, btw? It would be so much better if
The RSS hash report is a feature that's part of the virtio specification.
Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
(still a work in progress as per [1]) support this feature. While the
capability to obtain the RSS hash has been enabled in the normal path,
it's curren
From: "Steven Rostedt (Google)"
eventfs uses the tracefs_inode and assumes that it's already initialized
to zero. That is, it doesn't set fields to zero (like ti->private) after
getting its tracefs_inode. This causes bugs due to stale values.
Just initialize the entire structure to zero on alloc
This change adds ftrace support for following functions which
helps in debugging the issues when there is Channel state & MHI
state change and also when we receive data and control events:
1. mhi_intvec_mhi_states
2. mhi_process_data_event_ring
3. mhi_process_ctrl_ev_ring
4. mhi_gen_tre
5. mhi_upda
On Tue, Jan 30, 2024 at 07:39:55PM -0800, Linus Torvalds wrote:
> Why don't we, btw? It would be so much better if we did the
> d_release() from __d_free(). We have all that smarts in fs/dcache.c to
> decide if we need to RCU-delay it or not, and then we don't let
> filesystems use it.
Because we
On 1/30/24 17:28, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 10:22:11AM +0530, Anshuman Khandual wrote:
>>
>> On 1/29/24 17:21, Alexandru Elisei wrote:
>>> Hi,
>>>
>>> On Mon, Jan 29, 2024 at 02:54:20PM +0530, Anshuman Khandual wrote:
On 1/25/24 22:12, Alexandru Elisei
On Tue, 30 Jan 2024 11:03:54 -0800
Linus Torvalds wrote:
> +/*
> + * eventfs_inode reference count management.
> + *
> + * NOTE! We count only references from dentries, in the
> + * form 'dentry->d_fsdata'. There are also references from
> + * directory inodes ('ti->private'), but the dentry refe
On Tue, 30 Jan 2024 at 21:09, Steven Rostedt wrote:
>
> I would think that the last "put" would always have the "is_freed" set. The
> WARN_ON is to catch things doing too many put_ei().
Yes, that looks sane to me.
> > + simple_recursive_removal(dentry, NULL);
>
> Actually, this doesn't work.
On Tue, 30 Jan 2024 21:25:30 -0800
Linus Torvalds wrote:
> > Does this work:
> >
> > d_invalidate(dentry);
>
> It does, but it's basically irrelevant with the d_revalidate approach.
>
> Basically, once you have d_revalidate(), the unhashing happens there,
> and it's just extra work an
On Tue, 30 Jan 2024 at 21:33, Steven Rostedt wrote:
>
> With even the last patch included, without the d_invalidate() I get errors
> with simply doing:
>
> # cd /sys/kernel/tracing
> # mkdir instances/foo
> # ls instances/foo/events
> # rmdir instances/foo
>
> As the rmdir calls tracefs_remove
On 1/29/24 17:23, Alexandru Elisei wrote:
> Hi,
>
> On Mon, Jan 29, 2024 at 03:01:24PM +0530, Anshuman Khandual wrote:
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> Similar to the two events that relate to CMA allocations, add the
>>> CMA_RELEASE_SUCCESS and CMA_RELEASE_FAIL events that c
On Tue, 30 Jan 2024 at 21:57, Linus Torvalds
wrote:
>
> Ugh.
Oh, and double-ugh on that tracefs_syscall_mkdir/rmdir(). I hate how
it does that "unlock and re-lock inode" thing.
It's a disease, and no, it's not an acceptable response to "lockdep
shows there's a locking problem".
The comment says
On 1/30/24 17:05, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 10:50:00AM +0530, Anshuman Khandual wrote:
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> Today, cma_alloc() is used to allocate a contiguous memory region. The
>>> function allows the caller to specify the number
This is a tiny fix to pfn_to_virt() for some platforms.
The original implementaion of pfn_to_virt() takes PFN instead of PA as the
input to macro __va, with PAGE_SHIFT applying to the converted VA, which
is not right under most conditions, especially when there's an offset in
__va.
Yan Zhao (4):
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: 2d78057f0dd4 ("asm-generic/page.h: Make pfn accessors static inlines")
Signed-off-by: Yan Zhao
---
include/asm-generic/page.h | 2 +-
1 file changed, 1 in
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: c1884e1e1164 ("csky: Make pfn accessors static inlines")
Signed-off-by: Yan Zhao
---
arch/csky/include/asm/page.h | 2 +-
1 file changed, 1 insertion(+),
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: d6e81532b10d ("Hexagon: Make pfn accessors statics inlines")
Signed-off-by: Yan Zhao
---
arch/hexagon/include/asm/page.h | 2 +-
1 file changed, 1 inserti
Apply the page shift to PFN to get physical address for final VA.
The macro __va should take physical address instead of PFN as input.
Fixes: 232ba1630c66 ("openrisc: Make pfn accessors statics inlines")
Signed-off-by: Yan Zhao
---
arch/openrisc/include/asm/page.h | 2 +-
1 file changed, 1 inser
gt; On Thu, Dec 21, 2023 at 10:02:46AM +0100, Christophe Leroy wrote:
>>>>>> Declaring rodata_enabled and mark_rodata_ro() at all time
>>>>>> helps removing related #ifdefery in C files.
>>>>>>
>>>>>> Signed-off-by: Christophe Leroy
>
On 1/30/24 17:04, Alexandru Elisei wrote:
> Hi,
>
> On Tue, Jan 30, 2024 at 03:25:20PM +0530, Anshuman Khandual wrote:
>>
>> On 1/25/24 22:12, Alexandru Elisei wrote:
>>> arm64 uses VM_HIGH_ARCH_0 and VM_HIGH_ARCH_1 for enabling MTE for a VMA.
>>> When VM_HIGH_ARCH_0, which arm64 renames to VM_
On Wed, Jan 31, 2024 at 7:25 AM Yan Zhao wrote:
> This is a tiny fix to pfn_to_virt() for some platforms.
>
> The original implementaion of pfn_to_virt() takes PFN instead of PA as the
> input to macro __va, with PAGE_SHIFT applying to the converted VA, which
> is not right under most conditions,
101 - 147 of 147 matches
Mail list logo
