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
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
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 n
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, Zh
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 allow
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
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, userspa
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 l
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 report
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 l
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 f
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:
> >>>
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 aroun
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
--- a/scripts/docproc.c
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
index bc900310b431..a93
Leave a hint to folks which file to edit instead.
Signed-off-by: Jani Nikula
---
scripts/docproc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/scripts/docproc.c b/scripts/docproc.c
index 9babfd108d2e..0a12593b9041 100644
--- a/scripts/docproc.c
+++ b/scripts/docproc.c
@@ -45,6 +45
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 use
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 going to bring cla
Improves clarity. No functional changes.
Signed-off-by: Jani Nikula
---
scripts/docproc.c | 93 ---
1 file changed, 47 insertions(+), 46 deletions(-)
diff --git a/scripts/docproc.c b/scripts/docproc.c
index 48abc01a920e..fb195f0ed0ef 100644
--
Improves clarity. No functional changes.
Signed-off-by: Jani Nikula
---
scripts/docproc.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/scripts/docproc.c b/scripts/docproc.c
index e267e621431a..48abc01a920e 100644
--- a/scripts/docproc.c
+++ b/scripts/doc
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 --
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 documented
On Thu, May 12, 2016 at 08:52:46PM +0800, Zhangjian (Bamvor) wrote:
> 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
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 w
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 reports successful read/write.
>
> There are 2 problems:
> 1. How kernel
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
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 = 0
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 pwrit
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 pwrit
On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas 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
On Thu, May 12, 2016 at 05:34:15PM +0300, Yury Norov wrote:
> On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas 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
On Thu, May 12, 2016 at 03:54:03PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 05:34:15PM +0300, Yury Norov wrote:
> > On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote:
> > > On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> > > > On Thu, May 12, 2016 at
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 03:20
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 accountin
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 feedb
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 | 6 +++
arch/x8
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
CONFIG_MEMORY_HOTPL
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 disclose the kernel modules base addresses or
corrupt specific str
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.
Signed
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
Sorry about that. I will fix and send a new iteration this afternoon.
Thomas
On Thu, May 12, 2016 at 9:27 AM, kbuild test robot wrote:
> 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 appli
Ping, since the 4.7 merge window is opening soon and I haven't received
too much feedback on this version of the patch series based on 4.6-rc1.
1. Patch 09/13 for timer ticks was acked by Daniel Lezcano and is standalone,
so could be taken into the relevant trees. I'm not sure if it should go
On 05/10/2016 08:57 AM, Borislav Petkov wrote:
> 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 en
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 feedb
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.
Signed
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
CONFIG_MEMORY_HOTPL
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 disclose the kernel modules base addresses or
corrupt specific str
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 | 6 +++
arch/x8
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
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. There were significan
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
51 matches
Mail list logo
