From cosmos@astonlinux.com Wed May 2 14:05:21 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA19984; Wed, 2 May 2001 14:05:21 +0200 (MET DST) Received-Date: Wed, 2 May 2001 14:05:21 +0200 (MET DST) Received: from UNKNOWN(210.221.126.1), claiming to be "dsic.co.kr" via SMTP by guadalquivir.fnet.fr, id smtpd019982; Wed May 2 14:05:19 2001 Received: from cosmos [192.168.2.154] by dsic.co.kr [210.221.126.1] with SMTP (MDaemon.v3.5.6.R) for ; Wed, 02 May 2001 21:04:05 +0900 Message-ID: <000e01c0d300$58674ec0$9a02a8c0@cosmos> From: =?ks_c_5601-1987?B?sK29xbHU?= To: Subject: Suggestion related to no MMU. Date: Wed, 2 May 2001 21:06:40 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C0D34B.C82BB750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MDRemoteIP: 192.168.2.154 X-Return-Path: cosmos@astonlinux.com X-MDaemon-Deliver-To: linux-mips@fnet.fr Content-Length: 2201 Lines: 41 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C0D34B.C82BB750 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgZXZlcnkgYm9keS4uDQoNCk15IG5hbWUgaXMgU2hpbmt5dSBLYW5nLg0KDQpJJ2QgbGlrZSB0 byBwb3J0IGEgbW11LWxlc3MgbGludXggdG8gTUlQUyBiYXNlZCBkZXZpY2UuDQoNCklmIGFueWJv ZHkgd2hvIGludGVyZXN0cyBpbiBtbXUtbGVzcyBsaW51eCBhcmUgZXhpc3QsIGhvdyBhYm91dCB3 b3JrIHRvZ2V0aGVyIG9yIHN0YXJ0IG9wZW4gcHJvamVjdD8NCg0KTXkgZS1tYWlsIGFkZHJlc3Mg aXMgY29zbW9zQGFzdG9ubGludXguY29tIC4NCg0KdGhhbmsgeW91IGZvciByZWFkaW5nLg0KDQpy ZWdhcmRzLg0KDQpTaGlua3l1Li4NCg0KDQoNCg== ------=_NextPart_000_000B_01C0D34B.C82BB750 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2M4ZTBkOD4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGV2ZXJ5IGJv ZHkuLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5N eSBuYW1lIGlzIFNoaW5reXUgS2FuZy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+SSdkIGxpa2UgdG8gcG9ydCBhIG1tdS1sZXNzIGxpbnV4IHRvIE1J UFMgYmFzZWQgDQpkZXZpY2UuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPklmIGFueWJvZHkgd2hvIGludGVyZXN0cyBpbiBtbXUtbGVzcyBsaW51eCBh cmUgZXhpc3QsIGhvdyANCmFib3V0IHdvcmsgdG9nZXRoZXIgb3Igc3RhcnQgb3BlbiBwcm9qZWN0 PzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5NeSBl LW1haWwgYWRkcmVzcyBpcyA8QSANCmhyZWY9Im1haWx0bzpjb3Ntb3NAYXN0b25saW51eC5jb20i PmNvc21vc0Bhc3RvbmxpbnV4LmNvbTwvQT4gLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj50aGFuayB5b3UgZm9yIHJlYWRpbmcuPC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnJlZ2FyZHMuPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNoaW5reXUuLjwvRk9O VD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_000B_01C0D34B.C82BB750-- From anthony.wei@philips.com Thu May 3 19:16:51 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA02335; Thu, 3 May 2001 19:16:51 +0200 (MET DST) Received-Date: Thu, 3 May 2001 19:16:51 +0200 (MET DST) From: anthony.wei@philips.com Received: from gw-us4.philips.com(63.114.235.90) via SMTP by guadalquivir.fnet.fr, id smtpd002333; Thu May 3 19:16:40 2001 Received: from smtprelay-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id MAA29243; Thu, 3 May 2001 12:16:30 -0500 (CDT) (envelope-from anthony.wei@philips.com) Received: from smtprelay-nam2.philips.com(167.81.233.16) by gw-us4.philips.com via mwrap (4.0a) id xma029234; Thu, 3 May 01 12:16:30 -0500 Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com [161.88.79.213]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA00538; Thu, 3 May 2001 12:16:29 -0500 (CDT) Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via AMEC id 0056910011804600; Thu, 3 May 2001 12:19:21 -0500 To: , Cc: Subject: Has anyone successfully reduced the size of libc.so? Message-ID: <0056910011804600000002L102*@MHS> Date: Thu, 3 May 2001 12:19:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 05/03/01 12:16:08" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Length: 1271 Lines: 40 Hi, I am trying to create a stripped version of libc.so from glibc.2.1.95= src, by including only minimal symbols. original full size libc.so: 7.9 Meg original libc.so but symbols stripped 1.7 Meg (running mipsel-linux-strip libc.so) Has anyone successfully reduced the size of the libc.so? Here is what I did. I started with glibc 2.1.95 and cross compiled for= MIPS. A. Using Bradley D. LaRonde's ramdisk as a model B. Ran strings on /lib/libc-2.0.7.so and /lib/ld-2.0.7.so on LaRonde'= s ramdisk Removed all the messages, leaving mostly symbols. C. Ran a script, that took the symbols and found the corresponding *.os file. And resolved rescursively all undefined symbols. D. Extracted the commands used to create libc.so & ld.so, from the log while cross compiling glibc. Theses included: dl-allobjs.os libc_pic.a librtld.os ld.so libc_pic.os libc.so E. Replaced */stamp.os with the files found from step C. F. Extracted the symbols required for the ls command., and added to t= he *.os list. =20 This brought the size of the libc.so back to the original size 1.7Meg= (stripped)). =09 Thanks. Anthony Wei Philips Digital Network 1000 West Maude Avenue W3-948 Sunnyvale, CA 94085-2810 +1-408-617-1673 = From alan@lxorguk.ukuu.org.uk Thu May 3 19:48:41 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id TAA02971; Thu, 3 May 2001 19:48:41 +0200 (MET DST) Received-Date: Thu, 3 May 2001 19:48:41 +0200 (MET DST) Received: from router-100M.swansea.linux.org.uk(194.168.151.17), claiming to be "the-village.bc.nu" via SMTP by guadalquivir.fnet.fr, id smtpd002968; Thu May 3 19:48:32 2001 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14vNGm-0005uW-00; Thu, 3 May 2001 18:52:04 +0100 Subject: Re: Has anyone successfully reduced the size of libc.so? To: anthony.wei@philips.com Date: Thu, 3 May 2001 18:52:01 +0100 (BST) Cc: linux-mips@oss.sgi.com, linux-mips@fnet.fr, brad@ltc.com In-Reply-To: <0056910011804600000002L102*@MHS> from "anthony.wei@philips.com" at May 03, 2001 12:19:21 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Content-Length: 208 Lines: 4 > Has anyone successfully reduced the size of the libc.so? Not much. And Ulrich made very valid points about why this would fail. Someone should probably port newlib over as that is designed to be modular. From macro@ds2.pg.gda.pl Tue May 8 22:43:19 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id WAA16560; Tue, 8 May 2001 22:43:19 +0200 (MET DST) Received-Date: Tue, 8 May 2001 22:43:19 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd016528; Tue May 8 22:40:54 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA08120; Tue, 8 May 2001 22:21:56 +0200 (MET DST) Date: Tue, 8 May 2001 22:21:55 +0200 (MET DST) From: "Maciej W. Rozycki" To: linux-kernel@vger.kernel.org cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: [patch] 2.4.4: mmap() fails for certain legal requests Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2453 Lines: 71 Hi, The mmap() call fails when addr is specified, MAP_FIXED is cleared in flags and no address space can be allocated either at addr or above it. This is a legal request and it should not fail as long as there is space available below addr. Following is a patch that fixes the problem. This is nothing new -- I already submitted a similar patch against 2.4.0-test4 once upon a time. This patch is clean(er), though, and I believe it can be safely applied to the upcoming 2.4.5 release. A simple test case to trigger the current mmap() bad behaviour for 32-bit CPUs is something like: fd = open("/dev/zero", O_RDONLY); p = mmap((void *)0xfffff000, 4096, PROT_READ, MAP_SHARED, fd, 0); With my patch the code does not fail anymore -- p is set to an available address lower than 0xfffff000. The bug was discovered when tracking down the reason of dlopen() failures when called from statically linked binaries on MIPS/Linux. The patch fixes them. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -up --recursive --new-file linux-2.4.4.macro/mm/mmap.c linux-2.4.4/mm/mmap.c --- linux-2.4.4.macro/mm/mmap.c Tue May 1 17:24:25 2001 +++ linux-2.4.4/mm/mmap.c Tue May 1 18:23:25 2001 @@ -219,7 +219,7 @@ unsigned long do_mmap_pgoff(struct file if ((len = PAGE_ALIGN(len)) == 0) return addr; - if (len > TASK_SIZE || addr > TASK_SIZE-len) + if (len > TASK_SIZE) return -EINVAL; /* offset overflow? */ @@ -405,9 +405,15 @@ static inline unsigned long arch_get_unm if (len > TASK_SIZE) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; - addr = PAGE_ALIGN(addr); + + if (addr) { + addr = PAGE_ALIGN(addr); + vma = find_vma(current->mm, addr); + if (TASK_SIZE - len >= addr && + (!vma || addr + len <= vma->vm_start)) + return addr; + } + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) { /* At this point: (!vma || addr < vma->vm_end). */ @@ -425,6 +431,8 @@ extern unsigned long arch_get_unmapped_a unsigned long get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) { if (flags & MAP_FIXED) { + if (addr > TASK_SIZE - len) + return -EINVAL; if (addr & ~PAGE_MASK) return -EINVAL; return addr; From macro@ds2.pg.gda.pl Tue May 8 23:37:59 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id XAA16916; Tue, 8 May 2001 23:37:59 +0200 (MET DST) Received-Date: Tue, 8 May 2001 23:37:59 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd016914; Tue May 8 23:37:51 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id XAA10834; Tue, 8 May 2001 23:32:21 +0200 (MET DST) Date: Tue, 8 May 2001 23:32:21 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: "David S. Miller" cc: linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: <15096.23421.564537.144351@pizda.ninka.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 781 Lines: 19 On Tue, 8 May 2001, David S. Miller wrote: > There are several get_unmapped_area() implementations besides the > standard one (search for HAVE_ARCH_UNMAPPED_AREA). Please fix > them up too. Yep, I know (ia64 and sparc*). But being lazy enough (and being short on time) I won't do it until I know the idea of the change is accepted. I'm sorry -- I sent previous versions of the patch twice since last Summer with no response at all and doing bits no one is interested in is a waste of time. Thanks for your response, though -- maybe there is someone interested, after all. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From alan@lxorguk.ukuu.org.uk Wed May 9 01:00:39 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id BAA18903; Wed, 9 May 2001 01:00:39 +0200 (MET DST) Received-Date: Wed, 9 May 2001 01:00:39 +0200 (MET DST) Received: from router-100M.swansea.linux.org.uk(194.168.151.17), claiming to be "the-village.bc.nu" via SMTP by guadalquivir.fnet.fr, id smtpd018881; Wed May 9 01:00:36 2001 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 14xGS7-0000r5-00; Tue, 8 May 2001 23:59:35 +0100 Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests To: davem@redhat.com (David S. Miller) Date: Tue, 8 May 2001 23:59:33 +0100 (BST) Cc: macro@ds2.pg.gda.pl (Maciej W. Rozycki), linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com In-Reply-To: <15096.27432.381478.837650@pizda.ninka.net> from "David S. Miller" at May 08, 2001 02:54:48 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Content-Length: 387 Lines: 9 > > Thanks for your response, though -- maybe there is someone interested, > > after all. > > That's pretty arrogant that cut and pasting a few lines into some > architecture specific files and reporting the updated patch is too > much to ask. And just how is he going to test it ? Considering he was just asking if the concept was reasonable I think you are a little out of order From macro@ds2.pg.gda.pl Wed May 9 01:50:38 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id BAA19259; Wed, 9 May 2001 01:50:38 +0200 (MET DST) Received-Date: Wed, 9 May 2001 01:50:38 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd019256; Wed May 9 01:50:20 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id BAA14988; Wed, 9 May 2001 01:46:35 +0200 (MET DST) Date: Wed, 9 May 2001 01:46:35 +0200 (MET DST) From: "Maciej W. Rozycki" To: "David S. Miller" cc: linux-kernel@vger.kernel.org, linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: <15096.27432.381478.837650@pizda.ninka.net> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 8455 Lines: 223 On Tue, 8 May 2001, David S. Miller wrote: > That's pretty arrogant that cut and pasting a few lines into some > architecture specific files and reporting the updated patch is too > much to ask. I'm sorry if you find me arrogant -- that certainly was not my intent. I did look at the files and changes are not as trivial as cut and paste. > Perhaps reviewing your change is also, too much to ask. Perhaps > we are too lazy and short on time to have a look at your change. Well, I've been using similar changes since July. I may live with patches forever and be fine. Still this is not the point with free software. It would be malicious if I had a fix and I wouldn't share it. Sooner or later someone would discover the problem again and would waste time to track it down unnecessarily. And again, and again... > I don't think it's asking a lot to provide a complete change. It's not a lot, supposedly, but look at the case from my point of view. It's a bugfix and not a new feature. I've invested a few hours in finding the cause of a weird bug on a MIPS/Linux machine. I am providing a ready solution that works for most architectures with the exception of a few ones I'm not familiar with. Well, it's great I have an opportunity to get better knowledge on these architectures, but I cannot always afford it and I know there are people who already have enough knowledge to be sure bits get written correctly immediately. I never hesitate to do job myself in the areas I am familiar with or when I have enough free time (and I do have, from time to time). I don't have time currently, I am afraid (basically I am now stealing the time I would otherwise spend sleeping for a task that was quite low on my priority list) and I am sure someone familiar with the specific ports would spend less time than I do. Finally I do consider my time equally worth to anyone else's one, so why should I have to spend x units of time, whilst some else would only spend x/2 or x/3 or whatever... Of course I consider this rule working both ways. > I'm sure the MIPS folks know all too well whats it's like when their > port is crapped up because someone only made changes to x86 port > portions. At least for me on after working on Sparc for some time, > I'm adamant about providing complete changes so that this kind of > grief is avoided for other port maintainers. The port gets crapped from time to time, although Ralf is doing great job to keep it fine, so it's more that specific MIPS hosts lag behind the rest of the kernel. Still I consider it the specific maintainer's job to get things synchronized. It just works better this way. > In the time you used to compose your response to me, and now > to read this email from me, you could have fixed up the patch > perhaps 2 or 3 times. Just do it and get it over with ok? I'm not so sure, I'm afraid, especially at this time of the day. Check timestamps of mails if curious... > Dziekuje. Nie za ma co. ;-) A patch follows. Architecture-specific changes are completely untested. I hope I got things right, otherwise I'll consider my time wasted. BTW, I've noticed the "if (flags & MAP_FIXED)" statements in arch_get_unmapped_area() in arch/sparc*/kernel/sys_sparc.c are dead code now, as get_unmapped_area() in mm/mmap.c never calls it if MAP_FIXED is set in flags. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + diff -up --recursive --new-file linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c linux-2.4.4/arch/ia64/kernel/sys_ia64.c --- linux-2.4.4.macro/arch/ia64/kernel/sys_ia64.c Mon May 7 16:43:50 2001 +++ linux-2.4.4/arch/ia64/kernel/sys_ia64.c Tue May 8 23:25:49 2001 @@ -28,13 +28,22 @@ arch_get_unmapped_area (struct file *fil if (len > RGN_MAP_LIMIT) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; + if (addr) { + if (flags & MAP_SHARED) + addr = COLOR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + vmm = find_vma(current->mm, addr); + if (TASK_SIZE - len >= addr && + rgn_offset(addr) + len <= RGN_MAP_LIMIT) && + (!vmm || addr + len <= vmm->vm_start)) + return addr; + } if (flags & MAP_SHARED) - addr = COLOR_ALIGN(addr); + addr = COLOR_ALIGN(TASK_UNMAPPED_BASE); else - addr = PAGE_ALIGN(addr); + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ diff -up --recursive --new-file linux-2.4.4.macro/arch/sparc/kernel/sys_sparc.c linux-2.4.4/arch/sparc/kernel/sys_sparc.c --- linux-2.4.4.macro/arch/sparc/kernel/sys_sparc.c Mon May 7 16:22:42 2001 +++ linux-2.4.4/arch/sparc/kernel/sys_sparc.c Tue May 8 22:50:51 2001 @@ -54,17 +54,31 @@ unsigned long arch_get_unmapped_area(str return -ENOMEM; if (ARCH_SUN4C_SUN4 && len > 0x20000000) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; + if (addr) { + if (flags & MAP_SHARED) + addr = COLOR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + vmm = find_vma(current->mm, addr); + if (ARCH_SUN4C_SUN4 && addr < 0xe0000000 && + 0x20000000 - len < addr) { + addr = PAGE_OFFSET; + vmm = find_vma(current->mm, PAGE_OFFSET); + } + if (TASK_SIZE - PAGE_SIZE - len >= addr && + (!vmm || addr + len <= vmm->vm_start)) + return addr; + } if (flags & MAP_SHARED) - addr = COLOUR_ALIGN(addr); + addr = COLOR_ALIGN(TASK_UNMAPPED_BASE); else - addr = PAGE_ALIGN(addr); + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ - if (ARCH_SUN4C_SUN4 && addr < 0xe0000000 && 0x20000000 - len < addr) { + if (ARCH_SUN4C_SUN4 && addr < 0xe0000000 && + 0x20000000 - len < addr) { addr = PAGE_OFFSET; vmm = find_vma(current->mm, PAGE_OFFSET); } diff -up --recursive --new-file linux-2.4.4.macro/arch/sparc64/kernel/sys_sparc.c linux-2.4.4/arch/sparc64/kernel/sys_sparc.c --- linux-2.4.4.macro/arch/sparc64/kernel/sys_sparc.c Mon May 7 16:44:01 2001 +++ linux-2.4.4/arch/sparc64/kernel/sys_sparc.c Tue May 8 22:30:09 2001 @@ -60,15 +60,27 @@ unsigned long arch_get_unmapped_area(str task_size = 0xf0000000UL; if (len > task_size || len > -PAGE_OFFSET) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; + task_size -= len; + + if (addr) { + if (flags & MAP_SHARED) + addr = COLOR_ALIGN(addr); + else + addr = PAGE_ALIGN(addr); + vmm = find_vma(current->mm, addr); + if (addr < PAGE_OFFSET && -PAGE_OFFSET - len < addr) { + addr = PAGE_OFFSET; + vmm = find_vma(current->mm, PAGE_OFFSET); + } + if (task_size >= addr && + (!vmm || addr + len <= vmm->vm_start)) + return addr; + } if (flags & MAP_SHARED) - addr = COLOUR_ALIGN(addr); + addr = COLOR_ALIGN(TASK_UNMAPPED_BASE); else - addr = PAGE_ALIGN(addr); - - task_size -= len; + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vmm = find_vma(current->mm, addr); ; vmm = vmm->vm_next) { /* At this point: (!vmm || addr < vmm->vm_end). */ diff -up --recursive --new-file linux-2.4.4.macro/mm/mmap.c linux-2.4.4/mm/mmap.c --- linux-2.4.4.macro/mm/mmap.c Mon May 7 16:44:32 2001 +++ linux-2.4.4/mm/mmap.c Tue May 8 22:16:00 2001 @@ -219,7 +219,7 @@ unsigned long do_mmap_pgoff(struct file if ((len = PAGE_ALIGN(len)) == 0) return addr; - if (len > TASK_SIZE || addr > TASK_SIZE-len) + if (len > TASK_SIZE) return -EINVAL; /* offset overflow? */ @@ -405,9 +405,15 @@ static inline unsigned long arch_get_unm if (len > TASK_SIZE) return -ENOMEM; - if (!addr) - addr = TASK_UNMAPPED_BASE; - addr = PAGE_ALIGN(addr); + + if (addr) { + addr = PAGE_ALIGN(addr); + vma = find_vma(current->mm, addr); + if (TASK_SIZE - len >= addr && + (!vma || addr + len <= vma->vm_start)) + return addr; + } + addr = PAGE_ALIGN(TASK_UNMAPPED_BASE); for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) { /* At this point: (!vma || addr < vma->vm_end). */ @@ -425,6 +431,8 @@ extern unsigned long arch_get_unmapped_a unsigned long get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags) { if (flags & MAP_FIXED) { + if (addr > TASK_SIZE - len) + return -EINVAL; if (addr & ~PAGE_MASK) return -EINVAL; return addr; From michaels@jungo.com Wed May 9 14:07:34 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA24036; Wed, 9 May 2001 14:07:34 +0200 (MET DST) Received-Date: Wed, 9 May 2001 14:07:34 +0200 (MET DST) Received: from mailgw2.netvision.net.il(194.90.1.9) via SMTP by guadalquivir.fnet.fr, id smtpd024034; Wed May 9 14:07:27 2001 Received: from jungo.com ([194.90.113.98]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id PAA13119; Wed, 9 May 2001 15:05:49 +0300 (IDT) Message-ID: <3AF93224.6080304@jungo.com> Date: Wed, 09 May 2001 15:03:48 +0300 From: Michael Shmulevich Organization: Jungo LTD User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.8.1) Gecko/20010326 X-Accept-Language: en MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 557 Lines: 17 As a side question: does this patch apply to 2.2.x kernel too? While working on ld.so.1-9 port on MIPS I seen there's a try to mmap() some address > 0x80000000 which fails due to the same if(...TASK_SIZE...) mentioned in the patch. Just wondering if this applies to me too :-) Sincerely yours, Michael Shmulevich ______________________________________ Software Developer Jungo - R&D email: michaels@jungo.com web: http://www.jungo.com Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233 Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide) From macro@ds2.pg.gda.pl Wed May 9 14:47:23 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id OAA24265; Wed, 9 May 2001 14:47:23 +0200 (MET DST) Received-Date: Wed, 9 May 2001 14:47:23 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd024259; Wed May 9 14:46:58 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA07695; Wed, 9 May 2001 14:41:10 +0200 (MET DST) Date: Wed, 9 May 2001 14:41:10 +0200 (MET DST) From: "Maciej W. Rozycki" To: Michael Shmulevich cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com Subject: Re: [patch] 2.4.4: mmap() fails for certain legal requests In-Reply-To: <3AF93224.6080304@jungo.com> Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 732 Lines: 18 On Wed, 9 May 2001, Michael Shmulevich wrote: > As a side question: does this patch apply to 2.2.x kernel too? Feel free to backport it. ;-) One hunk fails for 2.2.19, but it can be applied by hand (note the vma variable is named vmm in 2.2). > While working on ld.so.1-9 port on MIPS I seen there's a try to mmap() > some address > 0x80000000 which fails due to the same > if(...TASK_SIZE...) mentioned in the patch. Yep, that's the exact problem, assuming MAP_FIXED is not set in flags (something is screwed if it is). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + From ralf@dea.waldorf-gmbh.de Mon May 14 23:07:11 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id XAA02111; Mon, 14 May 2001 23:07:11 +0200 (MET DST) Received-Date: Mon, 14 May 2001 23:07:11 +0200 (MET DST) Received: from oss.sgi.com(216.32.174.190) via SMTP by guadalquivir.fnet.fr, id smtpd002109; Mon May 14 23:07:01 2001 Received: from dea.waldorf-gmbh.de (IDENT:root@localhost [127.0.0.1]) by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EL6mF23538 for ; Mon, 14 May 2001 14:06:49 -0700 Received: (from ralf@localhost) by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f4EHsfx06540; Mon, 14 May 2001 14:54:41 -0300 Date: Mon, 14 May 2001 14:54:41 -0300 From: Ralf Baechle To: Bertrand HENRY Cc: linux-mips@fnet.fr Subject: Re: Mips with linux Message-ID: <20010514145441.A6533@bacchus.dhis.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from BHenry@ciril.net on Fri, May 11, 2001 at 02:54:49PM +0200 X-Accept-Language: de,en,fr Content-Length: 551 Lines: 14 On Fri, May 11, 2001 at 02:54:49PM +0200, Bertrand HENRY wrote: > where can i download Linux for Mips ? > I can't acces to your website (Blank screen) Thanks for telling this. It notes that the local firewall through which I'm accessing the net and Fnet's firewall are mutually exclusive, so I cannot update the FAQ from here; my last attempt resulted in truncation of the FAQ document. I'll fix that asap but that means not before May 29. The same document is also available from http://oss.sgi.com/mips/mips-howto.html or any LDP site. Ralf From macro@ds2.pg.gda.pl Mon May 28 17:31:38 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id RAA12585; Mon, 28 May 2001 17:31:38 +0200 (MET DST) Received-Date: Mon, 28 May 2001 17:31:38 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd012554; Mon May 28 17:26:49 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA26147; Mon, 28 May 2001 17:21:59 +0200 (MET DST) Date: Mon, 28 May 2001 17:21:59 +0200 (MET DST) From: "Maciej W. Rozycki" To: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle Subject: [patch] RFC: A sys__test_and_set() implementation Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 5214 Lines: 182 Hi, Following is a sys__test_and_set() syscall implementation that should suite well the _test_and_set() library call as defined by the MIPS ABI. I didn't have enough time to implement a glibc wrapper, yet, but I have written a test program that is much similar to how the wrapper will look like. The syscall uses a slightly modified calling convention which allows it to avoid errno mangling code and always return consistent results. The call never returns an error -- there is no reason to. If an illegal access is detected, a SIGBUS or a SIGSEGV is sent appropriately, depending on the kind of the violation. This mimics the ll/sc behaviour in these circumstances and makes the kernel vs library implementation more consistent. Here is the test program: #include #include #ifndef __NR__test_and_set #define __NR__test_and_set (__NR_Linux + 221) #endif static inline int _test_and_set(int *p, int v) { int r; asm volatile( "la $4,%1\n\t" "move $5,%2\n\t" "li $2,%3\n\t" "syscall\n\t" "move %0,$3" : "=r" (r) : "m" (*p), "r" (v), "i" (__NR__test_and_set) : "$2", "$3", "$4", "$5", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", "memory"); return r; } int main(void) { volatile int v = 1; int v0, v1, r; v0 = v; r = _test_and_set((int *)&v, -1); v1 = v; printf("v0: %i, v1: %i, r: %i\n", v0, v1, r); return 0; } Following it the patch. It was built and tested using a linux 2.4.0-test12 CVS snapshot from oss. It applies to a current snapshot of 2.4.3, but it wasn't run-time tested in this configuration. Given it's self-contained, I hope it works for 2.4.3 as well. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.0-test12-20010110-tas-11 diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c Sun Oct 29 05:26:54 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c Sun May 27 22:56:21 2001 @@ -174,6 +174,82 @@ asmlinkage int sys_olduname(struct oldol return error; } +/* Note: errno is always zero and the result is in v1. */ +asmlinkage int sys__test_and_set(struct pt_regs regs) +{ + int *ptr, val, ret, err, tmp; + + ptr = (int *)(regs.regs[4]); + val = (int)(regs.regs[5]); + + /* Don't emulate unaligned accesses. */ + if ((int)ptr & 3) + goto fault; + +#ifdef CONFIG_CPU_HAS_LLSC + __asm__(".set mips2\n\t" + "1:\n\t" + "ll %0,%5\n\t" + "move %3,%4\n" + "2:\n\t" + "sc %3,%1\n\t" + "beqz %3,1b\n\t" + "3:\n\t" + ".set mips0\n\t" + ".section .fixup,\"ax\"\n" + "4:\n\t" + "li %2,%7\n\t" + "j 3b\n\t" + ".previous\n\t" + ".section __ex_table,\"a\"\n\t" + ".word 1b,4b\n\t" + ".word 2b,4b\n\t" + ".previous" + : "=&r" (ret), "=R" (*ptr), "=r" (err), "=&r" (tmp) + : "r" (val), "1" (*ptr), "2" (0), "i" (-EFAULT)); +#else + /* A zero here saves us three instructions. */ + err = verify_area(VERIFY_WRITE, ptr, 0); + + save_and_cli(tmp); + err |= __get_user(ret, ptr); + err |= __put_user(val, ptr); /* No fault unless unwriteable. */ + restore_flags(tmp); +#endif + + if (err) + goto fault; + + (int)(regs.regs[3]) = ret; + + return 0; + +fault: + regs.cp0_epc -= 4; /* Go back to SYSCALL. */ + + { + struct siginfo info; + + + if ((int)ptr & 3) { + info.si_signo = SIGBUS; + info.si_code = BUS_ADRALN; + } else { + info.si_signo = SIGSEGV; + if (verify_area(VERIFY_WRITE, ptr, 0)) + info.si_code = SEGV_ACCERR; + else + info.si_code = SEGV_MAPERR; + } + info.si_errno = 0; + info.si_addr = (void *)regs.cp0_epc; + + force_sig_info(info.si_signo, &info, current); + } + + return 0; +} + /* * Do the indirect syscall syscall. * Don't care about kernel locking; the actual syscall will do it. diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h Wed Nov 8 05:26:57 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h Wed May 23 23:59:02 2001 @@ -235,3 +235,4 @@ SYS(sys_mincore, 3) SYS(sys_madvise, 3) SYS(sys_getdents64, 3) SYS(sys_fcntl64, 3) /* 4220 */ +SYS(sys__test_and_set, 0) diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h --- linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h Thu Oct 26 04:27:09 2000 +++ linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h Wed May 23 23:09:00 2001 @@ -233,11 +233,12 @@ #define __NR_madvise (__NR_Linux + 218) #define __NR_getdents64 (__NR_Linux + 219) #define __NR_fcntl64 (__NR_Linux + 220) +#define __NR__test_and_set (__NR_Linux + 221) /* * Offset of the last Linux flavoured syscall */ -#define __NR_Linux_syscalls 220 +#define __NR_Linux_syscalls 221 #ifndef _LANGUAGE_ASSEMBLY From macro@ds2.pg.gda.pl Thu May 31 05:25:37 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id FAA24834; Thu, 31 May 2001 05:25:37 +0200 (MET DST) Received-Date: Thu, 31 May 2001 05:25:37 +0200 (MET DST) Received: from delta.ds2.pg.gda.pl(213.192.72.1) via SMTP by guadalquivir.fnet.fr, id smtpd024832; Thu May 31 05:25:35 2001 Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA21204; Wed, 30 May 2001 19:58:44 +0200 (MET DST) Date: Wed, 30 May 2001 19:58:43 +0200 (MET DST) From: "Maciej W. Rozycki" Reply-To: "Maciej W. Rozycki" To: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Andreas Jaeger , Jun Sun Subject: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration Message-ID: Organization: Technical University of Gdansk MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 8885 Lines: 269 Hi, Here is the second version of the sys__test_and_set() syscall suite. A glibc patch is included this time as well. There are two small changes to the sys__test_and_set() implementation: 1. verify_area() is now called for the ll/sc version as well. Otherwise one could pass a KSEG address and gain unauthorized access. 2. The fuction now returns immediately without performing a write access if the value stored in the memory wouldn't change. This is to avoid the need of a potentially costful sc operation; for consistency, this is also done for the non-ll/sc version. The glibc patch should be fairly obvious. There is no inline version of the _test_and_set() function for MIPS I anymore -- while previously it saved an extra stack frame just to call sysmips(), this would be pointless now (well, not quite as long as we fallback to sysmips(), actually, but that is a temporary compatibility bit that will soon get removed, I hope). Note that while sys__test_and_set() never returns an error, there might one happen if someone tries to execute the syscall running a kernel that does not support it. Hence we fall back to sysmips(). The official entry point is _test_and_set(). There is also the ___test_and_set() entry point defined, mostly for completeness for MIPS II+ systems, to be sure all syscalls actually have their wrappers exported. Not to be used under normal circumstances, though. Andreas, what do you think: Should we fall back to sysmips() as in the following patch (at a considerable performance hit -- without the fallback the entire ___test_and_set() wrapper is seven instructions long) or just require a specific minimum kernel version bail out at the compile time if no __NR__test_and_set is defined? Granted, pthreads don't run for MIPS/Linux for a long time, so it's possible the user base is not that large such an abrupt switch would be impossible. Especially as sysmips() seems to be continuously in flux for the last few months. I assume the switch to the new syscall would be mandatory for glibc 2.3 in any case. I'm open to constructive feedback. An open question is whether returning the result in v1 is clean. I believe it is -- I haven't been convinced that storing the result in a memory location passed as the third argument is cleaner. Certainly it's not faster and v1 is still dedicated to be a result register. It's used by sys_pipe() this way, for example. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + patch-mips-2.4.0-test12-20010110-tas-12 diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscall.c Sun Oct 29 05:26:54 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscall.c Wed May 30 13:01:00 2001 @@ -174,6 +174,90 @@ asmlinkage int sys_olduname(struct oldol return error; } +/* Note: errno is always zero and the result is in v1. */ +asmlinkage int sys__test_and_set(struct pt_regs regs) +{ + int *ptr, val, ret, err, tmp; + + ptr = (int *)(regs.regs[4]); + val = (int)(regs.regs[5]); + + /* Don't emulate unaligned accesses. */ + if ((int)ptr & 3) + goto fault; + + /* A zero here saves us three instructions. */ + err = verify_area(VERIFY_WRITE, ptr, 0); + if (err) + goto fault; + +#ifdef CONFIG_CPU_HAS_LLSC + __asm__(".set mips2\n\t" + "1:\n\t" + "ll %0,%5\n\t" + ".set push\n\t" + ".set noreorder\n\t" + "beq %0,%4,3f\n\t" + " move %3,%4\n" + ".set pop\n\t" + "2:\n\t" + "sc %3,%1\n\t" + "beqz %3,1b\n\t" + "3:\n\t" + ".set mips0\n\t" + ".section .fixup,\"ax\"\n" + "4:\n\t" + "li %2,%7\n\t" + "j 3b\n\t" + ".previous\n\t" + ".section __ex_table,\"a\"\n\t" + ".word 1b,4b\n\t" + ".word 2b,4b\n\t" + ".previous" + : "=&r" (ret), "=R" (*ptr), "=r" (err), "=&r" (tmp) + : "r" (val), "1" (*ptr), "2" (0), "i" (-EFAULT)); +#else + save_and_cli(tmp); + err = __get_user(ret, ptr); + if (ret != val) + err |= __put_user(val, ptr); /* No fault + unless unwriteable. */ + restore_flags(tmp); +#endif + + if (err) + goto fault; + + (int)(regs.regs[3]) = ret; + + return 0; + +fault: + regs.cp0_epc -= 4; /* Go back to SYSCALL. */ + + { + struct siginfo info; + + + if ((int)ptr & 3) { + info.si_signo = SIGBUS; + info.si_code = BUS_ADRALN; + } else { + info.si_signo = SIGSEGV; + if (verify_area(VERIFY_WRITE, ptr, 0)) + info.si_code = SEGV_ACCERR; + else + info.si_code = SEGV_MAPERR; + } + info.si_errno = 0; + info.si_addr = (void *)regs.cp0_epc; + + force_sig_info(info.si_signo, &info, current); + } + + return 0; +} + /* * Do the indirect syscall syscall. * Don't care about kernel locking; the actual syscall will do it. diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h --- linux-mips-2.4.0-test12-20010110.macro/arch/mips/kernel/syscalls.h Wed Nov 8 05:26:57 2000 +++ linux-mips-2.4.0-test12-20010110/arch/mips/kernel/syscalls.h Wed May 23 23:59:02 2001 @@ -235,3 +235,4 @@ SYS(sys_mincore, 3) SYS(sys_madvise, 3) SYS(sys_getdents64, 3) SYS(sys_fcntl64, 3) /* 4220 */ +SYS(sys__test_and_set, 0) diff -up --recursive --new-file linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h --- linux-mips-2.4.0-test12-20010110.macro/include/asm-mips/unistd.h Thu Oct 26 04:27:09 2000 +++ linux-mips-2.4.0-test12-20010110/include/asm-mips/unistd.h Wed May 23 23:09:00 2001 @@ -233,11 +233,12 @@ #define __NR_madvise (__NR_Linux + 218) #define __NR_getdents64 (__NR_Linux + 219) #define __NR_fcntl64 (__NR_Linux + 220) +#define __NR__test_and_set (__NR_Linux + 221) /* * Offset of the last Linux flavoured syscall */ -#define __NR_Linux_syscalls 220 +#define __NR_Linux_syscalls 221 #ifndef _LANGUAGE_ASSEMBLY glibc-2.2.3-mips-tas.patch diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/Versions glibc-2.2.3/sysdeps/unix/sysv/linux/mips/Versions --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/Versions Wed Aug 2 21:53:16 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/Versions Wed May 30 02:20:28 2001 @@ -16,6 +16,6 @@ libc { } GLIBC_2.2 { # _* - _test_and_set; + _test_and_set; ___test_and_set; } } diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/_test_and_set.c Fri Jul 28 13:37:25 2000 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/_test_and_set.c Wed May 30 12:05:33 2001 @@ -21,10 +21,47 @@ defined in sys/tas.h */ #include +#include +#include +#include +#include #define _EXTERN_INLINE #ifndef __USE_EXTERN_INLINES # define __USE_EXTERN_INLINES 1 #endif +#ifdef __NR__test_and_set +#define __HAVE__TEST_AND_SET 1 +#else +#define __HAVE__TEST_AND_SET 0 +#endif + #include "sys/tas.h" + +int ___test_and_set (int *p, int v) +{ + if (__HAVE__TEST_AND_SET) + { + register int *__p asm ("$4") = p; + register int __v asm ("$5") = v; + register int __n asm ("$2") = SYS_ify (_test_and_set); + register int __e asm ("$7"); + register int __r asm ("$3"); + + asm + ("syscall" + : "=r" (__r), "=r" (__e) + : "r" (__p), "r" (__v), "r" (__n) + : "$2", + "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", + "memory"); + if (!__e) + return __r; + } + return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); +} + +#if (_MIPS_ISA < _MIPS_ISA_MIPS2) +strong_alias (___test_and_set, _test_and_set) +#endif diff -up --recursive --new-file glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h --- glibc-2.2.3.macro/sysdeps/unix/sysv/linux/mips/sys/tas.h Sun Jan 7 04:35:41 2001 +++ glibc-2.2.3/sysdeps/unix/sysv/linux/mips/sys/tas.h Wed May 30 02:18:19 2001 @@ -22,11 +22,11 @@ #include #include -#include __BEGIN_DECLS extern int _test_and_set (int *p, int v) __THROW; +extern int ___test_and_set (int *p, int v) __THROW; #ifdef __USE_EXTERN_INLINES @@ -59,15 +59,7 @@ _test_and_set (int *p, int v) __THROW return r; } -# else /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - -_EXTERN_INLINE int -_test_and_set (int *p, int v) __THROW -{ - return sysmips (MIPS_ATOMIC_SET, (int) p, v, 0); -} - -# endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ +# endif /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ #endif /* __USE_EXTERN_INLINES */ From aj@suse.de Thu May 31 08:54:07 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id IAA27059; Thu, 31 May 2001 08:54:07 +0200 (MET DST) Received-Date: Thu, 31 May 2001 08:54:07 +0200 (MET DST) Received: from ns.suse.de(213.95.15.193), claiming to be "Cantor.suse.de" via SMTP by guadalquivir.fnet.fr, id smtpd027054; Thu May 31 08:53:57 2001 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 105C61E10F; Thu, 31 May 2001 08:53:55 +0200 (MEST) X-Authentication-Warning: D139.suse.de: aj set sender to aj@suse.de using -f Sender: aj@suse.de To: "Maciej W. Rozycki" Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle , Jun Sun Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration References: From: Andreas Jaeger Date: 31 May 2001 08:52:58 +0200 In-Reply-To: ("Maciej W. Rozycki"'s message of "Wed, 30 May 2001 19:58:43 +0200 (MET DST)") Message-ID: User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 3261 Lines: 74 "Maciej W. Rozycki" writes: > Hi, > > Here is the second version of the sys__test_and_set() syscall suite. A > glibc patch is included this time as well. > > There are two small changes to the sys__test_and_set() implementation: > > 1. verify_area() is now called for the ll/sc version as well. Otherwise > one could pass a KSEG address and gain unauthorized access. > > 2. The fuction now returns immediately without performing a write access > if the value stored in the memory wouldn't change. This is to avoid the > need of a potentially costful sc operation; for consistency, this is also > done for the non-ll/sc version. > > The glibc patch should be fairly obvious. There is no inline version of > the _test_and_set() function for MIPS I anymore -- while previously it > saved an extra stack frame just to call sysmips(), this would be pointless > now (well, not quite as long as we fallback to sysmips(), actually, but > that is a temporary compatibility bit that will soon get removed, I hope). > Note that while sys__test_and_set() never returns an error, there might > one happen if someone tries to execute the syscall running a kernel that > does not support it. Hence we fall back to sysmips(). > > The official entry point is _test_and_set(). There is also the > ___test_and_set() entry point defined, mostly for completeness for MIPS > II+ systems, to be sure all syscalls actually have their wrappers > exported. Not to be used under normal circumstances, though. > > Andreas, what do you think: Should we fall back to sysmips() as in the > following patch (at a considerable performance hit -- without the fallback > the entire ___test_and_set() wrapper is seven instructions long) or just > require a specific minimum kernel version bail out at the compile time if > no __NR__test_and_set is defined? Granted, pthreads don't run for > MIPS/Linux for a long time, so it's possible the user base is not that > large such an abrupt switch would be impossible. Especially as sysmips() > seems to be continuously in flux for the last few months. I assume the > switch to the new syscall would be mandatory for glibc 2.3 in any case. Do it the following way: - Define in sysdeps/unix/sysv/linux/kernel-features a new macro, e.g. __ASSUME_TEST_AND_SET with the appropriate guards - Do *both* implementations like this: #include #if __ASSUME_TEST_AND_SET fast code without fallback #else slow code that first tries kernel call and then falls back to sysmips #endif This way you get the fast one if you configure glibc with --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with those features. Check other places in glibc for details how this can be done. Thanks, Andreas > I'm open to constructive feedback. An open question is whether returning > the result in v1 is clean. I believe it is -- I haven't been convinced > that storing the result in a memory location passed as the third argument > is cleaner. Certainly it's not faster and v1 is still dedicated to be a > result register. It's used by sys_pipe() this way, for example. > > Maciej -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jsun@mvista.com Thu May 31 21:20:42 2001 Received: (uucp@localhost) by guadalquivir.fnet.fr (8.8.8/97.02.12/Guadalquivir); id VAA04323; Thu, 31 May 2001 21:20:42 +0200 (MET DST) Received-Date: Thu, 31 May 2001 21:20:42 +0200 (MET DST) Received: from gateway-1237.mvista.com(12.44.186.158), claiming to be "hermes.mvista.com" via SMTP by guadalquivir.fnet.fr, id smtpd004321; Thu May 31 21:20:39 2001 Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75]) by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f4VJDr014020; Thu, 31 May 2001 12:13:53 -0700 Sender: jsun@hermes.mvista.com Message-ID: <3B1697BE.3F3765A2@mvista.com> Date: Thu, 31 May 2001 12:13:02 -0700 From: Jun Sun X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andreas Jaeger CC: "Maciej W. Rozycki" , linux-mips@fnet.fr, linux-mips@oss.sgi.com, Ralf Baechle Subject: Re: [patch] RFC: A sys__test_and_set() implementation, 2nd iteration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4159 Lines: 88 Andreas Jaeger wrote: > > "Maciej W. Rozycki" writes: > > > Hi, > > > > Here is the second version of the sys__test_and_set() syscall suite. A > > glibc patch is included this time as well. > > > > There are two small changes to the sys__test_and_set() implementation: > > > > 1. verify_area() is now called for the ll/sc version as well. Otherwise > > one could pass a KSEG address and gain unauthorized access. > > > > 2. The fuction now returns immediately without performing a write access > > if the value stored in the memory wouldn't change. This is to avoid the > > need of a potentially costful sc operation; for consistency, this is also > > done for the non-ll/sc version. > > > > The glibc patch should be fairly obvious. There is no inline version of > > the _test_and_set() function for MIPS I anymore -- while previously it > > saved an extra stack frame just to call sysmips(), this would be pointless > > now (well, not quite as long as we fallback to sysmips(), actually, but > > that is a temporary compatibility bit that will soon get removed, I hope). > > Note that while sys__test_and_set() never returns an error, there might > > one happen if someone tries to execute the syscall running a kernel that > > does not support it. Hence we fall back to sysmips(). > > > > The official entry point is _test_and_set(). There is also the > > ___test_and_set() entry point defined, mostly for completeness for MIPS > > II+ systems, to be sure all syscalls actually have their wrappers > > exported. Not to be used under normal circumstances, though. > > > > Andreas, what do you think: Should we fall back to sysmips() as in the > > following patch (at a considerable performance hit -- without the fallback > > the entire ___test_and_set() wrapper is seven instructions long) or just > > require a specific minimum kernel version bail out at the compile time if > > no __NR__test_and_set is defined? Granted, pthreads don't run for > > MIPS/Linux for a long time, so it's possible the user base is not that > > large such an abrupt switch would be impossible. Especially as sysmips() > > seems to be continuously in flux for the last few months. I assume the > > switch to the new syscall would be mandatory for glibc 2.3 in any case. > > Do it the following way: > - Define in sysdeps/unix/sysv/linux/kernel-features a new macro, e.g. > __ASSUME_TEST_AND_SET with the appropriate guards > - Do *both* implementations like this: > #include > #if __ASSUME_TEST_AND_SET > fast code without fallback > #else > slow code that first tries kernel call and then falls back to sysmips > #endif > > This way you get the fast one if you configure glibc with > --enable-kernel=2.4.6 if we assume that 2.4.6 is the first kernel with > those features. > > Check other places in glibc for details how this can be done. > This might be an overkill - the slow code on a newer kernel costs about 1 or 2 cycle longer per call. > > I'm open to constructive feedback. An open question is whether returning > > the result in v1 is clean. I believe it is -- I haven't been convinced > > that storing the result in a memory location passed as the third argument > > is cleaner. Certainly it's not faster and v1 is still dedicated to be a > > result register. It's used by sys_pipe() this way, for example. On a second thought I feel stronger using $v1 is not a good idea - what if the return path of syscall suddenly needs to modify $v1? Also we have generic syscall routine in glibc, what if someday that routine starts to check $v1 as well? I understand the chances of these "what if" are low (and perhaps sys_pipe() is already this way), but I am still convinced we should the right thing. (Whoever invented MIPS_ATOMIC_SET might have been thinking it should never need to return an error code!) I don't see any "dirtiness" in using the third argument. The slowdown in performance should be negligible under the context of the whole system call. A syscall is invented to be here and stay. I personally feel more comfortable to play a little safer rather than a littel faster. Jun