netdev - Re: [UDP6]: Restore sk

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]

Message-Id: <20071101223414.3d9a92ec.mitch@linux.vnet.ibm.com>
Date:	Thu, 1 Nov 2007 22:34:14 +0900
From:	Mitsuru Chinen <mitch@...ux.vnet.ibm.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [UDP6]: Restore sk_filter optimisation

On Wed, 31 Oct 2007 22:42:57 +0800
Herbert Xu <herbert@...dor.apana.org.au> wrote:

> On Wed, Oct 31, 2007 at 11:05:45PM +0900, Mitsuru Chinen wrote:
> >
> > > >  1. udp6InDatagrams is incremented instead of udpInErrors
> > > >  2. In userland, recvfrom() replies an error with EAGAIN.
> > > >     recvfrom() wasn't aware of such a packet before.
> > > > 
> > > > Are these changes intentional?
> >
> > As far as I tested, this doesn't happen with the old code even if
> > a filter is attached. However, this happen with the new code
> > without a filter and I don't see this rather when a filter is
> > attached. So, I'm afraid it's new.
> 
> Sorry, I read the patch the wrong way around :)
> 
> 1) is just an accounting issue.  It shouldn't be too difficult
> to fix it up.  In fact, I think udpInErrors will still be
> incremented once we detect the error.
> 
> 2) shouldn't be an issue because we've already solved the
> problem by making poll/select do the checksum verification
> before indiciating that the socket is readable.
> 
> > > And, we're not sure how much the "optimization"'s benefit is.
> > > It is even worse when we are hand
> 
> The checksum verification is costly because we have to bring
> the payload into cache.  Since filters are very rare it's
> worthwhile to postpone the checksum verification for the common
> case.
> 
> Also as a general rule, we want to avoid divergent behaviour
> between IPv4 and IPv6.  So for changes like this we should
> really modify both stacks in future rather than have each
> stack do its own thing.

I got it. OK. I will submit a patch to postpone the udpInError
counter incrementation, either.

Thanks for your detailed explanation!

Best Regards,
----
Mitsuru Chinen <mitch@...ux.vnet.ibm.com>
-
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