[Crash-utility] [PATCH v2] Fix "vm -M" option to properly deal with an invalid argument

[lijiang]

On Fri, Mar 24, 2023 at 8:45 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab at nec.com>
wrote:

> hmm, what does "special value" mean?  I think that htoll() skips 'h'

to accept strings like '1234h', so "0xh" is just converted to zero.
> I'm not sure why you pick the "0xh" up specially here.
>
>
The "special value" means that the value "0xh" is ambiguous, the htoll()
always
skips the "h", but for users, the "0xh" is actually a value(though it is an
invalid value).

And similar strings like "123h456",...

But this is another issue, as you mentioned below.


>
> As I said before, this is the expected behavior.  Mistakenly?
>
>
OK, let's remove it from the patch log.


> The issue that this patch fixes is the confusion by the option.
> The '0xh' is beside the point.  I've rewrite it, how about this?
>
>
The following patch log is fine to me.

Thanks.
Lianbo


> -----
> The "vm -M" option can accept an invalid address and print the virtual
> memory information of a task without an error like this:
>
>    crash> vm -M 0xdeadbeef
>    PID: 92960    TASK: ffff99157976cc80  CPU: 0    COMMAND: "crash"
>           MM               PGD          RSS    TOTAL_VM
>    ffff991573bfdf00  ffff9915857f2000  449020k  2427076k
>          VMA           START       END     FLAGS FILE
>    ffff99158718d1c8     400000     4de000 8000071 /home/crash/crash
>    ...
>
> The reasons are
> - htoll() only converts a hexadecimal string to an unsigned long long
>    value and does not evaluate whether it's a valid kernel virtual
>    address or not, and
> - The specified value is used only when the task's mm_struct is NULL.
>
> Also, this behavior is not described enough in its help text, so it's
> confusing for users.
>
> Let's add a check on the converted value regardless of the task's
> mm_struct and add a description of the behavior to its help text.
>
> With the patch:
>    crash> vm -M 0xdeadbeef
>    vm: invalid mm_struct address: 0xdeadbeef
> -----
>
> Thanks,
> Kazu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20230324/af44b24d/attachment.htm>