On Mon, Jan 14, 2019 at 10:49 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Mon, Jan 14, 2019 at 10:00:54AM -0800, Gwendal Grignou wrote:
> > On Sat, Jan 12, 2019 at 12:01 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Fri, Jan 11, 2019 at 04:32:12PM -0800, Gwendal Grignou 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]
> > > >
> > > > Signed-off-by: Gwendal Grignou <gwendal@xxxxxxxxxxxx>
> > > > ---
> > > > fs/proc/array.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > >
> > > Why send this to me? Always use scripts/get_maintainer.pl on a patch to
> > > determine who and what lists to send patches to.
> > I did, your email address is on the first line:
> > ./scripts/get_maintainer.pl
> > 0001-CHROMIUM-FIXUP-proc-Provide-details-on-speculation-f.patch
> > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> (commit_signer:6/4=100%)
>
> Ah, wait, you are making a patch against the stable kernel tree?
>
> We can't go back in time, you need to work against Linus's latest kernel
> tree, that's why I am showing up in this list. I'm not the upstream
> developer for this file.
>
> > "Srivatsa S. Bhat" <srivatsa@xxxxxxxxxxxxx> (commit_signer:3/4=75%)
> > Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > (commit_signer:3/4=75%,authored:1/4=25%,added_lines:3/28=11%)
> > David Woodhouse <dwmw@xxxxxxxxxxxx> (commit_signer:3/4=75%)
> > Bo Gan <ganb@xxxxxxxxxx> (commit_signer:3/4=75%)
> > Kees Cook <keescook@xxxxxxxxxxxx> (authored:1/4=25%,added_lines:23/28=82%)
> > Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > (authored:1/4=25%,removed_lines:1/2=50%)
> > Gwendal Grignou <gwendal@xxxxxxxxxxxx> (authored:1/4=25%,removed_lines:1/2=50%)
> > linux-kernel@xxxxxxxxxxxxxxx (open list)
> >
> > >
> > > And is this a new bug? What commit caused this?
> > It is only in 4.4 stable. It has been introduced by:
> > "484964fa3e5a0 proc: Provide details on speculation flaw mitigations"
>
> That really is commit fae1fa0fc6cca8beee3ab8ed71d54f9a78fa3f64 in
> Linus's tree, and is in the 4.4, 4.9, 4.14, 4.16, and 4.17 kernel
> releases.
>
> So it also is included in 5.0-rc1, if this is still an issue there,
> please submit the patch to the correct developers and then the patch
> will be backported to the needed stable kernel trees if you add the
> correct "Fixes:" and "cc: stable@xxxxxxxxxxxxxxxxx" lines to the patch.
> Documentation/SubmittingPatches will tell you all about how to do this.
>
> > That patch adds an extra \n in front of "Speculation Store Bypass"
> > that breaks iotop processing of /proc/../status.
>
> Why isn't iotop broken in the latest kernel release? It seems to work
> for me here.
iotop is not broken in ToT, only on 4.4 stable:
fae1fa0fc6cca8beee3ab8ed71d54f9a78fa3f64 assumes f7a5f132b447c ("proc:
faster /proc/*/status") has been applied. That patch breaks
seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
in 2:
seq_puts(m, "Seccomp:\t");
seq_put_decimal_ull(m, 0, p->seccomp.mode);
and
seq_putc(m, '\n');
f7a5f132b447c is not applied to 4.4 stable. Comparing fae1fa0fc6 with
484964fa3e5a0, the latter adds a 'seq_putc(m, '\n');' whereas it was
already there when fae1fa0fc6 was applied.
484964fa3e5a0 is adding an empty line, the patch I propose removes it.
Regards,
Gwendal.
>
> thanks,
>
> greg k-h
