Re: [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters

2024-03-08 Thread Linus Torvalds
On Fri, 8 Mar 2024 at 13:39, Linus Torvalds wrote: > > So the above "complexity" is *literally* just changing the > > (new = atomic_read_acquire(>seq)) != old > > condition to > > should_exit || >

Re: [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters

2024-03-08 Thread Linus Torvalds
On Fri, 8 Mar 2024 at 13:33, Steven Rostedt wrote: > > There's two layers: > > 1) the ring buffer has the above simple producer / consumer. >Where the wake ups can happen at the point of where the buffer has >the amount filled that the consumer wants to start consuming with. > > 2) The

Re: [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters

2024-03-08 Thread Linus Torvalds
On Fri, 8 Mar 2024 at 10:38, Steven Rostedt wrote: > > A patch was sent to "fix" the wait_index variable that is used to help with > waking of waiters on the ring buffer. The patch was rejected, but I started > looking at associated code. Discussing it on IRC with Mathieu Desnoyers > we

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-31 Thread Linus Torvalds
On Wed, 31 Jan 2024 at 07:58, Steven Rostedt wrote: > > BTW, I ran my full test suite on your patches with the below updates and it > all passed. Those patch updates all look sane to me. > I can break up and clean up the patches so that they are bisectable, and if > that passes the bisectable

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-31 Thread Linus Torvalds
On Wed, 31 Jan 2024 at 05:14, Steven Rostedt wrote: > > If you also notice, tracefs only allows mkdir/rmdir to be assigned to > one directory. Once it is assigned, no other directories can have mkdir > rmdir functionality. I think that does limit the damage, but it's not clear that it is

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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 p

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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

Re: [PATCH 6/6] eventfs: clean up dentry ops and add revalidate function

2024-01-30 Thread Linus Torvalds
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

Re: [PATCH 6/6] eventfs: clean up dentry ops and add revalidate function

2024-01-30 Thread Linus Torvalds
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

Re: [PATCH 3/6] tracefs: dentry lookup crapectomy

2024-01-30 Thread Linus Torvalds
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(_mutex); > > do { > > // The par

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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, an

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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 >

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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 h

Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
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

Re: [PATCH 6/6] eventfs: clean up dentry ops and add revalidate function

2024-01-30 Thread Linus Torvalds
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

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-30 Thread Linus Torvalds
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

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-30 Thread Linus Torvalds
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

[PATCH 6/6] eventfs: clean up dentry ops and add revalidate function

2024-01-30 Thread Linus Torvalds
eed at memory pressure rather than more proactively. But that's a separate issue. Signed-off-by: Linus Torvalds --- fs/tracefs/event_inode.c | 21 + fs/tracefs/inode.c | 27 ++- fs/tracefs/internal.h| 3 ++- 3 files changed, 25 insertions(+),

[PATCH 5/6] eventfs: get rid of dentry pointers without refcounts

2024-01-30 Thread Linus Torvalds
. As does the directory dentries. That makes the broken use case go away. Signed-off-by: Linus Torvalds --- fs/tracefs/event_inode.c | 245 --- fs/tracefs/internal.h| 9 +- 2 files changed, 80 insertions(+), 174 deletions(-) diff --git a/fs/tracefs/eve

[PATCH 4/6] eventfs: remove unused 'd_parent' pointer field

2024-01-30 Thread Linus Torvalds
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

[PATCH 3/6] tracefs: dentry lookup crapectomy

2024-01-30 Thread Linus Torvalds
ntries. Which meant that any other lookup would possibly return ENOENT if it saw that negative dentry before the data rwas then later filled in. You could see it in the immesnse amount of nonsensical code that didn't actually just do lookups. Signed-off-by: Linus Torvalds --- fs/tracefs

[PATCH 2/6] eventfsfs: initialize the tracefs inode properly

2024-01-30 Thread Linus Torvalds
ove the field initializations up to before the d_instantiate, and fix the use of uninitialized data. Signed-off-by: Linus Torvalds --- fs/tracefs/event_inode.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c in

[PATCH 1/6] tracefs: avoid using the ei->dentry pointer unnecessarily

2024-01-30 Thread Linus Torvalds
data that is irrelevant. Signed-off-by: Linus Torvalds --- fs/tracefs/event_inode.c | 26 -- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c index 1c3dd0ad4660..2d128bedd654 100644 --- a/fs/tracefs

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-30 Thread Linus Torvalds
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 RightTh

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-30 Thread Linus Torvalds
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

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-30 Thread Linus Torvalds
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

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-30 Thread Linus Torvalds
On Tue, 30 Jan 2024 at 00:43, Linus Torvalds wrote: > > I'll go back to bed, but I think the fix is something trivial like this: Almost. > + result = ERR_PTR(ENOENT); That needs a '-' in front of the ENOENT, otherwise you have a positive error number and things go wrong ver

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-30 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 19:56, Linus Torvalds wrote: > > But I've been staring at this code for too long, so I'm posting this > just as a "it's broken, but _something_ like this", because I'm taking > a break from looking at this. Bah. I literally woke up and realized what

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 17:50, Linus Torvalds wrote: > > So what I propose is that > > - ei->dentry and ei->d_children[] need to die. Really. They are > buggy. There is no way to save them. There never was. > > - but we *can* introduce a new 'ei->events_dir

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 16:35, Steven Rostedt wrote: > > # echo 'p:sched schedule' >> /sys/kernel/tracing/kprobe_events > # ls -l events/kprobes/ > ls: cannot access 'events/kprobes/': No such file or directory > > Where it should now exist but doesn't. But the lookup code never triggered. > >

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 14:49, Steven Rostedt wrote: > > Now I didn't change this last d_instantiate, because this is not called > through the lookup code. This is the root events directory and acts more > like debugfs. It's not "dynamically" added. Ahh, yes, I see, the dentry was created (as a

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 14:35, Linus Torvalds wrote: > > So just replace all the d_instantiate() calls there with "d_add()" > instead. I think that will fix it. I can confirm that with the mutex deadlock removed and the d_add() fix, at least things *look* superficially ok. I

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 14:21, Steven Rostedt wrote: > > But crashes with just a: > > # ls /sys/kernel/tracing/events > > [ 66.423983] [ cut here ] > [ 66.426447] kernel BUG at fs/dcache.c:1876! Duh. That's a bit too much copy-and-paste by me. So what is going on is

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 13:45, Steven Rostedt wrote: > > 1 file changed, 50 insertions(+), 219 deletions(-) > > Thanks, much appreciated. Well, I decided I might as well give it a test-run, and there's an immediate deadlock on eventfs_mutex, because I missed removing it from

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
r than the old code, but there may be some silly gotcha that I have missed. Linus From b1f487acf6f4e9093d8b0fa00f864a6d07a3c4c2 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Sat, 27 Jan 2024 13:27:01 -0800 Subject: [PATCH 2/4] tracefs: avoid using the ei->dentry point

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 11:24, Linus Torvalds wrote: > > So the patch was completely broken. Here's the one that should > actually compile (although still not actually *tested*). Note that this fixes the d_instantiate() ordering wrt initializing the inode. But as I look up the call cha

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 09:40, Linus Torvalds wrote: > > IOW, I think the right fix is really just this: Oh, for some reason I sent out the original patch I had which didn't fix the create_dir() case. So that patch was missing the important hunk that added the ti-

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 09:44, Steven Rostedt wrote: > > On Mon, 29 Jan 2024 09:40:06 -0800 > Linus Torvalds wrote: > > > Now, I do agree that your locking is strange, and that should be fixed > > *too*, but I think the above is the "right" fix for this particu

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 09:40, Linus Torvalds wrote: > > eventfs_create_events_dir() seems to have the same bug with ti->flags, > btw, but got the ti->private initialization right. > > Funnily enough, create_file() got this right. I don't even understand > why create_dir()

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-29 Thread Linus Torvalds
On Mon, 29 Jan 2024 at 09:01, Steven Rostedt wrote: > > Thanks for the analysis. I have a patch that removes the dropping of the > mutex over the create_dir/file() calls, and lockdep hasn't complained about > it. > > I was going to add that to my queue for the next merge window along with > other

Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address

2024-01-28 Thread Linus Torvalds
On Sun, 28 Jan 2024 at 18:59, kernel test robot wrote: > > 21: 48 8b 47 f8 mov-0x8(%rdi),%rax > 25: 48 85 c0test %rax,%rax > 28: 74 11 je 0x3b > 2a:* f6 40 78 02 testb $0x2,0x78(%rax) <-- trapping >

Re: [PATCH] eventfs: Give files a default of PAGE_SIZE size

2024-01-26 Thread Linus Torvalds
On Fri, 26 Jan 2024 at 10:41, Steven Rostedt wrote: > > Fine, but I still plan on sending you the update to give all files unique > inode numbers. If it screws up tar, it could possibly screw up something > else. Well, that in many ways just regularizes the code, and the dynamic inode numbers

Re: [PATCH] eventfs: Give files a default of PAGE_SIZE size

2024-01-26 Thread Linus Torvalds
On Fri, 26 Jan 2024 at 10:18, Steven Rostedt wrote: > > By following what sysfs does, and give files a default size of PAGE_SIZE, > it allows the tar to work. No event file is greater than PAGE_SIZE. No, please. Just don't. Nobody has asked for this, and nobody sane should use 'tar' on tracefs

Re: [PATCH v3 1/2] eventfs: Have the inodes all for files and directories all be the same

2024-01-22 Thread Linus Torvalds
On Mon, 22 Jan 2024 at 13:59, Darrick J. Wong wrote: > > though I don't think > leaking raw kernel pointers is an awesome idea. Yeah, I wasn't all that comfortable even with trying to hash it (because I think the number of source bits is small enough that even with a crypto hash, it's

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 14:14, Al Viro wrote: > > On Wed, Jan 03, 2024 at 01:54:36PM -0800, Linus Torvalds wrote: > > > Again: UNTESTED, and meant as a "this is another way to avoid messing > > with the dentry tree manually, and just using the VFS interfaces we > &

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 14:04, Steven Rostedt wrote: > > I actually have something almost working too. Here's the WIP. It only works > for tracefs, and now eventfs needs to be updated as the "events" directory > no longer has the right ownership. So I need a way to link the eventfs > entries to use

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 13:54, Linus Torvalds wrote: > > Here's an updated patch that builds, and is PURELY AN EXAMPLE. Oh, and while doing this patch, I found another bug in tracefs, although it happily is one that doesn't have any way to trigger. Tracefs has code like this: if (

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 11:57, Linus Torvalds wrote: > > Or, you know, you could do what I've told you to do at least TEN TIMES > already, which is to not mess with any of this, and just implement the > '->permission()' callback (and getattr() to just make 'ls' look sane > too, ra

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 11:52, Steven Rostedt wrote: > > This doesn't work because for tracefs (not eventfs) the dentries are > created at boot up and before the file system is mounted. This means you > can't even set a gid in /etc/fstab. This will cause a regression. Which is why I suggested

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 10:50, Steven Rostedt wrote: > I think these changes are a bit much for -rc8, don't you? Oh, absolutely. None of this is rc8 material apart from the oops fix in your pull request (which my patch that then removes the whole function did *not* have - so that patch won't

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 10:12, Linus Torvalds wrote: > > Much better. Now eventfs looks more like a real filesystem, and less > like an eldritch horror monster that is parts of dcache tackled onto a > pseudo-filesystem. Oh, except I think you still need to just remove the 'set_gid()'

Re: [PATCH] eventfs: Stop using dcache_readdir() for getdents()

2024-01-03 Thread Linus Torvalds
On Wed, 3 Jan 2024 at 07:24, Steven Rostedt wrote: > > Instead, just have eventfs have its own iterate_shared callback function > that will fill in the dent entries. This simplifies the code quite a bit. Much better. Now eventfs looks more like a real filesystem, and less like an eldritch horror

Re: [PATCH next 4/5] locking/osq_lock: Optimise per-cpu data accesses.

2023-12-30 Thread Linus Torvalds
On Sat, 30 Dec 2023 at 12:41, Linus Torvalds wrote: > > UNTESTED patch to just do the "this_cpu_write()" parts attached. > Again, note how we do end up doing that this_cpu_ptr conversion later > anyway, but at least it's off the critical path. Also note that while 't

Re: [PATCH next 4/5] locking/osq_lock: Optimise per-cpu data accesses.

2023-12-30 Thread Linus Torvalds
On Fri, 29 Dec 2023 at 12:57, David Laight wrote: > > this_cpu_ptr() is rather more expensive than raw_cpu_read() since > the latter can use an 'offset from register' (%gs for x86-84). > > Add a 'self' field to 'struct optimistic_spin_node' that can be > read with raw_cpu_read(), initialise on

Re: [PATCH next 0/5] locking/osq_lock: Optimisations to osq_lock code

2023-12-30 Thread Linus Torvalds
On Fri, 29 Dec 2023 at 12:52, David Laight wrote: > > David Laight (5): > Move the definition of optimistic_spin_node into osf_lock.c > Clarify osq_wait_next() I took these two as preparatory independent patches, with that osq_wait_next() clarification split into two. I also did the

Re: [PATCH next 3/5] locking/osq_lock: Clarify osq_wait_next()

2023-12-29 Thread Linus Torvalds
On Fri, 29 Dec 2023 at 12:56, David Laight wrote: > > osq_wait_next() is passed 'prev' from osq_lock() and NULL from osq_unlock() > but only needs the 'cpu' value to write to lock->tail. > Just pass prev->cpu or OSQ_UNLOCKED_VAL instead. > > Also directly return NULL or 'next' instead of breaking

Re: [PATCH] ring-buffer: Remove 32bit timestamp logic

2023-12-14 Thread Linus Torvalds
On Thu, 14 Dec 2023 at 12:35, Steven Rostedt wrote: > > On Thu, 14 Dec 2023 11:44:55 -0800 > Linus Torvalds wrote: > > > On Thu, 14 Dec 2023 at 08:55, Steven Rostedt wrote: > > > > > > And yes, this does get called in NMI context. > > > > Not on

Re: [PATCH v3] ring-buffer: Remove 32bit timestamp logic

2023-12-14 Thread Linus Torvalds
On Thu, 14 Dec 2023 at 12:30, Linus Torvalds wrote: > > Read my email. Don't do random x86-centric things. We have that > > #ifndef system_has_cmpxchg64 > #define system_has_cmpxchg64() false > #endif > > which should work. And again, by "should work&

Re: [PATCH v3] ring-buffer: Remove 32bit timestamp logic

2023-12-14 Thread Linus Torvalds
On Thu, 14 Dec 2023 at 12:18, Steven Rostedt wrote: > > For this issue of the 64bit cmpxchg, is there any config that works for any > arch that do not have a safe 64-bit cmpxchg? At least for 486, is the > second half of the if condition reasonable? > > if (IS_ENABLED(CONFIG_X86_32) &&

Re: [PATCH v3] ring-buffer: Remove 32bit timestamp logic

2023-12-14 Thread Linus Torvalds
On Thu, 14 Dec 2023 at 09:53, Steven Rostedt wrote: > > + /* > +* For architectures that can not do cmpxchg() in NMI, or require > +* disabling interrupts to do 64-bit cmpxchg(), do not allow them > +* to record in NMI context. > +*/ > + if

Re: [PATCH] ring-buffer: Remove 32bit timestamp logic

2023-12-14 Thread Linus Torvalds
On Thu, 14 Dec 2023 at 08:55, Steven Rostedt wrote: > > And yes, this does get called in NMI context. Not on an i486-class machine they won't. You don't have a local apic on those, and they won't have any NMI sources under our control (ie NMI does exist, but we're talking purely legacy NMI for

Re: [PATCH] ring-buffer: Remove 32bit timestamp logic

2023-12-13 Thread Linus Torvalds
On Wed, 13 Dec 2023 at 18:45, Steven Rostedt wrote: > > tl;dr; The ring-buffer timestamp requires a 64-bit cmpxchg to keep the > timestamps in sync (only in the slow paths). I was told that 64-bit cmpxchg > can be extremely slow on 32-bit architectures. So I created a rb_time_t > that on 64-bit

Re: [GIT PULL] Modules changes for v6.7-rc1

2023-11-02 Thread Linus Torvalds
On Wed, 1 Nov 2023 at 21:02, Linus Torvalds wrote: > > kmalloc() isn't just about "use physically contiguous allocations". > It's also more memory-efficient, and a *lot* faster than vmalloc(), > which has to play VM tricks. I've pulled this, but I think you should do somet

Re: [GIT PULL] Modules changes for v6.7-rc1

2023-11-02 Thread Linus Torvalds
On Wed, 1 Nov 2023 at 10:13, Luis Chamberlain wrote: > > The only thing worth highligthing is that gzip moves to use vmalloc() instead > of > kmalloc just as we had a fix for this for zstd on v6.6-rc1. Actually, that's almost certainly entirely the wrong thing to do. Unless you *know* that the

Re: [GIT PULL] NVDIMM and DAX for 6.5

2023-07-01 Thread Linus Torvalds
On Fri, 30 Jun 2023 at 12:17, Verma, Vishal L wrote: > > On an operational note, as Dan handed off the branch to me for this cycle, we > missed that the original few commits were inadvertently made on top of a few > CXL commits that went in in the 6.4-rc cycle via the CXL tree. > >

Re: [RFC][PATCH] fix short copy handling in copy_mc_pipe_to_iter()

2022-06-13 Thread Linus Torvalds
On Sun, Jun 12, 2022 at 5:10 PM Al Viro wrote: > > Unlike other copying operations on ITER_PIPE, copy_mc_to_iter() can > result in a short copy. In that case we need to trim the unused > buffers, as well as the length of partially filled one - it's not > enough to set ->head, ->iov_offset and

Re: [PATCH v3.4] capabilities: require CAP_SETFCAP to map uid 0

2021-04-20 Thread Linus Torvalds
On Tue, Apr 20, 2021 at 9:47 AM Christian Brauner wrote: > > If there's no objections then Linus can probably just pick up the single > patch here directly: I'm ok with that assuming I don't hear any last-minute concerns.. I'll plan on appling it later today, so anybody with concerns please

Re: [patch 11/12] gcov: clang: fix clang-11+ build

2021-04-19 Thread Linus Torvalds
On Mon, Apr 19, 2021 at 2:37 PM Nathan Chancellor wrote: > > This should not have been merged into mainline by itself. It was a fix > for "gcov: use kvmalloc()", which is still in -mm/-next. Merging it > alone has now broken the build: > >

Re: [PATCH 00/13] [RFC] Rust support

2021-04-19 Thread Linus Torvalds
On Mon, Apr 19, 2021 at 11:38 AM Paolo Bonzini wrote: > > It changes it for the worse, in that access to fields that are shared > across threads *must* either use atomic types Well, we won't be using those broken types in the core kernel, so that would all be entirely on the Rust side. And I

Re: [PATCH 00/13] [RFC] Rust support

2021-04-19 Thread Linus Torvalds
On Mon, Apr 19, 2021 at 2:36 AM Peter Zijlstra wrote: > > I also don't see how this is better than seq_cst. > > But yes, not broken, but also very much not optimal. I continue to feel like kernel people should just entirely ignore the C++ memory ordering standard. It's inferior to what we

Linux 5.12-rc8

2021-04-18 Thread Linus Torvalds
n open function MAINTAINERS: update my email Linus Torvalds (2): readdir: make sure to verify directory entry for legacy interfaces too Linux 5.12-rc8 Luke D Jones (1): HID: asus: Add support for 2021 ASUS N-Key keyboard Lv Yunlong (1): dmaengine: Fix a double free in

Re: [GIT PULL] Re: ARM SoC fixes for v5.12, part 2

2021-04-18 Thread Linus Torvalds
On Sun, Apr 18, 2021 at 12:24 PM Arnd Bergmann wrote: > > I forgot to add the '[GIT PULL]' in the subject line, replying to myself > here to ensure it hits the right email folder. Well, the reply hit _my_ search criterion, but the pr-tracker-bot is a bit more picky. As a result, I don't think

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote: > > No, wait - we have non-NULL buf->prev_reclen, so we'll hit > with buf->error completely ignored. Nevermind. Yeah, I'm pretty sure I even tested that -EINTR case at one point. Of course, it could easily have gotten broken again, so that's not a

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 12:44 PM Eric Dumazet wrote: > > I thought put_cmsg() callers were from the kernel, with no possibility > for user to abuse this interface trying to push GB of data. My point is that "I thought" is not good enough for the unsafe interfaces. It needs to be "I can see that

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 9:08 AM Linus Torvalds wrote: > > Side note: I'm, looking at the readdir cases that I wrote, and I have > to just say that is broken too. So "stones and glass houses" etc, and > I'll have to fix that too. In particular, the very very old OLD_READD

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Sat, Apr 17, 2021 at 9:03 AM Linus Torvalds wrote: > > Really. The "unsafe" user accesses are named that way very explicitly, > and for a very very good reason: the safety needs to be guaranteed and > obvious within the context of those accesses. Not within some "

Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()

2021-04-17 Thread Linus Torvalds
On Fri, Apr 16, 2021 at 12:24 PM Eric Dumazet wrote: > > From: Eric Dumazet > > We have to loop only to copy u64 values. > After this first loop, we copy at most one u32, one u16 and one byte. As Al mentioned, at least in trivial cases the compiler understands that the subsequent loops can only

Re: [PATCH 04/13] Kbuild: Rust support

2021-04-16 Thread Linus Torvalds
On Fri, Apr 16, 2021 at 6:38 AM Peter Zijlstra wrote: > > AFAICT rust has try/throw/catch exception handling (like > C++/Java/others) which is typically implemented with stack unwinding of > its own. I was assuming that the kernel side would never do that. There's some kind of "catch_unwind()"

Re: [PATCH 00/13] [RFC] Rust support

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote: > > There's a philosophical point to be discussed here which you're skating > right over! Should rust-in-the-linux-kernel provide the same memory > allocation APIs as the rust-standard-library, or should it provide a Rusty > API to the

Re: [PATCH 00/13] [RFC] Rust support

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:46 AM wrote: > > Some of you have noticed the past few weeks and months that > a serious attempt to bring a second language to the kernel was > being forged. We are finally here, with an RFC that adds support > for Rust to the Linux kernel. So I replied with my

Re: [PATCH 09/13] Samples: Rust examples

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:47 AM wrote: > > From: Miguel Ojeda > > A set of Rust modules that showcase how Rust modules look like > and how to use the abstracted kernel features. Honestly, I'd like to see a real example. This is fine for testing, but I'd like to see something a bit more real,

Re: [PATCH 07/13] Rust: Kernel crate

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:47 AM wrote: > > +#[alloc_error_handler] > +fn oom(_layout: Layout) -> ! { > +panic!("Out of memory!"); > +} > + > +#[no_mangle] > +pub fn __rust_alloc_error_handler(_size: usize, _align: usize) -> ! { > +panic!("Out of memory!"); > +} Again, excuse my lack of

Re: [PATCH 05/13] Rust: Compiler builtins crate

2021-04-14 Thread Linus Torvalds
On Wed, Apr 14, 2021 at 11:46 AM wrote: > > We also need a helpers C source file to contain some forwarders > to C macros and inlined functions. For the moment, we only need it > to call the `BUG()` macro, but we will be adding more later. Not being a Rust person, I can only guess based on

Re: Linux 5.12-rc7

2021-04-12 Thread Linus Torvalds
On Sun, Apr 11, 2021 at 10:14 PM Guenter Roeck wrote: > > Qemu test results: > total: 460 pass: 459 fail: 1 > Failed tests: > sh:rts7751r2dplus_defconfig:ata:net,virtio-net:rootfs > > The failure bisects to commit 0f6925b3e8da ("virtio_net: Do not pull payload > in > skb->head").

Linux 5.12-rc7

2021-04-11 Thread Linus Torvalds
ASoC: SOF: Intel: ICL: set shutdown callback to hda_dsp_shutdown ASoC: SOF: Intel: CNL: set shutdown callback to hda_dsp_shutdown ASoC: SOF: Intel: APL: set shutdown callback to hda_dsp_shutdown Linus Torvalds (1): Linux 5.12-rc7 Loic Poulain (1): net: qrtr: Fix

Re: [PATCH] vt_ioctl: make VT_RESIZEX behave like VT_RESIZE

2021-04-11 Thread Linus Torvalds
On Sun, Apr 11, 2021 at 2:43 PM Maciej W. Rozycki wrote: > > So it does trigger with vgacon and my old server, which I have started > experimenting with and for a start I have switched to a new kernel for an > unrelated purpose (now that I have relieved it from all its usual tasks > except for

Re: [RFC][PATCH] mm: Split page_has_private() in two to better handle PG_private_2

2021-04-08 Thread Linus Torvalds
On Thu, Apr 8, 2021 at 2:15 PM David Howells wrote: > > mm: Split page_has_private() in two to better handle PG_private_2 >From a look through the patch and some (limited) thinking about it, I like the patch. I think it clarifies the two very different cases, and makes it clear that one is about

Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression

2021-04-08 Thread Linus Torvalds
On Thu, Apr 8, 2021 at 1:32 AM kernel test robot wrote: > > FYI, we noticed a -41.9% regression of stress-ng.sigsegv.ops_per_sec due to > commit > 08ed4efad684 ("[PATCH v10 6/9] Reimplement RLIMIT_SIGPENDING on top of > ucounts") Ouch. I *think* this test may be testing "send so many signals

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 11:47 AM Mikulas Patocka wrote: > > So, we fixed it, but we don't know why. > > Peter Xu's patchset that fixed it is here: > https://lore.kernel.org/lkml/20200821234958.7896-1-pet...@redhat.com/ Yeah, that's the part that ends up being really painful to backport (with all

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 9:33 AM Suren Baghdasaryan wrote: > > Trying my hand at backporting the patchsets Peter mentioned proved > this to be far from easy with many dependencies. Let me look into > Vlastimil's suggestion to backport only 17839856fd58 and it sounds > like 5.4 already followed that

Re: [GIT PULL] parisc architecture fixes for kernel v5.12-rc7

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 2:09 AM Helge Deller wrote: > > http://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git > parisc-5.12-3 Not technically related to this pull (which I just did), but doing the pull did remind me that you're one of the people who don't use signed tags for

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-07 Thread Linus Torvalds
On Wed, Apr 7, 2021 at 6:22 AM Vlastimil Babka wrote: > > 1) Ignore the issue (outside of Android at least). The security model of > zygote > is unusual. Where else a parent of fork() doesn't trust the child, which is > the > same binary? Agreed. I think this is basically an android-only issue

Re: Linux 5.12-rc6

2021-04-05 Thread Linus Torvalds
On Mon, Apr 5, 2021 at 10:10 AM Guenter Roeck wrote: > > No change in test results since last week [..] Let's ping Frank for the alignment issue. If that promised patch isn't timely (and trivial), I really think that removing the alignment check is by now the way forward for that libftd

Linux 5.12-rc6

2021-04-04 Thread Linus Torvalds
extcon: Add stubs for extcon_register_notifier_all() functions Lars Povlsen (1): pinctrl: microchip-sgpio: Fix wrong register offset for IRQ trigger Linus Torvalds (1): Linux 5.12-rc6 Liu Ying (1): drm/imx: imx-ldb: Register LDB channel1 when it is the only channel to be used

Re: [PATCH] firewire: nosy: Fix a use-after-free bug in nosy_ioctl()

2021-04-03 Thread Linus Torvalds
On Fri, Apr 2, 2021 at 11:59 PM Zheyu Ma wrote: > > case NOSY_IOC_START: > + list_for_each_entry(tmp, >lynx->client_list, link) > + if (tmp == client) > + return -EINVAL; I don't think this is safe. You are doing this

Re: [GIT PULL] ftrace: Check if pages were allocated before calling free_pages()

2021-04-01 Thread Linus Torvalds
On Thu, Apr 1, 2021 at 1:07 PM Steven Rostedt wrote: > > On Wed, 31 Mar 2021 11:03:21 -0700 > Linus Torvalds wrote: > > > @@ -6231,7 +6231,8 @@ static int ftrace_process_locs(struct module *mod, > > if (!addr) > > continue; >

Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue"

2021-04-01 Thread Linus Torvalds
On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan wrote: > > We received a report that the copy-on-write issue repored by Jann Horn in > https://bugs.chromium.org/p/project-zero/issues/detail?id=2045 is still > reproducible on 4.14 and 4.19 kernels (the first issue with the reproducer > coded in

Re: [PATCH 0/6] Allow signals for IO threads

2021-04-01 Thread Linus Torvalds
On Thu, Apr 1, 2021 at 9:00 AM Stefan Metzmacher wrote: > > I haven't tried it, but it seems gdb tries to use PTRACE_PEEKUSR > against the last thread tid listed under /proc//tasks/ in order to > get the architecture for the userspace application Christ, what an odd hack. Why wouldn't it just do

  1   2   3   4   5   6   7   8   9   10   >