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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EA904C54E41 for ; Tue, 27 Feb 2024 17:55:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tzp11pEFh0jfbbY9kRPVkgXHAYUi9u9PMm6W4HgPuvE=; b=b9oMzPVe47CYT4 oUfTwNha4I97R+QD2oJ9NUKbump0xD0+fTlk5erxpGEQIVoSWvsScVlDagj0DdJfeYJ0KHNk2/xib kIF3zexLLz0WhuwFHPsyefYE6+BySC543grl0L80F8KxkVg/rlpywb9kzHEO1hWH2eF4w8uVPI2Ru trWW5orNBVTlRtUzT+mFhiaiwOmYwk66CjLPWC7TA+I/AI0XQvsYRctjaMJAxKVOgxWckvsDy4fEQ zBAiaWrh2fvmkkZJsx49GSccNLfpguZ0Tisysx8LTB76XlpPQu/ekS/xXJGJAhCJH9lv6LPeWyqeB wr3QasZ/VYBKTIZRD4TQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rf1fQ-00000006JzK-0xiT; Tue, 27 Feb 2024 17:55:00 +0000 Received: from mail-pg1-x535.google.com ([2607:f8b0:4864:20::535]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rf1fM-00000006Jy4-10Dg for linux-arm-kernel@lists.infradead.org; Tue, 27 Feb 2024 17:54:57 +0000 Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-5cedfc32250so4238923a12.0 for ; Tue, 27 Feb 2024 09:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1709056493; x=1709661293; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=kIdksP1jXgRqd1isvnR0Pk+ChLgtGPiZTFxnnPSsol0=; b=3fmRFBIuUAzJ7MgbxK4ACBEJJbqmOr/bF+Aohvfxk3Dcjr9l/bxPE7ywlrVJf86bst oy9gHxo8h/abNsZtrbSHG/nahklsU4balibt1EY6Q0/EYqFXz5qL5GbcEsFBd8wHq2hc kOfYM1sOBeF9rL5Wp94ytGiyeHz7Npy+R+kkGab8Y/2xLDwdpmHZ4WmfKdGKGJ9Ii5Fp NmtbXvW5m7dL/f8AzE2vUMagLY7fVFvicXG+M2uZSZy6HNltzsUNeSOuHfN/60JejA0t 8bSKsLP31jYgnRw+dv0gyT9aWGXLLZhpX/ajTuqU32O9wB2ZycyzkL2WWMNmyvjQp6VZ +PwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709056493; x=1709661293; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kIdksP1jXgRqd1isvnR0Pk+ChLgtGPiZTFxnnPSsol0=; b=Ax4pqQwRy73G1bR5T89HhpyGUTeFwUAmE/lu+efHjWl/jyKIXVQJH8367Mlmw0+s5v /ycqe96p+qPQ/uUCQomx3Azn0awZKMuIe1KLxuWUUCcRFujtfRVhGlMuiF4Uz+0htv0u TCCO5Un95Cb1ogkDl0S4vqopV2hfiSuxWhgEo4fO0QTY0hp4cD1LjN5kGC1RoCcA1Ljz +QCYaIVgOGXjswjxpMY1w7ryDH8Z5gDuxozsZs2d5AslM/1Pl9Dmub5Q5bHRFgt+VlfC i25edfn7jnDreQt9Z1bzB55yTcBq1BU/w/m8fMQjPkWI20HNyak3v4WClRhSlTrUgMRV 3qjQ== X-Forwarded-Encrypted: i=1; AJvYcCWDZnVtvOUEkugMTnNGKUVdHxZrV1F5JnR+PW4I7WpRCGqOZ5nH6IEjd3hkTpUSjUWhA68FoDHz1OyQYAOWleFLdifz/y9PRLJ0LMNbFfixTrodahI= X-Gm-Message-State: AOJu0YxPAwrjHhQ1YrgDFxA5jF5rK865g0c/gC+U3G08rwOg7y/sgJEa RT30Rsslq7p7ku7fmHN386XZIdfuNfdVKdb22+8u/q7KfI9jWFmshVsEKRmTU+M= X-Google-Smtp-Source: AGHT+IFz6f/uoaRRDlAo9FUesEjMdjsM1i3WorOHOm7Rgb/Bu93+PnLqfHQ9b5gv518bhE6IEAiu6A== X-Received: by 2002:a17:90a:6f01:b0:299:75aa:8949 with SMTP id d1-20020a17090a6f0100b0029975aa8949mr7822691pjk.22.1709056493179; Tue, 27 Feb 2024 09:54:53 -0800 (PST) Received: from ghost (mobile-166-137-160-039.mycingular.net. [166.137.160.39]) by smtp.gmail.com with ESMTPSA id n15-20020a17090ade8f00b002995e9aca72sm6856207pjv.29.2024.02.27.09.54.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Feb 2024 09:54:52 -0800 (PST) Date: Tue, 27 Feb 2024 09:54:49 -0800 From: Charlie Jenkins To: Christophe Leroy Cc: "Russell King (Oracle)" , Guenter Roeck , David Laight , Palmer Dabbelt , Andrew Morton , Helge Deller , "James E.J. Bottomley" , Parisc List , Arnd Bergmann , "linux-kernel@vger.kernel.org" , Palmer Dabbelt , Linux ARM Subject: Re: [PATCH v10] lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests Message-ID: References: <9b4ce664-3ddb-4789-9d5d-8824f9089c48@csgroup.eu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240227_095456_511078_6D68BA79 X-CRM114-Status: GOOD ( 49.48 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Feb 27, 2024 at 11:32:19AM +0000, Christophe Leroy wrote: > = > = > Le 27/02/2024 =E0 11:28, Russell King (Oracle) a =E9crit=A0: > > On Tue, Feb 27, 2024 at 06:47:38AM +0000, Christophe Leroy wrote: > >> > >> > >> Le 27/02/2024 =E0 00:48, Guenter Roeck a =E9crit=A0: > >>> On 2/26/24 15:17, Charlie Jenkins wrote: > >>>> On Mon, Feb 26, 2024 at 10:33:56PM +0000, David Laight wrote: > >>>>> ... > >>>>>> I think you misunderstand. "NET_IP_ALIGN offset is what the kernel > >>>>>> defines to be supported" is a gross misinterpretation. It is not > >>>>>> "defined to be supported" at all. It is the _preferred_ alignment > >>>>>> nothing more, nothing less. > >>>> > >>>> This distinction is arbitrary in practice, but I am open to being pr= oven > >>>> wrong if you have data to back up this statement. If the driver choo= ses > >>>> to not follow this, then the driver might not work. ARM defines the > >>>> NET_IP_ALIGN to be 2 to pad out the header to be on the supported > >>>> alignment. If the driver chooses to pad with one byte instead of 2 > >>>> bytes, the driver may fail to work as the CPU may stall after the > >>>> misaligned access. > >>>> > >>>>> > >>>>> I'm sure I've seen code that would realign IP headers to a 4 byte > >>>>> boundary before processing them - but that might not have been in > >>>>> Linux. > >>>>> > >>>>> I'm also sure there are cpu which will fault double length misalign= ed > >>>>> memory transfers - which might be used to marginally speed up code. > >>>>> Assuming more than 4 byte alignment for the IP header is likely > >>>>> 'wishful thinking'. > >>>>> > >>>>> There is plenty of ethernet hardware that can only write frames > >>>>> to even boundaries and plenty of cpu that fault misaligned accesses. > >>>>> There are even cases of both on the same silicon die. > >>>>> > >>>>> You also pretty much never want a fault handler to fixup misaligned > >>>>> ethernet frames (or really anything else for that matter). > >>>>> It is always going to be better to check in the code itself. > >>>>> > >>>>> x86 has just made people 'sloppy' :-) > >>>>> > >>>>> =A0=A0=A0=A0David > >>>>> > >>>>> - > >>>>> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keyne= s, > >>>>> MK1 1PT, UK > >>>>> Registration No: 1397386 (Wales) > >>>>> > >>>> > >>>> If somebody has a solution they deem to be better, I am happy to cha= nge > >>>> this test case. Otherwise, I would appreciate a maintainer resolving > >>>> this discussion and apply this fix. > >>>> > >>> Agreed. > >>> > >>> I do have a couple of patches which add explicit unaligned tests as w= ell as > >>> corner case tests (which are intended to trigger as many carry overfl= ows > >>> as possible). Once I get those working reliably, I'll be happy to sub= mit > >>> them as additional tests. > >>> > >> > >> The functions definitely have to work at least with and without VLAN, > >> which means the alignment cannot be greater than 4 bytes. That's also > >> the outcome of the discussion. > > = > > Thanks for completely ignoring what I've said. No. The alignment ends up > > being commonly 2 bytes. > > = > > As I've said several times, network drivers do _not_ have to respect > > NET_IP_ALIGN. There are 32-bit ARM drivers which have a DMA engine in > > them which can only DMA to a 32-bit aligned address. This means that > > the start of the ethernet header is placed at a 32-bit aligned address > > making the IP header misaligned to 32-bit. > > = > > I don't see what is so difficult to understand about this... but it > > seems that my comments on this are being ignored time and time again, > > and I can only think that those who are ignoring my comments have > > some alterior motive here. > > = > = > I'm sorry for this misunderstanding. I'm not ignoring what you said at = > all. I understood that ARM is able to handle unaligned accesses with = > some exception handlers at worst case and that DMA constraints may lead = > to the IP header beeing on a 2 bytes alignment only. > = > However I also understood from others that some architectures can't = > handle such a 2 bytes only alignments. > = > It's been suggested during the discussion that alignment tests should be = > added later in a follow-up patch. So for the time being I'm trying to = > find a compromise and get the existing tests working on all platforms = > but with a smaller alignment than the 16-bytes alignment brought by = > Charlie's v10 patch. And a 4 bytes alignment seemed to me to be a good = > compromise for this fix. The idea is also to make the fix as minimal as = > possible, unlike Charlie's patch that is churning up the tests quite = > heavily. Do you have a list of platforms this is failing on? I haven't seen any reports that haven't been fixed. - Charlie > = > But maybe I misunderstood some of the discussion and indeed 2 bytes = > alignment would work on all platforms and only an odd alignment is = > problematic ? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel