Re: [PATCH v5 1/1] ARM64: ACPI: Update documentation for latest specification version

On 2016/4/26 5:21, Al Stone wrote: The ACPI 6.1 specification was recently released at the end of January 2016, but the arm64 kernel documentation for the use of ACPI was written for the 5.1 version of the spec. There were significant additions to the spec that had not yet been mentioned -- for

Re: [PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

On Mon, May 2, 2016 at 1:19 PM, Al Stone wrote: > On 04/25/2016 03:21 PM, Al Stone wrote: >> The ACPI 6.1 specification was recently released at the end of January >> 2016, but the arm64 kernel documentation for the use of ACPI was written >> for the 5.1 version of the spec.

Re: [PATCH v5 1/4] x86, boot: Refactor KASLR entropy functions

Hi, [auto build test WARNING on next-20160512] [cannot apply to tip/x86/core v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-boot-KASLR

[PATCH v5 1/4] x86, boot: Refactor KASLR entropy functions

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-20160511 --- arch/x86/boot/compressed/kaslr.c | 77 +++--- arch/x86/include/asm/kaslr.h

[PATCH v5 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

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 used. The default value is 10 terabytes. If

[PATCH v5 0/4] x86, boot: KASLR memory randomization

This is PATCH v5 for KASLR memory implementation for x86_64. Recent changes: Add performance information on commit. Add details on PUD alignment. Add information on testing against the KASLR bypass exploit. Rebase on next-20160511 and merge recent KASLR changes. Integrate

[PATCH v5 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expect the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD table. It has no impact on current usage.

Re: [PATCH v4 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Hi, [auto build test ERROR on next-20160512] [cannot apply to tip/x86/core v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-boot-KASLR

[PATCH v4 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expect the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD table. It has no impact on current usage.

[PATCH v4 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

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 used. The default value is 10 terabytes. If

[PATCH v4 0/4] x86, boot: KASLR memory randomization

This is PATCH v4 for KASLR memory implementation for x86_64. Recent changes: Add performance information on commit. Add details on PUD alignment. Add information on testing against the KASLR bypass exploit. Rebase on next-20160511 and merge recent KASLR changes. Integrate

Re: [PATCH] Documentation/memcg: update kmem limit doc as codes behavior

On Wed, May 11, 2016 at 08:40:19AM +0200, Michal Hocko wrote: > 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

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Thu, May 12, 2016 at 05:24:57PM +0300, Yury Norov wrote: > On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote: > > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote: > > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > > > > On Thu, May 12, 2016 at

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote: > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote: > > > > I debugged preadv02 and

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote: > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote: > > > > I debugged preadv02 and

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote: > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote: > > > I debugged preadv02 and pwritev02 failures and found very weird bug. > > > Test passes {iovec_base =

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote: > > I debugged preadv02 and pwritev02 failures and found very weird bug. > > Test passes {iovec_base = 0x, iovec_len = 64} as one element > > of vector, and kernel

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thu, May 12, 2016 at 03:06:39PM +0200, Arnd Bergmann wrote: > On Thursday 12 May 2016 20:49:24 Zhangjian wrote: > > Hi, > > > > On 2016/5/12 17:21, Arnd Bergmann wrote: > > > On Thursday 12 May 2016 10:17:58 Catalin Marinas wrote: > > >> On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann

[PATCH 1/9] kernel-doc: rewrite usage description, remove duplicated comments

Instead of having the kernel-doc usage in both comments and in output to the user, merge them all to one here document. While at it, imrove the text and make it pretty. Give shoemaker's children some shoes. Signed-off-by: Jani Nikula --- scripts/kernel-doc | 83

[PATCH 3/9] kernel-doc: use rst C domain directives and references for types

First, the headings for structs, enums and typedefs will be similar to functions. Second, this provides a kind of namespace for cross references. Third, and most importantly, the return and parameter types from .. c:function:: definitions will automagically become cross references to the

[PATCH 2/9] kernel-doc: produce RestructuredText output

From: Jonathan Corbet If given the -rst flag, output will now be in RestructuredText. Various glitches to be worked out yet. In the end I decided not to use RST section headings within the kerneldoc comments. gpu.tmpl already has headings five levels deep; adding more is not

[PATCH 8/9] docproc: add support for reStructuredText format via --rst option

Expect reStructuredText input and have kernel-doc produce reStructuredText output with the new --rst option. Also add --docbook option for completeness. If no option is given, default to reStructuredText if the input file has ".rst" extension, DocBook otherwise. Directives for reStructuredText

[PATCH 7/9] docproc: abstract terminating lines at first space

Cleaner code. Also fixes a bug when F or P directives didn't in fact have space. Signed-off-by: Jani Nikula --- scripts/docproc.c | 34 +- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/scripts/docproc.c b/scripts/docproc.c

[PATCH 6/9] docproc: abstract docproc directive detection

Helps follow-up work. No functional changes. Signed-off-by: Jani Nikula --- scripts/docproc.c | 30 -- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/scripts/docproc.c b/scripts/docproc.c index fb195f0ed0ef..bc900310b431 100644

[PATCH 0/9] kernel-doc/docproc prep work for reStructuredText

Jon, I was hoping we could consider nudging things forward a bit in the kernel-doc and docproc reStructuredText front already in 4.7. I know it's a bit close to the merge window, but this should not interfere with anything else, and some of it are just trivial cleanups that I've been carrying

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 May 2016 20:49:24 Zhangjian wrote: > Hi, > > On 2016/5/12 17:21, Arnd Bergmann wrote: > > On Thursday 12 May 2016 10:17:58 Catalin Marinas wrote: > >> On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann wrote: > >>> On Wednesday 11 May 2016 17:59:01 Catalin Marinas wrote: > >>>

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Hi, On 2016/5/12 16:24, Yury Norov wrote: On Thu, May 12, 2016 at 11:45:53AM +0800, Zhangjian (Bamvor) wrote: [...] Hmm, that is indeed tricky. I think COMPAT_SYSCALL_WRAP4 rightfully refuses the loff_t argument here, as the common case is that this is not possible. It works if I apply the

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

Hi, On 2016/5/12 17:21, Arnd Bergmann wrote: On Thursday 12 May 2016 10:17:58 Catalin Marinas wrote: On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann wrote: On Wednesday 11 May 2016 17:59:01 Catalin Marinas wrote: I don't think the shifts are a problem, the main downside would be the

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Thu, May 12, 2016 at 11:19:21AM +0200, Arnd Bergmann wrote: > On Thursday 12 May 2016 03:20:00 Yury Norov wrote: > > > > I debugged preadv02 and pwritev02 failures and found very weird bug. > > Test passes {iovec_base = 0x, iovec_len = 64} as one element > > of vector, and kernel

Re: [PATCH nf-next] netfilter: allow logging from non-init namespaces

Hi Michal, On Wed, Apr 27, 2016 at 02:48:02PM +0200, Michal Kubecek wrote: > Commit 69b34fb996b2 ("netfilter: xt_LOG: add net namespace support for > xt_LOG") disabled logging packets using the LOG target from non-init > namespaces. The motivation was to prevent containers from flooding > kernel

Re: [RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

On Wed, 2016-05-04 at 09:29 +0200, Pavel Machek wrote: >  > If userspace wants to control the manually, it can do just that -- > control it manually. There should not be a need to "override the > default policy". I'm still not buying this. In the original situation, without these patches,

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thursday 12 May 2016 10:17:58 Catalin Marinas wrote: > On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann wrote: > > On Wednesday 11 May 2016 17:59:01 Catalin Marinas wrote: > > > > I don't think the shifts are a problem, the main downside would be > > the limit to 44 bits of file offsets

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

On Thursday 12 May 2016 03:20:00 Yury Norov wrote: > > I debugged preadv02 and pwritev02 failures and found very weird bug. > Test passes {iovec_base = 0x, iovec_len = 64} as one element > of vector, and kernel reports successful read/write. > > There are 2 problems: > 1. How kernel

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann wrote: > On Wednesday 11 May 2016 17:59:01 Catalin Marinas wrote: > > On Wed, May 11, 2016 at 12:55:01PM +0200, Arnd Bergmann wrote: > > > On Wednesday 11 May 2016 11:04:38 Yury Norov wrote: > > > > On Wed, May 11, 2016 at 10:04:16AM +0800,

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Mon, May 09, 2016 at 08:27:04AM +0200, Thomas Gleixner wrote: Good morning. > > On Fri, 6 May 2016, Jarkko Sakkinen wrote: > > I fully understand if you (and others) want to keep this standpoint but > > what if we could get it to staging after I've revised it with suggested > > > This should

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Thu, May 12, 2016 at 11:45:53AM +0800, Zhangjian (Bamvor) wrote: [...] > >Hmm, that is indeed tricky. I think COMPAT_SYSCALL_WRAP4 rightfully > >refuses the loff_t argument here, as the common case is that this is > >not possible. > It works if I apply the following patch, I defined the wrong

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

On Thu, May 12, 2016 at 02:26:27PM +0800, Baoquan He wrote: > On 04/28/16 at 10:28am, Russell King wrote: > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > > index 52a3a221bcb2..99cb9dac7909 100644 > > --- a/include/linux/kexec.h > > +++ b/include/linux/kexec.h > > @@ -318,6 +318,44

Re: [PATCH 11/12] kexec: allow architectures to override boot mapping

On 04/28/16 at 10:28am, Russell King wrote: > diff --git a/include/linux/kexec.h b/include/linux/kexec.h > index 52a3a221bcb2..99cb9dac7909 100644 > --- a/include/linux/kexec.h > +++ b/include/linux/kexec.h > @@ -318,6 +318,44 @@ int __weak arch_kexec_apply_relocations_add(const > Elf_Ehdr *ehdr,