Re: [PATCH] fs: fix over-zealous use of "const"

2016-04-21 Thread Andy Shevchenko
On Thu, Apr 21, 2016 at 10:53 PM, Kees Cook wrote: > When I was fixing up const recommendations from checkpatch.pl, I went > overboard. This fixes the warning (during a W=1 build): > > include/linux/fs.h:2627:74: warning: type qualifiers ignored on function > return type

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

2016-04-21 Thread Thomas Garnier
Make sense, thanks for the details. On Thu, Apr 21, 2016 at 1:15 PM, H. Peter Anvin wrote: > On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >>On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >>> On April 21, 2016 6:30:24 AM

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

2016-04-21 Thread H. Peter Anvin
On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >> On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >>> >>> >>>On 04/15/2016 06:03 PM, Thomas Garnier wrote:

[PATCH] fs: fix over-zealous use of "const"

2016-04-21 Thread Kees Cook
When I was fixing up const recommendations from checkpatch.pl, I went overboard. This fixes the warning (during a W=1 build): include/linux/fs.h:2627:74: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] static inline const char * const kernel_read_file_id_str(enum

Re: [PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144

2016-04-21 Thread Robert Richter
On 15.04.16 21:30:05, Robert Richter wrote: > From: Ganapatrao Kulkarni > > The erratum fixes the hang of ITS SYNC command by avoiding inter node > io and collections/cpu mapping on thunderx dual-socket platform. > > This fix is only applicable for Cavium's

[PATCH] Documentation: devres: Add missing INPUT function

2016-04-21 Thread Alexander Kurz
devm_input_allocate_device() got introduced with commit 2be975c6d920 ("Input: introduce managed input devices (add devres support)"). Add this function to the list of managed interfaces within the devres documentation. Signed-off-by: Alexander Kurz ---

Re: [PATCH 5/6] fs: define a string representation of the kernel_read_file_id enumeration

2016-04-21 Thread Andy Shevchenko
On Thu, 2016-04-21 at 09:47 -0700, Kees Cook wrote: > On Thu, Apr 21, 2016 at 6:26 AM, Andy Shevchenko > wrote: > > > > On Wed, 2016-04-20 at 15:46 -0700, Kees Cook wrote: > > > > > > From: Mimi Zohar > > > > > > A string

Re: [PATCH 5/6] fs: define a string representation of the kernel_read_file_id enumeration

2016-04-21 Thread Kees Cook
On Thu, Apr 21, 2016 at 6:26 AM, Andy Shevchenko wrote: > On Wed, 2016-04-20 at 15:46 -0700, Kees Cook wrote: >> From: Mimi Zohar >> >> A string representation of the kernel_read_file_id enumeration is >> needed for displaying messages

Re: [PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt

2016-04-21 Thread Will Deacon
On Thu, Apr 21, 2016 at 09:45:40PM +0800, w...@redhat.com wrote: > From: Fu Wei > > This is a update of Chinese documentation: > Documentation/zh_CN/arm64/booting.txt > > It is based on the modifications of Documentation/arm64/booting.txt in > submission: > "a7f8de16". > >

[PATCH] Mark "Out of Date" addresses as undeliverable

2016-04-21 Thread Zhigang Gao
From: Maxpain --- Documentation/zh_CN/CodingStyle | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/zh_CN/CodingStyle b/Documentation/zh_CN/CodingStyle index 654afd7..26ff11d 100644 --- a/Documentation/zh_CN/CodingStyle +++

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

2016-04-21 Thread H. Peter Anvin
On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky wrote: > > >On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> +void __init kernel_randomize_memory(void) >> +{ >> +size_t i; >> +unsigned long addr = memory_rand_start; >> +unsigned long padding, rand,

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

2016-04-21 Thread Thomas Garnier
On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: > On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >> >> >>On 04/15/2016 06:03 PM, Thomas Garnier wrote: >>> +void __init kernel_randomize_memory(void) >>> +{ >>> +size_t i; >>> +

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

2016-04-21 Thread Thomas Garnier
On Thu, Apr 21, 2016 at 6:30 AM, Boris Ostrovsky wrote: > > > On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> >> +void __init kernel_randomize_memory(void) >> +{ >> + size_t i; >> + unsigned long addr = memory_rand_start; >> + unsigned long padding,

Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version

2016-04-21 Thread Alexey Klimov
Hi Al, I hope you don't mind if I put few minor questions here. On Mon, Apr 18, 2016 at 8:32 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

[PATCH v2] hrtimers: doc cleanup

2016-04-21 Thread Cao jin
It has: a tense correction(led->leads); a typo(unevitably->inevitably); Signed-off-by: Cao jin --- Documentation/timers/hrtimers.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/timers/hrtimers.txt

Re: [PATCH] hrtimers: doc cleanup

2016-04-21 Thread Cao jin
On 04/21/2016 09:23 PM, Jonathan Corbet wrote: On Thu, 21 Apr 2016 18:25:41 +0800 Cao jin wrote: This change is incorrect - "unacceptable" is exactly what the writer wanted to say here. *it cannot be 'designed out' without inevitably degrading other portions of

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

2016-04-21 Thread Boris Ostrovsky
On 04/15/2016 06:03 PM, Thomas Garnier wrote: +void __init kernel_randomize_memory(void) +{ + size_t i; + unsigned long addr = memory_rand_start; + unsigned long padding, rand, mem_tb; + struct rnd_state rnd_st; + unsigned long remain_padding = memory_rand_end -

Re: [PATCH 5/6] fs: define a string representation of the kernel_read_file_id enumeration

2016-04-21 Thread Andy Shevchenko
On Wed, 2016-04-20 at 15:46 -0700, Kees Cook wrote: > From: Mimi Zohar > > A string representation of the kernel_read_file_id enumeration is > needed for displaying messages (eg. pr_info, auditing) that can be > used by multiple LSMs and the integrity subsystem.  To

Re: [PATCH] hrtimers: doc cleanup

2016-04-21 Thread Jonathan Corbet
On Thu, 21 Apr 2016 18:25:41 +0800 Cao jin wrote: > > This change is incorrect - "unacceptable" is exactly what the writer > > wanted to say here. > > > *it cannot be 'designed out' without inevitably degrading other portions > of the timers.c code in an unacceptable

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

2016-04-21 Thread Crestez Dan Leonard
On 04/20/2016 06:17 PM, Peter Rosin wrote: > v7 compared to v6: > - Removed i2c_mux_reserve_adapters, and all realloc attempts in > i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc > instead. > - Removed i2c_mux_one_adapter since it is was hard to use correctly, which

Re: [PATCH] hrtimers: doc cleanup

2016-04-21 Thread Cao jin
Hi jon Thanks for your quick respond for my 1st patch here. On 04/21/2016 05:56 PM, Jonathan Corbet wrote: On Thu, 21 Apr 2016 17:09:54 +0800 Cao jin wrote: - wheel concept, it cannot be 'designed out' without unevitably - degrading other portions of the

Re: [PATCH] hrtimers: doc cleanup

2016-04-21 Thread Jonathan Corbet
On Thu, 21 Apr 2016 17:09:54 +0800 Cao jin wrote: > - wheel concept, it cannot be 'designed out' without unevitably > - degrading other portions of the timers.c code in an unacceptable way. > + wheel concept, it cannot be 'designed out' without inevitably > +

Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

2016-04-21 Thread Vitaly Kuznetsov
David Rientjes writes: > On Tue, 19 Apr 2016, Vitaly Kuznetsov wrote: > >> > I'd personally disagree that we need more and more config options to take >> > care of something that an initscript can easily do and most distros >> > already have their own initscripts that this