Hi, Yury
On 2016/5/6 20:37, Yury Norov wrote:
On Fri, May 06, 2016 at 08:16:48PM +0800, Zhangjian (Bamvor) wrote:
Hi,
On 2016/4/6 6:08, Yury Norov wrote:
From: Andrew Pinski
Add a separate syscall-table for ILP32, which dispatches either to native
LP64 system call implementation or to compa
From: Kieran Bingham
Provide a worked example for utilising the lx_radix_tree_lookup function
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
Signed-off-by: Kieran Bingham
Signed-off-by: Jan Kiszka
---
Documentation/gdb-kernel-debugging.txt | 21 +
1 file changed, 21 i
Hi,
Sorry I forget to paste my test code:
#include
#include
#include
#include
#define TEMPFILE "mmapfile"
int main(int argc, char *argv[])
{
int fd;
void *addr;
unsigned long offset;
unsigned long size;
if (argc == 3) {
if (argv[1][0
Hi Andrew,
please include the following enhancements and fixed for the gdb scripts
in your queue.
This adds a number of new commands and helper functions, contributed by
Kieran, and fixes lx-dmesg for Python 3 as well as corrects the output
of lx-lsmod.
Kieran stepped up to support me significan
On Tuesday 10 May 2016 15:42:07 Zhangjian wrote:
> On 2016/5/6 20:37, Yury Norov wrote:
> > On Fri, May 06, 2016 at 08:16:48PM +0800, Zhangjian (Bamvor) wrote:
> >
> > AFAIR, here we don't shift offset, as it's 64-bit both in user-
> > and kernel-space,
> In your ilp32-2.22 branch, you wrapper mmap
On 25/04/16 03:24, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> Documentation/fb/udlfb.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt
> index 57d2f29..c985cb6 100644
> --- a/Documentation
Hi, Arnd
On 2016/5/10 16:36, Arnd Bergmann wrote:
On Tuesday 10 May 2016 15:42:07 Zhangjian wrote:
On 2016/5/6 20:37, Yury Norov wrote:
On Fri, May 06, 2016 at 08:16:48PM +0800, Zhangjian (Bamvor) wrote:
AFAIR, here we don't shift offset, as it's 64-bit both in user-
and kernel-space,
In you
On 09/05/2016 23:08, Tom Lendacky wrote:
> On 05/09/2016 10:13 AM, Paolo Bonzini wrote:
>>
>>
>> On 02/05/2016 20:31, Andy Lutomirski wrote:
>>> And did the SEV implementation remember to encrypt the guest register
>>> state? Because, if not, everything of importance will leak out
>>> through th
On Tuesday 10 May 2016 17:47:26 Zhangjian wrote:
> On 2016/5/10 16:36, Arnd Bergmann wrote:
> > On Tuesday 10 May 2016 15:42:07 Zhangjian wrote:
> >> On 2016/5/6 20:37, Yury Norov wrote:
>
> "include/uapi/asm-generic/posix_types.h" is uapi, we could not check
> "ARCH_32BIT_OFF_T" here. Besides, th
On Tue, May 10, 2016 at 01:23:35PM +0200, Paolo Bonzini wrote:
> It can send plaintext packets that will be stored encrypted in memory.
> (Of course the hypervisor can do that too if it has access to the guest
> network).
And then what?
You need to find out where exactly (which pages) got the pac
Hi,
On 2016/5/10 19:48, Arnd Bergmann wrote:
On Tuesday 10 May 2016 17:47:26 Zhangjian wrote:
On 2016/5/10 16:36, Arnd Bergmann wrote:
On Tuesday 10 May 2016 15:42:07 Zhangjian wrote:
On 2016/5/6 20:37, Yury Norov wrote:
"include/uapi/asm-generic/posix_types.h" is uapi, we could not check
"
On Tuesday 10 May 2016 20:39:41 Zhangjian wrote:
> Hi,
>
> On 2016/5/10 19:48, Arnd Bergmann wrote:
> > On Tuesday 10 May 2016 17:47:26 Zhangjian wrote:
> >> On 2016/5/10 16:36, Arnd Bergmann wrote:
> >>> On Tuesday 10 May 2016 15:42:07 Zhangjian wrote:
> On 2016/5/6 20:37, Yury Norov wrote:
On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote:
> The EFI tables are not encrypted and need to be accessed as such. Be sure
> to memmap them without the encryption attribute set. For EFI support that
> lives outside of the arch/x86 tree, create a routine that uses the __weak
> attribute so that
On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote:
> Is it not possible to maintain some kind of kernel virtual address
> mapping so memremap*() and friends can figure out when to twiddle the
> mapping attributes and map with/without encryption?
I guess we can move the sme_* specific st
On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote:
> Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define
> the padding used for the physical memory mapping section when KASLR
> memory is enabled. It ensures there is enough virtual address space when
> CONFIG_MEMORY_HOTPLUG is
On Tue, May 10, 2016 at 11:24 AM, Kees Cook wrote:
> On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote:
>> Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define
>> the padding used for the physical memory mapping section when KASLR
>> memory is enabled. It ensures there is eno
On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote:
> Randomizes the virtual address space of kernel memory sections (physical
> memory mapping, vmalloc & vmemmap) for x86_64. This security feature
> mitigates exploits relying on predictable kernel addresses. These
> addresses can be used to di
Signed-off-by: Geert Uytterhoeven
---
Documentation/vm/hugetlbpage.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index 54dd9b9c6c31aeed..6f3b3fa35613d900 100644
--- a/Documentation/vm/hugetlbpage.txt
Signed-off-by: Geert Uytterhoeven
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2d756aa471f33316..c01039b81d6eeb13 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -897,7 +897,7 @@ config MACH_STM32F429
Signed-off-by: Geert Uytterhoeven
---
drivers/spi/spi-dw-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-dw-pci.c b/drivers/spi/spi-dw-pci.c
index 332ccb0539a77710..ef7db75c92c13b34 100644
--- a/drivers/spi/spi-dw-pci.c
+++ b/drivers/spi/spi-dw-pci.c
@@ -
On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote:
> Move the KASLR entropy functions in x86/libray to be used in early
> kernel boot for KASLR memory randomization.
>
> Signed-off-by: Thomas Garnier
> ---
> Based on next-20160502
> ---
> arch/x86/boot/compressed/kaslr.c | 76 +++
On Tue, May 10, 2016 at 12:05 PM, Kees Cook wrote:
> On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote:
>> Move the KASLR entropy functions in x86/libray to be used in early
>> kernel boot for KASLR memory randomization.
>>
>> Signed-off-by: Thomas Garnier
>> ---
>> Based on next-20160502
>>
On Tue, May 10, 2016 at 11:53 AM, Kees Cook wrote:
> On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote:
>> Randomizes the virtual address space of kernel memory sections (physical
>> memory mapping, vmalloc & vmemmap) for x86_64. This security feature
>> mitigates exploits relying on predicta
Hi,
On 2016/5/10 20:50, Arnd Bergmann wrote:
On Tuesday 10 May 2016 20:39:41 Zhangjian wrote:
Hi,
On 2016/5/10 19:48, Arnd Bergmann wrote:
On Tuesday 10 May 2016 17:47:26 Zhangjian wrote:
On 2016/5/10 16:36, Arnd Bergmann wrote:
On Tuesday 10 May 2016 15:42:07 Zhangjian wrote:
On 2016/5/6
On 2016/5/5 16:32, Michal Hocko wrote:
> On Thu 05-05-16 16:15:01, Qiang Huang wrote:
>> We don't have this restriction for a long time, docs should
>> be fixed.
>>
>> Signed-off-by: Qiang Huang
>> ---
>> Documentation/cgroup-v1/memory.txt | 8 +++-
>> 1 file changed, 3 insertions(+), 5 dele
The restriction of kmem setting is not there anymore because the
accounting is enabled by default even in the cgroup v1 - see
b313aeee2509 ("mm: memcontrol: enable kmem accounting for all
cgroups in the legacy hierarchy").
Update docs accordingly.
Signed-off-by: Qiang Huang
---
Documentation/cg
On Wed 11-05-16 14:07:31, Qiang Huang wrote:
> The restriction of kmem setting is not there anymore because the
> accounting is enabled by default even in the cgroup v1 - see
> b313aeee2509 ("mm: memcontrol: enable kmem accounting for all
> cgroups in the legacy hierarchy").
>
> Update docs accord
27 matches
Mail list logo
