Re: [PATCH v2] proc: Remove empty line in /proc/self/status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 16, 2019 at 8:06 AM Guenter Roeck <groeck@xxxxxxxxxx> wrote:
>
> On Mon, Jan 14, 2019 at 11:05 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> >
> > On Mon, Jan 14, 2019 at 11:01 AM Guenter Roeck <groeck@xxxxxxxxxx> wrote:
> > >
> > > On Mon, Jan 14, 2019 at 10:50 AM Greg Kroah-Hartman
> > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Jan 14, 2019 at 10:21:45AM -0800, Guenter Roeck wrote:
> > > > > On Mon, Jan 14, 2019 at 10:13 AM Gwendal Grignou <gwendal@xxxxxxxxxxxx> wrote:
> > > > > >
> > > > > > Prevent an empty line in /proc/self/status, allow iotop to work.
> > > > > >
> > > > > > iotop does not like empty lines, fails with:
> > > > > >   File "/usr/local/lib64/python2.7/site-packages/iotop/data.py", line
> > > > > > 196, in parse_proc_pid_status
> > > > > >     key, value = line.split(':\t', 1)
> > > > > > ValueError: need more than 1 value to unpack
> > > > > >
> > > > > > [reading /proc/self/status]
> > > > > >
> > > > > > Fixes: 84964fa3e5a0 ("proc: Provide details on speculation flaw mitigations")
> > > > > >
> > > > > > Signed-off-by: Gwendal Grignou <gwendal@xxxxxxxxxxxx>
> > > > > > ---
> > > > > >  v2: Format commit message properly with proper subject and fixes
> > > > > >      keyword.
> > > > > >
> > > > > You might want to mention that this patch only applies to v4.4.y.
> > > > > v4.9.y has a similar problem, but only if CONFIG_SECCOMP=n, and would
> > > > > require a slightly different patch to fix. Other releases are, as far
> > > > > as I can see, not affected.
> > > > >
> > > > > Guenter
> > > > >
> > > > > >  fs/proc/array.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > > > > > index 0c142916a8c7d..f11df9ab4256e 100644
> > > > > > --- a/fs/proc/array.c
> > > > > > +++ b/fs/proc/array.c
> > > > > > @@ -334,7 +334,7 @@ static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
> > > > > >  #ifdef CONFIG_SECCOMP
> > > > > >         seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
> > > > > >  #endif
> > > > > > -       seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> > > > > > +       seq_printf(m, "Speculation_Store_Bypass:\t");
> > > >
> > > > Why isn't this issue showing up in all kernel releases, as this line is
> > > > still the same in 5.0-rc2?
> > > >
> > > > What makes the 4.4.y and 4.9.y trees so special here?
> > > >
> > >
> > > v4.14 and later:
> > >
> > > {
> > >         seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p));
> > > #ifdef CONFIG_SECCOMP
> > >         seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode);
> > > #endif
> > >         seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> > >
> > > ---
> > > v4.9:
> > >
> > > {
> > > #ifdef CONFIG_SECCOMP
> > >         seq_put_decimal_ull(m, "Seccomp:\t", p->seccomp.mode);
> > >                                                                 ^^^
> > > #endif
> > >         seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> > >                                ^^^
> > >
> > > -> extra newline if CONFIG_SECCOMP=n
> > >
> > > ---
> > > v4.4:
> > >
> > > {
> > > #ifdef CONFIG_SECCOMP
> > >         seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
> > >                                                       ^^^
> > > #endif
> > >         seq_printf(m, "\nSpeculation_Store_Bypass:\t");
> > >                                ^^^
> > >
> > > -> always extra newline
> > >
> > > Guenter
> >
> > Yeah, this grew out of odd placement of the trailing "\n". I agree it
> > needs fixing universally.
> >
>
> I think we need some guidance on how to fix this problem in 4.4.y and
> 4.9.y. Backport more of the context patches or stable-release-only
> patches, possibly with more context explaining the reason ?

I think we need 4.4 and 4.9 specific patches that fix it up, and a
patch to Linus that regularizes the "always have a trailing \n" style
(since the mixture of newlines was what causes this problem in the
first place).

-- 
Kees Cook



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux