On Fri, 22 Aug 2025 09:46:37 -0400
Linus Torvalds wrote:
> On Fri, 22 Aug 2025 at 05:58, Christophe Leroy
> wrote:
> >
> > The results of "access_ok()" can be mis-speculated. The result is that
> > you can end speculatively:
> >
> > if (access_ok(from, size))
> > // Righ
On Fri, 22 Aug 2025 11:58:05 +0200
Christophe Leroy wrote:
> At the time being, TASK_SIZE can be customized by the user via Kconfig
> but it is not possible to check all constraints in Kconfig. Impossible
> setups are detected at compile time with BUILD_BUG() but that leads
> to build failure whe
On Sat, 5 Jul 2025 15:15:57 -0500
Segher Boessenkool wrote:
...
> The isel machine instruction is super expensive on p8: it is marked as
> first in an instruction group, and has latency 5 for the GPR sources,
> and 8 for the CR field source.
>
> On p7 it wasn't great either, it was actually conv
On Thu, 26 Jun 2025 17:01:48 -0500
Segher Boessenkool wrote:
> On Thu, Jun 26, 2025 at 07:56:10AM +0200, Christophe Leroy wrote:
...
> I have no idea why you think power9 has it while older CPUS do not. In
> the GCC source code we have this comment:
> /* For ISA 2.06, don't add ISEL, since in
On Tue, 24 Jun 2025 16:37:12 -0500
Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jun 24, 2025 at 09:32:58AM +0100, David Laight wrote:
> > > So GCC uses the 'unlikely' variant of the branch instruction to force
> > > the correct prediction, doesn't it ?
On Tue, 24 Jun 2025 08:17:14 -0500
Segher Boessenkool wrote:
> On Tue, Jun 24, 2025 at 07:27:47AM +0200, Christophe Leroy wrote:
> > Ah ok, I overlooked that, I didn't know the cmove instruction, seem
> > similar to the isel instruction on powerpc e500.
>
> cmove does a move (register or memo
On Tue, 24 Jun 2025 13:25:05 -0500
Segher Boessenkool wrote:
> Hi!
>
> On Tue, Jun 24, 2025 at 05:50:01PM +0100, David Laight wrote:
> > On Tue, 24 Jun 2025 08:17:14 -0500
> > Segher Boessenkool wrote:
> >
> > > On Tue, Jun 24, 2025 at 07:27:47AM +0200,
On Tue, 24 Jun 2025 07:27:47 +0200
Christophe Leroy wrote:
> Le 22/06/2025 à 18:20, David Laight a écrit :
> > On Sun, 22 Jun 2025 11:52:38 +0200
> > Christophe Leroy wrote:
> >
> >> Masked user access avoids the address/size verification by access_ok().
> &g
On Tue, 24 Jun 2025 07:49:03 +0200
Christophe Leroy wrote:
> Le 22/06/2025 à 18:57, Linus Torvalds a écrit :
> > 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 c
On Sun, 22 Jun 2025 11:52:39 +0200
Christophe Leroy wrote:
> Allthough masked_user_access_begin() seems to only be used when reading
> data from user at the moment, introduce masked_user_read_access_begin()
> and masked_user_write_access_begin() in order to match
> user_read_access_begin() and us
On Sun, 22 Jun 2025 09:57:20 -0700
Linus Torvalds wrote:
> 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 h
On Sun, 22 Jun 2025 10:40:00 -0700
Linus Torvalds wrote:
> 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
On Sun, 22 Jun 2025 11:52:38 +0200
Christophe Leroy wrote:
> Masked user access avoids the address/size verification by access_ok().
> Allthough its main purpose is to skip the speculation in the
> verification of user address and size hence avoid the need of spec
> mitigation, it also has the ad
On Sun, 22 Jun 2025 11:52:43 +0200
Christophe Leroy wrote:
> Masked user access avoids the address/size verification by access_ok().
> Allthough its main purpose is to skip the speculation in the
> verification of user address and size hence avoid the need of spec
> mitigation, it also has the ad
On Sun, 22 Jun 2025 11:52:40 +0200
Christophe Leroy wrote:
> The results of "access_ok()" can be mis-speculated. The result is that
> you can end speculatively:
>
> if (access_ok(from, size))
> // Right here
>
> For the same reason as done in copy_from_user() by
> commit 74
On Wed, 11 Jun 2025 15:48:30 +0200
Christophe Leroy wrote:
> Le 10/06/2025 à 21:53, David Laight a écrit :
> > On Sat, 7 Jun 2025 13:37:42 +0200
> > Christophe Leroy wrote:
> >
> >> With user access protection (Called SMAP on x86 or KUAP on powerpc)
> >&g
On Sat, 7 Jun 2025 13:37:42 +0200
Christophe Leroy wrote:
> With user access protection (Called SMAP on x86 or KUAP on powerpc)
> each and every call to get_user() or put_user() performs heavy
> operations to unlock and lock kernel access to userspace.
>
> To avoid that, perform user accesses b
From: Linus Torvalds
> Sent: 22 November 2024 19:35
>
> 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/2024112219
From: Linus Torvalds
> Sent: 21 November 2024 22:16
>
> 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
From: Linus Torvalds
> Sent: 16 November 2024 01:27
>
> 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
> _
From: Josh Poimboeuf
> Sent: 29 October 2024 03:28
>
> On Mon, Oct 28, 2024 at 06:56:15PM -0700, Josh Poimboeuf wrote:
> > The barrier_nospec() in 64-bit __get_user() is slow. Instead use
> > pointer masking to force the user pointer to all 1's if a previous
> > access_ok() mispredicted true for
...
> access_ok() itself is so rarely used these days that we could out-line
> it. But the code cost of a function call is likely higher than
> inlining the 8-byte constant and a couple of instructions: not because
> the call instruction itself, but because of the code generation pain
> around it
From: Linus Torvalds
> Sent: 23 October 2024 21:08
>
> 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
From: Linus Torvalds
> Sent: 14 October 2024 12:21
>
> 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, t
...
> > 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 mask.
Isn't LAM just plain stupid unless th
From: Christophe Leroy
> Sent: 28 August 2024 07:35
> Hi Charlie,
>
> Le 28/08/2024 à 07:49, Charlie Jenkins a écrit :
> > Add support for MAP_BELOW_HINT to arch_get_mmap_base() and
> > arch_get_mmap_end().
> >
> > Signed-off-by: Charlie Jenkins
> > ---
> > arch/powerpc/include/asm/task_size_64
From: Simon Horman
> Sent: 31 July 2024 09:45
>
> On Tue, Jul 30, 2024 at 08:31:33AM +0200, Herve Codina wrote:
> > Received frame from QMC contains the CRC.
> > Upper layers don't need this CRC and tcpdump mentioned trailing junk
> > data due to this CRC presence.
> >
> > As some other HDLC drive
From: Stewart Hildebrand
> Sent: 17 July 2024 19:31
...
> > For more normal hardware just ensuring that two separate targets don't share
> > a page while allowing (eg) two 1k BAR to reside in the same 64k page would
> > give some security.
>
> Allow me to understand this better, with an example:
>
From: David Laight
> Sent: 17 July 2024 14:15
>
> From: Stewart Hildebrand
> > Sent: 16 July 2024 20:33
> >
> > This series sets the default minimum resource alignment to 4k for memory
> > BARs. In preparation, it makes an optimization and addresses so
From: Stewart Hildebrand
> Sent: 16 July 2024 20:33
>
> This series sets the default minimum resource alignment to 4k for memory
> BARs. In preparation, it makes an optimization and addresses some corner
> cases observed when reallocating BARs. I consider the prepapatory
> patches to be prerequisi
From: Nicholas Piggin
> Sent: 15 July 2024 09:25
>
> On Sun Jul 14, 2024 at 6:27 PM AEST, Naveen N Rao wrote:
> > Function profile sequence on powerpc includes two instructions at the
> > beginning of each function:
> > mflrr0
> > bl ftrace_caller
> >
> > The call to ftrace_caller
From: Segher Boessenkool
> Sent: 16 April 2024 11:38
>
> On Tue, Apr 16, 2024 at 03:02:52PM +0530, Naresh Kamboju wrote:
> > In file included from arch/powerpc/include/asm/io.h:672:
> > arch/powerpc/include/asm/io-defs.h:43:1: error: performing pointer
> > arithmetic on a null pointer has undefine
From: Adrian Hunter
> Sent: 11 April 2024 10:04
>
> On 11/04/24 10:56, Arnd Bergmann wrote:
> > On Thu, Apr 11, 2024, at 09:16, Adrian Hunter wrote:
> >> On 11/04/24 10:04, Arnd Bergmann wrote:
> >>> On Wed, Apr 10, 2024, at 17:32, Adrian Hunter wrote:
> BUG() does not return, and arch implem
From: Christophe Leroy
> Sent: 23 February 2024 10:07
...
> > +/* Ethernet headers are 14 bytes and NET_IP_ALIGN is used to align them */
> > +#define IP_ALIGNMENT (14 + NET_IP_ALIGN)
>
> Only if no VLAN.
>
> When using VLANs it is 4 bytes more. But why do you mind that at all ?
Wasn't one archi
From: Segher Boessenkool
> Sent: 13 February 2024 19:13
>
> On Tue, Feb 13, 2024 at 11:17:49AM +0100, Arnd Bergmann wrote:
> > clang warns about explicitly casting between incompatible function
> > pointers:
> >
> > drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void
> > *)'
From: David Laight
> Sent: 05 October 2023 11:16
...
> > - cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu*
> > -print -quit)
> > + cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name 'cpu*'
> > -print -quit)
>
> Isn
From: Athira Rajeev
> Sent: 29 September 2023 05:12
>
> Running shellcheck on tests/shell/test_arm_coresight.sh
> throws below warnings:
>
> In tests/shell/test_arm_coresight.sh line 15:
> cs_etm_path=$(find /sys/bus/event_source/devices/cs_etm/ -name cpu*
> -print -quit)
>
From: Shuai Xue
> Sent: 25 September 2023 02:44
>
> On 2023/9/21 21:20, David Laight wrote:
> > ...
> > I've got a target to generate AER errors by generating read cycles
> > that are inside the address range that the bridge forwards but
> > outside of any B
> It would be nice if they worked the same, but I suspect that vendors
> may rely on the fact that CPER_SEV_FATAL forces a restart/panic as
> part of their system integrity story.
The file system errors created by a panic (especially an NMI panic)
could easily be more problematic than a failed PCI
...
I've got a target to generate AER errors by generating read cycles
that are inside the address range that the bridge forwards but
outside of any BAR because there are 2 different sized BARs.
(Pretty easy to setup.)
On the system I was using they didn't get propagated all the way
to the root bri
...
> All of "\\n", "\n", '\n' are the same.
and \\n (without any quote characters at all).
Personally I'd use 'format' for printf.
To make it obvious that nothing is to be expanded.
But it isn't really worth changing existing 'stuff'.
David
-
Registered Address Lakeside, Bramley Road,
From: Jordan Niethe
> Sent: 07 August 2023 02:46
>
> The LPID register is 32 bits long. The host keeps the lpids for each
> guest in an unsigned word struct kvm_arch. Currently, LPIDs are already
> limited by mmu_lpid_bits and KVM_MAX_NESTED_GUESTS_SHIFT.
>
> The nestedv2 API returns a 64 bit "Gu
...
> FWIW, I agree with Christian that these behaviours are not ideal (and
> I'm working on a series that might allow for these things to be properly
> blocked in the future) but there's also the consistency argument -- I
> don't think fchownat() is much safer to allow in this way than
> fchmodat(
From: Aleksa Sarai
> Sent: 25 July 2023 17:36
...
> We almost certainly want to support AT_EMPTY_PATH at the same time.
> Otherwise userspace will still need to go through /proc when trying to
> chmod a file handle they have.
That can't be allowed.
Just because a process has a file open and write
From: Maninder Singh
> Sent: 29 May 2023 12:14
>
> kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
> writes on index "KSYM_NAME_LEN - 1".
>
> Thus array size should be KSYM_NAME_LEN.
>
> for hexagon it was defined as "128" directly.
> and commit '61968dbc2d5d' changed define va
From: Michael Ellerman
> Sent: 05 May 2023 04:51
>
> Since commit 1ba3cbf3ec3b ("mm: kfence: improve the performance of
> __kfence_alloc() and __kfence_free()"), kfence reports failures in
> random places at boot on big endian machines.
>
> The problem is that the new KFENCE_CANARY_PATTERN_U64 en
From: Danny Tsen
> Sent: 24 April 2023 19:47
>
> Improve overall performance of chacha20 encrypt and decrypt operations
> for Power10 or later CPU.
>
> Signed-off-by: Danny Tsen
> ---
> arch/powerpc/crypto/chacha-p10le-8x.S | 842 ++
> 1 file changed, 842 insertions(+)
>
From: Dave Hansen
> Sent: 11 April 2023 14:44
>
> On 4/11/23 04:35, Mark Rutland wrote:
> > I agree it'd be nice to have performance figures, but I think those would
> > only
> > need to demonstrate a lack of a regression rather than a performance
> > improvement, and I think it's fairly clear fr
From: Geert Uytterhoeven
> Sent: 11 April 2023 09:50
>
> Hi David,
>
> On Wed, Apr 5, 2023 at 11:37 PM David Laight wrote:
> > From: Linuxppc-dev Arnd Bergmann
> > > Sent: 05 April 2023 21:32
> > >
> > > On Wed, Apr 5, 2023, at 22:00, H. Peter
From: Uros Bizjak
> Sent: 06 April 2023 09:39
>
> On Thu, Apr 6, 2023 at 10:26 AM David Laight wrote:
> >
> > From: Dave Hansen
> > > Sent: 05 April 2023 17:37
> > >
> > > On 4/5/23 07:17, Uros Bizjak wrote:
> > > > Add generic and ta
From: Dave Hansen
> Sent: 05 April 2023 17:37
>
> On 4/5/23 07:17, Uros Bizjak wrote:
> > Add generic and target specific support for local{,64}_try_cmpxchg
> > and wire up support for all targets that use local_t infrastructure.
>
> I feel like I'm missing some context.
>
> What are the actual
From: Linuxppc-dev Arnd Bergmann
> Sent: 05 April 2023 21:32
>
> On Wed, Apr 5, 2023, at 22:00, H. Peter Anvin wrote:
> > On April 5, 2023 8:12:38 AM PDT, Niklas Schnelle
> > wrote:
> >>On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote:
> >>> We introduce a new HAS_IOPORT Kconfig option t
From: Arnd Bergmann
> Sent: 31 March 2023 11:39
...
> Most architectures that have write-through caches (m68k,
> microblaze) or write-back caches but no speculation (all other
> armv4/armv5, hexagon, openrisc, sh, most mips, later xtensa)
> only invalidate before DMA but not after.
>
> OTOH, most
From: Bjorn Helgaas
> Sent: 13 February 2023 21:38
>
> On Fri, Feb 10, 2023 at 02:33:23PM -0800, Ira Weiny wrote:
> > The CXL driver expects internal error reporting to be enabled via
> > pci_enable_pcie_error_reporting(). It is likely other drivers expect the
> > same.
> > Dave submitted a patc
From: Andrew Donnellan
> Sent: 27 January 2023 03:21
>
> On Thu, 2023-01-26 at 17:31 +0000, David Laight wrote:
> > Changing the size to kzalloc() doesn't help.
> > The alignment depends on the allocator and is only required to have
> > a relatively small alignmen
From: Segher Boessenkool
> Sent: 26 January 2023 17:19
>
> On Thu, Jan 26, 2023 at 12:09:53AM +1100, Michael Ellerman wrote:
> > Andrew Donnellan writes:
> > > A number of structures and buffers passed to PKS hcalls have alignment
> > > requirements, which could on occasion cause problems:
> > >
From: Segher Boessenkool
> Sent: 20 January 2023 10:54
...
> > > I suggest to file a bug against gcc complaining about a "spurious
> > > warning", and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is
> > > adapted to not emit the warning about the pointer division if the result
> > > is n
From: Arnaldo Carvalho de Melo
> Sent: 19 January 2023 17:00
>
> Em Thu, Jan 19, 2023 at 03:49:15PM +0000, David Laight escreveu:
> > From: Athira Rajeev
> > > Sent: 19 January 2023 14:27
> > ...
> > > The test script "tests/shell/buildid.sh" uses
From: Athira Rajeev
> Sent: 19 January 2023 14:27
...
> The test script "tests/shell/buildid.sh" uses some of the
> string substitution ways which are supported in bash, but not in
> "sh" or other shells. Above error on line number 69 that reports
> "Bad substitution" is:
Looks better - assuming i
From: Athira Rajeev
> Sent: 19 January 2023 11:31
...
> diff --git a/tools/perf/tests/shell/buildid.sh
> b/tools/perf/tests/shell/buildid.sh
> index aaf851108ca3..43e43e131be7 100755
> --- a/tools/perf/tests/shell/buildid.sh
> +++ b/tools/perf/tests/shell/buildid.sh
> @@ -66,7 +66,7 @@ check()
>
...
> > One thing that might be gnarly here is that I think you might not be
> > allowed to use up_read() to fully release ownership of an object -
> > from what I remember, I think that up_read() (unlike something like
> > spin_unlock()) can access the lock object after it's already been
> > acqui
From: Ingo Molnar
> Sent: 11 January 2023 09:54
>
> * Michal Hocko wrote:
>
> > On Tue 10-01-23 16:44:42, Suren Baghdasaryan wrote:
> > > On Tue, Jan 10, 2023 at 4:39 PM Davidlohr Bueso wrote:
> > > >
> > > > On Mon, 09 Jan 2023, Suren Baghdasaryan wrote:
> > > >
> > > > >This configuration var
From: James Bottomley
> Sent: 21 November 2022 14:03
...
> > Then how does the networking code handle the namespace stuff in
> > sysfs?
> > That seems to work today, or am I missing something?
>
> have you actually tried?
>
> jejb@lingrow:~> sudo unshare --net bash
> lingrow:/home/jejb # ls /sys/
From: Theodore Ts'o
> Sent: 17 November 2022 15:43
...
> The problem with "between", "ranged", "spanning" is that they don't
> tell the reader whether we're dealing with an "open interval" or a
> "closed interval". They are just different ways of saying that it's a
> range between, say, 0 and 20.
From: Tony Luck
> Sent: 21 October 2022 05:08
> When we do return to user mode the task is going to be busy servicing
> a SIGBUS ... so shouldn't try to touch the poison page before the
> memory_failure() called by the worker thread cleans things up.
What about an RT process on a busy system?
From: Joe Perches
> Sent: 12 October 2022 20:17
>
> On Wed, 2022-10-05 at 23:48 +0200, Jason A. Donenfeld wrote:
> > The prandom_u32() function has been a deprecated inline wrapper around
> > get_random_u32() for several releases now, and compiles down to the
> > exact same code. Replace the depre
From: Jason A. Donenfeld
> Sent: 07 October 2022 19:01
>
> The prandom_u32() function has been a deprecated inline wrapper around
> get_random_u32() for several releases now, and compiles down to the
> exact same code. Replace the deprecated wrapper with a direct call to
> the real function. The s
From: Jason A. Donenfeld
> Sent: 07 October 2022 19:01
>
> Rather than incurring a division or requesting too many random bytes for
> the given range, use the prandom_u32_max() function, which only takes
> the minimum required bytes from the RNG and avoids divisions.
>
...
> --- a/lib/cmdline_kun
From: Jason A. Donenfeld
> Sent: 07 October 2022 18:56
...
> > Given these kinds of less mechanical changes, it may make sense to split
> > these from the "trivial" conversions in a treewide patch. The chance of
> > needing a revert from the simple 1:1 conversions is much lower than the
> > need to
From: Christophe Leroy
> Sent: 06 October 2022 18:43
...
> But taking into account that sp must remain 16 bytes aligned, would it
> be better to do something like ?
>
> sp -= prandom_u32_max(PAGE_SIZE >> 4) << 4;
That makes me think...
If prandom_u32_max() is passed a (constant) power of 2
From: Nicholas Piggin
> Sent: 23 September 2022 16:42
>
> WARN_ONCE and similar are often used in frequently executed code, and
> should not crash the system. The program check interrupt caused by
> WARN_ON_ONCE can be a significant overhead even when nothing is being
> printed. This can cause perf
From: Stephen Hemminger
> Sent: 31 July 2022 20:06
> To: net...@vger.kernel.org
>
> Decnet is an obsolete network protocol that receives more attention
> from kernel janitors than users. It belongs in computer protocol
> history museum not in Linux kernel.
>
> It has been Orphaned in kernel since
...
> More directly, the reason we don't want to error is because the use case
> has fallbacks meant to handle errors. The cascade looks like this
> (quoting from the other email):
>
> unsigned long array[whatever];
> for (i = 0; i < ARRAY_SIZE(array);) {
> longs = arch_get_random_
From: Michael Ellerman
> Sent: 18 July 2022 05:41
...
> So we're memsetting all of args to 254, not zero.
>
> That's happening because allmodconfig with gcc 12 enables
> CONFIG_INIT_STACK_ALL_PATTERN, whereas gcc 11 doesn't.
I can't help feeling it would be better if that generated
a call to a me
From: Christophe Leroy
> Sent: 30 June 2022 10:40
>
> Le 30/06/2022 à 10:04, David Laight a écrit :
> > From: Michael Schmitz
> >> Sent: 29 June 2022 00:09
> >>
> >> Hi Arnd,
> >>
> >> On 29/06/22 09:50, Arnd Bergmann wrote:
> >
From: Michael Schmitz
> Sent: 29 June 2022 00:09
>
> Hi Arnd,
>
> On 29/06/22 09:50, Arnd Bergmann wrote:
> > On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz
> > wrote:
> >> On 28/06/22 19:03, Geert Uytterhoeven wrote:
> The driver allocates bounce buffers using kmalloc if it hits an
> >>
From: Sebastian Andrzej Siewior
> Sent: 14 June 2022 14:26
...
> > These changes seem to drop the priority from above that of the
> > highest priority RT process down to that of a default priority
> > user process.
> > There is no real guarantee that the latter will run 'any time soon'.
>
> Not su
From: Sebastian Andrzej Siewior
> Sent: 09 June 2022 16:03
>
> On 2022-05-30 16:15:11 [-0700], Davidlohr Bueso wrote:
> > Tasklets have long been deprecated as being too heavy on the system
> > by running in irq context - and this is not a performance critical
> > path. If a higher priority proces
From: Michael Ellerman
> Sent: 07 June 2022 03:05
>
> Bagas Sanjaya writes:
> > Hi,
> >
> > I'm trying to verify Drop ppc_inst_as_str() patch on [1] by performing
> > ppc64_defconfig build with powerpc64-unknown-linux-gnu-gcc (GCC 12.1.0).
> > The patch is applied on top of powerpc tree, next bra
From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > e
From: Maciej W. Rozycki
> Sent: 06 May 2022 14:15
> On Fri, 6 May 2022, David Laight wrote:
>
> > > The PCI configuration space was retrofitted into x86 systems (and is
> > > accessed in an awkward manner with them), but with a new design such a
> > > clean a
From: Maciej W. Rozycki
> Sent: 06 May 2022 13:27
>
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architecture th
> > Thanks for doing this implementation! One reason usercopy hardening
> > didn't persue doing a "full" stacktrace was because it seemed relatively
> > expensive. Did you do any usercopy-heavily workload testing to see if
> > there was a noticeable performance impact?
Look at anything that uses s
From: Kalle Valo
> Sent: 28 March 2022 10:29
>
> Larry Finger writes:
>
> > On 3/26/22 11:59, Benjamin Stürz wrote:
> >> This replaces comments with C99's designated
> >> initializers because the kernel supports them now.
> >>
> >> Signed-off-by: Benjamin Stürz
> >> ---
> >> drivers/net/wirel
From: Christophe Leroy
> Sent: 09 March 2022 07:56
...
> diff --git a/arch/powerpc/include/asm/checksum.h
> b/arch/powerpc/include/asm/checksum.h
> index 8321f6053a67..4b573a3b7e17 100644
> --- a/arch/powerpc/include/asm/checksum.h
> +++ b/arch/powerpc/include/asm/checksum.h
> @@ -38,14 +38,15 @@
From: Dan Carpenter
> Sent: 07 March 2022 15:01
>
> Updating this API is risky because some places rely on the old behavior
> and not all of them have been updated. Here are some additional places
> you might want to change.
I really can't help thinking that trying to merge this patch is
actuall
From: Xiaomeng Tong
> Sent: 03 March 2022 07:27
>
> On Thu, 3 Mar 2022 04:58:23 +0000, David Laight wrote:
> > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > The problem is the mis-use of iterator outside the loop on exit, and
> > > the iterator will b
From: Xiaomeng Tong
> Sent: 03 March 2022 02:27
>
> On Wed, 2 Mar 2022 14:04:06 +0000, David Laight
> wrote:
> > I think that it would be better to make any alternate loop macro
> > just set the variable to NULL on the loop exit.
> > That is easier to code for and t
From: Xiaomeng Tong
> Sent: 02 March 2022 09:31
>
> On Mon, 28 Feb 2022 16:41:04 -0800, Linus Torvalds
> wrote:
> >
> > But basically to _me_, the important part is that the end result is
> > maintainable longer-term.
>
> I couldn't agree more. And because of that, I stick with the following
> a
From: Linus Torvalds
> Sent: 01 March 2022 23:03
>
> On Tue, Mar 1, 2022 at 2:58 PM David Laight wrote:
> >
> > Can it be resolved by making:
> > #define list_entry_is_head(pos, head, member) ((pos) == NULL)
> > and double-checking that it isn't used anywhe
From: Linus Torvalds
> Sent: 01 March 2022 19:07
> On Mon, Feb 28, 2022 at 2:29 PM James Bottomley
> wrote:
> >
> > However, if the desire is really to poison the loop variable then we
> > can do
> >
> > #define list_for_each_entry(pos, head, member) \
> > for (pos
From: Christophe Leroy
> Sent: 01 March 2022 11:15
...
> Looks like ARM also does better code with the generic implementation as
> it seems to have some looking like conditional instructions 'rorne' and
> 'strne'.
In arm32 (and I think arm64) every instruction is conditional.
> static __always_in
From: Christophe Leroy
> Sent: 01 March 2022 10:20
>
> Le 13/02/2022 à 18:47, David Laight a écrit :
> > From: Segher Boessenkool
> >> Sent: 13 February 2022 09:16
> >
> >>
> >>> What happens on x86-64?
> >>>
> >&g
From: Matthew Wilcox
> Sent: 28 February 2022 20:16
>
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_ 'pos' t
From: Linus Torvalds
> Sent: 28 February 2022 19:56
> On Mon, Feb 28, 2022 at 4:19 AM Christian König
> wrote:
> >
> > I don't think that using the extra variable makes the code in any way
> > more reliable or easier to read.
>
> So I think the next step is to do the attached patch (which require
From: Guo Ren
> Sent: 28 February 2022 12:13
>
> On Mon, Feb 28, 2022 at 8:02 PM David Laight wrote:
> >
> > From: Guo Ren
> > > Sent: 28 February 2022 11:52
> > >
> > > On Mon, Feb 28, 2022 at 2:40 PM David Laight
> > > wrote:
&
From: Guo Ren
> Sent: 28 February 2022 11:52
>
> On Mon, Feb 28, 2022 at 2:40 PM David Laight wrote:
> >
> > From: guo...@kernel.org
> > > Sent: 27 February 2022 16:28
> > >
> > > From: Christoph Hellwig
> > >
> >
From: guo...@kernel.org
> Sent: 27 February 2022 16:28
>
> From: Christoph Hellwig
>
> Provide a single common definition for the compat_flock and
> compat_flock64 structures using the same tricks as for the native
> variants. Another extra define is added for the packing required on
> x86.
...
From: Kees Cook
> Sent: 24 February 2022 06:04
>
> Under CONFIG_HARDENED_USERCOPY=y, when exact stack frame boundary checking
> is not available (i.e. everything except x86 with FRAME_POINTER), check
> a stack object as being at least "current depth valid", in the sense
> that any object within th
From: Christoph Hellwig
> Sent: 18 February 2022 06:29
...
>
> > diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
> > index 15b058eefc4e..ee117fcf46ed 100644
> > --- a/arch/x86/kernel/stacktrace.c
> > +++ b/arch/x86/kernel/stacktrace.c
> > @@ -90,7 +90,7 @@ copy_stack_frame
1 - 100 of 618 matches
Mail list logo
