* Re: [GIT PULL] f2fs update for 6.8-rc1
@ 2024-01-12 18:18 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-12 18:18 UTC (permalink / raw)
To: Al Viro
Cc: Jaegeuk Kim, Linux Kernel Mailing List, Linux F2FS Dev Mailing List
On Thu, 11 Jan 2024 at 23:12, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Where would you end up with old_dir_page != NULL and old_dir_entry == NULL?
D'oh.
You are of course right, and I missed that connection. Happily my
merge still works, just isn't as minimal as yours.
I see that Jaegeuk already posted the patch for the cleanup.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] first round of SCSI updates for the 6.7+ merge window
@ 2024-01-12 18:34 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-12 18:34 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: James Bottomley, Andrew Morton, linux-scsi, linux-kernel
On Fri, 12 Jan 2024 at 06:27, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> I'm piping up just because I know how to get the output you want
Oh, I know how to get the output - I can read a man-page.
I'm just saying that the default output is unbelievably bad, and
subkeys are really atrocious from a usability standpoint, with
expiration making things even worse.
And being bad from a usability standpoint here is in the context of
gpg. That's a very low bar to begin with.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Scheduler changes for v6.8
@ 2024-01-12 20:49 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-12 20:49 UTC (permalink / raw)
To: Vincent Guittot
Cc: Qais Yousef, Dietmar Eggemann, Ingo Molnar, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Juri Lelli, Steven Rostedt,
Ben Segall, Mel Gorman, Daniel Bristot de Oliveira,
Valentin Schneider
On Fri, 12 Jan 2024 at 12:30, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I will test Vincent's test-patch next.
The patch at
https://lore.kernel.org/all/ZZ+ixagkxRPYyTCE@vingu-book/
makes absolutely no difference. All cores stay at 2.2GHz (ok, so
there's noise, but we're talking "within a couple of MHz of 2.2GHz").
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Scheduler changes for v6.8
@ 2024-01-13 1:31 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-13 1:31 UTC (permalink / raw)
To: Qais Yousef
Cc: Vincent Guittot, Dietmar Eggemann, Ingo Molnar, linux-kernel,
Peter Zijlstra, Thomas Gleixner, Juri Lelli, Steven Rostedt,
Ben Segall, Mel Gorman, Daniel Bristot de Oliveira,
Valentin Schneider
On Fri, 12 Jan 2024 at 17:24, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> With a *working* kernel, I get events, setting the frequency to either
> 2.2GHz (idle) or 3.8GHz (work).
Just to fix that - not 3.8Ghz, but in addition to 2.2 I see 2.8 or 3.7:
...
<idle>-0 [034] d.s.. 208.340412: cpu_frequency:
state=2200000 cpu_id=34
cc1-101686 [034] d.h.. 208.342402: cpu_frequency:
state=2800000 cpu_id=34
cc1-101686 [034] d.h.. 208.343401: cpu_frequency:
state=3700000 cpu_id=34
sh-108794 [029] d.h.. 216.401014: cpu_frequency:
state=2200000 cpu_id=29
sh-108794 [029] d.... 216.402670: cpu_frequency:
state=2800000 cpu_id=29
genksyms-108565 [029] d.h.. 216.404005: cpu_frequency:
state=3700000 cpu_id=29
...
etc.
Linus
^ permalink raw reply [relevance 99%]
* Heads up - effectively offline for now
@ 2024-01-13 21:31 99% Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-13 21:31 UTC (permalink / raw)
To: Greg Kroah-Hartman, Andrew Morton, Christian Brauner, Al Viro,
Thomas Gleixner
Cc: Linux Kernel Mailing List
Just a note to say that the merge window is paused as far as I'm
concerned, because we've lost power and internet thanks to a winter
storm. Of course, this is Oregon, so "storm" here is what some people
would probably consider "somewhat windy", and "winter" here means that
the temperature is approaching -10°C.
There's apparently about 100k people without power, and I doubt our
neighborhood is the priority, so I expect to be without power for some
time still. I hope I'm wrong, but a few years ago it took more than a
week to restore power due to all the downed trees. It's hopefully
nowhere near that, but..
And before anybody says "just go to a Starbucks and work from there",
the scariest thing out there - apart from possibly downed trees and
power lines - is other drivers. I'll stay put.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Backlight for v6.8
@ 2024-01-17 23:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-17 23:38 UTC (permalink / raw)
To: Lee Jones; +Cc: Linux Kernel Mailing List, Daniel Thompson
On Tue, 16 Jan 2024 at 08:42, Lee Jones <lee@kernel.org> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git backlight-next-6.8
-ENOSUCHTAG.
Did you forget to push out?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PULL REQUEST] i2c-for-6.8-rc1-fixed
@ 2024-01-18 0:02 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-18 0:02 UTC (permalink / raw)
To: Wolfram Sang, Linus Torvalds, linux-i2c, linux-kernel,
Peter Rosin, Bartosz Golaszewski, Andi Shyti, Kim Phillips
On Wed, 17 Jan 2024 at 13:30, Wolfram Sang <wsa@kernel.org> wrote:
>
> And a big series for the
> designware-driver needed to be reverted because issues have been
> reported late in the cycle and no incremental fix has been found yet.
> This is the fixed pull requested with a missing revert added.
Honestly, with three quarters of the commits being the broken series,
followed by reverting it, I get the feeling that this would be better
rebased.
I don't like rebasing, but I also don't like "look, we had most of
these commits broken, so we just reverted them all" all noticed before
it even hits my tree.
So I really feel like at that point you go "this branch was a failure"
and start anew - aka rebase. Along with a big explanation of why a
recent rebase ended up happening, so that there is no confusion about
it.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] power-supply changes for 6.8
@ 2024-01-18 0:11 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-18 0:11 UTC (permalink / raw)
To: Nathan Chancellor; +Cc: Sebastian Reichel, linux-kernel, linux-pm
On Wed, 17 Jan 2024 at 10:00, Nathan Chancellor <nathan@kernel.org> wrote:
>
> This is missing a fix for building with older compilers:
Dropped from my queue, will wait for a fixed pull request. Thanks for noticing,
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] dma-mapping fixes for Linux 6.8
@ 2024-01-19 0:52 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-19 0:52 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel, iommu
On Wed, 17 Jan 2024 at 23:30, Christoph Hellwig <hch@infradead.org> wrote:
>
> are available in the Git repository at:
>
> git.infradead.org:public_git/dma-mapping.git tags/dma-mapping-6.8-2024-01-18
Yeah, that doesn't work at all. Please fix your scripts to use the
proper public facing side like
git://git.infradead.org/users/hch/dma-mapping tags/dma-mapping-6.8-2024-01-18
instead of the ssh address you use to upload there.
I've pulled from the proper place, but please don't make me do that
for all your pulls.
In fact, this is the first time this happened, so you must have
changed some workflow for the worse..
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] strlcpy removal for v6.8-rc1
@ 2024-01-19 22:00 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-19 22:00 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, Andrew Morton, Andy Shevchenko, Andy Whitcroft,
Azeem Shaikh, Brian Foster, Dwaipayan Ray, Joe Perches,
Kent Overstreet, linux-bcachefs, linux-hardening, Lukas Bulwahn
On Fri, 19 Jan 2024 at 13:14, Kees Cook <keescook@chromium.org> wrote:
>
> The kernel is now free of the strlcpy() API!
.. still mentioned in docs and checkpatch. Maybe remove that too?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] strlcpy removal for v6.8-rc1
@ 2024-01-19 23:59 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-19 23:59 UTC (permalink / raw)
To: Kees Cook
Cc: linux-kernel, Andrew Morton, Andy Shevchenko, Andy Whitcroft,
Azeem Shaikh, Brian Foster, Dwaipayan Ray, Joe Perches,
Kent Overstreet, linux-bcachefs, linux-hardening, Lukas Bulwahn
On Fri, 19 Jan 2024 at 14:53, Kees Cook <keescook@chromium.org> wrote:
>
> Sorry, I should have called that out in the PR, but the commit itself
> had my rationale for intentionally leaving those in:
>
> Leave mentions in Documentation (about its deprecation), and in
> checkpatch.pl (to help migrate host-only tools/ usage).
Hmm. Yeah, I guess the host tooling is an issue, although there
strlcpy makes a lot more sense since I think it exists in various user
space libraries (while strscpy() is kernel-only).
> If you feel like that's not right, I can either respin or send a
> follow-up patch?
Oh, I already took the pull request, I was just reacting to leftovers.
This is not a big deal.
Linus
^ permalink raw reply [relevance 99%]
* Re: [RFC PATCH v3 11/11] mseal:add documentation
@ 2024-01-20 16:40 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-20 16:40 UTC (permalink / raw)
To: Theo de Raadt
Cc: Jeff Xu, Stephen Röttger, Jeff Xu, akpm, keescook, jannh,
willy, gregkh, jorgelo, groeck, linux-kernel, linux-kselftest,
linux-mm, pedro.falcato, dave.hansen, linux-hardening
On Sat, 20 Jan 2024 at 07:23, Theo de Raadt <deraadt@openbsd.org> wrote:
>
> There is an one large difference remainig between mimmutable() and mseal(),
> which is how other system calls behave.
>
> We return EPERM for failures in all the system calls that fail upon
> immutable memory (since Oct 2022).
>
> You are returning EACESS.
>
> Before it is too late, do you want to reconsider that return value, or
> do you have a justification for the choice?
I don't think there's any real reason for the difference.
Jeff - mind changing the EACESS to EPERM, and we'll have something
that is more-or-less compatible between Linux and OpenBSD?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH next v4 0/5] minmax: Relax type checks in min() and max().
@ 2024-01-20 21:33 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-20 21:33 UTC (permalink / raw)
To: David Laight
Cc: Stephen Rothwell, Jiri Slaby, linux-kernel, Andy Shevchenko,
Andrew Morton, Matthew Wilcox (Oracle),
Christoph Hellwig, Jason A. Donenfeld
[ Going through some pending issues now that I've mostly emptied my pull queue ]
On Wed, 10 Jan 2024 at 14:58, David Laight <David.Laight@aculab.com> wrote:
>
> The first check in __types_ok() can go, the second one (with the '+ 0')
> (added to promote char to int) includes the first one.
That turns out to not be true. An expression like
min(u8, unsigned int)
is fine because the underlying types are compatible.
But the promotion to 'int' makes the first argument be a signed
integer, and is no longer compatible with the second argument.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)
@ 2024-01-21 19:57 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-21 19:57 UTC (permalink / raw)
To: Hans Verkuil
Cc: Aurelien Jarno, linux-kernel, Bluecherry Maintainers,
Anton Sviridenko, Andrey Utkin, Ismael Luceno,
Mauro Carvalho Chehab, open list:SOFTLOGIC 6x10 MPEG CODEC,
Andy Shevchenko', Andrew Morton',
Matthew Wilcox, Christoph Hellwig',
Jason A . Donenfeld, Jiri Slaby, stable, David Laight
On Sun, 14 Jan 2024 at 03:04, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> I'll pick this up as a fix for v6.8.
>
> Linus, if you prefer to pick this up directly, then that's fine as well.
Bah, missed this email, and so a belated note that I picked the patch
up as commit 31e97d7c9ae3.
It even got your Reviewed-by thanks to b4 picking that up automatically.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] More bcachefs updates for 6.8-rc1
@ 2024-01-21 22:05 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-21 22:05 UTC (permalink / raw)
To: Kent Overstreet; +Cc: linux-bcachefs, linux-fsdevel, linux-kernel
On Sun, 21 Jan 2024 at 13:35, Kent Overstreet <kent.overstreet@linux.dev> wrote:
>
> Hi Linus, another small bcachefs pull. Some fixes, Some refactoring,
> some minor features.
I'm taking this, but only because bcachefs is new.
You need to be aware that the merge window is for *merging*. Not for
new development.
And almost all of the code here is new development.
What you send during the merge window is stuff that should all have
been ready *before* the merge window opened, not whatever random
changes you made during it.
Now, fixes happen any time, but for that argument to work they need to
be real fixes. Not "reorganize the code to make things easier to fix"
with the fix being something small on top of a big change.
Linus
^ permalink raw reply [relevance 99%]
* Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and directories all be the same
@ 2024-01-22 17:39 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-22 17:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Geert Uytterhoeven, Kees Cook, linux-kernel, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Christian Brauner, Al Viro, Ajay Kaher
On Mon, 22 Jan 2024 at 09:37, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Yeah, limiting it to directories will at least somewhat help the
> address leaking.
Actually, why not juist add an inode number to your data structures,
at least for directories? And just do a static increment on it as they
get registered?
That avoids the whole issue with possibly leaking kernel address data.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3 1/2] eventfs: Have the inodes all for files and directories all be the same
@ 2024-01-22 22:02 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-22 22:02 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers,
Christian Brauner, Al Viro, Ajay Kaher, linux-fsdevel
On Mon, 22 Jan 2024 at 13:59, Darrick J. Wong <djwong@kernel.org> 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 trivially brute-forceable).
See
https://lore.kernel.org/all/20240122152748.46897388@gandalf.local.home/
for the current patch under discussion (and it contains a link _to_
said discussion).
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Btrfs fixes for 6.8-rc2
@ 2024-01-22 22:34 99% ` Linus Torvalds
2024-01-22 22:54 99% ` Linus Torvalds
1 sibling, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-22 22:34 UTC (permalink / raw)
To: David Sterba; +Cc: linux-btrfs, linux-kernel
On Mon, 22 Jan 2024 at 10:34, David Sterba <dsterba@suse.com> wrote:
>
> please pull the following fixes.
Bah. These fixes are garbage. Now my machine doesn't even boot. I'm
bisecting, but it's between
good: e94dfb7a2935 ("btrfs: pass btrfs_io_geometry into btrfs_max_io_len")
bad: f398e70dd69e ("btrfs: tree-checker: fix inline ref size in error messages")
Not ok.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Btrfs fixes for 6.8-rc2
2024-01-22 22:34 99% ` Linus Torvalds
@ 2024-01-22 22:54 99% ` Linus Torvalds
2024-01-22 23:01 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-22 22:54 UTC (permalink / raw)
To: David Sterba, Qu Wenruo; +Cc: linux-btrfs, linux-kernel
On Mon, 22 Jan 2024 at 14:34, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Bah. These fixes are garbage. Now my machine doesn't even boot. I'm
> bisecting
My bisection says
1e7f6def8b2370ecefb54b3c8f390ff894b0c51b is the first bad commit
but I'll still have to verify by testing the revert on top of my current tree.
It did revert cleanly, but I also note that if the zstd case is wrong,
I assume the other very similar commits (for zlib and lzo) are
potentially also wrong.
Let me reboot to verify that at least my machine boots.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Btrfs fixes for 6.8-rc2
2024-01-22 22:54 99% ` Linus Torvalds
@ 2024-01-22 23:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-22 23:01 UTC (permalink / raw)
To: David Sterba, Qu Wenruo; +Cc: linux-btrfs, linux-kernel
On Mon, 22 Jan 2024 at 14:54, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Let me reboot to verify that at least my machine boots.
My tree with that commit reverted does indeed boot:
Revert "btrfs: zstd: fix and simplify the inline extent decompression"
is working ok for me.
I do not think I have anything odd in my Kconfig, and I didn't see any
messages, and there is nothing logged either - just a hang at boot.
Linus
^ permalink raw reply [relevance 99%]
* Re: [BUG] BUG: kernel NULL pointer dereference at ttm_device_init+0xb4
@ 2024-01-23 0:43 99% ` Linus Torvalds
[not found] ` <27c3d1e9-5933-47a9-9c33-ff8ec13f40d3@amd.com>
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-23 0:43 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Rajneesh Bhardwaj, Felix Kuehling, Christian König, dri-devel
On Mon, 22 Jan 2024 at 15:17, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Perhaps this is the real fix?
If you send a signed-off version, I'll apply it asap.
Thanks,
Linus
^ permalink raw reply [relevance 99%]
* Re: [BUG] BUG: kernel NULL pointer dereference at ttm_device_init+0xb4
[not found] ` <27c3d1e9-5933-47a9-9c33-ff8ec13f40d3@amd.com>
@ 2024-01-23 1:25 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-23 1:25 UTC (permalink / raw)
To: Bhardwaj, Rajneesh
Cc: Steven Rostedt, LKML, Felix Kuehling, Christian König, dri-devel
On Mon, 22 Jan 2024 at 16:56, Bhardwaj, Rajneesh
<rajneesh.bhardwaj@amd.com> wrote:
>
> I think a fix might already be in flight. Please see Linux-Kernel Archive: Re: [PATCH] drm/ttm: fix ttm pool initialization for no-dma-device drivers (iu.edu)
Please use lore.kernel.org that doesn't corrupt whitespace in patches
or lose header information:
https://lore.kernel.org/lkml/20240113213347.9562-1-pchelkin@ispras.ru/
although that seems to be a strange definition of "in flight". It was
sent out 8 days ago, and apparently nobody thought to include it in
the drm fixes pile that came in last Friday.
So it made it into rc1, even though it was reported a week before.
It also looks like some mailing list there is mangling emails - if you
use 'all' instead of 'lkml', lore reports multiple emails with the
same message-id, and it all looks messier as a result.
I assume it's dri-devel@lists.freedesktop.org that messes up, mainly
because I don't tend to see this behaviour when only the usual
kernel.org mailing lists are involved.
Linus
^ permalink raw reply [relevance 99%]
* Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper
@ 2024-01-24 16:46 99% ` Linus Torvalds
2024-01-24 16:54 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-24 16:46 UTC (permalink / raw)
To: Kees Cook
Cc: Kevin Locke, John Johansen, Josh Triplett, Mateusz Guzik,
Al Viro, linux-mm, linux-fsdevel, linux-kernel,
linux-security-module
On Wed, 24 Jan 2024 at 08:35, Kees Cook <keescook@chromium.org> wrote:
>
> Oh, yikes. This means the LSM lost the knowledge that this open is an
> _exec_, not a _read_.
>
> I will starting looking at this. John might be able to point me in the
> right direction more quickly, though.
One obvious change in -rc1 is that the exec open was moved much
earlier: commit 978ffcbf00d8 ("execve: open the executable file before
doing anything else").
If the code ends up deciding "is this an exec" based on some state
flag that hasn't been set, that would explain it.
Something like "current->in_execve", perhaps?
Linus
^ permalink raw reply [relevance 99%]
* Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper
2024-01-24 16:46 99% ` Linus Torvalds
@ 2024-01-24 16:54 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-24 16:54 UTC (permalink / raw)
To: Kees Cook
Cc: Kevin Locke, John Johansen, Josh Triplett, Mateusz Guzik,
Al Viro, linux-mm, linux-fsdevel, linux-kernel,
linux-security-module
On Wed, 24 Jan 2024 at 08:46, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> If the code ends up deciding "is this an exec" based on some state
> flag that hasn't been set, that would explain it.
>
> Something like "current->in_execve", perhaps?
Yeah, that looks like exactly what some of the security layer is testing.
Hmm. That whole thing is disgusting. I think it should have checked
FMODE_EXEC, and I have no idea why it doesn't.
Linus
^ permalink raw reply [relevance 99%]
* Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper
@ 2024-01-24 17:27 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-24 17:27 UTC (permalink / raw)
To: Kees Cook
Cc: Kevin Locke, John Johansen, Josh Triplett, Mateusz Guzik,
Al Viro, linux-mm, linux-fsdevel, linux-kernel,
linux-security-module
On Wed, 24 Jan 2024 at 09:21, Kees Cook <keescook@chromium.org> wrote:
>
> I opted to tie "current->in_execve" lifetime to bprm lifetime just to
> have a clean boundary (i.e. strictly in alloc/free_bprm()).
Honestly, the less uinnecessary churn that horrible flag causes, the better.
IOW, I think the goal here should be "minimal fix" followed by "remove
that horrendous thing".
Linus
^ permalink raw reply [relevance 99%]
* Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper
@ 2024-01-24 18:29 99% ` Linus Torvalds
2 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-24 18:29 UTC (permalink / raw)
To: Kees Cook, Kentaro Takeda, Tetsuo Handa, John Johansen, Paul Moore
Cc: Kevin Locke, Josh Triplett, Mateusz Guzik, Al Viro, linux-mm,
linux-fsdevel, linux-kernel, linux-security-module
On Wed, 24 Jan 2024 at 10:27, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> UNTESTED
.. and just to check who is awake, I used 'file->f_flags &
__FMODE_EXEC' in tomoyo when 'file' doesn't exist as a variable.
It should be 'f->f_flags & __FMODE_EXEC'.
That way it at least compiles.
Linus
^ permalink raw reply [relevance 99%]
* Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper
@ 2024-01-24 19:41 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-24 19:41 UTC (permalink / raw)
To: Kees Cook
Cc: Kentaro Takeda, Tetsuo Handa, John Johansen, Paul Moore,
Kevin Locke, Josh Triplett, Mateusz Guzik, Al Viro, linux-mm,
linux-fsdevel, linux-kernel, linux-security-module
On Wed, 24 Jan 2024 at 11:02, Kees Cook <keescook@chromium.org> wrote:
>
> Yup. Should I post a formal patch, or do you want to commit what you've
> got (with the "file" -> "f" fix)?
I took your formal patch. Thanks,
Linus
^ permalink raw reply [relevance 99%]
* Re: [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper
@ 2024-01-25 17:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-25 17:17 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Kees Cook, John Johansen, Paul Moore, Kevin Locke, Josh Triplett,
Mateusz Guzik, Al Viro, linux-mm, linux-fsdevel, linux-kernel,
linux-security-module, Kentaro Takeda
On Thu, 25 Jan 2024 at 06:17, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2024/01/25 3:27, Linus Torvalds wrote:
> > The whole cred use of current->in_execve in tomoyo should
> > *also* be fixed, but I didn't even try to follow what it actually
> > wanted.
>
> Due to TOMOYO's unique domain transition (transits to new domain before
> execve() succeeds and returns to old domain if execve() failed), TOMOYO
> depends on a tricky ordering shown below.
Ok, that doesn't really clarify anything for me.
I'm less interested in what the call paths are, and more like "_Why_
is all this needed for tomoyo?"
Why doesn't tomoyo just install the new cred at "commit_creds()" time?
(The security hooks that surround that are
"->bprm_committing_creds()" and "->bprm_committed_creds()")
IOW, the whole "save things across two *independent* execve() calls"
seems crazy.
Very strange and confusing.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] eventfs: Give files a default of PAGE_SIZE size
@ 2024-01-26 18:31 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-26 18:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
Christian Brauner, Ajay Kaher, Geert Uytterhoeven, linux-fsdevel
On Fri, 26 Jan 2024 at 10:18, Steven Rostedt <rostedt@goodmis.org> 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 anyway.
It hasn't worked before, so saying "now you can use tar" is just a
*bad* idea. There is no upside, only downsides, with tar either (a)
not working at all on older kernels or (b) complaining about how the
size isn't reliable on newer ones.
So please. You should *NOT* look at "this makes tar work, albeit badly".
You should look at whether it improves REAL LOADS. And it doesn't. All
it does is add a hack for a bad idea. Leave it alone.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] eventfs: Give files a default of PAGE_SIZE size
@ 2024-01-26 19:06 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-26 19:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Linux Trace Kernel, Masami Hiramatsu, Mathieu Desnoyers,
Christian Brauner, Ajay Kaher, Geert Uytterhoeven, linux-fsdevel
On Fri, 26 Jan 2024 at 10:41, Steven Rostedt <rostedt@goodmis.org> 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 actually prettier than the odd fixed date-based one
you picked. I assume it's your birthdate (although I don't know what
the directory ino number was).
Linus
^ permalink raw reply [relevance 99%]
* Re: [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and directories all be the same
@ 2024-01-26 19:09 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-26 19:09 UTC (permalink / raw)
To: Steven Rostedt
Cc: Christian Brauner, Geert Uytterhoeven, Kees Cook, linux-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Al Viro, Ajay Kaher
On Fri, 26 Jan 2024 at 08:26, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 26 Jan 2024 11:11:39 +0100
> Christian Brauner <brauner@kernel.org> wrote:
>
> > The size would be one thing. The other is that tar requires unique inode
> > numbers for all files iirc (That's why we have this whole btrfs problem
> > - let's not get into this here - where inode numbers aren't unique and
> > are duplicated per subvolume.).
>
> Well, I guess that answers Linus's question about wondering if there's any
> user space program that actually cares what the inodes are for files. The
> answer is "yes" and the program is "tar".
Well, the fact that it hits snapshots, shows that the real problem is
just "tar does stupid things that it shouldn't do".
Yes, inode numbers used to be special, and there's history behind it.
But we should basically try very hard to walk away from that broken
history.
An inode number just isn't a unique descriptor any more. We're not
living in the 1970s, and filesystems have changed.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Enable -Wstringop-overflow globally
@ 2024-01-26 21:22 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-26 21:22 UTC (permalink / raw)
To: Gustavo A. R. Silva; +Cc: Kees Cook, linux-hardening, linux-kernel
On Mon, 22 Jan 2024 at 07:29, Gustavo A. R. Silva <gustavoars@kernel.org> wrote:
>
> Enable -Wstringop-overflow globally
I suspect I'll have to revert this.
On arm64, I get a "writing 16 bytes into a region of size 0" in the Xe driver
drivers/gpu/drm/xe/xe_gt_pagefault.c:340
but I haven't looked into it much yet.
It's not some gcc-11 issue, though, this is with gcc version 13.2.1
It looks like the kernel test robot reported this too (for s390), at
https://lore.kernel.org/all/202401161031.hjGJHMiJ-lkp@intel.com/T/
and in that case it was gcc-13.2.0.
So I don't think the issue is about gcc-11 at all, but about other
random details.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Btrfs fixes for 6.8-rc2
@ 2024-01-26 21:51 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-26 21:51 UTC (permalink / raw)
To: Qu Wenruo; +Cc: dsterba, David Sterba, linux-btrfs, linux-kernel
On Fri, 26 Jan 2024 at 13:39, Qu Wenruo <wqu@suse.com> wrote:
>
> Oh, I forgot the most obvious problem.
>
> This means the extent buffer is full of garbage.
Allocation lifetime problems?
> What's the page size of the system? 4K or 16K or 64K?
This is a bog-standard x86-64 system. With 32 cores (and 64 threads),
but there's nothing remotely odd about it, except for the fact that
it's running a very recent kernel...
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Btrfs fixes for 6.8-rc2
@ 2024-01-26 22:02 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-26 22:02 UTC (permalink / raw)
To: Qu Wenruo; +Cc: dsterba, David Sterba, linux-btrfs, linux-kernel
On Fri, 26 Jan 2024 at 13:56, Qu Wenruo <wqu@suse.com> wrote:
>
> On 2024/1/27 08:21, Linus Torvalds wrote:
> >
> > Allocation lifetime problems?
>
> Could be, thus it may be better to output the flags of the first page
> for tree-checker.
Note that the fact that it magically went away certainly implies that
it never "really" existed, and that something was using a pointer or
similar.
IOW, this is not some IO that got scribbled over, or a cache that got
corrupted. If it had been real corruption, I would have expected that
it would have stayed around in memory.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] eventfs: Have inodes have unique inode numbers
@ 2024-01-26 22:29 99% ` Linus Torvalds
1 sibling, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-26 22:29 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Steven Rostedt, LKML, Linux Trace Devel, Masami Hiramatsu,
Christian Brauner, Ajay Kaher, Geert Uytterhoeven, linux-fsdevel
On Fri, 26 Jan 2024 at 14:14, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> I do however have a concern with the approach of using the same
> inode number for various files on the same filesystem: AFAIU it
> breaks userspace ABI expectations.
Virtual filesystems have always done that in various ways.
Look at the whole discussion about the size of the file. Then look at /proc.
And honestly, eventfs needs to be simplified. It's a mess. It's less
of a mess than it used to be, but people should *NOT* think that it's
a real filesystem.
Don't use some POSIX standard as an expectation for things like /proc,
/sys or tracefs.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Enable -Wstringop-overflow globally
@ 2024-01-26 22:36 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-26 22:36 UTC (permalink / raw)
To: Kees Cook
Cc: Gustavo A. R. Silva, Gustavo A. R. Silva, linux-hardening, linux-kernel
On Fri, 26 Jan 2024 at 14:24, Kees Cook <keescook@chromium.org> wrote:
>
> I think xe has some other weird problems too. This may be related (under
> allocating):
>
> ../drivers/gpu/drm/xe/xe_vm.c: In function 'xe_vma_create':
> ../drivers/gpu/drm/xe/xe_vm.c:806:21: warning: allocation of insufficient size '224' for type 'struct xe_vma' with size '368' [-Walloc-size]
> 806 | vma = kzalloc(sizeof(*vma) - sizeof(struct xe_userptr),
> | ^
That code is indeed odd, but there's a comment in the xe_vma definition
/**
* @userptr: user pointer state, only allocated for VMAs that are
* user pointers
*/
struct xe_userptr userptr;
although I agree that it should probably simply be made a final
variably-sized array instead (and then you make that array size be
0/1).
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] eventfs: Have inodes have unique inode numbers
@ 2024-01-26 22:49 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-26 22:49 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Steven Rostedt, LKML, Linux Trace Devel, Masami Hiramatsu,
Christian Brauner, Ajay Kaher, Geert Uytterhoeven, linux-fsdevel
On Fri, 26 Jan 2024 at 14:41, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> Yes, there is even a note about stat.st_size in inode(7) explaining
> this:
Good. Send a patch to do the same for st_ino.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] eventfs: Have inodes have unique inode numbers
@ 2024-01-26 23:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-26 23:17 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mathieu Desnoyers, Steven Rostedt, LKML, Linux Trace Devel,
Masami Hiramatsu, Christian Brauner, Ajay Kaher,
Geert Uytterhoeven, linux-fsdevel
On Fri, 26 Jan 2024 at 15:11, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, 26 Jan 2024 at 15:04, Matthew Wilcox <willy@infradead.org> wrote:
> >
> > Maybe we should take advantage of that historical oddity. All files
> > in eventfs have inode number 0, problem solved.
>
> That might not be a horrible idea.
Note the "might". I don't know why glibc would have special-cased
st_ino of 0, but I suspect it's some internal oddity in the readdir()
implementation.
So considering that we do have that commit 2adc376c5519, I suspect it
would just be more pain than its worth to try to teach user space
about the whole "no inode number" thing.
It might be safer to pick something like -1 instead.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] MIPS fixes for v6.8
@ 2024-01-28 18:46 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-28 18:46 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, linux-kernel
On Sun, 28 Jan 2024 at 05:28, Thomas Bogendoerfer
<tsbogend@alpha.franken.de> wrote:
>
> - fix missing prototypes issues
This pull request could definitely have mentioned this part of the commit:
"Also drop ip27-hubio.c as it's not used for a long time"
because I saw this in the diffstat:
> arch/mips/sgi-ip27/ip27-hubio.c | 185 -----------------------------
and had to go look at what was going on.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH next 10/11] block: Use a boolean expression instead of max() on booleans
@ 2024-01-28 19:59 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-28 19:59 UTC (permalink / raw)
To: David Laight
Cc: linux-kernel, Netdev, dri-devel, Andy Shevchenko, Andrew Morton,
Matthew Wilcox (Oracle),
Christoph Hellwig, Dan Carpenter, Linus Walleij,
David S . Miller, linux-btrfs, Jens Axboe
On Sun, 28 Jan 2024 at 11:36, David Laight <David.Laight@aculab.com> wrote:
>
> However it generates:
> error: comparison of constant ‘0’ with boolean expression is always true [-Werror=bool-compare]
> inside the signedness check that max() does unless a '+ 0' is added.
Please fix your locale. You have random garbage characters there,
presumably because you have some incorrect locale setting somewhere in
your toolchain.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] eventfs: Have inodes have unique inode numbers
@ 2024-01-29 4:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-29 4:01 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu, Mathieu Desnoyers, LKML, Linux Trace Devel,
Christian Brauner, Ajay Kaher, Geert Uytterhoeven, linux-fsdevel
On Sun, 28 Jan 2024 at 19:40, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> [ 106.258400] BUG: KASAN: slab-use-after-free in tracing_open_file_tr+0x3a/0x120
> [ 106.261228] Read of size 8 at addr ffff8881136f27b8 by task cat/868
Are you refcounting the pointers that you have in the dentries (and
inodes)? Like we talked about you needing to do?
Every time you assign a pointer to d_fsdata, you need to kref_get() it.
You try to work around the tracefs weaknesses by trying to clean up
the dentry data, but it's WRONG.
You should refcount the data properly, so that you don't NEED to clean it out.
Linus
^ permalink raw reply [relevance 99%]
* Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address
@ 2024-01-29 17:56 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-29 17:56 UTC (permalink / raw)
To: Steven Rostedt
Cc: kernel test robot, oe-lkp, lkp, linux-kernel, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Christian Brauner, Al Viro,
Ajay Kaher, linux-trace-kernel
On Mon, 29 Jan 2024 at 09:44, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 29 Jan 2024 09:40:06 -0800
> Linus Torvalds <torvalds@linux-foundation.org> 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 particular
> > issue.
>
> Would you be OK if I did both as a "fix"?
See my crossed email - not dropping the mutex *is* actually a fix for
another piece of data.
Linus
^ permalink raw reply [relevance 99%]
* Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address
@ 2024-01-30 0:01 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-30 0:01 UTC (permalink / raw)
To: Steven Rostedt
Cc: kernel test robot, oe-lkp, lkp, linux-kernel, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Christian Brauner, Al Viro,
Ajay Kaher, linux-trace-kernel
On Mon, 29 Jan 2024 at 14:49, Steven Rostedt <rostedt@goodmis.org> 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 negative one) with
tracefs_start_creating() -> lookup_one_len().
So yes, there d_instantiate() is correct, as it's exactly that "turn
negative dentry into a positive one" case.
I'll go see what's up with the "create it again" case - I don't
immediately see what's wrong.
Linus
^ permalink raw reply [relevance 99%]
* Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address
@ 2024-01-30 16:51 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-30 16:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: kernel test robot, oe-lkp, lkp, linux-kernel, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Christian Brauner, Al Viro,
Ajay Kaher, linux-trace-kernel
On Tue, 30 Jan 2024 at 06:39, Steven Rostedt <rostedt@goodmis.org> 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 do that because that happens for every event
> directory.
I wasn't thinking straight yesterday - the real fix is to just do a
"d_revalidate()". It's literally why that thing exists: check whether
a dentry is still valid.
In fact, that trivially gets rid of the 'events' subdirectory issues
too, so we can stop doing that horrendous simple_recursive_removal()
too.
Let me reboot into the trivial fix. I just needed to think about this
the right way.
None of this is anything that the VFS layer has any problems with.
Linus
^ permalink raw reply [relevance 99%]
* Re: [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address
@ 2024-01-30 16:55 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-30 16:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: kernel test robot, oe-lkp, lkp, linux-kernel, Masami Hiramatsu,
Mark Rutland, Mathieu Desnoyers, Christian Brauner, Al Viro,
Ajay Kaher, linux-trace-kernel
On Tue, 30 Jan 2024 at 08:49, Steven Rostedt <rostedt@goodmis.org> 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 that to do a lookup walking back down to the
> eventfs_inode I want to delete. This gives me the dentry that I can call
> d_invalidate() on.
Yes, that works.
However, I have a patch that is *much* smaller and simpler, and
doesn't need that walk.
The VFS layer already has a good interface for "should I still use
this dentry", which is needed for various network filesystems etc that
want to time out caches (or check explicitly whether the file still
exists etc): it's the dentry d_revalidate() check.
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.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 3/8] workqueue: Implement BH workqueues to eventually replace tasklets
@ 2024-01-30 17:25 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-30 17:25 UTC (permalink / raw)
To: Tejun Heo
Cc: mpatocka, linux-kernel, dm-devel, msnitzer, ignat, damien.lemoal,
bob.liu, houtao1, peterz, mingo, netdev, allen.lkml, kernel-team
On Tue, 30 Jan 2024 at 01:13, Tejun Heo <tj@kernel.org> wrote:
>
> This patch implements BH workqueues which share the same semantics and
> features of regular workqueues but execute their work items in the softirq
> context.
Thanks for doing this. Honestly, while I felt this was a natural thing
to do and would clean things up, every time I look at the workqueue
code I just shudder and go "I'm sure Tejun can work this out".
Patches look fine to me - I'd love to actually have the dm-crypt
people (and networking people, for that matter) verify that there are
no performance gotchas from the slightly heavier (but more generic)
workqueue interfaces.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 6/6] eventfs: clean up dentry ops and add revalidate function
@ 2024-01-30 21:36 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-30 21:36 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Masami Hiramatsu, linux-kernel, linux-trace-kernel
On Tue, 30 Jan 2024 at 13:25, Steven Rostedt <rostedt@goodmis.org> 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 over again in short spurts.
Sure. I think this is literally a tuning thing, and we'll see if
anybody ever says "the dentry cache grows too much with tracefs".
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts
@ 2024-01-30 22:58 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-30 22:58 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Masami Hiramatsu, linux-kernel, linux-trace-kernel
On Tue, 30 Jan 2024 at 14:55, Steven Rostedt <rostedt@goodmis.org> 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
> pointer size, and it's a savings of 22KB per instance. And in actuality, I
> should have rounded to the nearest kmalloc slab size as kzalloc() isn't going to
> return 35 bytes back but 64 bytes will be allocated.
No. See my other email. The kmalloc sizes actually means that it comes
out exactly even.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts
@ 2024-01-30 23:06 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-01-30 23:06 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Masami Hiramatsu, linux-kernel, linux-trace-kernel
On Tue, 30 Jan 2024 at 14:56, Linus Torvalds
<torvalds@linux-foundation.org> 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 eventfs_attr'
is 12 bytes and 4-byte aligned.
So if you pack all the 8-byte-aligned fields at the beginning, and the
4-byte-aligned ones at the end, you get 88 bytes.
At which point a name pointer would *just* fit in 96 bytes.
... and then some debug option is enabled, and it all goes to hell again.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts
@ 2024-01-30 23:25 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-30 23:25 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Masami Hiramatsu, linux-kernel, linux-trace-kernel
On Tue, 30 Jan 2024 at 15:10, Steven Rostedt <rostedt@goodmis.org> 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 one
slab entry on both x86-64 and arm64 (now that arm finally does sane
kmalloc sizes - for the longest time they were all 128-byte aligned
due to historical horrible DMA coherency issues).
But you might also add a comment to the eventfs_inode definition,
because if that ever changes, the math changes again. For example,
adding just one more attribute data would make it all fall apart.
If you *really* want to optimize that data structure, I think you can
make the child list be a 'hlist'. That makes the list head ('children'
becomes a 'hlist_head') smaller, even if the list entry ('list'
becomes a 'hlist_node') stays the same size.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 3/6] tracefs: dentry lookup crapectomy
@ 2024-01-31 0:39 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-31 0:39 UTC (permalink / raw)
To: Al Viro
Cc: Steven Rostedt, Masami Hiramatsu, linux-kernel, linux-trace-kernel
On Tue, 30 Jan 2024 at 16:23, Al Viro <viro@zeniv.linux.org.uk> 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
> > dentry = dentry->d_parent;
> > @@ -247,7 +246,6 @@ static struct eventfs_inode *eventfs_find_events(struct dentry *dentry)
> > }
> > // Walk upwards until you find the events inode
> > } while (!ei->is_events);
> > - mutex_unlock(&eventfs_mutex);
>
> Unless I'm missing something, you've just lost exclusion with
> removals (not that the original hadn't been suspicious in that
> respect - what's to protect ei past that mutex_unlock?
No, the mutex is actually taken up the call chain, and removing it
here is fixing a deadlock.
Ie we have the mutex taken in eventfs_root_lookup(), and then that
goes either through lookup_dir_entry() or lookup_file_dentry(), before
it gets to update_inode_attr().
That series is not very clean, I'm afraid.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 6/6] eventfs: clean up dentry ops and add revalidate function
@ 2024-01-31 2:37 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-31 2:37 UTC (permalink / raw)
To: Al Viro
Cc: Steven Rostedt, Masami Hiramatsu, linux-kernel, linux-trace-kernel
On Tue, 30 Jan 2024 at 17:12, Al Viro <viro@zeniv.linux.org.uk> 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 stale case.
>
> Looks like use after free, unless freeing ei is RCU-delayed...
We hold the ref to the ei in the very dentry that is doing d_revalidate().
So it should be fine. The race is with eventfs marking the ei
'is_freed' (under the mutex that we don't hold here), but when that
happens and we end up still using the dentry, the ei is still there,
all the operations are just going to fail.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts
@ 2024-01-31 5:57 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-31 5:57 UTC (permalink / raw)
To: Steven Rostedt; +Cc: Masami Hiramatsu, linux-kernel, linux-trace-kernel
On Tue, 30 Jan 2024 at 21:33, Steven Rostedt <rostedt@goodmis.org> 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() that calls simple_recursive_removal()
> that then walks into the "events" directory. Without that d_invalidate, it
> walks beyond just the top directory and then splats on the dentries that
> are cached.
Ugh.
This is only an issue for that "events" dir, right? The one that has a
proper refcount on the dentry in 'ei->events_dir'?
Because yes, then doing d_invalidate() looks like the right thing.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] SCSI fixes for 6.8-rc2
@ 2024-01-31 18:15 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-01-31 18:15 UTC (permalink / raw)
To: James Bottomley; +Cc: Andrew Morton, linux-scsi, linux-kernel
On Wed, 31 Jan 2024 at 06:12, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> 6 small fixes. 5 are obvious and in drivers the fifth is a core fix [..]
"Math is hard, let's go shopping"
Although I think even teen talk barbie could count past five.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 0/3] Handle delay slot for extable lookup
@ 2024-02-01 17:48 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-01 17:48 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Oleg Nesterov, Thomas Bogendoerfer, Andrew Morton, Ben Hutchings,
linux-arch, linux-kernel, linux-mips, linux-mm, Xi Ruoyao
On Thu, 1 Feb 2024 at 07:46, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> arch/alpha/include/asm/ptrace.h | 1 +
> arch/arc/include/asm/ptrace.h | 1 +
> arch/arm/include/asm/ptrace.h | 1 +
> arch/csky/include/asm/ptrace.h | 1 +
> arch/hexagon/include/uapi/asm/ptrace.h | 1 +
> arch/loongarch/include/asm/ptrace.h | 1 +
> arch/m68k/include/asm/ptrace.h | 1 +
> arch/microblaze/include/asm/ptrace.h | 3 ++-
> arch/mips/include/asm/ptrace.h | 2 ++
> arch/mips/kernel/ptrace.c | 7 +++++++
> arch/nios2/include/asm/ptrace.h | 3 ++-
> arch/openrisc/include/asm/ptrace.h | 1 +
> arch/parisc/include/asm/ptrace.h | 1 +
> arch/s390/include/asm/ptrace.h | 1 +
> arch/sparc/include/asm/ptrace.h | 2 ++
> arch/um/include/asm/ptrace-generic.h | 1 +
> mm/memory.c | 4 ++--
> 17 files changed, 28 insertions(+), 4 deletions(-)
The only user right now is mm/memory.c, and it doesn't even include
<asm/ptrace.h>, but instead does the proper thing and includes
<linux/ptrace.h>
So please make <linux/ptrace.h> just do
#ifndef exception_ip
#define exception_ip(x) instruction_pointer(x)
#endif
and all those non-MIPS architecture updates should just go away, and
the diffstat should look something like
arch/mips/kernel/ptrace.c | 7 +++++++
include/linux/ptrace.h | 4 ++++
mm/memory.c | 4 ++--
instead.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] perf tools fixes for v6.8
@ 2024-02-01 20:57 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-01 20:57 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ingo Molnar, Thomas Gleixner, Jiri Olsa, Namhyung Kim,
Ian Rogers, Adrian Hunter, Clark Williams, Kate Carcia,
linux-kernel, linux-perf-users, James Clark, Kan Liang,
Sun Haiyong, Thomas Richter, Yanteng Si, Yicong Yang,
Arnaldo Carvalho de Melo
On Thu, 1 Feb 2024 at 12:23, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Please consider pulling, mostly 'perf test' issues, which in its
> turn are mostly related to myself having Intel hybrid systems at home.
I started pulling, but there's some truly odd noise in the tag, so you
clearly have done something wrong.
You need to fix your odd tagging process, they are normally noisy, but
this is just so far off the norm that I can't overlook the craziness.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Kbuild fixes for v6.8-rc3
@ 2024-02-02 0:43 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-02-02 0:43 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: Linux Kernel Mailing List, Linux Kbuild mailing list
On Thu, 1 Feb 2024 at 15:57, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Is this your expectation?
Commit 82175d1f9430 touched *only* the nested 'if' indentations.
Your attached changed other indentations too, which I am not sure
makes any sense.
But honestly, that whole make rule wrt whitespace makes no sense to
begin with, and I don't know why the conditional statement is so
special to begin with, and why GNU make would then suddenly start
messing with an insane rule with bad historical reasons.
End result: all of this just reinforces how bad the Make rules for
whitespace is, but I would suggest doing the *minimal* changes to make
it work.
Which commit 82175d1f9430 did, but your attached patch then does not.
IOW, if the whole crazy makefile whitespace change was only about
conditionals, let's keep all the stupid whitespace fixups as purely
about conditionals too.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v8 0/4] Introduce mseal
@ 2024-02-02 3:29 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-02 3:29 UTC (permalink / raw)
To: Jeff Xu
Cc: Greg KH, Liam R. Howlett, Jonathan Corbet, akpm, keescook, jannh,
sroettger, willy, usama.anjum, rdunlap, jeffxu, jorgelo, groeck,
linux-kernel, linux-kselftest, linux-mm, pedro.falcato,
dave.hansen, linux-hardening
On Thu, 1 Feb 2024 at 19:24, Jeff Xu <jeffxu@chromium.org> wrote:
>
> The patch Stephan developed was based on V1 of the patch, IIRC, which
> is really ancient, and it is not based on MAP_SEALABLE, which is a
> more recent development entirely from me.
So the problem with this whole patch series from the very beginning
was that it was very specialized, and COMPLETELY OVER-ENGINEERED.
It got simpler at one point. And then you started adding these
features that have absolutely no reason for them. Again.
It's frustrating. And it's not making it more likely to be ever merged.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2 0/3] Handle delay slot for extable lookup
@ 2024-02-02 18:39 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-02-02 18:39 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Oleg Nesterov, Thomas Bogendoerfer, Andrew Morton, Ben Hutchings,
linux-arch, linux-kernel, linux-mips, linux-mm, Xi Ruoyao
On Fri, 2 Feb 2024 at 04:30, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> ptrace: Introduce exception_ip arch hook
> MIPS: Clear Cause.BD in instruction_pointer_set
> mm/memory: Use exception ip to search exception tables
Just to clarify: does that second patch fix the problem that
__isa_exception_epc() does a __get_user()?
Because that mm/memory.c use of "exception_ip()" most definitely
cannot take a page fault.
So if MIPS cannot do that whole exception IP thing without potentially
touching user space, I do worry that we might just have to add a
#ifndef __MIPS__
around this all.
Possibly somehow limited to just the microMIPS/MIPS16e case in Kconfig instead?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v8 0/4] Introduce mseal
@ 2024-02-02 23:36 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-02 23:36 UTC (permalink / raw)
To: Liam R. Howlett, Linus Torvalds, Jeff Xu, Jeff Xu,
Jonathan Corbet, akpm, keescook, jannh, sroettger, willy, gregkh,
usama.anjum, rdunlap, jorgelo, groeck, linux-kernel,
linux-kselftest, linux-mm, pedro.falcato, dave.hansen,
linux-hardening
On Fri, 2 Feb 2024 at 13:18, Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> There will be a larger performance cost to checking up front without
> allowing the partial completion.
I suspect that for mseal(), the only half-way common case will be
sealing an area that is entirely contained within one vma.
So the cost will be the vma splitting (if it's not the whole vma), and
very unlikely to be any kind of "walk the vma's to check that they can
all be sealed" loop up-front.
We'll see, but that's my gut feel, at least.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Kbuild fixes for v6.8-rc3
@ 2024-02-04 6:27 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-04 6:27 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: Linux Kernel Mailing List, Linux Kbuild mailing list
On Sun, 4 Feb 2024 at 00:00, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> Is the second patch fine with you?
Yes.
> If so, will you pick it up, or do you want me
> to include it in the next pull request?
This is not critical enough to bypass the regular pull chain, so just
put it in your queue, and I'll get it with the next pull.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] lib/bch.c: increase bitrev single conversion length
@ 2024-02-04 9:09 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-04 9:09 UTC (permalink / raw)
To: John Sanpe; +Cc: linux-mm, akpm, rdunlap, unixbhaskar, mm-commits, linux-kernel
On Sun, 4 Feb 2024 at 08:52, John Sanpe <sanpeqf@gmail.com> wrote:
>
> Optimized the performance of the three functions (load_ecc8 store_ecc8
> and bch_encode) using a larger calculation length.
Honestly, with any optimization, you should quote performance numbers.
Also, it's questionable how meaningful this is, considering that most
architectures dop the bit swap with a byte lookup, and the 32-bit bit
swap is just four byte lookups. For all we know, this only makes
things worse.
Finally, if you actually want to do things in bigger chunks, that
->swap_bits conditional should probably be moved out of the loops, not
just have that questionable 8->32 bit expansion.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2 0/3] Handle delay slot for extable lookup
@ 2024-02-04 11:45 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-04 11:45 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Oleg Nesterov, Thomas Bogendoerfer, Andrew Morton, Ben Hutchings,
linux-arch, linux-kernel, linux-mips, linux-mm, Xi Ruoyao
On Sun, 4 Feb 2024 at 11:03, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> Well this is the tricky part of my assumption.
> In `exception_epc()` `__isa_exception_epc()` stuff is only called if we
> are in delay slot.
> It is impossible for a invalid instruction_pointer to be considered as
> "in delay slot" by hardware.
Ok, I guess I'm convinced this is all safe. Not great, and not exactly
giving me the warm fuzzies, but not buggy.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2 1/3] LSM: add security_execve_abort() hook
@ 2024-02-07 17:57 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-07 17:57 UTC (permalink / raw)
To: Paul Moore
Cc: Kees Cook, Tetsuo Handa, Eric Biederman, Alexander Viro,
Christian Brauner, Jan Kara, James Morris, Serge E. Hallyn,
linux-security-module, linux-fsdevel, LKML
On Wed, 7 Feb 2024 at 16:45, Paul Moore <paul@paul-moore.com> wrote:
>
> Okay, let's get confirmation from Tetsuo on the current state of
> TOMOYO in Linus' tree. If it is currently broken [..]
As far as I understand, the current state is working, just the horrid
random flag.
So I think the series is a cleanup and worth doing, but also not
hugely urgent. But it would probably be good to just get this whole
thing over and done with, rather than leave it lingering for another
release for no reason.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11 (and earlier)
@ 2024-02-09 19:01 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-02-09 19:01 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Sean Christopherson, Andrew Pinski (QUIC),
linux-kernel, Masahiro Yamada, Peter Zijlstra, kvm
On Fri, 9 Feb 2024 at 10:55, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> And also pessimizes all asm gotos (for gcc) including ones that don't
> contain output as described in 43c249ea0b1e. The version checks would
> at least not pessimize those.
Yeah, no, we should limit that workaround only to the asm goto with
outputs case.
We should also probably get rid of the existing "asm_volatile_goto()"
macro name entirely. That name was always pretty horrific, in that it
didn't even mark the asm as volatile even in the case where it did
anything.
So the name of that macro made little sense, and the new workaround
should be only for asm goto with outputs. So I'd suggest jmaking a new
macro with that name:
#define asm_goto_output(x...)
and on gcc use that old workaround, and on clang just make it be a
plain "asm goto".
Hmm?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH wq/for-6.9] workqueue: Fix queue_work_on() with BH workqueues
@ 2024-02-14 19:03 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-14 19:03 UTC (permalink / raw)
To: Tejun Heo; +Cc: Lai Jiangshan, linux-kernel
On Wed, 14 Feb 2024 at 10:39, Tejun Heo <tj@kernel.org> wrote:
>
> When queue_work_on() is used to queue a BH work item on a remote CPU, the
> work item is queued on that CPU but kick_pool() raises softirq on the local
> CPU.
Now, does it make a lot of sense to ask to queue a BH work on another
CPU in the first place?
I don't think tasklets supported that. And while the workqueues
obviously do - and you fix that case - I wonder if we shouldn't say
"that operation makes no sense, please don't do it" rather than
actually support it?
What made you notice this issue?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11 (and earlier)
@ 2024-02-15 0:11 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-02-15 0:11 UTC (permalink / raw)
To: Uros Bizjak
Cc: Nick Desaulniers, Jakub Jelinek, Sean Christopherson,
Andrew Pinski (QUIC),
linux-kernel, Masahiro Yamada, Peter Zijlstra, kvm
On Wed, 14 Feb 2024 at 10:43, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Based on the current state of
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
>
> I would suggest this attached kernel patch [...]
Well, that "current state" didn't last long, and it looks like Jakub
found the real issue and posted a suggested fix.
Anyway, the end result is that the current kernel situation - that
adds the workaround for all gcc versions - is the best that we can do
for now.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11 (and earlier)
@ 2024-02-15 18:25 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-15 18:25 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Uros Bizjak, Nick Desaulniers, Sean Christopherson,
Andrew Pinski (QUIC),
linux-kernel, Masahiro Yamada, Peter Zijlstra, kvm
On Thu, 15 Feb 2024 at 00:39, Jakub Jelinek <jakub@redhat.com> wrote:
>
> Can it be guarded with
> #if GCC_VERSION < 140100
Ack. I'll update the workaround to do that, and add the new and
improved bugzilla pointer.
Thanks for fixing this so quickly.
Linus
^ permalink raw reply [relevance 99%]
* Re: Linux 6.8-rc5
@ 2024-02-20 22:02 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-20 22:02 UTC (permalink / raw)
To: Guenter Roeck
Cc: Matthew Auld, Arunpravin Paneer Selvam, Christian König,
Linux Kernel Mailing List
On Tue, 20 Feb 2024 at 13:48, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Turns out it wasn't this code, but
>
> > Now, the __moddi3() is a *bit* more reasonable, because I assume it comes from
> >
> > int slot = i % 3;
>
> this code.
Yeah. It's still the kernel doing silly things for no good reason, but
a compiler can certainly do a small-constant 64-bit unsigned division
without actually going to the expense of actually doing a full divide.
For example, in this case, because 1**32 mod 3 is 1, you can literally
just add the high bits together with the low bits (with carry), and do
a 32-bit modulus.
And in fact, you can then turn that 32-bit modulus into a multiply
instead, avoiding doing any expensive divide at all.
And gcc knows to do all this. I *suspect* that the failing
architectures end up not having a 32x32->64 multiply, or maybe they
just don't have a very good machine description, and that's why gcc
failed on them and just ended up doing the stupid thing.
Regardless, our kernel code was just not good. It should be fixed now.
Linus
^ permalink raw reply [relevance 99%]
* Re: [REGRESSION] 6.8-rc process is unable to exit and consumes a lot of cpu
@ 2024-02-24 23:43 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-24 23:43 UTC (permalink / raw)
To: Linux regressions mailing list, Al Viro
Cc: Christian Brauner (Microsoft),
Matt Heon, Ed Santiago, Linux-fsdevel, Paul Holzinger, LKML
On Fri, 23 Feb 2024 at 23:00, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> TWIMC, the quoted mail apparently did not get delivered to Al (I got a
> "48 hours on the queue" warning from my hoster's MTA ~10 hours ago).
Al's email has been broken for the last almost two weeks - the machine
went belly-up in a major way.
I bounced the email to his kernel.org email that seems to work, but I
also think Al ends up being busy trying to get through everything else
he missed, in addition to trying to get the machine working again...
Linus
^ permalink raw reply [relevance 99%]
* Re: Linux regressions report for mainline [2024-02-25]
@ 2024-02-26 17:33 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-26 17:33 UTC (permalink / raw)
To: Linux regressions mailing list; +Cc: LKML, ntfs3, Konstantin Komarov
On Sun, 25 Feb 2024 at 06:21, Linux regression tracking (Thorsten
Leemhuis) <regressions@leemhuis.info> wrote:
>
> Sorry, forgot something: there is a patch to fix a ntfs3 build problem
> that was posted 10+ days ago[1] that didn't get any reaction from the
> ntfs3 maintainer at all. Given the history of occasional slow responses
> for that subsystem I thought I'd let you know in case you want to pick
> the fix up directly; but if you do, consider using v2 of the patch[2].
Ack. Picked up directly.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 2/3] cleanup: Introduce cond_no_free_ptr()
@ 2024-02-27 20:40 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-27 20:40 UTC (permalink / raw)
To: Dan Williams; +Cc: peterz, gregkh, Jonathan Cameron, linux-kernel, linux-cxl
On Tue, 27 Feb 2024 at 08:49, Dan Williams <dan.j.williams@intel.com> wrote:
>
> 5/ cond_no_free_ptr(rc == 0, return rc, res, name);
Ugh. Honestly, this is all too ugly for words.
The whole - and only - point for the cond_guard() is to make mistakes
less likely.
This is not it. This makes mistakes unreadable and undebuggable.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] hotfixes for 6.8-rc7
@ 2024-02-28 0:51 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-28 0:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, mm-commits, linux-kernel
On Tue, 27 Feb 2024 at 14:56, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> 6 hotfixes. 3 are cc:stable and the remainder address post-6.7 issues
> or aren't considered appropriate for backporting.
Hmm. I notice that you add "Link:" pointers to lore, but you do so
even for emails that have been sent to you without any lists, so that
they don't actually exist on lore..
IOW, that link-generating automation of yours looks a bit overly aggressive.
Linus
^ permalink raw reply [relevance 99%]
* Re: [bug report] dead loop in generic_perform_write() //Re: [PATCH v7 07/12] iov_iter: Convert iterate*() to inline funcs
@ 2024-02-28 21:21 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-02-28 21:21 UTC (permalink / raw)
To: Tong Tiangen
Cc: David Howells, Jens Axboe, Al Viro, Christoph Hellwig,
Christian Brauner, David Laight, Matthew Wilcox, Jeff Layton,
linux-fsdevel, linux-block, linux-mm, netdev, linux-kernel,
Kefeng Wang
On Sat, 17 Feb 2024 at 19:13, Tong Tiangen <tongtiangen@huawei.com> wrote:
>
> After this patch:
> copy_page_from_iter_atomic()
> -> iterate_and_advance2()
> -> iterate_bvec()
> -> remain = step()
>
> With CONFIG_ARCH_HAS_COPY_MC, the step() is copy_mc_to_kernel() which
> return "bytes not copied".
>
> When a memory error occurs during step(), the value of "left" equal to
> the value of "part" (no one byte is copied successfully). In this case,
> iterate_bvec() returns 0, and copy_page_from_iter_atomic() also returns
> 0. The callback shmem_write_end()[2] also returns 0. Finally,
> generic_perform_write() goes to "goto again"[3], and the loop restarts.
> 4][5] cannot enter and exit the loop, then deadloop occurs.
Hmm. If the copy doesn't succeed and make any progress at all, then
the code in generic_perform_write() after the "goto again"
//[4]
if (unlikely(fault_in_iov_iter_readable(i, bytes) ==
bytes)) {
status = -EFAULT;
break;
}
should break out of the loop.
So either your analysis looks a bit flawed, or I'm missing something.
Likely I'm missing something really obvious.
Why does the copy_mc_to_kernel() fail, but the
fault_in_iov_iter_readable() succeeds?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Networking for v6.8-rc7
@ 2024-02-29 20:56 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-02-29 20:56 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, linux-kernel, pabeni
On Thu, 29 Feb 2024 at 12:39, Jakub Kicinski <kuba@kernel.org> wrote:
>
> A few hours late, the commit on top fixes an odd "rcu_dereference()
> needs to know full type" build issue I can't repro..
Ugfh. That change literally makes a single load instruction be a
function call. Pretty sad, particularly with all the crazy CPU
mitigations causing that to be even more expensive than it is already.
I really don't see how that error can happen, it sounds very odd.
Oh well.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH for 6.8] tomoyo: fix UAF write bug in tomoyo_write_control()
@ 2024-03-01 19:14 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-01 19:14 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Sam Sun, paul, syzkaller, takedakn, jmorris, serge,
linux-security-module, linux-kernel
On Fri, 1 Mar 2024 at 05:04, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> I couldn't reproduce this problem in my environment, but I believe
> this does fix a bug. Linus, can you directly apply to linux.git ?
Thanks. Applied,
Linus
^ permalink raw reply [relevance 99%]
* Re: [bug report] dead loop in generic_perform_write() //Re: [PATCH v7 07/12] iov_iter: Convert iterate*() to inline funcs
@ 2024-03-02 18:11 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-02 18:11 UTC (permalink / raw)
To: Tong Tiangen
Cc: Al Viro, David Howells, Jens Axboe, Christoph Hellwig,
Christian Brauner, David Laight, Matthew Wilcox, Jeff Layton,
linux-fsdevel, linux-block, linux-mm, netdev, linux-kernel,
Kefeng Wang
On Sat, 2 Mar 2024 at 10:06, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> In other words, it's the usual "Enterprise Hardware" situation. Looks
> fancy on paper, costs an arm and a leg, and the reality is just sad,
> sad, sad.
Don't get me wrong. I'm sure large companies are more than willing to
sell other large companies very expensive support contracts and have
engineers that they fly out to deal with the problems all these
enterprise solutions have.
The problem *will* get fixed somehow, it's just going to cost you. A lot.
Because THAT is what Enterprise Hardware is all about.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Prevent trace_marker being bigger than unsigned short
@ 2024-03-02 20:25 99% ` Linus Torvalds
2024-03-02 20:33 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-02 20:25 UTC (permalink / raw)
To: Steven Rostedt; +Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers
On Sat, 2 Mar 2024 at 12:00, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I don't have control over the strings. Anyone can do in user space:
>
> fd = open("/sys/kernel/tracing/trace_marker", O_WRONLY);
> r = write(fd, huge_string, 10000000);
So?
Stop the stupidity.
You already limit the string.
Just limit it to a sane value. if somebody uses a 10kB trace marker,
return an error, or just truncate it to 100 bytes.
You already were willing to truncate it to 32kB. Use your brain, and
realize that 32kB is a ridiculous limit.
Why do I even need to tell you this? I'm getting really tired of
having these idiotic arguments with you.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Prevent trace_marker being bigger than unsigned short
2024-03-02 20:25 99% ` Linus Torvalds
@ 2024-03-02 20:33 99% ` Linus Torvalds
1 sibling, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-02 20:33 UTC (permalink / raw)
To: Steven Rostedt; +Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers
On Sat, 2 Mar 2024 at 12:00, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> The error isn't printk, it's vsnprintf() that is writing to a seq_file
> to user space. There's no stack or printk involved here.
Look again. The code uses 'struct printf_spec' and we literally have a
static_assert(sizeof(struct printf_spec) == 8);
because we want the compiler to generate sane calling conventions and
not waste space and code with arguments on the stack. That's literally
why we do all those limits in a bitfield - because the code in
question is written to say "unreasonable people can go screw
themselves".
I'm not interested in arguing this. We're not doing some completely
idiotic "let's edge up to the physical limit of what our printk code
is willing to do".
I'm perfectly happy having that WARN_ON() to continue to tell people
they are doing stupid things that won't work.
And if you ever decide that a sane limit is ok, you can send that in.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Prevent trace_marker being bigger than unsigned short
@ 2024-03-02 20:55 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-02 20:55 UTC (permalink / raw)
To: Steven Rostedt; +Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Sachin Sant
On Sat, 2 Mar 2024 at 12:47, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> I'm fine with just making it 4K with a comment saying that "4K is the
> minimum page size on most archs, and to keep this consistent for crazy
> architectures like PowerPC and it's 64K pages, we hard code 4K to keep
> all architectures acting the same".
4k is at least a somewhat sane limit, and yes, being hw-independent is
a good idea.
We have other strings that have that limit for similar reasons (ie PATH_MAX).
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Prevent trace_marker being bigger than unsigned short
@ 2024-03-03 17:38 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-03 17:38 UTC (permalink / raw)
To: Steven Rostedt; +Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Sachin Sant
On Sun, 3 Mar 2024 at 04:59, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> - trace_seq_printf(s, ": %.*s", max, field->buf);
> + trace_seq_puts(s, ": ");
> + /* Write 1K chunks at a time */
> + p = field->buf;
> + do {
> + int pre = max > 1024 ? 1024 : max;
> + trace_seq_printf(s, "%.*s", pre, p);
> + max -= pre;
> + p += pre;
> + } while (max > 0);
The above loop is complete garbage.
If 'p' is a string, you're randomly just walking past the end of the
string with 'p += pre'
And if 'o' isn't a string but has a fixed size, you shouldn't use '%s'
in the first place, you should just use seq_write().
Just stop. You are doing things entirely wrong, and you're just adding
random code.
I'm not taking *any* fixes from you as things are now, you're once
again only making things worse.
What was wrong with saying "don't do that"? You seem to be bending
over backwards to doing stupid things, and then insisting on doing
them entirely wrong.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Prevent trace_marker being bigger than unsigned short
@ 2024-03-05 0:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-05 0:17 UTC (permalink / raw)
To: Steven Rostedt; +Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Sachin Sant
On Mon, 4 Mar 2024 at 15:50, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> But this still isn't fixing anything. It's just adding a limit.
Limiting things to a common maximum size is a good thing. The kernel
limits much more important things for very good reasons.
The kernel really shouldn't have big strings. EVER. And it literally
shows in our kernel infrastructure. It showed in that vsnprintf
precision thing. It shows in our implementation choices, where we tend
to have simplistic implementations because doing things a byte at a
time is simple and cheap when the strings are limited in size (and we
don't want fancy and can't use vector state anyway).
If something as core as a pathname can be limited to 4kB, then
something as unimportant as a trace string had better be limited too.
Because we simply DO NOT WANT to have to deal with longer strings in
the kernel.
Linus
^ permalink raw reply [relevance 99%]
* Re: linux-next: build warning after merge of the vfs-brauner tree
@ 2024-03-06 2:48 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-06 2:48 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christian Brauner, Tong Tiangen, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, 5 Mar 2024 at 15:51, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> fs/coredump.c: In function 'dump_user_range':
> fs/coredump.c:923:40: warning: left-hand operand of comma expression has no effect [-Wunused-value]
> 923 | #define dump_page_copy(src, dst) ((dst), (src))
> | ^
> fs/coredump.c:948:58: note: in expansion of macro 'dump_page_copy'
> 948 | int stop = !dump_emit_page(cprm, dump_page_copy(page, dump_page));
> | ^~~~~~~~~~~~~~
>
> Introduced by commit
>
> 4630f2caafcd ("coredump: get machine check errors early rather than during iov_iter")
Bah. If comes from that
#define dump_page_copy(src,dst) ((dst),(src))
and I did it that way because I wanted to avoid *another* warning,
namely the "dst not used" thing.
But it would have probably been better to either make it an inline
function, or maybe an explicit cast, eg
#define dump_page_copy(src,dst) ((void)(dst),(src))
or whatever.
Linus
^ permalink raw reply [relevance 99%]
* Re: linux-next: build warning after merge of the vfs-brauner tree
@ 2024-03-06 4:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-06 4:47 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christian Brauner, Tong Tiangen, Linux Kernel Mailing List,
Linux Next Mailing List
On Tue, 5 Mar 2024 at 20:37, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> +static struct page *dump_page_copy(struct page *src, struct page *dst)
> +{
> + return NULL;
> +}
No, it needs to be "return src;" not NULL.
That
#define dump_page_copy(src, dst) ((dst), (src))
was supposed to be a "use 'dst', return 'src'" macro, and is correct
as that. The problem - as you noticed - is that it causes that "left
side of comma expression has no effect" warning.
(Technically it *does* have an effect - exactly the "argument is used"
one - but the compiler warning does make sense).
Actually, the simplest thing to do is probably just
#define dump_page_free(x) ((void)(x))
#define dump_page_copy(src, dst) (src)
where the "use" of the 'dump_page' argument is that dump_page_free()
void cast, and dump_page_copy() simply doesn't need to use it at all.
Christian?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] x86: disable non-instrumented version of copy_mc when KMSAN is enabled
@ 2024-03-07 0:09 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-07 0:09 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Alexander Potapenko, Marco Elver, Dmitry Vyukov, kasan-dev, LKML,
the arch/x86 maintainers, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin
On Wed, 6 Mar 2024 at 14:08, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Something like below one?
I'd rather leave the regular fallbacks (to memcpy and copy_to_user())
alone, and I'd just put the
kmsan_memmove(dst, src, len - ret);
etc in the places that currently just call the MC copy functions.
The copy_mc_to_user() logic is already set up for that, since it has
to do the __uaccess_begin/end().
Changing copy_mc_to_kernel() to look visually the same would only
improve on this horror-show, I feel.
Obviously some kmsan person needs to validate your kmsan_memmove() thing, but
> Can we assume that 0 <= ret <= len is always true?
Yes. It had better be for other reasons.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters
@ 2024-03-08 21:39 99% ` Linus Torvalds
2024-03-08 21:41 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-08 21:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, joel, linke li, Rabin Vincent
On Fri, 8 Mar 2024 at 13:33, Steven Rostedt <rostedt@goodmis.org> 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 tracing layer; Here on close of a file, the consumers need to be
> woken up and not wait again. And just take whatever was there to finish
> reading.
>
> There's also another case that the ioctl() just kicks the current
> readers out, but doesn't care about new readers.
But that's the beauty of just using the wait_event() model.
Just add that "exit" condition to the condition.
So the above "complexity" is *literally* just changing the
(new = atomic_read_acquire(&my->seq)) != old
condition to
should_exit ||
(new = atomic_read_acquire(&my->seq)) != old
(replace "should_exit" with whatever that condition is, of course) and
the wait_event() logic will take care of the rest.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters
2024-03-08 21:39 99% ` Linus Torvalds
@ 2024-03-08 21:41 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-08 21:41 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, joel, linke li, Rabin Vincent
On Fri, 8 Mar 2024 at 13:39, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So the above "complexity" is *literally* just changing the
>
> (new = atomic_read_acquire(&my->seq)) != old
>
> condition to
>
> should_exit ||
> (new = atomic_read_acquire(&my->seq)) != old
.. and obviously you'll need to add the exit condition to the actual
"deal with events" loop too.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] vfs pidfd
@ 2024-03-11 20:05 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-11 20:05 UTC (permalink / raw)
To: Christian Brauner; +Cc: linux-fsdevel, linux-kernel
On Fri, 8 Mar 2024 at 02:14, Christian Brauner <brauner@kernel.org> wrote:
>
> * Move pidfds from the anonymous inode infrastructure to a tiny
> pseudo filesystem. This will unblock further work that we weren't able
> to do simply because of the very justified limitations of anonymous
> inodes. Moving pidfds to a tiny pseudo filesystem allows for statx on
> pidfds to become useful for the first time. They can now be compared
> by inode number which are unique for the system lifetime.
So I obviously pulled this already, but I did have one question - we
don't make nsfs conditional, and I'm not convinced we should make
pidfs conditional either.
I think (and *hope*) all the semantic annoyances got sorted out, and I
don't think there are any realistic size advantages to not enabling
CONFIG_FS_PID.
Is there some fundamental reason for that config entry to exist?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] x86/sev for v6.9-rc1
@ 2024-03-12 0:50 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-12 0:50 UTC (permalink / raw)
To: Borislav Petkov; +Cc: x86-ml, lkml
On Mon, 11 Mar 2024 at 08:19, Borislav Petkov <bp@alien8.de> wrote:
>
> If you're merging tip pull requests in the chronological order you've
> received them, you'll encounter a couple of simple merge conflicts.
It's not exactly chronological - I tend to go by areas and by
submitter, but it tends to approximate chronological most of the
time..
> I'm adding how I've resolved them at the end of this message in case
> you wanna compare notes.
Hmm. I took a slightly different approach:
> diff --cc arch/x86/include/asm/coco.h
> index 76c310b19b11,21940ef8d290..42871bb262d0
> --- a/arch/x86/include/asm/coco.h
> +++ b/arch/x86/include/asm/coco.h
> @@@ -10,9 -11,15 +11,15 @@@ enum cc_vendor
> CC_VENDOR_INTEL,
> };
>
> -extern enum cc_vendor cc_vendor;
> + extern u64 cc_mask;
> +
> #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
> +extern enum cc_vendor cc_vendor;
I put the 'cc_mask' declaration inside the #ifdef too.
Because those two variables are defined together, and without
CONFIG_ARCH_HAS_CC_PLATFORM the whole coco/ subdirectory that defines
them won't even be built, as far as I can tell.
And I don't see any _use_ of 'cc_mask' anywhere outside of that one
'cc_set_mask()' inline function and the coco/core.c file. So declaring
it only when it's all enabled seems to be the right thing.
Let's hope my artistic merge resolution doesn't end up coming back to bite me.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] EDAC updates for v6.9
@ 2024-03-12 1:12 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-12 1:12 UTC (permalink / raw)
To: Borislav Petkov; +Cc: x86-ml, lkml, linux-edac
On Mon, 11 Mar 2024 at 08:57, Borislav Petkov <bp@alien8.de> wrote:
>
> - return topology_die_id(err->cpu) % amd_get_nodes_per_socket();
> + return topology_amd_node_id(err->cpu) % topology_amd_nodes_per_pkg();
Ho humm. Lookie here:
static inline unsigned int topology_amd_nodes_per_pkg(void)
{ return 0; };
that's the UP case.
Yeah, I'm assuming nobody tests this for UP, but it's clearly wrong to
potentially do that modulus by zero.
So I made the merge also change that UP case of
topology_amd_nodes_per_pkg() to return 1.
Because dammit, not only is a mod-by-zero wrong, a UP system most
definitely has one node per package, not zero.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] EDAC updates for v6.9
@ 2024-03-12 2:25 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-12 2:25 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Borislav Petkov, x86-ml, lkml, linux-edac
On Mon, 11 Mar 2024 at 19:24, Randy Dunlap <rdunlap@infradead.org> wrote:
>
> and there's an extra/trailing ';'.
Ayup, I fixed that too while I was in there anyway.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] vfs pidfd
@ 2024-03-12 16:23 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-12 16:23 UTC (permalink / raw)
To: Christian Brauner; +Cc: linux-fsdevel, linux-kernel
On Tue, 12 Mar 2024 at 07:16, Christian Brauner <brauner@kernel.org> wrote:
>
> No, the size of struct pid was the main reason but I don't think it
> matters. A side-effect was that we could easily enforce 64bit inode
> numbers. But realistically it's trivial enough to workaround. Here's a
> patch for what I think is pretty simple appended. Does that work?
This looks eminently sane to me. Not that I actually _tested_it, but
since my testing would have compared it to my current setup (64-bit
and CONFIG_FS_PID=y) any testing would have been pointless because
that case didn't change.
Looking at the patch, I do wonder how much we even care about 64-bit
inodes. I'd like to point out how 'path_from_stashed()' only takes a
'unsigned long ino' anyway, and I don't think anything really cares
about either the high bits *or* the uniqueness of that inode number..
And similarly, i_ino isn't actually *used* for anything but naming to
user space.
So I'm not at all sure the whole 64-bit checks are worth it. Am I
missing something else?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Networking for v6.9
@ 2024-03-12 20:17 99% ` Linus Torvalds
2024-03-13 1:00 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-12 20:17 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, linux-kernel, pabeni, bpf
On Mon, 11 Mar 2024 at 21:25, Jakub Kicinski <kuba@kernel.org> wrote:
>
> I get what looks like blk-iocost deadlock when I try to run
> your current tree on real Meta servers :(
Hmm. This "it breaks on real hardware, but works in virtual boxes"
sounds like it might be the DM queue limit issue.
Did the tree you tested with perhaps have commit 8e0ef4128694 (which
came in yesterday through the block merge (merge commit 1ddeeb2a058d
just after 11am Monday), but not the revert (commit bff4b74625fe, six
hours later).
IOW, just how current was that "current"? Your email was sent multiple
hours after the revert happened and was pushed out, but I would not be
surprised if your testing was done with something that was in that
broken window.
So if you merged some *other* tree than one from that six-hour window,
please holler - because there's something else going on and we need to
get the block people on it.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] vfs pidfd
@ 2024-03-12 20:21 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-12 20:21 UTC (permalink / raw)
To: Christian Brauner; +Cc: linux-fsdevel, linux-kernel
On Tue, 12 Mar 2024 at 13:09, Christian Brauner <brauner@kernel.org> wrote:
>
> It's used to compare pidfs and someone actually already sent a pull
> request for this to another project iirc. So it'd be good to keep that
> property.
Hmm. If people really do care, I guess we should spend the effort on
making those things unique.
> But if your point is that we don't care about this for 32bit then I do
> agree. We could do away with the checks completely and just accept the
> truncation for 32bit. If that's your point feel free to just remove the
> 32bit handling in the patch and apply it. Let me know. Maybe I
> misunderstood.
I personally don't care about 32-bit any more, but it also feels wrong
to just say that it's ok depending on something on a 64-bit kernel,
but not a 32-bit one.
So let's go with your patch. It's not like it's a problem to spend the
(very little) extra effort to do a 64-bit inode number.
Linus
^ permalink raw reply [relevance 99%]
* Re: Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9]
@ 2024-03-12 21:44 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-12 21:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: Boqun Feng, linux-kernel, kernel-team, paulmck, mingo, tglx, rcu,
joel, neeraj.upadhyay, urezki, qiang.zhang1211, frederic,
bigeasy, anna-maria, chenzhongjin, yangjihong1, rostedt
On Tue, 12 Mar 2024 at 14:34, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> and here is a log where this fails:
>
> https://gist.github.com/ffainelli/ed08a2b3e853f59343786ebd20364fc8
You could try the 'initcall_debug' kernel command line.
It will make the above *much* noisier, but it might - thanks to all
the new noise - show exactly *what* is being crazy slow to initialize.
Because right now it's just radio silence in between those
[ 1.926435] bcmgenet f0480000.ethernet: GENET 5.0 EPHY: 0x0000
[ 162.148135] unimac-mdio unimac-mdio.0: Broadcom UniMAC MDIO bus
things, and that's presumably because some random initcall there just
takes forever to time out.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Networking for v6.9
2024-03-12 20:17 99% ` Linus Torvalds
@ 2024-03-13 1:00 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-13 1:00 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, linux-kernel, pabeni, bpf
On Mon, 11 Mar 2024 at 21:25, Jakub Kicinski <kuba@kernel.org> wrote:
>
> - Large effort by Eric to lower rtnl_lock pressure and remove locks:
W00t!
Pulled. The rtnl lock is probably my least favorite kernel lock. It's
been one of the few global locks we have left (at least that matters).
There are others (I'm not claiming tasklist_lock is great), but
rtnl_lock has certainly been "up there" with the worst of them.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] slab updates for 6.9
@ 2024-03-13 3:54 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-13 3:54 UTC (permalink / raw)
To: Vlastimil Babka
Cc: David Rientjes, Joonsoo Kim, Christoph Lameter, Pekka Enberg,
Andrew Morton, linux-mm, LKML, patches, Roman Gushchin,
Hyeonggon Yoo, Chengming Zhou, Xiongwei Song
On Tue, 12 Mar 2024 at 02:55, Vlastimil Babka <vbabka@suse.cz> wrote:
>
> Also deprecate SLAB_MEM_SPREAD which was only
> used by SLAB, so it's a no-op since SLAB removal. Assign it an explicit zero
> value. The removals of the flag usage are handled independently in the
> respective subsystems, with a final removal of any leftover usage planned
> for the next release.
I already had the patch ready to go:
https://lore.kernel.org/all/CAHk-=wji0u+OOtmAOD-5JV3SXcRJF___k_+8XNKmak0yd5vW1Q@mail.gmail.com/
so I just did a "git stash apply" and got rid of the final stragglers.
No need to have various random maintainers have to worry about a flag
that hasn't had any meaning since 6.7, and very little before that
either.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] vfs pidfd
@ 2024-03-13 19:40 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-13 19:40 UTC (permalink / raw)
To: Christian Brauner; +Cc: linux-fsdevel, linux-kernel
On Wed, 13 Mar 2024 at 10:10, Christian Brauner <brauner@kernel.org> wrote:
>
> If you're fine with it I would ask you to please just apply it [..]
I'll take it directly, no problem.
Thanks,
Linus
^ permalink raw reply [relevance 99%]
* Re: [RFC PATCH 1/2] smp: Implement serialized smp_call_function APIs
@ 2024-03-13 21:19 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-13 21:19 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Peter Oskolkov, linux-kernel, Peter Zijlstra, Paul E . McKenney,
Boqun Feng, Andrew Hunter, Maged Michael, gromer, Avi Kivity,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
On Wed, 13 Mar 2024 at 13:56, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> Introduce serialized smp_call_function APIs to limit the number of
> concurrent smp_call_function IPIs which can be sent to a given CPU to a
> maximum of two: one broadcast and one specifically targeting the CPU.
So honestly, with only one user, I think the serialization code
should be solidly in that one user, not in kernel/smp.c.
Also, this kind of extra complexity does require numbers to argue for it.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] bcachefs updates for 6.9
@ 2024-03-13 21:51 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-13 21:51 UTC (permalink / raw)
To: Kent Overstreet
Cc: Darrick J. Wong, linux-bcachefs, linux-fsdevel, linux-kernel
On Wed, 13 Mar 2024 at 14:34, Kent Overstreet <kent.overstreet@linux.dev> wrote:
>
> I liked your MAD suggestion, but the catch was that we need an
> exponentially weighted version,
The code for the weighted version literally doesn't change.
The variance value is different, but the difference between MAD and
standard deviation is basically just a constant factor (which will be
different for different distributions, but so what? Any _particular_
case will have a particular distribution).
So why would a constant factor make _any_ difference for any
exponential weighting?
Anyway, feel free to keep your code in bcachefs.
And maybe xfs even wants to copy that code. I don't care, it seems
stupid, but that's a filesystem choice.
But if we're making it a generic kernel library, it needs to be sane.
Not making people do 64-bit square roots and 128-bit divides just for
a random statistical element.
Linus
^ permalink raw reply [relevance 99%]
* Re: [git pull] drm for 6.9-rc1
@ 2024-03-14 1:49 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-14 1:49 UTC (permalink / raw)
To: Dave Airlie, Animesh Manna, Jani Nikula; +Cc: Daniel Vetter, dri-devel, LKML
On Tue, 12 Mar 2024 at 21:07, Dave Airlie <airlied@gmail.com> wrote:
>
> I've done a trial merge into your tree from a few hours ago, there
> are definitely some slighty messy conflicts, I've pushed a sample
> branch here:
I appreciate your sample merges since I like verifying my end result,
but I think your merge is wrong.
I got two differences when I did the merge. The one in
intel_dp_detect() I think is just syntactic - I ended up placing the
if (!intel_dp_is_edp(intel_dp))
intel_psr_init_dpcd(intel_dp);
differently than you did (I did it *after* the tunnel_detect()).
I don't _think,_ that placement matters, but somebody more familiar
with the code should check it out. Added Animesh and Jani to the
participants.
But I think your merge gets the TP_printk() for the xe_bo_move trace
event is actively wrong. You don't have the destination for the move
in the printk.
Or maybe I got it wrong. Our merges end up _close_, but not identical.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] bcachefs updates for 6.9
@ 2024-03-14 17:15 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-14 17:15 UTC (permalink / raw)
To: Kent Overstreet
Cc: Darrick J. Wong, linux-bcachefs, linux-fsdevel, linux-kernel
On Wed, 13 Mar 2024 at 15:28, Kent Overstreet <kent.overstreet@linux.dev> wrote:
>
> Sorry, you were talking about mean absolute deviation; that does work
> here.
Yes, I meant mean, not median.
But the confusion is my fault - I wrote MAD and then to "explain"
that, I put "median" in my own email - so you read it right the first
time, and it was just me being sloppy and confusing things.
They are both called MAD in their own contexts, and they are much too
easy to confuse.
My bad,
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] lsm/lsm-pr-20240314
@ 2024-03-14 23:05 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-14 23:05 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-security-module, linux-kernel
On Thu, 14 Mar 2024 at 13:31, Paul Moore <paul@paul-moore.com> wrote:
>
> I would like if you could merge these patches, I believe fixing the
> syscall signature problem now poses very little risk and will help us
> avoid the management overhead of compat syscall variants in the future.
> However, I'll understand if you're opposed, just let me know and I'll
> get you a compat version of this pull request as soon as we can get
> something written/tested/verfified.
No, attempting to just fix it after-the-fact in the hopes that nobody
actually uses the new system call yet sounds like the right thing to
do.
6.8 has been out for just days, and I see it's marked for stable, so
hopefully nobody ever even sees the mistake. I can't imagine that the
new system call is that eagerly used.
Famous last wods.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] fs/9p patches for 6.9 merge window
@ 2024-03-15 17:17 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-15 17:17 UTC (permalink / raw)
To: Eric Van Hensbergen; +Cc: v9fs, linux-kernel
On Fri, 15 Mar 2024 at 08:10, Eric Van Hensbergen <ericvh@kernel.org> wrote:
>
> fs/9p changes for the 6.9 merge window
Entirely tangential, but your pgp key drives me insane, and it finally
drove me over the edge.
One of your uid's has your own name mis-spelled. This is not new.
Please tell me there's a reason for it.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] clk changes for the merge window
@ 2024-03-15 18:54 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-15 18:54 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Michael Turquette, linux-clk, linux-kernel
On Thu, 14 Mar 2024 at 12:43, Stephen Boyd <sboyd@kernel.org> wrote:
>
> I'm hoping that we can make that into a genpd that drivers attach
> instead, but this API should help drivers simplify in the meantime.
.. and I'm hoping that name dies in the code too, not just in the
directory structure.
'genpd' really makes absolutely zero sense as a name to anybody
outside of that legacy clique.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL]: Generic phy updates for v6.9
@ 2024-03-15 19:22 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-15 19:22 UTC (permalink / raw)
To: Vinod Koul; +Cc: LKML
On Fri, 15 Mar 2024 at 04:03, Vinod Koul <vkoul@kernel.org> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git next
That is not a valid signed tag, and I can't find one in that repo.
I know you know how to do this right, so please send me a proper pull
request with a signed tag like you usually do...
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Crypto Update for 6.9
@ 2024-03-15 21:51 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-15 21:51 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Linux Kernel Mailing List, Linux Crypto Mailing List
On Thu, 14 Mar 2024 at 20:04, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Drivers:
>
> - Add queue stop/query debugfs support in hisilicon/qm.
There's a lot more than that in there. Fairl ybig Intel qat updates
from what I can see, for example.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] Revert "KVM: arm64: Snapshot all non-zero RES0/RES1 sysreg fields for later checking"
@ 2024-03-16 0:51 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-16 0:51 UTC (permalink / raw)
To: Oliver Upton
Cc: Paolo Bonzini, Marc Zyngier, Catalin Marinas, Mark Rutland,
Will Deacon, linux-kernel, kvm, kvmarm, James Morse,
Suzuki K Poulose, Zenghui Yu
On Fri, 15 Mar 2024 at 17:25, Oliver Upton <oliver.upton@linux.dev> wrote:
>
> This reverts commits 99101dda29e3186b1356b0dc4dbb835c02c71ac9 and
> b80b701d5a67d07f4df4a21e09cb31f6bc1feeca.
Applied. Thanks,
Linus
^ permalink raw reply [relevance 99%]
* Re: [patch 5/9] x86: Cure per CPU madness on UP
@ 2024-03-16 1:23 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-16 1:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Guenter Roeck, LKML, x86, Uros Bizjak, linux-sparse, lkp,
oe-kbuild-all, Arnd Bergmann
On Fri, 15 Mar 2024 at 18:11, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> You wish. We still support 486 and some of the still produced 486 clones
> do not have a local APIC.
Ouch. I was _sure_ we had dropped i486 support too due to cmpxchg8b.
But apparently that was just a discussion, and my wishful thinking,
and we never actually followed through.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] KVM changes for Linux 6.9 merge window
@ 2024-03-16 16:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-16 16:01 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Oliver Upton, Marc Zyngier, Catalin Marinas, Mark Rutland,
Will Deacon, linux-kernel, kvm
On Sat, 16 Mar 2024 at 01:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> Linus, were you compiling with allyesconfig so that you got
> CONFIG_KVM_ARM64_RES_BITS_PARANOIA on?
Regular allmodconfig.
> You can also make CONFIG_KVM_ARM64_RES_BITS_PARANOIA depend on !COMPILE_TEST.
No.
WTF is wrong with you?
You're saying "let's turn off this compile-time sanity check when
we're doing compile testing".
That's insane.
The sanity check was WRONG. People hadn't tested it. Stephen points
out that it was reported to you almost a month ago in
https://lore.kernel.org/linux-next/20240222220349.1889c728@canb.auug.org.au/
and you're still trying to just *HIDE* this garbage?
Stop it.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Updates for v6.9
@ 2024-03-16 16:31 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-16 16:31 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Beau Belgrave,
Chengming Zhou, Huang Yiwei, John Garry, Randy Dunlap,
Thorsten Blum, Vincent Donnefort, linke li,
Daniel Bristot de Oliveira
On Fri, 15 Mar 2024 at 09:27, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> - Add ring_buffer memory mappings
I pulled this, looked at it, and unpulled it again.
I don't want to have years of "fix up the mistakes after the fact".
This is all done entirely incorrectly, and just as an example of that,
subbuf_map_prepare() is another case of "tracing code works around the
fact that it did things wrong in the first place".
So instead of merging a new feature that was mis-designed and is
already having code working around its mis-design, I'm not merging it
at all.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL]: Generic phy updates for v6.9
@ 2024-03-16 18:23 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-16 18:23 UTC (permalink / raw)
To: Vinod Koul; +Cc: LKML
On Sat, 16 Mar 2024 at 11:05, Vinod Koul <vkoul@kernel.org> wrote:
>
> On 15-03-24, 12:22, Linus Torvalds wrote:
> >
> > That is not a valid signed tag, and I can't find one in that repo.
>
> It was pushed: tags/phy-for-6.9, I erred in generating the request for
> sure
Ahh. I did do a "git ls-remote" to try to find it, but I must have
messed up searching for it.
> git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy-for-6.9
Thanks, now pulled.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] vfs fixes
@ 2024-03-18 19:41 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-18 19:41 UTC (permalink / raw)
To: Christian Brauner; +Cc: linux-fsdevel, linux-kernel
On Mon, 18 Mar 2024 at 12:14, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> IOW, isn't the 'get()' always basically paired with the mounting? And
> the 'put()' would probably be best done iin kill_block_super()?
.. or alternative handwavy approach:
The fundamental _reason_ for the ->get/put seems to be to make the
'holder' lifetime be at least as long as the 'struct file' it is
associated with. No?
So how about we just make the 'holder' always *be* a 'struct file *'? That
(a) gets rid of the typeless 'void *' part
(b) is already what it is for normal cases (ie O_EXCL file opens).
wouldn't it be lovely if we just made the rule be that 'holder' *is*
the file pointer, and got rid of a lot of typeless WTF code?
Again, this comment (and the previous email) is more based on "this
does not feel right to me" than anything else.
That code just makes my skin itch. I can't say it's _wrong_, but it
just FeelsWrongToMe(tm).
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL v2] dlm fixes for 6.9
@ 2024-03-18 22:44 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-18 22:44 UTC (permalink / raw)
To: David Teigland; +Cc: linux-kernel, gfs2
On Mon, 18 Mar 2024 at 14:25, David Teigland <teigland@redhat.com> wrote:
>
> I dropped the commit with the bad atomic usage, and replaced it with two
> other commits: the first reverts the unnecessary change that began using
> atomic_t for lkb_wait_count, and the second adds comments to the recovery
> code that forcibly resets the wait_count state.
Ok, the diff certainly looks saner. I didn't look at the code outside
the context of the diff, so that's literally just going by the patches
themselves, but I appreciate the comment ("The wait_count will almost
always be 1, but in case of an overlapping unlock/cancel it could be
2: see ..") and yes, it just makes the old atomic thing sound even
odder.
Thanks,
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v1 2/3] instrumented.h: add instrument_memcpy_before, instrument_memcpy_after
@ 2024-03-19 17:52 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-19 17:52 UTC (permalink / raw)
To: Alexander Potapenko
Cc: akpm, linux-kernel, linux-mm, kasan-dev, tglx, x86,
Dmitry Vyukov, Marco Elver, Tetsuo Handa
On Tue, 19 Mar 2024 at 09:37, Alexander Potapenko <glider@google.com> wrote:
>
> +/**
> + * instrument_memcpy_after - add instrumentation before non-instrumented memcpy
Spot the cut-and-paste.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v1 3/3] x86: call instrumentation hooks from copy_mc.c
@ 2024-03-19 17:58 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-19 17:58 UTC (permalink / raw)
To: Alexander Potapenko
Cc: akpm, linux-kernel, linux-mm, kasan-dev, tglx, x86,
Dmitry Vyukov, Marco Elver, Tetsuo Handa
On Tue, 19 Mar 2024 at 09:37, Alexander Potapenko <glider@google.com> wrote:
>
> if (copy_mc_fragile_enabled) {
> __uaccess_begin();
> + instrument_copy_to_user(dst, src, len);
> ret = copy_mc_fragile((__force void *)dst, src, len);
> __uaccess_end();
I'd actually prefer that instrument_copy_to_user() to be *outside* the
__uaccess_begin.
In fact, I'm a bit surprised that objtool didn't complain about it in that form.
__uaccess_begin() causes the CPU to accept kernel accesses to user
mode, and I don't think instrument_copy_to_user() has any business
actually touching user mode memory.
In fact it might be better to rename the function and change the prototype to
instrument_src(src, len);
because you really can't sanely instrument the destination of a user
copy, but "instrument_src()" might be useful in other situations than
just user copies.
Hmm?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL v2] tracing: Updates for v6.9
@ 2024-03-19 21:22 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-19 21:22 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Steven Rostedt, LKML, Masami Hiramatsu, Mathieu Desnoyers,
Alison Schofield, Beau Belgrave, Huang Yiwei, John Garry,
Randy Dunlap, Thorsten Blum, Vincent Donnefort, linke li, llvm
On Tue, 19 Mar 2024 at 14:03, Nathan Chancellor <nathan@kernel.org> wrote:
>
> For what it's worth, I applied that change and built ARCH=x86_64
> defconfig with LLVM 18.1.1 from [1] but it does not appear to help the
> instances of -Wstring-compare; in fact, it adds some additional warnings
> that I have not seen before. I have attached the full build log.
Hmm. I'm no longer seeing any problems with commit 24f5bb9f24ad
("tracing: Just use strcmp() for testing __string() and __assign_str()
match").
But that's clang 17.0.6.
The patch that Steven sent out (and that I applied) is a bit different
from his "I'll change it to this" email, though. A couple of casts and
parentheses different.
So maybe current -git works for you?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2 1/3] mm: kmsan: implement kmsan_memmove()
@ 2024-03-20 16:04 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-20 16:04 UTC (permalink / raw)
To: Alexander Potapenko
Cc: akpm, linux-kernel, linux-mm, kasan-dev, tglx, x86, Tetsuo Handa,
Dmitry Vyukov, Marco Elver
On Wed, 20 Mar 2024 at 03:18, Alexander Potapenko <glider@google.com> wrote:
>
> Provide a hook that can be used by custom memcpy implementations to tell
> KMSAN that the metadata needs to be copied. Without that, false positive
> reports are possible in the cases where KMSAN fails to intercept memory
> initialization.
Thanks, the series looks fine to me now with the updated 3/3.
I assume it will go through Andrew's -mm tree?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing/tools: Updates for v6.9
@ 2024-03-20 23:40 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-20 23:40 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Daniel Bristot de Oliveira
On Wed, 20 Mar 2024 at 08:19, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> - Update makefiles for latency-collector and RTLA, using tools/build/
> makefiles like perf does, inheriting its benefits.
Lovely. Now it all worked for me, and gave me the legible
Auto-detecting system features:
... libtraceevent: [ on ]
... libtracefs: [ OFF ]
libtracefs is missing. Please install libtracefs-dev/libtracefs-devel
Makefile.config:29: *** Please, check the errors above.. Stop.
and after installing libtracefs-devel as suggested it finished cleanly.
Let's see if it works for others too,
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Hyper-V commits for 6.9
@ 2024-03-21 17:06 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-21 17:06 UTC (permalink / raw)
To: Wei Liu; +Cc: Linux Kernel List, Linux on Hyper-V List, kys, haiyangz, decui
On Wed, 20 Mar 2024 at 21:09, Wei Liu <wei.liu@kernel.org> wrote:
>
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-next-signed-20240320
Pulled, but...
Your pgp key expired two weeks ago. Please extend the expiration date
(and not something small!) and make sure to refresh the kernel.org
repo and/or other keyservers.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] remoteproc updates for v6.9
@ 2024-03-21 18:05 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-21 18:05 UTC (permalink / raw)
To: Bjorn Andersson
Cc: linux-remoteproc, linux-kernel, Andrew Davis, Neil Armstrong,
Arnaud Pouliquen, Krzysztof Kozlowski, Sibi Sankar, Abel Vesa,
Dmitry Baryshkov, Joakim Zhang, Mathieu Poirier
On Thu, 21 Mar 2024 at 11:03, Bjorn Andersson <andersson@kernel.org> 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 didn't seem at all controversial, but
maybe you should double-check.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
@ 2024-03-21 18:10 99% ` Linus Torvalds
2024-03-21 18:12 99% ` Linus Torvalds
0 siblings, 2 replies; 200+ results
From: Linus Torvalds @ 2024-03-21 18:10 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Greg KH, Andrew Morton, Arnd Bergmann, linux-kernel, llvm
On Thu, 21 Mar 2024 at 06:48, Nathan Chancellor <nathan@kernel.org> wrote:
>
> That build warning actually happens with clang, not GCC as far as I am
> aware, and it is actually a hard build error with older versions of
> clang
So the "labels without a statement" thing is not only a long-time gcc
behavior (admittedly due to a parsing bug), afaik it's becoming
"standard C" in C23.
Does clang have a flag to allow this?
Considering that gcc doesn't warn for it, and that it will become
official at some point anyway, I think this might be a thing that we
might be better off just accepting, rather than be in the situation
where people write code that compiles fine with gcc and don't notice
that clang will error out.
So yes, clang is being correct, but in this case it only causes problems.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
2024-03-21 18:10 99% ` Linus Torvalds
@ 2024-03-21 18:12 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-21 18:12 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Greg KH, Andrew Morton, Arnd Bergmann, linux-kernel, llvm
On Thu, 21 Mar 2024 at 11:10, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So the "labels without a statement" thing is not only a long-time gcc
> behavior (admittedly due to a parsing bug), afaik it's becoming
> "standard C" in C23.
Actually, let me take that back. I think it's only a proposal (WG14
N2508), I have no idea if it's actually going to be standard.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
@ 2024-03-21 20:28 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-21 20:28 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Greg KH, Andrew Morton, Arnd Bergmann, linux-kernel, llvm
On Thu, 21 Mar 2024 at 11:30, Nathan Chancellor <nathan@kernel.org> wrote:
>
> Since GCC does not appear emit warnings for newer C features that it
> allows even with older 'gnu' standard values by default (I think it does
> with '-pedantic'?), perhaps we should just disable -Wc23-extensions
> altogether? Not sure how big of a hammer this is, I think this type of
> warning is the only thing I have seen come from -Wc23-extensions...
It looks like adding -Wno-c23-extensions would only work with more
recent clang versions, so it wouldn't actually fix the build problems,
just make them even harder for developers to actually notice.
Oh well. It's not like this is all that common a problem, so I think
we'll just have to live with it, and hope that people don't do that
"label at end of statement" very often.
(I think it's case statements too, not just labels, too lazy to look
up the details again)
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] SCSI postmerge updates for the 6.8+ merge window
@ 2024-03-22 19:55 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-22 19:55 UTC (permalink / raw)
To: James Bottomley; +Cc: Andrew Morton, linux-scsi, linux-kernel
On Fri, 22 Mar 2024 at 12:12, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> Eleven patches that are based on the rw_hint branch of the vfs tree
> which contained the base block and fs changes needed to support this.
> 8 patches are in the debug driver and 3 in the core.
Please people - the number of patches involved is entirely immaterial.
I want my merge messages to say what those patches *do*?
This whole "how many patches" thing is a disease. It's not even
remotely interesting. I see the size of the patch in the diffstat, and
that actually has some meaning in the sense of "how much does this
pull actually change", whether it's in one patch or a hundred.
I have absolutely *zero* idea what the above pull request actually
asks me to pull.
So I won't.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] SCSI postmerge updates for the 6.8+ merge window
@ 2024-03-22 20:34 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-22 20:34 UTC (permalink / raw)
To: James Bottomley; +Cc: Andrew Morton, linux-scsi, linux-kernel
On Fri, 22 Mar 2024 at 13:24, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> OK, try this (I've updated the scsi-misc tag with it as well)
Well there we go. I really had no idea what the pull was supposed to do.
And while I end up looking at individual commits for random smaller
subsystems when it's unclear (sometimes just for language barrier
issues), for long-time maintainers of bigger stuff I kind of expect
better.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Hyper-V commits for 6.9
@ 2024-03-22 23:42 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-22 23:42 UTC (permalink / raw)
To: Wei Liu; +Cc: Linux Kernel List, Linux on Hyper-V List, kys, haiyangz, decui
On Fri, 22 Mar 2024 at 16:25, Wei Liu <wei.liu@kernel.org> wrote:
>
> Hmm... I thought I refreshed it right before the expiration date. I
> pushed it to Ubuntu's keyserver.
Ok, I can find it there.
> I will check if something's wrong.
>
> Do you have a keyserver that you prefer?
The problem with keyservers is that there's so many of them, and
everybody uses different keyservers, and the propagation of pgp keys
across keyservers hasn't really worked for over a decade by now.
Maybe keys eventually propagate, but I have my doubts.
My default keyserver appears to be hkps://keys.openpgp.org, but the
pgp key git tree on kernel.org is the one I then look at when some key
isn't there (or is there, but hasn't been updated).
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Char/Misc driver changes for 6.9-rc1
@ 2024-03-27 20:26 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-27 20:26 UTC (permalink / raw)
To: Greg KH, Chris Leech, Nilesh Javali, Christoph Hellwig; +Cc: linux-kernel
On Wed, 27 Mar 2024 at 09:56, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I also *suspect* that using 'physaddr_t' is in itself pointless,
> because I *think* the physical addresses are always page-aligned
> anyway, and it would be better if the uio_mem thing just contained the
> pfn instead. Which could just be 'unsigned long pfn'.
Oddly, the uio code seems to be written to allow unaligned page buffers,
actual_pages = ((idev->info->mem[mi].addr & ~PAGE_MASK)
+ idev->info->mem[mi].size + PAGE_SIZE -1) >>
PAGE_SHIFT;
but none of the mmap routines than actually allow such a mapping, and
they all have alignment checks.
Which sounds wonderful, until you find code like this duplicated in
various uio drivers:
uiomem->memtype = UIO_MEM_PHYS;
uiomem->addr = r->start & PAGE_MASK;
uiomem->offs = r->start & ~PAGE_MASK;
uiomem->size = (uiomem->offs + resource_size(r)
+ PAGE_SIZE - 1) & PAGE_MASK;
IOW, it explicitly aligns the resources to pages, so now mmap works
again. Oh the horror.
But yes, that physical part of 'addr' should be a pfn. Sadly, all of
this code is such a mess that it's a horrible job to try to fix it all
up.
So we may be stuck with the horrendous confusion that is the current
uio_mem thing.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tpmdd changes for v6.9-rc2
@ 2024-03-30 22:32 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-03-30 22:32 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Peter Huewe, Jason Gunthorpe, David Howells, linux-integrity,
linux-kernel, keyrings
On Tue, 26 Mar 2024 at 07:38, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/tpmdd-v6.9-rc2
So I haven't pulled this, because the subject line (and tag name)
talks about tpmdd, but this is clearly about key handling.
Also, the actual contents seem to be very much an "update", not fixes.
And it doesn't seem to be an actual improvement, in how it now does
things from interrupts. That seems to be going backward rather than
forward.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tpmdd changes for v6.9-rc2
@ 2024-03-31 17:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-03-31 17:01 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: dhowells, Peter Huewe, Jason Gunthorpe, linux-integrity,
linux-kernel, keyrings
On Sat, 30 Mar 2024 at 22:57, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> OK, point taken and it is evolutionary issue really but definitely
> needs to be fixed.
>
> I review and test most of the stuff that goes to keyring but other
> than trusted keys, I usually pick only few patches every now and
> then to my tree.
It's perfectly fine if you send me key updates - you're listed as
maintainer etc, that's not a problem.
But when I get a tag name that says "tpmdd" and a subject that says
"tpmdd", I'm noty expecting to then see key updates in the pull.
So that part of my issue was literally just that your subject line and
tag name didn't match the contents, and that just makes me go "there's
something wrong here".
So keys coming through your tree is fine per se, it's just that I want
the subject line etc to actually make sense.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] security changes for v6.9-rc3
@ 2024-04-02 21:35 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-02 21:35 UTC (permalink / raw)
To: Al Viro
Cc: Roberto Sassu, linux-integrity, linux-security-module,
linux-fsdevel, linux-cifs, linux-kernel, Roberto Sassu
On Tue, 2 Apr 2024 at 14:00, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> 1) location of that hook is wrong. It's really "how do we catch
> file creation that does not come through open() - yes, you can use
> mknod(2) for that". It should've been after the call of vfs_create(),
> not the entire switch. LSM folks have a disturbing fondness of inserting
> hooks in various places, but IMO this one has no business being where
> they'd placed it. Bikeshedding regarding the name/arguments/etc. for
> that thing is, IMO, not interesting...
Hmm. I guess that's right - for a non-file node, there's nothing that
the security layer can really check after-the-fact anyway.
It's not like you can attest the contents of a character device or whatever...
> 2) the only ->mknod() instance in the tree that tries to leave
> dentry unhashed negative on success is CIFS (and only one case in it).
> From conversation with CIFS folks it's actually cheaper to instantiate
> in that case as well - leaving instantiation to the next lookup will
> cost several extra roundtrips for no good reason.
Ack.
> 3) documentation (in vfs.rst) is way too vague. The actual
> rules are
> * ->create() must instantiate on success
> * ->mkdir() is allowed to return unhashed negative on success and
> it might be forced to do so in some cases. If a caller of vfs_mkdir()
> wants the damn thing positive, it should account for such possibility and do
> a lookup. Normal callers don't care; see e.g. nfsd and overlayfs for example
> of those that do.
> * ->mknod() is interesting - historically it had been "may leave
> unhashed negative", but e.g. unix_bind() expected that it won't do so;
> the reason it didn't blow up for CIFS is that this case (SFU) of their mknod()
> does not support FIFOs and sockets anyway. Considering how few instances
> try to make use of that option and how it doesn't actually save them
> anything, I would prefer to declare that ->mknod() should act as ->create().
> * ->symlink() - not sure; there are instances that make use of that
> option (coda and hostfs). OTOH, the only callers of vfs_symlink() that
> care either way are nfsd and overlayfs, and neither is usable with coda
> or hostfs... Could go either way, but we need to say it clearly in the
> docs, whichever way we choose.
Fair enough.
Anyway, it does sound like maybe the minimal fix would be just that
"move it into the
case 0: case S_IFREG:
path".
Although if somebody already has the cifs patch to just do the
d_instantiate() for mknod, that might be even better.
I will leave this in more competent hands for now.
Let the bike-shedding commence,
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/retpoline: Fix a missing return thunk warning (was: Re: [linus:master] [x86/bugs] 4535e1a417: WARNING:at_arch/x86/kernel/alternative.c:#apply_returns)
@ 2024-04-03 16:45 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-03 16:45 UTC (permalink / raw)
To: Borislav Petkov; +Cc: kernel test robot, oe-lkp, lkp, linux-kernel, Ingo Molnar
On Wed, 3 Apr 2024 at 05:24, Borislav Petkov <bp@alien8.de> wrote:
>
> Subject: [PATCH] x86/retpoline: Fix a missing return thunk warning
Thanks, applied directly,
Linus
^ permalink raw reply [relevance 99%]
* Re: user-space concurrent pipe buffer scheduler interactions
@ 2024-04-03 16:56 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-03 16:56 UTC (permalink / raw)
To: Michael Clark; +Cc: Jens Axboe, Ingo Molnar, Peter Zijlstra, linux-kernel
On Tue, 2 Apr 2024 at 13:54, Michael Clark <michael@metaparadigm.com> wrote:
>
> I am working on a low latency cross-platform concurrent pipe buffer
> using C11 threads and atomics.
You will never get good performance doing spinlocks in user space
unless you actually tell the scheduler about the spinlocks, and have
some way to actually sleep on contention.
Which I don't see you as having.
Linus
^ permalink raw reply [relevance 99%]
* Re: [RESEND][PATCH v3] security: Place security_path_post_mknod() where the original IMA call was
@ 2024-04-03 16:59 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-03 16:59 UTC (permalink / raw)
To: Roberto Sassu
Cc: viro, brauner, jack, paul, jmorris, serge, zohar, linux-fsdevel,
linux-kernel, linux-security-module, linux-cifs, linux-integrity,
pc, Roberto Sassu, Steve French
On Wed, 3 Apr 2024 at 02:10, Roberto Sassu
<roberto.sassu@huaweicloud.com> wrote:
>
> Move security_path_post_mknod() where the ima_post_path_mknod() call was,
> which is obviously correct from IMA/EVM perspective. IMA/EVM are the only
> in-kernel users, and only need to inspect regular files.
Thanks, applied,
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/retpoline: Fix a missing return thunk warning (was: Re: [linus:master] [x86/bugs] 4535e1a417: WARNING:at_arch/x86/kernel/alternative.c:#apply_returns)
@ 2024-04-03 17:13 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-03 17:13 UTC (permalink / raw)
To: Borislav Petkov; +Cc: kernel test robot, oe-lkp, lkp, linux-kernel, Ingo Molnar
On Wed, 3 Apr 2024 at 10:05, Borislav Petkov <bp@alien8.de> wrote:
>
> Can you pls replace it with the below one?
Ok, done.
Linus
^ permalink raw reply [relevance 99%]
* Re: user-space concurrent pipe buffer scheduler interactions
@ 2024-04-03 20:57 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-03 20:57 UTC (permalink / raw)
To: Michael Clark; +Cc: Jens Axboe, Ingo Molnar, Peter Zijlstra, linux-kernel
On Wed, 3 Apr 2024 at 13:52, Michael Clark <michael@metaparadigm.com> wrote:
>
> On 4/4/24 05:56, Linus Torvalds wrote:
> > On Tue, 2 Apr 2024 at 13:54, Michael Clark <michael@metaparadigm.com> wrote:
> >>
> >> I am working on a low latency cross-platform concurrent pipe buffer
> >> using C11 threads and atomics.
> >
> > You will never get good performance doing spinlocks in user space
> > unless you actually tell the scheduler about the spinlocks, and have
> > some way to actually sleep on contention.
> >
> > Which I don't see you as having.
>
> We can work on this.
It's been tried.
Nobody ever found a use-case that is sufficiently convincing, but see
the write-up at
https://lwn.net/Articles/944895/
for a pointer to at least attempts.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH cmpxchg 08/14] parisc: add u16 support to cmpxchg()
@ 2024-04-08 20:10 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-08 20:10 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-arch, linux-kernel, elver, akpm, tglx, peterz, dianders,
pmladek, Arnd Bergmann, Al Viro
On Mon, 8 Apr 2024 at 10:50, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> And get rid of manual truncation down to u8, etc. in there - the
> only reason for those is to avoid bogus warnings about constant
> truncation from sparse, and those are easy to avoid by turning
> that switch into conditional expression.
I support the use of the conditional, but why add the 16-bit case when
it turns out we don't want it after all?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] turbostat 2024.04.10
@ 2024-04-10 20:18 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-10 20:18 UTC (permalink / raw)
To: Len Brown; +Cc: Linux PM list, Linux Kernel Mailing List
On Wed, 10 Apr 2024 at 06:24, Len Brown <lenb@kernel.org> wrote:
>
> Turbostat version 2024.04.10
Tssk. Things like this should still come in during the merge window
and preferably be in linux-next.
I have pulled this, since it's obviously just tooling (and the
maintainer file pattern update), but stil...
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] vfs: relax linkat() AT_EMPTY_PATH - aka flink() - requirements
@ 2024-04-11 0:20 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-11 0:20 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Jan Kara
Cc: linux-fsdevel, linux-kernel, Andrew Lutomirski, Peter Anvin
On Wed, 10 Apr 2024 at 17:10, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> "The definition of insanity is doing the same thing over and over
> again and expecting different results”
Note that I'm sending this patch out not because I plan to commit it,
but to see if people can shoot holes in the concept.
There's a reason why people have tried to do this for decades.
There's also a reason why it has not worked out well.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] vfs: relax linkat() AT_EMPTY_PATH - aka flink() - requirements
@ 2024-04-11 16:21 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-11 16:21 UTC (permalink / raw)
To: Christian Brauner
Cc: Alexander Viro, Jan Kara, linux-fsdevel, linux-kernel,
Andrew Lutomirski, Peter Anvin
On Thu, 11 Apr 2024 at 05:25, Christian Brauner <brauner@kernel.org> wrote:
>
> Btw, I think we should try to avoid putting this into path_init() and
> confine this to linkat() itself imho. The way I tried to do it was by
> presetting a root for filename_lookup(); means we also don't need a
> LOOKUP_* flag for this as this is mostly a linkat thing.
So I had the exact reverse reaction to your patch - I felt that using
that 'root' thing was the hacky case.
The lookup flag may be limited to linkat(), but it makes the code
smaller and clearer, and avoids having multiple places where we check
dfd.
And that 'root' argument really is the special hacky case, and is not
actually used by any normal system call path, and is meant for
internal kernel use rather than any generic case.
Linus
^ permalink raw reply [relevance 99%]
* Re: [tip: locking/core] locking/pvqspinlock: Use try_cmpxchg_acquire() in trylock_clear_pending()
@ 2024-04-11 16:31 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-11 16:31 UTC (permalink / raw)
To: linux-kernel
Cc: linux-tip-commits, Uros Bizjak, Ingo Molnar, Waiman Long, x86
On Thu, 11 Apr 2024 at 06:33, tip-bot2 for Uros Bizjak
<tip-bot2@linutronix.de> wrote:
>
> Use try_cmpxchg_acquire(*ptr, &old, new) instead of
> cmpxchg_relaxed(*ptr, old, new) == old in trylock_clear_pending().
The above commit message is horribly confusing and wrong.
I was going "that's not right", because it says "use acquire instead
of relaxed" memory ordering, and then goes on to say "No functional
change intended".
But it turns out the *code* was always acquire, and it's only the
commit message that is wrong, presumably due to a bit too much
cut-and-paste.
But please fix the commit message, and use the right memory ordering
in the explanations too.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] turbostat 2024.04.10
@ 2024-04-11 19:14 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-11 19:14 UTC (permalink / raw)
To: Len Brown; +Cc: Linux PM list, Linux Kernel Mailing List
On Thu, 11 Apr 2024 at 11:20, Len Brown <lenb@kernel.org> wrote:
>
> ISTR that once upon a time at the kernel summit you expressed a
> preference that things like utilities (which sometimes depend on merge
> window changes) come in after rc1 is declared to basically stay out of
> the way.
That may have been true at some point, but probably long ago - the
merge windows have been so reliable that it's just not an issue any
more.
So I'd rather see people hold to the normal release cycle, and aim to
have the rc releases for fixes or major problems.
We also used to allow entirely new drivers etc outside the release
cycle as a "this cannot regress" exception to the normal rules, but
that has also been largely abandoned as the release cycle is just
short enough that it makes no sense.
So the "new hardware support" rule has basically been watered down
over the years, and has become a "new hardware IDs are fine" kind of
rule, where just adding basically just a PCI ID or OF matching entry
or similar is still fine, but no more "whole new drivers".
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] vfs: relax linkat() AT_EMPTY_PATH - aka flink() - requirements
@ 2024-04-11 20:22 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-11 20:22 UTC (permalink / raw)
To: Charles Mirabile
Cc: Christian Brauner, Alexander Viro, Jan Kara, linux-fsdevel,
linux-kernel, Andrew Lutomirski, Peter Anvin
On Thu, 11 Apr 2024 at 13:08, Charles Mirabile <cmirabil@redhat.com> wrote:
>
> The problem with this is that another process might be able to access
> the file during via that name during the brief period before it is
> unlinked. If I am not using NFS, I am always going to prefer using
> O_TMPFILE. I would rather be able to do that without restriction even
> if it isn't the most robust solution by your definition.
Oh, absolutely. I think the right pattern is basically some variation of
fd = open(filename, O_TMPFILE | O_WRONLY, 0600);
if (fd < 0) {
char template{...] = ".tmpfileXXXXXX";
fd = mkstmp(template);
unlink(template);
}
.. now act on fd to initialize it ..
linkat(fd, "", AT_FDCWD, "finalname", AT_EMPTY_PATH);
which should work reasonably well in various environments.
Clearly O_TMPFILE is the superior option when it exists. I'm just
saying that anything that *relies* on it existing is dubious.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] vfs: relax linkat() AT_EMPTY_PATH - aka flink() - requirements
@ 2024-04-12 15:36 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-12 15:36 UTC (permalink / raw)
To: Christian Brauner
Cc: Charles Mirabile, Alexander Viro, Jan Kara, linux-fsdevel,
linux-kernel, Andrew Lutomirski, Peter Anvin
On Fri, 12 Apr 2024 at 00:46, Christian Brauner <brauner@kernel.org> wrote:
>
> Hm, I would like to avoid adding an exception for O_PATH.
Ack. It's not the important or really relevant part.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Fixes for v6.9
@ 2024-04-12 16:07 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-12 16:07 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Andrew Morton,
Arnd Bergmann, Prasad Pandit, Yang Li
On Fri, 12 Apr 2024 at 07:29, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> - Replace bad tab with space in Kconfig for FTRACE_RECORD_RECURSION_SIZE
Argh. What parser is this? We need to fix this craziness.
Yes, yes, we have "tabs and spaces" issues due to the fundamental
brokenness of make, and we can't get rid of *that* bogosity.
But for our own Kconfig files? Whitespace is whitespace (ignoring
crazy unicode extensions), we need to get away from "tabs and spaces
act differently".
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Fixes for v6.9
@ 2024-04-12 16:20 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-12 16:20 UTC (permalink / raw)
To: Steven Rostedt
Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Andrew Morton,
Arnd Bergmann, Prasad Pandit, Yang Li
On Fri, 12 Apr 2024 at 09:15, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Note, the tab is here:
Yeah, yeah, I checked.
I also checked that the normal "make defconfig" does not care.
In fact, I'm seriously inclined to make sure that our main Kconfig
file has several tabs in several places, just to make damn sure that
any broken sh*t is fixed.
Because no, the fix is *not* to try to fix invisible problems in the
Kconfig files themselves.
I've pulled your thing, but any parsers that think tabs and spaces are
different need to either be fixed, or they need to be shunned.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing: Fixes for v6.9
@ 2024-04-12 16:21 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-12 16:21 UTC (permalink / raw)
To: Randy Dunlap
Cc: Steven Rostedt, LKML, Masami Hiramatsu, Mathieu Desnoyers,
Andrew Morton, Arnd Bergmann, Prasad Pandit, Yang Li
On Fri, 12 Apr 2024 at 09:20, Randy Dunlap <rdunlap@infradead.org> wrote:
> >>
> >> Argh. What parser is this? We need to fix this craziness.
>
> something that fedora cares about.
> out-of-tree I expect.
Ok, that shit will now be broken immediately by me adding tabs to our
Kconfig file.
Because no, some out-of-tree garbage is not relevant, and if they
don't fix it out of tree, that's *their* problem, not ours.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2 1/3] x86/bugs: Only harden syscalls when needed
@ 2024-04-15 15:16 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-15 15:16 UTC (permalink / raw)
To: Nikolay Borisov
Cc: Josh Poimboeuf, x86, linux-kernel, Daniel Sneddon, Pawan Gupta,
Thomas Gleixner, Alexandre Chartre, Konrad Rzeszutek Wilk,
Peter Zijlstra, Greg Kroah-Hartman, Sean Christopherson,
Andrew Cooper, Dave Hansen, KP Singh, Waiman Long,
Borislav Petkov, Ingo Molnar
On Mon, 15 Apr 2024 at 00:37, Nikolay Borisov <nik.borisov@suse.com> wrote:
>
> To ask again, what do we gain by having this syscall hardening at the
> same time as the always on BHB scrubbing sequence?
What happens the next time some indirect call problem comes up?
If we had had *one* hardware bug in this area, that would be one
thing. But this has been going on for a decade now.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Btrfs fixes for 6.9-rc5
@ 2024-04-18 0:14 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-18 0:14 UTC (permalink / raw)
To: David Sterba; +Cc: linux-btrfs, linux-kernel
On Wed, 17 Apr 2024 at 16:53, David Sterba <dsterba@suse.com> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git tags/for-6.9-rc4-tag
Nol such tag. I see the branch 'for-6.9-rc4' with the right commit,
but not the signed tag. Forgot to push out?
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] tty: n_gsm: restrict tty devices to attach
@ 2024-04-20 18:05 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-20 18:05 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Greg Kroah-Hartman, Jiri Slaby, Andrew Morton, Starke, Daniel,
LKML, linux-security-module
On Sat, 20 Apr 2024 at 11:02, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Most other normal tty devices just expect ->write() to be called in
> normal process context, so if we do a line discipline flag, it would
^^^^^^^^^^^^^^^^^^^^
> have to be something like "I'm ok with being called with interrupts
> disabled", and then the n_gsm ->open function would just check that.
Not line discipline - it would be a 'struct tty_operations' flag
saying 'my ->write() function is ok with atomic context".
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v2] tty: n_gsm: restrict tty devices to attach
@ 2024-04-23 16:37 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-23 16:37 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Greg Kroah-Hartman, Jiri Slaby, Andrew Morton, Starke, Daniel,
LKML, linux-security-module
On Tue, 23 Apr 2024 at 08:26, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2024/04/22 1:04, Linus Torvalds wrote:
> >
> > Actually, another option would be to just return an error at 'set_ldisc()' time.
>
> This patch works for me. You can propose a formal patch.
Ok, I wrote a commit message, added your tested-by, and sent it out
https://lore.kernel.org/all/20240423163339.59780-1-torvalds@linux-foundation.org/
let's see if anybody has better ideas, but that patch at least looks
palatable to me.
Linus
^ permalink raw reply [relevance 99%]
* Re: regression fixes sitting in subsystem git trees for a week or longer (was: Re: [PATCH v2] HID: i2c-hid: Revert to await reset ACK before reading report descriptor)
@ 2024-04-24 18:53 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-24 18:53 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Jiri Kosina, Douglas Anderson, Hans de Goede, linux-input,
linux-kernel, Kenny Levinsen, Benjamin Tissoires,
Linux regressions mailing list
On Wed, 24 Apr 2024 at 09:56, Thorsten Leemhuis
<regressions@leemhuis.info> wrote:
>
> out of interest: what's your stance on regression fixes sitting in
> subsystem git trees for a week or longer before being mainlined?
Annoying, but probably depends on circumstances. The fact that it took
a while to even be noticed presumably means it's not common or holding
anything up.
That said, th4e last HID pull I have is from March 14. If the issue is
just that there's nothing else happening, I think people should just
point me to the patch and say "can you apply this single fix?"
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] ACPI fixes for v6.9-rc6
@ 2024-04-25 19:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-25 19:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: ACPI Devel Maling List, Linux PM, Linux Kernel Mailing List
On Thu, 25 Apr 2024 at 11:58, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> When that macro now has had TWO independent bugs, how about you just
> write it out with explicit types and without any broken "helpers":
>
> static inline u64 MASK_VAL(const struct cpc_reg *reg, u64 val)
> {
> u64 mask = (1ull << reg->bit_width)-1;
> return (val >> reg->bit_offset) & mask;
> }
>
> which is a few more lines, but doesn't that make it a whole lot more readable?
>
> And maybe this time, it's not a buggy mess?
Just to clarify: that was written in the MUA, and entirely untested.
Somebody should still verify it, but really, with already now two
bugs, that macro needs fixing for good, and the "for good" should be
looking at least _something_ like the above.
And despite needing fixing, I've done the pull, since bug #2 is at
least less bad than bug#1 was.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
@ 2024-04-28 18:50 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-28 18:50 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Greg Kroah-Hartman, Dmitry Vyukov, syzbot, linux-kernel,
syzkaller-bugs, Nathan Chancellor, Arnd Bergmann, Al Viro,
Jiri Slaby
On Sun, 28 Apr 2024 at 03:20, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
>
> If we keep the current model, WRITE_ONCE() is not sufficient.
>
> My understanding is that KCSAN's report like
I find it obnoxious that these are NOT REAL PROBLEMS.
It's KCSAN that is broken and doesn't allow us to just tell it to
sanely ignore things.
I don't want to add stupid and pointless annotations for a broken tooling.
Can you instead just ask the KCSAN people to have some mode where we
can annotate a pointer as a "use one or the other", and just shut that
thing up that way?
Because no, we're not adding some idiotic "f_op()" wrapper just to
shut KCSAN up about a non-issue.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] scheduler fixes
@ 2024-04-28 19:13 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-28 19:13 UTC (permalink / raw)
To: Ingo Molnar
Cc: Vincent Guittot, linux-kernel, Peter Zijlstra, Thomas Gleixner,
Juri Lelli, Daniel Bristot de Oliveira, Valentin Schneider
On Sun, 28 Apr 2024 at 01:42, Ingo Molnar <mingo@kernel.org> wrote:
>
> Merge note: in case you are wondering about the timestamps, I ninja-rebased
> these two commits shortly before the pull request to fix an annoying typo
> in a commit title.
Hmm. You also forgot to have a diffstat..
Linus
^ permalink raw reply [relevance 99%]
* Re: [syzbot] [bpf?] [trace?] possible deadlock in force_sig_info_to_task
@ 2024-04-29 0:50 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-29 0:50 UTC (permalink / raw)
To: Hillf Danton
Cc: syzbot, Tetsuo Handa, andrii, bpf, linux-kernel, syzkaller-bugs
On Sun, 28 Apr 2024 at 16:23, Hillf Danton <hdanton@sina.com> wrote:
>
> So is game like copying from/putting to user with runqueue locked
> at the first place.
No, that should be perfectly fine. In fact, it's even normal. It would
happen any time you have any kind of tracing thing, where looking up
the user mode frame involves doing user accesses with page faults
disabled.
The runqueue lock is irrelevant. As mentioned, it's only a symptom of
something else going wrong.
Now, judging by the syz reproducer, the trigger for this all is almost
certainly that
bpf$BPF_RAW_TRACEPOINT_OPEN(0x11,
&(0x7f00000000c0)={&(0x7f0000000080)='sched_switch\x00', r0}, 0x10)
and that probably causes the instability. But the immediate problem is
not the user space access, it's that something goes horribly wrong
*around* it.
> Plus as per another syzbot report [1], bpf could make trouble with
> workqueue pool locked.
That seems to be entirely different. There's no unexplained page fault
in that case, that seems to be purely a "take lock in the wrong order"
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS
@ 2024-04-29 15:32 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-29 15:32 UTC (permalink / raw)
To: Matthew Wilcox (Oracle)
Cc: linux-kernel,
Михаил
Новоселов,
Ильфат
Гаптрахманов,
stable, Rik van Riel, Mel Gorman, Peter Zijlstra, Ingo Molnar,
Andrew Morton
On Mon, 29 Apr 2024 at 07:48, Matthew Wilcox (Oracle)
<willy@infradead.org> wrote:
>
> bits_per() rounds up to the next power of two when passed a power of
> two. This causes crashes on some machines and configurations.
Bah. Your patch is *still* wrong, because bits_per() thinks you need
one bit for a zero value, so when you do
bits_per(CONFIG_NR_CPUS - 1)
and some insane person has enabled SMP and managed to set
CONFIG_NR_CPUS to 1, the math is *still* broken.
The right thing to do is
order_base_2(CONFIG_NR_CPUS)
and 'bits_per()' should be avoided, having completely crazy semantics
(you can tell how almost all users actually do "x-1" as the argument).
We should probably get rid of that horrid bits_per(() entirely.
I applied your patch with that fixed (which admittedly make it all
*my* patch, but applying it as yours just to get the changelog).
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/mm: Remove broken vsyscall emulation code from the page fault code
@ 2024-04-29 15:51 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-04-29 15:51 UTC (permalink / raw)
To: Ingo Molnar
Cc: Hillf Danton, Andy Lutomirski, Peter Anvin, Adrian Bunk, syzbot,
Tetsuo Handa, andrii, bpf, linux-kernel, syzkaller-bugs
On Mon, 29 Apr 2024 at 01:00, Ingo Molnar <mingo@kernel.org> wrote:
>
> I did some Simple Testing™, and nothing seemed to break in any way visible
> to me, and the diffstat is lovely:
>
> 3 files changed, 3 insertions(+), 56 deletions(-)
>
> Might stick this into tip:x86/mm and see what happens?
Well, Hilf had it go through the syzbot testing, and Jiri seems to
have tested it on his setup too, so it looks like it's all good, and
you can change the "Not-Yet-Signed-off-by" to be a proper sign-off
from me.
It would be good to have some UML testing done, but at the same time I
do think that anybody running UML on modern kernels should be running
a modern user-mode setup too, so while the exact SIGSEGV details may
have been an issue in 2011, I don't think it's reasonable to think
that it's an issue in 2024.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] x86/mm: Remove broken vsyscall emulation code from the page fault code
@ 2024-04-30 0:05 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-04-30 0:05 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Ingo Molnar, Hillf Danton, Peter Anvin, Adrian Bunk, syzbot,
Tetsuo Handa, andrii, bpf, linux-kernel, syzkaller-bugs
On Mon, 29 Apr 2024 at 16:30, Andy Lutomirski <luto@amacapital.net> wrote:
>
> What strange page table handling do we do for XONLY?
Ahh, I misread set_vsyscall_pgtable_user_bits(). It's used for EMULATE
not for XONLY.
And the code in pti_setup_vsyscall() is just wrong, and does it for all cases.
> So I think we should remove EMULATE before removing XONLY.
Ok, looking at that again, I don't disagree. I misread that XONLY as
mapping it executable, but it is actually just mapping it readable
Yes, let's remove EMULATE, and keep XONLY.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
@ 2024-05-01 18:56 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-01 18:56 UTC (permalink / raw)
To: paulmck
Cc: Marco Elver, Tetsuo Handa, Greg Kroah-Hartman, Dmitry Vyukov,
syzbot, linux-kernel, syzkaller-bugs, Nathan Chancellor,
Arnd Bergmann, Al Viro, Jiri Slaby
On Wed, 1 May 2024 at 11:46, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> In short, I for one do greatly value KCSAN's help. Along with that of
> a great many other tools, none of which are perfect, but all of which
> are helpful.
It's not that I don't value what KCSAN does, but I really think this
is a KCSAN issue.
I absolutely *detest* these crazy "randomly add data race annotations".
Could we instead annotate particular structure fields? I don't want to
mark things actually "volatile", because that then causes the compiler
to generate absolutely horrendous code. But some KCSAN equivalent of
"this field has data races, and we don't care" kind of annotation
would be lovely..
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
@ 2024-05-02 17:29 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-02 17:29 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Marco Elver, paulmck, Greg Kroah-Hartman, Dmitry Vyukov, syzbot,
linux-kernel, syzkaller-bugs, Nathan Chancellor, Arnd Bergmann,
Al Viro, Jiri Slaby
On Thu, 2 May 2024 at 09:42, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> OK if below change is acceptable.
>
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1012,7 +1012,7 @@ struct file {
> struct file_ra_state f_ra;
> struct path f_path;
> struct inode *f_inode; /* cached value */
> - const struct file_operations *f_op;
> + const __data_racy struct file_operations *f_op;
No, this is very wrong.
It's not the *pointer* that is __data_racy. It's the structure *fied*.
So that should be
const struct file_operations *__data_racy f_op;
which is very different.
> Hmm, debugfs assumes that f_op does not change?
>
> fs/debugfs/file.c: In function 'full_proxy_release':
> fs/debugfs/file.c:357:45: warning: initialization discards 'volatile' qualifier from pointer target type [-Wdiscarded-qualifiers]
> const struct file_operations *proxy_fops = filp->f_op;
> ^~~~
This error is a direct result of placing the __data_racy in the wrong place.
It's not that the _result_ of reading filp->f_op is racy. It's the
read of filp->f_op itself that is.
Yes, this is unusual. The *common* thing is to mark pointers as being
volatile. But this really is something entirely different from that.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
@ 2024-05-03 1:12 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-03 1:12 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Marco Elver, paulmck, Greg Kroah-Hartman, Dmitry Vyukov, syzbot,
linux-kernel, syzkaller-bugs, Nathan Chancellor, Arnd Bergmann,
Al Viro, Jiri Slaby
On Thu, 2 May 2024 at 16:54, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> debugfs (or maybe any filesystems that wraps f_op) caches filp->f_op into
> private data
That's just for debugfs uses. If you somehow try to do that on a tty,
you are quite welcome to keep both broken pieces.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH 10/14] alpha: remove DECpc AXP150 (Jensen) support
@ 2024-05-03 16:07 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-03 16:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-alpha, Arnd Bergmann, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Alexander Viro, Marc Zyngier, Paul E. McKenney,
linux-kernel
On Fri, 3 May 2024 at 01:12, Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> This is one of the hackiest Alpha machines, and the only one without
> PCI support. Removing this allows cleaning up code in eise and tty
> drivers in addition to the architecture code.
Oh well, The axp150 was the machine I used originally, so it's a bit
sad to see it go.
But yeah, good riddance. The lack of byte and word operations were a
fundamental mistake and made those early alphas very painful.
The design team obviously made other technical mistakes (sw fill tlb
etc, with memory ordering being the one that never got fixed), but the
byte were the killer for any sanity both on the IO side and the code
generation side.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
@ 2024-05-03 21:52 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-03 21:52 UTC (permalink / raw)
To: Al Viro
Cc: keescook, axboe, brauner, christian.koenig, dri-devel, io-uring,
jack, laura, linaro-mm-sig, linux-fsdevel, linux-kernel,
linux-media, minhquangbui99, sumit.semwal,
syzbot+045b454ab35fd82a35fb, syzkaller-bugs
On Fri, 3 May 2024 at 14:45, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> How do you get through eventpoll_release_file() while someone
> has entered ep_item_poll()?
Doesn't matter.
Look, it's enough that the file count has gone down to zero. You may
not even have gotten to eventpoll_release_file() yet - the important
part is that you're on your *way* to it.
That means that the file will be released - and it means that you have
violated all the refcounting rules for poll().
So I think you're barking up the wrong tree.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] tracing/tracefs: Fixes for v6.9
@ 2024-05-04 0:01 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-04 0:01 UTC (permalink / raw)
To: Steven Rostedt; +Cc: LKML, Masami Hiramatsu, Mathieu Desnoyers, Beau Belgrave
On Fri, 3 May 2024 at 16:07, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> - Minor fix for user_events interface
> The ABI of creating a user event states that the fields
> are separated by semicolons, and spaces should be ignored.
> But the parsing expected at least one space to be there (which was incorrect).
> Fix the reading of the string to handle fields separated by
> semicolons but no space between them.
This is the opposite of a fix.
A fix would have fixed the documentation to match reality.
Instead, this relaxes our existing parsing. Are there any old kernels
that had that relaxed parsing? Is there any actual reason to not just
fix documentation to match reality?
Because when reality and documentation do not match, it is not
*REALITY* that is buggy.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
@ 2024-05-04 0:14 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-04 0:14 UTC (permalink / raw)
To: paulmck
Cc: Boqun Feng, Marco Elver, Tetsuo Handa, Greg Kroah-Hartman,
Dmitry Vyukov, syzbot, linux-kernel, syzkaller-bugs,
Nathan Chancellor, Arnd Bergmann, Al Viro, Jiri Slaby
On Fri, 3 May 2024 at 16:59, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Hmmm... Maybe something like this very lightly tested patch?
I'm a bit nervous about using the built-in atomics, when it's not
clear what the compiler will do on various architectures.
Gcc documentation talks about __atomic_is_lock_free(), which makes me
think that on various architectures it might end up doing some "fall
back to helper functions" cases (possibly for odd architectures).
IOW: I don't think the patch is wrong, but I do think we need to
verify that all compilers we support generate the obvious code for
this, and we don't have some "fall back to function calls".
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH v3] tty: tty_io: remove hung_up_tty_fops
@ 2024-05-04 17:50 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-04 17:50 UTC (permalink / raw)
To: paulmck
Cc: Boqun Feng, Marco Elver, Tetsuo Handa, Greg Kroah-Hartman,
Dmitry Vyukov, syzbot, linux-kernel, syzkaller-bugs,
Nathan Chancellor, Arnd Bergmann, Al Viro, Jiri Slaby
On Fri, 3 May 2024 at 22:08, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> You are right, this is going to need some arch-specific code for a few
> of the architectures. Hey, I was hoping!!!
>
> The compilers do not currently optimize these things, but things appear
> to me to be heading in that direction.
Ok, so it sounds like right now it makes no sense - presumably
__atomic_load_n() doesn't actually generate better code than
READ_ONCE() does as-is, and we have the issue with having to make it
per-architecture anyway.
But maybe in a couple of years we can revisit this when / if it
actually generates better code and is more widely applicable.
Linus
^ permalink raw reply [relevance 99%]
* Re: [BUG][v6.9-rc6] Deadlock with: Revert "drm/qxl: simplify qxl_fence_wait"
@ 2024-05-06 20:28 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-06 20:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Steven Rostedt, LKML, Alex Constantino, Timo Lindfors,
Dave Airlie, Gerd Hoffmann, Maarten Lankhorst, Thomas Zimmermann,
Daniel Vetter
On Mon, 6 May 2024 at 05:46, Maxime Ripard <mripard@kernel.org> wrote:
>
> It looks like qxl is not well maintained. Please send the revert, we'll
> merge it.
I'll just do the revert and we don't have to do the round-trip
overhead (since we're already in rc7 and I hope to just do final next
weekend).
Linus
^ permalink raw reply [relevance 99%]
* Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
@ 2024-05-07 19:07 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-07 19:07 UTC (permalink / raw)
To: Daniel Vetter
Cc: Simon Ser, Pekka Paalanen, Christian König,
Christian Brauner, Al Viro, keescook, axboe, christian.koenig,
dri-devel, io-uring, jack, laura, linaro-mm-sig, linux-fsdevel,
linux-kernel, linux-media, minhquangbui99, sumit.semwal,
syzbot+045b454ab35fd82a35fb, syzkaller-bugs
On Tue, 7 May 2024 at 11:04, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
>
> > I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl
> > too, if this is possibly a more common thing. and not just DRM wants
> > it.
> >
> > Would something like that work for you?
>
> Yes.
>
> Adding Simon and Pekka as two of the usual suspects for this kind of
> stuff. Also example code (the int return value is just so that callers know
> when kcmp isn't available, they all only care about equality):
>
> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/os_file.c#L239
That example thing shows that we shouldn't make it a FISAME ioctl - we
should make it a fcntl() instead, and it would just be a companion to
F_DUPFD.
Doesn't that strike everybody as a *much* cleaner interface? I think
F_ISDUP would work very naturally indeed with F_DUPFD.
Yes? No?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] ARM SoC fixes for 6.9, part 3
@ 2024-05-08 17:22 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-08 17:22 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: soc, linux-kernel, linux-arm-kernel
On Tue, 7 May 2024 at 23:00, Arnd Bergmann <arnd@arndb.de> wrote:
>
> ARM SoC fixes for 6.9, part 3
Hmm. Some of this already came in in "part 2", and your diffstat is
wrong as a result.
You seem to have done the mtk-soc merge again:
> Arnd Bergmann (3):
> Merge tag 'mtk-soc-fixes-for-v6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into for-next
and this part of the diffstat:
> drivers/soc/mediatek/Kconfig | 1 +
> drivers/soc/mediatek/mtk-svs.c | 7 +++++--
doesn't show up for me because I already had it from your
soc-fixes-6.9-2 pull request.
I've pulled this, but am a bit confused about how you missed your own
previous pull..
Linus
^ permalink raw reply [relevance 99%]
* Re: [Linaro-mm-sig] Re: [PATCH] epoll: try to be a _bit_ better about file lifetimes
@ 2024-05-09 15:48 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-09 15:48 UTC (permalink / raw)
To: Christian Brauner
Cc: Daniel Vetter, Simon Ser, Pekka Paalanen, Christian König,
Al Viro, keescook, axboe, christian.koenig, dri-devel, io-uring,
jack, laura, linaro-mm-sig, linux-fsdevel, linux-kernel,
linux-media, minhquangbui99, sumit.semwal,
syzbot+045b454ab35fd82a35fb, syzkaller-bugs
On Thu, 9 May 2024 at 04:39, Christian Brauner <brauner@kernel.org> wrote:
>
> Not worth it without someone explaining in detail why imho. First pass
> should be to try and replace kcmp() in scenarios where it's obviously
> not needed or overkill.
Ack.
> I've added a CLASS(fd_raw) in a preliminary patch since we'll need that
> anyway which means that your comparison patch becomes even simpler imho.
> I've also added a selftest patch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git/log/?h=vfs.misc
LGTM.
Maybe worth adding an explicit test for "open same file, but two
separate opens, F_DUPFD_QUERY returns 0? Just to clarify the "it's not
testing the file on the filesystem for equality, but the file pointer
itself".
Linus
^ permalink raw reply [relevance 99%]
* Re: [RFC] Mitigating unexpected arithmetic overflow
@ 2024-05-09 18:08 99% ` Linus Torvalds
2024-05-09 18:39 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-09 18:08 UTC (permalink / raw)
To: Al Viro
Cc: Theodore Ts'o, Kees Cook, Justin Stitt, Peter Zijlstra,
Mark Rutland, linux-hardening, linux-kernel, llvm
On Thu, 9 May 2024 at 10:54, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Thu, May 09, 2024 at 08:38:28AM -0700, Linus Torvalds wrote:
>
> > Going the other way is similar:
> >
> > all_bits = low_bits + ((u64) high_bits << 16) << 16);
> >
> > and again, the compiler will recognize this idiom and do the right
> > thing (and if 'all_bits' is only 32-bit, the compiler will optimize
> > the high bit noise away).
>
> Umm... That would make sense if it was
> all_bits = low_bits + ((T) high_bits << 16) << 16);
> with possibly 32bit T. But the way you wrote that (with u64) it's
> pointless - u64 _can_ be shifted by 32 just fine.
Casting to 'T' is probably a clearer option but doesn't work very well
in a helper functions that may not know what the final type is.
Any half-way decent compiler will end up optimizing away the shifts
and adds for the high bits because they see the assignment to
'all_bits'. There's no point in generating high bits that just get
thrown away.
Linus
^ permalink raw reply [relevance 99%]
* Re: [RFC] Mitigating unexpected arithmetic overflow
2024-05-09 18:08 99% ` Linus Torvalds
@ 2024-05-09 18:39 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-09 18:39 UTC (permalink / raw)
To: Al Viro
Cc: Theodore Ts'o, Kees Cook, Justin Stitt, Peter Zijlstra,
Mark Rutland, linux-hardening, linux-kernel, llvm
On Thu, 9 May 2024 at 11:08, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Any half-way decent compiler will end up optimizing away the shifts
> and adds for the high bits because they see the assignment to
> 'all_bits'. There's no point in generating high bits that just get
> thrown away.
.. it might also actually be a good idea *IF* we were to have some
kind of "implicit cast drops bits" warning, in that the compiler for
that case wouldn't remove the upper bits calculation, but would
trigger a warning if they are non-zero.
So there are actually potential advantages to just always apparently
doing the full 64-bit arithmetic.
Without debug warnings, it's a no-op that the compiler will just skip.
And with some hypothetical debug flag, it would be a "you are now
losing the high bits of the time value when assigning the result to a
limited 32-bit time_t" warning.
Linus
^ permalink raw reply [relevance 99%]
* Re: [RFC] Mitigating unexpected arithmetic overflow
@ 2024-05-09 19:15 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-09 19:15 UTC (permalink / raw)
To: Al Viro
Cc: Theodore Ts'o, Kees Cook, Justin Stitt, Peter Zijlstra,
Mark Rutland, linux-hardening, linux-kernel, llvm
On Thu, 9 May 2024 at 11:48, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> FWIW, the thing that somewhat worries me about having a helper along
> the lines of combine_to_u64(low, high) is that
> foo->splat = combine_to_u64(something, something_else);
> would be inviting hard-to-catch brainos -
> foo->splat = combine_to_u64(something_else, something);
Yeah, we'd have to be very clear about naming and ordering. So it
would probably have to be something like
result = combine_to_u64_hi_lo(high, low);
to be easy to use.
The good news is that if you *do* get it wrong despite clear naming,
the resulting value will be so obviously wrong that it's generally a
"Duh!" thing if you do any testing what-so-ever.
Of course, I say that as somebody who always points out that I haven't
tested my own patches at all, and they are "something like this,
perhaps?".
But having "hi_lo" kind of naming would hopefully make it really
obvious even when just looking at the source code.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] hotfixes for 6.10
@ 2024-05-10 21:00 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-10 21:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, mm-commits, linux-kernel
On Fri, 10 May 2024 at 13:17, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> 18 hotfixes, 7 of which are cc:stable.
I assume the subject line is wrong, and you meant 6.9.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] asm-generic cleanups for 6.10
@ 2024-05-13 16:11 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-13 16:11 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, Linux-Arch, Thomas Zimmermann, Thorsten Blum
On Fri, 10 May 2024 at 14:17, Arnd Bergmann <arnd@arndb.de> wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git asm-generic-6.10
Hmm. That tag doesn't exist. The top commit you mention doesn't exist
under any other name either, so there isn't even a matching branch.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] alpha: cleanups and build fixes for 6.10
@ 2024-05-13 16:27 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-13 16:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Linux-Arch, linux-alpha, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Alexander Viro, Paul E. McKenney
On Fri, 10 May 2024 at 14:20, Arnd Bergmann <arnd@arndb.de> wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-alpha
Well, despite the discussion about timing of this, I have pulled this.
I still have a fond spot for alpha, even if it has the worst memory
ordering ever devised, but the lack of byte operations was an
inexcusable "we can deal with that in the compiler" senior moment in
the design. So good riddance.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] RCU changes for v6.10
@ 2024-05-13 16:48 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-13 16:48 UTC (permalink / raw)
To: paulmck
Cc: Uladzislau Rezki (Sony),
RCU, LKML, Ingo Molnar, Thomas Gleixner, Johannes Berg,
Nikita Kiryushin, linke li, Zqiang, Zenghui Yu, Neeraj upadhyay,
Boqun Feng, Joel Fernandes, Frederic Weisbecker,
Oleksiy Avramchenko
On Mon, 13 May 2024 at 09:46, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Yes, this is intentional, nothing odd is going on, and Uladzislau's pull
> request is legitimate.
If this is more than a one-time thing, maybe Uladzislau should be in
the MAINTAINERS entry too?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] RCU changes for v6.10
@ 2024-05-13 16:58 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-13 16:58 UTC (permalink / raw)
To: paulmck
Cc: Uladzislau Rezki (Sony),
RCU, LKML, Ingo Molnar, Thomas Gleixner, Johannes Berg,
Nikita Kiryushin, linke li, Zqiang, Zenghui Yu, Neeraj upadhyay,
Boqun Feng, Joel Fernandes, Frederic Weisbecker,
Oleksiy Avramchenko
On Mon, 13 May 2024 at 09:56, Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Unless you tell me you want it sooner, we will sending this into the
> v6.11 merge window.
No hurry, just as long as it gets done at some point. Uladzislau is in
my keychain now, so this no longer triggers big warning messages in my
scripts..
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] x86/boot changes for v6.10
@ 2024-05-14 1:02 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-14 1:02 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, the arch/x86 maintainers, Ard Biesheuvel, H. Peter Anvin
On Sun, 12 May 2024 at 23:51, Ingo Molnar <mingo@kernel.org> wrote:
>
> - Re-introduce a bootloader quirk wrt. CR4 handling
I've pulled this, but shouldn't the compressed boot also just stop
setting the G flag that it didn't understand?
For example, arch/x86/kernel/head64.c seems to do this:
pmd_entry = __PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL;
but arch/x86/boot/compressed/ident_map_64.c does the somewhat suspect
mapping_info.page_flag = __PAGE_KERNEL_LARGE_EXEC | sme_me_mask;
without masking off _PAGE_GLOBAL.
The hibernation code does
pgprot_t pmd_text_prot = __pgprot(__PAGE_KERNEL_LARGE_EXEC);
pgprot_val(pmd_text_prot) &= __default_kernel_pte_mask;
and again there are several situations where __default_kernel_pte_mask
does not have _PAGE_GLOBAL.
So again, the boot/compressed code seems a bit at an odds with other
code paths. The cr4 games seem to work around the fact that this code
is just buggy.
Hmm?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] x86/shstk change for v6.10
@ 2024-05-14 2:38 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-14 2:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-kernel, the arch/x86 maintainers, H.J. Lu, H. Peter Anvin
On Mon, 13 May 2024 at 01:13, Ingo Molnar <mingo@kernel.org> wrote:
>
> Enable shadow stacks for x32.
>
> While we normally don't do such feature-enabling on 32-bit
> kernels anymore, this change is small, straightforward & tested on
> upstream glibc.
Color me confused.
"feature-enabling on 32-bit kernels"
This is not for 32-bit kernels, as far as I can tell. This is just the
x32 user mode for x86-64 kernels.
Or am I missing something?
I've pulled this, but does anybody actually use x32? I feel like it
was a failed experiment. No?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Networking for v6.10
@ 2024-05-15 4:06 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-15 4:06 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, linux-kernel, pabeni, bpf
On Tue, 14 May 2024 at 20:32, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Why does it do that disgusting
>
> struct bpf_array *array = container_of(map, struct bpf_array, map);
> ...
> *insn++ = BPF_ALU32_IMM(BPF_AND, BPF_REG_0, array->index_mask);
>
> thing? As far as I can tell, a bpf map can be embedded in many
> different structures, not just that 'bpf_array' thing.
Bah. It still needs to do that array->elem_size, so it's not just the
spectre-v1 code that needs that 'bpf_array' thing.
And the non-percpu case seems to do all the same contortions, so I
don't know why the new percpu array would show issues.
Oh well. I guess the bpf people will figure it out once they come back
from "partying at LSFMM" as you put it.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] vfs: Delete the associated dentry when deleting a file
@ 2024-05-15 16:05 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-15 16:05 UTC (permalink / raw)
To: Yafang Shao, kernel test robot
Cc: brauner, jack, linux-fsdevel, longman, viro, walters, wangkai86,
linux-mm, linux-kernel, Matthew Wilcox
Oliver,
is there any chance you could run this through the test robot
performance suite? The original full patch at
https://lore.kernel.org/all/20240515091727.22034-1-laoar.shao@gmail.com/
and it would be interesting if the test robot could see if the patch
makes any difference on any other loads?
Thanks,
Linus
On Wed, 15 May 2024 at 02:17, Yafang Shao <laoar.shao@gmail.com> wrote:
>
> Our applications, built on Elasticsearch[0], frequently create and delete
> files. These applications operate within containers, some with a memory
> limit exceeding 100GB. Over prolonged periods, the accumulation of negative
> dentries within these containers can amount to tens of gigabytes.
>
> Upon container exit, directories are deleted. However, due to the numerous
> associated dentries, this process can be time-consuming. Our users have
> expressed frustration with this prolonged exit duration, which constitutes
> our first issue.
^ permalink raw reply [relevance 99%]
* Re: [PATCH 6.1 000/243] 6.1.91-rc2 review
@ 2024-05-15 16:20 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-15 16:20 UTC (permalink / raw)
To: Mark Brown
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml,
Florian Fainelli, Doug Berger
On Wed, 15 May 2024 at 09:17, Mark Brown <broonie@kernel.org> wrote:
>
> A bisect claims that "net: bcmgenet:
> synchronize EXT_RGMII_OOB_CTRL access" is the first commit that breaks,
> I'm not seeing issues with other stables.
That's d85cf67a3396 ("net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL
access") upstream. Is upstream ok?
Linus
^ permalink raw reply [relevance 99%]
* Re: [git pull] drm for 6.10-rc1
@ 2024-05-15 20:24 99% ` Linus Torvalds
2024-05-15 20:29 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-15 20:24 UTC (permalink / raw)
To: Dave Airlie, Arunpravin Paneer Selvam, Christian König,
Matthew Auld
Cc: Daniel Vetter, dri-devel, LKML
On Wed, 15 May 2024 at 13:21, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I guess I'll try to revert the later commit that enables it for amdgpu
> (commit a68c7eaa7a8f) and see if it at least makes the horrendous
> messages go away.
I have to revert both
a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
to make things build cleanly. Next step: see if it boots and fixes the
problem for me.
Linus
^ permalink raw reply [relevance 99%]
* Re: [git pull] drm for 6.10-rc1
2024-05-15 20:24 99% ` Linus Torvalds
@ 2024-05-15 20:29 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-15 20:29 UTC (permalink / raw)
To: Dave Airlie, Arunpravin Paneer Selvam, Christian König,
Matthew Auld
Cc: Daniel Vetter, dri-devel, LKML
On Wed, 15 May 2024 at 13:24, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I have to revert both
>
> a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality")
> e362b7c8f8c7 ("drm/amdgpu: Modify the contiguous flags behaviour")
>
> to make things build cleanly. Next step: see if it boots and fixes the
> problem for me.
Well, perhaps not surprisingly, the WARN_ON() no longer triggers with
this, and everything looks fine.
Let's see if the machine ends up being stable now. It took several
hours for the "scary messages" state to turn into the "hung machine"
state, so they *could* have been independent issues, but it seems a
bit unlikely.
Linus
^ permalink raw reply [relevance 99%]
* Re: [git pull] drm for 6.10-rc1
@ 2024-05-15 20:43 99% ` Linus Torvalds
1 sibling, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-15 20:43 UTC (permalink / raw)
To: Dave Airlie, Jani Nikula; +Cc: Daniel Vetter, dri-devel, LKML
On Tue, 14 May 2024 at 23:21, Dave Airlie <airlied@gmail.com> wrote:
>
> This is the main pull request for the drm subsystems for 6.10.
.. and now that I look more at this pull request, I find other things wrong.
Why is the DRM code asking if I want to enable -Werror? I have Werror
enabled *already*.
I hate stupid config questions. They only confuse users.
If the global WERROR config is enabled, then the DRM config certainly
shouldn't ask whether you want even more -Werror. It does nothing but
annoy people.
And no, we are not going to have subsystems that can *weaken* the
existing CONFIG_WERROR. Happily, that doesn't seem to be what the DRM
code wants to do, it just wants to add -Werror, but as mentioned, its'
crazy to do that when we already have it globally enabled.
Now, it might make more sense to ask if you want -Wextra. A lot of
those warnings are bogus.
Linus
^ permalink raw reply [relevance 99%]
* Re: [git pull] drm for 6.10-rc1
@ 2024-05-15 23:58 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-15 23:58 UTC (permalink / raw)
To: Dave Airlie; +Cc: Jani Nikula, Jani Nikula, Daniel Vetter, dri-devel, LKML
On Wed, 15 May 2024 at 16:17, Dave Airlie <airlied@gmail.com> wrote:
>
> It's also possible it's just that hey there's a few others in the tree
>
> KVM_WERROR not tied to it
> PPC_WERROR (why does CXL uses this?)
Yeah, that should be fixed too, but at least KVM_WERROR predates the
whole-kernel WERROR.
And PPC_WERROR predates it by over a decade.
But yes, good catch - both of those should be silenced if we already
have the global WERROR enabled.
I mainly notice new questions (because I use "make oldconfig"), so old
pre-existing illogical ones don't trigger my "why are they asking?"
reaction.
> AMDGPU, I915 and XE all have !COMPILE_TEST on their variants
Hmm. It turns out that I didn't notice the AMDGPU one because my
Threadripper - that has AMDGPU enabled - I have actually turned off
EXPERT on, so it's hidden by that for me.
But yes, both of those should be "depends on !WERROR" too.
Or maybe they should just go away entirely, and be subsumed by the
DRM_WERROR thing.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] workqueue: Changes for v6.10
@ 2024-05-16 0:36 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-16 0:36 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel, Lai Jiangshan
On Wed, 15 May 2024 at 15:26, Tejun Heo <tj@kernel.org> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git/ tags/wq-for-6.10
Hmm.
You seem to have tagged your test-merge, not the actual commit you
*meant* to tag.
I guess it doesn't really matter, but it's ugly and brings in a random
merge commit with no commit message.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] workqueue: Changes for v6.10
@ 2024-05-16 0:58 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-16 0:58 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-kernel, Lai Jiangshan
On Wed, 15 May 2024 at 17:55, Tejun Heo <tj@kernel.org> wrote:
>
> I'll send the corrected pull request right away.
It's fine, I already merged it.
Mistakes happen, this wasn't a huge pattern of problems with you, and
while I could have just merged the non-merge commit I decided that I'd
rather take the ugly empty merge and get your signature than to pick
the "right" commit and avoid the merge.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] Btrfs updates for 6.10
@ 2024-05-16 15:47 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-16 15:47 UTC (permalink / raw)
To: Qu Wenruo; +Cc: David Sterba, linux-btrfs, linux-kernel
On Thu, 16 May 2024 at 02:02, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
> Considering aarch64 is going more and more common, is the workstation
> also an aarch64 platform? (the Ampere one?)
No, this happened on my regular old AMD Threadripper.
Linus
^ permalink raw reply [relevance 99%]
* Re: [git pull] drm urgent for 6.10-rc1
@ 2024-05-17 19:27 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-17 19:27 UTC (permalink / raw)
To: Alex Deucher
Cc: Dave Airlie, Daniel Vetter, Deucher, Alexander,
Arunpravin Paneer Selvam, dri-devel, LKML
On Fri, 17 May 2024 at 06:55, Alex Deucher <alexdeucher@gmail.com> wrote:
>
> Can you try this patch?
> https://patchwork.freedesktop.org/patch/594539/
Ack. This seems to fix it for me - unless the problem is random and
only happens sometimes, and I've just been *very* unlucky until now.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] probes updates for v6.10
@ 2024-05-18 15:55 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-18 15:55 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Andrii Nakryiko, Jiri Olsa, Jonathan Haslam, Kui-Feng Lee,
Stephen Brennan, Ye Bin, Steven Rostedt, linux-kernel
On Sat, 18 May 2024 at 07:38, Masami Hiramatsu <mhiramat@kernel.org> wrote:
>
> Ah, and I missed to build it with W=1.
Note that I do *not* at all expect people to build with W=1. It gets
very noisy depending on your compiler version etc, and a lot of the
W=1 errors are not at all worth worrying about.
But what I do expect is for merge window pull requests to have been
in linux-next, which will give it at least reasonable build coverage
from the bots,
I'm not sure whether it was because I built witch clang (which gives
some warnings that gcc does not, and vice versa) or whether it was
just that my clang build has a different Kconfig. Regardless, if this
had been in linux-next, I'm pretty sure that it would have been found
before I hit it.
Linus
^ permalink raw reply [relevance 99%]
* Re: [PATCH] fs: switch timespec64 fields in inode to discrete integers
@ 2024-05-18 16:03 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-18 16:03 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jeff Layton, Christian Brauner, Alexander Viro, Jan Kara,
linux-fsdevel, Amir Goldstein, linux-kernel
On Fri, 17 May 2024 at 22:23, Matthew Wilcox <willy@infradead.org> wrote:
>
> Smaller is always better, but for a meaningful improvement, we'd want
> to see more.
I think one of the more interesting metrics for inodes is actually not
necessarily size per se, but cache footprint.
A *lot* of the inode is never actually touched in normal operation.
Inodes have all these fields that are only used for certain types, or
perhaps only for IO.
So inodes are big, but more important than shrinking them is likely to
try to make them dense in the cache for normal operations (ie
open/close/stat in particular). They cache very well, and actual
memory use - while still somewhat relevant - is less relevant than
cache misses.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] ext4 updates for v6.10-rc1
@ 2024-05-18 21:19 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-18 21:19 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Ext4 Developers List, Linux Kernel Developers List
On Fri, 17 May 2024 at 21:46, Theodore Ts'o <tytso@mit.edu> wrote:
>
> Note that there is a relatively merge conflict; the relatively simple
> resolution which I used when running regression tests is at the tag
> ext4_merge_resolution in the ext4 git repo,
Heh. That tag just points to the same commit you asked me to pull. I
think you may have tagged it before you actually committed your merge
resolution.
That said, the merge resolution looks trivial, so no big deal. When
people send me a suggested merge, I usually compare against it just
because it's cheap insurance, not because it's usually necessary.
But you may want to check that I actually did the same thing you did.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] MM updates for 6.10-rc1
@ 2024-05-19 16:48 99% ` Linus Torvalds
1 sibling, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-19 16:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, mm-commits, linux-kernel
On Sun, 19 May 2024 at 08:32, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> I'm going to take this pull and fix up the cases I find, but I'm not
> happy with this kind of trivial C preprocessor misuse.
I did some other maco handling cleanup too and tried to regularize
some of this all, and it seems to work for me. But somebody should
double-check, and it's possible these patterns should all be
regularized further with a few helper macros for the whole "add
__GFP_ZERO to argument list" or similar.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] MM updates for 6.10-rc1
@ 2024-05-19 18:59 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-19 18:59 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, mm-commits, linux-kernel
On Sun, 19 May 2024 at 11:56, Linus Torvalds
<torvalds@linuxfoundation.org> wrote:
>
> Instead you seem to merge _and_ then rebase. So you do the worst of both worlds.
Hmm. Your non-MM pull request doesn't show this pattern, so the
problem seems to be purely about something you have done differently
in the MM branch.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] dmi update for v6.10
@ 2024-05-20 16:27 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-20 16:27 UTC (permalink / raw)
To: Jean Delvare; +Cc: LKML
On Mon, 20 May 2024 at 01:12, Jean Delvare <jdelvare@suse.de> wrote:
>
> * Bug fixes:
> - KCFI violation in dmi-id
> - Panic on broken (short) DMI table entry
Well, I wasn't going to pull that based on the description, but it
turns out it's not a panic at all, it's just a "stop decoding".
Because panicking on broken firmware would be horrible.
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] VFIO updates for v6.10-rc1
@ 2024-05-20 22:05 99% ` Linus Torvalds
0 siblings, 1 reply; 200+ results
From: Linus Torvalds @ 2024-05-20 22:05 UTC (permalink / raw)
To: Alex Williamson; +Cc: kvm, linux-kernel
On Mon, 20 May 2024 at 11:12, Alex Williamson
<alex.williamson@redhat.com> wrote:
>
> I've provided the simplified diffstat from a temporary merge branch to
> avoid the noise of merging QAT dependencies from a branch provided by
> Herbert.
The diffstat looks good, but the merge itself sucks.
This is the totality of the "explanation" in the merge commit: "".
Yup. That's it. Nothing. Nada.
If you cannot explain *why* you merged a branch from some other tree,
youi damn well shouldn't have done the merge in the first place.
Merge commits need explanations just like regular commits do. In fact,
because there isn't some obvious diff attached to them, explanations
are arguably even more needed.
I've pulled this, but dammit, why does this keep happening?
Linus
^ permalink raw reply [relevance 99%]
* Re: [GIT PULL] VFIO updates for v6.10-rc1
@ 2024-05-20 23:09 99% ` Linus Torvalds
0 siblings, 0 replies; 200+ results
From: Linus Torvalds @ 2024-05-20 23:09 UTC (permalink / raw)
To: Alex Williamson; +Cc: kvm, linux-kernel
On Mon, 20 May 2024 at 16:03, Alex Williamson
<alex.williamson@redhat.com> wrote:
>
> Sorry. In my case I've looked through logs and I've seen bare merges in
> the past and I guess I assumed the reasoning here would be more obvious.
Yeah, the bare merges in the past is why I'm so frustrated about this
all. I don't understand why this keeps happening so much.
Who do people keep doing this thing where they just think "I don't
need to explain this thing".
Yes, git made merges easy. It was one of the design goals, since (a) I
do a lot of them and (b) it's what EVERY OTHER SCM historically
absolutely sucked at.
But just because merging used to be hard, and git made it so easy,
doesn't mean that people should then not even explain them.
I complained to Andrew this merge window about one of his pull
requests that had _seven_ pointless and totally unexplained merges.
It's like people do this operation in their sleep or something, and
don't think about how big an operation a merge is.
Linus
^ permalink raw reply [relevance 99%]
Results 1-200 of ~20000 next [<= 99%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
[not found] <6a150ddd-3267-4f89-81bd-6807700c57c1@redhat.com>
[not found] ` <652928aa-0fb8-425e-87b0-d65176dd2cfa@redhat.com>
[not found] ` <9b92706b-14c2-4761-95fb-7dbbaede57f4@leemhuis.info>
[not found] ` <e733c14e-0bdd-41b2-82aa-90c0449aff25@redhat.com>
2024-02-21 16:32 ` [REGRESSION] 6.8-rc process is unable to exit and consumes a lot of cpu Linux regression tracking (Thorsten Leemhuis)
2024-02-24 7:00 ` Thorsten Leemhuis
2024-02-24 23:43 99% ` Linus Torvalds
[not found] <CAHk-=whHsCLoBsCdv2TiaQB+2TUR+wm2EPkaPHxF=g9Ofki7AQ@mail.gmail.com>
2024-05-15 9:17 ` [PATCH] vfs: Delete the associated dentry when deleting a file Yafang Shao
2024-05-15 16:05 99% ` Linus Torvalds
2024-01-13 21:31 99% Heads up - effectively offline for now Linus Torvalds
2024-02-01 13:39 [GIT PULL] Kbuild fixes for v6.8-rc3 Masahiro Yamada
2024-02-01 20:06 ` Linus Torvalds
2024-02-01 23:57 ` Masahiro Yamada
2024-02-02 0:43 99% ` Linus Torvalds
2024-02-02 2:15 ` Masahiro Yamada
2024-02-03 23:59 ` Masahiro Yamada
2024-02-04 6:27 99% ` Linus Torvalds
2024-04-11 0:10 [PATCH] vfs: relax linkat() AT_EMPTY_PATH - aka flink() - requirements Linus Torvalds
2024-04-11 0:20 99% ` Linus Torvalds
2024-04-11 2:39 ` Linus Torvalds
2024-04-11 9:04 ` Christian Brauner
2024-04-11 16:15 ` Linus Torvalds
2024-04-11 16:44 ` Charles Mirabile
2024-04-11 17:29 ` Charles Mirabile
2024-04-11 17:35 ` Charles Mirabile
2024-04-11 18:13 ` Linus Torvalds
2024-04-11 20:08 ` Charles Mirabile
2024-04-11 20:22 99% ` Linus Torvalds
2024-04-11 19:34 ` Linus Torvalds
2024-04-12 7:45 ` Christian Brauner
2024-04-12 15:36 99% ` Linus Torvalds
2024-04-11 12:25 ` Christian Brauner
2024-04-11 16:21 99% ` Linus Torvalds
2024-05-20 18:12 [GIT PULL] VFIO updates for v6.10-rc1 Alex Williamson
2024-05-20 22:05 99% ` Linus Torvalds
2024-05-20 23:03 ` Alex Williamson
2024-05-20 23:09 99% ` Linus Torvalds
2024-01-31 17:50 [PATCH v8 0/4] Introduce mseal jeffxu
2024-01-31 19:34 ` Liam R. Howlett
2024-02-01 1:27 ` Jeff Xu
2024-02-01 20:45 ` Liam R. Howlett
2024-02-01 22:24 ` Theo de Raadt
2024-02-02 1:06 ` Greg KH
2024-02-02 3:24 ` Jeff Xu
2024-02-02 3:29 99% ` Linus Torvalds
2024-02-02 3:14 ` Jeff Xu
2024-02-02 15:13 ` Liam R. Howlett
2024-02-02 17:24 ` Jeff Xu
2024-02-02 19:21 ` Liam R. Howlett
2024-02-02 19:32 ` Theo de Raadt
2024-02-02 20:36 ` Linus Torvalds
2024-02-02 21:18 ` Liam R. Howlett
2024-02-02 23:36 99% ` Linus Torvalds
2024-04-02 14:11 [GIT PULL] security changes for v6.9-rc3 Roberto Sassu
2024-04-02 19:39 ` Linus Torvalds
2024-04-02 19:57 ` Linus Torvalds
2024-04-02 21:00 ` Al Viro
2024-04-02 21:35 99% ` Linus Torvalds
2024-01-28 13:28 [GIT PULL] MIPS fixes for v6.8 Thomas Bogendoerfer
2024-01-28 18:46 99% ` Linus Torvalds
2024-05-15 6:20 [git pull] drm for 6.10-rc1 Dave Airlie
2024-05-15 20:43 99% ` Linus Torvalds
2024-05-15 22:45 ` Dave Airlie
2024-05-15 22:56 ` Linus Torvalds
2024-05-15 23:17 ` Dave Airlie
2024-05-15 23:58 99% ` Linus Torvalds
2024-05-15 20:06 ` Linus Torvalds
2024-05-15 20:21 ` Linus Torvalds
2024-05-15 20:24 99% ` Linus Torvalds
2024-05-15 20:29 99% ` Linus Torvalds
2024-03-12 4:25 [GIT PULL] Networking for v6.9 Jakub Kicinski
2024-03-12 20:17 99% ` Linus Torvalds
2024-03-13 1:00 99% ` Linus Torvalds
2024-03-11 15:19 [GIT PULL] x86/sev for v6.9-rc1 Borislav Petkov
2024-03-12 0:50 99% ` Linus Torvalds
2024-03-20 10:18 [PATCH v2 1/3] mm: kmsan: implement kmsan_memmove() Alexander Potapenko
2024-03-20 16:04 99% ` Linus Torvalds
2024-03-01 8:32 [Linux Kernel Bug] KASAN: slab-out-of-bounds Write in tomoyo_write_control Sam Sun
2024-03-01 13:04 ` [PATCH for 6.8] tomoyo: fix UAF write bug in tomoyo_write_control() Tetsuo Handa
2024-03-01 19:14 99% ` Linus Torvalds
2024-04-20 11:12 [PATCH v2] tty: n_gsm: restrict tty devices to attach Tetsuo Handa
2024-04-20 17:34 ` Linus Torvalds
2024-04-20 18:02 ` Linus Torvalds
2024-04-20 18:05 99% ` Linus Torvalds
2024-04-21 13:28 ` Tetsuo Handa
2024-04-21 16:04 ` Linus Torvalds
2024-04-21 17:18 ` Linus Torvalds
2024-04-23 15:26 ` Tetsuo Handa
2024-04-23 16:37 99% ` Linus Torvalds
2024-05-03 18:26 get_file() unsafe under epoll (was Re: [syzbot] [fs?] [io-uring?] general protection fault in __ep_remove) Kees Cook
2024-05-03 21:11 ` [PATCH] epoll: try to be a _bit_ better about file lifetimes Linus Torvalds
2024-05-03 21:24 ` Al Viro
2024-05-03 21:33 ` Linus Torvalds
2024-05-04 9:37 ` Christian Brauner
2024-05-04 15:32 ` Linus Torvalds
2024-05-04 18:20 ` Linus Torvalds
2024-05-06 14:29 ` [Linaro-mm-sig] " Christian König
2024-05-07 11:02 ` Daniel Vetter
2024-05-07 16:46 ` Linus Torvalds
2024-05-07 18:04 ` Daniel Vetter
2024-05-07 19:07 99% ` Linus Torvalds
2024-05-08 16:19 ` Linus Torvalds
2024-05-08 17:14 ` Linus Torvalds
2024-05-09 11:38 ` Christian Brauner
2024-05-09 15:48 99% ` Linus Torvalds
2024-05-03 21:45 ` Al Viro
2024-05-03 21:52 99% ` Linus Torvalds
2024-01-30 19:03 [PATCH 1/6] tracefs: avoid using the ei->dentry pointer unnecessarily Linus Torvalds
2024-01-30 19:03 ` [PATCH 3/6] tracefs: dentry lookup crapectomy Linus Torvalds
2024-01-31 0:23 ` Al Viro
2024-01-31 0:39 99% ` Linus Torvalds
2024-01-30 19:03 ` [PATCH 5/6] eventfs: get rid of dentry pointers without refcounts Linus Torvalds
2024-01-31 5:09 ` Steven Rostedt
2024-01-31 5:25 ` Linus Torvalds
2024-01-31 5:33 ` Steven Rostedt
2024-01-31 5:57 99% ` Linus Torvalds
2024-01-30 20:55 ` Steven Rostedt
2024-01-30 21:52 ` Linus Torvalds
2024-01-30 22:56 ` Steven Rostedt
2024-01-30 22:58 99% ` Linus Torvalds
2024-01-30 22:56 ` Linus Torvalds
2024-01-30 23:06 99% ` Linus Torvalds
2024-01-30 23:10 ` Steven Rostedt
2024-01-30 23:25 99% ` Linus Torvalds
2024-01-30 19:03 ` [PATCH 6/6] eventfs: clean up dentry ops and add revalidate function Linus Torvalds
2024-01-31 1:12 ` Al Viro
2024-01-31 2:37 99% ` Linus Torvalds
2024-01-30 21:25 ` Steven Rostedt
2024-01-30 21:36 99% ` Linus Torvalds
2023-09-25 12:02 [PATCH v7 00/12] iov_iter: Convert the iterator macros into inline funcs David Howells
2023-09-25 12:03 ` [PATCH v7 07/12] iov_iter: Convert iterate*() to " David Howells
2024-02-18 3:13 ` [bug report] dead loop in generic_perform_write() //Re: " Tong Tiangen
2024-02-28 21:21 99% ` Linus Torvalds
2024-02-28 22:57 ` Linus Torvalds
2024-02-29 8:13 ` Tong Tiangen
2024-02-29 17:32 ` Linus Torvalds
2024-03-02 2:59 ` Linus Torvalds
2024-03-02 9:37 ` Tong Tiangen
2024-03-02 18:06 ` Linus Torvalds
2024-03-02 18:11 99% ` Linus Torvalds
2024-03-19 16:36 [PATCH v1 1/3] mm: kmsan: implement kmsan_memmove() Alexander Potapenko
2024-03-19 16:36 ` [PATCH v1 2/3] instrumented.h: add instrument_memcpy_before, instrument_memcpy_after Alexander Potapenko
2024-03-19 17:52 99% ` Linus Torvalds
2024-03-19 16:36 ` [PATCH v1 3/3] x86: call instrumentation hooks from copy_mc.c Alexander Potapenko
2024-03-19 17:58 99% ` Linus Torvalds
2024-01-24 16:19 [6.8-rc1 Regression] Unable to exec apparmor_parser from virt-aa-helper Kevin Locke
2024-01-24 16:35 ` Kees Cook
2024-01-24 16:46 99% ` Linus Torvalds
2024-01-24 16:54 99% ` Linus Torvalds
2024-01-24 17:10 ` Linus Torvalds
2024-01-24 17:21 ` Kees Cook
2024-01-24 17:27 99% ` Linus Torvalds
2024-01-24 18:27 ` Linus Torvalds
2024-01-24 18:29 99% ` Linus Torvalds
2024-01-25 14:16 ` Tetsuo Handa
2024-01-25 17:17 99% ` Linus Torvalds
2024-01-24 19:02 ` Kees Cook
2024-01-24 19:41 99% ` Linus Torvalds
2024-03-13 1:10 [GIT PULL] bcachefs updates for 6.9 Kent Overstreet
2024-03-13 20:47 ` Linus Torvalds
2024-03-13 21:34 ` Kent Overstreet
2024-03-13 21:51 99% ` Linus Torvalds
2024-03-13 22:22 ` Kent Overstreet
2024-03-13 22:28 ` Kent Overstreet
2024-03-14 17:15 99% ` Linus Torvalds
2024-04-25 17:45 [GIT PULL] ACPI fixes for v6.9-rc6 Rafael J. Wysocki
2024-04-25 18:58 ` Linus Torvalds
2024-04-25 19:01 99% ` Linus Torvalds
2024-01-17 21:30 [PULL REQUEST] i2c-for-6.8-rc1-fixed Wolfram Sang
2024-01-18 0:02 99% ` Linus Torvalds
2024-01-10 20:48 [GIT PULL] first round of SCSI updates for the 6.7+ merge window James Bottomley
2024-01-11 22:36 ` Linus Torvalds
2024-01-11 22:47 ` Linus Torvalds
2024-01-11 23:28 ` James Bottomley
2024-01-11 23:50 ` Linus Torvalds
2024-01-12 14:27 ` Konstantin Ryabitsev
2024-01-12 18:34 99% ` Linus Torvalds
2024-05-10 18:30 [GIT PULL] RCU changes for v6.10 Uladzislau Rezki (Sony)
2024-05-13 16:38 ` Linus Torvalds
2024-05-13 16:46 ` Paul E. McKenney
2024-05-13 16:48 99% ` Linus Torvalds
2024-05-13 16:56 ` Paul E. McKenney
2024-05-13 16:58 99% ` Linus Torvalds
2024-03-18 15:30 [GIT PULL v2] tracing: Updates for v6.9 Steven Rostedt
2024-03-19 16:23 ` Linus Torvalds
2024-03-19 17:06 ` Steven Rostedt
2024-03-19 17:13 ` Steven Rostedt
2024-03-19 21:03 ` Nathan Chancellor
2024-03-19 21:22 99% ` Linus Torvalds
2024-05-08 6:00 [GIT PULL] ARM SoC fixes for 6.9, part 3 Arnd Bergmann
2024-05-08 17:22 99% ` Linus Torvalds
2024-01-21 21:35 [GIT PULL] More bcachefs updates for 6.8-rc1 Kent Overstreet
2024-01-21 22:05 99% ` Linus Torvalds
2024-01-19 21:14 [GIT PULL] strlcpy removal for v6.8-rc1 Kees Cook
2024-01-19 22:00 99% ` Linus Torvalds
2024-01-19 22:53 ` Kees Cook
2024-01-19 23:59 99% ` Linus Torvalds
2024-03-21 12:55 [GIT PULL] remoteproc updates for v6.9 Bjorn Andersson
2024-03-21 18:08 ` Bjorn Andersson
2024-03-21 18:05 99% ` Linus Torvalds
2024-01-16 22:55 [PATCH v3 0/2] eventfs: Create dentries and inodes at dir open Steven Rostedt
2024-01-16 22:55 ` [PATCH v3 1/2] eventfs: Have the inodes all for files and directories all be the same Steven Rostedt
2024-01-22 21:59 ` Darrick J. Wong
2024-01-22 22:02 99% ` Linus Torvalds
2024-05-10 21:17 [GIT PULL] asm-generic cleanups for 6.10 Arnd Bergmann
2024-05-13 16:11 99% ` Linus Torvalds
2024-05-10 21:19 ` [GIT PULL] alpha: cleanups and build fixes " Arnd Bergmann
2024-05-13 16:27 99% ` Linus Torvalds
2024-03-05 23:51 linux-next: build warning after merge of the vfs-brauner tree Stephen Rothwell
2024-03-06 2:48 99% ` Linus Torvalds
2024-03-06 4:37 ` Stephen Rothwell
2024-03-06 4:47 99% ` Linus Torvalds
2024-03-14 19:43 [GIT PULL] clk changes for the merge window Stephen Boyd
2024-03-15 18:54 99% ` Linus Torvalds
2024-03-18 21:25 [GIT PULL v2] dlm fixes for 6.9 David Teigland
2024-03-18 22:44 99% ` Linus Torvalds
2024-05-14 23:11 [GIT PULL] Networking for v6.10 Jakub Kicinski
2024-05-15 3:32 ` Linus Torvalds
2024-05-15 4:06 99% ` Linus Torvalds
2024-04-12 14:32 [GIT PULL] tracing: Fixes for v6.9 Steven Rostedt
2024-04-12 16:07 99% ` Linus Torvalds
2024-04-12 16:15 ` Steven Rostedt
2024-04-12 16:20 99% ` Linus Torvalds
2024-04-12 16:20 ` Randy Dunlap
2024-04-12 16:21 99% ` Linus Torvalds
2024-05-20 8:12 [GIT PULL] dmi update for v6.10 Jean Delvare
2024-05-20 16:27 99% ` Linus Torvalds
2024-01-13 18:33 [PATCH] media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c) Aurelien Jarno
2024-01-14 11:04 ` Hans Verkuil
2024-01-21 19:57 99% ` Linus Torvalds
2024-01-28 19:24 [PATCH next 00/11] minmax: Optimise to reduce .i line length David Laight
2024-01-28 19:35 ` [PATCH next 10/11] block: Use a boolean expression instead of max() on booleans David Laight
2024-01-28 19:59 99% ` Linus Torvalds
2024-01-22 18:33 [GIT PULL] Btrfs fixes for 6.8-rc2 David Sterba
2024-01-22 22:34 99% ` Linus Torvalds
2024-01-22 22:54 99% ` Linus Torvalds
2024-01-22 23:01 99% ` Linus Torvalds
2024-01-26 19:25 ` Linus Torvalds
2024-01-26 20:00 ` David Sterba
2024-01-26 21:39 ` Qu Wenruo
2024-01-26 21:51 99% ` Linus Torvalds
2024-01-26 21:56 ` Qu Wenruo
2024-01-26 22:02 99% ` Linus Torvalds
2024-03-20 15:22 [GIT PULL] tracing/tools: Updates for v6.9 Steven Rostedt
2024-03-20 23:40 99% ` Linus Torvalds
2024-02-18 21:13 Linux 6.8-rc5 Linus Torvalds
2024-02-20 19:08 ` Guenter Roeck
2024-02-20 19:57 ` Linus Torvalds
2024-02-20 21:48 ` Guenter Roeck
2024-02-20 22:02 99% ` Linus Torvalds
2024-02-01 20:22 [GIT PULL] perf tools fixes for v6.8 Arnaldo Carvalho de Melo
2024-02-01 20:57 99% ` Linus Torvalds
2024-01-15 20:43 [GIT PULL] power-supply changes for 6.8 Sebastian Reichel
2024-01-17 18:00 ` Nathan Chancellor
2024-01-18 0:11 99% ` Linus Torvalds
2024-04-08 17:47 [PATCH RFC cmpxchg 0/8] Provide emulation for one- and two-byte cmpxchg() Paul E. McKenney
2024-04-08 17:49 ` [PATCH cmpxchg 08/14] parisc: add u16 support to cmpxchg() Paul E. McKenney
2024-04-08 20:10 99% ` Linus Torvalds
2024-03-04 10:12 [patch 0/9] x86: Cure tons of sparse warnings (mostly __percpu) Thomas Gleixner
2024-03-04 10:12 ` [patch 5/9] x86: Cure per CPU madness on UP Thomas Gleixner
2024-03-15 16:17 ` Guenter Roeck
2024-03-15 16:42 ` Linus Torvalds
2024-03-15 17:40 ` Thomas Gleixner
2024-03-15 22:55 ` Thomas Gleixner
2024-03-15 23:23 ` Linus Torvalds
2024-03-16 1:11 ` Thomas Gleixner
2024-03-16 1:23 99% ` Linus Torvalds
2024-03-18 12:19 [GIT PULL] vfs fixes Christian Brauner
2024-03-18 19:14 ` Linus Torvalds
2024-03-18 19:41 99% ` Linus Torvalds
2024-03-02 16:12 [GIT PULL] tracing: Prevent trace_marker being bigger than unsigned short Steven Rostedt
2024-03-02 17:24 ` Linus Torvalds
2024-03-02 19:59 ` Steven Rostedt
2024-03-02 20:25 99% ` Linus Torvalds
2024-03-02 20:33 99% ` Linus Torvalds
2024-03-02 20:47 ` Steven Rostedt
2024-03-02 20:55 99% ` Linus Torvalds
2024-03-03 12:59 ` Steven Rostedt
2024-03-03 17:38 99% ` Linus Torvalds
2024-03-03 19:07 ` Steven Rostedt
2024-03-03 20:09 ` Linus Torvalds
2024-03-03 21:00 ` Steven Rostedt
2024-03-04 21:42 ` Steven Rostedt
2024-03-04 21:50 ` Linus Torvalds
2024-03-04 22:10 ` Steven Rostedt
2024-03-04 23:20 ` Linus Torvalds
2024-03-04 23:47 ` Steven Rostedt
2024-03-04 23:52 ` Steven Rostedt
2024-03-05 0:17 99% ` Linus Torvalds
2024-05-13 6:51 [GIT PULL] x86/boot changes for v6.10 Ingo Molnar
2024-05-14 1:02 99% ` Linus Torvalds
2024-01-26 18:18 [PATCH] eventfs: Give files a default of PAGE_SIZE size Steven Rostedt
2024-01-26 18:31 99% ` Linus Torvalds
2024-01-26 18:41 ` Steven Rostedt
2024-01-26 19:06 99% ` Linus Torvalds
2024-05-16 2:53 [git pull] drm urgent for 6.10-rc1 Dave Airlie
2024-05-16 17:25 ` Linus Torvalds
2024-05-17 13:55 ` Alex Deucher
2024-05-17 19:27 99% ` Linus Torvalds
2024-02-25 13:21 Linux regressions report for mainline [2024-02-25] Regzbot (on behalf of Thorsten Leemhuis)
2024-02-25 14:21 ` Linux regression tracking (Thorsten Leemhuis)
2024-02-26 17:33 99% ` Linus Torvalds
2024-03-26 14:38 [GIT PULL] tpmdd changes for v6.9-rc2 Jarkko Sakkinen
2024-03-30 22:32 99% ` Linus Torvalds
2024-03-31 5:57 ` Jarkko Sakkinen
2024-03-31 17:01 99% ` Linus Torvalds
2024-02-04 8:51 [PATCH] lib/bch.c: increase bitrev single conversion length John Sanpe
2024-02-04 9:09 99% ` Linus Torvalds
2024-04-03 9:07 [RESEND][PATCH v3] security: Place security_path_post_mknod() where the original IMA call was Roberto Sassu
2024-04-03 16:59 99% ` Linus Torvalds
2024-01-31 14:12 [GIT PULL] SCSI fixes for 6.8-rc2 James Bottomley
2024-01-31 18:15 99% ` Linus Torvalds
2024-01-18 7:30 [GIT PULL] dma-mapping fixes for Linux 6.8 Christoph Hellwig
2024-01-19 0:52 99% ` Linus Torvalds
2024-01-30 9:11 [PATCHSET wq/for-6.9] workqueue: Implement BH workqueue and convert several tasklet users Tejun Heo
2024-01-30 9:11 ` [PATCH 3/8] workqueue: Implement BH workqueues to eventually replace tasklets Tejun Heo
2024-01-30 17:25 99% ` Linus Torvalds
2024-05-10 20:17 [GIT PULL] hotfixes for 6.10 Andrew Morton
2024-05-10 21:00 99% ` Linus Torvalds
2023-09-18 8:14 [PATCH next v4 0/5] minmax: Relax type checks in min() and max() David Laight
2024-01-08 11:46 ` Jiri Slaby
2024-01-08 18:19 ` Linus Torvalds
2024-01-08 20:04 ` Linus Torvalds
2024-01-08 21:11 ` Linus Torvalds
2024-01-10 6:17 ` Stephen Rothwell
2024-01-10 19:35 ` Linus Torvalds
2024-01-10 22:58 ` David Laight
2024-01-20 21:33 99% ` Linus Torvalds
2024-03-25 14:09 [PATCH 1/2] locking/pvqspinlock: Use try_cmpxchg_acquire() in trylock_clear_pending() Uros Bizjak
2024-04-11 13:33 ` [tip: locking/core] " tip-bot2 for Uros Bizjak
2024-04-11 16:31 99% ` Linus Torvalds
2024-01-17 14:35 [for-linus][PATCH 0/3] eventfs: A few more fixes for 6.8 Steven Rostedt
2024-01-17 14:35 ` [for-linus][PATCH 1/3] eventfs: Have the inodes all for files and directories all be the same Steven Rostedt
2024-01-22 10:38 ` Geert Uytterhoeven
2024-01-22 15:06 ` Steven Rostedt
2024-01-22 16:23 ` Geert Uytterhoeven
2024-01-22 16:47 ` Steven Rostedt
2024-01-22 17:37 ` Linus Torvalds
2024-01-22 17:39 99% ` Linus Torvalds
2024-01-22 18:19 ` Linus Torvalds
2024-01-22 19:44 ` Steven Rostedt
2024-01-25 17:40 ` Christian Brauner
2024-01-25 18:07 ` Steven Rostedt
2024-01-25 18:08 ` Steven Rostedt
2024-01-26 8:07 ` Geert Uytterhoeven
2024-01-26 10:11 ` Christian Brauner
2024-01-26 16:25 ` Steven Rostedt
2024-01-26 19:09 99% ` Linus Torvalds
2024-01-29 2:58 [linus:master] [eventfs] 852e46e239: BUG:unable_to_handle_page_fault_for_address kernel test robot
2024-01-29 4:36 ` Linus Torvalds
2024-01-29 17:01 ` Steven Rostedt
2024-01-29 17:40 ` Linus Torvalds
2024-01-29 17:44 ` Steven Rostedt
2024-01-29 17:56 99% ` Linus Torvalds
2024-01-29 19:24 ` Linus Torvalds
2024-01-29 19:51 ` Linus Torvalds
2024-01-29 20:26 ` Steven Rostedt
2024-01-29 20:51 ` Linus Torvalds
2024-01-29 22:22 ` Steven Rostedt
2024-01-29 22:35 ` Linus Torvalds
2024-01-29 22:42 ` Linus Torvalds
2024-01-29 22:49 ` Steven Rostedt
2024-01-30 0:01 99% ` Linus Torvalds
2024-01-30 0:35 ` Steven Rostedt
2024-01-30 1:50 ` Linus Torvalds
2024-01-30 3:56 ` Linus Torvalds
2024-01-30 8:43 ` Linus Torvalds
2024-01-30 9:12 ` Linus Torvalds
2024-01-30 14:39 ` Steven Rostedt
2024-01-30 16:51 99% ` Linus Torvalds
2024-01-30 16:49 ` Steven Rostedt
2024-01-30 16:55 99% ` Linus Torvalds
2024-03-21 13:02 [GIT PULL] Char/Misc driver changes for 6.9-rc1 Greg KH
2024-03-27 16:56 ` Linus Torvalds
2024-03-27 20:26 99% ` Linus Torvalds
2024-03-21 13:48 ` Nathan Chancellor
2024-03-21 18:10 99% ` Linus Torvalds
2024-03-21 18:12 99% ` Linus Torvalds
2024-03-21 18:30 ` Nathan Chancellor
2024-03-21 20:28 99% ` Linus Torvalds
2024-04-10 13:24 [GIT PULL] turbostat 2024.04.10 Len Brown
2024-04-10 20:18 99% ` Linus Torvalds
2024-04-11 18:20 ` Len Brown
2024-04-11 19:14 99% ` Linus Torvalds
2024-03-08 17:15 [GIT PULL] RCU changes for v6.9 Boqun Feng
2024-03-12 20:32 ` Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9] Florian Fainelli
2024-03-12 21:07 ` Boqun Feng
2024-03-12 21:34 ` Florian Fainelli
2024-03-12 21:44 99% ` Linus Torvalds
2024-05-18 0:08 [PATCH] fs: switch timespec64 fields in inode to discrete integers Jeff Layton
2024-05-18 5:23 ` Matthew Wilcox
2024-05-18 16:03 99% ` Linus Torvalds
2024-03-31 18:24 [PATCH v2] HID: i2c-hid: Revert to await reset ACK before reading report descriptor Kenny Levinsen
2024-04-22 17:10 ` Linux regression tracking (Thorsten Leemhuis)
2024-04-23 14:59 ` Benjamin Tissoires
2024-04-24 16:56 ` regression fixes sitting in subsystem git trees for a week or longer (was: Re: [PATCH v2] HID: i2c-hid: Revert to await reset ACK before reading report descriptor) Thorsten Leemhuis
2024-04-24 18:53 99% ` Linus Torvalds
2024-02-29 20:39 [GIT PULL] Networking for v6.8-rc7 Jakub Kicinski
2024-02-29 20:56 99% ` Linus Torvalds
2024-04-27 20:00 [syzbot] [bpf?] [trace?] possible deadlock in force_sig_info_to_task syzbot
2024-04-27 23:13 ` Hillf Danton
2024-04-28 20:01 ` Linus Torvalds
2024-04-28 23:23 ` Hillf Danton
2024-04-29 0:50 99% ` Linus Torvalds
2024-04-29 1:33 ` Linus Torvalds
2024-04-29 8:00 ` [PATCH] x86/mm: Remove broken vsyscall emulation code from the page fault code Ingo Molnar
2024-04-29 15:51 99% ` Linus Torvalds
2024-04-29 18:47 ` Linus Torvalds
2024-04-29 19:07 ` Linus Torvalds
2024-04-29 23:29 ` Andy Lutomirski
2024-04-30 0:05 99% ` Linus Torvalds
2024-05-07 23:27 [RFC] Mitigating unexpected arithmetic overflow Kees Cook
2024-05-08 17:52 ` Linus Torvalds
2024-05-08 19:44 ` Kees Cook
2024-05-08 20:07 ` Linus Torvalds
2024-05-08 22:54 ` Kees Cook
2024-05-08 23:47 ` Linus Torvalds
2024-05-09 6:11 ` Kees Cook
2024-05-09 14:08 ` Theodore Ts'o
2024-05-09 15:38 ` Linus Torvalds
2024-05-09 17:54 ` Al Viro
2024-05-09 18:08 99% ` Linus Torvalds
2024-05-09 18:39 99% ` Linus Torvalds
2024-05-09 18:48 ` Al Viro
2024-05-09 19:15 99% ` Linus Torvalds
2024-05-02 12:16 [BUG][v6.9-rc6] Deadlock with: Revert "drm/qxl: simplify qxl_fence_wait" Steven Rostedt
2024-05-04 8:39 ` Steven Rostedt
2024-05-06 12:45 ` Maxime Ripard
2024-05-06 20:28 99% ` Linus Torvalds
2024-02-01 15:46 [PATCH 0/3] Handle delay slot for extable lookup Jiaxun Yang
2024-02-01 17:48 99% ` Linus Torvalds
2024-03-12 9:55 [GIT PULL] slab updates for 6.9 Vlastimil Babka
2024-03-13 3:54 99% ` Linus Torvalds
2024-05-15 8:27 [PATCH 6.1 000/243] 6.1.91-rc2 review Greg Kroah-Hartman
2024-05-15 16:17 ` Mark Brown
2024-05-15 16:20 99% ` Linus Torvalds
2024-03-22 19:12 [GIT PULL] SCSI postmerge updates for the 6.8+ merge window James Bottomley
2024-03-22 19:55 99% ` Linus Torvalds
2024-03-22 20:24 ` James Bottomley
2024-03-22 20:34 99% ` Linus Torvalds
2024-02-03 10:52 [PATCH v2 0/3] fs/exec: remove current->in_execve flag Tetsuo Handa
2024-02-03 10:52 ` [PATCH v2 1/3] LSM: add security_execve_abort() hook Tetsuo Handa
2024-02-07 14:24 ` Kees Cook
2024-02-07 15:21 ` Paul Moore
2024-02-07 15:43 ` Kees Cook
2024-02-07 16:45 ` Paul Moore
2024-02-07 17:57 99% ` Linus Torvalds
2024-03-13 4:06 [git pull] drm for 6.9-rc1 Dave Airlie
2024-03-14 1:49 99% ` Linus Torvalds
2024-05-03 8:11 [PATCH 00/14] alpha: cleanups for 6.10 Arnd Bergmann
2024-05-03 8:11 ` [PATCH 10/14] alpha: remove DECpc AXP150 (Jensen) support Arnd Bergmann
2024-05-03 16:07 99% ` Linus Torvalds
2024-02-14 18:39 [PATCH wq/for-6.9] workqueue: Fix queue_work_on() with BH workqueues Tejun Heo
2024-02-14 19:03 99% ` Linus Torvalds
2024-01-11 18:28 [GIT PULL] f2fs update for 6.8-rc1 Jaegeuk Kim
2024-01-12 5:05 ` Linus Torvalds
2024-01-12 7:12 ` Al Viro
2024-01-12 18:18 99% ` Linus Torvalds
2023-10-28 12:23 [GIT PULL] Scheduler changes for v6.7 Ingo Molnar
2024-01-08 14:07 ` [GIT PULL] Scheduler changes for v6.8 Ingo Molnar
2024-01-10 22:19 ` Linus Torvalds
2024-01-10 22:41 ` Linus Torvalds
2024-01-10 22:57 ` Linus Torvalds
2024-01-11 8:11 ` Vincent Guittot
2024-01-11 17:45 ` Linus Torvalds
2024-01-11 17:53 ` Linus Torvalds
2024-01-11 18:16 ` Vincent Guittot
2024-01-12 14:23 ` Dietmar Eggemann
2024-01-12 18:18 ` Qais Yousef
2024-01-12 19:03 ` Vincent Guittot
2024-01-12 20:30 ` Linus Torvalds
2024-01-12 20:49 99% ` Linus Torvalds
2024-01-12 21:04 ` Linus Torvalds
2024-01-13 1:04 ` Qais Yousef
2024-01-13 1:24 ` Linus Torvalds
2024-01-13 1:31 99% ` Linus Torvalds
2024-03-14 20:31 [GIT PULL] lsm/lsm-pr-20240314 Paul Moore
2024-03-14 23:05 99% ` Linus Torvalds
2024-02-08 22:06 [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11 (and earlier) Sean Christopherson
2024-02-09 17:03 ` Nick Desaulniers
2024-02-09 17:14 ` Andrew Pinski (QUIC)
2024-02-09 17:55 ` Linus Torvalds
2024-02-09 18:43 ` Sean Christopherson
2024-02-09 18:55 ` Nick Desaulniers
2024-02-09 19:01 99% ` Linus Torvalds
2024-02-09 20:39 ` Linus Torvalds
2024-02-11 11:12 ` Uros Bizjak
2024-02-14 18:43 ` Linus Torvalds
2024-02-15 0:11 99% ` Linus Torvalds
2024-02-15 8:39 ` Jakub Jelinek
2024-02-15 18:25 99% ` Linus Torvalds
2024-02-27 22:56 [GIT PULL] hotfixes for 6.8-rc7 Andrew Morton
2024-02-28 0:51 99% ` Linus Torvalds
2023-04-23 23:55 [syzbot] [kernel?] KCSAN: data-race in __fput / __tty_hangup (4) Tetsuo Handa
2023-04-24 0:44 ` Al Viro
2023-04-24 1:09 ` Tetsuo Handa
2023-04-25 14:47 ` Tetsuo Handa
2023-04-25 16:03 ` Al Viro
2023-04-25 22:09 ` Tetsuo Handa
2023-04-26 11:05 ` [PATCH] tty: tty_io: remove hung_up_tty_fops Tetsuo Handa
2023-05-14 1:02 ` [PATCH v2] " Tetsuo Handa
2023-05-30 10:44 ` Greg Kroah-Hartman
2023-05-30 11:57 ` Tetsuo Handa
2023-05-30 12:51 ` Greg Kroah-Hartman
2024-04-27 6:20 ` [PATCH v3] " Tetsuo Handa
2024-04-27 19:02 ` Linus Torvalds
2024-04-28 10:19 ` Tetsuo Handa
2024-04-28 18:50 99% ` Linus Torvalds
2024-04-29 13:55 ` Marco Elver
2024-04-29 15:38 ` Linus Torvalds
2024-05-01 18:45 ` Paul E. McKenney
2024-05-01 18:56 99% ` Linus Torvalds
2024-05-01 19:02 ` Paul E. McKenney
2024-05-01 20:14 ` Marco Elver
2024-05-01 21:06 ` Linus Torvalds
2024-05-01 21:20 ` Linus Torvalds
2024-05-01 21:49 ` Paul E. McKenney
2024-05-01 22:32 ` Paul E. McKenney
2024-05-02 16:37 ` Boqun Feng
2024-05-03 23:59 ` Paul E. McKenney
2024-05-04 0:14 99% ` Linus Torvalds
2024-05-04 5:08 ` Paul E. McKenney
2024-05-04 17:50 99% ` Linus Torvalds
2024-05-02 14:14 ` Marco Elver
2024-05-02 16:42 ` Tetsuo Handa
2024-05-02 17:29 99% ` Linus Torvalds
2024-05-02 23:54 ` Tetsuo Handa
2024-05-03 1:12 99% ` Linus Torvalds
2024-05-03 23:07 [GIT PULL] tracing/tracefs: Fixes for v6.9 Steven Rostedt
2024-05-04 0:01 99% ` Linus Torvalds
2024-03-21 4:09 [GIT PULL] Hyper-V commits for 6.9 Wei Liu
2024-03-21 17:06 99% ` Linus Torvalds
2024-03-22 23:25 ` Wei Liu
2024-03-22 23:42 99% ` Linus Torvalds
2024-03-15 15:10 [GIT PULL] fs/9p patches for 6.9 merge window Eric Van Hensbergen
2024-03-15 17:17 99% ` Linus Torvalds
2024-02-02 12:30 [PATCH v2 0/3] Handle delay slot for extable lookup Jiaxun Yang
2024-02-02 18:39 99% ` Linus Torvalds
2024-02-03 13:56 ` Jiaxun Yang
2024-02-04 7:41 ` Linus Torvalds
2024-02-04 11:03 ` Jiaxun Yang
2024-02-04 11:45 99% ` Linus Torvalds
2024-03-08 10:13 [GIT PULL] vfs pidfd Christian Brauner
2024-03-11 20:05 99% ` Linus Torvalds
2024-03-12 14:15 ` Christian Brauner
2024-03-12 16:23 99% ` Linus Torvalds
2024-03-12 20:09 ` Christian Brauner
2024-03-12 20:21 99% ` Linus Torvalds
2024-03-13 17:10 ` Christian Brauner
2024-03-13 19:40 99% ` Linus Torvalds
2024-05-18 4:46 [GIT PULL] ext4 updates for v6.10-rc1 Theodore Ts'o
2024-05-18 21:19 99% ` Linus Torvalds
2022-05-27 11:29 [GIT PULL] Crypto Fixes for 5.19 Herbert Xu
2022-08-02 6:05 ` [GIT PULL] Crypto Update for 5.20 Herbert Xu
2022-10-04 8:54 ` [GIT PULL] Crypto Update for 6.1 Herbert Xu
2022-12-14 8:15 ` [GIT PULL] Crypto Update for 6.2 Herbert Xu
2023-02-20 5:22 ` [GIT PULL] Crypto Update for 6.3 Herbert Xu
2023-04-24 4:52 ` [GIT PULL] Crypto Update for 6.4 Herbert Xu
2023-06-29 5:06 ` [GIT PULL] Crypto Update for 6.5 Herbert Xu
2023-08-28 9:22 ` [GIT PULL] Crypto Update for 6.6 Herbert Xu
2023-11-02 6:56 ` [GIT PULL] Crypto Update for 6.7 Herbert Xu
2024-01-09 22:17 ` [GIT PULL] Crypto Update for 6.8 Herbert Xu
2024-03-15 3:04 ` [GIT PULL] Crypto Update for 6.9 Herbert Xu
2024-03-15 21:51 99% ` Linus Torvalds
2024-03-15 17:49 [GIT PULL] KVM changes for Linux 6.9 merge window Paolo Bonzini
2024-03-15 22:28 ` Linus Torvalds
2024-03-15 23:32 ` Oliver Upton
2024-03-15 23:49 ` Oliver Upton
2024-03-16 8:48 ` Paolo Bonzini
2024-03-16 16:01 99% ` Linus Torvalds
2024-03-16 0:24 ` [PATCH] Revert "KVM: arm64: Snapshot all non-zero RES0/RES1 sysreg fields for later checking" Oliver Upton
2024-03-16 0:51 99% ` Linus Torvalds
2024-01-22 15:29 [GIT PULL] Enable -Wstringop-overflow globally Gustavo A. R. Silva
2024-01-26 21:22 99% ` Linus Torvalds
2024-01-26 21:30 ` Gustavo A. R. Silva
2024-01-26 22:24 ` Kees Cook
2024-01-26 22:36 99% ` Linus Torvalds
2024-05-13 8:13 [GIT PULL] x86/shstk change for v6.10 Ingo Molnar
2024-05-14 2:38 99% ` Linus Torvalds
2024-03-11 15:57 [GIT PULL] EDAC updates for v6.9 Borislav Petkov
2024-03-12 1:12 99% ` Linus Torvalds
2024-03-12 2:24 ` Randy Dunlap
2024-03-12 2:25 99% ` Linus Torvalds
2024-03-15 16:29 [GIT PULL] tracing: Updates " Steven Rostedt
2024-03-16 16:31 99% ` Linus Torvalds
2024-04-17 23:45 [GIT PULL] Btrfs fixes for 6.9-rc5 David Sterba
2024-04-18 0:14 99% ` Linus Torvalds
2024-05-16 0:52 [GIT PULL] probes updates for v6.10 Masami Hiramatsu
2024-05-18 2:12 ` Linus Torvalds
2024-05-18 14:38 ` Masami Hiramatsu
2024-05-18 15:55 99% ` Linus Torvalds
2024-01-16 16:42 [GIT PULL] Backlight for v6.8 Lee Jones
2024-01-17 23:38 99% ` Linus Torvalds
2024-02-27 16:48 [PATCH 0/2] cleanup: A couple extensions for conditional resource management Dan Williams
2024-02-27 16:48 ` [PATCH 2/3] cleanup: Introduce cond_no_free_ptr() Dan Williams
2024-02-27 20:40 99% ` Linus Torvalds
2024-03-08 18:38 [PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters Steven Rostedt
2024-03-08 20:39 ` Linus Torvalds
2024-03-08 21:35 ` Steven Rostedt
2024-03-08 21:39 99% ` Linus Torvalds
2024-03-08 21:41 99% ` Linus Torvalds
2024-05-15 22:26 [GIT PULL] workqueue: Changes for v6.10 Tejun Heo
2024-05-16 0:36 99% ` Linus Torvalds
2024-05-16 0:55 ` Tejun Heo
2024-05-16 0:58 99% ` Linus Torvalds
2024-01-26 20:02 [PATCH] eventfs: Have inodes have unique inode numbers Steven Rostedt
2024-01-26 20:25 ` Linus Torvalds
2024-01-26 21:26 ` Steven Rostedt
2024-01-26 21:36 ` Linus Torvalds
2024-01-26 21:49 ` Linus Torvalds
2024-01-27 21:47 ` Linus Torvalds
2024-01-28 22:51 ` Steven Rostedt
2024-01-28 23:24 ` Linus Torvalds
2024-01-28 23:59 ` Steven Rostedt
2024-01-29 0:21 ` Steven Rostedt
2024-01-29 1:00 ` Linus Torvalds
2024-01-29 1:42 ` Linus Torvalds
2024-01-29 2:32 ` Steven Rostedt
2024-01-29 3:40 ` Steven Rostedt
2024-01-29 4:01 99% ` Linus Torvalds
2024-01-26 22:14 ` Mathieu Desnoyers
2024-01-26 22:29 99% ` Linus Torvalds
2024-01-26 22:41 ` Mathieu Desnoyers
2024-01-26 22:49 99% ` Linus Torvalds
2024-01-26 22:34 ` Matthew Wilcox
2024-01-26 22:48 ` Linus Torvalds
2024-01-26 23:04 ` Matthew Wilcox
2024-01-26 23:11 ` Linus Torvalds
2024-01-26 23:17 99% ` Linus Torvalds
2024-04-12 18:10 [PATCH 0/3] x86/bugs: BHI fixes / improvements - round 2 Josh Poimboeuf
2024-04-12 18:10 ` [PATCH v2 1/3] x86/bugs: Only harden syscalls when needed Josh Poimboeuf
2024-04-15 7:32 ` Nikolay Borisov
2024-04-15 15:16 99% ` Linus Torvalds
2024-03-13 20:56 [RFC PATCH 0/2] Introduce serialized smp_call_function APIs Mathieu Desnoyers
2024-03-13 20:56 ` [RFC PATCH 1/2] smp: Implement " Mathieu Desnoyers
2024-03-13 21:19 99% ` Linus Torvalds
2024-04-28 8:24 [GIT PULL] scheduler fixes Ingo Molnar
2024-04-28 8:42 ` Ingo Molnar
2024-04-28 19:13 99% ` Linus Torvalds
2024-04-29 14:47 [PATCH] bounds: Use the right number of bits for power-of-two CONFIG_NR_CPUS Matthew Wilcox (Oracle)
2024-04-29 15:32 99% ` Linus Torvalds
2023-12-12 23:16 [RFC PATCH v3 00/11] Introduce mseal() jeffxu
2023-12-12 23:17 ` [RFC PATCH v3 11/11] mseal:add documentation jeffxu
2023-12-13 0:39 ` Linus Torvalds
2023-12-14 0:35 ` Jeff Xu
2023-12-14 1:31 ` Linus Torvalds
2023-12-14 18:06 ` Stephen Röttger
2023-12-14 20:14 ` Linus Torvalds
2023-12-14 22:52 ` Jeff Xu
2024-01-20 15:23 ` Theo de Raadt
2024-01-20 16:40 99% ` Linus Torvalds
2024-03-01 22:52 [PATCH v2] x86: disable non-instrumented version of copy_mc when KMSAN is enabled Tetsuo Handa
2024-03-05 11:31 ` Tetsuo Handa
2024-03-05 17:57 ` Linus Torvalds
2024-03-06 22:08 ` Tetsuo Handa
2024-03-07 0:09 99% ` Linus Torvalds
2024-03-15 11:03 [GIT PULL]: Generic phy updates for v6.9 Vinod Koul
2024-03-15 19:22 99% ` Linus Torvalds
2024-03-16 18:05 ` Vinod Koul
2024-03-16 18:23 99% ` Linus Torvalds
2024-04-02 2:14 [linus:master] [x86/bugs] 4535e1a417: WARNING:at_arch/x86/kernel/alternative.c:#apply_returns kernel test robot
2024-04-03 12:23 ` [PATCH] x86/retpoline: Fix a missing return thunk warning (was: Re: [linus:master] [x86/bugs] 4535e1a417: WARNING:at_arch/x86/kernel/alternative.c:#apply_returns) Borislav Petkov
2024-04-03 16:45 99% ` Linus Torvalds
2024-04-03 17:05 ` Borislav Petkov
2024-04-03 17:13 99% ` Linus Torvalds
2024-05-18 2:22 [GIT PULL] MM updates for 6.10-rc1 Andrew Morton
2024-05-19 15:32 ` Linus Torvalds
2024-05-19 16:48 99% ` Linus Torvalds
2024-05-19 18:36 ` Andrew Morton
2024-05-19 18:56 ` Linus Torvalds
2024-05-19 18:59 99% ` Linus Torvalds
2024-05-13 16:20 [GIT PULL] Btrfs updates for 6.10 David Sterba
2024-05-16 0:31 ` Linus Torvalds
2024-05-16 9:01 ` Qu Wenruo
2024-05-16 15:47 99% ` Linus Torvalds
2024-01-22 23:06 [BUG] BUG: kernel NULL pointer dereference at ttm_device_init+0xb4 Steven Rostedt
2024-01-22 23:15 ` Steven Rostedt
2024-01-22 23:19 ` Steven Rostedt
2024-01-23 0:43 99% ` Linus Torvalds
[not found] ` <27c3d1e9-5933-47a9-9c33-ff8ec13f40d3@amd.com>
2024-01-23 1:25 99% ` Linus Torvalds
2024-04-02 20:53 user-space concurrent pipe buffer scheduler interactions Michael Clark
2024-04-03 16:56 99% ` Linus Torvalds
2024-04-03 20:39 ` Michael Clark
2024-04-03 20:57 99% ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).