From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756299AbdJPUDV (ORCPT ); Mon, 16 Oct 2017 16:03:21 -0400 Received: from 20pmail.ess.barracuda.com ([64.235.150.247]:45790 "EHLO 20pmail.ess.barracuda.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754332AbdJPUDU (ORCPT ); Mon, 16 Oct 2017 16:03:20 -0400 Date: Mon, 16 Oct 2017 21:02:09 +0100 From: James Hogan To: Michal Hocko CC: Kees Cook , LKML , Linus Torvalds , Jiri Kosina , Al Viro , Oleg Nesterov , Ingo Molnar , Baoquan He , Subject: Re: [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map Message-ID: <20171016200208.GL15235@jhogan-linux> References: <20171004075059.bbx7madwgwflb7ky@dhcp22.suse.cz> <20171016134446.19910-1-mhocko@kernel.org> <20171016134446.19910-2-mhocko@kernel.org> <20171016190047.76ry2inllsacd3pv@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lYetfuAxy9ic4HK3" Content-Disposition: inline In-Reply-To: <20171016190047.76ry2inllsacd3pv@dhcp22.suse.cz> User-Agent: Mutt/1.7.2 (2016-11-26) X-Originating-IP: [192.168.154.110] X-BESS-ID: 1508184116-298552-5255-138702-3 X-BESS-VER: 2017.12-r1710102214 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.186034 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --lYetfuAxy9ic4HK3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 16, 2017 at 09:00:47PM +0200, Michal Hocko wrote: > [CCing metag people for the metag elf_map implementation specific. The th= read > starts here http://lkml.kernel.org/r/20171016134446.19910-1-mhocko@kernel= =2Eorg] >=20 > On Mon 16-10-17 09:39:14, Kees Cook wrote: > > On Mon, Oct 16, 2017 at 6:44 AM, Michal Hocko wrote: > > > + return -EAGAIN; > > > + } > > > + > > > + return map_addr; > > > +} > > > + > > > static unsigned long elf_map(struct file *filep, unsigned long addr, > > > struct elf_phdr *eppnt, int prot, int type, > > > unsigned long total_size) > > > @@ -366,11 +389,11 @@ static unsigned long elf_map(struct file *filep= , unsigned long addr, > >=20 > > elf_map is redirected on metag -- it should probably have its vm_mmap > > calls adjust too. >=20 > Thanks for spotting this. I am not really familiar with metag. It seems > to clear MAP_FIXED already > tcm_tag =3D tcm_lookup_tag(addr); >=20 > if (tcm_tag !=3D TCM_INVALID_TAG) > type &=3D ~MAP_FIXED; >=20 > So if there is a tag the flag is cleared. I do not understand this code > (and git log doesn't help) but why is this MAP_FIXED code really needed? This function was added to the metag port in mid-2010 to support ELFs with tightly coupled memory (TCM) segments, for example metag "core" memories are at fixed virtual addresses and aren't MMU mappable (i.e. globally accessible), and are outside of the usual userland address range, but are as fast as cache. The commit message says this: > Override the definition of the elf_map() function to special case > sections that are loaded at the address of the internal memories. > If we have such a section, map it at a different address and copy > the contents of the section into the appropriate memory. So yeh, it looks like if the section is meant to use TCM based on the virtual address, it drops MAP_FIXED so that the vm_mmap can succeed (because its outside the normally valid range), and then copies it directly to the desired TCM so the program can use it. Hope that helps add some context to understand whats needed. There was some description of this in an ELCE-2010 talk by the original author Will Newton that may also be of interest [1]. Cheers James [1] http://free-electrons.com/blog/elce-2010-videos/ "Exploiting On-chip Memories in Embedded Linux Applications" See slides about "core memories". --lYetfuAxy9ic4HK3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEd80NauSabkiESfLYbAtpk944dnoFAlnlEDgACgkQbAtpk944 dnptDQ//TGLJYFTBPdhvfV6RG0Osxz9n8NGhuTVsM21ccrXGnb/e2JGrikjXxanV XCornW47iPsBnelDOcRwJuoBAT/wy0xalvuhfH6xJ3aVYFc7yvU44iM24IPj0UCK 9MD//r92fxoxslaPzG1tyv9kiHP8WmiBx+6983fHRHKmsX9Jo5xJayWHp5IiF0oW fDHnx2okE7WCZrlNXdRdkqeNtzi7huCv8j6K7d5HVXc5m+3ztZx67j6d1J39riWo ahGNLmH4zI/vpN2O4NiHX0FF4zsQGXop/dep2HAJ/5Qjmp8GHSmA75OQRs0LkZ9h ConSVpK6pX99EtP76sGTeVkoYJfh7j+5yVSPVRU+h1EiTSFGZd7gsxP3FJG4zgRA hAsojo2Z4fduvX+7X7yF5lU4xyRn78vANtzsKWzC5SUOROSlMqHZ3VQzh59aAvbZ SUPVMpsuXfukB574R4jDuKHqW7f3C5tf8v8anEOCPVH70KKHP6j177dqTz5kM2Rb MG7wuokc1+nHp4hLzAm1cyT8Mg3OOUawg9xJW+AH6V0mCkj5doAVGhedE/GlEfwQ 9si51SJ5bjlXR8vjtCuNBXgp0yxMsV4xqgWIGQ/3MeFYpb2bSlicmo5vMofbU0nO dtvN5BvDhVlgQrskjspZsMIefkeqjfA+7HLRsxnKk/vhRy2o68M= =gRZE -----END PGP SIGNATURE----- --lYetfuAxy9ic4HK3--