> Yes, obviously... I'll make that change locally and wait for the rest.
Another nit: You could use '--strict' with checkpatch and see if you
want to fix the issues reported. I am not keen on those (except for
'space around operators'), it's a matter of taste I guess, but maybe you
like some of th
On 2016-04-29 09:16, Wolfram Sang wrote:
>> Yes, obviously... I'll make that change locally and wait for the rest.
> Another nit: You could use '--strict' with checkpatch and see if you
> want to fix the issues reported. I am not keen on those (except for
> 'space around operators'), it's a matter
I'm trying to reduce the time taken in the kernel in initcalls, with
my aim being to reduce the current ~700ms spent in initcalls before
userspace, down to something like 100ms. All times on my Broadwell-U
laptop, under virtualization. The purpose of this is to be able to
launch VMs around contai
Running self-tests for a short-lived KVM VM takes 28ms on my laptop.
This commit adds a flag 'cryptomgr.notests' which allows them to be
disabled.
Signed-off-by: Richard W.M. Jones
---
Documentation/kernel-parameters.txt | 3 +++
crypto/testmgr.c| 9 +
2 files changed
Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones:
Hi Richard,
> Running self-tests for a short-lived KVM VM takes 28ms on my laptop.
> This commit adds a flag 'cryptomgr.notests' which allows them to be
> disabled.
>
> Signed-off-by: Richard W.M. Jones
> ---
> Documentation/kern
v1 -> v2:
- Use printk_once.
Because the serial console is so slow, printing the message multiple
times consumed about 6ms extra later on in the boot. Printing it only
once is both neater and avoids this extra overhead.
Rich.
- - -
I'm trying to reduce the time taken in the kernel in initcal
Running self-tests for a short-lived KVM VM takes 28ms on my laptop.
This commit adds a flag 'cryptomgr.notests' which allows them to be
disabled.
Signed-off-by: Richard W.M. Jones
---
Documentation/kernel-parameters.txt | 3 +++
crypto/testmgr.c| 9 +
2 files changed
On Fri, Apr 29, 2016 at 12:59:57PM +0200, Stephan Mueller wrote:
> Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones:
>
> Hi Richard,
[...]
> > + if (notests) {
>
> What about if (!fips_enabled && notests) ?
>
> I am not sure whether the kernel should prevent mistakes in user spac
On Fri, Apr 29, 2016 at 12:43:41AM +0200, Arnd Bergmann wrote:
> On Friday 29 April 2016 01:21:37 Yury Norov wrote:
> > index 1458ad7..410d817 100644
> > --- a/arch/arm64/kernel/sys_ilp32.c
> > +++ b/arch/arm64/kernel/sys_ilp32.c
> > @@ -17,6 +17,8 @@
> > * along with this program. If not, see
>
Hi Russell,
On Thu, Apr 28, 2016 at 2:57 PM, Russell King
wrote:
[...]
> + On arm, the use of "crashkernel=Y@X" is no longer necessary; the
> + kernel will automatically locate the crash kernel image within the
> + first 512MB of RAM if X is not given.
>
>
> Load the Dump-capture Kernel
On Thu, Apr 28, 2016 at 2:57 PM, Russell King
wrote:
> Signed-off-by: Russell King
> ---
> arch/arm/kernel/setup.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 77b54c461c52..d9317eec1eba 100644
> --- a/arch
On Thu, Apr 28, 2016 at 2:58 PM, Russell King
wrote:
> Provide a helper to indicate whether we need to perform special handling
> for boot identity mapping aliases or not.
>
> Signed-off-by: Russell King
> ---
> arch/arm/include/asm/memory.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff
On Thu, Apr 28, 2016 at 2:58 PM, Russell King
wrote:
> Ensure that user memory sizes do not wrap around when validating the
> user input, which can lead to the following input validation working
> incorrectly.
>
> Signed-off-by: Russell King
> ---
> kernel/kexec_core.c | 2 ++
> 1 file changed,
On Thu, Apr 28, 2016 at 2:58 PM, Russell King
wrote:
> If we are unable to find a suitable page when allocating the control
> page, do not invoke the OOM-killer: killing processes probably isn't
> going to help.
>
> Signed-off-by: Russell King
> ---
> include/linux/kexec.h | 2 +-
> 1 file chang
Hi Russell,
On Thu, Apr 28, 2016 at 2:58 PM, Russell King
wrote:
> Advertise the location of bootable RAM to kexec-tools. kexec needs to
> know where it can place the kernel in RAM, and so be executable when
> the system needs to jump into it.
>
> Advertise these areas in /proc/iomem with a "Sys
On Thu, Apr 28, 2016 at 2:58 PM, Russell King
wrote:
> On PAE systems (eg, ARM LPAE) the vmcore note may be located above
> 4GB physical on 32-bit architectures, so we need a wider type than
> "unsigned long" here. Arrange for paddr_vmcoreinfo_note() to return
> a phys_addr_t, thereby allowing it
On 04/29/2016 02:17 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 26, 2016 at 05:58:12PM -0500, Tom Lendacky wrote:
>> Since DMA addresses will effectively look like 48-bit addresses when the
>> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
>> device performing the DMA do
On Thu, Apr 28, 2016 at 2:58 PM, Russell King
wrote:
> kexec physical addresses are the boot-time view of the system. For
> certain ARM systems (such as Keystone 2), the boot view of the system
> does not match the kernel's view of the system: the boot view uses a
> special alias in the lower 4GB
On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> > + phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> > + return sprintf(buf, "%pa %x\n", &vmcore_base,
>
> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
The %pa* printk format specifiers take the value b
On Friday 29 April 2016 16:13:38 Yury Norov wrote:
> On Fri, Apr 29, 2016 at 12:43:41AM +0200, Arnd Bergmann wrote:
> > On Friday 29 April 2016 01:21:37 Yury Norov wrote:
> > >
> > > arch/arm64/kernel/sys_ilp32.c:59:0: warning: "__SYSCALL" redefined
> > > #define __SYSCALL(nr, sym) [nr] = sym,
>
On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> > + phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
>> > + return sprintf(buf, "%pa %x\n", &vmcore_base,
>>
>> Why do we pass &vmcore_base? Shouldn't it be vmcor
On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote:
> ILP32 VDSO exports next symbols:
> __kernel_rt_sigreturn;
> __kernel_gettimeofday;
> __kernel_clock_gettime;
> __kernel_clock_getres;
[...]
> +$(obj)/gettimeofday-ilp32.o: $(src)/../vdso/gettimeofday.S
> + $(call if_changed_dep
On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote:
> +config ARM64_ILP32
> + bool "Kernel support for ILP32"
> + select COMPAT_WRAPPER
> + help
> + This option enables support for AArch64 ILP32 user space. ILP32
> + is an ABI where long and pointers are 32bits but
On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote:
> On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote:
> > +config ARM64_ILP32
> > + bool "Kernel support for ILP32"
> > + select COMPAT_WRAPPER
> > + help
> > + This option enables support for AArch64 ILP32 user spac
On Fri, Apr 29, 2016 at 07:08:55PM +0300, Yury Norov wrote:
> On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote:
> > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote:
> > > +config ARM64_ILP32
> > > + bool "Kernel support for ILP32"
> > > + select COMPAT_WRAPPER
> > > + help
On Fri, Apr 29, 2016 at 05:14:46PM +0100, Catalin Marinas wrote:
> On Fri, Apr 29, 2016 at 07:08:55PM +0300, Yury Norov wrote:
> > On Fri, Apr 29, 2016 at 05:03:34PM +0100, Catalin Marinas wrote:
> > > On Wed, Apr 06, 2016 at 01:08:47AM +0300, Yury Norov wrote:
> > > > +config ARM64_ILP32
> > > > +
Any feedback on this patch proposal?
Thanks,
Thomas
On Mon, Apr 25, 2016 at 9:39 AM, Thomas Garnier wrote:
> This is PATCH v1 for KASLR memory implementation on x86_64. Minor changes
> were done based on RFC v1 comments.
>
> ***Background:
> The current implementation of KASLR randomizes only th
On Friday 29 April 2016 17:01:55 Catalin Marinas wrote:
> On Wed, Apr 06, 2016 at 01:08:46AM +0300, Yury Norov wrote:
> > ILP32 VDSO exports next symbols:
> > __kernel_rt_sigreturn;
> > __kernel_gettimeofday;
> > __kernel_clock_gettime;
> > __kernel_clock_getres;
>
> [...]
>
> > +$(obj)/getti
On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> Hi Russell,
>
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> wrote:
> > Advertise the location of bootable RAM to kexec-tools. kexec needs to
> > know where it can place the kernel in RAM, and so be executable when
> > the syst
On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> wrote:
> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> > index 152da4a48867..9f1920d2d0c6 100644
> > --- a/kernel/ksysfs.c
> > +++ b/kernel/ksysfs.c
> > @@ -128,8 +128,8 @@ KERNEL
On Fri, Apr 29, 2016 at 08:44:29PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> wrote:
> > kexec physical addresses are the boot-time view of the system. For
> > certain ARM systems (such as Keystone 2), the boot view of the system
> > does not match the kernel's
On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
> wrote:
> > Signed-off-by: Russell King
> > ---
> > arch/arm/kernel/setup.c | 5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/kernel/setup.c
On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > Intel(R) SGX is a set of CPU instructions that can be used by
> > applications to set aside private regions of code and data. The code
> > outside the enclave is disallowed to acc
On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > Intel(R) SGX is a set of CPU instructions that can be used by
> > applications to set aside private regions of code and data. The code
> > outside the enclave is disallowed to acc
On 04/29/2016 11:27 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 29, 2016 at 10:12:45AM -0500, Tom Lendacky wrote:
>> On 04/29/2016 02:17 AM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Apr 26, 2016 at 05:58:12PM -0500, Tom Lendacky wrote:
Since DMA addresses will effectively look like 48-bit a
On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
wrote:
> On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> Hi Russell,
>>
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> wrote:
>> > Advertise the location of bootable RAM to kexec-tools. kexec needs to
>> > know wh
On Fri, Apr 29, 2016 at 11:36 PM, Russell King - ARM Linux
wrote:
> On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> wrote:
>> > diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
>> > index 152da4a48867..9f1920d2d0c6 100644
>> > ---
On Fri, Apr 29, 2016 at 11:40 PM, Russell King - ARM Linux
wrote:
> On Fri, Apr 29, 2016 at 07:49:45PM +0530, Pratyush Anand wrote:
>> On Thu, Apr 28, 2016 at 2:57 PM, Russell King
>> wrote:
>> > Signed-off-by: Russell King
>> > ---
>> > arch/arm/kernel/setup.c | 5 +
>> > 1 file changed, 1
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Tom Lendacky
> Sent: Tuesday, April 26, 2016 5:56 PM
> Subject: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)
>
> This RFC patch series provides support fo
39 matches
Mail list logo
