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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85B8DE7717F for ; Fri, 13 Dec 2024 21:53:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 17B806B00A1; Fri, 13 Dec 2024 16:53:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 105BF6B00A2; Fri, 13 Dec 2024 16:53:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC15B6B00A3; Fri, 13 Dec 2024 16:53:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CA0C26B00A1 for ; Fri, 13 Dec 2024 16:53:57 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 87C7F1C8225 for ; Fri, 13 Dec 2024 21:53:57 +0000 (UTC) X-FDA: 82891288620.28.93FAE3A Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by imf29.hostedemail.com (Postfix) with ESMTP id B1D47120013 for ; Fri, 13 Dec 2024 21:53:18 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734126823; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p3XO30CvJa2rLmnkvFL2XnDeax061g/QdjIwndsFiKE=; b=hfDXwf0Tb0xoDzpxJjHRrPtxva7MYmnx2NQ6KENVzeGv8JdZdAyBVXaEusvrQUQQ5U1Mtd hcCP/bPy+eKN9a5g6C2SauQtqAAabnKoxW8KIA123cQ8Bupakg28SrLJAkOcGdoJ02Lkzk qAiN5TNLNA9LP8/q2+yY/h7mYXiUiOY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734126823; a=rsa-sha256; cv=none; b=5YVInvf/seQkEbZxOYv9p0ql6Ns7y6nhmo7Gh8OL+dlm12f9O4pQb6Et9YlPTeHf8m5xnR 3/jjf+fgIc8DB6Co53ag9D7QjQtCb5vFOSZEbD+3Hk0X5wbw15nRS9DXNhxXIWLG3ipRWC RQTZhZoQDDUNacp4bJZiTQ4+NwcbaAs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com Received: from in01.mta.xmission.com ([166.70.13.51]:56506) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1tMDbc-009pZC-L3; Fri, 13 Dec 2024 14:53:52 -0700 Received: from ip72-198-198-28.om.om.cox.net ([72.198.198.28]:40456 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1tMDbb-00AZd8-G0; Fri, 13 Dec 2024 14:53:52 -0700 From: "Eric W. Biederman" To: Hajime Tazaki Cc: linux-um@lists.infradead.org, ricarkol@google.com, Liam.Howlett@oracle.com, kees@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org References: <87r06d0ymg.fsf@email.froward.int.ebiederm.org> <87bjxf1he1.fsf@email.froward.int.ebiederm.org> Date: Fri, 13 Dec 2024 15:53:44 -0600 In-Reply-To: (Hajime Tazaki's message of "Sat, 14 Dec 2024 06:23:44 +0900") Message-ID: <87r06bz1uf.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1tMDbb-00AZd8-G0;;;mid=<87r06bz1uf.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=72.198.198.28;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX19KAHdFFUi5cVQHGBC8QctGuBcxACTIOzs= Subject: Re: [PATCH v5 02/13] x86/um: nommu: elf loader for fdpic X-SA-Exim-Connect-IP: 166.70.13.51 X-SA-Exim-Rcpt-To: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, jack@suse.cz, brauner@kernel.org, viro@zeniv.linux.org.uk, kees@kernel.org, Liam.Howlett@oracle.com, ricarkol@google.com, linux-um@lists.infradead.org, thehajime@gmail.com X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Scanned: No (on out03.mta.xmission.com); SAEximRunCond expanded to false X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B1D47120013 X-Stat-Signature: 3w9yuim5ku6x3n91d18qyycoypt6poqj X-Rspam-User: X-HE-Tag: 1734126798-692253 X-HE-Meta: U2FsdGVkX19QJU4ORWV/kJkq+nTyAb7pnJjUHV6mEIE0W3ClzgmHG/UMGVpdEAL9+mUaDgDNKjmloZMvICbZKv/6cQ4KSkICW9dqeRv9crPGlgGwMPeSi1m1/kPlVbvc8rZHNYiVmNkEG3A8a0p/2I664t+a5rGBsqblR8jXHgZxCxJMGCJqcEShIDuDAHJQtJXuH3dmgKSi+cXj9rnZCV9oi4Jny8otlRYFlXtcWFggMFd3dZ99n8PgkComvI9rOU/TWVTTBmB3dNHst4fud8/Ew9SlnwUZc50Dw4g5EI1+a1nMy60nTUflqL9ENIBRz7/MBMb86jDtlWRKr5m91u/Ug8a10hSTeax6FSr+8ZZCKISvB04g/z0C20LSrtSKAnwJkTuO5nXriDMa3gv/rUj6JVet/t0e39uSTTlUigyxJRJujBkQoo1RVsq9eCKbUPaCfIxG5/bcA3sTJkYlEGA+9CH3jvDwW0h19xd6F/UsTjGHRrAlkY/l429euXghxni1Qw/CmMf+cHTjPG+Rk8sSo+qDTQt9FaJpzf6lwd5QVBXBYTOODffbv7qDp9pTuARJNRfKmfvRrxL+qyHoJkAX5NK5YyWNwcoxsnnzSjMGaC7KpAlwGkibmPOFVpQTRUOcBCNlWn7Hs5o0KBy+AZ8VT1ZMGLqF73+dCBcHxzpKRJk3G43oZhMbAh/j8RIs6UayBS6vZG/g2ae15hyFV0ASXJ9X3bJ7V0B/CYTuxxeBqwxAoiLjSycraIwccxsjHrJlf74W5rSMFTeOE3t7qQl+dLpLWJJMglOuATpClDbDseuV/3Bzm7yK1CnGzEEkJtlXYGv8VAqdyfcR7jhpPbcbB7TDpRMbUe7F36jzuUPepsvoOpgrdhISIOSwbztC8fWTjQdDwan5+8JrB+hmnYxmTkY8AGV9W99nua9u8jgsMAiWv64M1MnHZykNkM04kvxo5iu681Pjf1BFFP0 vwBXz7kg rlaCNXtE40jlp0u03RHr1k1tahPvcSc6MF1/7kortECqBKiIHQ7bD1dbYbvWGAcFi00sErV9kdXD9iA0Ud9tsQiJL2aLYFAnj9teM X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hajime Tazaki writes: > On Sat, 14 Dec 2024 05:01:58 +0900, > Eric W. Biederman wrote: > >> >> Last time I looked the regular binfmt_elf works just fine >> >> without an mmu. I looked again and at a quick skim the >> >> regular elf loader still looks like it will work without >> >> an MMU. >> > >> > I'm wondering how you looked at it and how you see that it works >> > without MMU. >>=20 >> I got as far as seeing that vm_mmap should work. As all of the >> bits for mmap to work, are present in both mmu and nommu. > > hmm, at least MAP_FIXED doesn't work in current mm/nommu.c. > # also documented at Documentation/admin-guide/mm/nommu-mmap.rst. Yes, and that fundamentally makes sense. >> > I also wish to use the regular binfmt_elf, but it doesn't allow me to >> > compile with !CONFIG_MMU right now. >>=20 >> Then I may simply be confused. Where does the compile fail? >> Is it somewhere in Kconfig? >>=20 >> I could be completely confused. It has happened before. > > If I applied to below in addition to my whole patchset, > > diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt > index 419ba0282806..b34d0578a22f 100644 > --- a/fs/Kconfig.binfmt > +++ b/fs/Kconfig.binfmt > @@ -4,7 +4,6 @@ menu "Executable file formats" >=20=20 > config BINFMT_ELF > bool "Kernel support for ELF binaries" > - depends on MMU > select ELFCORE > default y > help > @@ -58,7 +57,7 @@ config ARCH_USE_GNU_PROPERTY > config BINFMT_ELF_FDPIC > bool "Kernel support for FDPIC ELF binaries" > default y if !BINFMT_ELF > - depends on ARM || ((M68K || RISCV || SUPERH || UML || XTENSA) && = !MMU) > + depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) > select ELFCORE > help > ELF FDPIC binaries are based on ELF, but allow the individual l= oad You have my apologies I was most definitely confused. BINFMT_ELF currently does not work without an MMU. > this is the output from `make ARCH=3Dum`. > > GEN Makefile > CALL ../scripts/checksyscalls.sh > CC fs/binfmt_elf.o > In file included from ./arch/x86/include/generated/asm/rwonce.h:1, > from ../include/linux/compiler.h:317, > from ../include/linux/build_bug.h:5, > from ../include/linux/container_of.h:5, > from ../include/linux/list.h:5, > from ../include/linux/module.h:12, > from ../fs/binfmt_elf.c:13: > ../fs/binfmt_elf.c: In function =E2=80=98load_elf_binary=E2=80=99: > ../include/asm-generic/rwonce.h:44:71: error: lvalue required as unary = =E2=80=98&=E2=80=99 operand > 44 | #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(= x) *)&(x)) > | = ^ > ../include/asm-generic/rwonce.h:50:9: note: in expansion of macro =E2=80= =98__READ_ONCE=E2=80=99 > 50 | __READ_ONCE(x); = \ > | ^~~~~~~~~~~ > ../fs/binfmt_elf.c:1006:49: note: in expansion of macro =E2=80=98READ_ONC= E=E2=80=99 > 1006 | const int snapshot_randomize_va_space =3D READ_ONCE(rando= mize_va_space); > |=20=20=20 > > I avoided this issue (with nasty MAP_FIXED workaround) but there seems > to be still a lot of things that I need to fix to work with nommu. Yes, at a minimum all of the MAP_FIXED code would need to be conditionalized on having an MMU. > >> I just react a little strongly to the assertion that elf_fdpic is >> the only path when I don't see why that should be. >>=20 >> Especially for an architecture like user-mode-linux where I would expect >> it to run the existing binaries for a port. > > I understand your concern, and will try to work on improving this > situation a bit. > > Another naive question: are there any past attempts to do the similar > thing (binfmt_elf without MMU) ? At this point what I would recommend is: Merge your original patch. Get nommu UML working with binfmt_elf_fdpic.c. I think it is a proper superset of ELF functionality. Then I would make it a long term goal to see about removing redundancy between binfmt_elf.c and binfmt_elf_fdpic.c with a view to merging them in the long term. There is a lot of mostly duplicate code between the two and binfmt_elf_fdpic.c does not get half the attention and use binfmt_elf.c gets. Eric