`strncpy` is deprecated for use on NUL-terminated destination strings [1].
A suitable replacement is `memcpy` as we've already precisely calculated
the number of bytes to copy while `buf` has been explicitly
zero-initialized:
| char buf[8] = { 0 };
Link:
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
archsdk_defconfig gcc
arc randconfig-001-20230918 gcc
arc randconfig-001-20230919
Geert Uytterhoeven writes:
> Upstream Linux never had a "README.legal" file, but it was present
> in early source releases of Linux/m68k. It contained a simple copyright
> notice and a link to a version of the "COPYING" file that predated the
> addition of the "only valid GPL version is v2"
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20230918 gcc
arc randconfig-001-20230919 gcc
arm allmodconfig
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: c3f4309693758b13fbb34b3741c2e2801ad28769 powerpc/dexcr: Move
HASHCHK trap handler
elapsed time: 727m
configs tested: 146
configs skipped: 161
The following configs have been built
On Monday, September 18th, 2023 at 19:41, Segher Boessenkool
wrote:
> On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote:
>
> > ReiserFS has been considered deprecated for 19 months since commit
> > eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are
> > several
On Mon, Sep 18, 2023, Michael Roth wrote:
> On Wed, Sep 13, 2023 at 06:55:08PM -0700, Sean Christopherson wrote:
> > Add flags to "struct kvm_gfn_range" to let notifier events target only
> > shared and only private mappings, and write up the existing mmu_notifier
> > events to be shared-only
On Mon, Sep 18, 2023 at 05:56:09PM +, Peter Lafreniere wrote:
> ReiserFS has been considered deprecated for 19 months since commit
> eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are
> several architectures that still build it into their defconfig kernels.
>
> As ReiserFS will
On Wed, Sep 13, 2023 at 06:55:08PM -0700, Sean Christopherson wrote:
> Add flags to "struct kvm_gfn_range" to let notifier events target only
> shared and only private mappings, and write up the existing mmu_notifier
> events to be shared-only (private memory is never associated with a
> userspace
ReiserFS has been deprecated for a year and a half, yet is still built
as part of a defconfig kernel.
According to commit eb103a51640e ("reiserfs: Deprecate reiserfs"), the
filesystem is slated to be removed in 2025. Remove it from the defconfig
profiles now, as part of its deprecation process.
ReiserFS has been considered deprecated for 19 months since commit
eb103a51640e ("reiserfs: Deprecate reiserfs"). However, there are
several architectures that still build it into their defconfig kernels.
As ReiserFS will be removed in 2025, delete all ReiserFS-related options
from defconfig
On Wed, Sep 13, 2023 at 06:55:12PM -0700, Sean Christopherson wrote:
> TODO
>
> Cc: Fuad Tabba
> Cc: Vishal Annapurve
> Cc: Ackerley Tng
> Cc: Jarkko Sakkinen
> Cc: Maciej Szmigiero
> Cc: Vlastimil Babka
> Cc: David Hildenbrand
> Cc: Quentin Perret
> Cc: Michael Roth
> Cc: Wang
> Cc:
Hi all,
I have added the kvm-ppc tree today from
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
branch topic/ppc-kvm
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgement of your code. The purpose of
On Mon, Sep 18, 2023 at 07:42:30PM +0800, Xi Ruoyao wrote:
> ...
> My workstation suffers from too much correctable AER reporting as well
> (related to Intel's errata "RPL013: Incorrectly Formed PCIe Packets May
> Generate Correctable Errors" and/or the motherboard design, I guess).
We should
On Mon, Sep 18, 2023 at 4:42 AM Xi Ruoyao wrote:
>
> On Mon, 2023-08-14 at 08:40 -0700, Grant Grundler wrote:
> > On Sat, Aug 12, 2023 at 5:45 PM David Heidelberg
> > wrote:
> > >
> > > Tested-by: David Heidelberg
> >
> > Thanks David!
> >
> > > For PATCH v4 please fix the typo reported by the
On Mon, Sep 18, 2023 at 08:52:40AM -0700, Sean Christopherson wrote:
> > I wonder if we should be making the VFIO drivers that need the kvm to
> > ask for it? 'select CONFIG_NEED_VFIO_KVM' or something?
>
> I wondered the same thing, if only to make it easier to track which
> drivers actually
On Mon, Sep 18, 2023 at 08:49:57AM -0700, Sean Christopherson wrote:
> On Mon, Sep 18, 2023, Jason Gunthorpe wrote:
> > On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote:
> > > Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to
> > > VFIO instead of having VFIO
On Mon, Sep 18, 2023, Binbin Wu wrote:
>
>
> On 9/14/2023 9:55 AM, Sean Christopherson wrote:
> > Add flags to "struct kvm_gfn_range" to let notifier events target only
> > shared and only private mappings, and write up the existing mmu_notifier
> > events to be shared-only (private memory is
On Mon, Sep 18, 2023, Jason Gunthorpe wrote:
> On Fri, Sep 15, 2023 at 05:30:58PM -0700, Sean Christopherson wrote:
> > Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if
> > and only if VFIO itself is enabled. Similar to the recent change to have
> > VFIO stop looking at
On Mon, Sep 18, 2023, Jason Gunthorpe wrote:
> On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote:
> > Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to
> > VFIO instead of having VFIO do a symbol lookup back into KVM. Having both
> > KVM and VFIO do symbol
On Fri, Sep 15, 2023 at 05:30:58PM -0700, Sean Christopherson wrote:
> Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if
> and only if VFIO itself is enabled. Similar to the recent change to have
> VFIO stop looking at HAVE_KVM, compiling in support for talking to VFIO
> just
On Fri, Sep 15, 2023 at 05:30:57PM -0700, Sean Christopherson wrote:
> Explicitly pass KVM's get/put helpers to VFIO when attaching a VM to
> VFIO instead of having VFIO do a symbol lookup back into KVM. Having both
> KVM and VFIO do symbol lookups increases the overall complexity and places
> an
On Fri, Sep 15, 2023 at 05:30:55PM -0700, Sean Christopherson wrote:
> Hide vfio_file_set_kvm() and its unique helpers if KVM is not enabled,
> nothing else in the kernel (or out of the kernel) should be using a
> KVM specific helper.
>
> Signed-off-by: Sean Christopherson
> ---
>
On Fri, Sep 15, 2023 at 05:30:54PM -0700, Sean Christopherson wrote:
> Move the definitions of vfio_device_get_kvm_safe() and vfio_device_put_kvm()
> down in vfio_main.c to colocate them with other KVM-specific functions,
> e.g. to allow wrapping them all with a single CONFIG_KVM check.
>
>
On Fri, Sep 15, 2023 at 05:30:53PM -0700, Sean Christopherson wrote:
> Wrap the helpers for getting references to KVM instances with a check on
> CONFIG_KVM being enabled, not on CONFIG_HAVE_KVM being defined. PPC does
> NOT select HAVE_KVM, despite obviously supporting KVM, and guarding code
>
Update the documentation for trusted and encrypted KEYS with DCP as new
trust source:
- Describe security properties of DCP trust source
- Describe key usage
- Document blob format
Co-developed-by: Richard Weinberger
Signed-off-by: Richard Weinberger
Co-developed-by: David Oberhollenzer
DCP is capable to performing AES with hardware-bound keys.
These keys are not stored in main memory and are therefore not directly
accessible by the operating system.
So instead of feeding the key into DCP, we need to place a
reference to such a key before initiating the crypto operation.
Keys
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/
v2 is here:
https://lore.kernel.org/keyrings/2023091215.24274-1-da...@sigma-star.at/
v2 -> v3:
- Addressed review comments from Jarkko
DCP (Data Co-Processor) is the little brother of NXP's CAAM IP.
Beside of accelerated crypto operations, it also offers support for
hardware-bound keys. Using this feature it is possible to implement a blob
mechanism just like CAAM offers. Unlike on CAAM, constructing and
parsing the blob has to
On Thu, Sep 14, 2023 at 10:02:04PM +0530, Athira Rajeev wrote:
Add a function dt_find_by_name_before_addr() that returns the child node if
it matches till first occurrence at "@" of a given name, otherwise NULL.
This is helpful for cases with node name like: "name@addr". In
scenarios where nodes
On Fri, 15 Sep 2023 17:31:10 -0700
Sean Christopherson wrote:
> Don't add virt/kvm to KVM s390's include path, the headers in virt/kvm are
> intended to be used only by other code in virt/kvm, i.e. are "private" to
> the core KVM code. It's not clear that s390 *ever* included a header from
>
On Fri, 15 Sep 2023 17:31:02 -0700
Sean Christopherson wrote:
> Now that nothing in s390 or architecture agnostic code consumes HAVE_KVM,
> stop selecting it in s390. This is one of several steps towards deleting
> HAVE_KVM from the common KVM Kconfig.
>
> Signed-off-by: Sean Christopherson
>
On Mon, 2023-08-14 at 08:40 -0700, Grant Grundler wrote:
> On Sat, Aug 12, 2023 at 5:45 PM David Heidelberg
> wrote:
> >
> > Tested-by: David Heidelberg
>
> Thanks David!
>
> > For PATCH v4 please fix the typo reported by the bot :)
>
> Sorry - I'll do that today.
Hi Grant,
Is there an
Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k. It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.
Get rid of the references to
Hi all,
Several source files contain license boilerplate that refers to the file
"README.legal", which never existed in upstream Linux. This is a relic
from the early port of Linux to the m68k processor family, before it was
merged in v1.3.94. Later, copies of this boilerplate ended up
Upstream Linux never had a "README.legal" file, but it was present
in early source releases of Linux/m68k. It contained a simple copyright
notice and a link to a version of the "COPYING" file that predated the
addition of the "only valid GPL version is v2" clause.
Get rid of the references to
On Mon, Sep 18, 2023 at 10:29:30AM +0206, John Ogness wrote:
> On 2023-09-14, John Ogness wrote:
> > Provide and use wrapper functions for spin_[un]lock*(port->lock)
> > invocations so that the console mechanics can be applied later on at a
> > single place and does not require to copy the same
On 2023-09-14, John Ogness wrote:
> Provide and use wrapper functions for spin_[un]lock*(port->lock)
> invocations so that the console mechanics can be applied later on at a
> single place and does not require to copy the same logic all over the
> drivers.
For the full 74-patch series:
Hi, all folks,
Error reporting and recovery are one of the important features of PCIe, and
the kernel has been supporting them since version 2.6, 17 years ago.
I am very curious about the expected behavior of the software.
I first recap the error classification and then list my questions bellow
On Tue, 12 Sep 2023 13:04:56 +0200
Linus Walleij wrote:
> Hi Herve,
>
> thanks for your patch!
>
> On Tue, Sep 12, 2023 at 12:15 PM Herve Codina
> wrote:
>
> > The Lantiq PEF2256 is a framer and line interface component designed to
> > fulfill all required interfacing between an analog
On Mon, 18 Sep 2023 09:49:19 +0200
Herve Codina wrote:
> Hi Christophe,
>
> On Tue, 12 Sep 2023 18:49:26 +
> Christophe Leroy wrote:
>
> > Le 12/09/2023 à 20:13, Conor Dooley a écrit :
> > > Yo,
> > >
> > > I'm not au fait enough with this to leave particularly meaningful
> > >
On 9/14/2023 9:55 AM, Sean Christopherson wrote:
From: Chao Peng
[...]
+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
+/*
+ * Returns true if _all_ gfns in the range [@start, @end) have attributes
+ * matching @attrs.
+ */
+bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t
Hi Christophe,
On Tue, 12 Sep 2023 18:49:26 +
Christophe Leroy wrote:
> Le 12/09/2023 à 20:13, Conor Dooley a écrit :
> > Yo,
> >
> > I'm not au fait enough with this to leave particularly meaningful
> > comments, so just some minor ones for you.
> >
> > On Tue, Sep 12, 2023 at 12:14:44PM
Hi Conor,
On Wed, 13 Sep 2023 15:59:41 +0100
Conor Dooley wrote:
> On Wed, Sep 13, 2023 at 03:56:16PM +0100, Conor Dooley wrote:
> > On Wed, Sep 13, 2023 at 04:52:50PM +0200, Herve Codina wrote:
> > > On Wed, 13 Sep 2023 15:42:45 +0100
> > > Conor Dooley wrote:
> > >
> > > > On Wed, Sep
Ping for a review.
I'd like to get at least the first two patches into the DRM git tree.
The PPC patches could later be merged through another tree.
Best regards
Thomas
Am 12.09.23 um 15:48 schrieb Thomas Zimmermann:
Clean up and rename fb_pgprotect() to work without struct file. Then
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make it select
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes inside
modules,
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULES and make
From: "Mike Rapoport (IBM)"
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/kernel/module.c and compile it when CONFIG_EXECMEM=y
Signed-off-by:
From: "Mike Rapoport (IBM)"
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As powerpc uses
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on RISC-V are not placed in
the modules area and these custom allocations are implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec().
Slightly reorder execmem_params initialization to support both 32 and
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF ranges in
From: "Mike Rapoport (IBM)"
Data related to code allocations, such as module data section, need to
comply with architecture constraints for its placement and its
allocation right now was done using execmem_text_alloc().
Create a dedicated API for allocating data related to code allocations
and
From: "Mike Rapoport (IBM)"
Define default parameters for address range for code allocations using
the current values in module_alloc() and make execmem_text_alloc() use
these defaults when an architecture does not supply its specific
parameters.
With this, execmem_text_alloc() implements
From: "Mike Rapoport (IBM)"
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc and support for allocation of KASAN shadow required by
arm64, s390 and x86.
The
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters
for address space ranges, required alignment and page
From: "Mike Rapoport (IBM)"
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystems
that need to allocate code, such as ftrace, kprobes and BPF to modules
and puts the burden of code allocation to the
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleixner
Acked-by:
From: "Mike Rapoport (IBM)"
Hi,
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystmes
that need to allocate code, such as ftrace, kprobes and BPF to modules and
puts the burden of code allocation to the
On 16/09/2023 02.31, Sean Christopherson wrote:
Don't add virt/kvm to KVM s390's include path, the headers in virt/kvm are
intended to be used only by other code in virt/kvm, i.e. are "private" to
the core KVM code. It's not clear that s390 *ever* included a header from
virt/kvm, i.e. odds are
60 matches
Mail list logo
