Hi Xia,
Le 01/05/2024 à 08:22, 赵夏 a écrit :
> Hi Christophe,
>
> I identified that the function named "arch_local_irq_restore" of the
> file irq_64.c was updated by you frequently in the last two years.
You mean arch/powerpc/kernel/irq_64.c I guess ?
I don't think I "frequently" changed
Le 24/04/2024 à 13:09, Hari Bathini a écrit :
> When KFENCE is enabled, total system memory is mapped at page level
> granularity. But in radix MMU mode, ~3GB additional memory is needed
> to map 100GB of system memory at page level granularity when compared
> to using 2MB direct mapping. This
Le 06/05/2024 à 14:51, Michael Ellerman a écrit :
> Replace 4xx usage with 44x, and replace 4xx_SOC with 44x.
You can go one step further because CONFIG_44x implies CONFIG_BOOKE, see
Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> There are cases where define a global register variable and associate it
> with a specified register. Example, in powerpc, two registers are
> defined to represent variable:
> 1. r13: represents local_paca
> register struct paca_struct *local_paca
Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> Update instruction tracking with add instruction. Apart from "mr"
> instruction, the register state is carried on by other insns, ie,
> "add, addi, addis". Since these are not memory instructions and doesn't
> fall in the range of (32 to 63), add
Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> Add instruction tracking function "update_insn_state_powerpc" for
> powerpc. Example sequence in powerpc:
>
> ld r10,264(r3)
> mr r31,r3
> <
> ld r9,312(r31)
Your approach looks fragile.
mr is a simplified instruction which in
Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> Use the raw instruction code and macros to identify memory instructions,
> extract register fields and also offset. The implementation addresses
> the D-form, X-form, DS-form instructions. Two main functions are added.
> New parse function
Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> Add support to capture and parse raw instruction in objdump.
What's the purpose of using 'objdump' for reading raw instructions ?
Can't they be read directly without invoking 'objdump' ? It looks odd to
me to use objdump to provide readable
Le 01/05/2024 à 18:29, Stephen Brennan a écrit :
> 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 kprobes will still be active, and when triggered, they
> will use the freed memory,
Le 19/04/2024 à 17:49, Mike Rapoport a écrit :
> Hi Masami,
>
> On Thu, Apr 18, 2024 at 06:16:15AM +0900, Masami Hiramatsu wrote:
>> Hi Mike,
>>
>> On Thu, 11 Apr 2024 19:00:50 +0300
>> Mike Rapoport wrote:
>>
>>> From: "Mike Rapoport (IBM)"
>>>
>>> kprobes depended on CONFIG_MODULES because
Le 16/04/2024 à 14:14, Markus Elfring a écrit :
>> This is explicit in Kernel documentation:
>>
>> /**
>>* kfree - free previously allocated memory
>>* @object: pointer returned by kmalloc() or kmem_cache_alloc()
>>*
>>* If @object is NULL, no operation is performed.
>>*/
>>
Le 16/04/2024 à 13:11, Michael Ellerman a écrit :
> Markus Elfring writes:
>>> A few update suggestions were taken into account
>>> from static source code analysis.
>>>
>>> Markus Elfring (2):
>>
>> I would appreciate a bit more information about the reasons
>> why this patch series was
Le 15/04/2024 à 21:12, Christophe Leroy a écrit :
>
>
> Le 12/04/2024 à 16:30, Peter Xu a écrit :
>> On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote:
>>>
>>>
>>> Le 11/04/2024 à 18:15, Peter Xu a écrit :
>>>> On Mon, M
Le 12/04/2024 à 16:30, Peter Xu a écrit :
> On Fri, Apr 12, 2024 at 02:08:03PM +0000, Christophe Leroy wrote:
>>
>>
>> Le 11/04/2024 à 18:15, Peter Xu a écrit :
>>> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
>>>> On Mon, Mar 25,
Le 15/04/2024 à 17:35, Arnd Bergmann a écrit :
> On Mon, Apr 15, 2024, at 04:19, Michael Ellerman wrote:
>> "Arnd Bergmann" writes:
>>> On Thu, Apr 11, 2024, at 11:27, Adrian Hunter wrote:
>>>> On 11/04/24 11:22, Christophe Leroy wrote:
>>>>
Le 10/04/2024 à 21:58, Peter Xu a écrit :
>>
>> e500 has two modes: 32 bits and 64 bits.
>>
>> For 32 bits:
>>
>> 8xx is the only one handling it through HW-assisted pagetable walk hence
>> requiring a 2-level whatever the pagesize is.
>
> Hmm I think maybe finally I get it..
>
> I think the
Le 11/04/2024 à 18:15, Peter Xu a écrit :
> On Mon, Mar 25, 2024 at 01:38:40PM -0300, Jason Gunthorpe wrote:
>> On Mon, Mar 25, 2024 at 03:55:53PM +0100, Christophe Leroy wrote:
>>> This series reimplements hugepages with hugepd on powerpc 8xx.
>>>
>>> Unlik
Le 11/04/2024 à 18:05, Mike Rapoport a écrit :
> From: "Mike Rapoport (IBM)"
>
> vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explictly
> specify node ID will use huge pages only if size_per_node is larger than
> PMD_SIZE.
> Still the actual allocated memory is not distributed
Le 11/04/2024 à 10:12, Christophe Leroy a écrit :
>
>
> Le 11/04/2024 à 09:16, Adrian Hunter a écrit :
>> 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 implementa
Le 11/04/2024 à 09:16, Adrian Hunter a écrit :
> 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 implementations of BUG() use unreachable()
>>> or other non-returning code. However with !CONFIG_BUG, the default
Le 10/04/2024 à 17:28, Peter Xu a écrit :
> On Tue, Apr 09, 2024 at 08:43:55PM -0300, Jason Gunthorpe wrote:
>> On Fri, Apr 05, 2024 at 05:42:44PM -0400, Peter Xu wrote:
>>> In short, hugetlb mappings shouldn't be special comparing to other huge pXd
>>> and large folio (cont-pXd) mappings for
Le 10/04/2024 à 17:22, Joel Savitz a écrit :
> [Vous ne recevez pas souvent de courriers de jsav...@redhat.com. Découvrez
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
>
> On Mon, Apr 1, 2024 at 10:17 AM Joel Savitz wrote:
>>
>> On Tue, Mar 26, 2024 at 12:45
Le 10/04/2024 à 15:42, lizhe a écrit :
>
> Hi，
> I have already tested it, it is functioning properly, Please review.
>
> *Lizhe*
>
> Thanks
>
Please don't top-post, see
Hi Vladimir,
Le 19/02/2024 à 16:30, Vladimir Oltean a écrit :
> Hi Sean,
>
> On Thu, Feb 15, 2024 at 11:23:26AM -0500, Sean Anderson wrote:
>> smp_call_function_single disables IRQs when executing the callback. To
>> prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
>> This
Le 09/04/2024 à 06:37, Michael Ellerman a écrit :
> Andrew Donnellan writes:
>> The cxl driver is no longer actively maintained and we intend to remove it
>> in a future kernel release. Change its status to obsolete, and update the
>> sysfs ABI documentation accordingly.
>>
>> Signed-off-by:
Hi Christian, hi Hari,
Le 04/04/2024 à 19:44, Christian Zigotzky a écrit :
> Shall we use CONFIG_CRASH_DUMP to get int crashing_cpu = -1;?
>
> Further information:
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2024-March/269985.html
>
will inheret instrumentation from their caller.
>
> KCSAN kernels were observed to compile without inlining these routines,
> which would lead to grief on NMI handlers.
>
> Signed-off-by: Rohan McLure
Reviewed-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/interru
Le 04/04/2024 à 06:45, Rohan McLure a écrit :
> Arbitrary instrumented locations, including syscall handlers, can call
> arch_local_irq_restore() transitively when KCSAN is enabled, and in turn
> also replay_soft_interrupts_irqrestore(). The precondition on entry to
> this routine that is
Le 27/03/2024 à 17:57, Jason Gunthorpe a écrit :
> On Wed, Mar 27, 2024 at 09:58:35AM +0000, Christophe Leroy wrote:
>>> Just general remarks on the ones with huge pages:
>>>
>>>hash 64k and hugepage 16M/16G
>>>radix 64k/radix hugepage 2M/
Le 03/04/2024 à 15:07, Jason Gunthorpe a écrit :
> On Wed, Apr 03, 2024 at 12:26:43PM +0000, Christophe Leroy wrote:
>>
>>
>> Le 03/04/2024 à 14:08, Jason Gunthorpe a écrit :
>>> On Tue, Apr 02, 2024 at 07:35:45PM -0400, Peter Xu wrote:
>>>> On Tu
Le 03/04/2024 à 14:08, Jason Gunthorpe a écrit :
> On Tue, Apr 02, 2024 at 07:35:45PM -0400, Peter Xu wrote:
>> On Tue, Apr 02, 2024 at 07:53:20PM -0300, Jason Gunthorpe wrote:
>>> On Tue, Apr 02, 2024 at 06:43:56PM -0400, Peter Xu wrote:
>>>
I actually tested this without hitting the issue
_PARAVIRT for hcalls")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Christophe Leroy
> ---
> arch/powerpc/sysdev/fsl_msi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
> index 8e6c84df4ca1..
Le 02/04/2024 à 12:58, Hari Bathini a écrit :
> Currently, bpf jit code on powerpc assumes all the bpf functions and
> helpers to be kernel text. This is false for kfunc case, as function
> addresses can be module addresses as well. So, ensure module addresses
> are supported to enable kfunc
Le 02/04/2024 à 12:58, Hari Bathini a écrit :
> With PCREL addressing, there is no kernel TOC. So, it is not setup in
> prologue when PCREL addressing is used. But the number of instructions
> to skip on a tail call was not adjusted accordingly. That resulted in
> not so obvious failures while
Le 28/03/2024 à 08:57, Christophe Leroy a écrit :
>
>
> Le 28/03/2024 à 07:52, Christophe Leroy a écrit :
>>
>>
>> Le 28/03/2024 à 05:55, Rohan McLure a écrit :
>>> Support page table check on all PowerPC platforms. This works by
>>> serialising
Le 28/03/2024 à 07:52, Christophe Leroy a écrit :
>
>
> Le 28/03/2024 à 05:55, Rohan McLure a écrit :
>> Support page table check on all PowerPC platforms. This works by
>> serialising assignments, reassignments and clears of page table
>> entries at ea
Le 28/03/2024 à 05:55, Rohan McLure a écrit :
> Support page table check on all PowerPC platforms. This works by
> serialising assignments, reassignments and clears of page table
> entries at each level in order to ensure that anonymous mappings
> have at most one writable consumer, and likewise
Le 28/03/2024 à 05:55, Rohan McLure a écrit :
> Page table checking depends on architectures providing an
> implementation of p{te,md,ud}_user_accessible_page. With
> refactorisations made on powerpc/mm, the pte_access_permitted() and
> similar methods verify whether a userland page is
Le 28/03/2024 à 05:55, Rohan McLure a écrit :
> The page table check feature requires that pud_pfn() be defined
> on each consuming architecture. Since only 64-bit, Book3S platforms
> allow for hugepages at this upper level, and since the calling code is
> gated by a call to
Le 27/03/2024 à 05:59, Nicholas Miehlbradt a écrit :
> JUMP_LABEL_FEATURE_CHECK_DEBUG used static_key_initialized to determine
> whether {cpu,mmu}_has_feature() was used before static keys were
> initialized. However, {cpu,mmu}_has_feature() should not be used before
> setup_feature_keys() is
Le 26/03/2024 à 16:01, Jason Gunthorpe a écrit :
> On Mon, Mar 25, 2024 at 07:05:01PM +0000, Christophe Leroy wrote:
>
>> Not looked into details yet, but I guess so.
>>
>> By the way there is a wiki dedicated to huge pages on powerpc, you can
>> have a look at i
group.eu/
>
> Suggested-by: Christophe Leroy
> Signed-off-by: Benjamin Gray
>
> ---
>
> v2: * New in v2
>
> I think Suggested-by is an appropriate tag. The patch is Christophe's
> from the link, I just added the commit description, so it could well
> be better to c
Le 25/03/2024 à 17:19, Jason Gunthorpe a écrit :
> On Mon, Mar 25, 2024 at 03:55:54PM +0100, Christophe Leroy wrote:
>> Unlike many architectures, powerpc 8xx hardware tablewalk requires
>> a two level process for all page sizes, allthough second level only
>> has one entr
it is addressing an 8M page,
this is required for the HW tablewalk assistance.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/hugetlb.h| 11 -
.../include/asm/nohash/32/hugetlb-8xx.h | 28 +++-
arch/powerpc/include/asm/nohash/32/pgalloc.h | 2 +
arch
Remove support for 8M pages in order to stop using hugepd.
Support for 8M pages will be added back later using the same
approach as for 512k pages, in extenso using contiguous page
entries in the regular page table.
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig
Le 21/03/2024 à 23:07, pet...@redhat.com a écrit :
> From: Peter Xu
>
> v3:
> - Rebased to latest mm-unstalbe (a824831a082f, of March 21th)
> - Dropped patch to introduce pmd_thp_or_huge(), replace such uses (and also
>pXd_huge() users) with pXd_leaf() [Jason]
> - Add a comment for
set_huge_pte_at() expects the real page size, not the psize which is
the index of the page definition in table mmu_psize_defs[]
Fixes: 935d4f0c6dc8 ("mm: hugetlb: add huge page size param to
set_huge_pte_at()")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/8xx.c | 3 +
In preparation of implementing huge pages on powerpc 8xx
without hugepd, enclose hugepd related code inside an
ifdef CONFIG_ARCH_HAS_HUGEPD
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/hugetlb.h| 2 ++
arch/powerpc/include/asm/nohash/pgtable.h | 8 +---
arch
the pmd.
In order to be consistent with huge_ptep_get_and_clear(), give
mm and address to huge_ptep_get().
Signed-off-by: Christophe Leroy
---
arch/arm64/include/asm/hugetlb.h | 2 +-
fs/hugetlbfs/inode.c | 2 +-
fs/proc/task_mmu.c | 8 +++---
fs/userfaultfd.c
On powerpc 8xx, when a page is 8M size, the information is in the PMD
entry. So provide it to pte_leaf_size().
Signed-off-by: Christophe Leroy
---
arch/arm64/include/asm/pgtable.h | 2 +-
arch/powerpc/include/asm/nohash/32/pte-8xx.h | 2 +-
arch/riscv/include/asm/pgtable.h
In order to be able to flag the PMD entry with _PMD_HUGE_8M on
powerpc 8xx, provide page size to pte_alloc_huge() and use it
through the newly introduced pte_alloc_size().
Signed-off-by: Christophe Leroy
---
arch/arm64/mm/hugetlbpage.c | 2 +-
arch/parisc/mm/hugetlbpage.c | 2 +-
arch
for use by
pte_alloc_huge().
When an architecture doesn't provide pmd_populate_size(),
pmd_populate() is used as a fallback.
Signed-off-by: Christophe Leroy
---
include/linux/mm.h | 12 +++-
mm/filemap.c | 2 +-
mm/internal.h | 2 +-
mm/memory.c| 19
for that 8M page.
At the moment it has to look into each helper to know if the
hugepage ptep is a PTE or a PMD in order to know it is a 8M page or
a lower size. I hope this can me handled by core-mm in the future.
There are probably several ways to implement stuff, so feedback is
very welcome.
Christophe
Hi,
Le 25/03/2024 à 06:18, Christian Zigotzky a écrit :
> I have created a patch:
>
> --- a/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:14:02.201209476 +0100
> +++ b/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:10:04.421425931 +0100
> @@ -393,6 +393,7 @@ static void
Le 20/03/2024 à 17:09, Peter Xu a écrit :
> On Wed, Mar 20, 2024 at 06:16:43AM +0000, Christophe Leroy wrote:
>> At the first place that was to get a close fit between hardware
>> pagetable topology and linux pagetable topology. But obviously we
>> already stepped back for
Le 20/03/2024 à 00:26, Jason Gunthorpe a écrit :
> On Tue, Mar 19, 2024 at 11:07:08PM +0000, Christophe Leroy wrote:
>>
>>
>> Le 18/03/2024 à 17:15, Jason Gunthorpe a écrit :
>>> On Thu, Mar 14, 2024 at 01:11:59PM +, Christophe Leroy wrote:
>>>>
Le 18/03/2024 à 17:15, Jason Gunthorpe a écrit :
> On Thu, Mar 14, 2024 at 01:11:59PM +0000, Christophe Leroy wrote:
>>
>>
>> Le 14/03/2024 à 13:53, Peter Xu a écrit :
>>> On Thu, Mar 14, 2024 at 08:45:34AM +, Christophe Leroy wrote:
>>>>
>>
Le 09/10/2022 à 19:31, Christophe Leroy a écrit :
> init_mm->pgd is always swapper_pg_dir[] which is known
> at build time.
>
> Directly use the later instead of loading it from init_mm
> struct at every time.
>
> Signed-off-by: Christophe Leroy
Dropping this p
mark_rodata_ro() and mark_initmem_nx() use functions that can
fail like set_memory_nx() and set_memory_ro(), leading to a not
protected kernel.
In case of failure, panic.
Link: https://github.com/KSPP/linux/issues/7
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link:
https
Le 15/03/2024 à 09:38, Christophe Leroy a écrit :
>
>
> Le 15/03/2024 à 03:59, Benjamin Gray a écrit :
>> The existing patching alias page setup and teardown sections can be
>> simplified to make use of the new open_patch_window() abstraction.
>>
>>
Le 15/03/2024 à 09:38, Christophe Leroy a écrit :
>
>
> Le 15/03/2024 à 03:59, Benjamin Gray a écrit :
>> The existing patching alias page setup and teardown sections can be
>> simplified to make use of the new open_patch_window() abstraction.
>>
>>
Hi,
Le 15/03/2024 à 13:20, Michal Suchánek a écrit :
> Hello,
>
> I cannot load the wireguard module.
>
> Loading the module provides no diagnostic other than 'No such device'.
>
> Please provide maningful diagnostics for loading software-only driver,
> clearly there is no particular device
Le 15/03/2024 à 03:59, Benjamin Gray a écrit :
> The existing patching alias page setup and teardown sections can be
> simplified to make use of the new open_patch_window() abstraction.
>
> This eliminates the _mm variants of the helpers, consumers no longer
> need to check mm_patch_enabled(),
Le 29/02/2024 à 07:37, Michael Ellerman a écrit :
> Stephen Rothwell writes:
>> Hi all,
>>
>> Today's linux-next merge of the powerpc tree got a conflict in:
>>
>>arch/powerpc/mm/pgtable_32.c
>>
>> between commit:
>>
>>a5e8131a0329 ("arm64, powerpc, riscv, s390, x86: ptdump: refactor
Le 15/03/2024 à 03:57, Benjamin Gray a écrit :
> patch_instructions() introduces new behaviour with a couple of
> variations. Test each case of
>
>* a repeated 32-bit instruction,
>* a repeated 64-bit instruction (ppc64), and
>* a copied sequence of instructions
>
> for both on a
Le 15/03/2024 à 03:57, Benjamin Gray a écrit :
> As we are patching instructions, we can assume the length is a multiple
> of 4 and the destination address is aligned.
>
> Atomicity of patching a prefixed instruction is not a concern, as the
> original implementation doesn't provide it anyway.
Le 15/03/2024 à 03:57, Benjamin Gray a écrit :
> The patching page set up as a writable alias may be in quadrant 1
> (userspace) if the temporary mm path is used. This causes sanitiser
> failures if so. Sanitiser failures also occur on the non-mm path
> because the plain memset family is
: Herve Codina
>> Reviewed-by: Christophe Leroy
>> Acked-by: Jakub Kicinski
>> ---
> [ ... ]
>
>> +
>> +static const struct of_device_id qmc_hdlc_id_table[] = {
>> +{ .compatible = "fsl,qmc-hdlc" },
>> +{} /* sentinel */
>> +};
>&g
Le 14/03/2024 à 13:53, Peter Xu a écrit :
> On Thu, Mar 14, 2024 at 08:45:34AM +0000, Christophe Leroy wrote:
>>
>>
>> Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
>>> From: Peter Xu
>>>
>>> PowerPC book3s 4K mostly has the same definition o
mutex_init()
>
> Signed-off-by: George Stark
> Suggested by-by: Christophe Leroy
s/Suggested by-by/Suggested-by:
Reviewed-by: Christophe Leroy
> ---
> include/linux/mutex.h| 27 +++
> kernel/locking/mutex-debug.c | 11 +++
> 2 fi
Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> From: Peter Xu
>
> This API is not used anymore, drop it for the whole tree.
>
> Signed-off-by: Peter Xu
> ---
> arch/arm/mm/Makefile | 1 -
> arch/arm/mm/hugetlbpage.c | 29
Le 13/03/2024 à 22:47, pet...@redhat.com a écrit :
> From: Peter Xu
>
> Now after we're sure all pXd_huge() definitions are the same as pXd_leaf(),
> reuse it. Luckily, pXd_huge() isn't widely used.
>
> Signed-off-by: Peter Xu
> ---
> arch/arm/include/asm/pgtable-3level.h | 2 +-
>
uge() treewide.
>
> NOTE: *_leaf() definition need to be moved before the inclusion of
> asm/book3s/64/pgtable-4k.h, which defines pXd_huge() with it.
>
> [1] https://lore.kernel.org/r/87v85zo6w7.fsf@mail.lhotse
>
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christo
Le 13/03/2024 à 05:21, Rohan McLure a écrit :
> In the new set_ptes() API, set_pte_at() (a special case of set_ptes())
> is intended to be instrumented by the page table check facility. There
> are however several other routines that constitute the API for setting
> page table entries, including
Le 13/03/2024 à 05:21, Rohan McLure a écrit :
> Page table checking depends on architectures providing an
> implementation of p{te,md,ud}_user_accessible_page. With
> refactorisations made on powerpc/mm, the pte_access_permitted() and
> similar methods verify whether a userland page is
Le 13/03/2024 à 05:21, Rohan McLure a écrit :
> Prior to this commit, pud_pfn was implemented with BUILD_BUG as the inline
> function for 64-bit Book3S systems but is never included, as its
> invocations in generic code are guarded by calls to pud_devmap which return
> zero on such systems. A
re's already an equivalent commit in mm-stable, that will likely go
into v6.9:
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-stable=bd18b688220c7225fb50498dabd9f9d0c9988e67
>
> Reviewed-by: Christophe Leroy
> Signed-off-by: Rohan McLure
> ---
> v9:
tand from this text that, as agreed, this patch removes the
pointless/redundant zero-init of individual members. But it is not what
is done, see below ?
>
> Signed-off-by: Rick Edgecombe
> Acked-by: Michael Ellerman
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Chri
Le 12/03/2024 à 16:30, George Stark a écrit :
> [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello Christophe
>
> On 3/12/24 14:51, Christophe Ler
Le 12/03/2024 à 12:39, George Stark a écrit :
> [Vous ne recevez pas souvent de courriers de gnst...@salutedevices.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello Christophe
>
> Thanks for the review
> You were right about typecheck
+Nathan as this is RTAS related.
Le 21/08/2018 à 20:42, Breno Leitao a écrit :
> The rtas syscall reads a value from a user-provided structure and uses it
> to index an array, being a possible area for a potential spectre v1 attack.
> This is the code that exposes this problem.
>
>
Le 19/06/2018 à 21:54, Pedro Franco de Carvalho a écrit :
> Would something like this be ok?
>
> I factored out the calls to flush_fp_to_thread and flush_altivec_to_thread,
> although I don't really understand why these are necessary. The
> tm_cvsx_get/set
> functions also calls
Le 29/01/2024 à 07:25, Sathvika Vasireddy a écrit :
> Hi Christophe, Nick
>
> On 1/26/24 12:32 AM, Christophe Leroy wrote:
>> Hi Nic,
>>
>> Le 21/05/2017 à 03:01, Nicholas Piggin a écrit :
>>> Implement build-time fixup of alternate feature relative addr
>>>> often is bound to other resources and has no own devm wrapping.
>>>>> Since mutex_destroy() actually does nothing in non-debug builds
>>>>> frequently calling mutex_destroy() is just ignored which is safe
>>>>>
Le 12/03/2024 à 02:10, Waiman Long a écrit :
> On 3/11/24 19:47, George Stark wrote:
>> Hello Waiman, Marek
>>
>> Thanks for the review.
>>
>> I've never used lockdep for debug but it seems preferable to
>> keep that feature working. It could be look like this:
>>
>> diff --git
g formally and can lead to a problem if mutex_destroy() will be
>>> extended so introduce devm_mutex_init()
>>>
>>> Signed-off-by: George Stark
>>> Signed-off-by: Christophe Leroy
>>
>>> Hello Christophe. Hope you don't mind I put you SoB tag because
Le 11/03/2024 à 14:20, Stefan Berger a écrit :
> linux,sml-base holds the address of a buffer with the TPM log. This
> buffer may become invalid after a kexec. To avoid accessing an invalid
> address or corrupted buffer, embed the whole TPM log in the device tree
> property linux,sml-log. This
Le 06/03/2024 à 11:41, pet...@redhat.com a écrit :
> From: Peter Xu
>
> [based on akpm/mm-unstable latest commit a7f399ae964e]
>
> In previous work [1], we removed the pXd_large() API, which is arch
> specific. This patchset further removes the hugetlb pXd_huge() API.
>
> Hugetlb was never
Le 09/03/2024 à 08:25, Athira Rajeev a écrit :
> The function get_dwarf_regnum() returns a DWARF register number
> from a register name string. This calls arch specific function
> get_arch_regnum to return register number for corresponding arch.
> Add mappings for register name to register
Le 09/03/2024 à 08:25, Athira Rajeev a écrit :
> Add powerpc instruction nmemonic table to associate load/store
> instructions with move_ops. mov_ops is used to identify mem_type
> to associate instruction with data type and offset. Also initialize
> and allocate arch specific fields for
Le 08/03/2024 à 14:14, Adrian Hunter a écrit :
> [Vous ne recevez pas souvent de courriers de adrian.hun...@intel.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Consolidate vdso_calc_delta(), in preparation for further simplification.
>
>
builds
> frequently calling mutex_destroy() is just ignored which is safe for now
> but wrong formally and can lead to a problem if mutex_destroy() will be
> extended so introduce devm_mutex_init()
>
> Signed-off-by: George Stark
> Signed-off-by: Christophe Leroy
> ---
> Hell
Le 07/03/2024 à 06:32, Michael Ellerman a écrit :
> Christophe Leroy writes:
>> Le 06/03/2024 à 13:58, Michael Ellerman a écrit :
>>> If both CONFIG_SENSORS_AMS_PMU and CONFIG_SENSORS_AMS_I2C are unset,
>>> there is an unused variable warning in the ams driver:
>&g
Le 06/03/2024 à 13:58, Michael Ellerman a écrit :
> If both CONFIG_SENSORS_AMS_PMU and CONFIG_SENSORS_AMS_I2C are unset,
> there is an unused variable warning in the ams driver:
>
>drivers/macintosh/ams/ams-core.c: In function 'ams_init':
>drivers/macintosh/ams/ams-core.c:181:29:
:
>> On 2/23/24 00:38, Christophe Leroy wrote:
>>> Le 22/02/2024 à 18:07, Sean Anderson a écrit :
>>>> [Vous ne recevez pas souvent de courriers de sean.ander...@linux.dev.
>>>> Découvrez pourquoi ceci est important à
>>>> https://aka.ms/LearnAboutSenderI
h/powerpc/include/asm/pgtable.h. because similar
> fallback macros for pXd_leaf() are already defined in
> include/linux/pgtable.h.
>
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: "Aneesh Kumar K.V"
> Cc: "Naveen N. Rao"
> Cc: linuxppc-dev@lists.
macro to pXd_leaf().
> Define it unconditionally just like pXd_leaf(). This helps to prepare
> merging the two APIs.
>
> Cc: Michael Ellerman
> Cc: Nicholas Piggin
> Cc: Christophe Leroy
> Cc: "Aneesh Kumar K.V"
> Cc: "Naveen N. Rao"
> Cc: linuxppc-
filter opcode 0006 (@1) unsupported
jited:0 261 PASS
test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed]
Fix them by adding missing processing.
Fixes: daabb2b098e0 ("bpf/tests: add tests for cpuv4 instructions")
Signed-off-by: Christophe Leroy
---
arch/powerpc/incl
Le 05/03/2024 à 11:04, Thomas Zimmermann a écrit :
> Hi
>
> Am 05.03.24 um 10:25 schrieb Christophe Leroy:
>>
>> Le 05/03/2024 à 10:01, Thomas Zimmermann a écrit :
>>> Replace with a forward declaration in to
>>> resolves an unnecessary depende
Le 05/03/2024 à 10:01, Thomas Zimmermann a écrit :
> Replace with a forward declaration in to
> resolves an unnecessary dependency. Remove pmac_backlight_curve_lookup()
> and struct fb_info from source and header files. The function and the
> framebuffer struct is unused. No functional
1 - 100 of 9537 matches
Mail list logo
