Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp2819083pxm; Mon, 28 Feb 2022 06:44:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJxpeHwVDRgyo0H6+cYmuQXeoJPr0QYRf4S5u0jUA9KBXbmUux1MBB8NlY2rjfbJP9vEq9d6 X-Received: by 2002:a17:906:37c3:b0:6cf:8ece:e8e7 with SMTP id o3-20020a17090637c300b006cf8ecee8e7mr15422472ejc.690.1646059444126; Mon, 28 Feb 2022 06:44:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646059444; cv=none; d=google.com; s=arc-20160816; b=sRK0JcbdLmFu1IYoPa5S3bUGZgyHIqp5RonbW5Ve5BBKcn4CEIL8T/AkZdzTTfspsJ 2QpvdzDVlKcMOKTLdWRWcWOF1NXyNN4WuNGwfFfDem0gYuChAshAnJ0qt1MZ2d2gQoe/ OkeHE5PlhHMSI0zizdgVLTTbgV1TCGclvKS1JDG9VDhtyFSX3jt8lY9/Gv85Zxkv3+kF hdO5zyD6PNEs/YMy1+GivP0YGeeBjenu34pPYaVl8feB2NUwssCJ3x+2z+q+7bK+c/I7 oBFhlr3rth4m99QRxZ9YIczcPUhtPZia6YuwKYyi4Iwox6vQ5mbVHoAdeinnpDsXIXnR HHTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=sjoNoizTM7wBWO/hSI1spi6lesysS0T46+5C0u0c52A=; b=hX+YhvtFbujpVCjJ6kyQyYBhJlVclwfSods8VhXRPleBYIcpecYE1S7XL1pYAoJepo tiSIkJ/cosVrov37HFhqRNBSfVZ6jNyx8NbV2SqXxSJYuov3ACFsqk9jBl03jw1SMW5g CoOS52fh0lcXMrnQKI5qhXTNJOXE00yhYNjkIcPVtADKvjVcGXd3+kE1dA77mWZggwo8 VQjvob4C8Muak3PGX8yZDcF9qTXZljGEYQoGw9R/2MiGuMe3YeW27VtHUWAawhgQ5TGK sXY4+oHaT2LZfLmi0fOt4KAK3U8tRvO8z/e6CFrPKhh3UWWB73duqn1Fn4pNT/O8fFZx jgAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SRUpKzRN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x24-20020a170906b09800b006d69d20e916si3434261ejy.603.2022.02.28.06.43.41; Mon, 28 Feb 2022 06:44:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SRUpKzRN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236028AbiB1Lwx (ORCPT + 99 others); Mon, 28 Feb 2022 06:52:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235066AbiB1Lwp (ORCPT ); Mon, 28 Feb 2022 06:52:45 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B0C0723FA; Mon, 28 Feb 2022 03:52:05 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6FA84610A5; Mon, 28 Feb 2022 11:52:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D047DC340F4; Mon, 28 Feb 2022 11:52:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646049124; bh=12lEy+rZsxAbLHQ5lt0XyIX0neTrZHPLb7NInfEDMcc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SRUpKzRNM4/KvOrKZXX7WF2i3gFVTE8eW4pQGcpOQY9lp11YUOi3PxFsqPQvayCcd RRo+6AjFr6sHDBYCIzu8qorItwxwkpV7cFz/6ed3WeK85FWLoO8LE0n9BtEWjwLeO7 yd+DcrFdwcNtDn6FwQVrJ7BaW3zCEq92ftdj5pmrtHJ813v/tA01YhvNqsz2dEniAl PH5k3aV7bSLqvavFPxscXymknzz0TGMzguJvKQDvpHWq+ZACEGv7AuOLT0qp0VrJEy 9TBxwBhu4oGQTJJvVShyBZtx59FEQhySIYwjZqDbIgoeORdOgeWKvtRlJ0da7lM122 gBTYswmMcsFBw== Received: by mail-vs1-f43.google.com with SMTP id t22so12649269vsa.4; Mon, 28 Feb 2022 03:52:04 -0800 (PST) X-Gm-Message-State: AOAM530VDjlDabPibvx6yfj4ZQBcUp3L2Qv3P3oKV8IqN9Efk8Vf3AEK SM9bh9TFh1of601oH8oygNHEdOC6AmkcWGxfycM= X-Received: by 2002:a05:6102:c4a:b0:31a:54e6:edb1 with SMTP id y10-20020a0561020c4a00b0031a54e6edb1mr6626535vss.51.1646049123736; Mon, 28 Feb 2022 03:52:03 -0800 (PST) MIME-Version: 1.0 References: <20220227162831.674483-1-guoren@kernel.org> <20220227162831.674483-4-guoren@kernel.org> In-Reply-To: From: Guo Ren Date: Mon, 28 Feb 2022 19:51:52 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V7 03/20] compat: consolidate the compat_flock{,64} definition To: David Laight Cc: "palmer@dabbelt.com" , "arnd@arndb.de" , "anup@brainfault.org" , "gregkh@linuxfoundation.org" , "liush@allwinnertech.com" , "wefu@redhat.com" , "drew@beagleboard.org" , "wangjunqiang@iscas.ac.cn" , "hch@lst.de" , "linux-arch@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-csky@vger.kernel.org" , "linux-s390@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-parisc@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "x86@kernel.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 28, 2022 at 2:40 PM David Laight wrote: > > From: guoren@kernel.org > > Sent: 27 February 2022 16:28 > > > > From: Christoph Hellwig > > > > Provide a single common definition for the compat_flock and > > compat_flock64 structures using the same tricks as for the native > > variants. Another extra define is added for the packing required on > > x86. > ... > > diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h > ... > > /* > > - * IA32 uses 4 byte alignment for 64 bit quantities, > > - * so we need to pack this structure. > > + * IA32 uses 4 byte alignment for 64 bit quantities, so we need to pack the > > + * compat flock64 structure. > > */ > ... > > +#define __ARCH_NEED_COMPAT_FLOCK64_PACKED > > > > struct compat_statfs { > > int f_type; > > diff --git a/include/linux/compat.h b/include/linux/compat.h > > index 1c758b0e0359..a0481fe6c5d5 100644 > > --- a/include/linux/compat.h > > +++ b/include/linux/compat.h > > @@ -258,6 +258,37 @@ struct compat_rlimit { > > compat_ulong_t rlim_max; > > }; > > > > +#ifdef __ARCH_NEED_COMPAT_FLOCK64_PACKED > > +#define __ARCH_COMPAT_FLOCK64_PACK __attribute__((packed)) > > +#else > > +#define __ARCH_COMPAT_FLOCK64_PACK > > +#endif > ... > > +struct compat_flock64 { > > + short l_type; > > + short l_whence; > > + compat_loff_t l_start; > > + compat_loff_t l_len; > > + compat_pid_t l_pid; > > +#ifdef __ARCH_COMPAT_FLOCK64_PAD > > + __ARCH_COMPAT_FLOCK64_PAD > > +#endif > > +} __ARCH_COMPAT_FLOCK64_PACK; > > + > > Provided compat_loff_t are correctly defined with __aligned__(4) See include/asm-generic/compat.h typedef s64 compat_loff_t; Only: #ifdef CONFIG_COMPAT_FOR_U64_ALIGNMENT typedef s64 __attribute__((aligned(4))) compat_s64; So how do you think compat_loff_t could be defined with __aligned__(4)? > marking the structure packed isn't needed. > I believe compat_u64 and compat_s64 both have aligned(4). > It is also wrong, consider: > > struct foo { > char x; > struct compat_flock64 fl64; > }; > > There should be 3 bytes of padding after 'x'. > But you've removed it. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/