Re: [PATCH] tty/serial: create debugfs interface for UART register tracing

[Dan Raymond <draymond@foxvalley.net>]

On 8/23/2023 1:01 AM, Greg KH wrote:

> This really should be a Kconfig option as some people will not want the
> added size, or feature, in their system as many serial ports have data
> that other users, even root ones, shouldn't be snooping on (i.e.
> cell modems.)

Done.

> Can you wrap comments at 80 columns please?  Code is fine to go to 100.

Sure.

>> + *
>> + *  Each serial port ("ttyS0", "ttyS1", etc.) will have its own directory in the root of
>> + *  the debug filesystem.  Inside each directory will be the following pseudo-files:
>> + *
>> + *  trace_all    - toggles tracing of all registers vs. just the RX/TX registers
> So 0 is just rx/tx?

Yes, 0 is just rx/tx.  I've updated the comment to reflect that.

> This should be documented somewhere in Documentation/ OR better yet, in
> kernel doc format so that when building the documentation, it sucks it
> in from this file to be included there automatically.
>
> And what are the default values of these files at boot?

I've converted this to kernel-doc format and linked it to 
Documentation/trace/index.rst.  I've also documented the default values.

>> + *  Example session:
>> + *
>> + *  > mount -t debugfs debugfs /sys/kernel/debug
>> + *  > echo '1' > /sys/kernel/debug/ttyS1/trace_all
>> + *  > echo '1' > /sys/kernel/debug/ttyS1/trace_enable
> Any reason why you didn't just use the existing kernel tracing facility
> for all of this?

No, it just seemed easier to use the debugfs.  Not a good reason, I 
know.  I'll take a closer look at the tracefs for this.

> This is the big issue I have with this change, sorry, it's an odd one.
>
> The use of "uintX_t" variable types belongs in userspace, these are not
> kernel data types (yes, they are used in places, but no, they do not
> make sense, see the many times Linus and I have talked about this in the
> past, wrong namespace, etc.)
>
> Can you change these all to the normal types of u32, u16, u8 and so on
> please?

Done.

>> +struct reg_queue {
>> +	uint32_t          read_idx;   /* first full (written) slot */
>> +	uint32_t          write_idx;  /* first empty (unwritten) slot */
>> +	struct reg_event *buf;        /* array to hold the data */
>> +	uint32_t          size;       /* array size (number of entries - must be power of 2) */
>> +	bool              wrap;       /* true if write_idx wrapped around and reached read_idx */
> If you use pahole on this structure, you will see you can get this a bit
> smaller.  Although I don't think you use this a lot, right?

I was using a 32-bit target and pahole didn't show any gaps. Does the 
pointer cause a gap on 64-bit targets?  In any case I moved the pointer 
to the top of the structure.

>> +
>> +struct uart_debug {
>> +	spinlock_t        lock;
>> +	struct mutex      mutex;
> Why 2 locks?  Please document these.

The spinlock protects the 'struct reg_queue' which can be accessed from 
interrupt context and normal context.  The mutex protects the outer data 
structure which only the user accesses so it doesn't need to disable 
interrupts.  I moved the spinlock to the reg_queue to make this more 
explicit.

>> +	char              line[64];  /* buffer to hold text of last item removed from queue */
> Why 64?

I changed it to 28 which is just enough to hold the 26-character 
register event string + newline + NUL.

>> +static ssize_t      all_read(struct file *filp, char __user *buf, size_t size, loff_t *ppos);
>> +static ssize_t      all_write(struct file *filp,
>> +			const char __user *buf, size_t size, loff_t *ppos);
>> +static ssize_t      buffer_read(struct file *filp, char __user *buf, size_t size, loff_t *ppos);
>> +static ssize_t      enable_read(struct file *filp, char __user *buf, size_t size, loff_t *ppos);
>> +static ssize_t      enable_write(struct file *filp,
>> +			const char __user *buf, size_t size, loff_t *ppos);
>> +static void         format_cycle(uint64_t cpu_cycles, char *buf, uint32_t size);
>> +static void         queue_add(struct uart_port *port, uint8_t reg, uint8_t data, bool write);
>> +static bool         queue_alloc(struct uart_port *port);
>> +static void         queue_free(struct uart_port *port, bool force);
>> +static void         queue_remove(struct uart_port *port, char *buf, uint32_t size);
>> +static unsigned int serial_in_wrapper(struct uart_port *port, int offset);
>> +static void         serial_out_wrapper(struct uart_port *port, int offset, int value);
>> +static ssize_t      size_read(struct file *filp, char __user *buf, size_t size, loff_t *ppos);
>> +static ssize_t      size_write(struct file *filp,
>> +			const char __user *buf, size_t size, loff_t *ppos);
> Any chance to reorginize the code to not need the forward declarations?

I generally keep functions in alphabetical order and choose names 
accordingly so they are grouped the way I want.  For example, the 
queue_xxx() functions are the only ones that touch the reg_queue 
structure.  I use forward declarations (whether needed or not) to avoid 
compiler errors regardless of the function order.  Is this a bad practice?

> Nice hack to make the overhead "zero" but now you have 2 function jumps
> per character, on some systems that can be a lot of overhead.  Why not
> just use the existing trace functionality for this instead?  If the
> feature is not enabled, it will not have any overhead, and if it is, it
> will only have the one call to your hook, saving you another function
> call jump (which on modern processors is VERY slow thanks to spectre
> issues...)

Can you clarify the functionality you are suggesting?  Is it the mcount 
call inserted by the compiler for function tracing?  I guess I need to 
get more familiar with the kernel tracing facility to make a comparison 
but maybe you could point me in the right direction?

>
> We do have at least 2 different ringbuffer structures in the kernel, why
> create another one?

Can you point me to the structures you have in mind?  One thought is 
that I have a 'wrap' flag which is a little paranoid but it ensures that 
a buffer overflow is detected.

> Anyway, again, cool feature, I like it, but if you can tie it into the
> existing trace framework better (either by using that entirely which
> might be best), or at the least, putting your hook into the data path
> with it, that would be best.
>
> thanks,
>
> greg k-h

Thanks for your review!  I've created another patch that incorporates 
most of your suggestions and I'll post that next. I'll also spend some 
more time looking at the tracefs to address your other suggestions.