On 01.06.24 08:34, Greg KH wrote:
> On Fri, May 31, 2024 at 12:16:50PM +0200, Greg KH wrote:
>> On Fri, May 31, 2024 at 12:02:15PM +0200, Greg KH wrote:
>>> On Fri, May 31, 2024 at 11:19:34AM +0200, Thorsten Leemhuis wrote:
Thx, I already had an eye on this, but thought tracking would not be
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
On 20.05.24 17:15, Christoph Hellwig wrote:
> Adding ben and the linuxppc list.
Hmm, no reply and no other progress to get this resolved afaics. So lets
bring
From: "Dr. David Alan Gilbert"
'cgr_comp' has been unused since
commit 96f413f47677 ("soc/fsl/qbman: fix issue in
qman_delete_cgr_safe()").
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/soc/fsl/qbman/qman.c | 5 -
1 file changed, 5 deletions(-)
diff --git
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
From: "Dr. David Alan Gilbert"
The last function to reference module_bug_list went in 2008's
commit b9754568ef17 ("powerpc: Remove dead module_find_bug code")
but I don't think that was called since 2006's
commit 73c9ceab40b1 ("[POWERPC] Generic BUG for powerpc")
Now that the list has gone,
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
Was this regression ever resolved? Doesn't look like it, but maybe I
just missed something.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat
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
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 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
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 (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
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 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,
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:
-
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
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:
-
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:
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
>
> [...]
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:
- [
[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 have
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a
On 18.07.23 18:15, Randy Dunlap wrote:
> On 7/18/23 04:48, Michael Ellerman wrote:
>> Bagas Sanjaya writes:
>>> On Thu, Jul 13, 2023 at 09:11:10AM -0700, Randy Dunlap wrote:
>>>> on ppc64:
>>>>
>>>> In file included from ../include/linux/d
On 19.07.23 18:19, Linux regression tracking #adding (Thorsten Leemhuis)
wrote:
> On 17.07.23 16:45, Sachin Sant wrote:
>> Kdump seems to be broken with 6.5 for ppc64le.
>> [...]
>>
>> 6.4 was good. Git bisect points to following patch
>>
>> commit 6
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a
[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 have
Michael, thx for looking into this!
On 18.07.23 13:48, Michael Ellerman wrote:
> Bagas Sanjaya writes:
>> On Thu, Jul 13, 2023 at 09:11:10AM -0700, Randy Dunlap wrote:
>>> on ppc64:
>>>
>>> In file included from ../include/linux/device.h:15,
>>>
gt;>> there :)
>>>
>>> I'm in wait-a-few-days-mode on this. To see if we have a backportable
>>> fix rather than disabling the feature in -stable.
Andrew, how long will you remain in "wait-a-few-days-mode"? Given what
Greg said below and that we already h
t;> + count_vm_vma_lock_event(VMA_LOCK_RETRY);
>
> This is apparently not strong enough as it causes go build failures like:
TWIMC & for the record: there is another report about trouble caused by
this change; for details see
https://bugzilla.kernel.org/show_bug.cgi?id=217624
An
the same commit that causes build problems with go:
https://lore.kernel.org/all/dbdef34c-3a07-5951-e1ae-e9c6e3cdf...@kernel.org/
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtra
happens in 1-3 out of 20
> builds only.
>
> If I revert the commit on top of 6.4, they all dismiss. Any idea?
>
> The downstream report:
> https://bugzilla.suse.com/show_bug.cgi?id=1212775
> [...]
Thanks for the report. To be sure the issue doesn't fall through the
cracks u
Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
for once, to make this easily accessible to everyone.
As Linus will likely release 6.4 on this or the following Sunday a quick
question: is there any hope this regression might be fixed any time
soon? Doesn't look like
[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 have
o, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
On 08.05.23 14:58, Bagas Sanjaya wrote:
> On Mon, May 08, 2023 at 01:29:22PM +0200, Linux regression tracking #adding
> (Thorsten Leemhuis) wrote:
>> [CCing the regression list, as it should be in the loop for regressions:
>> https://docs.kernel.org/admin-guide/reportin
On 08.05.23 14:49, Michael Ellerman wrote:
> "Linux regression tracking #adding (Thorsten Leemhuis)"
> writes:
>> [CCing the regression list, as it should be in the loop for regressions:
>> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>>
[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 have
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
or the rest of this mail:
[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 have encountered already in similar form.
See link in footer if these mails annoy you.]
Thanks for the report. To be
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
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
[TLDR: This mail in primarily relevant for Linux regression tracking. A
change or fix related to the regression discussed in this thread was
posted or applied, but it did not use a Link: tag to point to the
report, as Linus and the documentation call for. Things happen, no
worries -- but now
[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 have encountered already in similar form.
See link in footer if these mails annoy you.]
[CCing the regression list, as it should be in the loop
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 22.12.22 12:24, Thorsten Leemhuis wrote:
> On 22.12.22 11:42, Christian Zigotzky wrote:
>>
>> The Nemo board [1] doesn't reboot anymore since the f
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; all text you find below is based on a few templates
paragraphs you might have encountered already already in similar form.
See link in footer if these mails annoy you.]
On 01.01.23 15:18, Christian Zigotzky wrote
From: Guilherme G. Piccoli Sent: Friday, April 29, 2022
3:35 PM
>
> Hi Michael, first of all thanks for the great review, much appreciated.
> Some comments inline below:
>
> On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> > [...]
> >> hypervisor I/O completio
From: Guilherme G. Piccoli Sent: Friday, April 29, 2022
11:04 AM
>
> On 29/04/2022 14:30, Michael Kelley (LINUX) wrote:
> > From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> > 2022
> 3:49 PM
> >> [...]
> >>
> >> @@ -2843
From: Guilherme G. Piccoli Sent: Friday, April 29, 2022
1:38 PM
>
> On 29/04/2022 14:53, Michael Kelley (LINUX) wrote:
> > From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> > 2022
> 3:49 PM
> >> [...]
> >> + panic_notifiers_level=
> >>
ed in the first patch of the series (and
> it's a bug present even before this refactor).
>
> * Notice we didn't add a sysrq for panic notifiers level - should have it?
> Alejandro proposed recently to add a sysrq for "crash_kexec_post_notifiers",
&g
g-heartbeat.c | 4 ++--
> drivers/misc/bcm-vk/bcm_vk_dev.c | 6 +++---
> drivers/misc/pvpanic/pvpanic.c | 4 ++--
> drivers/power/reset/ltc2952-poweroff.c | 4 ++--
> drivers/s390/char/zcore.c| 5 +++--
> drivers/soc/bcm/brcmstb/pm/pm-arm.c | 2 +-
>
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently Hyper-V guests are among the most relevant users of the panic
> infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
> both in cleaning-up procedures (closing a hypervisor <-> guest connection,
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently we have a debug infrastructure in the notifiers file, but
> it's very simple/limited. This patch extends it by:
>
> (a) Showing all registered/unregistered notifiers' callback names;
>
> (b) Adding a dynamic
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. This makes sense, since we're turning off
> such CPUs,
| 15 ++-----
> drivers/xen/swiotlb-xen.c | 4 +--
> include/linux/swiotlb.h| 15 ++-
> include/trace/events/swiotlb.h | 29 -
> kernel/dma/swiotlb.c | 35 ++
> 15 files changed, 55
From: Dongli Zhang Sent: Friday, March 4, 2022 10:28
AM
>
> Hi Michael,
>
> On 3/4/22 10:12 AM, Michael Kelley (LINUX) wrote:
> > From: Christoph Hellwig Sent: Tuesday, March 1, 2022 2:53 AM
> >>
> >> Power SVM wants to allocate a swiotlb buffer that i
arch/powerpc/platforms/pseries/svm.c | 26 +-
> include/linux/swiotlb.h | 1 +
> kernel/dma/swiotlb.c | 9 +++--
> 7 files changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/svm.h b/arch/powerpc/incl
From: Christoph Hellwig Sent: Monday, February 28, 2022 3:31 AM
>
> On Mon, Feb 28, 2022 at 02:53:39AM +, Michael Kelley (LINUX) wrote:
> > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31
> > AM
> > >
> > > Pass a bool to pass
gt; arch/x86/kernel/pci-dma.c | 15 ++-
> arch/x86/mm/mem_encrypt_amd.c | 3 ---
> drivers/xen/swiotlb-xen.c | 4 +--
> include/linux/swiotlb.h| 15 ++-
> include/trace/events/swiotlb.h | 29 -
thanks for trying. I'll have a look again with brain awake tomorrow
> >> morning.
> >
> > Morning was busy with other things, but I found what my sleepy brain
> > managed to do wrong yesterday evening.
> >
> > Let me reintegrate the pile and I'll send you an up
On Sat, Apr 10, 2021 at 03:06:52PM +0100, Matthew Wilcox wrote:
> How about moving the flags into the union? A bit messy, but we don't
> have to play games with __packed__.
Yes, that is probably the better solution, avoiding the games to try
and get the union appropriately placed on 32-bit
On Wed, Mar 17, 2021 at 09:52:10AM +0800, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen
> Signed-off-by: Kefeng Wang
Acked-by: Russell King # for
On Mon, Mar 22, 2021 at 06:10:01PM +0100, Cye Borg wrote:
> PWS 500au:
>
> snow / # lspci -vvx -s 7.1
> 00:07.1 IDE interface: Contaq Microsystems 82c693 (prog-if 80 [ISA
> Compatibility mode-only controller, supports bus mastering])
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV-
On Mon, Mar 22, 2021 at 04:33:14PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote:
> > On Mon, Mar 22, 2021 at 03:15:03PM +, Russell King - ARM Linux admin
> > wrote:
> > > It gets worse than that though - d
On Mon, Mar 22, 2021 at 05:09:13PM +0100, John Paul Adrian Glaubitz wrote:
> On 3/22/21 4:15 PM, Russell King - ARM Linux admin wrote:
> > I'm quite surprised that the CY82C693 even works on Alpha - I've
> > asked for a lspci for that last week but nothing has yet been
> > for
On Mon, Mar 22, 2021 at 04:18:23PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 03:15:03PM +, Russell King - ARM Linux admin
> wrote:
> > It gets worse than that though - due to a change to remove
> > pcibios_min_io from the generic code, moving it into the AR
On Mon, Mar 22, 2021 at 03:54:03PM +0100, Christoph Hellwig wrote:
> On Fri, Mar 19, 2021 at 05:53:12PM +, Russell King - ARM Linux admin
> wrote:
> > If I extend the arch/arm/kernel/bios32.c code to kill BARs 2/3 (which
> > actually are not present on the CY82C693) then th
On Fri, Mar 19, 2021 at 05:07:53PM +, Russell King - ARM Linux admin wrote:
> On Thu, Mar 18, 2021 at 05:56:58AM +0100, Christoph Hellwig wrote:
> > footbridge_defconfig enables CONFIG_IDE but no actual host controller
> > driver, so just drop it.
>
> I have been using t
On Thu, Mar 18, 2021 at 05:56:58AM +0100, Christoph Hellwig wrote:
> footbridge_defconfig enables CONFIG_IDE but no actual host controller
> driver, so just drop it.
I have been using the Cypress 82C693 IDE driver on Footbridge for a
CD ROM drive, and I know it doesn't work with the PATA driver -
On Tue, Feb 02, 2021 at 07:47:04PM +0800, Ding Tianhong wrote:
> On 2021/2/2 19:13, Russell King - ARM Linux admin wrote:
> > On Tue, Feb 02, 2021 at 09:05:02PM +1000, Nicholas Piggin wrote:
> >> diff --git a/arch/arm/include/asm/pgtable.h
> >> b/arch/arm/inclu
On Tue, Feb 02, 2021 at 09:05:02PM +1000, Nicholas Piggin wrote:
> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
> index c02f24400369..d63a5bb6bd0c 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -166,6 +166,9 @@ extern
On Wed, Dec 30, 2020 at 10:00:28AM +, Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote:
> > Excerpts from Russell King - ARM Linux admin's message of December 29, 2020
> > 8:44 pm:
> > > On Tue, Dec 29, 2020 at 01
On Wed, Dec 30, 2020 at 12:33:02PM +1000, Nicholas Piggin wrote:
> Excerpts from Russell King - ARM Linux admin's message of December 29, 2020
> 8:44 pm:
> > On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
> >> I think it should certainly be documented in ter
On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
> I think it should certainly be documented in terms of what guarantees
> it provides to application, _not_ the kinds of instructions it may or
> may not induce the core to execute. And if existing API can't be
> re-documented
On Mon, Dec 28, 2020 at 11:44:33AM -0800, Andy Lutomirski wrote:
> On Mon, Dec 28, 2020 at 11:09 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> > > After chatting with rmk about this (bu
On Mon, Dec 28, 2020 at 07:29:34PM +0100, Jann Horn wrote:
> After chatting with rmk about this (but without claiming that any of
> this is his opinion), based on the manpage, I think membarrier()
> currently doesn't really claim to be synchronizing caches? It just
> serializes cores. So arguably
On Mon, Dec 28, 2020 at 09:14:23AM -0800, Andy Lutomirski wrote:
> On Mon, Dec 28, 2020 at 2:25 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote:
> > > On Sun, Dec 27, 2020 at 12:18 PM Mat
On Sun, Dec 27, 2020 at 01:36:13PM -0800, Andy Lutomirski wrote:
> On Sun, Dec 27, 2020 at 12:18 PM Mathieu Desnoyers
> wrote:
> >
> > - On Dec 27, 2020, at 1:28 PM, Andy Lutomirski l...@kernel.org wrote:
> >
>
> > >
> > > I admit that I'm rather surprised that the code worked at all on
On Tue, Jul 14, 2020 at 03:01:09PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 03:19:24PM +0300, Ard Biesheuvel wrote:
> > So perhaps the answer is to have text_alloc() not with a 'where'
> > argument but with a 'why' argument. Or more simply, just have separate
> > alloc/free APIs for
On Tue, Jul 14, 2020 at 01:17:22PM +0300, Ard Biesheuvel wrote:
> On Tue, 14 Jul 2020 at 12:53, Jarkko Sakkinen
> wrote:
> >
> > On Mon, Jul 13, 2020 at 10:49:48PM +0300, Ard Biesheuvel wrote:
> > > This patch suggests that there are other reasons why conflating
> > > allocation of module space
On Tue, Jul 14, 2020 at 12:49:28PM +0300, Jarkko Sakkinen wrote:
> On Mon, Jul 13, 2020 at 07:34:10PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen wrote:
> > > Rename module_alloc() to text_alloc
On Tue, Jul 14, 2020 at 12:45:36PM +0300, Jarkko Sakkinen wrote:
> Rename module_alloc() to text_alloc() and module_memfree() to
> text_memfree(), and move them to kernel/text.c, which is unconditionally
> compiled to the kernel proper. This allows kprobes, ftrace and bpf to
> allocate space for
On Mon, Jul 13, 2020 at 09:19:37PM +0300, Jarkko Sakkinen wrote:
> Rename module_alloc() to text_alloc() and module_memfree() to
> text_memfree(), and move them to kernel/text.c, which is unconditionally
> compiled to the kernel proper. This allows kprobes, ftrace and bpf to
> allocate space for
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
From: Jagadeesh Pagadala
Code cleanup: Remove duplicate headers which are included twice.
Signed-off-by: Jagadeesh Pagadala
---
tools/testing/selftests/powerpc/tm/tm-poison.c | 1 -
tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c | 1 -
2 files changed, 2 deletions(-)
diff --git
From: Jagadeesh Pagadala
Code cleanup: Remove duplicate headers which are included twice.
Signed-off-by: Jagadeesh Pagadala
---
tools/testing/selftests/powerpc/mm/tlbie_test.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/mm/tlbie_test.c
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':
>
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
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 X,X Read/Write Read/Wr
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
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
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
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 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/
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 tree in g
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
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
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
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
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 +0800, Leo Yan
1 - 100 of 331 matches
Mail list logo
