On Mon, 12 May 2025 at 11:14, Dmitry Antipov wrote:
>
> Technically speaking you're right, and I will take notice on that for
> further commits. OTOH replying with "please adjust commit message and
> send v2" could be the way faster.
I suspect it ends up depending on the people.
Personally, I te
On Fri, 9 May 2025 at 08:09, Petr Pavlu wrote:
>
> The fix has been on modules-next only since yesterday but should be safe.
Hmm.
At a minimum, the *description* of this bug is garbage.
It talks about an "uninitialized completion pointer", but then the fix
actually depends on it being initializ
On Sat, 1 Feb 2025 at 10:51, Masahiro Yamada wrote:
>
> This commit addresses the issue by leveraging modpost. Symbol names
> passed to symbol_get() are recorded in the special .no_trim_symbol
> section, which is then parsed by modpost to forcibly keep such symbols.
> The .no_trim_symbol section i
On Fri, 17 Jan 2025 at 09:24, Uladzislau Rezki (Sony) wrote:
>
> Please pull the latest RCU git tree from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux.git
> tags/rcu.release.v6.14
Hmm. I have pulled this, and the resulting shortlog matches what you
say I should have gotten.
But
On Mon, 23 Dec 2024 at 02:55, Petr Pavlu wrote:
>
> Luis asked me to look after the modules maintenance for a while, with the
> plan to rotate it with other recently added modules maintainers/reviewers.
> This is my first pull request to you.
I *really* want maintainers to give me a heads up befo
On Mon, 2 Dec 2024 at 07:15, Peter Zijlstra wrote:
>
> Perhaps we can ask Linus to run this now, before -next fills up again ?
Sure. I did an unasked-for scripted 'remove_new' removal right after
rc1 for the same reason.
If we have these kinds of big scripted things, right after the merge
window
On Thu, 28 Nov 2024 at 11:27, Luis Chamberlain wrote:
>
> This consists of 3 fixes, the main one build that we build the kallsyms
> test modules all over again if we just run make twice.
Thanks, my empty builds went from 43s back to 23s where they belong.
(Obviously when some core header file ch
On Wed, 27 Nov 2024 at 15:26, Luis Chamberlain wrote:
>
> On Wed, Nov 27, 2024 at 02:35:36PM -0800, Luis Chamberlain wrote:
> > Sorry about that, I'm on it.
>
> OK here is a fix, goes double build tested and then run time tested.
No, you misunderstand.
I don't mind the tests being built. That's
On Tue, 26 Nov 2024 at 17:10, Luis Chamberlain wrote:
>
> Highlights for this merge window:
Lowlights:
> * Adds a new modules selftests: kallsyms which helps us tests find_symbol()
> and the limits of kallsyms on Linux today.
This is completely broken.
Try doing "make allmodconfig" and t
On Mon, 21 Oct 2024 at 15:16, Mark Brown wrote:
>
> Fix this by making the addition of this x86 specific command line flag
> conditional on building for x86.
Applied directly, just to have this silly thing done with.
Thanks,
Linus
On Sat, 5 Oct 2024 at 09:16, Peter Zijlstra wrote:
>
> On Wed, Oct 02, 2024 at 10:39:15AM -0700, Linus Torvalds wrote:
> > So I think the real issue is that "active_mm" is an old hack from a
> > bygone era when we didn't have the (much more involved) full TLB
On Tue, 1 Oct 2024 at 18:04, Mathieu Desnoyers
wrote:
>
> Hazard pointers appear to be a good fit for replacing refcount based lazy
> active mm tracking.
If the mm refcount is this expensive, I suspect we really shouldn't
use it at all.
The thing is, we don't _need_ to use the mm refcount - the
On Fri, 27 Sept 2024 at 12:28, Linus Torvalds
wrote:
>
> Dammit, people, read the code I posted.
Actually, no, apologies. You were right, and I was wrong.
It does need both of the sources of the comparison to be hidden,
because while even hiding just one side makes the comparison
On Fri, 27 Sept 2024 at 12:12, Jonas Oberhauser
wrote:
>
> I think it depends on which one you hide.
No.
Dammit, people, read the code I posted.
> But for
>
> z = a;
> hide(z);
> if (z==b) { *b; }
No.
I *intentionally* made it an inline function, and only hid the
arguments to the equali
On Fri, 27 Sept 2024 at 10:53, Mathieu Desnoyers
wrote:
>
> > (b) the value barrier needs to be on *both* values so that the order
> > of the equality testing doesn't matter.
>
> If we use OPTIMIZER_HIDE_VAR() on both parameters, it indeed minimizes
> the odds that someone get the order wrong, b
On Fri, 27 Sept 2024 at 10:17, Mathieu Desnoyers
wrote:
>
> The barrier() is ineffective at fixing the issue.
> It does not prevent the compiler CSE from losing the
> address dependency:
Ok. Thanks for actually specifying code.
That needs to be
(a) in a comment
(b) the value barrier needs to
On Thu, 26 Sept 2024 at 18:38, Boqun Feng wrote:
>
> Note that ADDRESS_EQ() only hide first parameter, so this should be
> ADDRESS_EQ(b, a).
Yeah, please stop making things unnecessarily complicated.
Just use a barrier(). Please. Stop these stupid games until you can
show why it matters.
And b
On Thu, 26 Sept 2024 at 08:54, Jonas Oberhauser
wrote:
>
> No, the issue introduced by the compiler optimization (or by your
> original patch) is that the CPU can speculatively load from the first
> pointer as soon as it has completed the load of that pointer:
You mean the compiler can do it. The
On Thu, 26 Sept 2024 at 09:40, Jonas Oberhauser
wrote:
>
> Boqun seems to be unhappy with a barrier though, because it would
> theoretically also forbid unrelated optimizations.
Well, doing a "barrier()" is kind of a big hammer thing, but honestly,
I don't think we've ever seen any real situation
On Tue, 24 Sept 2024 at 12:31, Linus Torvalds
wrote:
>
> It's in my tree now, but please fix asap.
Argh, now that I noticed it, I can no longer unsee it.
So I did this
- depends on ARCH_K3 || COMPILE_TEST
+ depends on ARCH_OMAP2PLUS || ARCH_K3
to the TI_K3_M4_REMOTEPR
On Mon, 23 Sept 2024 at 21:44, Bjorn Andersson wrote:
>
> remoteproc updates for v6.12
Grr. I didn't immediately notice this new Kconfig warning, so now it's
in my tree:
WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX
Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K
On Thu, 19 Sept 2024 at 16:15, Christoph Hellwig wrote:
>
> Agreed. From the description this would seem like a good fit for
> q_usage_counter in the block layer, which currently makes creative use
> of percpu counters.
Yes, if this actually could simplify code that currently used percpu
counter
On Thu, 19 Sept 2024 at 00:44, Neeraj Upadhyay wrote:
>
> While we were working on this problem, this refcount scalability issue got
> resolved recently with conditional ref acquisition [3] (however, there are
> new
> developments in apparmor code which might bring back the refcount problem
> [
On Tue, 17 Sept 2024 at 16:34, Boqun Feng wrote:
>
> This series introduces hazard pointers [1] to kernel space. A TL;DR
> description of hazard pointers is "a scalable refcounting mechanim
> with RCU-like API". More information can be found at [2].
Please give actual "this is useful for X, and h
On Mon, 16 Sept 2024 at 11:45, Vlastimil Babka wrote:
>
> There's a small conflict with the rcu tree:
> https://lore.kernel.org/lkml/20240812124748.37250...@canb.auug.org.au/
Hmm. The conflict resolution is trivial, but the code itself looks buggy.
Look here, commit 2b55d6a42d14 ("rcu/kvfree: Ad
On Fri, 16 Aug 2024 at 10:15, Ira Weiny wrote:
>
> Ira Weiny wrote:
> > Hi Linux, please pull from
> ^
> Linus.
>
> Apologies,
Heh. I've been called worse. And it's a fairly common typo with people
whose fingers are used to type "Linux" and do so on auto-pilot.
I have an evil twin
On Sat, 22 Jun 2024 at 14:25, Mateusz Guzik wrote:
>
> +cc Linus
Thanks.
> To sum up the problem: stat and statx met with "" + AT_EMPTY_PATH have
> more work to do than fstat and its hypotethical statx counterpart:
> - buf alloc/free for the path
> - userspace access (very painful on x86_64 + SM
On Thu, 21 Mar 2024 at 11:03, Bjorn Andersson wrote:
>
> I was further notified that this conflicts with your tree, Linus. Below
> is the resolution for this conflict.
Heh. This email came in after the pr-tracker-bot email notifying you
that it's already done..
I think I got it all right, it did
On Tue, 19 Mar 2024 at 00:41, Michael S. Tsirkin wrote:
>
> virtio: features, fixes
>
> Per vq sizes in vdpa.
> Info query for block devices support in vdpa.
> DMA sync callbacks in vduse.
>
> Fixes, cleanups.
Grr. I thought the merge message was a bit too terse, but I let it slide.
But only aft
On Fri, 8 Mar 2024 at 13:39, Linus Torvalds
wrote:
>
> So the above "complexity" is *literally* just changing the
>
> (new = atomic_read_acquire(&my->seq)) != old
>
> condition to
>
> should_exit ||
>
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 tra
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 discovered
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 po
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 actually
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
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 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 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 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 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
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 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'
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,
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 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 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 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.,
, but they only tend to get freed
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 ++-
by having child dentries take a ref to the ei. 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(+),
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/tr
s. 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/tr
t assignment.
Move 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/trac
ooking up extraneous 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 100
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 RightThin
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
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 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 thin
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 u
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_d
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.
>
> If
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 ne
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
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
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
eventfs_find_events()
spection.
That's great, but it really means that it's all untested. It *looks*
better 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 Ja
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 cal
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
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
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_d
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
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
> instr
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 are
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 a
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 tr
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
> &
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
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:
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
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
"
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 apply
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_g
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
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 whi
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 fir
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 renaming
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
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
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&
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) && !IS
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 ((!IS_ENABLED
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 "m
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 w
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
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
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.
>
> git-request-pul
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 ->c
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
holl
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:
>
> https://github.com/ClangBuiltLinux/continuous-integration2
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 don
1 - 100 of 8762 matches
Mail list logo
