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