From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 569F5C433E1 for ; Wed, 22 Jul 2020 17:39:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 29F3720787 for ; Wed, 22 Jul 2020 17:39:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727840AbgGVRjL (ORCPT ); Wed, 22 Jul 2020 13:39:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726157AbgGVRjK (ORCPT ); Wed, 22 Jul 2020 13:39:10 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 790B5C0619DC; Wed, 22 Jul 2020 10:39:10 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyIhr-000Qcs-Cu; Wed, 22 Jul 2020 17:39:03 +0000 Date: Wed, 22 Jul 2020 18:39:03 +0100 From: Al Viro To: David Laight Cc: Linus Torvalds , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" Subject: Re: [PATCH 04/18] csum_and_copy_..._user(): pass 0xffffffff instead of 0 as initial sum Message-ID: <20200722173903.GG2786714@ZenIV.linux.org.uk> References: <20200721202425.GA2786714@ZenIV.linux.org.uk> <20200721202549.4150745-1-viro@ZenIV.linux.org.uk> <20200721202549.4150745-4-viro@ZenIV.linux.org.uk> <2d85ebb8ea2248c8a14f038a0c60297e@AcuMS.aculab.com> <20200722144213.GE2786714@ZenIV.linux.org.uk> <4e03cce8ed184d40bb0ea40fd3d51000@AcuMS.aculab.com> <20200722155452.GF2786714@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 22, 2020 at 04:17:02PM +0000, David Laight wrote: > > David, do you *ever* bother to RTFS? I mean, competent supercilious twits > > are annoying, but at least with those you can generally assume that what > > they say makes sense and has some relation to reality. You, OTOH, keep > > spewing utter bollocks, without ever lowering yourself to checking if your > > guesses have anything to do with the reality. With supercilious twit part > > proudly on the display - you do speak with confidence, and the way you > > dispense the oh-so-valuable advice to everyone around... > > Yes, I do look at the code. > I've actually spent a lot of time looking at the x86 checksum code. > I've posted a patch for a version that is about twice as fast as the > current one on a large range of x86 cpus. > > Possibly I meant the 32bit reduction inside csum_add() > rather than what csum_fold() does. Really? static inline unsigned add32_with_carry(unsigned a, unsigned b) { asm("addl %2,%0\n\t" "adcl $0,%0" : "=r" (a) : "0" (a), "rm" (b)); return a; } static inline __wsum csum_add(__wsum csum, __wsum addend) { return (__force __wsum)add32_with_carry((__force unsigned)csum, (__force unsigned)addend); } I would love to see your patch, anyway, along with the testcases and performance comparison. > Having worked on the internals of SYSV, NetBSD and Linux I probably > forget the exact names for a few things. That's usually dealt with by a few minutes with grep and vi... > The brain can only hold so much information. Bravo. "I can't be arsed to check anything" spun into the claim of one's superior experience. What it means in practice is that your output is so much garbage that _might_ be untangled into something meaningful if the reader manages to guess the substitutions. Provided that the reconstruction won't not turn out to be a composite of things applying to different versions of different kernels, not being valid for any of those, that is...