[Crash-utility] dev command deteriorates with new kernels

[Dave Anderson]

----- "Bob Montgomery" <bob.montgomery at hp.com> wrote:

> With respect to character devices:
> 
> Sometime way back in the 2.6ish kernel, the fops field of struct
> char_device_struct ceased to be used for anything, and on those
> kernels
> (like 2.6.18), dev always reports the OPERATIONS field as "(none)":
> 
> crash-4.0-8.10> dev
> CHRDEV    NAME            OPERATIONS
>    1      mem                     (none)
>    2      pty                     (none)
>    3      ttyp                    (none)
>    4      /dev/vc/0               (none)
>    4      tty                     (none)
>    4      ttyS                    (none)
>    5      /dev/tty                (none)
>    5      /dev/console            (none)
>    5      /dev/ptmx               (none)
>    7      vcs                     (none)
>   10      misc                    (none)
>   13      input                   (none)
>   21      sg                      (none)
>   29      fb                      (none)
> ...
> 
> Then recently (by 2.6.28, anyway), someone noticed that the fops field
> was unused and removed it from struct char_device_struct altogether, so
> now we get:
> 
> crash-4.0-8.10> dev
> 
> dev: invalid structure member offset: char_device_struct_fops
>      FILE: dev.c  LINE: 221  FUNCTION: dump_chrdevs()
> 
> [/home/bobm/bin/crash-4.0-8.10] error trace: 452e75 => 4cf528 => 4cf957 => 50d8d3
> CHRDEV    NAME            OPERATIONS
> 
>   50d8d3: OFFSET_verify+168
>   4cf957: dump_chrdevs+1043
>   4cf528: cmd_dev+198
>   452e75: exec_command+306
> 
> dev: invalid structure member offset: char_device_struct_fops
>      FILE: dev.c  LINE: 221  FUNCTION: dump_chrdevs()
> 
> crash-4.0-8.10>
> 
> The attached patch changes the behavior in both cases to something like
> this:
> 
> crash-4.0-8.10fix> dev
> CHRDEV    NAME            OPERATIONS
>    1      mem           ffffffff8043ee00  <memory_fops>
>    2      pty                     (none)
>    3      ttyp                    (none)
>    4      /dev/vc/0               (none)
>    4      tty                     (none)
>    4      ttyS                    (none)
>    5      /dev/tty                (none)
>    5      /dev/console            (none)
>    5      /dev/ptmx               (none)
>    7      vcs           ffffffff8043ff40  <vcs_fops>
>   10      misc          ffffffff8043fe40  <misc_fops>
>   13      input         ffffffff805413c0  <input_fops>
>   21      sg                      (none)
>   29      fb            ffffffff80531c60  <fb_fops>
> 
> Which is definitely an improvement.
>   
> But wondering about those remaining (none) entries, I found that if I
> pursue info through the cdev_map with a series of crash commands like
> this:
> 
> crash-4.0-8.10fix> p (*cdev_map.probes[2]).data
> $7 = (void *) 0xffff81013a66c408
> crash-4.0-8.10fix> p (*(struct cdev *)0xffff81013a66c408).ops
> $8 = (const struct file_operations *) 0xffffffff8043f860
> crash-4.0-8.10fix> sym 0xffffffff8043f860
> ffffffff8043f860 (r) tty_fops
> 
> 
> crash-4.0-8.10fix> p (*cdev_map.probes[21]).data
> $9 = (void *) 0xffff81013acf8d80
> crash-4.0-8.10fix> p (*(struct cdev *)0xffff81013acf8d80).ops
> $10 = (const struct file_operations *) 0xffffffff8820ee00
> crash-4.0-8.10fix> sym 0xffffffff8820ee00
> ffffffff8820ee00 (d) sg_fops
> 
> I can come up with believable file_ops values for (most? all?) of the
> others.  And this leads me to wonder if crash shouldn't be collecting
> this info in a similar manner to fill in the other OPERATIONS fields.
> But now I'm quite a bit past what I know about how the character device
> stuff works.
> 
> 
> Thanks,
> Bob Montgomery
> Working at HP

Thanks Bob, I appreciate your investigation and patch.

I'll take a look (it's been years...), and build upon your patch to have the
command dig further when necessary.   

Dave