Le 03/02/2022 à 06:39, Michael Ellerman a écrit :
> Luis Chamberlain writes:
>> On Thu, Jan 27, 2022 at 11:28:12AM +, Christophe Leroy wrote:
>>> book3s/32 and 8xx have a separate area for allocating modules,
>>> defined by MODULES_VADDR / MODULES_END.
>>>
>>> On book3s/32, it is not possibl
Le 03/02/2022 à 01:01, Luis Chamberlain a écrit :
> On Sat, Jan 29, 2022 at 05:02:09PM +, Christophe Leroy wrote:
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 11f51e17fb9f..f3758115ebaa 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -81,7 +81,9 @@
>> /* If this
Le 03/02/2022 à 00:48, Luis Chamberlain a écrit :
> On Sat, Jan 29, 2022 at 05:02:07PM +, Christophe Leroy wrote:
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 163e32e39064..11f51e17fb9f 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -81,6 +81,8 @@
>> /* If this
Luis Chamberlain writes:
> On Thu, Jan 27, 2022 at 11:28:12AM +, Christophe Leroy wrote:
>> book3s/32 and 8xx have a separate area for allocating modules,
>> defined by MODULES_VADDR / MODULES_END.
>>
>> On book3s/32, it is not possible to protect against execution
>> on a page basis. A full
Each call into pte_mkhuge() is invariably followed by arch_make_huge_pte().
Instead arch_make_huge_pte() can accommodate pte_mkhuge() at the beginning.
This updates generic fallback stub for arch_make_huge_pte() and available
platforms definitions. This makes huge pte creation much cleaner and easi
On Wed, Feb 2, 2022 at 3:52 PM Christoph Hellwig wrote:
>
> On Tue, Feb 01, 2022 at 11:05:39PM +0800, guo...@kernel.org wrote:
> > +bool compat_elf_check_arch(Elf32_Ehdr *hdr)
> > +{
> > + if (compat_mode_support && (hdr->e_machine == EM_RISCV))
> > + return true;
> > + else
>
On Sat, Jan 29, 2022 at 05:02:03PM +, Christophe Leroy wrote:
> This series allow architectures to request having modules data in
> vmalloc area instead of module area.
>
> This is required on powerpc book3s/32 in order to set data non
> executable, because it is not possible to set executabil
On Sat, Jan 29, 2022 at 05:02:09PM +, Christophe Leroy wrote:
> diff --git a/kernel/module.c b/kernel/module.c
> index 11f51e17fb9f..f3758115ebaa 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -81,7 +81,9 @@
> /* If this is set, the section belongs in the init part of the module *
On Sat, Jan 29, 2022 at 05:02:07PM +, Christophe Leroy wrote:
> diff --git a/kernel/module.c b/kernel/module.c
> index 163e32e39064..11f51e17fb9f 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -81,6 +81,8 @@
> /* If this is set, the section belongs in the init part of the module *
On 2/1/22 21:38, Anshuman Khandual wrote:
> Each call into pte_mkhuge() is invariably followed by arch_make_huge_pte().
> Instead arch_make_huge_pte() can accommodate pte_mkhuge() at the beginning.
> This updates generic fallback stub for arch_make_huge_pte() and available
> platforms definitions.
On Thu, Jan 27, 2022 at 11:28:12AM +, Christophe Leroy wrote:
> book3s/32 and 8xx have a separate area for allocating modules,
> defined by MODULES_VADDR / MODULES_END.
>
> On book3s/32, it is not possible to protect against execution
> on a page basis. A full 256M segment is either Exec or No
On Wed, Jan 26, 2022 at 06:38:30AM +, Christophe Leroy wrote:
>
>
> Le 25/01/2022 à 22:10, Luis Chamberlain a écrit :
> > On Mon, Jan 24, 2022 at 09:22:34AM +, Christophe Leroy wrote:
> >> This can also be useful on other powerpc/32 in order to maximize the
> >> chance of code being close
On Wed, Feb 02, 2022 at 09:36:53AM +0100, Gerd Hoffmann wrote:
> Having a "secrets/" directory looks good to me. Then the individual
> implementations can either add files to the directory, i.e. efi_secrets
> would create "secrets/" files. Or each implementation creates a
> subdirectory with the
On Wed, Feb 02, 2022 at 08:22:03AM +0100, Ard Biesheuvel wrote:
> On Wed, 2 Feb 2022 at 08:10, Matthew Garrett wrote:
> > Which other examples are you thinking of? I think this conversation may
> > have accidentally become conflated with a different prior one and now
> > we're talking at cross pur
On Wed, Feb 02, 2022 at 08:05:23AM +0100, Greg KH wrote:
> I see different platform patches trying to stick these blobs in
> different locations and ways to access (securityfs, sysfs, char device
> node), which seems crazy to me. Why can't we at least pick one way to
> access these to start with,
On Wed, Feb 02, 2022 at 07:10:02AM +0100, Greg KH wrote:
> On Wed, Feb 02, 2022 at 04:01:57AM +, Matthew Garrett wrote:
> > We're talking about things that have massively different semantics.
>
> I see lots of different platforms trying to provide access to their
> "secure" firmware data to us
On Tue, Feb 01, 2022 at 09:24:50AM -0500, James Bottomley wrote:
> On Tue, 2022-02-01 at 14:50 +0100, Greg KH wrote:
> > You all need to work together to come up with a unified place for
> > this and stop making it platform-specific.
We're talking about things that have massively different semanti
On 1/20/22 10:01 AM, Fabiano Rosas wrote:
This adds the infrastructure for writing tests for the powerpc
platform (Only Radix MMU for now).
This patch also enables two tests:
- a dummy sample test that creates a guest with one vcpu, issues
hypercalls and reads/writes test values from memory.
On Wed, 2 Feb 2022 00:45:35 +0100, Linus Walleij wrote:
> My patch created compilation bugs in the MPC512x-PSC driver.
> Fix them up.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: mpc512x-psc: Fix compile errors
commit: 8d3
On Wed, Feb 02, 2022 at 01:25:28PM +0100, David Hildenbrand wrote:
> That's the whole idea for being able to allocate parts of an unmovable
> pageblock that are movable.
>
> If the first part is unmovable but the second part is movable, nothing
> should stop us from trying to allocate the second p
On 2 Feb 2022, at 7:25, David Hildenbrand wrote:
> On 02.02.22 13:18, Oscar Salvador wrote:
>> On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote:
>>> From: Zi Yan
>>>
>>> Enable set_migratetype_isolate() to check specified sub-range for
>>> unmovable pages during isolation. Page isolation is
On 01/02/22 17:14, Michael Ellerman wrote:
Sourabh Jain writes:
On large config LPARs (having 192 and more cores), Linux fails to boot
due to insufficient memory in the first memblock. It is due to the
memory reservation for the crash kernel which starts at 128MB offset of
the first memblock.
On 28.01.22 16:15, David Hildenbrand wrote:
> ... and call node_dev_init() after memory_dev_init() from driver_init(),
> so before any of the existing arch/subsys calls. All online nodes should
> be known at that point.
>
> This is in line with memory_dev_init(), which initializes the memory
> dev
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/topic/ppc-kvm]
[also build test ERROR on powerpc/next v5.17-rc2 next-20220202]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
On 02.02.22 13:18, Oscar Salvador wrote:
> On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote:
>> From: Zi Yan
>>
>> Enable set_migratetype_isolate() to check specified sub-range for
>> unmovable pages during isolation. Page isolation is done
>> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) g
On Wed, Jan 19, 2022 at 02:06:19PM -0500, Zi Yan wrote:
> From: Zi Yan
>
> Enable set_migratetype_isolate() to check specified sub-range for
> unmovable pages during isolation. Page isolation is done
> at max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) granularity, but not all
> pages within that gra
On 2/2/22 11:50 AM, Christophe Leroy wrote:
>
> Le 02/02/2022 à 06:38, Anshuman Khandual a écrit :
>> Each call into pte_mkhuge() is invariably followed by arch_make_huge_pte().
>> Instead arch_make_huge_pte() can accommodate pte_mkhuge() at the beginning.
>> This updates generic fallback stub
Vaibhav Jain writes:
> Presently PAPR doesn't support injecting smart errors on an
> NVDIMM. This makes testing the NVDIMM health reporting functionality
> difficult as simulating NVDIMM health related events need a hacked up
> qemu version.
>
> To solve this problem this patch proposes simulatin
Hi,
> The only thing I personally struggle with here is whether "coco" is the
> best name for it, and whether there are reasonable use cases that
> wouldn't be directly related to confidential computing (eg, if the
> firmware on a bare-metal platform had a mechanism for exposing secrets
> t
On Wed, Feb 02, 2022 at 08:04:01AM +, Matthew Garrett wrote:
> On Wed, Feb 02, 2022 at 08:22:03AM +0100, Ard Biesheuvel wrote:
> > On Wed, 2 Feb 2022 at 08:10, Matthew Garrett wrote:
> > > Which other examples are you thinking of? I think this conversation may
> > > have accidentally become co
30 matches
Mail list logo
