Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Tue, 24 Oct 2023 03:59:28 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     David Laight <David.Laight@aculab.com>
Cc:     Eric Dumazet <edumazet@google.com>,
        gus Gusenleitner Klaus <gus@keba.com>,
        Al Viro <viro@ftp.linux.org.uk>,
        Thomas Gleixner <tglx@linutronix.de>,
        lkml <linux-kernel@vger.kernel.org>,
        Ingo Molnar <mingo@redhat.com>, "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        "dsahern@kernel.org" <dsahern@kernel.org>,
        "kuba@kernel.org" <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>
Subject: Re: AW: [PATCH] amd64: Fix csum_partial_copy_generic()
Message-ID: <20231024025928.GD800259@ZenIV>
References: <20231019050250.GV800259@ZenIV>
 <20231019061427.GW800259@ZenIV>
 <20231019063925.GX800259@ZenIV>
 <CANn89iJre=VQ6J=UuD0d2J5t=kXr2b9Dk9b=SwzPX1CM+ph60A@mail.gmail.com>
 <20231019080615.GY800259@ZenIV>
 <20231021071525.GA789610@ZenIV>
 <20231021222203.GA800259@ZenIV>
 <5487af5c8c184ac896af2d0b32b3ff42@AcuMS.aculab.com>
 <20231022111153.GB800259@ZenIV>
 <2a4555bf640e4bc4b76e1ae14e5cb5e1@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2a4555bf640e4bc4b76e1ae14e5cb5e1@AcuMS.aculab.com>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Mon, Oct 23, 2023 at 08:16:59AM +0000, David Laight wrote:
> From: Al Viro
> > Sent: 22 October 2023 12:12
> > 
> > On Sun, Oct 22, 2023 at 11:03:39AM +0000, David Laight wrote:
> > 
> > > > +			return -1;
> > >
> > > If you are going to return -1 the return type should be signed.
> > 
> > It's a perfectly valid C to have return -1 in a function that
> > returns unsigned long long (or any other unsigned type, really)...
> 
> It is also valid C to return a pointer :-)

No, it is not.  Conversions done for return are the same as for
assignments; in particular, conversion from any integer type to
any unsigned integer type is done by taking the value modulo
the range of target type.  Conversion from pointer to an integer,
OTOH, is a constraint violation.

> I also suspect that sparse will complain massively and
> require a lot of the horrid (__force) casts.
> (They should really be a function so that they are completely
> ignored by the compiler - unless the compiler needs a cast as well.)

Why would sparse "complain massively" about operations with u64?
I realize that you've slapped "I suspect" in front of that
particular load of fertilizer, but... seriously, your output is
very hard to distinguish from ChatGPT drivel ;-/