Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp3962279pxy; Tue, 4 May 2021 14:11:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwv1mMYDMb6sn6hBFsDEd0F9LMhrqkuy6OuuhJAHnI3RLVUmwo36fwmRC9gx8QAgqZG2yzg X-Received: by 2002:aa7:8389:0:b029:209:da1c:17b5 with SMTP id u9-20020aa783890000b0290209da1c17b5mr25765732pfm.29.1620162679322; Tue, 04 May 2021 14:11:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620162679; cv=none; d=google.com; s=arc-20160816; b=WPwwGzJd/8qP4n2nTy37hlRzJGPMbR/laow9riLULzKCxUry1DqP6ZDVAtOyGb6Hj0 hRop0drvdasEudIjj1f9FLUX03By/IKWpvM47LeY/FywUU45vQp6qCiDLO/da6/rZCq3 zMBipnTJpxmpm6WS7bnt6tet/Pg1vsoGspwzAkXYhui2Eto2fGPgeR85vOZG0Z30KBjg rdYxH25icGAgH3Qu0bvXjuJ2itJ5ydLPydnNCrscMk5j6nP6Y4r60IBbYmAX37x+risi c1m02ScKTGGRcEY8tUcS04bSWaKnlUfbbLzAmaIw5GZZmXTbmOKwiDMxfMqEHX+YDz1l 2DLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=UqZONYzS5VNSHeaL+8CpeCbBO/qIgrdfB71oK7wEl/c=; b=ebPa1UhLl1WVbzoYthoWtjg3otemtk92845+JK17estNVUw87Ee59BTIBV+8mm30RG utHsFyyX5VXeva0/muCXrzc+CNXWzwR7jwbXZkzTmttplE94E7weRb6Q9ensv3Ucx7Bm ICwkb63l3bWrtQFSj8Xe4401FHUYvEwerLul5ZOaK8qIqNVkc7qKtQgZRAe56cWqGlkg s8vUwJlktTBrMDnSKzc+e87UK05pl82pL9yp0rspGYo/2WakVoMZI2emmFfE3WX0c2DO j15cW3/6UuS6u2RgJfLalVBr+cJKG0yhDdr7bgUtT++7oklJPZ0cMn3IFZ6omgkh+W9k JSkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g16si4938606plo.320.2021.05.04.14.11.00; Tue, 04 May 2021 14:11:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232493AbhEDVLi (ORCPT + 99 others); Tue, 4 May 2021 17:11:38 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:56283 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S232169AbhEDVLh (ORCPT ); Tue, 4 May 2021 17:11:37 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 144LAY74001543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 4 May 2021 17:10:35 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id B5BD315C3C43; Tue, 4 May 2021 17:10:34 -0400 (EDT) Date: Tue, 4 May 2021 17:10:34 -0400 From: "Theodore Ts'o" To: Eric Biggers Cc: harshad shirwadkar , Andreas Dilger , Ext4 Developers List , Harshad Shirwadkar Subject: Re: [PATCH] e2fsck: fix portability problems caused by unaligned accesses Message-ID: References: <20210504031024.3888676-1-tytso@mit.edu> <8E9C71E8-FE5F-4CB8-BA62-8D8895DCA92A@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, May 04, 2021 at 01:45:02PM -0700, Eric Biggers wrote: > > No, 'flags = unaligned_ptr->t_flags' is fine, provided that unaligned_ptr is a > pointer to a struct with the packed attribute. What -Waddress-of-packed-member > will warn about is if you do something like &unaligned_ptr->t_flags to get a > pointer directly to the t_flags field, as such pointers can then be incorrectly > used for misaligned accesses. Yeah, the warnings appear if you apply my patch, and then *also* add the __attribute__((__packed__)) annotation. If you revert my patch, and then only add the __packed__ annotation, there are no warnings, because we're no longer taking the address of the field with a packed attribute. Basically, what gcc (and presumably clang) is doing is it is special casing packed_ptr->field so that the compiled code will work regardless of the alignment of packed_ptr. This isn't documented anywhere, but it apparently is the case. (I had assumed that it would only generate unaligned access for those fields that are not aligned if the structure started on an aligned boundary.) However, if you take an address of a packed memory, short *p = &packed_ptr->field; .. and then later derference that pointer, the C compiler can't know that it needs to generate the magic unaligned derferencing code when it dereferences that pointer. So that's why that warning is there. But if you just add __packed__ attribute, without my proposed patch, we aren't taking the &packed_ptr->field anywhere in e2fsprogs, so we're fine. > If we really don't want to use __attribute__((packed)) that is fine, but then > we'll need to remember to use an unaligned accessor *every* field access (except > for bytes), which seems harder to me -- and the compiler won't warn when one of > these is missing. (They can only be detected at runtime using UBSAN.) One reason not to use the __packed__ attribute is that there are cases where people attempt to build e2fsprogs on non-gcc/non-clang binaries. At one point FreeBSD was trying to use pcc to build e2fsprogs IIRC. And certainly there are people who try to build e2fsprogs on MSVC on Windows. So maybe the memcpy to a local copy is the better way to go, and hopefully the C compiler will optimize away the local copy on architectures where it is safe to do so. And in the unlikely case that it is a performance bottleneck, we could add a -DUBSAN when configure --enable-ubsan is in force, which switches in the memcpy when only when ubsan is enabled. - Ted