Re: [PATCH v2] tile: handle __ro_after_init like parisc does

2016-11-14 Thread Heiko Carstens
On Mon, Nov 14, 2016 at 01:12:05PM -0800, Kees Cook wrote: > At some point here, I want to collect all the arch maintainers and > discuss the options for correctly reflecting the three data > memory-protection needs we have: > > - always read-only > - read-only after init > - read-only except

Re: [PATCH v2] tile: handle __ro_after_init like parisc does

2016-11-14 Thread Heiko Carstens
On Mon, Nov 14, 2016 at 01:12:05PM -0800, Kees Cook wrote: > At some point here, I want to collect all the arch maintainers and > discuss the options for correctly reflecting the three data > memory-protection needs we have: > > - always read-only > - read-only after init > - read-only except

Re: [PATCH v2] tile: handle __ro_after_init like parisc does

2016-11-14 Thread Kees Cook
On Mon, Nov 14, 2016 at 12:29 PM, Chris Metcalf wrote: > The tile architecture already marks RO_DATA as read-only in > the kernel, so grouping RO_AFTER_INIT_DATA with RO_DATA, as is > done by default, means the kernel faults in init when it tries > to write to

Re: [PATCH v2] tile: handle __ro_after_init like parisc does

2016-11-14 Thread Kees Cook
On Mon, Nov 14, 2016 at 12:29 PM, Chris Metcalf wrote: > The tile architecture already marks RO_DATA as read-only in > the kernel, so grouping RO_AFTER_INIT_DATA with RO_DATA, as is > done by default, means the kernel faults in init when it tries > to write to RO_AFTER_INIT_DATA. For now, just

[PATCH v2] tile: handle __ro_after_init like parisc does

2016-11-14 Thread Chris Metcalf
The tile architecture already marks RO_DATA as read-only in the kernel, so grouping RO_AFTER_INIT_DATA with RO_DATA, as is done by default, means the kernel faults in init when it tries to write to RO_AFTER_INIT_DATA. For now, just arrange that __ro_after_init is handled like __write_once, i.e.

[PATCH v2] tile: handle __ro_after_init like parisc does

2016-11-14 Thread Chris Metcalf
The tile architecture already marks RO_DATA as read-only in the kernel, so grouping RO_AFTER_INIT_DATA with RO_DATA, as is done by default, means the kernel faults in init when it tries to write to RO_AFTER_INIT_DATA. For now, just arrange that __ro_after_init is handled like __write_once, i.e.