Page MenuHomeFreeBSD

intrng: merge INTR_ISRC_NAMELEN into INTRNAME_LEN
Needs ReviewPublic

Authored by ehem_freebsd_m5p.com on Jan 19 2023, 3:01 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 21, 3:41 PM
Unknown Object (File)
Thu, Nov 21, 2:28 PM
Unknown Object (File)
Oct 22 2024, 9:45 PM
Unknown Object (File)
Sep 24 2024, 3:33 AM
Unknown Object (File)
Sep 23 2024, 1:45 PM
Unknown Object (File)
Sep 18 2024, 6:31 AM
Unknown Object (File)
Sep 11 2024, 2:03 AM
Unknown Object (File)
Sep 11 2024, 1:15 AM

Details

Reviewers
markj
mmel
manu
Summary

INTRNAME_LEN and INTR_ISRC_NAMELEN serve extremely similar purposes.
Setting the length of interrupt name strings. Having two values with
near-identical purposes, but different values serves to confuse. In
turn this is a recipe for trouble if the wrong one is used. As such
merge them together.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 49255
Build 46145: arc lint + arc unit

Event Timeline

I had originally written D38116 before doing this. Then on review I realized this was a distinct value and that would cause things to explode. This does mean intermediate strings are shorter, but these rarely occur. As such I tend to opt for this approach and getting rid of the booby trap.

This also effects D35898 as I believe the combined length value should be used for ii_name as well.

I checked find sys -type f -print0 | xargs -0 grep -eINTR_ISRC_NAMELEN -l and no results. Could be a few spots use sizeof(isrc->isrc_name).

Looking at isrc_update_name(), we concatenate two strings, one from a buffer of size MAXCOMLEN+1, so changing INTRNAME_LEN from 2*MAXCOMLEN+1 to MAXCOMLEN+1 seems likely to introduce some string truncation? Shouldn't we keep the original, larger size?

This is true, but this is also the nature of fixed-length strings. Copy from too long a string and it will overflow. If the truncation becomes a problem, you can increase the string length. I worry more having two fixed-length strings of different lengths is a recipe for a security hole.

I dislike MAXCOMLEN not including the terminator. Also looks like rather a long time since MAXCOMLEN was last increased.

jhb added inline comments.
sys/kern/subr_intr.c
477

FYI, I would maybe change this to use vsnprintf(isrc->isrc_name, sizeof(isrc->isrc_name), ...) I'm not sure if that approach means you can use the constant in fewer places?

As far as it goes, I could see moving INTRNAME_LEN from sys/sys/intr.h to sys/sys/interrupt.h, then replacing all the instances of MAXCOMLEN + 1 in the PowerPC/x86 intr_machdep.c files with INTRNAME_LEN. Then INTRNAME_LEN could instead use 2*MAXCOMLEN + 1.

Ultimately though the interrupt name strings will get truncated somewhere at some limit. I see little gain by having an extra constant which merely moves where the truncation occurs and increases confusion.

sys/kern/subr_intr.c
477

I agree with this, it is in my tree. Doesn't really make too large of an impact right now though.

ehem_freebsd_m5p.com marked an inline comment as done.

Updating as per @jhb's comment. Checking I noticed INTR_IPI_NAMELEN should also be part of this and merged those in.

Ping on D38115. I've got a patch/commit for moving INTRNAME_LEN to sys/sys/interrupt.h and switching PowerPC/x86 to use INTRNAME_LEN instead of MAXCOMLEN + 1. I'm wondering whether that would be acceptable for reviewing as part of D38115 (the overlap is so heavy it seems to make sense, but others may disagree).