Re: [PATCH] fs: fix over-zealous use of "const"
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 [-Wignored-qualifiers]
> static inline const char * const kernel_read_file_id_str(enum
> kernel_read_file_id id)
>
> Reported-by: Andy Shevchenko
> Signed-off-by: Kees Cook
Will test next week if someone don't do that before.
Thanks.
> ---
> This is for linux-security next
> ---
> include/linux/fs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 518716b4834e..82f9a2db3b1a 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2610,7 +2610,7 @@ static const char * const kernel_read_file_str[] = {
> __kernel_read_file_id(__fid_stringify)
> };
>
> -static inline const char * const kernel_read_file_id_str(enum
> kernel_read_file_id id)
> +static inline const char *kernel_read_file_id_str(enum kernel_read_file_id
> id)
> {
> if (id < 0 || id >= READING_MAX_ID)
> return kernel_read_file_str[READING_UNKNOWN];
> --
> 2.6.3
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] ASoC: docs: add clocking examples for DAI formats
Provide *our* view of what the rules are for the different DAI formats, so that we do not have to trust external interpretations for this crucial bit of interoperability. Signed-off-by: Peter Rosin --- Documentation/sound/alsa/soc/clocking.txt | 195 ++ 1 file changed, 195 insertions(+) Use rising edge and falling edge (instead of flanks). Also differentiate how transmitters and receivers behave and explain at what edges transmitters change data and at what edges receivers read data. Don't speak about left and right channels for the DSP formats where there are just a number of channels. Cheers, Peter diff --git a/Documentation/sound/alsa/soc/clocking.txt b/Documentation/sound/alsa/soc/clocking.txt index b1300162e01c..7c2bea8124b0 100644 --- a/Documentation/sound/alsa/soc/clocking.txt +++ b/Documentation/sound/alsa/soc/clocking.txt @@ -47,5 +47,200 @@ rate, number of channels and word size) to save on power. It is also desirable to use the codec (if possible) to drive (or master) the audio clocks as it usually gives more accurate sample rates than the CPU. +The below diagrams all have BCLK as the first signal, LRC as the second signal +and DATA as the third. Below that is an indication about which DATA bits belong +in what channel. + +A "..." marking as DATA indicates that there may be more bits that are not +shown. Also, all DATA bits marked X may or may not be present. DAI +transmitters must add them should LRC not match the word size exactly and DAI +receivers must be prepared to ignore them. DAI transmitters must insert zeros +for I2S and Left Justified modes, and preferably not drive DATA for the DSP +modes for these extra X bits. + + +I2S +--- + +The LRC master should put the edges of LRC so that the LRC slaves can reliably +sample LRC at the rising edges of BCLK, preferably by changing LRC in response +to falling edges of BCLK. + +Transmitters wait for a falling edge of LRC, then skip a rising edge of BCLK, +and start the left word (output MSB) at the following falling edge of BCLK. +Transmitters continue with the rest of the word by changing DATA at the falling +edges to BCLK. Transmitters must pad words with zeros if LRC is not matching +the word size, so that receivers expecting wider words do not get noise. +Transmission of the right word works the same, but is initiated by a rising +edge of LRC instead. + +Receivers wait for a falling edge of LRC, then skip a rising edge of BCLK and +read the MSB of the left word at the following rising edge of BCLK. Receivers +then continue with the rest of the word at the following rising edges of BCLK. +Receivers must ignore the tail if more bits per word are transmitted than they +can use. Reception of the right word works the same, but is initiated by a +rising edge of LRC instead. + +See the official I2S specification +https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf + + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- +---. .---. + '---' '- +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + | |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'- + | Left channel | Right channel | + + +Left Justified (aka MSB) + + +The LRC master should synchronize the LRC clock edges with the falling edges of +BCLK. + +Transmitters start the left word (output MSB) at the rising edge of LRC and +hold MSB over the first rising edge of BCLK. The transmitters then change DATA +at the falling edges of BCLK. Transmitters must pad words with zeros if LRC is +not matching the word size, so that receivers expecting wider words do not get +noise. Transmission of the right word works the same, but is initiated by a +falling edge of LRC instead. + +Receivers wait for a rising edge of LRC and reads the MSB of the left word at +the first rising edge of BCLK after that. Receivers then continue with the rest +of the word at the following rising edges of BCLK. Receivers must ignore the +tail if more bits per word are transmitted than they can use. Reception of the +right word works the same, but is initiated by a falling edge of LRC instead. + + .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. .-. +-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '-' '- + .---. .- +---' '---' +---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.- + |MSB| |...| |LSB| X |...| X |MSB| |...| |LSB| X |...| X | | +---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---
Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)
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 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, mem_tb;
> +struct rnd_state rnd_st;
> +unsigned long remain_padding = memory_rand_end -
>>memory_rand_start;
> +
> +if (!kaslr_enabled())
> +return;
> +
> +/* Take the additional space when Xen is not active. */
> +if (!xen_domain())
> +page_offset_base -= __XEN_SPACE;
This should be !xen_pv_domain(). Xen HVM guests are no different from
bare metal as far as address ranges are concerned. (Technically it's
probably !xen_pv_domain() && !xen_pvh_domain() but we can ignore PVH
for
now since it is being replaced by an HVM-type guest)
Having said that, I am not sure I understand why page_offset_base is
shifted. I thought 0x8000 - 0x87ff is not
supposed to be used by anyone, whether we are running under a
hypervisor
or not.
-boris
>>>
>>> That range is reserved for the hypervisor use.
>>
>>I know, I thought I could use it if no hypervisor was used but might
>>introduce problems in the future so I will remove it for the next
>>iteration.
>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse brevity and
>>formatting.
>
> At least in theory the hypervisor can use it even though no PV architecture
> is advertised to the kernel. One kind of would hope none would.
>
> I think this range is also used by the kernel pointer checking thing, as it
> *has* to live right next to the canonical boundary.
> --
> Sent from my Android device with K-9 Mail. Please excuse brevity and
> formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)
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:
+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 -
>memory_rand_start;
+
+if (!kaslr_enabled())
+return;
+
+/* Take the additional space when Xen is not active. */
+if (!xen_domain())
+page_offset_base -= __XEN_SPACE;
>>>
>>>This should be !xen_pv_domain(). Xen HVM guests are no different from
>>>bare metal as far as address ranges are concerned. (Technically it's
>>>probably !xen_pv_domain() && !xen_pvh_domain() but we can ignore PVH
>>>for
>>>now since it is being replaced by an HVM-type guest)
>>>
>>>Having said that, I am not sure I understand why page_offset_base is
>>>shifted. I thought 0x8000 - 0x87ff is not
>>>supposed to be used by anyone, whether we are running under a
>>>hypervisor
>>>or not.
>>>
>>>-boris
>>
>> That range is reserved for the hypervisor use.
>
>I know, I thought I could use it if no hypervisor was used but might
>introduce problems in the future so I will remove it for the next
>iteration.
>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse brevity and
>formatting.
At least in theory the hypervisor can use it even though no PV architecture is
advertised to the kernel. One kind of would hope none would.
I think this range is also used by the kernel pointer checking thing, as it
*has* to live right next to the canonical boundary.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fs: fix over-zealous use of "const"
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
kernel_read_file_id id)
Reported-by: Andy Shevchenko
Signed-off-by: Kees Cook
---
This is for linux-security next
---
include/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 518716b4834e..82f9a2db3b1a 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2610,7 +2610,7 @@ static const char * const kernel_read_file_str[] = {
__kernel_read_file_id(__fid_stringify)
};
-static inline const char * const kernel_read_file_id_str(enum
kernel_read_file_id id)
+static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
{
if (id < 0 || id >= READING_MAX_ID)
return kernel_read_file_str[READING_UNKNOWN];
--
2.6.3
--
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] irqchip, gicv3-its, numa: Enable workaround for Cavium thunderx erratum 23144
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 ThunderX dual-socket platform. > > This is based on NUMA v16 series. > Message-Id: <1460155828-8690-1-git-send-email-ddaney.c...@gmail.com> Will, Catalin, after NUMA base patches went into linux-next (many thanks), please consider this pass 1.x errata workaround for inclusion too. Thanks, -Robert > > v5 (by Robert Richter): > fixed use of cpumask_of_node() only for (node >= 0) > minor style fixes > > v4: > updated silicon-errata.txt > updated as per Robert Richter review comment. > > v3: > updatated as per Marc Zyngier's review comments. > http://www.spinics.net/lists/arm-kernel/msg443462.html > > v2: > updatated as per Marc Zyngier's review comments. > > Reviewed-by: Robert Richter > Signed-off-by: Ganapatrao Kulkarni > Signed-off-by: Robert Richter > --- > Documentation/arm64/silicon-errata.txt | 1 + > arch/arm64/Kconfig | 9 +++ > drivers/irqchip/irq-gic-v3-its.c | 49 > -- > 3 files changed, 57 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: devres: Add missing INPUT function
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
---
Documentation/driver-model/devres.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index 73b98df..25e8f3e 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -268,6 +268,9 @@ IIO
devm_iio_trigger_alloc()
devm_iio_trigger_free()
+INPUT
+ devm_input_allocate_device()
+
IO region
devm_release_mem_region()
devm_release_region()
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] fs: define a string representation of the kernel_read_file_id enumeration
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 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 simplify > > > keeping the list of strings up to date with the enumeration, this > > > patch defines two new preprocessing macros named __fid_enumify and > > > __fid_stringify to create the enumeration and an array of strings. > > > kernel_read_file_id_str() returns a string based on the > > > enumeration. > > I got this > > > > In file included from /home/andy/prj/linux- > > topic/include/linux/seq_file.h:10:0, > > from /home/andy/prj/linux- > > topic/include/linux/pinctrl/consumer.h:17, > > from /home/andy/prj/linux- > > topic/include/linux/pinctrl/devinfo.h:21, > > from /home/andy/prj/linux- > > topic/include/linux/device.h:24, > > from /home/andy/prj/linux- > > topic/include/linux/dmaengine.h:20, > > from /home/andy/prj/linux- > > topic/drivers/dma/dw/core.c:15: > > /home/andy/prj/linux-topic/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 > > kernel_read_file_id id) > What gcc version are you using? Seems like I need to drop the added > "const" on the return? $ gcc --version gcc (Debian 5.3.1-14) 5.3.1 20160409 Build was done with $ make W=1 -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] fs: define a string representation of the kernel_read_file_id enumeration
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 (eg. pr_info, auditing) that can be
>> used by multiple LSMs and the integrity subsystem. To simplify
>> keeping the list of strings up to date with the enumeration, this
>> patch defines two new preprocessing macros named __fid_enumify and
>> __fid_stringify to create the enumeration and an array of strings.
>> kernel_read_file_id_str() returns a string based on the enumeration.
>>
>> Signed-off-by: Mimi Zohar
>> [kees: removed removal of my old version, constified pointer values]
>> Signed-off-by: Kees Cook
>
>
> I got this
>
> In file included from /home/andy/prj/linux-
> topic/include/linux/seq_file.h:10:0,
> from /home/andy/prj/linux-
> topic/include/linux/pinctrl/consumer.h:17,
> from /home/andy/prj/linux-
> topic/include/linux/pinctrl/devinfo.h:21,
> from /home/andy/prj/linux-
> topic/include/linux/device.h:24,
> from /home/andy/prj/linux-
> topic/include/linux/dmaengine.h:20,
> from /home/andy/prj/linux-
> topic/drivers/dma/dw/core.c:15:
> /home/andy/prj/linux-topic/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
> kernel_read_file_id id)
What gcc version are you using? Seems like I need to drop the added
"const" on the return?
-Kees
>
>> ---
>> include/linux/fs.h | 31 +--
>> 1 file changed, 25 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 70e61b58baaf..518716b4834e 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -2590,15 +2590,34 @@ static inline void i_readcount_inc(struct
>> inode *inode)
>> #endif
>> extern int do_pipe_flags(int *, int);
>>
>> +#define __kernel_read_file_id(id) \
>> + id(UNKNOWN, unknown)\
>> + id(FIRMWARE, firmware) \
>> + id(MODULE, kernel-module) \
>> + id(KEXEC_IMAGE, kexec-image)\
>> + id(KEXEC_INITRAMFS, kexec-initramfs)\
>> + id(POLICY, security-policy) \
>> + id(MAX_ID, )
>> +
>> +#define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
>> +#define __fid_stringify(dummy, str) #str,
>> +
>> enum kernel_read_file_id {
>> - READING_FIRMWARE = 1,
>> - READING_MODULE,
>> - READING_KEXEC_IMAGE,
>> - READING_KEXEC_INITRAMFS,
>> - READING_POLICY,
>> - READING_MAX_ID
>> + __kernel_read_file_id(__fid_enumify)
>> +};
>> +
>> +static const char * const kernel_read_file_str[] = {
>> + __kernel_read_file_id(__fid_stringify)
>> };
>>
>> +static inline const char * const kernel_read_file_id_str(enum
>> kernel_read_file_id id)
>> +{
>> + if (id < 0 || id >= READING_MAX_ID)
>> + return kernel_read_file_str[READING_UNKNOWN];
>> +
>> + return kernel_read_file_str[id];
>> +}
>> +
>> extern int kernel_read(struct file *, loff_t, char *, unsigned long);
>> extern int kernel_read_file(struct file *, void **, loff_t *, loff_t,
>> enum kernel_read_file_id);
>
> --
> Andy Shevchenko
> Intel Finland Oy
>
--
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
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". > > Signed-off-by: Fu Wei > --- > Documentation/zh_CN/arm64/booting.txt | 20 > 1 file changed, 12 insertions(+), 8 deletions(-) > > diff --git a/Documentation/zh_CN/arm64/booting.txt > b/Documentation/zh_CN/arm64/booting.txt > index 1145bf8..c1dd968 100644 > --- a/Documentation/zh_CN/arm64/booting.txt > +++ b/Documentation/zh_CN/arm64/booting.txt > @@ -8,7 +8,7 @@ or if there is a problem with the translation. > > M: Will Deacon > zh_CN: Fu Wei > -C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 > +C: 55f058e7574c3615dea4615573a19bdb258696c6 Just curious, but what are these SHAs supposed to represent? Neither of them looks particularly relevant to me. Will -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Mark "Out of Date" addresses as undeliverable
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 +++ b/Documentation/zh_CN/CodingStyle @@ -5,20 +5,20 @@ However, if you have problem communicating in English you can also ask the Chinese maintainer for help. Contact the Chinese maintainer, if this translation is outdated or there is problem with translation. -Chinese maintainer: Zhang Le +Chinese maintainer: Zhang Le - Documentation/CodingStyle的中文翻译 如果想评论或更新本文的内容，请直接发信到LKML。如果你使用英文交流有困难的话，也可 以向中文版维护者求助。如果本翻译更新不及时或者翻译存在问题，请联系中文版维护者。 -中文版维护者： 张乐 Zhang Le -中文版翻译者： 张乐 Zhang Le +中文版维护者： 张乐 Zhang Le +中文版翻译者： 张乐 Zhang Le 中文版校译者： 王聪 Wang Cong wheelz 管旭东 Xudong Guan - Li Zefan - Wang Chen + Li Zefan + Wang Chen 以下为正文 - -- 2.6.4 (Apple Git-63) -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)
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, mem_tb;
>> +struct rnd_state rnd_st;
>> +unsigned long remain_padding = memory_rand_end - memory_rand_start;
>> +
>> +if (!kaslr_enabled())
>> +return;
>> +
>> +/* Take the additional space when Xen is not active. */
>> +if (!xen_domain())
>> +page_offset_base -= __XEN_SPACE;
>
>This should be !xen_pv_domain(). Xen HVM guests are no different from
>bare metal as far as address ranges are concerned. (Technically it's
>probably !xen_pv_domain() && !xen_pvh_domain() but we can ignore PVH
>for
>now since it is being replaced by an HVM-type guest)
>
>Having said that, I am not sure I understand why page_offset_base is
>shifted. I thought 0x8000 - 0x87ff is not
>supposed to be used by anyone, whether we are running under a
>hypervisor
>or not.
>
>-boris
That range is reserved for the hypervisor use.
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)
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;
>>> +unsigned long addr = memory_rand_start;
>>> +unsigned long padding, rand, mem_tb;
>>> +struct rnd_state rnd_st;
>>> +unsigned long remain_padding = memory_rand_end - memory_rand_start;
>>> +
>>> +if (!kaslr_enabled())
>>> +return;
>>> +
>>> +/* Take the additional space when Xen is not active. */
>>> +if (!xen_domain())
>>> +page_offset_base -= __XEN_SPACE;
>>
>>This should be !xen_pv_domain(). Xen HVM guests are no different from
>>bare metal as far as address ranges are concerned. (Technically it's
>>probably !xen_pv_domain() && !xen_pvh_domain() but we can ignore PVH
>>for
>>now since it is being replaced by an HVM-type guest)
>>
>>Having said that, I am not sure I understand why page_offset_base is
>>shifted. I thought 0x8000 - 0x87ff is not
>>supposed to be used by anyone, whether we are running under a
>>hypervisor
>>or not.
>>
>>-boris
>
> That range is reserved for the hypervisor use.
I know, I thought I could use it if no hypervisor was used but might
introduce problems in the future so I will remove it for the next
iteration.
> --
> Sent from my Android device with K-9 Mail. Please excuse brevity and
> formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)
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, rand, mem_tb;
>> + struct rnd_state rnd_st;
>> + unsigned long remain_padding = memory_rand_end -
>> memory_rand_start;
>> +
>> + if (!kaslr_enabled())
>> + return;
>> +
>> + /* Take the additional space when Xen is not active. */
>> + if (!xen_domain())
>> + page_offset_base -= __XEN_SPACE;
>
>
> This should be !xen_pv_domain(). Xen HVM guests are no different from bare
> metal as far as address ranges are concerned. (Technically it's probably
> !xen_pv_domain() && !xen_pvh_domain() but we can ignore PVH for now since it
> is being replaced by an HVM-type guest)
>
In my test KASLR was disabled on Xen so I should just remove this
check. I kept it in case it might change in the future.
> Having said that, I am not sure I understand why page_offset_base is
> shifted. I thought 0x8000 - 0x87ff is not supposed
> to be used by anyone, whether we are running under a hypervisor or not.
>
It is shifted to get the most space possible, it increases the entropy
available. Do you know why we should not use 0x8000 -
0x87ff?
> -boris
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation:Update Documentation/zh_CN/arm64/booting.txt
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". Signed-off-by: Fu Wei --- Documentation/zh_CN/arm64/booting.txt | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt index 1145bf8..c1dd968 100644 --- a/Documentation/zh_CN/arm64/booting.txt +++ b/Documentation/zh_CN/arm64/booting.txt @@ -8,7 +8,7 @@ or if there is a problem with the translation. M: Will Deacon zh_CN: Fu Wei -C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 +C: 55f058e7574c3615dea4615573a19bdb258696c6 - Documentation/arm64/booting.txt 的中文翻译 @@ -20,7 +20,7 @@ Documentation/arm64/booting.txt 的中文翻译 中文版维护者： 傅炜 Fu Wei 中文版翻译者： 傅炜 Fu Wei 中文版校译者： 傅炜 Fu Wei -本文翻译提交时的 Git 检出点为： 1926e54f115725a9248d0c4c65c22acaf94de4c4 +本文翻译提交时的 Git 检出点为： 55f058e7574c3615dea4615573a19bdb258696c6 以下为正文 - @@ -125,18 +125,22 @@ AArch64 内核当前没有提供自解压代码，因此如果使用了压缩内 1 - 4K 2 - 16K 3 - 64K - 位 3-63: 保留。 + 位 3: 内核物理位置 + 0 - 2MB 对齐基址应尽量靠近内存起始处，因为 + 其基址以下的内存无法通过线性映射访问 + 1 - 2MB 对齐基址可以在物理内存的任意位置 + 位 4-63: 保留。 - 当 image_size 为零时，引导装载程序应试图在内核映像末尾之后尽可能 多地保留空闲内存供内核直接使用。对内存空间的需求量因所选定的内核 特性而异, 并无实际限制。 -内核映像必须被放置在靠近可用系统内存起始的 2MB 对齐为基址的 -text_offset 字节处，并从该处被调用。当前，对 Linux 来说在此基址以下的 -内存是无法使用的，因此强烈建议将系统内存的起始作为这个基址。2MB 对齐 -基址和内核映像起始地址之间的区域对于内核来说没有特殊意义，且可能被 -用于其他目的。 +内核映像必须被放置在任意一个可用系统内存 2MB 对齐基址的 text_offset +字节处，并从该处被调用。2MB 对齐基址和内核映像起始地址之间的区域对于 +内核来说没有特殊意义，且可能被用于其他目的。 从映像起始地址算起，最少必须准备 image_size 字节的空闲内存供内核使用。 +注： v4.6 之前的版本无法使用内核映像物理偏移以下的内存，所以当时建议 +将映像尽量放置在靠近系统内存起始的地方。 任何提供给内核的内存（甚至在映像起始地址之前），若未从内核中标记为保留 (如在设备树（dtb）的 memreserve 区域），都将被认为对内核是可用。 -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version
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 version of the spec. There were significant additions to the > spec that had not yet been mentioned -- for example, the 6.0 mechanisms > added to make it easier to define processors and low power idle states, > as well as the 6.1 addition allowing regular interrupts (not just from > GPIO) be used to signal ACPI general purpose events. > > This patch reflects going back through and examining the specs in detail > and updating content appropriately. Whilst there, a few odds and ends of > typos were caught as well. This brings the documentation up to date with > ACPI 6.1 for arm64. Why linux-acpi is not in the destination list? > Changes for v4: >-- Clarify that IORT can sometimes be optional (Jon Masters). >-- Remove "Use as needed" descriptions of ACPI objects; they provide > no substantive information and doing so simplifies maintenance of > this document over time. These have been replaced with a simpler > notice that states that unless otherwise noted, do what the APCI > specification says is needed. >-- Corrected the _OSI object usage recommendation; it described kernel > behavior that does not exist (Al Stone). > > Changes for v3: >-- Clarify use of _LPI/_RDI (Vikas Sajjan) >-- Whitespace cleanup as pointed out by checkpatch > > Changes for v2: >-- Clean up white space (Harb Abdulhahmid) >-- Clarification on _CCA usage (Harb Abdulhamid) >-- IORT moved to required from recommended (Hanjun Guo) >-- Clarify IORT description (Hanjun Guo) > > Signed-off-by: Al Stone > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Jonathan Corbet > --- > Documentation/arm64/acpi_object_usage.txt | 347 > -- > Documentation/arm64/arm-acpi.txt | 28 ++- > 2 files changed, 212 insertions(+), 163 deletions(-) > > diff --git a/Documentation/arm64/acpi_object_usage.txt > b/Documentation/arm64/acpi_object_usage.txt > index a6e1a18..3891750 100644 > --- a/Documentation/arm64/acpi_object_usage.txt > +++ b/Documentation/arm64/acpi_object_usage.txt > @@ -13,14 +13,18 @@ For ACPI on arm64, tables also fall into the > following categories: [..] > == Memory-mapped ConFiGuration space == > @@ -176,14 +192,38 @@ MPST Section 5.2.21 (signature == "MPST") > == Memory Power State Table == > Optional, not currently supported. > > +MSCT Section 5.2.19 (signature == "MSCT") > + == Maximum System Characteristic Table == > + Optional, not currently supported. > + > MSDM Signature Reserved (signature == "MSDM") > == Microsoft Data Management table == > Microsoft only table, will not be supported. > > -MSCT Section 5.2.19 (signature == "MSCT") > - == Maximum System Characteristic Table == > +NFIT Section 5.2.25 (signature == "NFIT") > + == NVDIMM Firmware Interface Table == > Optional, not currently supported. > > +OEMx Signature of "OEMx" only > + == OEM Specific Tables == > + All tables starting with a signature of "OEM" are reserved for OEM > + use. Since these are not meant to be of general use but are limited > + to very specific end users, they are not recommended for use and are > + not supported by the kernel for arm64. > + > +PCCT Section 14.1 (signature == "PCCT) > + == Platform Communications Channel Table == > + Recommend for use on arm64, and required when using CPPC to control > + power on the platform. Could you please check corectness of this sentence? If I remember correctly CPPC may operate via PCC interface but there is no strict requirement to implement control mechanism via PCC. > using CPPC to control power on the platform Sorry, I think I need to disagree. Main description of CPPC says that CPPC defines mechanism to manage performance of logical processor. What do you think about "to control performance on the platform"? (or maybe "to control performance and power on the platform") Thanks, Alexey -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] hrtimers: doc cleanup
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 b/Documentation/timers/hrtimers.txt index ce31f65..492f1af 100644 --- a/Documentation/timers/hrtimers.txt +++ b/Documentation/timers/hrtimers.txt @@ -28,9 +28,9 @@ several reasons why such integration is hard/impossible: - the unpredictable [O(N)] overhead of cascading leads to delays which necessitate a more complex handling of high resolution timers, which - in turn decreases robustness. Such a design still led to rather large + in turn decreases robustness. Such a design still leads to rather large timing inaccuracies. Cascading is a fundamental property of the timer - wheel concept, it cannot be 'designed out' without unevitably + wheel concept, it cannot be 'designed out' without inevitably degrading other portions of the timers.c code in an unacceptable way. - the implementation of the current posix-timer subsystem on top of -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hrtimers: doc cleanup
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 the timers.c code in an unacceptable way* equals *it can be 'designed out' ... in an acceptable way*, I think. So, just from semantics, my feeling is, *it cannot be 'designed out' in an acceptable way* is the reason why integration is hard. Am I still wrong? The original author, clearly, was talking about the degradation being unacceptable. It seems clear enough, I don't think that change should be made. Thanks, will remove the change in v2 -- Yours Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)
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 - memory_rand_start;
+
+ if (!kaslr_enabled())
+ return;
+
+ /* Take the additional space when Xen is not active. */
+ if (!xen_domain())
+ page_offset_base -= __XEN_SPACE;
This should be !xen_pv_domain(). Xen HVM guests are no different from
bare metal as far as address ranges are concerned. (Technically it's
probably !xen_pv_domain() && !xen_pvh_domain() but we can ignore PVH for
now since it is being replaced by an HVM-type guest)
Having said that, I am not sure I understand why page_offset_base is
shifted. I thought 0x8000 - 0x87ff is not
supposed to be used by anyone, whether we are running under a hypervisor
or not.
-boris
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] fs: define a string representation of the kernel_read_file_id enumeration
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 simplify
> keeping the list of strings up to date with the enumeration, this
> patch defines two new preprocessing macros named __fid_enumify and
> __fid_stringify to create the enumeration and an array of strings.
> kernel_read_file_id_str() returns a string based on the enumeration.
>
> Signed-off-by: Mimi Zohar
> [kees: removed removal of my old version, constified pointer values]
> Signed-off-by: Kees Cook
I got this
In file included from /home/andy/prj/linux-
topic/include/linux/seq_file.h:10:0,
from /home/andy/prj/linux-
topic/include/linux/pinctrl/consumer.h:17,
from /home/andy/prj/linux-
topic/include/linux/pinctrl/devinfo.h:21,
from /home/andy/prj/linux-
topic/include/linux/device.h:24,
from /home/andy/prj/linux-
topic/include/linux/dmaengine.h:20,
from /home/andy/prj/linux-
topic/drivers/dma/dw/core.c:15:
/home/andy/prj/linux-topic/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
kernel_read_file_id id)
> ---
> include/linux/fs.h | 31 +--
> 1 file changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 70e61b58baaf..518716b4834e 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2590,15 +2590,34 @@ static inline void i_readcount_inc(struct
> inode *inode)
> #endif
> extern int do_pipe_flags(int *, int);
>
> +#define __kernel_read_file_id(id) \
> + id(UNKNOWN, unknown)\
> + id(FIRMWARE, firmware) \
> + id(MODULE, kernel-module) \
> + id(KEXEC_IMAGE, kexec-image)\
> + id(KEXEC_INITRAMFS, kexec-initramfs)\
> + id(POLICY, security-policy) \
> + id(MAX_ID, )
> +
> +#define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
> +#define __fid_stringify(dummy, str) #str,
> +
> enum kernel_read_file_id {
> - READING_FIRMWARE = 1,
> - READING_MODULE,
> - READING_KEXEC_IMAGE,
> - READING_KEXEC_INITRAMFS,
> - READING_POLICY,
> - READING_MAX_ID
> + __kernel_read_file_id(__fid_enumify)
> +};
> +
> +static const char * const kernel_read_file_str[] = {
> + __kernel_read_file_id(__fid_stringify)
> };
>
> +static inline const char * const kernel_read_file_id_str(enum
> kernel_read_file_id id)
> +{
> + if (id < 0 || id >= READING_MAX_ID)
> + return kernel_read_file_str[READING_UNKNOWN];
> +
> + return kernel_read_file_str[id];
> +}
> +
> extern int kernel_read(struct file *, loff_t, char *, unsigned long);
> extern int kernel_read_file(struct file *, void **, loff_t *, loff_t,
> enum kernel_read_file_id);
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hrtimers: doc cleanup
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 way* > > equals > > *it can be 'designed out' ... in an acceptable way*, I think. > > So, just from semantics, my feeling is, *it cannot be 'designed out' in > an acceptable way* is the reason why integration is hard. Am I still wrong? The original author, clearly, was talking about the degradation being unacceptable. It seems clear enough, I don't think that change should be made. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/24] i2c mux cleanup and locking update
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 > was evident from the crash in the mpu6050 driver (on a mpu9150 chip) > reported > by Crestez Dan Leonard. Also, it didn't make things all that much simpler > anyway (even if used correctly). > - Rename i2c_mux_core:adapters into i2c_mux_core:num_adapters. > - Some grammar and spelling fixes. I tested this new version on mpu9150 and there are no more obvious deadlocks or crashes. The magnetometer and accel/gyro can be used at the same time without issues. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hrtimers: doc cleanup
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 timers.c code in an unacceptable way. + wheel concept, it cannot be 'designed out' without inevitably + degrading other portions of the timers.c code in an acceptable way. 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 way* equals *it can be 'designed out' ... in an acceptable way*, I think. So, just from semantics, my feeling is, *it cannot be 'designed out' in an acceptable way* is the reason why integration is hard. Am I still wrong? -- Yours Sincerely, Cao jin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hrtimers: doc cleanup
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 > + degrading other portions of the timers.c code in an acceptable way. This change is incorrect - "unacceptable" is exactly what the writer wanted to say here. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hrtimers: doc cleanup
It has: a tense correction(led->leads); a typo(unevitably->inevitably); a logic error correction(unacceptable->acceptable) Signed-off-by: Cao jin --- Documentation/timers/hrtimers.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/timers/hrtimers.txt b/Documentation/timers/hrtimers.txt index ce31f65..347ad82 100644 --- a/Documentation/timers/hrtimers.txt +++ b/Documentation/timers/hrtimers.txt @@ -28,10 +28,10 @@ several reasons why such integration is hard/impossible: - the unpredictable [O(N)] overhead of cascading leads to delays which necessitate a more complex handling of high resolution timers, which - in turn decreases robustness. Such a design still led to rather large + in turn decreases robustness. Such a design still leads to rather large timing inaccuracies. Cascading is a fundamental property of the timer - 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 + degrading other portions of the timers.c code in an acceptable way. - the implementation of the current posix-timer subsystem on top of the timer wheel has already introduced a quite complex handling of -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy
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 can be added to. I don't see
>> > anything that the config option adds.
>>
>> Yes, but why does every distro need to solve the exact same issue by
>> a distro-specific init script when we can allow setting reasonable
>> default in kernel?
>>
>
> No, only distros that want to change the long-standing default which is
> "offline" since they apparently aren't worried about breaking existing
> userspace.
>
> Changing defaults is always risky business in the kernel, especially when
> it's long standing. If the default behavior is changeable, userspace
> needs to start testing for that and acting accordingly if it actually
> wants to default to offline (and there are existing tools that suppose the
> long-standing default). The end result is that the kernel default doesn't
> matter anymore, we've just pushed it to userspace to either online or
> offline at the time of hotplug.
>
"We don't break userspace". Yes, I know, but is there an example of such
userspace which is going to break?
E.g. RHEL7 ships the following udev rule by default:
# Memory hotadd request
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
which is not very smart but it does the job (with issues I'm trying to
solve). I'm not aware of any breakages reported after it was introduced.
My understanding is that the legacy default 'offline' was introduced
before memory hotplug became a frequently used feature in virtual
machines. When you hotplug physical memory you go to your server room,
open your server, insert memory dimm, ... - in this scenario 'offline'
is a reasonable default. But in VMs mempory hotplug is usually an
automatic from host side -- we address high memory pressure/tenant
requests.
>> If the config option itself is a problem (though I don't understand why)
>> we can get rid of it making the default 'online' and keeping the command
>> line parameter to disable it for cases when something goes wrong but why
>> not leave an option for those who want it the other way around?
>>
>
> That could break existing userspace that assumes the default is offline;
> if users are currently hotadding memory and then onlining it when needed
> rather than immediately, they break. So that's not a possibility.
>
Yes, so I introduce a config option. Next thing we do we enable it in
'bleeding edge' distros, e.g. Fedora and see who complains. My guess is
that nobody is going to complain.
>> Other than the above, let's imagine a 'unikernel' scenario when there
>> are no initscripts and we're in a virtualized environment. We may want to
>> have memory hotplug there too, but where would we put the 'onlining'
>> logic? In every userspace we want to run? This doesn't sound right.
>>
>
> Nobody is resisting hotplug notifiers.
Yes, but we need to teach memory hotplug to every userspace instead.
--
Vitaly
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
