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
| ||
|
Date: Mon, 12 May 2008 20:56:16 -0700 From: "Jerry Chu" <hkchu@...gle.com> To: "David Miller" <davem@...emloft.net> Cc: netdev@...r.kernel.org Subject: Re: Socket buffer sizes with autotuning On Mon, May 12, 2008 at 3:31 PM, David Miller <davem@...emloft.net> wrote: > From: David Miller <davem@...emloft.net> > Date: Mon, 12 May 2008 15:29:00 -0700 (PDT) > > > > Simply notice, when we're about to decrement in_flight, that the data > > reference is one. You can take appropriate actions if so. > > Actually, there is an even simpler solution. Since this is a fast > clone, when the parent SKB is freed we can see if the fast-clone child > is active and has the in_flight atomic_t pointer. If so, we decrement > in_flight and zap it to NULL. I thought about that too. But what happens if the clone is being freed by the driver at the same time when TCP is freeing the parent? Isn't there an intrinsic race condition here? If true, can we use some atomic operation to zap in_flight, but also return to the caller if in_flight has been nullified already so that the accounting can be handled correctly? (Although tp->host_inflight doesn't need to be super accurate, if there is no simple solution above I'll have to reset tp->host_inflight periodically and convince myself the pathological case of host_inflight drifting forever won't ever happen...) Jerry -- 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
Powered by blists - more mailing lists