netdev - Re: [PATCH] [PATCH] tcp: Increment of LINUX_MIB_LISTENOVERFLOWS in tcp_v4_conn

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 29 Jan 2013 09:19:57 -0800
From:	Vijay Subramanian <subramanian.vijay@...il.com>
To:	Nivedita Singhvi <niveditasinghvi@...il.com>
Cc:	netdev@...r.kernel.org, David Miller <davem@...emloft.net>,
	Nivedita Singhvi <niv@...ibm.com>
Subject: Re: [PATCH] [PATCH] tcp: Increment of LINUX_MIB_LISTENOVERFLOWS in
 tcp_v4_conn_request() (updated)

> Firstly, before my verbosity here, I'll definitely send in an updated
> version with LISTENDROPS incremented as well as you suggest, separately.
> It gets us towards (1) option I outline below.

Thanks for the updated patch. I have acked it.

>
> The right way to fix that is to agree to what the counters should hold
> and then add the remaining instances where they should be incremented
> (which is what I was sort of half way through). I ran into this while
> debugging a problem of missing packets.
>
> We can:
>
> 1. Consider LISTENDROPS a count of all drops prior to the connection
>    getting ESTABLISHED.  Increment LISTENDROPS everywhere OVERFLOWS
>    is, but also add the increments to LISTENDROPS where we drop the
>    pkt for other reasons.

I think the current code has these semantics. However, prior to your
patch, these counters
were incremented only in tcp_v4_syn_recv_sock().  There may be other
places where we may need to update
these counters.


>
> 2. Remove LISTENDROPS if we don't want to count any other drops, keep
>    only LISTENOVERFLOWS.
>

> Is there anything I'm not seeing here and being a dufus about (likely)?
> Any reason not to do (1)?
>

We cannot remove any counters or change their meaning since they will
break existing applications in my opinion.
So I agree (1) is the best option. The code does this currently but
there may be places where the counters are not getting updated.
We can find and fix these missed updates.

Thanks,
Vijay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html