tracing: A couple of fixes for v6.18
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest2 patches 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | tracing: Fix tracing_mark_raw_write() to use buf and not ubufkernel/ | +2 | 0 replies | |
| 2/2 | tracing: Stop fortify-string from warning in tracing_mark_raw_write()kernel/ | +5 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [for-linus][PATCH 0/2] tracing: A couple of fixes for v6.18
tracing fixes for v6.18:
- Fix tracing_mark_raw_write() to use per CPU buffer
The fix to use the per CPU buffer to copy from user space was needed for both the trace_maker and trace_maker_raw file. The trace_maker file is used to write ASCII text into the trace buffer, but the trace_maker_raw is used to write binary structures directly into the ring buffer.
The fix for reading from user space into per CPU buffers properly fixed the trace_marker write function, but the trace_marker_raw file wasn't fixed properly. The user space data was correctly written into the per CPU buffer, but the code that wrote into the ring buffer still used the user space pointer and not the per CPU buffer that had the user space data already written.
There are several tests in the test suite to test the trace_marker file but it appears that there's no tests that test the trace_marker_raw file (this needs to be fixed), and this bug was missed.
- Stop the fortify string warning from writing into trace_marker_raw
After converting the copy_from_user_nofault() into a memcpy(), another issue appeared. As writes to the trace_marker_raw expects binary data, the first entry is a 4 byte identifier. The entry structure is defined as:
struct {
struct trace_entry ent;
int id;
char dynamic_array[];};
The size of this structure is reserved on the ring buffer and the pointer to the structure on the ring buffer is assigned to "entry". Then the data is copied via a memcpy() with:
memcpy(&entry->id, buf, size);
But the fortify string detects that the size is bigger than the size of the entry->id and produces a false positive warning.
Hide the write from fortify string with:
void *ptr = entry; ptr += offsetof(typeof(*entry), id); memcpy(ptr, buf, size);
Steven Rostedt (2):
tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
tracing: Stop fortify-string from warning in tracing_mark_raw_write()
----
kernel/trace/trace.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)