On 13. 02. 24, 11:17, Arnd Bergmann wrote:
From: Arnd Bergmann
clang warns about explicitly casting between incompatible function
pointers:
drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)'
to 'void (*)(struct device *)' converts to incompatible function type
Thanks for the patch. Applied this patch and verified and issue is fixed.
This issue way originally reported in the below mail.
https://marc.info/?l=linux-kernel=170737160630106=2
Tested-by: Venkat Rao Bagalkote
On 13/02/24 10:51 pm, Jason Gunthorpe wrote:
On Tue, Feb 13, 2024 at
Hi Niklas,
On 2/10/2024 6:56 AM, Niklas Cassel wrote:
The series is based on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=endpoint
Hello all,
This series cleans up the hardware description for PCI endpoint BARs.
The problems with the existing hardware
Hello Andy
On 2/13/24 13:55, Andy Shevchenko wrote:
On Tue, Feb 13, 2024 at 2:14 AM George Stark wrote:
Hello Andy
On 2/12/24 12:53, Andy Shevchenko wrote:
On Mon, Feb 12, 2024 at 1:52 AM George Stark wrote:
I haven't lose hope for the devm_mutex thing and keep pinging those guys
from
>>And loop in Wen Xiong and Ming Lei, who care for this issue too.
Hi Pingfan, Thanks for your email!
Hi Michael,
Thanks for your new patchset!
In past month, Our several test team have modified /etc/sysconfig/kdump file
with nr_cpus=1, triggered kdump over the following IO devices and
>
> On 12. Feb 2024, at 12:19, Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> On powerpc, it is possible to compile test both the new apple (arm) and
> old pasemi (powerpc) drivers for the i2c hardware at the same time,
> which leads to a warning about linking the same object file twice:
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 *)'
> to 'void (*)(struct device *)' converts to incompatible function
On 13/02/2024 17:44, Mark Rutland wrote:
> On Fri, Feb 02, 2024 at 08:07:56AM +, Ryan Roberts wrote:
>> There are situations where a change to a single PTE could cause the
>> contpte block in which it resides to become foldable (i.e. could be
>> repainted with the contiguous bit). Such
Michael reported that we are seeing ftrace bug on bootup when KASAN is
enabled, and if we are using -fpatchable-function-entry:
ftrace: allocating 47780 entries in 18 pages
ftrace-powerpc: 0xc20b3d5c: No module provided for non-kernel
address
[ ftrace bug
On Fri, Feb 02, 2024 at 08:07:56AM +, Ryan Roberts wrote:
> There are situations where a change to a single PTE could cause the
> contpte block in which it resides to become foldable (i.e. could be
> repainted with the contiguous bit). Such situations arise, for example,
> when user space
On Tue, Feb 13, 2024 at 10:05:22AM -0600, Shivaprasad G Bhat wrote:
> The function spapr_tce_platform_iommu_attach_dev() is missing to call
> iommu_group_put() when the domain is already set. This refcount leak
> shows up with BUG_ON() during DLPAR remove operation as,
>
> KernelBug: Kernel bug
On Fri, Feb 02, 2024 at 08:07:55AM +, Ryan Roberts wrote:
> As set_ptes() and wrprotect_ptes() become a bit more complex, the
> compiler may choose not to inline them. But this is critical for fork()
> performance. So mark the functions, along with contpte_try_unfold()
> which is called by
On Fri, Feb 02, 2024 at 08:07:54AM +, Ryan Roberts wrote:
> When core code iterates over a range of ptes and calls ptep_get() for
> each of them, if the range happens to cover contpte mappings, the number
> of pte reads becomes amplified by a factor of the number of PTEs in a
> contpte block.
On Tue, Feb 13, 2024 at 04:48:50PM +, Ryan Roberts wrote:
> On 13/02/2024 16:43, Mark Rutland wrote:
> > On Fri, Feb 02, 2024 at 08:07:52AM +, Ryan Roberts wrote:
> >> +static inline void __clear_full_ptes(struct mm_struct *mm, unsigned long
> >> addr,
> >> +
On 13/02/2024 16:43, Mark Rutland wrote:
> On Fri, Feb 02, 2024 at 08:07:52AM +, Ryan Roberts wrote:
>> Optimize the contpte implementation to fix some of the
>> exit/munmap/dontneed performance regression introduced by the initial
>> contpte commit. Subsequent patches will solve it entirely.
On Fri, Feb 02, 2024 at 08:07:52AM +, Ryan Roberts wrote:
> Optimize the contpte implementation to fix some of the
> exit/munmap/dontneed performance regression introduced by the initial
> contpte commit. Subsequent patches will solve it entirely.
>
> During exit(), munmap() or
On 13/02/2024 16:31, Mark Rutland wrote:
> On Fri, Feb 02, 2024 at 08:07:51AM +, Ryan Roberts wrote:
>> Optimize the contpte implementation to fix some of the fork performance
>> regression introduced by the initial contpte commit. Subsequent patches
>> will solve it entirely.
>>
>> During
On Fri, Feb 02, 2024 at 08:07:51AM +, Ryan Roberts wrote:
> Optimize the contpte implementation to fix some of the fork performance
> regression introduced by the initial contpte commit. Subsequent patches
> will solve it entirely.
>
> During fork(), any private memory in the parent must be
The function spapr_tce_platform_iommu_attach_dev() is missing to call
iommu_group_put() when the domain is already set. This refcount leak
shows up with BUG_ON() during DLPAR remove operation as,
KernelBug: Kernel bug in state 'None': kernel BUG at
arch/powerpc/platforms/pseries/iommu.c:100!
On 12/02/2024 16:24, David Hildenbrand wrote:
> On 12.02.24 16:34, Ryan Roberts wrote:
>> On 12/02/2024 15:26, David Hildenbrand wrote:
>>> On 12.02.24 15:45, Ryan Roberts wrote:
On 12/02/2024 13:54, David Hildenbrand wrote:
>>> If so, I wonder if we could instead do that comparison
Le 12/02/2024 à 18:14, Timothy Pearson a écrit :
> When building the kernel in size optimized mode with the amdgpu module
> enabled,
> gcc will begin referencing external gpr1 and fpu save/restore functions. This
> will then cause a linker failure as we do not link against libgcc which
>
On 2024-01-23 15:21, Arnd Bergmann wrote:
>>> + /kisskb/src/arch/sparc/include/asm/floppy_64.h: error: no previous
>>> prototype for 'sparc_floppy_irq' [-Werror=missing-prototypes]: => 200:13
>>> + /kisskb/src/arch/sparc/include/asm/floppy_64.h: error: no previous
>>> prototype for
On 13/02/2024 14:08, Ard Biesheuvel wrote:
> On Tue, 13 Feb 2024 at 15:05, David Hildenbrand wrote:
>>
>> On 13.02.24 15:02, Ryan Roberts wrote:
>>> On 13/02/2024 13:45, David Hildenbrand wrote:
On 13.02.24 14:33, Ard Biesheuvel wrote:
> On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote:
On Tue, 13 Feb 2024 at 15:05, David Hildenbrand wrote:
>
> On 13.02.24 15:02, Ryan Roberts wrote:
> > On 13/02/2024 13:45, David Hildenbrand wrote:
> >> On 13.02.24 14:33, Ard Biesheuvel wrote:
> >>> On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote:
>
> On 13/02/2024 13:13, David
On 13.02.24 15:02, Ryan Roberts wrote:
On 13/02/2024 13:45, David Hildenbrand wrote:
On 13.02.24 14:33, Ard Biesheuvel wrote:
On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote:
On 13/02/2024 13:13, David Hildenbrand wrote:
On 13.02.24 14:06, Ryan Roberts wrote:
On 13/02/2024 12:19, David
On 13/02/2024 13:45, David Hildenbrand wrote:
> On 13.02.24 14:33, Ard Biesheuvel wrote:
>> On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote:
>>>
>>> On 13/02/2024 13:13, David Hildenbrand wrote:
On 13.02.24 14:06, Ryan Roberts wrote:
> On 13/02/2024 12:19, David Hildenbrand wrote:
arch_vmap_pud_supported() and arch_vmap_pmd_supported() are
expected to constant-fold to false when RADIX is not enabled.
Force inlining in order to avoid following failure which
leads to unexpected call of non-existing pud_set_huge() and
pmd_set_huge() on powerpc 8xx.
In function
On 13.02.24 14:33, Ard Biesheuvel wrote:
On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote:
On 13/02/2024 13:13, David Hildenbrand wrote:
On 13.02.24 14:06, Ryan Roberts wrote:
On 13/02/2024 12:19, David Hildenbrand wrote:
On 13.02.24 13:06, Ryan Roberts wrote:
On 12/02/2024 20:38, Ryan
On Tue, 13 Feb 2024 at 14:21, Ryan Roberts wrote:
>
> On 13/02/2024 13:13, David Hildenbrand wrote:
> > On 13.02.24 14:06, Ryan Roberts wrote:
> >> On 13/02/2024 12:19, David Hildenbrand wrote:
> >>> On 13.02.24 13:06, Ryan Roberts wrote:
> On 12/02/2024 20:38, Ryan Roberts wrote:
> >
On 13/02/2024 13:22, David Hildenbrand wrote:
> On 13.02.24 14:20, Ryan Roberts wrote:
>> On 13/02/2024 13:13, David Hildenbrand wrote:
>>> On 13.02.24 14:06, Ryan Roberts wrote:
On 13/02/2024 12:19, David Hildenbrand wrote:
> On 13.02.24 13:06, Ryan Roberts wrote:
>> On 12/02/2024
On 13.02.24 14:20, Ryan Roberts wrote:
On 13/02/2024 13:13, David Hildenbrand wrote:
On 13.02.24 14:06, Ryan Roberts wrote:
On 13/02/2024 12:19, David Hildenbrand wrote:
On 13.02.24 13:06, Ryan Roberts wrote:
On 12/02/2024 20:38, Ryan Roberts wrote:
[...]
+static inline bool
On 13/02/2024 13:13, David Hildenbrand wrote:
> On 13.02.24 14:06, Ryan Roberts wrote:
>> On 13/02/2024 12:19, David Hildenbrand wrote:
>>> On 13.02.24 13:06, Ryan Roberts wrote:
On 12/02/2024 20:38, Ryan Roberts wrote:
> [...]
>
> +static inline bool mm_is_user(struct
On 13.02.24 14:06, Ryan Roberts wrote:
On 13/02/2024 12:19, David Hildenbrand wrote:
On 13.02.24 13:06, Ryan Roberts wrote:
On 12/02/2024 20:38, Ryan Roberts wrote:
[...]
+static inline bool mm_is_user(struct mm_struct *mm)
+{
+ /*
+ * Don't attempt to apply the contig bit to kernel
On 13/02/2024 12:19, David Hildenbrand wrote:
> On 13.02.24 13:06, Ryan Roberts wrote:
>> On 12/02/2024 20:38, Ryan Roberts wrote:
>>> [...]
>>>
>>> +static inline bool mm_is_user(struct mm_struct *mm)
>>> +{
>>> + /*
>>> + * Don't attempt to apply the contig bit to kernel
On 13/02/2024 12:02, Mark Rutland wrote:
> On Mon, Feb 12, 2024 at 12:59:57PM +, Ryan Roberts wrote:
>> On 12/02/2024 12:00, Mark Rutland wrote:
>>> Hi Ryan,
>
> [...]
>
+static inline void set_pte(pte_t *ptep, pte_t pte)
+{
+ /*
+ * We don't have the mm or vaddr so
On 13.02.24 13:06, Ryan Roberts wrote:
On 12/02/2024 20:38, Ryan Roberts wrote:
[...]
+static inline bool mm_is_user(struct mm_struct *mm)
+{
+ /*
+* Don't attempt to apply the contig bit to kernel mappings, because
+* dynamically adding/removing the contig bit can cause
On 12/02/2024 20:38, Ryan Roberts wrote:
> [...]
>
> +static inline bool mm_is_user(struct mm_struct *mm)
> +{
> + /*
> + * Don't attempt to apply the contig bit to kernel mappings, because
> + * dynamically adding/removing the contig bit can cause page faults.
> + *
On Mon, Feb 12, 2024 at 12:59:57PM +, Ryan Roberts wrote:
> On 12/02/2024 12:00, Mark Rutland wrote:
> > Hi Ryan,
[...]
> >> +static inline void set_pte(pte_t *ptep, pte_t pte)
> >> +{
> >> + /*
> >> + * We don't have the mm or vaddr so cannot unfold contig entries (since
> >> + * it
Remove CONFIG_CRASH_DUMP dependency on CONFIG_KEXEC. CONFIG_KEXEC_CORE
was used at places where CONFIG_CRASH_DUMP or CONFIG_CRASH_RESERVE was
appropriate. Replace with appropriate #ifdefs to support CONFIG_KEXEC
and !CONFIG_CRASH_DUMP configuration option. Also, make CONFIG_FA_DUMP
dependent on
CONFIG_KEXEC_FILE does not have to select CONFIG_CRASH_DUMP. Move
some code under CONFIG_CRASH_DUMP to support CONFIG_KEXEC_FILE and
!CONFIG_CRASH_DUMP case.
Signed-off-by: Hari Bathini
---
arch/powerpc/kexec/elf_64.c | 4 +-
arch/powerpc/kexec/file_load_64.c | 269
struct crash_mem defined under include/linux/crash_core.h represents
a list of memory ranges. While it is used to represent memory ranges
for kdump kernel, it can also be used for other kind of memory ranges.
In fact, KEXEC_FILE_LOAD syscall in powerpc uses this structure to
represent reserved
This patch series is a follow-up to [1] based on discussions at [2]
about additional work needed to get it working on powerpc.
The first patch in the series makes struct crash_mem available with or
without CONFIG_CRASH_DUMP enabled. The next patch moves kdump specific
code for kexec_file_load
On Mon, Feb 12, 2024 at 05:04:58PM -0300, Ricardo B. Marliere wrote:
> This series is part of an effort to cleanup the users of the driver
> core, as can be seen in many recent patches authored by Greg across the
> tree (e.g. [1]). Patch 1/5 is a prerequisite to 2/5, but the others have
> no
On Tue, Feb 13, 2024 at 2:14 AM George Stark wrote:
>
> Hello Andy
>
> On 2/12/24 12:53, Andy Shevchenko wrote:
> > On Mon, Feb 12, 2024 at 1:52 AM George Stark
> > wrote:
> >> I haven't lose hope for the devm_mutex thing and keep pinging those guys
> >> from time to time.
> >
> > I don't
From: Arnd Bergmann
clang warns about explicitly casting between incompatible function
pointers:
drivers/tty/hvc/hvc_iucv.c:1100:23: error: cast from 'void (*)(const void *)'
to 'void (*)(struct device *)' converts to incompatible function type
[-Werror,-Wcast-function-type-strict]
1100 |
On 12.02.24 21:38, Ryan Roberts wrote:
[...]
+static inline bool mm_is_user(struct mm_struct *mm)
+{
+ /*
+* Don't attempt to apply the contig bit to kernel mappings, because
+* dynamically adding/removing the contig bit can cause page faults.
+* These racing
Am Montag, 5. Februar 2024, 09:39:07 CET schrieb David Gstir:
> Hi,
>
> > On 15.12.2023, at 12:06, David Gstir wrote:
> >
> > This is a revival of the previous patch set submitted by Richard Weinberger:
> > https://lore.kernel.org/linux-integrity/20210614201620.30451-1-rich...@nod.at/
> >
> >
On 12.02.24 22:34, Ryan Roberts wrote:
On 12/02/2024 14:29, David Hildenbrand wrote:
On 12.02.24 15:10, Ryan Roberts wrote:
On 12/02/2024 12:14, David Hildenbrand wrote:
On 02.02.24 09:07, Ryan Roberts wrote:
The goal is to be able to advance a PTE by an arbitrary number of PFNs.
So
Hi Christophe,
On 13 Feb 08:05, Christophe Leroy wrote:
> Hi
>
> Le 12/02/2024 à 21:04, Ricardo B. Marliere a écrit :
> > This series is part of an effort to cleanup the users of the driver
> > core, as can be seen in many recent patches authored by Greg across the
> > tree (e.g. [1]). Patch 1/5
Hi
Le 12/02/2024 à 21:04, Ricardo B. Marliere a écrit :
> This series is part of an effort to cleanup the users of the driver
> core, as can be seen in many recent patches authored by Greg across the
> tree (e.g. [1]). Patch 1/5 is a prerequisite to 2/5, but the others have
> no dependency. They
50 matches
Mail list logo
