[Toybox] [PATCH] dmesg: fix multi-line messages

[Juhyung Park]

Hi Rob,

This was a nit-picky patch, so I didn't bother to follow up and ping
you again, but yes, the issue is still there.
Just checked again against the latest master branch: b5baa040128e Fix
comm - and make comm -123 detect missing files.

On Wed, Oct 5, 2022 at 4:15 PM Rob Landley <rob at landley.net> wrote:
>
> I'm going through my "old patches" directory and deleting the ones I've already
> applied or resolved, and I hit this from mid-pandemic, which does not have a
> reply marker in my email nor in the list web archive. (Most likely my laptop
> battery died and my reply window got lost because thunderbird doesn't save them,
> and then I never got a follow-up poke to remind me...)
>
> Was there more context? Was this ever tracked down as a kernel bug or a dash
> issue or something? Is the original reporter still available? Because I didn't
> reproduce it.

This is definitely not a kernel bug. It's just how the userspace
parses /dev/kmsg.

>
> On 3/7/20 10:24, Ju Hyung Park wrote:
> > Hi Rob, sorry for the late reply.
> >
> > Was busy with uni stuffs.
> >
> > On Tue, Mar 3, 2020 at 5:00 AM Rob Landley <rob at landley.net> wrote:
> >> I'm not sure what the sh -c wrapper accomplishes here?
> >
> > The results are different from
> > `sh -c "printf 'line a\nline b\n'" > /dev/kmsg`
> > and
> > `printf 'line a\nline b\n' > /dev/kmsg`.
> >
> > I honestly don't know why, but you'll get the same issue as my
> > original commit message describes if you wrap it with `sh -c`.
>
> Which sounds like it means you were using dash in the one that failed, and bash
> in the one that succeeded. (Because on ubuntu the login shell of all users is
> bash by default, but /bin/sh points to dash because ubuntu did something stupid
> and refused to ever admit it had been stupid even when it publicly didn't work.)
>
> That said:
>
> $ sh -c "printf 'line a\nlinb\n'"  | hd
> 00000000  6c 69 6e 65 20 61 0a 6c  69 6e 62 0a              |line a.linb.|
> 0000000c
> $ printf 'line a\nlinb\n' | hd
> 00000000  6c 69 6e 65 20 61 0a 6c  69 6e 62 0a              |line a.linb.|
> 0000000c
>
> Binary identical. And also:
>
> $ sh -c "printf 'line a\nlinb\n'" > /dev/kmsg
> bash: /dev/kmsg: Permission denied
>
> If you try to run under sudo it'll fail because your shell tries to set up the
> redirect before calling sudo, and a common reason for an sh -c wrapper like that
> is so you can sudo the whole command line, but that would mean the redirect was
> INSIDE the quotes which is not what you presented here...
>
> >> The util-linux dmesg isn't parsing "\x0a" as a magic sequence, that I can tell?
> >
> > I deliberately didn't peek at util-linux or busybox's implementation
> > as that would potentially become a licensing issue..?
> > But either way, I'm sure they'll handle this "multi-line" kmsg.
>
> My point was the specific processing you wanted to add to toybox dmesg is not
> being done by other dmesg implementations. "It's ok, they handle it another way
> by magic" is not really the explanation I'm looking for here...
>
> >> How do I reproduce the problem you're seeing?
> >
> > As I mentioned, a `sh -c` wrapper will do its thing.
>
> It didn't for me at the time.
>
> > The behavior is reproducible on my Ubuntu setup and my Android 10 device.
>
> I was going to ask you to do:
>
>   sudo timeout 2 cat /dev/kmsg | gzip > kmsg.gz
>
> And send me the kmsg.gz file on a system demonstrating this problem.

That indeed would make it much easier for you to take a look:
https://arter97.com/kmsg.gz

I've changed my phone since, and this kernel prints other special
characters than just '\x0a' too, so the original patch I've sent can
definitely be improved.
For example, '\x09' is correctly handled as '\t' by util-linux.

>
> > The reason why I wanted to fix this was to make toybox properly
> > display multi-line printk()s such as `pr_info("%s\n%s\n%s", ...);`.
>
> I'd love to fix it. First I'd like to reproduce it.

Let me know if you need anything else.

Thanks.

>
> > Thanks.
>
> Rob