On 03/09/2024 18.30, Andrew Jones wrote:
The spec says unaligned accesses are supported, so this isn't required
and clang doesn't support it. A platform might have slow unaligned
accesses, but kvm-unit-tests isn't about speed anyway.
Signed-off-by: Andrew Jones
---
riscv/Makefile | 2 +-
1 f
On 03/09/2024 18.30, Andrew Jones wrote:
Test building 32 and 64-bit with clang. Throw a test of in- and out-
of-tree building in too by swapping which is done to which (32-bit
vs. 64-bit) with respect to the gcc build tests.
Signed-off-by: Andrew Jones
---
.gitlab-ci.yml | 28 +++
On 03/09/2024 18.30, Andrew Jones wrote:
When a user specifies the compiler with --cc assume it's already
fully named, even if the user also specifies a cross-prefix. This
allows clang to be selected for the compiler, which doesn't use
prefixes, but also still provide a cross prefix for binutils.
Mark Brown writes:
> In preparation for using vm_flags to ensure guard pages for shadow stacks
> supply them as an argument to generic_get_unmapped_area(). The only user
> outside of the core code is the PowerPC book3s64 implementation which is
> trivially wrapping the generic implementation in th
Replace kthread_create/kthread_bind/wake_up_process() with
kthread_run_on_cpu() to simplify the code.
Signed-off-by: Hongbo Li
---
v2:
- Remove the extra parameter to solve the compilation.
- Change cpu from int type to unsigned int type.
v1:
https://lore.kernel.org/linux-arm-kernel/202409
On 2024/9/3 23:46, kernel test robot wrote:
Hi Hongbo,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20240902]
url:
https://github.com/intel-lab-lkp/linux/commits/Hongbo-Li/soc-fsl-qbman-make-use-of-the-helper-function-kthread_run_on_cpu/20240903
This 'struct kobj_type' is not modified. It is only used in
kobject_init_and_add() which takes a 'const struct kobj_type *ktype'
parameter.
Constifying this structure and moving it to a read-only section,
and can increase over all security.
Signed-off-by: Hongbo Li
---
drivers/misc/cxl/sysfs.c
On Tue, Sep 03, 2024 at 06:56:41PM GMT, Christophe Leroy wrote:
> Le 30/08/2024 à 16:21, Ma Ke a écrit :
> > Zero and negative number is not a valid IRQ for in-kernel code and the
> > irq_of_parse_and_map() function returns zero on error. So this check for
> > valid IRQs should only accept values
On 9/2/24 21:08, Mark Brown wrote:
When we introduced arch_get_unmapped_area_vmflags() in 961148704acd
("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of
properly supporting guard pages for shadow stacks on x86_64, which uses
a custom arch_get_unmapped_area(). Equivalent feat
When a user specifies the compiler with --cc assume it's already
fully named, even if the user also specifies a cross-prefix. This
allows clang to be selected for the compiler, which doesn't use
prefixes, but also still provide a cross prefix for binutils. If
a user needs a prefix on the compiler t
Test building 32 and 64-bit with clang. Throw a test of in- and out-
of-tree building in too by swapping which is done to which (32-bit
vs. 64-bit) with respect to the gcc build tests.
Signed-off-by: Andrew Jones
---
.gitlab-ci.yml | 28
1 file changed, 28 insertions
The spec says unaligned accesses are supported, so this isn't required
and clang doesn't support it. A platform might have slow unaligned
accesses, but kvm-unit-tests isn't about speed anyway.
Signed-off-by: Andrew Jones
---
riscv/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Modify configure to allow --cc=clang and a cross-prefix to be specified
together (as well as --cflags). This allows compiling with clang, but
using cross binutils for everything else, including the linker. So far
tested on riscv 32- and 64-bit and aarch64 (with some hacks to the code
to get it to c
Unit tests would like to go nuts with the number of harts in order
to help shake out issues with hart number assumptions. Rather than
set a huge number that will only be used when a platform supports
a huge number or when QEMU is told to exceed the recommended
number of vcpus, make the number confi
Allow users to add additional CONFIG_* and override defaults
by concatenating a given file with #define's and #undef's to
lib/config.h
Signed-off-by: Andrew Jones
---
configure | 14 ++
1 file changed, 14 insertions(+)
diff --git a/configure b/configure
index 27ae9cc89657..7a1317d06
riscv already wants to change NR_CPUS sometimes, so a CONFIG_NR_CPUS,
which can be changed at compile time, would be helpful. We could just
provide support for that with the configure command line, but other
configurations will eventually come along (there are already two more
in another riscv bran
On Tue, Sep 03, 2024 at 03:41:49PM -0400, Liam R. Howlett wrote:
> * Mark Brown [240902 15:09]:
> > +static inline unsigned long stack_guard_placement(vm_flags_t vm_flags)
> > +{
> > + if (vm_flags & VM_SHADOW_STACK)
> > + return PAGE_SIZE;
> Is PAGE_SIZE is enough?
It's what x86 cu
* Mark Brown [240902 15:09]:
> As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow
> stack guard gap during placement") our current mmap() implementation does
> not take care to ensure that a new mapping isn't placed with existing
> mappings inside it's own guard gaps. This i
* Mark Brown [240902 15:09]:
> In preparation for using vm_flags to ensure guard pages for shadow stacks
> supply them as an argument to generic_get_unmapped_area(). The only user
> outside of the core code is the PowerPC book3s64 implementation which is
> trivially wrapping the generic implementa
* Mark Brown [240902 15:09]:
> When we introduced arch_get_unmapped_area_vmflags() in 961148704acd
> ("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of
> properly supporting guard pages for shadow stacks on x86_64, which uses
> a custom arch_get_unmapped_area(). Equivalent fea
On Tue, Sep 03, 2024 at 07:20:02PM GMT, Mark Brown wrote:
> On Tue, Sep 03, 2024 at 06:49:46PM +0100, Lorenzo Stoakes wrote:
> > On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
>
> > > On x86 there is a custom arch_get_unmapped_area() which was updated by the
> > > above commit to cover t
On Tue, Sep 03, 2024 at 06:49:46PM +0100, Lorenzo Stoakes wrote:
> On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
> > On x86 there is a custom arch_get_unmapped_area() which was updated by the
> > above commit to cover this case by specifying a start_gap for allocations
> > with VM_SHAD
Hi Hongbo,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20240902]
url:
https://github.com/intel-lab-lkp/linux/commits/Hongbo-Li/soc-fsl-qbman-make-use-of-the-helper-function-kthread_run_on_cpu/20240903-060257
base: next-20240902
patch link
On Mon, Sep 02, 2024 at 08:08:15PM GMT, Mark Brown wrote:
> As covered in the commit log for c44357c2e76b ("x86/mm: care about shadow
> stack guard gap during placement") our current mmap() implementation does
> not take care to ensure that a new mapping isn't placed with existing
> mappings inside
On Mon, Sep 02, 2024 at 08:08:14PM GMT, Mark Brown wrote:
> In preparation for using vm_flags to ensure guard pages for shadow stacks
> supply them as an argument to generic_get_unmapped_area(). The only user
> outside of the core code is the PowerPC book3s64 implementation which is
> trivially wra
On Mon, Sep 02, 2024 at 08:08:13PM GMT, Mark Brown wrote:
> When we introduced arch_get_unmapped_area_vmflags() in 961148704acd
> ("mm: introduce arch_get_unmapped_area_vmflags()") we did so as part of
> properly supporting guard pages for shadow stacks on x86_64, which uses
> a custom arch_get_unm
Hi Charlie,
Le 29/08/2024 à 09:15, Charlie Jenkins a écrit :
The hint address and mmap_flags are necessary to determine if
MAP_BELOW_HINT requirements are satisfied.
Signed-off-by: Charlie Jenkins
---
arch/alpha/kernel/osf_sys.c | 2 ++
arch/arc/mm/mmap.c | 3 +++
arch/a
Le 30/08/2024 à 16:21, Ma Ke a écrit :
Zero and negative number is not a valid IRQ for in-kernel code and the
irq_of_parse_and_map() function returns zero on error. So this check for
valid IRQs should only accept values > 0.
unsigned int irq_of_parse_and_map(struct device_node *node, int in
Hi Hongbo,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20240902]
url:
https://github.com/intel-lab-lkp/linux/commits/Hongbo-Li/soc-fsl-qbman-make-use-of-the-helper-function-kthread_run_on_cpu/20240903-060257
base: next-20240902
patch link
On Tue, Sep 03, 2024 at 03:50:46PM +0100, Joey Gouly wrote:
> On Thu, Aug 29, 2024 at 06:55:07PM +0100, Mark Brown wrote:
> > On Thu, Aug 22, 2024 at 04:10:59PM +0100, Joey Gouly wrote:
> >
> > > +static bool fault_from_pkey(unsigned long esr, struct vm_area_struct
> > > *vma,
> > > +
On Mon, Sep 02, 2024 at 08:08:08PM +0100, Catalin Marinas wrote:
> On Tue, Aug 27, 2024 at 12:38:04PM +0100, Will Deacon wrote:
> > On Fri, Aug 23, 2024 at 07:40:52PM +0100, Catalin Marinas wrote:
> > > On Fri, Aug 23, 2024 at 06:08:36PM +0100, Will Deacon wrote:
> > > > On Fri, Aug 23, 2024 at 05:
On Thu, Aug 29, 2024 at 06:55:07PM +0100, Mark Brown wrote:
> On Thu, Aug 22, 2024 at 04:10:59PM +0100, Joey Gouly wrote:
>
> > +static bool fault_from_pkey(unsigned long esr, struct vm_area_struct *vma,
> > + unsigned int mm_flags)
> > +{
> > + unsigned long iss2 = ESR_ELx_ISS
On 2024/9/2 15:43, Pierre Gondois wrote:
> Hello Yicong
>
> On 8/30/24 11:35, Yicong Yang wrote:
>> On 2024/8/29 20:46, Pierre Gondois wrote:
>>> Hello Yicong,
>>>
>>> On 8/29/24 09:40, Yicong Yang wrote:
Hi Pierre,
On 2024/8/27 23:40, Pierre Gondois wrote:
> Hello Yicong,
>
On Tue, Sep 03, 2024 at 09:27:44AM +0200, Christoph Hellwig wrote:
> I've pulled this into the dma-mapping for-next tree, although I'd
> love to see one of the vdpa maintainers look over patch 1. I'm
> pretty sure it's correct, but a confirmation would be good.
Missed patch 1, I was wondering why
On Wed, Aug 28, 2024 at 09:10:28AM +0300, Christoph Hellwig wrote:
> vdpa_sim has been fixed to not override the dma_map_ops in commit
> 6c3d329e6486 ("vdpa_sim: get rid of DMA ops"), so don't select the
> symbol and don't depend on HAS_DMA.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Michael
On 02-09-24, 16:28, Liu Jing wrote:
> The word 'swtich' is wrong, so fix it.
>
> Signed-off-by: Liu Jing
> ---
> drivers/cpufreq/powernv-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied. Thanks.
--
viresh
Since commit 868941b14441 ("fs: remove no_llseek"), no_llseek() is
simply defined to be NULL, and a NULL llseek means seeking is
unsupported.
So for statically defined file_operations, such as all these, there's no
need or benefit to set llseek = no_llseek.
Signed-off-by: Michael Ellerman
---
a
Le 02/08/2024 à 04:16, Xiaolei Wang a écrit :
[Vous ne recevez pas souvent de courriers de xiaolei.w...@windriver.com.
Découvrez pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
RESERVEDMEM_OF_DECLARE usage has been removed. For
non-popwerpc platforms, such as l
Le 12/08/2024 à 09:25, Lu Baolu a écrit :
[Vous ne recevez pas souvent de courriers de baolu...@linux.intel.com.
Découvrez pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
An iommu domain is allocated in portal_set_cpu() and is attached to
pcfg->dev in the same
On Thu 29-08-24 10:33:22, Charlie Jenkins wrote:
> On Thu, Aug 29, 2024 at 10:30:56AM +0200, Michal Hocko wrote:
> > On Thu 29-08-24 00:15:57, Charlie Jenkins wrote:
> > > Some applications rely on placing data in free bits addresses allocated
> > > by mmap. Various architectures (eg. x86, arm64, p
Le 08/08/2024 à 09:10, Herve Codina a écrit :
Hi,
This series add support for the QUICC Engine (QE) version of TSA and QMC
components.
CPM1 version is already supported and, as the QE version of those
component are pretty similar to the CPM1 version, the series extend
the already existing dr
On Tue, Sep 3, 2024, at 06:36, Christophe Leroy wrote:
> Hi Arnd,
>
> Please pull the following Freescale Soc Drivers changes for 6.12
>
> There are no conflicts with latest linux-next tree.
Thanks, pulled now.
Arnd
I've pulled this into the dma-mapping for-next tree, although I'd
love to see one of the vdpa maintainers look over patch 1. I'm
pretty sure it's correct, but a confirmation would be good.
43 matches
Mail list logo
