On Mon, 23 Jun 2025 at 22:49, Christophe Leroy
wrote:
>
> >
> > (Although I also suspect that when we added ITER_UBUF we might have
> > created cases where those user addresses aren't checked at iter
> > creation time any more).
> >
>
> Let's take the follow path as an exemple:
>
> snd_pcm_ioctl(S
On Sun, 22 Jun 2025 at 10:13, David Laight wrote:
>
> Not checking the size is slightly orthogonal.
> It really just depends on the accesses being 'reasonably sequential'.
> That is probably always true since access_ok() covers a single copy.
It is probably true in practice, but yeah, it's worth
On Sun, 22 Jun 2025 at 02:52, Christophe Leroy
wrote:
>
> The results of "access_ok()" can be mis-speculated.
Hmm. This code is critical. I think it should be converted to use that
masked address thing if we have to add it here.
And at some point this access_ok() didn't even exist, because we ch
On Sun, 1 Jun 2025 at 16:00, Eric Biggers wrote:
>
> I implemented my proposal, for lib/crc first,
Ok, I scanned through that series, and it looks good to me. A clear improvement.
Linus
On Thu, 29 May 2025 at 14:16, Eric Biggers wrote:
>
> So using crc32c() + ext4 + x86 as an example (but SHA-256 would be very
> similar), the current behavior is that ext4.ko depends on the crc32c_arch()
> symbol.
Yes, I think that's a good example.
I think it's an example of something that "wor
On Thu, 29 May 2025 at 10:37, Eric Biggers wrote:
>
> Long-term, I'd like to find a clean way to consolidate the library code for
> each
> algorithm into a single module.
No, while I think the current situation isn't great, I think the "make
it one single module" is even worse.
For most archite
On Fri, 25 Apr 2025 at 23:51, Eric Biggers wrote:
>
> Following the example of several other algorithms (e.g. CRC32, ChaCha,
> Poly1305, BLAKE2s), this series refactors the kernel's existing
> architecture-optimized SHA-256 code to be available via the library API,
> instead of just via the crypto
On Sun, 8 Dec 2024 at 14:54, Andreas Schwab wrote:
>
> This breaks userspace on ppc32. As soon as /init in the initrd is
> started the kernel hangs (without any messages).
Funky, funky. Most of the diff is the code movement (and some small
x86-specific stuff), so for ppc, the only part that shou
On Sun, 24 Nov 2024 at 08:11, David Laight wrote:
>
> Is there an 'unsafe_get_user_nofault()' that uses a trap handler
> that won't fault in a page?
Nope. I was thinking about the same thing, but we actually don't look
up the fault handler early - we only do it at failure time.
So the pagefault_
On Fri, 22 Nov 2024 at 11:13, Linus Torvalds
wrote:
>
> I've only compiled it so far, about to actually boot into it.
Looks fine. Sent out a proper patch with commit message etc at
https://lore.kernel.org/all/20241122193305.7316-1-torva...@linux-foundation.org/
because it looks
On Thu, 21 Nov 2024 at 19:57, Linus Torvalds
wrote:
>
> Anyway, that was a long way of saying: I really think we should just
> special-case the (few) important cases that get reported. Because any
> *big* improvements will come not from just inlining.
Looking around at the futex co
On Fri, 22 Nov 2024 at 01:20, Christophe Leroy
wrote:
>
> On powerpc for this kind of stuff I have been using do { } while (0);
> with a break; in the middle, see for instance __put_user() or
> __get_user_size_allowed() in arch/powerpc/include/asm/uaccess.h
Oh, that's indeed a nicer syntax. I'll
On Thu, 21 Nov 2024 at 19:11, Josh Poimboeuf wrote:
>
> On Thu, Nov 21, 2024 at 05:02:06PM -0800, Linus Torvalds wrote:
> > [ Time passes ]
> >
> > Ugh. I tried it. It looks like this:
> >
> > #define inlined_get_user(res, ptr) ({
On Thu, 21 Nov 2024 at 16:12, Josh Poimboeuf wrote:
>
> The asm looks good, but the C exploded a bit... why not just have an
> inline get_user()?
That was originally one of my goals for the "unsafe" ones - if done
right, they'd be the proper building blocks for a get_user(), and we'd
only really
On Thu, 21 Nov 2024 at 13:40, Josh Poimboeuf wrote:
>
> The profile is showing futex_get_value_locked():
Ahh.
> That has several callers, so we can probably just use get_user() there?
Yeah, that's the simplest thing. That thing isn't even some inline
function, so the real cost is the call.
Tha
On Sat, 16 Nov 2024 at 13:38, David Laight wrote:
>
> If __get_user() is the same as get_user() [..]
No, the problem is that it's the same from a performance angle (and
now it's actually slower), but some hacky code paths depend on
__get_user() not checking the address.
They then use that to rea
On Fri, 15 Nov 2024 at 15:06, Josh Poimboeuf wrote:
>
> It's sad that __get_user() is now slower than get_user() on x86, it kind
> of defeats the whole point!
Well, honestly, we've been trying to get away from __get_user() and
__put_user() for a long long time.
With CLAC/STAC, it's been probably
On Wed, 6 Nov 2024 at 05:02, Steven Rostedt wrote:
>
> This fix looks fine to me. How should we handle this when we send our pull
> requests to Linus? I may forgot about this issue, and it also matters who's
> tree goes first.
So just mention the issue in the pull request - preferably on both
sid
On Mon, 28 Oct 2024 at 15:56, Josh Poimboeuf wrote:
>
> The barrier_nospec() in 64-bit copy_from_user() is slow. Instead use
> pointer masking to force the user pointer to all 1's if the access_ok()
> mispredicted true for an invalid address.
>
> The kernel test robot reports a 2.6% improvement i
On Mon, 28 Oct 2024 at 10:31, Kirill A. Shutemov wrote:
>
> On Mon, Oct 28, 2024 at 08:44:10AM -1000, Linus Torvalds wrote:
> > I The *hardware* presumably uses either bit 47/56 because that's the
> > actual hardware width of the TLB / cache matching.
>
> It is a
On Mon, 28 Oct 2024 at 01:29, Kirill A. Shutemov wrote:
>
> I think it is worth looking at this approach again as it gets better
> code: removes two instructions from get_user() and doesn't get flags
> involved.
The problem with the 'and' is that it's just re-introducing the same old bug.
> The
On Fri, 25 Oct 2024 at 01:56, David Laight wrote:
>
> > > Especially if there is always a (PAGE sized) gap between the highest
> > > user address and the lowest kernel address so the 'size' argument
> > > to access_ok() can be ignored on the assumption that the accesses
> > > are (reasonably) line
On Thu, 24 Oct 2024 at 02:22, David Laight wrote:
>
> Would it be better to make the 'bogus' constant one that makes
> all accesses fail?
Well, the bogus constant is actually used for other runtime cases too
(well, right now that's only the dentry pointer, but could be more),
it's not some kind o
On Wed, 23 Oct 2024 at 16:32, Linus Torvalds
wrote:
>
> And I guess I should make "__put_user()" do the same thing, just so
> that we only have one sequence.
No, I decided it's not worth it. The put_user side already also
doesn't do any other speculation barri
On Wed, 23 Oct 2024 at 12:17, Linus Torvalds
wrote:
>
> NOTE! This is obviously untested and I didn't check that it does the
> cmp/sbb/or the right way around.
Well, it boots. The code generation (from strncpy_from_user()) seems ok:
movabs $0x123456789abcdef,%rcx
cm
On Wed, 23 Oct 2024 at 13:07, Linus Torvalds
wrote:
>
> Well, it boots. The code generation (from strncpy_from_user()) seems ok:
Actually, doing some more sanity checking, that patch is wrong.
Not *badly* wrong, but for some reason I did the "sbb" in 32-bit
(quite intentionall
On Wed, 23 Oct 2024 at 02:45, Borislav Petkov wrote:
>
> So I was able to get some info: CLAC/STAC in everything Zen4 and older is
> serializing so there's no issue there.
>
> Zen5 is a different story and AC is being renamed there and thus,
> non-serializing. So we'd need to do something there, p
On Mon, 21 Oct 2024 at 03:48, Kirill A. Shutemov wrote:
>
> LAM brings own speculation issues[1] that is going to be addressed by
> LASS[2]. There was a patch[3] to disable LAM until LASS is landed, but it
> never got applied for some reason.
Bah., I think the reason was that nobody knew what - i
On Sun, 20 Oct 2024 at 16:11, Josh Poimboeuf wrote:
>
> Until it's s/think/know/ can we please put something in place?
Honestly, I'm pretty damn fed up with buggy hardware and completely
theoretical attacks that have never actually shown themselves to be
used in practice.
So I think this time we
On Sun, 20 Oct 2024 at 15:44, Josh Poimboeuf wrote:
>
> Anyway, I'd really like to make forward progress on getting rid of the
> LFENCEs in copy_from_user() and __get_user(), so until if/when we hear
> back from both vendors, how about we avoid noncanonical exceptions
> altogether (along with the
On Wed, 16 Oct 2024 at 15:13, Kirill A. Shutemov wrote:
>
> It is worse than that. If we get LAM_SUP enabled (there's KASAN patchset
> in works) this check will allow arbitrary kernel addresses.
Ugh. I haven't seen the LAM_SUP patches.
But yeah, I assume any LAM_SUP model would basically then ma
On Wed, 16 Oct 2024 at 15:03, Andrew Cooper wrote:
>
> That doesn't have the same semantics, does it?
Correct. It just basically makes all positive addresses be force-canonicalized.
> If AMD think it's appropriate, then what you probably want is the real
> branch as per before (to maintain archi
On Mon, 14 Oct 2024 at 09:55, Linus Torvalds
wrote:
>
> On Mon, 14 Oct 2024 at 05:30, Kirill A. Shutemov wrote:
> >
> > Given that LAM enforces bit 47/56 to be equal to bit 63 I think we can do
> > this unconditionally instead of masking:
> >
> > diff --git
On Mon, 14 Oct 2024 at 05:30, Kirill A. Shutemov wrote:
>
> Given that LAM enforces bit 47/56 to be equal to bit 63 I think we can do
> this unconditionally instead of masking:
>
> diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
> index d066aecf8aeb..86d4511520b1 100644
> --- a/arch/x
On Mon, 14 Oct 2024 at 02:59, David Laight wrote:
>
> Isn't LAM just plain stupid unless the hardware validates the bits
> against the TLB?
What? No. You can't do that. At some point, the TLB isn't filled, and
then you have to do the access with lots of linear address bits
masked.
> Doesn't ARM6
On Sun, 13 Oct 2024 at 20:54, Josh Poimboeuf wrote:
>
> If I understand correctly, LAM bits are for the benefit of SW and are
> ignored by HW? Can we just mask those bits off?
Yes. But then you waste time on the masking, but particularly if it
then causes silly extra overhead just to get the mas
On Sat, 12 Oct 2024 at 17:53, Linus Torvalds
wrote:
>
> So no, the address masking can not depend on things like
> __VIRTUAL_MASK_SHIFT, it would need to at least take LAM into account
> too. Not that I know if there are any CPU's out there that actually
> have LAM enabled.
On Sat, 12 Oct 2024 at 10:44, Linus Torvalds
wrote:
>
> Anyway, what's the speculation window size like?
Note that this is important basically because we do *NOT* want to
check the address against TASK_SIZE_MAX like we used to, because not
only is TASK_SIZE_MAX not a compile-time co
On Sat, 12 Oct 2024 at 10:23, Andrew Cooper wrote:
>>
> This logic is asymmetric.
>
> For an address in the upper half (canonical or non-canonical), it ORs
> with -1 and fully replaces the prior address.
Right. The point is that non-canonical addresses will fault, and
kernel addresses are guarant
On Sat, 12 Oct 2024 at 07:21, Borislav Petkov wrote:
>
> Commit
>
> 2865baf54077 ("x86: support user address masking instead of
> non-speculative conditional")
No.
Thos started long before. Again, see commit b19b74bc99b1 ("x86/mm:
Rework address range check in get_user() and put_user(
On Sat, 12 Oct 2024 at 01:49, Andrew Cooper wrote:
>
> You do realise mask_user_address() is unsafe under speculation on AMD
> systems?
That had *better* not be true.
> Had the mask_user_address() patch been put for review, this feedback
> would have been given then.
That's BS.
Why? Look at co
On Fri, 6 Sept 2024 at 05:08, Michael Ellerman wrote:
>
> Please pull some more powerpc fixes for 6.11:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-6.11-3
Hmm. New pgp key? Please don't take me by surprise like this.
The key looks fine, I see the signa
On Mon, 2 Sept 2024 at 13:49, Andrew Morton wrote:
>
> uprobe_clear_state() is a pretty simple low-level thing. Side-effects
> seem unlikely?
I think uprobe_clear_state() should be removed from fork.c entirely,
made 'static', and then we'd have
area->xol_mapping.close = uprobe_clear_sta
top and internet, I'm unlikely to work on this any more.
Andrew - I think this is good, but there may be other issues lurking.
Do with it as you see fit,
Linus
From ef4e84d69c3d669e606b5d386625267a3b9c9573 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Tue, 20 Aug 2024 15:14:47
On Tue, 20 Aug 2024 at 14:17, Rob Landley wrote:
>
> Hexagon also has &&vdso_page which I don't understand (but have a toolchain
> for
> somewhere to at least smoketest...)
The '&&' is just a typo. It should obviously be just a single '&'. As
mentioned, the only testing that patch got was a x86-
On Mon, 19 Aug 2024 at 23:26, Michael Ellerman wrote:
>
> Linus Torvalds writes:
> > +static struct vm_special_mapping vdso_mapping = {
> > + .name = "[vdso]",
> > + .pages = syscall_pages;
> ^
>
On Mon, 19 Aug 2024 at 18:05, Andrew Morton wrote:
>
> >
> > I forgot to actually attach that "this". Here it is. For real, this time.
>
> Thanks. Do you think your one-liner remains desirable with this fix in
> place?
That patch actually removes the whole 'legacy_special_mapping_vmops'
that my
On Mon, 19 Aug 2024 at 13:15, Linus Torvalds
wrote:
>
> Ok, I did a quick hack-job to remove that disgusting
> install_special_mapping() legacy case.
>
> With this [..]
I forgot to actually attach that "this". Here it is. For real, this time.
Linus
On Mon, 19 Aug 2024 at 12:51, Nathan Chancellor wrote:
>
> Yes, that appears to fix it for me. I don't have much to say about the
> rest but others might :)
Ok, I did a quick hack-job to remove that disgusting
install_special_mapping() legacy case.
With this, the old "install_special_mapping()"
On Mon, 19 Aug 2024 at 11:53, Nathan Chancellor wrote:
>
>
> Modules linked in:
> Pid: 24, comm: mount Not tainted 6.11.0-rc4-next-20240819
> RIP: 0033:0x68006f6c
> RSP: 6c8bfc68 EFLAGS: 00010206
> RAX: 68006f6c RBX: 68a0aa18 RCX: 600d8b09
> RDX: R
On Wed, 7 Aug 2024 at 16:20, Liam R. Howlett wrote:
>
> Okay, I'm going to try one more time here. You are suggesting to have a
> conf flag to leave the vdso pointer unchanged when it is unmapped.
> Having the close behind the conf option will not prevent it from being
> unmapped or mapped over,
On Wed, 24 Jul 2024 at 14:00, Joel Granados wrote:
>
> This is my first time sending out a semantic patch, so get back to me if
> you have issues or prefer some other way of receiving it.
Looks fine to me.
Sometimes if it's just a pure scripting change, people send me the
script itself and just
On Thu, 20 Jun 2024 at 13:20, Yury Norov wrote:
>
> FORCE_NR_CPUS helped to generate a better code for me back then. I'll
> check again against the current kernel.
Of _course_ it generates better code.
But when "better code" is a source of bugs, and isn't actually useful
in general, it's not bet
On Thu, 20 Jun 2024 at 11:32, Yury Norov wrote:
>
> Is that in master already? I didn't get any email, and I can't find
> anything related in the master branch.
It's 5d272dd1b343 ("cpumask: limit FORCE_NR_CPUS to just the UP case").
> > New rule: before you send some optimization, you need to ha
On Thu, 20 Jun 2024 at 10:57, Yury Norov wrote:
>
>
> The typical lock-protected bit allocation may look like this:
If it looks like this, then nobody cares. Clearly the user in question
never actually cared about performance, and you SHOULD NOT then say
"let's optimize this that nobody cares abo
On Tue, 4 Jun 2024 at 11:25, Rodrigo Vivi wrote:
>
> (I believe that the new _match_string(str1, size, str2) deserves a better
> name,
> but since I'm bad with naming stuff, I don't have any good suggestion)
I hated the enormous cc list, so I didn't reply to all. But clearly
everybody else is ju
On Mon, 27 Nov 2023 at 02:27, Christian Brauner wrote:
>
> So I've picked up your patch (vfs.misc). It's clever alright so thanks
> for the comments in there otherwise I would've stared at this for far
> too long.
Note that I should probably have commented on one other thing: that
whole "just loa
On Sun, 26 Nov 2023 at 12:23, Linus Torvalds
wrote:
>
> IOW, I might have messed up some "trivial cleanup" when prepping for
> sending it out...
Bah. Famous last words. One of the "trivial cleanups" made the code
more "obvious" by renaming the nospec mask a
On Sun, 19 Nov 2023 at 23:11, kernel test robot wrote:
>
> kernel test robot noticed a -2.9% regression of will-it-scale.per_thread_ops
> on:
>
> commit: 0ede61d8589cc2d93aa78230d74ac58b5b8d0244 ("file: convert to
> SLAB_TYPESAFE_BY_RCU")
Ok, so __fget_light() is one of our more performance-cri
On Thu, 28 Sept 2023 at 20:50, Amir Goldstein wrote:
>
> OTOH, it is perfectly fine if the vfs wants to stop providing sub 100ns
> services to filesystems. It's just going to be the fs problem and the
> preserved pre-historic/fine-grained time on existing files would only
> need to be provided in
On Thu, 28 Sept 2023 at 14:28, Theodore Ts'o wrote:
>
> I don't think anyone will complain about breaking the userspace API
> --- especially since if, say, the CIA was using this for their spies'
> drop boxes, they probably wouldn't want to admit it. :-)
Well, you will find that real apps do kin
On Thu, 28 Sept 2023 at 04:06, Jeff Layton wrote:
>
> Move i_blocks up above the i_lock, which moves the new 4 byte hole to
> just after the timestamps, without changing the size of the structure.
I'm sure others have mentioned this, but 'struct inode' is marked with
__randomize_layout, so the ac
On Tue, 15 Aug 2023 at 07:12, kernel test robot wrote:
>
> kernel test robot noticed a 6.3% improvement of stress-ng.zero.ops_per_sec on:
WTF? That's ridiculous. Why would that even test new_inode() at all?
And why would it make any difference anyway to prefetch a new inode?
The 'zero' test claim
On Fri, 4 Aug 2023 at 16:25, Mateusz Guzik wrote:
>
> I know of these guys, I think they are excluded as is -- they go
> through access_remote_vm, starting with:
> if (mmap_read_lock_killable(mm))
> return 0;
>
> while dup_mmap already write locks the parent's mm.
Oh, you'
On Fri, 4 Aug 2023 at 14:46, Mateusz Guzik wrote:
>
> I don't see it mentioned in the discussion, so at a risk of ruffling
> feathers or looking really bad I'm going to ask: is the locking of any
> use if the forking process is single-threaded? T
Sadly, we've always been able to access the mm fro
On Wed, 2 Aug 2023 at 09:16, Nathan Chancellor wrote:
>
> We see this warning with ARCH=arm64 defconfig + CONFIG_CPU_BIG_ENDIAN=y.
Oh Christ. I didn't even realize that arm64 allowed a BE config.
The config option goes back to 2013 - are there actually BE user space
implementations around?
Peop
On Sat, 8 Jul 2023 at 15:36, Suren Baghdasaryan wrote:
>
> On Sat, Jul 8, 2023 at 2:18 PM Linus Torvalds
> >
> > Again - maybe I messed up, but it really feels like the missing
> > vma_start_write() was more fundamental, and not some "TLB coherency"
> >
On Sat, 8 Jul 2023 at 12:12, Suren Baghdasaryan wrote:
>
> kernel/fork.c | 1 +
> 1 file changed, 1 insertion(+)
I ended up editing your explanation a lot.
I'm not convinced that the bug has much to do with the delayed tlb flushing.
I think it's more fundamental than some tlb coherence issue:
On Sat, 8 Jul 2023 at 12:17, Suren Baghdasaryan wrote:
>
> Do you want me to disable per-VMA locks by default as well?
No. I seriously believe that if the per-vma locking is so broken that
it needs to be disabled in a development kernel, we should just admit
failure, and revert it all.
And not i
On Sat, 8 Jul 2023 at 11:40, Suren Baghdasaryan wrote:
>
> My understanding was that flush_cache_dup_mm() is there to ensure
> nothing is in the cache, so locking VMAs before doing that would
> ensure that no page faults would pollute the caches after we flushed
> them. Is that reasoning incorrect
On Sat, 8 Jul 2023 at 10:39, Andrew Morton wrote:
>
> That was the v1 fix, but after some discussion
> (https://lkml.kernel.org/r/20230705063711.2670599-1-sur...@google.com)
> it was decided to take the "excessive" approach.
That makes absolutely _zero_ sense.
It seems to be complete voodoo prog
On Sat, 8 Jul 2023 at 04:35, Thorsten Leemhuis
wrote:
>
> The plan since early this week is to mark CONFIG_PER_VMA_LOCK as broken;
> latest patch that does this is this one afaics:
Bah.
Both marking it as broken and the pending fix seems excessive.
Why isn't the trivial fix just to say "yes, fo
On Fri, Apr 28, 2023 at 2:44 AM Michael Ellerman wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> tags/powerpc-6.4-1
Odd. Your shortlog has this:
> Michael Ellerman (46):
> powerpc/configs: Make pseries_defconfig an alias for ppc64le_guest
that removed the
On Tue, Apr 25, 2023 at 10:59 PM Nicholas Piggin wrote:
>
> Suggested-by: Linus Torvalds
I was all "what is Nick talking about", and had to follow the link to
remember that old discussion at all.
Patch obviously looks fine to me, I'll presumably be getting it at
some futu
On Sun, Mar 19, 2023 at 5:53 PM Sasha Levin wrote:
>
> [ Upstream commit 8ca09d5fa3549d142c2080a72a4c70ce389163cd ]
These are technically real fixes, but they are really just "documented
behavior" fixes, and don't actually matter unless you also have
596ff4a09b89 ("cpumask: re-introduce constant-
On Fri, Feb 17, 2023 at 2:40 PM Michael Ellerman wrote:
>
> Thanks to: Benjamin Gray, "Erhard F.".
That just looks _odd_.
It's not like the full name wasn't already elsewhere in the kernel
logs as a reporter (and at least once as patch author), so I just
fixed it up ;)
Linus
[ Adding a few more x86 and arm64 maintainers - while linux-arch is
the right mailing list, I'm not convinced people actually follow it
all that closely ]
On Wed, Jan 18, 2023 at 12:00 AM Nicholas Piggin wrote:
>
> On a 16-socket 192-core POWER8 system, a context switching benchmark
> with as man
On Mon, Jan 16, 2023 at 6:08 AM David Howells wrote:
>
> I'm not sure how relevant it is to the topic, but I seem to remember you
> having a go at implementing spinlocks with x86_64 memory transaction
> instructions a while back. Do you have any thoughts on whether these
> instructions are ever l
On Fri, Jan 13, 2023 at 3:47 PM Luck, Tony wrote:
>
> The computer necrophiliacs at Debian and Gentoo seem determined
> to keep ia64 alive.
>
> So perhaps this should s/cpu_relax/soemt_relax/ where soemt_relax
> is a no-op everywhere except ia64, which can define it as cpu_relax.
Heh. I already t
On Thu, Jan 12, 2023 at 9:20 PM Nicholas Piggin wrote:
>
> Actually what we'd really want is an arch specific implementation of
> lockref.
The problem is mainly that then you need to generate the asm versions
of all those different CMPXCHG_LOOP() variants.
They are all fairly simple, though, an
On Thu, Jan 12, 2023 at 7:12 PM Mateusz Guzik wrote:
>
> I did not want to make such a change without redoing the ThunderX2
> benchmark, or at least something else arm64-y. I may be able to bench it
> tomorrow on whatever arm-y stuff can be found on Amazon's EC2, assuming
> no arm64 people show up
On Thu, Jan 12, 2023 at 6:31 PM Luck, Tony wrote:
>
> There's not much "simultaneous" in the SMT on ia64.
Oh, I forgot about the whole SoEMT fiasco.
Yeah, that might make ia64 act a bit differently here.
But I don't think anybody cares any more, so I don't think that merits
making this a per-ar
[ Adding linux-arch, which is relevant but not very specific, and the
arm64 and powerpc maintainers that are the more specific cases for an
architecture where this might actually matter.
See
https://lore.kernel.org/all/CAGudoHHx0Nqg6DE70zAVA75eV-HXfWyhVMWZ-aSeOofkA_=w...@mail.gmail.com
On Thu, Nov 17, 2022 at 2:58 PM Kees Cook wrote:
>
> Oh, er, why does get_arg_page() even need FOLL_FORCE? This is writing the
> new stack contents to the nascent brpm->vma, which was newly allocated
> with VM_STACK_FLAGS, which an arch can override, but they all appear to
> include
> VM_WRITE |
On Wed, Nov 16, 2022 at 2:30 AM David Hildenbrand wrote:
>
> Let's make it clearer that functionality provided by FOLL_FORCE is
> really only for ptrace access.
I'm not super-happy about this one.
I do understand the "let's rename the bit so that no new user shows up".
And it's true that the ma
On Wed, Nov 2, 2022 at 7:09 PM Michael Ellerman wrote:
>
> - Fix an endian thinko in the asm-generic compat_arg_u64() which led to
> syscall arguments
>being swapped for some compat syscalls.
Am I mis-reading this, or did this bug (introduced in this merge
window by commit 43d5de2b67d7 "asm
On Tue, Oct 25, 2022 at 9:24 AM Guenter Roeck wrote:
>
> Build results:
> total: 152 pass: 152 fail: 0
> Qemu test results:
> total: 499 pass: 499 fail: 0
Woo-hoo!
That was quick, for once.
> Runtime warnings
Oh.
Well, close enough, and those fixes are presumably pending too.
On Wed, Oct 12, 2022 at 11:29 PM Arnd Bergmann wrote:
>
> On Thu, Oct 13, 2022, at 12:08 AM, Michael S. Tsirkin wrote:
> >
> > Do these two boxes even have pci?
>
> Footbridge/netwinder has PCI and PC-style ISA on-board devices
> (floppy, ps2 mouse/keyboard, parport, soundblaster, ...), RiscPC
> h
On Wed, Oct 12, 2022 at 8:51 AM Michael S. Tsirkin wrote:
>
> Are you sure?
MichaelE is right.
This is just bogus historical garbage:
> arch/arm/include/asm/irq.h:#ifndef NO_IRQ
> arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))
that I've tried to get rid of for years, but
On Mon, Oct 10, 2022 at 8:59 PM Joel Stanley wrote:
>
> The merge of the kbuild tree dropped the renaming of the FSL_BOOKE
> kconfig option.
Thanks. Mea culpa. Applied,
Linus
On Sat, Aug 13, 2022 at 4:27 PM wrote:
> [..]
Btw, could you please fix whatever your email setup is, so that you
have a proper name?
Seeing that 'mpe' as a source in my inbox just makes me think it's
spam and not real mail.
My search for "git pull" will find it, so it's not a huge problem in
p
On Mon, Jul 25, 2022 at 5:39 AM Michael Ellerman wrote:
>
> Further digging shows that the build failures only occur with compilers
> that default to 64-bit long double.
Where the heck do we have 'long double' things anywhere in the kernel?
I tried to grep for it, and failed miserably. I found s
On Mon, Jul 18, 2022 at 3:12 PM Segher Boessenkool
wrote:
>
> Assembler language is unforgiving. It isn't easy to write, and most
> mistakes will not be diagnosed. If the assmbler language makes it
> easier to read the code, that makes it more likely correct code will be
> written, and that corr
On Sun, Jul 17, 2022 at 9:41 PM Michael Ellerman wrote:
>
> > li 4,254 #,
>
> Here we load 254 into r4, which is the 2nd parameter to memset (c).
I love how even powerpc people know that "4" is bogus, and have to
make it clear that it means "r4".
I don't understand why th
On Mon, Jul 18, 2022 at 6:44 AM Michael Ellerman wrote:
>
> With GCC 12, allmodconfig enables CONFIG_INIT_STACK_ALL_PATTERN, which
> causes the compiler to emit memset calls to initialise on-stack
> variables with a pattern.
Ahh, and that explains why "volatile" made no difference. That did
seem
On Sun, Jul 17, 2022 at 2:49 PM Segher Boessenkool
wrote:
>
> > I can *kind of* see the logic that when you do a whole struct
> > assignment, it turns into a "memcpy" without regard for volatile
> > members. You're not actually accessing the volatile members in some
> > particular order, so the st
On Sun, Jul 17, 2022 at 2:00 PM Segher Boessenkool
wrote:
>
> Calling mem* on a volatile object (or a struct containing one) is not
> valid. I opened gcc.gnu.org/PR106335.
Well, that very quickly got marked as a duplicate of a decade-old bug.
So I guess we shouldn't expect this to be fixed any
On Sun, Jul 17, 2022 at 1:38 PM Sudip Mukherjee
wrote:
>
> I have also tried adding volatile to all the members of that struct. :(
Can you read the code to figure otu what the memcpy is all about?
Or maybe there is something that disables 'volatile' with pre-processor hackery.
Because a compil
On Sun, Jul 17, 2022 at 1:25 PM Sudip Mukherjee
wrote:
>
> And the generated assembly still has the memset for "struct prom_args".
Strange. That smells like a compiler bug to me.
But I can't read powerpc assembly code - it's been too many years, and
even back when I did read it I hated how the r
On Sun, Jul 17, 2022 at 2:13 AM Sudip Mukherjee
wrote:
>
> I was trying to check it. With gcc-11 the assembly code generated is
> not using memset, but using __memset.
> But with gcc-12, I can see the assembly code is using memset. One
> example from the assembly:
You could try making the 'args'
1 - 100 of 510 matches
Mail list logo
