Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp146018pxy; Tue, 20 Apr 2021 22:52:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIRBzONFK+OaWoRGe7zoZzuduz9fxBv3PKqeQYaDpmyBZ/fybGu3p1/nKNiHAp2SmsSpXd X-Received: by 2002:a17:90a:dc07:: with SMTP id i7mr9095367pjv.16.1618984343652; Tue, 20 Apr 2021 22:52:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618984343; cv=none; d=google.com; s=arc-20160816; b=iBoOIrU886DaR71+A1x2oXAoSchq7eboLHnnlNA1ZJmjumoq0bhA8DJMYRnSBaTLnd faOkEHDswlDNcZT9ZaBdO9vp5sZhi4sUbeiwZnsz/+WYi7u1TJsnM0Wrt3e4SKrPCDln KNORqD39LwIs3E/EU9fznNecZrcx+hglEJt7rlccnYQLc/IlDiXQlb9Szh+0WOLTcw1C x/V+8WjbxkH5IGVLmTNA9O8rkzuyaphUHv6Czhim7wWvLVVMh3JeMakQQagvirNiEnnF xZcP6Xj1NLL0+iP4GTOak1irR2Vg4C2AT96cgYFfmo8T8cQKysHP6qLzYkgmS2V+nRkG YLaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=0o20uUyQbXpIdOmISRlMctevF68FLP2jvzldjMJ+Deo=; b=B3mn1ahmfpxvGUgPk7iWcs0zfzhK4gTscFrp71KASGIetSSx+q/1cQ9beRjEKeKOIx 6bQx/8GeSh633d6w+j1/Y1M363arSSbb5ToXJK4mrUnVmzsh5hAfhDCpNs5RRK8ZoWVY EOs8IK8fCcnEmdIEOx0syzQqCuK1RcbWUSilbgz3NR/Y9xu8I8MaBqphExIpmwLy6LjQ /3R3eI5XOC0v69NP6wqz/Unb7ZEEXXK2lVgd8wkmgaB+YIXGB/aEE/6Rl3JQeuITXSHw QoxxoNlKOLRLwHM+WNrZg5h4VWvXT3vCbZrItewYvyksDvHNIOvJD5IPCxYUBjBToLrl YDkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 h16si1394442pgg.516.2021.04.20.22.52.08; Tue, 20 Apr 2021 22:52:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235288AbhDUFvJ (ORCPT + 99 others); Wed, 21 Apr 2021 01:51:09 -0400 Received: from verein.lst.de ([213.95.11.211]:52980 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230390AbhDUFvF (ORCPT ); Wed, 21 Apr 2021 01:51:05 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 7324868BFE; Wed, 21 Apr 2021 07:50:28 +0200 (CEST) Date: Wed, 21 Apr 2021 07:50:28 +0200 From: "hch@lst.de" To: Arnd Bergmann Cc: Vineet Gupta , Matthew Wilcox , "grygorii.strashko@ti.com" , "netdev@vger.kernel.org" , "ilias.apalodimas@linaro.org" , "linux-kernel@vger.kernel.org" , "linux-mips@vger.kernel.org" , "mhocko@kernel.org" , "linux-mm@kvack.org" , "mgorman@suse.de" , "brouer@redhat.com" , "mcroce@linux.microsoft.com" , "linux-snps-arc@lists.infradead.org" , "linuxppc-dev@lists.ozlabs.org" , "hch@lst.de" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems Message-ID: <20210421055028.GA28910@lst.de> References: <20210416230724.2519198-1-willy@infradead.org> <20210416230724.2519198-2-willy@infradead.org> <20210417024522.GP2531743@casper.infradead.org> <9f99b0a0-f1c1-f3b0-5f84-3a4bfc711725@synopsys.com> <20210420031029.GI2531743@casper.infradead.org> <8d0fce1c-be7c-1c9b-bf5c-0c531db496ac@synopsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 20, 2021 at 11:20:19PM +0200, Arnd Bergmann wrote: > In that case, there should be no problem for you. > > The main issue is with system calls and ioctls that contain a misaligned > struct member like > > struct s { > u32 a; > u64 b; > }; > > Passing this structure by reference from a 32-bit user space application > to a 64-bit kernel with different alignment constraints means that the > kernel has to convert the structure layout. See > compat_ioctl_preallocate() in fs/ioctl.c for one such example. We've also had this problem with some on-disk structures in the past, but hopefully people desining those have learnt the lesson by now.