On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
> >> Or perhaps the MMU and caches can be turned off for the duration of the
> >> callback.
> >> I don't have the details of ARM MMUs and caches reloaded into my head
> >> yet. Maybe next week...
We've had these kinds of questions in t
On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> None of this is a deal-breaker for the kind of debugging tasks that are
> the primary use case for the callback.
Would you mind explaining what kind of tasks these callbacks will
be used for?
___
On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote:
> However, there's a lot of room for abuse here and I'm worried that if it
> becomes widespread, we'll start seeing vendors use that as a way to do
> some kind of HAL and hide various platform methods in there (clock
> control,
On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote:
> Last missing piece is being able to do "select FOO = n", which Stephen
> is currently working on.
I thought Linus' idea was to use:
KBUILD_KCONFIG=file make allnoconfig
in which case any option which would be presented to the user w
On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
> For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
> smart enough to notice and automatically enable CONFIG_MTD and
> CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
How do you sort out somet
functions sbi_console_putchar() and sbi_console_getchar().
> (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases)
>
> This series adds support for SBI debug console (DBCN) extension in KVM RISC-V
> and Linux RISC-V.
>
> [...]
Here is the summary with links:
- [v3,1
Hello:
This patch was applied to riscv/linux.git (fixes)
by Masahiro Yamada :
On Tue, 17 Oct 2023 19:37:39 +0900 you wrote:
> The '%.ko' rule in arch/*/Makefile.postlink does nothing but call the
> 'true' command.
>
> Remove the meaningless code.
>
> Signed-off-by: Masahiro Yamada
>
> [...]
Hello:
This series was applied to riscv/linux.git (for-next)
by Palmer Dabbelt :
On Wed, 29 Mar 2023 06:53:23 +0200 you wrote:
> After multiple attempts, this patchset is now based on the fact that the
> 64b kernel mapping was moved outside the linear mapping.
>
> The first patch allows to build
functions sbi_console_putchar() and sbi_console_getchar().
> (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases)
>
> This series adds support for SBI debug console (DBCN) extension in
> Linux RISC-V.
>
> [...]
Here is the summary with links:
- [v5
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton :
On Tue, 26 Dec 2023 13:46:10 -0800 you wrote:
> A test [1] in Android test suite started failing after [2] was merged.
> It turns out that after handling a major fault under per-VMA lock, the
> process major fault counter
functions sbi_console_putchar() and sbi_console_getchar().
> (Refer v2.0-rc5 at https://github.com/riscv-non-isa/riscv-sbi-doc/releases)
>
> This series adds support for SBI debug console (DBCN) extension in
> Linux RISC-V.
>
> [...]
Here is the summary with links:
- [v6
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton :
On Tue, 14 Nov 2023 17:16:56 +0800 you wrote:
> Justification:
> ==
> Kexec_load interface has been doing top down searching and loading
> kernel/initrd/purgtory etc to prepare for kexec reboot. In that way,
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton :
On Wed, 15 Nov 2023 21:00:27 +0800 you wrote:
> This function, being a variant of walk_system_ram_res() introduced in
> commit 8c86e70acead ("resource: provide new functions to walk through
> resources"), walks through a
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton :
On Wed, 13 Dec 2023 13:57:40 +0800 you wrote:
> Currently, specifying '-d' on kexec command will print a lot of debugging
> informationabout kexec/kdump loading with kexec_load interface.
>
> However, kexec_file_load pr
Hello:
This patch was applied to riscv/linux.git (fixes)
by Palmer Dabbelt :
On Wed, 14 Feb 2024 07:34:30 -0800 you wrote:
> From: Palmer Dabbelt
>
> The new SBI console has the same problem as the old one: there's only
> one shared backing hardware and no synchronization, so the two drivers
>
Hello:
This series was applied to riscv/linux.git (for-next)
by Andrew Morton :
On Fri, 13 Jan 2023 18:10:00 +0100 you wrote:
> This is the follow-up on [1]:
> [PATCH v2 0/8] mm: COW fixes part 3: reliable GUP R/W FOLL_GET of
> anonymous pages
>
> After we implemented __HAVE_ARCH_PTE
Hello:
This patch was applied to riscv/linux.git (for-next)
by Andrew Morton :
On Tue, 3 Jan 2023 16:27:32 -0800 you wrote:
> zap_page_range was originally designed to unmap pages within an address
> range that could span multiple vmas. While working on [1], it was
> discovered that all callers
Hello:
This patch was applied to riscv/linux.git (fixes)
by Andrew Morton :
On Mon, 22 Jan 2024 22:43:05 -0800 you wrote:
> The change [1] missed ARM architecture when fixing major fault accounting
> for page fault retry under per-VMA lock. Add missing code to fix ARM
> architecture fault account
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton :
On Mon, 29 Jan 2024 13:46:34 +0100 you wrote:
> Now that the rmap overhaul[1] is upstream that provides a clean interface
> for rmap batching, let's implement PTE batching during fork when processing
> PTE-mapped THPs.
>
Hello:
This series was applied to riscv/linux.git (fixes)
by Andrew Morton :
On Thu, 25 Jan 2024 15:55:06 -0700 you wrote:
> Hi all,
>
> This series bumps the minimum supported version of LLVM for building the
> kernel to 13.0.1. The first patch does the bump and all subsequent
> patches clean u
Hello:
This patch was applied to riscv/linux.git (fixes)
by Masami Hiramatsu (Google) :
On Wed, 1 May 2024 09:29:56 -0700 you wrote:
> If an error happens in ftrace, ftrace_kill() will prevent disarming
> kprobes. Eventually, the ftrace_ops associated with the kprobes will be
> freed, yet the kp
On Wed, Feb 27, 2008 at 05:04:41PM -0700, Bjorn Helgaas wrote:
> Move bridge enable from pcibios_enable_resources() to
> platform_pci_enable_device() so the former matches other
> architectures and can be shared.
>
> Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
>
> Index: work6/arch/arm/kerne
On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote:
> Ingo and Steven,
>
> Here's an updated version of the arch/arm changes for dynamic ftrace
> based on top of your latest tip/master.
Excuse me if I'm rather confused, but...
When ftrace for ARM was originally
On Mon, Mar 06, 2017 at 11:37:20PM +0530, Naveen N. Rao wrote:
> On 2017/02/08 01:24AM, Naveen N Rao wrote:
> > ... as the weak variant will do.
> >
> > Signed-off-by: Naveen N. Rao
> > ---
> > arch/arm/probes/kprobes/core.c | 10 --
> > arch/arm64/kernel/probes/kprobes.c | 6 --
BOn Thu, Jun 08, 2017 at 03:25:50PM +0200, Christoph Hellwig wrote:
> +static int dmabounce_mapping_error(struct device *dev, dma_addr_t dma_addr)
> +{
> + if (dev->archdata.dmabounce)
> + return 0;
I'm not convinced that we need this check here:
dev->archdata.dmabounce =
f the address space is unused.
With existing kernels on ARM:
0001-00017000 r-xp 08:01 270810 /bin/cat
00026000-00027000 r--p 6000 08:01 270810 /bin/cat
00027000-00028000 rw-p 7000 08:01 270810 /bin/cat
7f661000-7f679000 r-xp 08:01 281659
/lib/arm-linu
On Mon, Nov 13, 2017 at 10:20:06AM +0100, Michal Hocko wrote:
> [Cc arm and ppc maintainers]
>
> Thanks a lot for testing!
>
> On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote:
> > > Hi Joel,
> > >
> > > On Wed 08-11-17 15:20:50, Michal Hocko
On Mon, Nov 13, 2017 at 03:11:40PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 10:20:06, Michal Hocko wrote:
> > [Cc arm and ppc maintainers]
> >
> > Thanks a lot for testing!
> >
> > On Sun 12-11-17 11:38:02, Joel Stanley wrote:
> > > On Fri, Nov 10, 2017 at 11:00 PM, Michal Hocko wrote:
> > >
On Mon, Nov 13, 2017 at 04:16:41PM +0100, Michal Hocko wrote:
> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
> > Yes, I have mentioned that in the previous email but the amount of code
> > would be even larger. Basically every arch which reimplements
> > arch_get_unmapped_area would have t
On Mon, Jan 09, 2017 at 12:33:02PM +0100, Arnd Bergmann wrote:
> On Friday, January 6, 2017 10:43:53 AM CET Nicolas Dichtel wrote:
> >
> > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> > index a53cdb8f068c..c48fee3d7b3b 100644
> > --- a/arch/arm/include/asm/types.h
> >
On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
> diff --git a/arch/arm/include/uapi/asm/Kbuild
> b/arch/arm/include/uapi/asm/Kbuild
> index 46a76cd6acb6..607f702c2d62 100644
> --- a/arch/arm/include/uapi/asm/Kbuild
> +++ b/arch/arm/include/uapi/asm/Kbuild
> @@ -1,23 +1,6 @@
> #
On Fri, Jan 13, 2017 at 05:01:01PM +0100, Nicolas Dichtel wrote:
> Please, do not remove the email subject when you reply. I restore it to
> ease the thread follow-up.
I mentioned it to David, and he says it's because the long list of
recipients is breaking his mailer. I've already posed the ques
y to build
> with
> - * -ffreestanding and include 'stdint.h' (such as when you include
> 'arm_neon.h'
> - * in order to use NEON intrinsics)
> - *
> - * As the typedefs for these types in 'stdint.h' are based on builtin defines
> - * supplied by
amin Herrenschmidt
> Cc: Chris Metcalf
> Cc: David Woodhouse
> Cc: linux-a...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Paul Mackerras
> Cc: Russell King
Acked-by: Russell Kin
On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote:
> diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
> index 6795368ad023..cc414382dab4 100644
> --- a/arch/arm/include/asm/futex.h
> +++ b/arch/arm/include/asm/futex.h
> @@ -128,20 +128,10 @@ futex_atomic_cmpxchg_ina
On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > Now only those architectures that have custom initrd free requirements
> > need to define free_initrd_mem.
> ...
> > --- a/arch/arc/mm/init.c
> > +++ b/arch/arc/mm/init.c
> > @@ -229,10 +229,
On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>
>
> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >>> Now only those a
On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrot
On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> On Thu, Mar 29, 2018 at 5:27 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Mar 29, 2018 at 09:37:52AM +1100, Oliver wrote:
> >> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> >>
On Thu, Mar 29, 2018 at 11:39:24AM -0500, Rob Landley wrote:
>
>
> On 03/28/2018 05:14 PM, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux
On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> On Thu, 29 Mar 2018 16:58:27 +0100,
> Russell King - ARM Linux wrote:
> >
> > On Thu, Mar 29, 2018 at 05:43:47PM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Mar 29, 2018 at 5:27 PM, Russell Ki
On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> A similar commit v4.16-rc1~159^2~37
> ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have
> introduced a similar ABI regression to compat arm.
So, could you explain how can this change cause a regression?
+#define
On Thu, Apr 12, 2018 at 02:03:14PM +0300, Dmitry V. Levin wrote:
> On Thu, Apr 12, 2018 at 10:58:11AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> > > A similar commit v4.16-rc1~159^2~37
> > > ("sig
On Thu, Apr 12, 2018 at 03:49:28PM +0300, Dmitry V. Levin wrote:
> The "KERNEL BUG" diagnostics I was talking about was added to strace yesterday
> as a part of workaround commit, see
> https://github.com/strace/strace/commit/34c7794cc16e2511eda7b1d5767c655a83b17309
> Before that change the test ju
On Thu, Apr 12, 2018 at 09:50:26AM -0700, Linus Torvalds wrote:
> Does this attached patch perhaps fix the ARM case?
>
> It just uses FPE_FLTUNK as the default si_code for SIGFPE, which seems
> sane enough. And then gets rid of FPE_FIXME, which should resolve the
> nasty case.
>
> Hmm? Entirely u
On Thu, Apr 12, 2018 at 10:22:15AM -0700, Linus Torvalds wrote:
> On Thu, Apr 12, 2018 at 10:20 AM, Russell King - ARM Linux
> wrote:
> >
> > This file was created to contain FPE_FIXME, by the "signal/arm: Document
> > conflicts with SI_USER and SIGFPE"
On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote:
> On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote:
> > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux
> > wrote:
> > >
> > > Yes, it does solve the problem at hand with strace
On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote:
> If that's the case though, I don't see how a userspace testsuite is
> hitting this code path. Maybe I've misunderstood the context of this
> thread.
It isn't hitting this exact case.
The userspace testsuite is hitting an entirely dif
On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote:
> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote:
> >
> > Most uses I've seen do nothing more than use the FPE_xyz value to
> > format diagnostic messages while dying. I struggled to find code that
> > made a meaningful function
. By default this is the same as cpu_relax on all architectures.
Rather than having to update all these architectures in this way, can't
we put in some linux/*.h header something like:
#ifndef cpu_relax_yield
#define cpu_relax_yield() cpu_relax()
#endif
so only those architectures that need to do someth
On Tue, Nov 15, 2016 at 02:19:53PM +0100, Christian Borntraeger wrote:
> On 11/15/2016 01:30 PM, Russell King - ARM Linux wrote:
> > On Tue, Oct 25, 2016 at 11:03:11AM +0200, Christian Borntraeger wrote:
> >> For spinning loops people do often use barrier() or cpu_rela
e/asm/processor_32.h | 1 -
> arch/sparc/include/asm/processor_64.h | 1 -
> arch/tile/include/asm/processor.h | 2 --
> arch/unicore32/include/asm/processor.h | 1 -
> arch/x86/include/asm/processor.h| 2 --
> arch/x86/um/asm/processor.h | 1 -
>
On Tue, May 31, 2016 at 04:19:31PM +0200, Krzysztof Kozlowski wrote:
> Remove __init annotation from all of console->setup implementations
> because:
> 1. The pointer to it is stored in a struct console which is not
>marked with __initdata.
> 2. It is referenced by register_console() from kerne
On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
> I'm not an expert on DTB, so I can't provide an example of code
> execution, but you have already mentioned the /chosen/linux,stdout-path
> property. If an attacker redirects the bootloader to an insecure
>
On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
> Russell King - ARM Linux writes:
> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
> >> I'm not an expert on DTB, so I can't provide an example of code
> >> execution, but you hav
On Wed, Jul 13, 2016 at 09:47:56AM +0200, Ard Biesheuvel wrote:
> On 13 July 2016 at 09:36, Russell King - ARM Linux
> wrote:
> > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
> >> Russell King - ARM Linux writes:
> >> > On Tue, Jul 12, 2016
On Wed, Jul 13, 2016 at 05:55:33PM +1000, Stewart Smith wrote:
> Russell King - ARM Linux writes:
> > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
> >> Russell King - ARM Linux writes:
> >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tes
On Wed, Jul 13, 2016 at 09:03:38AM -0400, Vivek Goyal wrote:
> On Wed, Jul 13, 2016 at 09:26:39AM +0100, Russell King - ARM Linux wrote:
> > Indeed - maybe Eric knows better, but I can't see any situation where
> > the dtb we load via kexec should ever affect "the bo
On Wed, Jul 13, 2016 at 03:13:42PM +0200, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 10:41:28 AM CEST Mark Rutland wrote:
> > The big question is whether this is a realistic case on a secure boot
> > system.
>
> What does x86 do here? I assume changes to the command line are also
> limited
On Fri, Jul 15, 2016 at 09:26:10AM -0400, Vivek Goyal wrote:
> On Fri, Jul 15, 2016 at 09:31:02AM +0200, Arnd Bergmann wrote:
> > I think that helps, as it makes the problem space correspond to that
> > of modifying the command line, but I can still come up with countless
> > attacks based on modif
On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote:
> > IOW, if your kernel forced signature verification, you should not be
> > able to do sig_enforce=0. If you kernel did not have
> > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway
> > and you are not making it
#x27; and no one has actually thought about why.
> That ioctl() works is (probably) even more lucky.
>
> There are ABI that use different calling conventions for varags functions
> (eg always stack all the arguments). I guess linux doesn't run on any of them.
>
> ioctl() is a p
On Fri, Aug 19, 2016 at 10:59:01AM +0530, Ravi Bangoria wrote:
> -static struct ins instructions[] = {
> +static struct ins instructions_x86[] = {
> { .name = "add", .ops = &mov_ops, },
> { .name = "addl", .ops = &mov_ops, },
> { .name = "addq", .ops = &mov_ops, },
>
On Fri, Aug 19, 2016 at 04:09:51PM +0530, Ravi Bangoria wrote:
> Thanks Russell for reviewing.
>
> On Friday 19 August 2016 01:20 PM, Russell King - ARM Linux wrote:
> > On Fri, Aug 19, 2016 at 10:59:01AM +0530, Ravi Bangoria wrote:
> >> -static struct ins instructions[]
On Tue, Sep 06, 2016 at 08:33:20PM -0300, Thiago Jung Bauermann wrote:
> Thanks for reporting the problem and finding the commit that caused it.
> The only thing in commit 5c01cdd2d4bc which can affect kexec_load is the
> fact that struct kexec_segment has a new member.
>
> This is probably break
Hello:
This pull request was applied to riscv/linux.git (fixes)
by Linus Torvalds :
On Wed, 24 Jul 2024 23:00:14 +0200 you wrote:
> Linus
>
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as they would reside in .rodata. To get
> there, the proc_
Hello:
This pull request was applied to riscv/linux.git (for-next)
by Linus Torvalds :
On Wed, 24 Jul 2024 23:00:14 +0200 you wrote:
> Linus
>
> Constifying ctl_table structs will prevent the modification of
> proc_handler function pointers as they would reside in .rodata. To get
> there, the pr
Hello:
This series was applied to riscv/linux.git (fixes)
by Thomas Gleixner :
On Wed, 4 Dec 2024 14:20:01 + you wrote:
> This patch series focuses on improving the machine_kexec_mask_interrupts()
> function by consolidating its implementation and optimizing its behavior to
> avoid redundant
Hello:
This series was applied to riscv/linux.git (fixes)
by Thomas Gleixner :
On Thu, 10 Oct 2024 09:01:02 +0200 you wrote:
> Historically each architecture defined their own datapage to store the
> VDSO data. This stands in contrast to the generic nature of the VDSO
> code itself.
> We plan to
Hello:
This patch was applied to riscv/linux.git (fixes)
by Steven Rostedt (Google) :
On Thu, 10 Oct 2024 20:21:14 -0400 you wrote:
> From: Steven Rostedt
>
> Most architectures use pt_regs within ftrace_regs making a lot of the
> accessor functions just calls to the pt_regs internally. Instead
Hello:
This series was applied to riscv/linux.git (fixes)
by Steven Rostedt (Google) :
On Tue, 08 Oct 2024 19:05:27 -0400 you wrote:
> This is based on:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git/
> ftrace/for-next
>
> ftrace_regs w
Hello:
This series was applied to riscv/linux.git (fixes)
by Arnd Bergmann :
On Wed, 23 Oct 2024 07:36:36 +0200 you wrote:
> page_to_phys is duplicated by all architectures, and from some strange
> reason placed in where it doesn't fit at all.
>
> phys_to_page is only provided by a few architec
Hello:
This patch was applied to riscv/linux.git (fixes)
by Michael Ellerman :
On Sun, 3 Nov 2024 16:05:52 +0800 you wrote:
> seq_printf is costy, when stress reading /proc/interrupts, profiling indicates
> seq_printf takes about ~47% of show_interrupts samples:
>
> show_interrupts(94.495%
Hello:
This patch was applied to riscv/linux.git (fixes)
by Arnd Bergmann :
On Tue, 29 Oct 2024 08:48:58 +0100 you wrote:
> After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
> return void") .remove() is (again) the right callback to implement for
> platform drivers.
>
> Conver
Hello:
This patch was applied to riscv/linux.git (fixes)
by Rob Herring (Arm) :
On Wed, 23 Oct 2024 18:14:26 +0100 you wrote:
> __pa() is only intended to be used for linear map addresses and using
> it for initial_boot_params which is in fixmap for arm64 will give an
> incorrect value. Hence sav
Hello:
This series was applied to riscv/linux.git (for-next)
by Paolo Bonzini :
On Mon, 24 Feb 2025 15:55:35 -0800 you wrote:
> This was _supposed_ to be a tiny one-off patch to fix a nVMX bug where KVM
> fails to detect that, after nested VM-Exit, L1 has a pending IRQ (or NMI).
> But because x86
Hello:
This patch was applied to riscv/linux.git (fixes)
by Masahiro Yamada :
On Tue, 3 Jun 2025 03:12:54 +0900 you wrote:
> The extra-y syntax is deprecated. Instead, use always-$(KBUILD_BUILTIN),
> which behaves equivalently.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/alpha/kernel/M
On Fri, Mar 22, 2019 at 10:30:08AM -0400, Waiman Long wrote:
> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
> it generate slightly better code.
>
> Before this patch, down_read_trylock:
>
>0x <+0>: callq 0x5
>0x0005 <+5>: jm
On Fri, Apr 03, 2020 at 01:58:31AM +0100, Al Viro wrote:
> On Thu, Apr 02, 2020 at 11:35:57AM -0700, Kees Cook wrote:
>
> > Yup, I think it's a weakness of the ARM implementation and I'd like to
> > not extend it further. AFAIK we should never nest, but I would not be
> > surprised at all if we di
On Thu, Apr 02, 2020 at 11:35:57AM -0700, Kees Cook wrote:
> On Thu, Apr 02, 2020 at 06:50:32PM +0100, Al Viro wrote:
> > On Thu, Apr 02, 2020 at 07:03:28PM +0200, Christophe Leroy wrote:
> >
> > > user_access_begin() grants both read and write.
> > >
> > > This patch adds user_read_access_begin(
0 1,0 Read-only No access
00 0,1 Read-only Read-only
00 1,1 Unpredictable Unpredictable
01 X,X Read/Write No access
10 X,X Read/Write Read-only
11
On Wed, Oct 23, 2019 at 08:52:33AM -0500, Rob Herring wrote:
> On Wed, Oct 23, 2019 at 1:41 AM Benjamin Herrenschmidt
> wrote:
> >
> > On Wed, 2019-10-23 at 16:42 +1100, Michael Ellerman wrote:
> > >
> > > Right, it seems of_dma_is_coherent() has baked in the assumption that
> > > devices are non-
On Wed, Oct 23, 2019 at 08:52:33AM -0500, Rob Herring wrote:
> > I think this should have been done the other way around and default to
> > coherent since most traditional OF platforms are coherent, and you
> > can't just require those DTs to change.
>
> You can blame me. This was really only inte
On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote:
> I suppose I'm surprised there are backtraces that are not important.
> Either badness happened and it needs printing, or the user asked for it
> and it needs printing.
Or utterly meaningless.
> Perhaps we should be removing backtra
On Fri, Nov 08, 2019 at 04:28:30PM +, Dmitry Safonov wrote:
> On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> > On Wed, Nov 06, 2019 at 04:27:33PM +, Dmitry Safonov wrote:
> [..]
> >> Sorry, I should have tried to describe better.
> >>
> >> I'm trying to remove external users of console_logleve
On Wed, Apr 08, 2020 at 01:58:58PM +0200, Christoph Hellwig wrote:
> Hi all,
>
> Peter noticed that with some dumb luck you can toast the kernel address
> space with exported vmalloc symbols.
>
> I used this as an opportunity to decruft the vmalloc.c API and make it
> much more systematic. This
On Wed, Apr 08, 2020 at 08:58:16PM +0200, Arnd Bergmann wrote:
> A 1024 byte variable on the stack will warn on any 32-bit architecture
> during compile-testing, and is generally a bad idea anyway:
>
> fsl/dpio/dpio-service.c: In function
> 'dpaa2_io_service_enqueue_multiple_desc_fq':
> fsl/dpio/
On Tue, Apr 21, 2020 at 03:49:19AM +0100, Al Viro wrote:
> The only source I'd been able to find speeks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in q
On Tue, Aug 06, 2019 at 05:45:03PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Aug 06, 2019 at 05:08:54PM +0100, Will Deacon wrote:
> > On Sat, Aug 03, 2019 at 08:48:12AM +0200, Christoph Hellwig wrote:
> > > On Fri, Aug 02, 2019 at 11:38:03AM +0100,
tecture
> > > doesn't have
> > > anything called "write combine", so in Linux we instead provide what the
> > > Arm
> > > architecture calls "Normal non-cacheable" memory for
> > > pgprot_writecombine().
> > > Amongst ot
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for c
On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> >
> > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > > - Once we get to 512, we clash with the x32 n
On Fri, Jan 25, 2019 at 03:43:59PM +, Catalin Marinas wrote:
> On Fri, Jan 18, 2019 at 05:18:13PM +0100, Arnd Bergmann wrote:
> > diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> > index 86de9eb34296..20ed7e026723 100644
> > --- a/arch/arm/tools/syscall.tbl
> > +++ b/arch/
gt; > > > [if your patch is applied to the wrong git tree, please drop us a
> > > > > note to help
> > > > > improve the system. BTW, we also suggest to use '--base' option to
> > > > > specify the
> > > > > base
On Mon, Feb 10, 2020 at 11:46:23AM +0100, Christophe Leroy wrote:
>
>
> Le 10/02/2020 à 11:02, Russell King - ARM Linux admin a écrit :
> > On Mon, Feb 10, 2020 at 07:38:38AM +0100, Christophe Leroy wrote:
> > >
> > >
> > > Le 10/
On Tue, Feb 11, 2020 at 06:33:47AM +0100, Christophe Leroy wrote:
>
>
> Le 11/02/2020 à 03:25, Anshuman Khandual a écrit :
> >
> >
> > On 02/10/2020 04:36 PM, Russell King - ARM Linux admin wrote:
> > > There are good reasons for the way ARM does stuff.
On Sun, Feb 16, 2020 at 10:18:30AM +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
>
> These patches convert several architectures to use page table folding and
> remove __ARCH_HAS_5LEVEL_HACK along with include/asm-generic/5level-fixup.h.
>
> The changes are mostly about mechanical r
I'm sorry, I can't apply this, it produces loads of:
include/linux/error-injection.h:7:10: fatal error: asm/error-injection.h: No
such file or directory
Since your patch 1 has been merged by the ARM64 people, I can't take
it until next cycle.
On Mon, Aug 19, 2019 at 05:18:08PM
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might
On 19.11.23 00:45, Timothy Pearson wrote:
> During floating point and vector save to thread data fr0/vs0 are clobbered
> by the FPSCR/VSCR store routine. This leads to userspace register corruption
> and application data corruption / crash under the following rare condition:
> [...]
> Tested-by: T
201 - 300 of 346 matches
Mail list logo
