[RFC PATCH iproute2 0/3] ss: follow-ups to the packet/netlink /proc removal

[Stephen Hemminger <stephen@networkplumber.org>]

This is the overly wordy AI suggestions:


Commit a2b31976 ("ss: drop the /proc parsers for packet and netlink
sockets") removed the sscanf() based /proc/net/packet and
/proc/net/netlink fallbacks.  Reviewing it turned up three loose ends,
one of which is a real regression from that commit.  Sending as RFC
because patch 3 changes user-visible filtering behaviour and I have
not been able to exercise it (see below).

Patch 1 is the regression fix and is the one that matters.  a2b31976
removed the fallback but left the code whose only purpose was to
request it:

	/* use /proc/net/packet if all info are not available */
	if (!tb[PACKET_DIAG_MEMINFO])
		return -1;

That -1 used to propagate up so packet_show() would retry via
net_packet_open().  With no fallback left it is returned from an
rtnl_dump_filter() callback, which aborts the dump.  A kernel that
omits PACKET_DIAG_MEMINFO for a socket now silently truncates the
listing at that socket rather than falling back.  The check is
redundant in any case: the code below already guards the attribute and
leaves stat.rq at 0 when it is absent.

Patch 2 adds a diagnostic.  Without the /proc fallback, "ss -0" on a
kernel lacking CONFIG_PACKET_DIAG prints a header and nothing else.
AF_PACKET sockets exist on essentially every system, so an empty
listing reads as "no sockets" rather than "ss could not ask" -- unlike
tipc or vsock, where an empty result is unremarkable.  rtnl_dump_error()
deliberately swallows ENOENT and EOPNOTSUPP for NETLINK_SOCK_DIAG
precisely because callers used to fall back to /proc, so those two are
reported at the call site.  Exit status is unchanged.

Patch 3 restores packet_raw/packet_dgram filtering.  This one is not a
regression from a2b31976, but that commit is what made it
unconditional.  The SOCK_RAW/SOCK_DGRAM check only ever lived in the
removed /proc parser; the sock_diag path never had it, and since
packet_show() already preferred sock_diag, "ss -A packet_raw" has been
returning dgram sockets on any kernel with packet_diag for a long time.

Open question, and the reason for the RFC tag: I could not get
"ss -A packet", "-A packet_raw" or "-A packet_dgram" to list anything
at all, on current HEAD or before this series, while "ss -0" works
fine.  filter_db_set() sets f->states and f->dbs but never
f->families, whereas -0 goes via filter_af_set(), which does set it;
packet_show() then gates on filter_af_get(f, AF_PACKET).  If that is
the cause then -A packet* has been a no-op independently of any of
this, and patch 3's filtering cannot be reached through -A until it is
fixed.  I have not confirmed this and deliberately have not touched it
here.  So patch 3 is verified only in that it compiles clean and does
not over-filter the default "ss -0" path; the case it exists for is
untested.  Review of that patch especially welcome.

Patches 1 and 2 were tested on a kernel with packet_diag, including a
simulated PACKET_DIAG failure to confirm the new message goes to
stderr and leaves stdout clean.

Stephen Hemminger (3):
  ss: drop the dead /proc fallback trigger in packet_show_sock()
  ss: warn when packet socket diag is unavailable
  ss: restore packet_raw/packet_dgram filtering

 misc/ss.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

--
2.53.0

Stephen Hemminger (3):
  ss: drop the dead /proc fallback trigger in packet_show_sock()
  ss: warn when packet socket diag is unavailable
  ss: restore packet_raw/packet_dgram filtering

 misc/ss.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

-- 
2.53.0