On Fri, Mar 24, 2023 at 8:45 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio...@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 >
-- Crash-utility mailing list Crash-utility@redhat.com https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
