Page MenuHomeFreeBSD
Differential D55660

inpcb: remove extraneous check in inp_next()
AbandonedPublic
Actions

Authored by glebius on Mar 4 2026, 9:39 PM.
Tags
None
Referenced Files
F174284631: D55660.id.diff
Fri, Oct 2, 12:57 AM
Unknown Object (File)
Thu, Oct 1, 4:57 AM
Unknown Object (File)
Sun, Sep 20, 4:56 AM
Unknown Object (File)
Sun, Sep 20, 2:18 AM
Unknown Object (File)
Sun, Sep 20, 2:15 AM
Unknown Object (File)
Wed, Sep 9, 3:09 PM
Unknown Object (File)
Aug 29 2026, 8:47 AM
Unknown Object (File)
Aug 23 2026, 9:24 AM
View All 44 Files
Subscribers
imp
melifaro
pouria

Details

Reviewers
markj
Group Reviewers
network
Summary

The condition of the embracing for(;;) loop is the same.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 71186
Build 68069: arc lint + arc unit

Event Timeline

glebius created this revision.Mar 4 2026, 9:39 PM
Herald added subscribers: melifaro, imp. · View Herald TranscriptMar 4 2026, 9:39 PM
Harbormaster completed remote builds in B71186: Diff 173155.Mar 4 2026, 9:39 PM
glebius requested review of this revision.Mar 4 2026, 9:39 PM
pouria added a subscriber: pouria.Mar 4 2026, 9:52 PM
pouria added inline comments.
sys/netinet/in_pcb.c
1601

Is it possible for inp to become NULL here first, and then for the for loop to attempt to update inp by assigning II_LIST_NEXT(**NULL**, hash) here?

pouria added inline comments.Mar 4 2026, 10:03 PM
sys/netinet/in_pcb.c
1601

I mean, theorically, for loop will update the variable first and then it will test its condition.
I don't think if II_LIST_NEXT can tolerate NULL input as its argument.
since it'll call the CK_LIST_NEXT macro and it will dereference inp to find its next element: &(NULL)->field.cle_next

glebius abandoned this revision.Mar 5 2026, 2:17 AM

Today was my turn to be stupid :) See 430df2abee9049c2e4773704190a9f0d1779ff10

Revision Contents
Changeset List

PathSize
sys/
netinet/
2 lines

Diff 173155

View Options

sys/netinet/in_pcb.c

Loading...