On Fri, Mar 24, 2023 at 8:45 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@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