On Tue, Jan 30, 2018 at 01:16:11PM +0100, Michal Hocko wrote:
> On Thu 18-01-18 17:50:48, Ram Pai wrote:
> [...]
> > @@ -851,9 +848,13 @@ static int show_smap(struct seq_file *m, void *v, int
> > is_pid)
> >(unsigned long)(mss->pss >> (10 + PSS_SHIFT)));
> >
> > if (!
On Thu 18-01-18 17:50:48, Ram Pai wrote:
[...]
> @@ -851,9 +848,13 @@ static int show_smap(struct seq_file *m, void *v, int
> is_pid)
> (unsigned long)(mss->pss >> (10 + PSS_SHIFT)));
>
> if (!rollup_mode) {
> - arch_show_smap(m, vma);
> +#ifdef CONFIG_
Ram Pai writes:
> On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
>> Ram Pai writes:
>>
>> > Currently the architecture specific code is expected to
>> > display the protection keys in smap for a given vma.
>> > This can lead to redundant code and possibly to divergen
On Fri, Jan 19, 2018 at 10:09:41AM -0600, Eric W. Biederman wrote:
> Ram Pai writes:
>
> > Currently the architecture specific code is expected to
> > display the protection keys in smap for a given vma.
> > This can lead to redundant code and possibly to divergent
> > formats in which th
Ram Pai writes:
> Currently the architecture specific code is expected to
> display the protection keys in smap for a given vma.
> This can lead to redundant code and possibly to divergent
> formats in which the key gets displayed.
>
> This patch changes the implementation. It displays
Currently the architecture specific code is expected to
display the protection keys in smap for a given vma.
This can lead to redundant code and possibly to divergent
formats in which the key gets displayed.
This patch changes the implementation. It displays the
pkey only if the archite
