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,
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_
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
>
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
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: 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: 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
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):
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
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/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: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 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: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 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 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, 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
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
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
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
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
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
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 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
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: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 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: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, 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, 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 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 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
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 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
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, 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;
> -
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, 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: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, 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 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, 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 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 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, 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 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 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: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
> length of the string plus the '\0' character - 8 bytes) to accommodate the
> p
On Tue, 30 Jan 2024 at 13:52, Linus Torvalds
wrote:
>
> Btw, you can look at name lengths in tracefs with something stupid like this:
>
> find . | sed 's:^.*/::' | tr -c '\n' . | sort | uniq -c
Actually, since only directories have these 'ei' fields, that find
should have "-type d", and then
On Tue, 30 Jan 2024 13:52:05 -0800
Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 12:55, Steven Rostedt wrote:
> >
> > I'm going to be putting back the ei->name pointer as the above actually
> > adds more memory usage.
>
> I did it mainly because I hate having multiple different allocation
>
On Tue, Jan 30, 2024 at 01:52:30PM -0500, Steven Rostedt wrote:
> On Tue, 30 Jan 2024 10:05:15 -0800
> Beau Belgrave wrote:
>
> > On Mon, Jan 29, 2024 at 09:24:07PM -0500, Steven Rostedt wrote:
> > > On Mon, 29 Jan 2024 09:29:07 -0800
> > > Beau Belgrave wrote:
> > >
> > > > Thanks, yeah idea
On Tue, 30 Jan 2024 at 12:55, Steven Rostedt wrote:
>
> I'm going to be putting back the ei->name pointer as the above actually
> adds more memory usage.
I did it mainly because I hate having multiple different allocation
sites that then have to do that kref_init() etc individually, and once
ther
On Tue 30-01-24 11:52:50, Mathieu Desnoyers wrote:
> Use dax_is_supported() to validate whether the architecture has
> virtually aliased data caches at mount time. Print an error and disable
> DAX if dax=always is requested as a mount option on an architecture
> which does not support DAX.
>
> Thi
On Tue, 30 Jan 2024 at 13:25, Steven Rostedt wrote:
>
> I actually find the dentry's sticking around when their ref counts go to
> zero a feature. Tracing applications will open and close the eventfs files
> many times. If the dentry were to be deleted on every close, it would need
> to be create
On Tue, 30 Jan 2024 11:03:55 -0800
Linus Torvalds wrote:
> Another thing that might be worth doing is to make all eventfs lookups
> mark their dentries as not worth caching. We could do that with
> d_delete(), but the DCACHE_DONTCACHE flag would likely be even better.
>
> As it is, the dentries
On Tue, 30 Jan 2024 11:03:54 -0800
Linus Torvalds wrote:
> -static void free_ei(struct eventfs_inode *ei)
> +static inline struct eventfs_inode *alloc_ei(const char *name)
> {
> - kfree_const(ei->name);
> - kfree(ei->d_children);
> - kfree(ei->entry_attrs);
> - kfree(ei);
> +
On Tue, Jan 30, 2024 at 08:36:14PM +0100, Marco Pagani wrote:
> The current implementation of try_module_get() requires the module to
> exist and be live as a precondition. While this may seem intuitive at
> first glance, enforcing the precondition can be tricky, considering that
> modules can be u
On 1/17/24 12:58 PM, Mathieu Poirier wrote:
> Alright, I spent several hours looking at this patchset and the driver as a
> whole. I certainly salute your efforts to heed my advice and make the code
> less
> brittle but I'm afraid we are not there.
Hi Mathieu,
I am back from vacation. Started
Declaring rodata_enabled and mark_rodata_ro() at all time
> >>>> helps removing related #ifdefery in C files.
> >>>>
> >>>> Signed-off-by: Christophe Leroy
> >>> Very nice cleanup, thanks!, applied and pushed
> >>>
> >>>
From: Linus Torvalds
The tracefs-specific fields in the inode were not initialized before the
inode was exposed to others through the dentry with 'd_instantiate()'.
Move the field initializations up to before the d_instantiate.
Cc: sta...@vger.kernel.org
Fixes: 5790b1fb3d672 ("eventfs: Remove e
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
On Tue, 30 Jan 2024 11:54:56 -0800
Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 11:37, Steven Rostedt wrote:
> >
> > Do you want me to put this in my urgent branch and mark them for stable,
> > and then send them for 6.8?
>
> Hmm. I think the only one that fixes a _reported_ bug is that [PT
On Tue, 30 Jan 2024 14:48:02 -0500
Steven Rostedt wrote:
> The ti is allocated from fs/tracefs/inode.c that has:
>
> static struct inode *tracefs_alloc_inode(struct super_block *sb)
> {
> struct tracefs_inode *ti;
>
> ti = kmem_cache_alloc(tracefs_inode_cachep, GFP_KERNEL);
I coul
On Tue, 30 Jan 2024 at 11:37, Steven Rostedt wrote:
>
> Do you want me to put this in my urgent branch and mark them for stable,
> and then send them for 6.8?
Hmm. I think the only one that fixes a _reported_ bug is that [PTCH
2/6]. And it turns out that while 'ti->private' really is entirely
uni
On Tue, 30 Jan 2024 11:03:51 -0800
Linus Torvalds wrote:
> @@ -328,7 +328,9 @@ static struct dentry *create_file(const char *name,
> umode_t mode,
> inode->i_ino = EVENTFS_FILE_INODE_INO;
>
> ti = get_tracefs(inode);
> - ti->flags |= TRACEFS_EVENT_INODE;
> + ti->flags = TRA
On Tue, 30 Jan 2024 11:03:51 -0800
Linus Torvalds wrote:
> The tracefs-specific fields in the inode were not initialized before the
> inode was exposed to others through the dentry with 'd_instantiate()'.
>
> And the ->flags file was initialized incorrectly with a '|=', when the
> old value was
On Tue, 30 Jan 2024 11:19:01 -0800
Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 10:23, Steven Rostedt wrote:
> >
> > I know you don't send patches inlined anymore, which is a shame, because
> > patchwork takes care of all the administering when patches are inlined, and
> > I don't miss patches
The current implementation of try_module_get() requires the module to
exist and be live as a precondition. While this may seem intuitive at
first glance, enforcing the precondition can be tricky, considering that
modules can be unloaded at any time if not previously taken. For
instance, the caller
Hi!
We (as in cip project), are trying to do -cip-rt releases
once a month. Are there any plans for 5.10-rt release any time soon?
That would help us ;-).
Best regards,
Pavel
--
DENX Software Engineering GmbH,Managing Direct
On Tue, 30 Jan 2024 at 10:23, Steven Rostedt wrote:
>
> I know you don't send patches inlined anymore, which is a shame, because
> patchwork takes care of all the administering when patches are inlined, and
> I don't miss patches like I use to.
I just sent the whole series as individual patches.,
In order for the dentries to stay up-to-date with the eventfs changes,
just add a 'd_revalidate' function that checks the 'is_freed' bit.
Also, clean up the dentry release to actually use d_release() rather
than the slightly odd d_iput() function. We don't care about the inode,
all we want to do
The eventfs inode had pointers to dentries (and child dentries) without
actually holding a refcount on said pointer. That is fundamentally
broken, and while eventfs tried to then maintain coherence with dentries
going away by hooking into the '.d_iput' callback, that doesn't actually
work since it
It's never used
Signed-off-by: Linus Torvalds
---
fs/tracefs/event_inode.c | 4 +---
fs/tracefs/internal.h| 2 --
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index ad11063bdd53..1d0102bfd7da 100644
--- a/fs/tracefs/event_i
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 naming - how it claimed t
The tracefs-specific fields in the inode were not initialized before the
inode was exposed to others through the dentry with 'd_instantiate()'.
And the ->flags file was initialized incorrectly with a '|=', when the
old value was stale. It should have just been a straight assignment.
Move the fie
The eventfs_find_events() code tries to walk up the tree to find the
event directory that a dentry belongs to, in order to then find the
eventfs inode that is associated with that event directory.
However, it uses an odd combination of walking the dentry parent,
looking up the eventfs inode associ
On Tue, 30 Jan 2024 10:05:15 -0800
Beau Belgrave wrote:
> On Mon, Jan 29, 2024 at 09:24:07PM -0500, Steven Rostedt wrote:
> > On Mon, 29 Jan 2024 09:29:07 -0800
> > Beau Belgrave wrote:
> >
> > > Thanks, yeah ideally we wouldn't use special characters.
> > >
> > > I'm not picky about this. H
On Mon, 29 Jan 2024 19:56:52 -0800
Linus Torvalds wrote:
> [0001-tracefs-avoid-using-the-ei-dentry-pointer-unnecessar.patch
> text/x-patch (3561 bytes)]
>
> [0002-eventfsfs-initialize-the-tracefs-inode-properly.patch text/x-patch
> (2548 bytes)]
Ah these two are new.
-- Steve
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 output will also include the tracepoint n
On Tue, Jan 30, 2024 at 11:09:33AM +0900, Masami Hiramatsu wrote:
> Hi Beau,
>
> On Tue, 23 Jan 2024 22:08:40 +
> Beau Belgrave wrote:
>
> > Currently user_events supports 1 event with the same name and must have
> > the exact same format when referenced by multiple programs. This opens
> >
On Mon, 29 Jan 2024 19:56:52 -0800
Linus Torvalds wrote:
> [0005-eventfs-get-rid-of-dentry-pointers-without-refcounts.patch
> text/x-patch (15652 bytes)]
I missed this email when I wrote basically the same thing :-p
It was sent just as I went to bed and this morning I mistaken it as an
email
On Sat, 20 Jan 2024 20:11:15 +0100, Karel Balej wrote:
> From: Karel Balej
>
> IST3032C is a touchscreen IC which seems mostly compatible with IST3038C
> except that it reports a different chip ID value.
>
> Signed-off-by: Karel Balej
> ---
>
> Notes:
> v4:
> * Reword commit descript
On Tue, Jan 30, 2024 at 11:12:22PM +0900, Masami Hiramatsu wrote:
> On Mon, 29 Jan 2024 09:29:07 -0800
> Beau Belgrave wrote:
>
> > On Fri, Jan 26, 2024 at 03:04:45PM -0500, Steven Rostedt wrote:
> > > On Fri, 26 Jan 2024 11:10:07 -0800
> > > Beau Belgrave wrote:
> > >
> > > > > OK, so the each
On Mon, Jan 29, 2024 at 09:24:07PM -0500, Steven Rostedt wrote:
> On Mon, 29 Jan 2024 09:29:07 -0800
> Beau Belgrave wrote:
>
> > Thanks, yeah ideally we wouldn't use special characters.
> >
> > I'm not picky about this. However, I did want something that clearly
> > allowed a glob pattern to fi
On Thu, Jan 18, 2024 at 11:04:31AM +0100, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
>
>
>>>> Signed-off-by: Christophe Leroy
>>> Very nice cleanup, thanks!, applied and pushed
>>>
>>> Luis
>> On next-20240130, which has your modules-next branch, and thus this
>> series and the other "module: Use set_memory_rox()" series
On Fri, Jan 26, 2024 at 12:03:25PM +0100, Krzysztof Kozlowski wrote:
> On 18/01/2024 11:04, Arnaud Pouliquen wrote:
> > The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> > where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> > (TEE).
> > For instan
On Tue, 30 Jan 2024 at 08:55, Linus Torvalds
wrote:
>
> Let me just reboot into it to test that I got all the cases.
>
> It makes the code even more obvious, and avoids all the complexity.
Yup, this works at least for the case you pointed out, and it really
feels like the RightThing(tm) from a VF
On Tue, 30 Jan 2024 08:55:51 -0800
Linus Torvalds wrote:
> On Tue, 30 Jan 2024 at 08:49, Steven Rostedt wrote:
> >
> > - On removal, I got rid of the SRCU callback and the work queue.
> > Instead, I find the dentry of the current eventfs_inode that is being
> > deleted by walking the ei->par
On Tue, 30 Jan 2024 at 08:49, Steven Rostedt wrote:
>
> - On removal, I got rid of the SRCU callback and the work queue.
> Instead, I find the dentry of the current eventfs_inode that is being
> deleted by walking the ei->parent until I find the events inode that has
> a dentry. I then use t
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 query this.
For dcache aliasing, there are three scenarios dependending on th
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 too broad (e.g. recent ARMv7 don't have virtually aliased
dcaches), and also misses
Use dax_is_supported() to validate whether the architecture has
virtually aliased data caches at mount time. Silently disable
DAX if dax=always is requested as a mount option on an architecture
which does not support DAX.
This is relevant for architectures which require a dynamic check
to validate
Use dax_is_supported() to validate whether the architecture has
virtually aliased data caches at mount time. Silently disable
DAX if dax=always is requested as a mount option on an architecture
which does not support DAX.
This is relevant for architectures which require a dynamic check
to validate
Use dax_is_supported() to validate whether the architecture has
virtually aliased data caches at mount time. Mount fails if dax=always
is requested as a mount option on an architecture which does not support
DAX.
This is relevant for architectures which require a dynamic check
to validate whether
Use dax_is_supported() to validate whether the architecture has
virtually aliased data caches at mount time. Print an error and disable
DAX if dax=always is requested as a mount option on an architecture
which does not support DAX.
This is relevant for architectures which require a dynamic check
t
This commit introduced in v5.13 prevents building FS_DAX on 32-bit ARM,
even on ARMv7 which does not have virtually aliased dcaches:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
It used to work fine before: I have customers using DAX over pmem on
ARMv7, but t
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 preparation for its use by each filesystem supporting
the dax mount option to validate w
On Tue, 30 Jan 2024 at 06:39, Steven Rostedt wrote:
>
> On Tue, 30 Jan 2024 01:12:05 -0800
> >
> > I suspect the solution is to make eventfs_create_dir() do the same as
> > the events directory case does, and actually pin the directory dentry
> > and save it off.
>
> I rather not have the create d
On Tue, 30 Jan 2024 09:39:42 -0500
Steven Rostedt wrote:
> I may try something that will still let me get rid of the ei->dentry.
This appears to work, but like always, I may have missed something. I need
to add debugging (printks) to make sure the that I don't leave any dangling
dentries around
1 - 100 of 147 matches
Mail list logo
