| commit | 6410840fb40a141780d464294053fab8a115952b | [log] [tgz] |
|---|---|---|
| author | Andrew Jeffery <andrew@codeconstruct.com.au> | Mon Jun 02 13:14:39 2025 +0930 |
| committer | Andrew Jeffery <andrew@codeconstruct.com.au> | Mon Jun 02 13:26:00 2025 +0930 |
| tree | 5c2846ccea19d37a6dbf2d0382bd9f1bce5c25d6 | |
| parent | 375786fc0e8ce34d72bafffb03a28689df94fb62 [diff] |
console-server: Fix pointer arithmetic in container_of() implementation
Pointer arithmetic is performed in units of the size of the pointed-to
object. Cast to char to ensure that both the pointer arithmetic is
defined, and that subtracting the result of the offsetof() stays
in-bounds.
The issue was detected by clang-tidy:
```
>>> /usr/bin/clang-tidy --use-color -export-fixes .../obmc-console/buildc92dibdo/meson-private/clang-tidy-fix/log-handler.c.m2f5figo.yaml -quiet -p .../obmc-console/buildc92dibdo .../obmc-console/log-handler.c
9557 warnings generated.
../log-handler.c:50:9: error: suspicious usage of 'offsetof(...)' in pointer arithmetic; this scaled value will be scaled again by the '-' operator [bugprone-sizeof-expression,-warnings-as-errors]
50 | return container_of(handler, struct log_handler, handler);
| ^
../console-server.h:272:27: note: expanded from macro 'container_of'
272 | ((type *)((void *)((ptr) - offsetof(type, member))))
| ^ ~~~~~~~~~~~~~~~~~~~~~~
../log-handler.c:50:9: note: '-' in pointer arithmetic internally scales with 'sizeof(struct handler)' == 8
50 | return container_of(handler, struct log_handler, handler);
| ^
../console-server.h:272:27: note: expanded from macro 'container_of'
272 | ((type *)((void *)((ptr) - offsetof(type, member))))
| ^
```
Change-Id: I808428c0a751abeb4409cf28dd5e95588ae5c0e2
Fixes: 1a0e03b4385e ("Split IO handling code into separate handler modules")
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
To build this project, run the following shell commands:
meson setup build meson compile -C build
To test:
dbus-run-session meson test -C build
Running the server requires a serial port (e.g. /dev/ttyS0):
touch obmc-console.conf ./obmc-console-server --config obmc-console.conf ttyS0
To connect to the server, simply run the client:
./obmc-console-client
To disconnect the client, use the standard ~. combination.
This shows how the host UART connection is abstracted within the BMC as a Unix domain socket.
+---------------------------------------------------------------------------------------------+
| |
| obmc-console-client unix domain socket obmc-console-server |
| |
| +----------------------+ +------------------------+ |
| | client.2200.conf | +---------------------+ | server.ttyVUART0.conf | |
+---+--+ +----------------------+ | | +------------------------+ +--------+-------+
Network | 2200 +--> +->+ @obmc-console.host0 +<-+ <--+ /dev/ttyVUART0 | UARTs
+---+--+ | console-id = "host0" | | | | console-id = "host0" | +--------+-------+
| | | +---------------------+ | | |
| +----------------------+ +------------------------+ |
| |
| |
| |
+---------------------------------------------------------------------------------------------+
This supports multiple independent consoles. The console-id is a unique portion for the unix domain socket created by the obmc-console-server instance. The server needs to know this because it needs to know what to name the pipe; the client needs to know it as it needs to form the abstract socket name to which to connect.
In some hardware designs, multiple UARTS may be available behind a Mux. Please reference docs/mux-support.md in that case.
For developing obmc-console, we can use pseudo terminals (pty's) in Linux.
The socat command will output names of 2 pty's, one of which is the master and the other one is the slave. The master pty can be used to emulate a UART.
$ socat -d -d pty,raw,echo=0,link=pty1 pty,raw,echo=0,link=pty2 $ obmc-console-server --console-id dev $(realpath pty2) $ obmc-console-client -i dev # this message should appear for the client $ echo "hi" > pty1