From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 122131350CF for ; Mon, 26 Feb 2024 23:17:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708989431; cv=none; b=Bg1TlaeNHAMbGhtyzrV4XjQ1fLpE0lFmnv0H7UBzqDqPCkvQW/I9KvblqKind+S025pQRhJvTReXbwoGu3f3mMG4qIbbUTthHfphULgP9bGyf1dVpreOea8csLyq3qn6Do8pbGaOUrK4z990TMURormD2gpQ1MECrHJH51e2L0M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708989431; c=relaxed/simple; bh=qOuAEHrf8q5fX3cChhCFW8ymfxwHQRMOJI5lw870U9Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UkNuNaNe/VhWGLx+Y9IhBOZ7XUUEcg3Cwf4pb5F+d8DsGv+MK/aQYS6VgFtCe6M6kQTq72TEXuJsc2DcaxmeZglmwmY+bI8qqIwWGS6BVKUJwB6ZYoxVocTyXot3aZQGFC6j0JKbPrXNvlttH4HtoS1v+ivfeDAcpBKQKlvHRhs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=XhE7ozGm; arc=none smtp.client-ip=209.85.215.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="XhE7ozGm" Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-5ce942efda5so2895328a12.2 for ; Mon, 26 Feb 2024 15:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1708989428; x=1709594228; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eYuGQ7XfN8pbZjALsZ8f3cB3Gxf+yNkm9MR0bR+0+ps=; b=XhE7ozGmwgq4SsoKlUkPgQeU4OlwwzJeDxtRLHJIeTkjqsSTZR8X8oWsjoxZGYR2EP lxevk7gdSVPVj443CIFp4e7GtL7fmxGcx0ryBFJTqGyPZDbTgW5MURwhI/VfTzMnYsPY RxosxKuAiHQG2hwoLtKKN/9aGls70OKXBnBFe7M5B4laF8m5ADMDc7c1Vr9lEJmwVLaE W2ump7RJsVdiqwoR0Tw3ZUZ0qE6IYUyn0AusAMewe44czOqKH6XuQFTLouBPsjAYGakt vG68RLwcQfcO06IywyM5rlzXogIDCGxASCHpyKagNVWer+uIDHcqbqRDfYm1zOx9B/v3 QQfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708989428; x=1709594228; h=in-reply-to: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=eYuGQ7XfN8pbZjALsZ8f3cB3Gxf+yNkm9MR0bR+0+ps=; b=KM4Aw3q26BLx9QG8nvE5teDg7HQtJtXUhbmLvHwArsvR2+9cpc4MiX+MV8yEH406AL 1E9Gg/slyFX+qkAlO5hBikqBVPAmLXfjGho/O++xhASTk8OicLVgzh1bnuylBbGXuANO f/HZATxErDudxNxXC/4ytJjXyVhsBItcsYGoz9mO0N3KYgH0AFJRN/0aiht8TSm7IZA+ ePOGBS0Lu+rnHxWkEso8Aw+lro5A3quxkA4dnlEOpPjZ4CrUVt/adTRqoxD5f0PH4aGu GOgW0qkVQD9fnVoPnbHyPdijk10LuW1piIILTRglrDtQPYZKncxXXf+d2DAX9dkKIhuc Kilg== X-Forwarded-Encrypted: i=1; AJvYcCU5UVxu2d1m1yG/ud+eAffH58l7YQzmvEpLi6jW0FzWIQyBlzpgMjMblpaVZ/uQvrC3wO2+ywJz/XeDbBchdu+TwC+Yg5O0DQXbeKUt X-Gm-Message-State: AOJu0YxXq2IbZkHmI5WbmvmflOy0wuYZ5kkz6qs13Hho0jMpvXvgZ0P3 SsvbOKyOpcuL8O+t1dm/3Eq26P5jKpnqMmJcqysQNrYEEiA2/Nzgf1xcGowAjUw= X-Google-Smtp-Source: AGHT+IEpkBisnFY51DxSCQVNGVHByQM/L8pu9TXeuE9bPXGftlegROVVVLta7KVPD3RdCTgh+hFK7w== X-Received: by 2002:a17:90a:68c8:b0:299:42d1:91df with SMTP id q8-20020a17090a68c800b0029942d191dfmr7094179pjj.14.1708989428406; Mon, 26 Feb 2024 15:17:08 -0800 (PST) Received: from ghost ([50.213.54.97]) by smtp.gmail.com with ESMTPSA id qa2-20020a17090b4fc200b0029ad1df1661sm1671155pjb.52.2024.02.26.15.17.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 15:17:07 -0800 (PST) Date: Mon, 26 Feb 2024 15:17:05 -0800 From: Charlie Jenkins To: David Laight Cc: 'Russell King' , Guenter Roeck , Christophe Leroy , 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: <20240223-fix_sparse_errors_checksum_tests-v10-1-b6a45914b7d8@rivosinc.com> <7ae930a7-3b10-4470-94ee-89cb650b3349@csgroup.eu> Precedence: bulk X-Mailing-List: linux-parisc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 proven wrong if you have data to back up this statement. If the driver chooses 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 misaligned > 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' :-) > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > If somebody has a solution they deem to be better, I am happy to change this test case. Otherwise, I would appreciate a maintainer resolving this discussion and apply this fix. - Charlie 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 4BD89C5478C for ; Mon, 26 Feb 2024 23:17:28 +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=tdRl0ZVTNHzPj4MDmijVp93GZmbeRUFmvRu79R9bFL0=; b=25wTlX8iRML0AD 6zoJfBHbMJx5RiVG24u1yZ2qdimnCjw805N0wM16tfVnKOIT20kWpm0Ml+vMalE5RJp6solM8NHOT fbutfKIeWHdyi3aWmHTL7HD9njBs25eJQqBFpPNv31gpwp6RT7gNCN/z/LijucukNB47M37AztrJ1 2CNxO9OXz+xPJDbnR/PE06toQ0uh1VKLwmVfxs7jEbsMQUuPC7DAkCH9efN3ptQfrHybPzSdAA/T5 UYhE8LOWVEs5bfcXJUowHEKOClhDC+4KN+fhckw+NzUBqerAcljA5/uV42X5R7TvllZYZtQ7kvz9R NYauppCnr9PNkkJTE4rg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rekDf-00000002woW-3bBM; Mon, 26 Feb 2024 23:17:11 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rekDd-00000002wnn-2pWY for linux-arm-kernel@lists.infradead.org; Mon, 26 Feb 2024 23:17:11 +0000 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-299c11b250fso2721174a91.2 for ; Mon, 26 Feb 2024 15:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1708989428; x=1709594228; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eYuGQ7XfN8pbZjALsZ8f3cB3Gxf+yNkm9MR0bR+0+ps=; b=OBfdhXkQyMkuCNXG/6Hc5+pR6A9UCEAGIMViX7bkcsjkHFSnxpFKkUU1IJ/FZOG4gI KjSsi1CCSLCCPnUm/tN09g6Hm2CprHhqmrMek67NseBoXRum+74EjN+O0F+mPm9trtEs wEjsU0gU0yQtWnepgx5jS9t6uNvgluuU+8MLPF/JXhu3/C3obOJXLWn9XWILjZkofFup MK+U2tEp6gcS7o/avMmqQMbNEfunItjqY8tHFNUaNaZEdXuN4E5wIkdqn9R6BHh8SvOE ICgIBL59lJOmRgsnfh/VOINqjpfTcw5ZjJCnBJfDUlFxObCwAGF5UL/Iqdipb7ujCnN8 xdMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708989428; x=1709594228; h=in-reply-to: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=eYuGQ7XfN8pbZjALsZ8f3cB3Gxf+yNkm9MR0bR+0+ps=; b=sYqTMMfEWwZfjDkAQ1FqXo6GE/mGdErQRcTERQDl68r6SEuC1kRiNS9iVul2iocITQ 4ez8YwnYRprczgCv0jXzPaxOOkvWMRSFCzOodRdyXz+HkJQiWov0atmtmPWmERl+/zub W8NFLRiYUsZGInBB6sfC7BXaEGMpwpuysuWn8Wkhe3YfRFtgnqAHwgIw8dY0ieOpxjps x2aIVeb6JPW7P4kWn0lx6WtN9Gwh2DczEyYZwMitRJVY6ItxRWLjqPDP0sx5z25665Tl nkxVUngDiKVN0vJnWYeaP9iZS1hbQiXeNj4YlHi+u4Bj8Fq1hLNUfxCBsHMptyGvSF5C mwEg== X-Forwarded-Encrypted: i=1; AJvYcCW0Vso3tqy5Rt0bIy1Aqt8wKqjq3At5zSNkEokJqiVNCWRL/Pvb4j6GdOkGFVm2gea24DeVZuDdqxnu+3XCsife/CM6DCUSfozGG2/YY2WesxVdmc8= X-Gm-Message-State: AOJu0YzBDAIhhYX83ntV/aYICJsROChySMNn0WIcIKzu0yLE2HQtBKGR M+St0jBpBm+qrh/ouKDTrnZYhjfPa+Jtg2II5lhUiGP223Mv4juWB1AS6IHZwcE= X-Google-Smtp-Source: AGHT+IEpkBisnFY51DxSCQVNGVHByQM/L8pu9TXeuE9bPXGftlegROVVVLta7KVPD3RdCTgh+hFK7w== X-Received: by 2002:a17:90a:68c8:b0:299:42d1:91df with SMTP id q8-20020a17090a68c800b0029942d191dfmr7094179pjj.14.1708989428406; Mon, 26 Feb 2024 15:17:08 -0800 (PST) Received: from ghost ([50.213.54.97]) by smtp.gmail.com with ESMTPSA id qa2-20020a17090b4fc200b0029ad1df1661sm1671155pjb.52.2024.02.26.15.17.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 15:17:07 -0800 (PST) Date: Mon, 26 Feb 2024 15:17:05 -0800 From: Charlie Jenkins To: David Laight Cc: 'Russell King' , Guenter Roeck , Christophe Leroy , 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: <20240223-fix_sparse_errors_checksum_tests-v10-1-b6a45914b7d8@rivosinc.com> <7ae930a7-3b10-4470-94ee-89cb650b3349@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-20240226_151709_969884_66073F81 X-CRM114-Status: GOOD ( 24.83 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 proven wrong if you have data to back up this statement. If the driver chooses 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 misaligned > 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' :-) > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > If somebody has a solution they deem to be better, I am happy to change this test case. Otherwise, I would appreciate a maintainer resolving this discussion and apply this fix. - Charlie _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel