This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Apr 23 09:55:08 2024 Received: from entropy.muc.muohio.edu (IDENT:root@entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id VAA06984 for ; Fri, 16 Apr 1999 21:25:53 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id WAA15791; Fri, 16 Apr 1999 22:24:22 -0400 Received: by vger.rutgers.edu via listexpand id <160699-11364>; Fri, 16 Apr 1999 21:30:55 -0400 Received: by vger.rutgers.edu id <160723-11366>; Fri, 16 Apr 1999 21:23:24 -0400 Received: from inet16.us.oracle.com ([192.86.155.100]:36408 "EHLO inet16.us.oracle.com" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <160473-11364>; Fri, 16 Apr 1999 21:21:39 -0400 Received: from mailsun2.us.oracle.com (mailsun2.us.oracle.com [144.25.88.74]) by inet16.us.oracle.com (8.8.5/8.8.5) with SMTP id SAA24054 for ; Fri, 16 Apr 1999 18:44:24 -0700 (PDT) Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id SAA28316; Fri, 16 Apr 1999 18:44:17 -0700 Message-Id: <199904170144.SAA28316@mailsun2.us.oracle.com> Date: 16 Apr 99 18:43:17 -0700 From: "orarepl" To: linux-kernel@vger.rutgers.edu Subject: Return Message Reply-To: orarepl@us.oracle.com Mime-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.2.1.3.1) Content-Type: multipart/mixed; boundary="=_ORCL_27262309_0_0" Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig --=_ORCL_27262309_0_0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" The included message could not be delivered to the following invalid mail names. Please verify these names and try them again. Bad name: hyin --=_ORCL_27262309_0_0 Content-Type:message/rfc822 Date: 16 Apr 99 18:43:15 From:owner-linux-kernel-digest@vger.rutgers.edu To:linux-kernel-digest@vger.rutgers.edu Subject:linux-kernel-digest V1 #3683 Reply-to:linux-kernel@vger.rutgers.edu Return-Path: Received:from mailsun2.us.oracle.com by usmail05 with SMTP (SMI-8.6/37.9) id SAA20819; Fri, 16 Apr 1999 18:42:50 -0700 Received:from inet16.us.oracle.com by mailsun2.us.oracle.com with ESMTP (SMI-8.6/37.8) id SAA28069; Fri, 16 Apr 1999 18:42:42 -0700 Received:from listserv.funet.fi (listserv.funet.fi [128.214.248.27]) by inet16.us.oracle.com (8.8.5/8.8.5) with ESMTP id SAA23706; Fri, 16 Apr 1999 18:42:47 -0700 (PDT) Received:from vger.rutgers.edu ([128.6.190.2]:53541 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]") by listserv.funet.fi with ESMTP id <8220-25681>; Sat, 17 Apr 1999 04:41:04 +0300 Received:by vger.rutgers.edu via listexpand id <161781-11366>; Fri, 16 Apr 1999 21:11:52 -0400 Received:by vger.rutgers.edu id <160769-11364>; Fri, 16 Apr 1999 21:11:23 -0400 Errors-To:owner-linux-kernel-digest@vger.rutgers.edu Precedence: bulk Message-Id:<19990417011144Z160769-11364+5589@vger.rutgers.edu> X-Orcpt:rfc822;linux-kernel-digest-outgoing MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" linux-kernel-digest Friday, 16 April 1999 Volume 01 : Number 3683 In this issue: Re: Lockups with Intel EtherExpress Pro 10/100 Return Message Re: bad lmbench numbers for mmap Re: bad lmbench numbers for mmap Re: updated proposal for cap in elf Re: bad lmbench numbers for mmap Re: bad lmbench numbers for mmap See the end of the digest for information on subscribing to the linux-kernel or linux-kernel-digest mailing lists. ---------------------------------------------------------------------- From: abob@dpd130.rh.psu.edu Date: Fri, 16 Apr 1999 20:55:37 -0400 (EDT) Subject: Re: Lockups with Intel EtherExpress Pro 10/100 > Situation: > The machine is crusing along with a load average of 0.01 and all of a > sudden one of the ethernet boards will lock up. I get this too sometimes (I can see the eepro100 card is sending, but not receiving on another machine). [cut kernel messages about eth0: Transmit timed out...] > The only way to reset the card is to reboot the machine. ifconfig eth0 down ; ifconfig eth0 up .... ; route add ... makes the card functional for me when it does this. > Linux 2.2.5 (root@rhdsdev) (gcc 2.7.2.3) #2 [rhdsdev.] > Linux 2.2.5 (root@ds6) (gcc 2.7.2.3) #5 SMP Tue Mar 30 08:06:24 CST 1999 both compiled with gcc 2.7.2.3, good :) > Both of these machines have had at least one lockup. I have 8 machines > with near identical setups. The lookups occur at about a rate of > 1 per week. What you might want to try is compile the kernel without Multicasting, it seems to have helped with my computer. (this seems to be a common problem with the eepro100's) - -- Daniel Drown Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: "orarepl" Date: 16 Apr 99 18:01:57 -0700 Subject: Return Message - --=_ORCL_27261906_0_0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" The included message could not be delivered to the following invalid mail names. Please verify these names and try them again. Bad name: hyin - --=_ORCL_27261906_0_0 Content-Type:message/rfc822 Date: 16 Apr 99 18:01:01 From:owner-linux-kernel-digest@vger.rutgers.edu To:linux-kernel-digest@vger.rutgers.edu Subject:linux-kernel-digest V1 #3682 Reply-to:linux-kernel@vger.rutgers.edu Return-Path: Received:from mailsun2.us.oracle.com by usmail05 with SMTP (SMI-8.6/37.9) id SAA11201; Fri, 16 Apr 1999 18:00:11 -0700 Received:from inet16.us.oracle.com by mailsun2.us.oracle.com with ESMTP (SMI-8.6/37.8) id SAA21002; Fri, 16 Apr 1999 18:00:04 -0700 Received:from listserv.funet.fi (listserv.funet.fi [128.214.248.27]) by inet16.us.oracle.com (8.8.5/8.8.5) with ESMTP id SAA13287; Fri, 16 Apr 1999 18:00:08 -0700 (PDT) Received:from vger.rutgers.edu ([128.6.190.2]:32809 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]") by listserv.funet.fi with ESMTP id <16998-26551>; Sat, 17 Apr 1999 03:57:27 +0300 Received:by vger.rutgers.edu via listexpand id <160313-11364>; Fri, 16 Apr 1999 20:33:10 -0400 Received:by vger.rutgers.edu id <160816-11366>; Fri, 16 Apr 1999 20:29:36 -0400 Errors-To:owner-linux-kernel-digest@vger.rutgers.edu Precedence: bulk Message-Id:<19990417003255Z160816-11366+5525@vger.rutgers.edu> X-Orcpt:rfc822;linux-kernel-digest-outgoing MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" linux-kernel-digest Friday, 16 April 1999 Volume 01 : Number 3682 In this issue: Re: Linux ping flood on localhost Re: caps in elf headers: use the sticky bit! Possible security hole? [was: verify_area(...) possible problem] Re: bad lmbench numbers for mmap Re: bad lmbench numbers for mmap Re: bad lmbench numbers for mmap Re: bad lmbench numbers for mmap Re: Module Question Re: bad lmbench numbers for mmap Re: bad lmbench numbers for mmap Return Message segfaults if HD is full Re: bad lmbench numbers for mmap mm/page_alloc.c low_on_memory variable. Re: Linux ping flood on localhost Re: Static Swap Re: bad lmbench numbers for mmap Re: 2.2.5 optimizations for web benchmarks? See the end of the digest for information on subscribing to the linux-kernel or linux-kernel-digest mailing lists. - ---------------------------------------------------------------------- From: "Richard B. Johnson" Date: Fri, 16 Apr 1999 18:36:05 -0400 (EDT) Subject: Re: Linux ping flood on localhost On Fri, 16 Apr 1999, Philip Blundell wrote: > >> The net-tools package does not include any `ping' program, let alone the > >> latest version. > > > >Wonder what this is? > > I've no idea, but it's not net-tools 1.50 (nor any other version that I > recognise). Or rather it is, but with some mysterious extra files. Where > did you get it? > Don't remember. It was pointed out, probably last December (that's the date on my directory) when I first complained about ping. Usually (too usually) when I say something doesn't work, somebody replies with "your tools are no good anymore" -- sometimes with a suggestion as to where to get new ones. The machines I have at work don't use "standard distributions". I get whatever someone tells me to get off the net. Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.2.5 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology. Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: Casey Schaufler Date: Fri, 16 Apr 1999 15:34:46 -0700 Subject: Re: caps in elf headers: use the sticky bit! David L. Parsley (lkml account) wrote: > Well, I certainly am not in favor of trying to hack capabilities to work > in a heterogenous environment. I see no reason why nfs can't be hacked so > that two Linux machines can use capabilities over nfs. As far as IRIX, > Linux 2.0 nfs servers, ... I just don't see this as an absolute necessity, > especially when it adds what I consider unneeded bloat and complexity to > our implementation. > > Of course, at least one gentleman from SGI has been very helpful in this > thread; Thanks, I think.... > perhaps IRIX will get patched for this. ;-) Well, I didn't really want to mention it, but we do have an extension to NFS3 which propogates arbitrary extended attributes which we use for ACLs, Capabilities, and MAC labels in Trusted Irix. So we don't have to patch *Irix* for a heterogenous environment. - - -- Casey Schaufler voice: (650) 933-1634 casey@sgi.com fax: (650) 933-0170 Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: Jamie Lokier Date: Sat, 17 Apr 1999 00:43:45 +0200 Subject: Possible security hole? [was: verify_area(...) possible problem] Andi Kleen wrote: > In theory not, because early i386 with broken supervisor write > protection checking depend on on verify_area/access_ok to actually > check the page tables. The page tables could change while you sleep. > > But, the concept is really broken, because e.g. when a user access > crosses two vm areas, and the user access faults (=sleeps) in the > first, and the goes on to write to the second, while that has been > already unmapped by another thread, it overwrites innoncent > memory. Andi, nice thinking. Can this (the current behaviour) be a security hole? I'm thinking that two cloned threads could, on an i386 with the broken WP protection: (a) read a file to hack to bring it into cache, e.g. /bin/su (b) does a shared writable mapping of some writable file that is not in cache (use your imagination) (c) thread #2 spins checking a flag (d) thread #1 writes the flag and then writes to the writable mapping (e) thread #1 blocks to pull in the page (f) thread #2 sees the flag and maps /bin/su into place (read only) (g) the page comes in though the mapping is no longer present (h) thread #1 unblocks and overwrites a page of /bin/su (i) run /bin/su, get root with no password check, H940R D00D2 R001 --> there isn't even any evidence on disk This will not happen if, when thread #1 blocks, the remapping is blocked by a lock. But I'm not sure, is it? I don't have an i386 to try it on. Enjoy, - - -- Jamie Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: David Miller Date: Fri, 16 Apr 1999 15:50:03 -0700 Subject: Re: bad lmbench numbers for mmap Date: Sat, 17 Apr 1999 01:34:18 +0530 (IST) From: V Ganesh I tried lmbench 1.9 on an ultra5 (270 MHz, 128 MB RAM) running linux 2.2.2 and compared with an identical machine running solaris 2.6(except it had 64M). linux blew solaris away in most of the benchmarks except mmap latency. ... so what's up with mmap ? There are two things which changed in the mmap/munmap code paths recently, and I know the numbers were competitive when I was running lmbench a lot several months ago. The two changes are: 1) Using VMA trees (I really don't think it accounts for the slowness being seen here) 2) The freeing up of page tables at munmap I think #2 could be a possible culprit. Linus, did you see any performance degration of lat_mmap when you added the free_pgtables() stuff into 2.2.x? I think such a problem would trigger if lat_mmap is doing large enough mmap's and they are in the right place. Mr Ganesh, can you post here the full lmbench raw output for the lat_mmap test? It should be in the results/sparc64-linux/xxxx files lmbench made as it ran. Later, David S. Miller davem@redhat.com Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: David Miller Date: Fri, 16 Apr 1999 15:58:26 -0700 Subject: Re: bad lmbench numbers for mmap Date: Sat, 17 Apr 1999 01:34:18 +0530 (IST) From: V Ganesh I tried lmbench 1.9 on an ultra5 (270 MHz, 128 MB RAM) running linux 2.2.2 and compared with an identical machine running solaris 2.6(except it had 64M). linux blew solaris away in most of the benchmarks except mmap latency. Wait a second, lat_mmap touches a large part of the set of pages in the mmap'd area. If the Solaris machine had half as much memory, and lat_mmap used a smaller upper limit on the size of the mmap'd area, then the difference in performance makes sense. If you have the opportunity, I'd rerun the tests with identical memory configurations on both systems. Later, David S. Miller davem@redhat.com Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: Jakub Jelinek Date: Sat, 17 Apr 1999 01:03:21 +0200 (CEST) Subject: Re: bad lmbench numbers for mmap > > so what's up with mmap ? Actually it seems like more than 90% of the time in this test is spent in munmap, particularly in filemap_sync. From quick looking at the sources, the only routine which changed there substantially is filemap_write_page, so it might well be because it waits for every dirtied page until it is stored to disk and in 2.1.103 did not do that. I'm too tired now to investigate further and actually think about it whether doing so is needed. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz Administrator of SunSITE Czech Republic, MFF, Charles University ___________________________________________________________________ UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/ Linux version 2.2.5 on a sparc64 machine (3958.37 BogoMips) ___________________________________________________________________ Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: V Ganesh Date: Sat, 17 Apr 1999 04:28:47 +0530 (IST) Subject: Re: bad lmbench numbers for mmap > From: David Miller [snip] > lat_mmap test? It should be in the results/sparc64-linux/xxxx files > lmbench made as it ran. here they are: "mappings 0.524288 677 1.048576 1193 2.097152 2189 4.194304 4379 8.388608 8993 16.777216 17745 33.554432 35039 I tried several runs and got very similar numbers. This is from the ultra5 running 2.2.2 and this is from the ultra5 running solaris 2.6 "mappings 0.524288 340 1.048576 526 2.097152 923 4.194304 1745 8.388608 4134 16.777216 9321 again, pretty repeatable. ganesh Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: Aaron Tiensivu Date: Fri, 16 Apr 1999 19:05:13 -0400 Subject: Re: Module Question On Fri, Apr 16, 1999 at 09:43:46AM +0200, Matthias Runge wrote: > Hello, > > maybe this is a newbe question, but I'd like to know, how > to find out, which module to choose to fix a message like this: > blah ... can't locate module ppp-compress-1 > or so. I'm not so interested to which module is attached, but > in the way to get it out. Predictor-1 compression module for ppp, not implemented yet. alias ppp-compress-1 off Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: David Miller Date: Fri, 16 Apr 1999 16:19:19 -0700 Subject: Re: bad lmbench numbers for mmap Date: Sat, 17 Apr 1999 04:38:41 +0530 (IST) From: V Ganesh I just posted the raw numbers and we are roughly twice as slow as solaris. At least it is consistant with the fact that the solaris run had to touch roughly half as much memory during the benchmark than Linux did. Unfortunately, the touching of memory in lat_mmap() drains away a lot of what it should be measuring (this I take part blame for as I was one of the people that suggested to Larry to make it do this). The problem is that we had to add this to avoid cases like Solaris where the mapping state is not created at all if the process does not touch any of the pages. By touching the pages this would better guarentee that both systems in question would have to set up (and later, tear down) the same amount of state in the kernel. But conversely, when the size of the area gets large, you begin to test the memory speed moreso than the raw mmap/munmap latency of the kernel. Later, David S. Miller davem@redhat.com Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: V Ganesh Date: Sat, 17 Apr 1999 04:38:41 +0530 (IST) Subject: Re: bad lmbench numbers for mmap > From: David Miller > > Wait a second, lat_mmap touches a large part of the set of pages in > the mmap'd area. If the Solaris machine had half as much memory, and > lat_mmap used a smaller upper limit on the size of the mmap'd area, > then the difference in performance makes sense. ouch. you're right of course. I was misled by the fact that the table just said "mmap latency". so it's not so horrible as I thought, but it's still pretty bad. I just posted the raw numbers and we are roughly twice as slow as solaris. ganesh Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: "orarepl" Date: 16 Apr 99 16:36:34 -0700 Subject: Return Message - - --=_ORCL_27260304_0_0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="us-ascii" The included message could not be delivered to the following invalid mail names. Please verify these names and try them again. Bad name: hyin - - --=_ORCL_27260304_0_0 Content-Type:message/rfc822 Date: 16 Apr 99 16:35:54 From:owner-linux-kernel-digest@vger.rutgers.edu To:linux-kernel-digest@vger.rutgers.edu Subject:linux-kernel-digest V1 #3681 Reply-to:linux-kernel@vger.rutgers.edu Return-Path: Received:from mailsun2.us.oracle.com by usmail05 with SMTP (SMI-8.6/37.9) id QAA15106; Fri, 16 Apr 1999 16:35:12 -0700 Received:from inet16.us.oracle.com by mailsun2.us.oracle.com with ESMTP (SMI-8.6/37.8) id QAA00710; Fri, 16 Apr 1999 16:35:05 -0700 Received:from listserv.funet.fi (listserv.funet.fi [128.214.248.27]) by inet16.us.oracle.com (8.8.5/8.8.5) with ESMTP id QAA12976; Fri, 16 Apr 1999 16:35:10 -0700 (PDT) Received:from vger.rutgers.edu ([128.6.190.2]:801 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]") by listserv.funet.fi with ESMTP id <15945-25681>; Sat, 17 Apr 1999 02:27:51 +0300 Received:by vger.rutgers.edu via listexpand id <160054-11364>; Fri, 16 Apr 1999 18:47:01 -0400 Received:by vger.rutgers.edu id <160329-11366>; Fri, 16 Apr 1999 18:42:51 -0400 Errors-To:owner-linux-kernel-digest@vger.rutgers.edu Precedence: bulk Message-Id:<19990416224654Z160329-11366+5425@vger.rutgers.edu> X-Orcpt:rfc822;linux-kernel-digest-outgoing X-MIME-Autoconverted:from 8bit to quoted-printable by inet16.us.oracle.com id QAA12976 MIME-Version: 1.0 Content-Type:text/plain; charset=unknown-8bit Content-Transfer-Encoding:quoted-printable linux-kernel-digest Friday, 16 April 1999 Volume 01 : Number 36= 81 In this issue: Re: scheduling policy of bottom halfs, task_queues and timers? Re: Solaris tmpfs vs. Linux RAMdisk bad lmbench numbers for mmap 2.2.5-ac7 Kernel panic... Re: bad lmbench numbers for mmap Re: caps in elf, next itteration (the hack get's bigger) Re: caps in elf headers: use the sticky bit! Re: Solaris tmpfs vs. Linux RAMdisk Re: caps in elf, next itteration (the hack get's bigger) Re: bad lmbench numbers for mmap Re: Weird PCI problem [CFT] FAT patch (beta) Re: caps in elf, next itteration (the hack get's bigger) Re: 2.2.5-ac6 breaks lp0? Re: caps in elf headers: use the sticky bit! Re: caps in elf headers: use the sticky bit! Re: Linux ping flood on localhost Re: Linux TCP Fixing everyones problems? WAS(Re: TCP push sometimes missing= under 2.2.5? Re: caps in elf headers: use the sticky bit! Re: Module Question Re: caps in elf headers: use the sticky bit! Re: bad lmbench numbers for mmap Re: Weird PCI problem Re: caps in elf headers: use the sticky bit! Re: Weird PCI problem Re: caps in elf headers: use the sticky bit! Re: Swap size proportion Re: Linux ping flood on localhost Re: caps in elf, next itteration (the hack get's bigger) Re: 2.2.5 optimizations for web benchmarks? Re: bad lmbench numbers for mmap Re: Swap size proportion fork failing for no obvious reason? Re: [PATCH] Capabilities, this time in elf section Re: Module Question Re: Swap size proportion See the end of the digest for information on subscribing to the linux-kernel or linux-kernel-digest mailing lists. - - ---------------------------------------------------------------------- From: Roger Gammans Date: Fri, 16 Apr 1999 19:43:01 +0100 Subject: Re: scheduling policy of bottom halfs, task_queues and timers? In article <199904152101.RAA19761@dcl>, tytso@MIT.EDU writes > Date: Tue, 13 Apr 1999 21:05:45 +0100 > From: Roger Gammans > > There is another irq to signal the end of the wait time, but obviously > with isr's or bh's being schedulable a wait_for_irq() is out of the > question. I presume other drivers have solved this problem.. it seems > rather nasty though to do it a chain of ISRs. > >You don't need to schedule a wait_for_irq(). >The trick is that you have to change how you think about the thread of >control. If you know you're going to get a second interrupt at the end >of the wait period, you can simply return from the first interrupt. Actually my context is a bit more complex, but not a lot. The trick I needed was to realise that the current context of the driver could include a function pointer, so we can do a callback on to higher level driver from the stub driver. TTFN - - - -- Roger Gammans Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Stephen C. Tweedie" Date: Fri, 16 Apr 1999 20:23:22 +0100 (BST) Subject: Re: Solaris tmpfs vs. Linux RAMdisk Hi, On Thu, 15 Apr 1999 23:08:54 -0700 (PDT), Jeremy Fitzhardinge said: > I got the impression that you were planning on making synchronous writes p= ut > data into the log, and thereby make it pretty fast compared to normal > synchronous writes. Is that still in the plan? Yes. That will definitely be there in v1. Sync writes (including data writes) will be logged straight to the journal with no seeks. This is primarily intended to speed up sync NFS servers. Of course, you will still need to write back the data to the main filesystem area, but that can be done asynchronously. Hopefully, journaling to a separate disk will also be present in v1, which will improve performance still further. Finally, it will support multiple filesystems sharing a single journal disk, but the error recovery semantics get really complex there so that mode will not necessarily be supported in the initial release. Cheers, Stephen Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: V Ganesh Date: Sat, 17 Apr 1999 01:34:18 +0530 (IST) Subject: bad lmbench numbers for mmap hi, I tried lmbench 1.9 on an ultra5 (270 MHz, 128 MB RAM) running linux 2.2.2 and compared with an identical machine running solaris 2.6(exce= pt it had 64M). linux blew solaris away in most of the benchmarks except mmap latency. File & VM system latencies in microseconds - smaller is better - - - -------------------------------------------------------------- Host OS 0K File 10K File Mmap Prot Page Create Delete Create Delete Latency Fault Fault - - - --------- ------------- ------ ------ ------ ------ ------- ----- -----= sparc64-l Linux 2.2.2 24 4 54 13 36488 4 1.9K - - - --------- ------------- ------ ------ ------ ------ ------- ----- -----= sparc-sun SunOS 5.6 480 598 4761 245 4912 21 15.6K and this on a P-II 450 running 2.2.5 - - - --------- ------------- ------ ------ ------ ------ ------- ----- -----= i686-linu Linux 2.2.5 15 1 27 2 11674 1 0.7K so what's up with mmap ? ganesh Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Brian Macy" Date: Fri, 16 Apr 1999 13:18:14 -0700 Subject: 2.2.5-ac7 Kernel panic... Kernel panic: SCSI DMA pool memory leak 31 32 This happened in the same second that the "scsi : 0 hosts." syslog message popped up. I have a BusLogic BT-958 SCSI card with all the SCSI stuff built as modules. I was repeatedly loading and unloading sg and the rest of the scsi stuff. Only the SCSI Tape Drive was being recognized on the buss (I think the scanner needed to be reset). Brian Macy Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Fri, 16 Apr 1999 22:15:35 +0100 (BST) Subject: Re: bad lmbench numbers for mmap > --------- ------------- ------ ------ ------ ------ ------- ----- -----= > sparc64-l Linux 2.2.2 24 4 54 13 36488 4 1.9K > > --------- ------------- ------ ------ ------ ------ ------- ----- -----= > sparc-sun SunOS 5.6 480 598 4761 245 4912 21 15.6K > > and this on a P-II 450 running 2.2.5 > --------- ------------- ------ ------ ------ ------ ------- ----- -----= > i686-linu Linux 2.2.5 15 1 27 2 11674 1 0.7K > > so what's up with mmap ? Redo the benchmark modified to use the mmaped object each iteration. Compare= =2E Ponder if one OS is delaying mmap setup Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "David L. Parsley (lkml account)" Date: Fri, 16 Apr 1999 16:34:40 -0400 (EDT) Subject: Re: caps in elf, next itteration (the hack get's bigger) On Fri, 16 Apr 1999, Theodore Y. Ts'o wrote: > Date: Fri, 16 Apr 1999 11:44:35 -0400 (EDT) > From: "David L. Parsley (lkml account)" > > Ok, I agree completely with this; I don't see any good use for fE, it > really doesn't enhance security; if someone can explain to me why it > might, I'd be interested (Ted?) > > fE is the rough equivalent of the setuid bit, except it's broken out by > capabilities. You still need it, because a non-privileged user may need > to execute a binary which has some privileges, but which does its own > access controls and authorization checks before doing some privileged > operation on behalf of the user. So fE is still absolutely needed. > Most of the programs which are setuid root today would have some kind of > non-zero fE mask. OK, I had to give this some thought, but I can certainly see it's usefulness (and don't want to take away flexibility); though I still say that for a cracker, the effective set is a non-issue. Feel free to stomp on this, but would you consider the addition of an fM to mask out further inheritance? (the whole 'inheritance' thing, while being very useful, is also very powerful and carries some serious security implications) What of my suggestion for compatibilty of the new cap-enable bit? cheers, David - - - - -- David L. Parsley Network Specialist City of Salem Schools Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: David Lang Date: Fri, 16 Apr 1999 13:27:23 -0700 (PDT) Subject: Re: caps in elf headers: use the sticky bit! - - - -----BEGIN PGP SIGNED MESSAGE----- The environment that this senerio would be most likly to be used in would not be using a Linux box for the NFS server, instead it would be using something like a Network appliance (or their higher end competitor, Auspecs or domwthing like that). These boxes run their own OS, have their own filesystem and are heavily tuned (raid for disks, large amounts of static ram to buffer writes to, etc). They are also not cheap, the one I am using at my web farm here runs ~$60,000. not having the ability to use any capabilities for files residing on this system would be a drawback. David Lang On Fri, 16 Apr 1999, David L. Parsley (lkml account) wrote: > > Well, I certainly am not in favor of trying to hack capabilities to work > in a heterogenous environment. I see no reason why nfs can't be hacked so > that two Linux machines can use capabilities over nfs. As far as IRIX, > Linux 2.0 nfs servers, ... I just don't see this as an absolute necessity, > especially when it adds what I consider unneeded bloat and complexity to > our implementation. > > Of course, at least one gentleman from SGI has been very helpful in this > thread; perhaps IRIX will get patched for this. ;-) > "If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy." - - - - -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA = '97) - - - -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNxedLT7msCGEppcbAQHhvQf/Ue62De3eGprO1YRO8wvCGW5Py9ETlzfO +oJovnyDpg5TWjGapI0ADpWv3iLcZy4Po0qqVYrqHsqq/ddE9w/UrsH9WcOkz7cn j5GueFWhdr/XZkjxYcGD3HPYUXfSqqCmTHoJ5YJfM+ti+z4j5mTpFdT5H1ohZkfv O5ZxlI+URqSv3440oR0Ogm0MBhxRv3vK3DWxXh7bAMMqofZNbNFuCtnKALCpCoOs c7sZdfD/I7Fryijn0/QfidRxJWSHyOx1e9D4/xGwFzTCsRC99XzIP41wdAyMDTdP UBJxmyC1V9IZ0gsYpoYo3uTgBjJMirI9W7hUgnOywiBlamSFOMhQMw=3D=3D =3DCxSc - - - -----END PGP SIGNATURE----- Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Walter Hofmann Date: Fri, 16 Apr 1999 21:46:09 +0200 (MEST) Subject: Re: Solaris tmpfs vs. Linux RAMdisk - - - -----BEGIN PGP SIGNED MESSAGE----- On Thu, 15 Apr 1999 owner-linux-kernel-digest@vger.rutgers.edu wrote: > PS: There is a bug in the benchmark program I posted yesterday. It should= be > using the tv_usec field to calculate microseconds instead of the tv_se= c > field. I reran the tests with this fix in and it does not make a > significant difference in the results. I get the following results: wh@frodo:~ > ./test /home/wh Did 14137 loops in 2.99 seconds (4724.35 loops/sec) wh@frodo:~ > ./test /tmp Did 15923 loops in 2.99 seconds (5322.36 loops/sec) wh@frodo:~ > ./test /usr/local/tmp Did 28783 loops in 3.00 seconds (9596.10 loops/sec) /home and /tmp are on the same ext2 partition (486M, 84% filled) /usr is an (soft-)raid0 array (4G, 81% filled, 2 disks) There is virtually no disk access during the test, the results are stable over many runs. Yet there is one big question: Why is the raid0-array twice as fast when there is no disk access??? Walter - - - -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBNxeThfzeA3/eVHOFAQHW+AQAsAVQcqyEDlVcZcCYta11Iw9jhXP5pbrP xlUjLyiCsf3kwq437dkPOZaw5iqZguLtzMWmHiDh95zkI6WNgxhT0IMv2PqAvDKc e+XnlHxPia3fTTx2PLY80u3iqNrC86yTd2+6a77sOoDSTgLUATYynAJb8xDeWnn/ rYos6QeCwQo=3D =3DrWUv - - - -----END PGP SIGNATURE----- Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Stephen C. Tweedie" Date: Fri, 16 Apr 1999 21:46:32 +0100 (BST) Subject: Re: caps in elf, next itteration (the hack get's bigger) Hi, On Thu, 15 Apr 1999 14:15:45 +0100 (BST), alan@lxorguk.ukuu.org.uk (Alan Cox) said: >> I thought the VMS security features posted here looked useful. >> VMS also has file record and transaction support. > This is seen as a bug by most OS designers. Not at all. First of all, it is kept outside the kernel: it is more like a library than anything else (although it _does_ run at a higher privilege level than user code). Secondly, in a clustered environment with shared-disk filesystems, having no OS-facility for reliably accessing shared data would be a critical omission. - - - --Stephen Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: V Ganesh Date: Sat, 17 Apr 1999 02:17:35 +0530 (IST) Subject: Re: bad lmbench numbers for mmap > > --------- ------------- ------ ------ ------ ------ ------- ----- ---= - - -- > > sparc-sun SunOS 5.6 480 598 4761 245 4912 21 15.= 6K > > > > and this on a P-II 450 running 2.2.5 > > --------- ------------- ------ ------ ------ ------ ------- ----- ---= - - -- > > i686-linu Linux 2.2.5 15 1 27 2 11674 1 0.= 7K > > > > so what's up with mmap ? > > Redo the benchmark modified to use the mmaped object each iteration. Compa= re. > Ponder if one OS is delaying mmap setup [from lat_mmap.c] where =3D mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); #endif if ((int)where =3D=3D -1) { perror("mmap"); exit(1); } if (random) { end =3D where + size; for (p =3D where; p < end; p +=3D STRIDE) { *p =3D c; } } else { end =3D where + (size / N); for (p =3D where; p < end; p +=3D PSIZE) { *p =3D c; } } munmap(where, size); } certainly seems to be touching the mmaped object. ganesh Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Stephen C. Tweedie" Date: Fri, 16 Apr 1999 21:53:34 +0100 (BST) Subject: Re: Weird PCI problem Hi, On Thu, 15 Apr 1999 11:14:36 -0700 (PDT), Linux Lists said: > I have a customer with a pretty weird problem. > - Kernel 2.0.36 (stock kernel, not RPM) > I/O at 0xe0310000. > ^^^^^^^^^^^^^^^^^ > , when it should be yelling: > Non-prefetchable 32 bit memory at 0xe0310000. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Any hints ??? First of all you could try looking at whether 2.2 shows the same information. By default, 2.2 interrogates PCI information directly instead of via the BIOS. - - - --Stephen Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Alexander Viro Date: Fri, 16 Apr 1999 16:49:27 -0400 (EDT) Subject: [CFT] FAT patch (beta) New version of FAT patch is out there. News: UMSDOS seems to be working with it now. sticky bit handling removed from UMSDOS (done in VFS since December). Matija's UMSDOS patch included. TODO: fat_get_entry() optimization (*badly* needed, since it's used more active than in old implementation). fat_readdir_x() cleanup (related to previous). real UMSDOS cleanup. internationalization stuff. UMSDOS still requires cleanup. This patch simply makes it work with the new FAT code and doesn't fix any bugs of UMSDOS proper. I consider this patch as beta. I.e. it's unlikely to let the magic smoke out of your disk, but don't try it on living filesystems. Help with testing is more than welcome. It definitely fixes a lot of bugs in FAT-derived stuff and seriously reduces the size of fs/msdos/* and fs/vfat/*. Patch (against 2.2.6-pre3) lives on ftp.math.psu.edu/pub/viro/fat-patch-11.gz Cheers, Al Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Stephen C. Tweedie" Date: Fri, 16 Apr 1999 21:48:16 +0100 (BST) Subject: Re: caps in elf, next itteration (the hack get's bigger) Hi, On 16 Apr 1999 11:52:11 +0200, Christian von Roques said: > Just a thought, > "Stephen C. Tweedie" writes: >> It is much more than that: it is to prevent privileges leaking, so >> that bugs in these daemons do not compromise the security of other >> parts of the OS. > Therefore there should be a privilege to exec(2), if there isn't > already, which most daemons should deny themselves. No, that's not necessary. The trick is that exec()ing a new process doesn't automatically transfer the current process's privileges to the new program. In a capabilities model, the exec() drops all currently held privileges unless the new program is specifically marked to be able to inherit certain privileges. - - - --Stephen Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Tim Waugh Date: Fri, 16 Apr 1999 21:35:27 +0100 (GMT) Subject: Re: 2.2.5-ac6 breaks lp0? On Fri, 16 Apr 1999, Nomad the Wanderer wrote: > Last kenernel was 2.2.3. (dont remember if I had any ac patches on it) Hi Robert, What's in /proc/parport/0/hardware? It would be useful if you could just confirm that 2.2.4 is the kernel that breaks, and clean 2.2.3 works. Thanks, Tim. */ Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Theodore Y. Ts'o" Date: Fri, 16 Apr 1999 16:58:15 -0400 (EDT) Subject: Re: caps in elf headers: use the sticky bit! Date: Fri, 16 Apr 1999 13:27:23 -0700 (PDT) From: David Lang The environment that this senerio would be most likly to be used in would not be using a Linux box for the NFS server, instead it would be using something like a Network appliance (or their higher end competitor, Auspecs or domwthing like that). These boxes run their own OS, have their own filesystem and are heavily tuned (raid for disks, large amounts of static ram to buffer writes to, etc). They are also not cheap, the one I am using at my web farm here runs ~$60,000. not having the ability to use any capabilities for files residing on this system would be a drawback. Why? Put your all of your data files on the central NFS server. Put all of your executables (which for a web farm should be a *very* small number of files) on local disk. Simple, and secure. For bonus points, if what you need is something so simple, stupid that even a manager can maintain it, write a script which copies the executables from the NFS server, verifies their MD5 checksums, and finally verifies the PGP signature on the MD5 checksum file. Then have that script set any necessary capabilities on the freshly copied executables on your machine. There! Now it's even easy to administer. And still secure. - Ted Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: David Lang Date: Fri, 16 Apr 1999 13:57:25 -0700 (PDT) Subject: Re: caps in elf headers: use the sticky bit! - - - -----BEGIN PGP SIGNED MESSAGE----- I agree it is possible, I disagree that it should be nessasary. For E-commerce sites you will find that the number of cgi's can end up much larget than you would expect from normal web site statistics. I will let this drop now as it appears that this is not going to be an option. David Lang On Fri, 16 Apr 1999, Theodore Y. Ts'o wrote: > > Date: Fri, 16 Apr 1999 13:27:23 -0700 (PDT) > From: David Lang > > The environment that this senerio would be most likly to be used in wou= ld > not be using a Linux box for the NFS server, instead it would be using > something like a Network appliance (or their higher end competitor, > Auspecs or domwthing like that). These boxes run their own OS, have the= ir > own filesystem and are heavily tuned (raid for disks, large amounts of > static ram to buffer writes to, etc). They are also not cheap, the one = I > am using at my web farm here runs ~$60,000. not having the ability to u= se > any capabilities for files residing on this system would be a drawback. > > Why? Put your all of your data files on the central NFS server. > > Put all of your executables (which for a web farm should be a *very* > small number of files) on local disk. Simple, and secure. > > For bonus points, if what you need is something so simple, stupid that > even a manager can maintain it, write a script which copies the > executables from the NFS server, verifies their MD5 checksums, and > finally verifies the PGP signature on the MD5 checksum file. Then have > that script set any necessary capabilities on the freshly copied > executables on your machine. There! Now it's even easy to administer. > And still secure. > > - Ted > > "If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy." - - - - -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA = '97) - - - -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNxekNz7msCGEppcbAQGuygf+N+Z76Hqudri+/nKucNBdo9mH1/lgbyYz 9INKKSnIymBQDb0WoKq8IFXEgHd6haDwXPk5C038FWH3PHxQ8vt38/KWWg4f8fR3 JKazlXZBPI++S/WSzznUlfIBsalPktFMaa62Z2p2djVWNP5++SdMwBI1/folKYlZ eUEHIi5kHnLLn5FcqYDc5Zkbrhdd+36Ge+bd/aRkOv0C2prThSrnTKZA4ma3bxaZ lGg0gmDfq50PhoGc0frR1gBecA5Cbl45LP2/QkxQY/E6Jl6feZefs4RYhYcG5GKd ALB1QKAK56lr4n3fYTp4tv73eF7UfF6u1YncDHK6tgAPVopMrdqGGA=3D=3D =3DQlv9 - - - -----END PGP SIGNATURE----- Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Richard B. Johnson" Date: Fri, 16 Apr 1999 17:05:17 -0400 (EDT) Subject: Re: Linux ping flood on localhost On Fri, 16 Apr 1999, Philip Blundell wrote: > >Well it certainly does not work that way on my system and I use > >the so-called latest ping from net-tools-1.50.tar.gz. Over six > > The net-tools package does not include any `ping' program, let alone the > latest version. > > p. Wonder what this is? Script started on Fri Apr 16 17:03:28 1999 # ls COPYING arp.c hostname.o lib rarp.c statistics.c ChangeLog arp.o ifconfig man rarp.o statistics.o INSTALLING config.h ifconfig.c netstat route typescript Makefile config.in ifconfig.o netstat.c route.c version.h README config.status include netstat.o route.o README.ipv6 configure.sh interface.c nls sockets.c TODO hostname interface.h ping sockets.h arp hostname.c interface.o rarp sockets.o # exit Script done on Fri Apr 16 17:03:36 1999 Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.2.5 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology. Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Stephen C. Tweedie" Date: Fri, 16 Apr 1999 22:00:39 +0100 (BST) Subject: Re: Linux TCP Fixing everyones problems? WAS(Re: TCP push sometimes= missing under 2.2.5? Hi, On Wed, 14 Apr 1999 08:40:29 -0400 (EDT), Geof Goodrum said: > Realizing that this is a bit of a headache for the kernel maintainers, > but why isn't anyone else suggesting options in the kernel config? I > believe that the compatibility patches should be included in the > kernel by default, but could be deselected during a custom kernel > config. Can you _imagine_ the pain of maintaining multiple different incompatible sets of tcp behaviour in the kernel? It's a crazy idea. > Our site uses FTP Software's PC/TCP suite, and until the problems in that > suite were fixed, I always compiled in the compatibility option included > in the kernel. The world has an internet now. It really doesn't make much sense to compile kernels which have problems talking to certain types of machine, since as soon as you are on the net it's only a matter of time before you meet one of them. - - - --Stephen Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Theodore Y. Ts'o" Date: Fri, 16 Apr 1999 17:25:43 -0400 (EDT) Subject: Re: caps in elf headers: use the sticky bit! Date: Fri, 16 Apr 1999 13:57:25 -0700 (PDT) From: David Lang X-Sender: dlang@dlang I agree it is possible, I disagree that it should be nessasary. For E-commerce sites you will find that the number of cgi's can end up much larget than you would expect from normal web site statistics. I will let this drop now as it appears that this is not going to be an option. Perl CGI's aren't exectables, and get executed by mod_perl. If you have real CGI progams which are written in C, then sure --- but usually most web machines don't have that many custom CGI programs written in C. They're using written in Perl, or using Java Servlets, or some other mechanism. I repeat --- the number of actual ELF executables on a web farm is probably a very small number. - Ted Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Dag Wieers Date: Fri, 16 Apr 1999 22:22:40 +0200 (CEST) Subject: Re: Module Question On Fri, 16 Apr 1999, Matthias Runge wrote: > maybe this is a newbe question, but I'd like to know, how > to find out, which module to choose to fix a message like this: > blah ... can't locate module ppp-compress-1 > or so. I'm not so interested to which module is attached, but > in the way to get it out. well, look at /usr/include/linux/ppp-comp.h you'll see : #define CI_PREDICTOR_1 1 /* config option for Predictor-1 */ #define CI_PREDICTOR_2 2 /* config option for Predictor-2 */ #define CI_BSD_COMPRESS 21 /* config. option for BSD-Compress *= / #define CI_DEFLATE 24 /* config option for Deflate */ thus /etc/conf.modules might contain: alias ppp-compress-21 bsd_comp alias ppp-compress-24 ppp_deflate i don't know what ppp-compress-1 stands for exactly. so i would put it off to turn off the messages (maybe someone could explain ?) alias ppp-compress-1 off the same goes for net-pf-3, in /usr/include/socketbits.h #define PF_AX25 3 /* Amateur Radio AX.25. */ #define PF_IPX 4 /* Novell Internet Protocol. */ #define PF_APPLETALK 5 /* Don't use this. */ and in /etc/conf.modules alias net-pf-3 off alias net-pf-4 off alias net-pf-5 appletalk - - - -- dag wieers, , http://dag.life.be/ _| _ _ for life is quite absurd, (_|(_|(_| and death's the final word. -- Monty Python | Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "David L. Parsley (lkml account)" Date: Fri, 16 Apr 1999 17:34:49 -0400 (EDT) Subject: Re: caps in elf headers: use the sticky bit! Hi David, On Fri, 16 Apr 1999, David Lang wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > The environment that this senerio would be most likly to be used in would > not be using a Linux box for the NFS server, instead it would be using > something like a Network appliance (or their higher end competitor, > Auspecs or domwthing like that). These boxes run their own OS, have their > own filesystem and are heavily tuned (raid for disks, large amounts of > static ram to buffer writes to, etc). They are also not cheap, the one I > am using at my web farm here runs ~$60,000. not having the ability to use > any capabilities for files residing on this system would be a drawback. Well, as much as I hate to suggest it again, you _could_ hack the nfs client to honor sticky as cap-enabled, but only if you can exercise total filesystem security. I only like the sticky bit for compatibility reasons, because currently it has no other interpretation. I still disdain setuid root, because both the setuid bit and the uid already serve another purpose. I reallize this information can be duplicated in the headers, but I just don't like it. cheers, David - - - - -- David L. Parsley Network Specialist City of Salem Schools Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Jakub Jelinek Date: Fri, 16 Apr 1999 23:35:02 +0200 (CEST) Subject: Re: bad lmbench numbers for mmap > hi, > I tried lmbench 1.9 on an ultra5 (270 MHz, 128 MB RAM) running > linux 2.2.2 and compared with an identical machine running solaris 2.6(ex= cept > it had 64M). linux blew solaris away in most of the benchmarks except mmap > latency. Actually, all the numbers are horribly bad on the ultra. I haven't run lmbench for a while, and I see it was a mistake. The mmap is clearly very bad, especially when 2.1.103 kernel on 167 MHz Ultra had mmap latency of 1505usec. I'll check what's going on. Anyway, we have a couple of new things prepared for sparc64 for 2.3 once that gets opened, so the numbers might actually get better again. BTW: So that I have good comparisons, can you please send me full benchmark numbers (best the results/ files) from your 450PII and ultra5/Solaris, preferably using ftp://ftp.bitmover.com/lmbench/lmbench-2alpha11.tgz ? Thanks. Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz Administrator of SunSITE Czech Republic, MFF, Charles University ___________________________________________________________________ UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/ Linux version 2.2.5 on a sparc64 machine (3958.37 BogoMips) ___________________________________________________________________ Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Gerard Roudier Date: Fri, 16 Apr 1999 23:52:40 +0200 (MET DST) Subject: Re: Weird PCI problem On Fri, 16 Apr 1999, Linux Lists wrote: > On Thu, 15 Apr 1999, Gerard Roudier wrote: > > > > A PCI base address register that maps I/O space must have bit 0 > > _hardwired_ to 1 by the device. The same way, bit 0 must be hardwired to= 0 > > for base address registers that map into memory space. > > Ok, I don't know whether this "hardwires" these bits inside our PCI > bridge (which is from PLX), but the EEPROM on the board programs the PCI > bridge to request a 32-bit non-prefetchable memory address from the > system. I think that if the system BIOS / O.S. are operating properly, > this should be enough in order to get that register programmed correctly > as requested. We can imagine that this bit is writable, but set to 0 on reset and then the PCI BIOS will consider the device needs a memory mapped window, and, for obscure reasons, this bit has just been written to 1 by some other piece of code. (Just some guessing perhaps quite wrong). Anyway, the PCI specs 2.1 says that this bit must be hardwired. > > It is indeed quite weird to read 1 as bit 0 from a register that should > > have bit 0 hardwired to 0. > > Really weird. > > > Could it be possible that bit 0 is just writable for this base address > > register. > > I don't think this is the case, because the address asginment works > correctly in other systems, and even in the same system, yet in a > different OS (DOS in this case). Without problem consistency within OS's, > I wouldn't point the problem to the hardware. > > > You can verify that by hacking appropriately the Cyclades driver > > in its detection routine. You may try for example: > > > > - Read the value of the offending base address reg. and save it. > > - Write 1 to that base address reg., then read it and print the value. > > - Write 0 to that base address, then read it and print the value. > > - Restore the value of that base address. > > I can't do that right now, as: > > - this is a customer's production server; > - the problem _only_ happens on that system; How much are you sure that other systems, that donnot have this problem, use same pieces of hardware of same revision? > > Note that if bit 0 is writable, the device may just be bogus and not > > conformant to PCI specs, but it could be trivial to work around the > > problem. > > So, do you think that if I _force_ that bit to be 0 by inserting the If you can do that, then, I will recommend you to do at least: - - - - Read this base address register - - - - Warn if any of bit 1, 2 or 3 is set. - - - - Mask all the bits that should have read zero (bit 0,1,2,3) - - - - Rewrite this base address register - - - - Read it again and warn if any bit 0, 1, 2 or 3 is still set. > appropriate code in the driver, it would make everything work ?? My > question is: wouldn't this affect other parts of the system that have > detected that address as an I/O address before ?!?!? If not, the solution, Normally, only the device driver has to access the device. > although "dirty", is really trivial. The fact is that I always thought > that these PCI base register contents should (must) NOT be changed > manually. Normally, the PCI BIOS must have assigned to PCI devices all needed resources prior to allowing to boot the machine. So, we should never need to change any of the base address registers at boot. :) What you may want to check could be that the resulted memory mapped window after the fix-up of bit 0 is not already allocated to another device, or maps real memory. Regards, G=E9rard. Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: David Lang Date: Fri, 16 Apr 1999 14:35:10 -0700 (PDT) Subject: Re: caps in elf headers: use the sticky bit! - - - -----BEGIN PGP SIGNED MESSAGE----- The suggestion that was made to allow different implementations of the "capabilitys exist for this file" bit for different filesystems sounded like it was on the right track, it allows for filesystem support where it is feasable, and allows for workarounds to be implemented for other filesystems without having to change the entire filesystem. When the NFS client is modified to use the sticky bit as the caps bit it should get the squash_sticky default as well. That keeps things secure by default but allows for exceptions to be made as the administrators of a particular site deem it nessasary. David Lang On Fri, 16 Apr 1999, David L. Parsley (lkml account) wrote: > > Well, as much as I hate to suggest it again, you _could_ hack the nfs > client to honor sticky as cap-enabled, but only if you can exercise total > filesystem security. I only like the sticky bit for compatibility > reasons, because currently it has no other interpretation. I still > disdain setuid root, because both the setuid bit and the uid already serve > another purpose. I reallize this information can be duplicated in the > headers, but I just don't like it. > > cheers, > David > > - -- > David L. Parsley > Network Specialist > City of Salem Schools > > > "If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy." - - - - -Paul Evans (as quoted by Barb Dijker in "Managing Support Staff", LISA = '97) - - - -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNxetEj7msCGEppcbAQGbCAgAv//saSsBYhk0CBi1cW6vsEFip1DzK9vJ 2GegGnZ1J3ASkzkhNZbKjkkqS/++2KjxmzekSceX99Xe1d+WW2JPabu4O5uJ8gYb on4RyasMSSaMMGiovgLVJ2yCjWlQ0KR4AFPPsiNz1kQ0MdnUWTaHVTHNTANX0bPY Fw978Oe46WMl0LxMSTawLd1k/XwRHQu51wyBd60unvwmUB7r37gtVMx1uIVtalhM wgZ61dlKYlQNMMv0mZCVAf5PUMbkJyJ1lhxPrMsaAW6/ZqECbGuH3vtqBlVbwgL9 ZjVNZ4UvMXK787C4EfzuhW0bMLtoZXxdUxWA+9hr8Y56TpnZCv0tWQ=3D=3D =3DyHZL - - - -----END PGP SIGNATURE----- Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Linux Lists Date: Fri, 16 Apr 1999 14:49:10 -0700 (PDT) Subject: Re: Weird PCI problem On Thu, 15 Apr 1999, Gerard Roudier wrote: > > Could it be possible that bit 0 is just writable for this base address > register. You can verify that by hacking appropriately the Cyclades driver > in its detection routine. You may try for example: > > - Read the value of the offending base address reg. and save it. > - Write 1 to that base address reg., then read it and print the value. > - Write 0 to that base address, then read it and print the value. > - Restore the value of that base address. Ok, did that in a machine where the Cyclom-Y board is assigned the proper address (i.e., the address type it has requested): - - - - Before: pcibios_read_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, (unsigned int *) &cy_pci_addr2); - - - - After: pcibios_read_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, (unsigned int *) &cy_pci_addr2); printk("got 0x%lx ; ", cy_pci_addr2); cy_pci_addr_tmp =3D cy_pci_addr2; cy_pci_addr2 |=3D 0x01; pcibios_write_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, cy_pci_addr2); printk("wrote 0x%lx ; ", cy_pci_addr2); pcibios_read_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, (unsigned int *) &cy_pci_addr2); printk("got 0x%lx\n", cy_pci_addr2); cy_pci_addr2 =3D 0xffffffff; pcibios_write_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, cy_pci_addr2); printk("wrote 0x%lx ; ", cy_pci_addr2); pcibios_read_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, (unsigned int *) &cy_pci_addr2); printk("got 0x%lx\n", cy_pci_addr2); pcibios_write_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, cy_pci_addr_tmp); pcibios_read_config_dword(cyy_bus, cyy_dev_fn, PCI_BASE_ADDRESS_2, (unsigned int *) &cy_pci_addr2); Results: Cyclades driver 2.1.2.1 1999/04/08 16:17:18 built Apr 16 1999 14:52:03 got 0xe0310000 ; wrote 0xe0310001 ; got 0xe0310000 wrote 0xffffffff ; got 0xffffc000 Cyclom-Y/PCI #1: 0x2e88000-0x2e8bfff, IRQ15, 16 channels starting from port 0. That has shown that, at least by using the Linux kernel PCI interface commands (pcibios_read/write_config), I'm not able to change that bit. Furthermore, it has shown that I can't write to the last 14 bits [13-0] of the base address register. Again, this was done in a machine where the Cyclom-Y board is assigned the proper address (i.e., the address type it has requested). Do you think that this test would yell a different result if run on the "deffective" system ?? Regards, Ivan Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "David L. Parsley (lkml account)" Date: Fri, 16 Apr 1999 17:55:09 -0400 (EDT) Subject: Re: caps in elf headers: use the sticky bit! Hi David, On Fri, 16 Apr 1999, David Lang wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > The suggestion that was made to allow different implementations of the > "capabilitys exist for this file" bit for different filesystems sounded > like it was on the right track, it allows for filesystem support where it > is feasable, and allows for workarounds to be implemented for other > filesystems without having to change the entire filesystem. Yes, and this sticky bit is a good candidate because it's so well supported and so useless otherwise. ;-) > When the NFS > client is modified to use the sticky bit as the caps bit it should get the > squash_sticky default as well. Most definitely. I'd be surprised, though, if the idea doesn't draw a few screams. ;-) cheers, David - - - - -- David L. Parsley Network Specialist City of Salem Schools Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Matthew Vanecek Date: Fri, 16 Apr 1999 17:00:50 -0500 (CDT) Subject: Re: Swap size proportion On 16 Apr, none spewed forth: :: :: HI * , :: :: What are the proportion of swap size for RAM size ? :: ex. I have 128 mb RAM, what are the best size of my partiiion/file swa= p ? :: :: Tanks :: This would be a better question for a newsgroup, but in answer... Whatever you need. Depends on your machine, your applications, etc. Try searching dejanews or Usenet for more info. - - - -- Matthew Vanecek Course of Study: http://www.unt.edu/bcis Visit my Website at http://people.unt.edu/~mev0003 For answers type: perl -e 'print $i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)= - - -2),oct(115),10);' ***************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Philip Blundell Date: Fri, 16 Apr 1999 22:52:51 +0100 Subject: Re: Linux ping flood on localhost >> The net-tools package does not include any `ping' program, let alone the >> latest version. > >Wonder what this is? I've no idea, but it's not net-tools 1.50 (nor any other version that I recognise). Or rather it is, but with some mysterious extra files. Where did you get it? p. Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Casey Schaufler Date: Fri, 16 Apr 1999 15:05:53 -0700 Subject: Re: caps in elf, next itteration (the hack get's bigger) Andrej Presern wrote: > The problem with this scheme is that one needs to attach the whole list of > privileges to each and every program, even though only one or two of the > privileges may be required by most of them. Since such a list takes up spa= ce, > and this space is multiplied by the number of programs in the system, ther= e > cannot be an unlimited number of privileges in the list, forcing the designer > to choose between fine grain security and efficient use of space. Worrying over space required to maintain capability sets is silly. At 24 bytes a pop (on Irix) that just isn't an issue. The choice of capability granularity is a sigificant issue. On Irix there are about 40. On DG/UX there are 330. Me, I prefer a set that I can deal with. > Since each > capability in the list enables a single and specific privilege, one would, > conceptually, need an infinite list of capabilities to have arbitrarily fi= ne > grain security which is needed to be able to really obey the principle of = least > authority This will depend on how you choose to map your capabilities to your security policy. For example, you could choose to map stime(2) and adjtime(2) to a single capability or give each their own. On Irix, capabilities are mapped to the policy (e.g. MAC, DAC) enforced, without regard to the type of object (e.g. file, message queue). On Trusted Solaris I've been told (I'm not 100% sure I have this right) they have a seperate capability for each (e.g. file MAC, message queue DAC). In any case, the granularity of capability ought to reflect the system security policy in some coherant way. > That is of course not feasible in any real system. It's not so much that it's infeasible as it's unnecessary and misses a significant point WRT system security policy, which is that there ought to some reason to it. > One might want to circumvent the problem by not storing individual privile= ges > in an array but organizing them into a linked list instead, allowing one t= o > drop the disabled capabilities from the list and only keep the active ones= =2E To date bitmasks have proven sufficient. > With this strategy however one still faces the efficiency problem as the l= inked > list needs to be searched for any required capabilities, and it needs to b= e > searched every time the access control comes to play, which may with a lon= ger > list and strict access control again result in substantial decrease in > efficiency of the system. The remedy is the same as before: a compromise > between security and efficiency, meaning you fail to obey the principle of > least authority again. This has not proven to be a problem in real implementations. > There are other important issues that designers who want to use capability > lists need to resolve, such as how to cut the total authority into individ= ual > privileges for example. Again, this is strait forward, if not simple or painless. One decides the capabilities based on: 1. Desired system security policy 2. Where you have calls to suser() in the kernel. 2a. Where you have those Baaaaad euid =3D=3D 0 checks. > As for POSIX privileges, a specific design based on capability lists, it > contains a number of design failures besides the obvious disadvantages of > capability lists. I don't believe that you've made a compelling case for the disadvantages of capability lists, as noted above. > For example, the POSIX privileges concept makes a distinction > between the permitted and the effective set of capabilities. In security > reality however, there is no 'permitted' set, only the set of effective > capabilities. When a capability is a single system call away (that can be = taken > by the process anytime and from any point), marginal security gained by > 'turning off' a capability in the 'effective' set but leaving it 'on' in t= he > 'permitted' set is exactly zero, making the set of permitted capabilities > effectively the set of effective capabilities. In other words, your proces= s is > either able to do something, or not able to do something - an extra syscal= l or > two makes no difference. In this, we disagree. In a world where all programs are coded correctly (see TCSEC A1 requirements) you might have a point. However, even good programs somethimes do things they oughtn't. The principle of least privilege has a time axis; there is a very real distinction between having a gun and having a loaded gun. > Furthermore, the POSIX privileges contain the third set of capabilities, t= he > inheritable set, which is also a design failure as it makes the design to = fail > to contain the damage in case of a buggy privileged binary. Once a privile= ged > binary is broken into (for example at runtime by means of a stack overrun)= , it > can be made to spawn an arbitrary child (such as a shell for example) that= will > inherit the authority of a buggy parent, thus enabling an attacker to gain > unauthorized access in a useful form (a shell for example). Because you ne= ver > know how the inherited authority will be used, inheriting authority in a > computer system is just as bad as when a stupid prince inherits the throne= of > a great king. The purpose of the inheritable bits is to allow a program to be set up so that it can NOT have a capability (by leaving it out of the inheritable set on the binary). > There are probably many more issues about POSIX privileges, such as where = to > store them, how to manage and delegate them etc There are several ways to store them, many of which have been discussed (at length!) here. Manageing and delegating them are easy. > As I said above, I would not like to speculate whether POSIX privileges wo= uld > bring an improvement in security or not as that depends very much on the > implementation details. From a designer's point of view, they are inadequa= te > and broken and will in combination with existing subsystems lead to furthe= r > extensions and ad hoc solutions to solve the security problem. Having been involved in the design of the POSIX capabilities, and having implemented them on a real commercial system, I believe your stated opinions to be unfounded. I believe that I have sufficient evidence to refute the bulk of your claims, and that many of your assertions are based on insuffient information. In short, POSIX capabilities are completely implementable. - - - -- Casey Schaufler voice: (650) 933-1634 casey@sgi.com fax: (650) 933-0170 Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Rik van Riel Date: Fri, 16 Apr 1999 23:04:03 +0200 (CEST) Subject: Re: 2.2.5 optimizations for web benchmarks? On Fri, 16 Apr 1999, Cacophonix Gaul wrote: > I'd like some help with optimizing linux (and apache) > for a web benchmark. I understand many of the tunables > in /proc/sys, I've recently updated the documentation for the sysctl files: http://www.nl.linux.org/~riel/patches/ > What should I change at 2.2.5 compile time? If you want to do an honest benchmark, you should (IMHO) compile a mostly vanilla kernel... > Does anyone have any empirical ideas about > _specific_ values that would work well for: > inode-max Large, really large (like, 8192 or slightly above that) > bdflush Set a low number of max dirty percentage and high syncing times... > buffermem > pagecache Forget these two files, they really don't do much anymore (or need to, with the new algorithms). > freepages > kswapd Leave at standard value. > Any other I'm missing ? If you plan on going into swap, set page-cluster to 5; if you do a lot of fork()s / exit()s, set pagetable_cache to something higher... > I'm using many of the common apache 1.4.3 > optimizations. Is there anything I can do to improve > SMP performance, to help the built in affinity-scheme > of linux? If you're running with 50+ apache processes, processor affininity isn't going to buy you much. Better make sure that each Apache child can serve a lot of processes. And don't do reverse IP lookups with the standard named :) > The benchmark itself is specweb96, so the files are > distributed over a large range of sizes. I expect to > see 10K-20K simultaneous active connections. 10k active connections? Have you found a way to run this many processes simultaneously? (is it included in the kernel and did I miss that event or isn't it integrated yet?) Rik -- Open Source: you deserve to be in control of your data. +-------------------------------------------------------------------+ | Le Reseau netwerksystemen BV: http://www.reseau.nl/ | | Linux Memory Management site: http://humbolt.geo.uu.nl/Linux-MM/ | | Nederlandse Linux documentatie: http://www.nl.linux.org/ | +-------------------------------------------------------------------+ Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: V Ganesh Date: Sat, 17 Apr 1999 03:36:17 +0530 (IST) Subject: Re: bad lmbench numbers for mmap > From: Jakub Jelinek [snip] > lmbench for a while, and I see it was a mistake. The mmap is clearly very > bad, especially when 2.1.103 kernel on 167 MHz Ultra had mmap latency of > 1505usec. I'll check what's going on. Anyway, we have a couple of new thin= gs I don't think it's an ultra-specific problem then. if you could get 1505 out of a 167 MHz Ultra surely a 450 Mhz P2 must be much better. at any rate it can't be as bad as 11600 which is the best I've got so far. something must have changed in the generic mm layer. (I'll mail you my results later). ganesh Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Brandon S. Allbery KF8NH" Date: Fri, 16 Apr 1999 18:11:13 -0400 Subject: Re: Swap size proportion Please set a valid email address. In message , "none" writes: +----- | What are the proportion of swap size for RAM size ? | ex. I have 128 mb RAM, what are the best size of my partiiion/file swap= ? +--->8 There is no single answer. A very rough first approximation that works well in many settings is 1.5 * memory size --- but the "best" value depends on what you're doing with the system and what kind of load it gets. A dedicate= d NFS server, for instance, doesn't need much (if any) swap, whereas a databas= e server with many users can need quite a bit of swap unless the database fits completely in memory. - - - -- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu carnegie mellon / electrical and computer engineering KF8NH We are Linux. Resistance is an indication that you missed the point. Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Tim Smith Date: Fri, 16 Apr 1999 15:17:06 -0700 (PDT) Subject: fork failing for no obvious reason? Hi; I've got 2.2.4 SMP with two CPUs running a fairly busy web server, and I'm running into an odd problem. When the total number of processes on the system gets above around 170, non-root can no longer fork. Errno is set to EAGAIN. The per-user process limit is 256, so obviously no one is near that limit. From root, I can fork to my heart's content--I have no trouble starting up 40 or 50 root shells (that's not a limit--I get tired of typing "sh" after that many). I've got half a gig of RAM, with about 400 meg free if buffers are subtracted out, so I don't seem to be running out of memory. Anyone have any suggestions as to what resource I need more of? - - - --Tim Smith Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Richard Gooch Date: Sat, 17 Apr 1999 08:40:11 +1000 Subject: Re: [PATCH] Capabilities, this time in elf section Horst von Brand writes: > Richard Gooch said: > > [...] > > > I'm not necessarily advocating "capabilities light". I'm definately > > advocating a "capabilities practical" scheme, which obviously includes > > NFS and similar support. > > I would love that, iff such a scheme does not (a) preclude "capabilities > full", and (b) it doesn't add potential unwanted interactions with > capabilities in metadata (its the _only_ reasonable place for them anyway) > or random careless setups. > > I'm not convinced that the overloading of bits + keeping metadata in the > executable file is at all secure (b), and I worry about (a). I think your worries are unfounded. > > In addition, my scheme gives you a pretty flexible system for > > increasing security on non-caps kernels. You can easily set things up > > so that when root runs another binary, the uid and euid are set to > > nobody, if that binary has no capability header, or doesn't have any > > inheritable caps set. The only thing you can't control is statically > > linked binaries without the magic code. But if you're setting up a > > secure system, you'd relink those anyway. > > That looks like a lot more work than a simple "setcaps ..." on the > affected executables. Plus you _can't_ do it with your propietary > database which you need to trust for raw access to partition > /dev/foo... and all to be able to smuggle capabilities behind the > system's back via tar(1) et al? Where (with the inmutable bit) the > whole idea of being able to use the existing tools transparently is > long lost anyway? Your proprietary database programme doesn't need any privs: make the raw device file owned by "database" and run the database under that account. There's no reason the device file has to be owned by root. And your use of the term "smuggling capabilities" is false, misleading and emotive. The correct term is "preserve capabilities", as that is the intent of the sysadmin. The term "going behind the systems back" is also false, misleading and emotive. Rather, the system is duly performing the tasks required of it by the sysadmin. Regards, Richard.... Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: "Richard B. Johnson" Date: Fri, 16 Apr 1999 18:28:20 -0400 (EDT) Subject: Re: Module Question On Fri, 16 Apr 1999, Dag Wieers wrote: > On Fri, 16 Apr 1999, Matthias Runge wrote: > > > maybe this is a newbe question, but I'd like to know, how > > to find out, which module to choose to fix a message like this: > > blah ... can't locate module ppp-compress-1 execute modprobe -c Put the results (not all, look at what you are doing) in /etc/conf.modules Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.2.5 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology. Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ From: Alec Smith Date: Fri, 16 Apr 1999 18:38:25 -0400 (EDT) Subject: Re: Swap size proportion Usual figure is 2x RAM -- so 256MB. HOWEVER, kernel 2.0.x and the old fdisk/swapon/swapoff/etc utils only handle 128MB per swap partition. To use more get kernel 2.2.x and the latest utilities. On Fri, 16 Apr 1999, Matthew Vanecek wrote: > On 16 Apr, none spewed forth: > :: > :: HI * , > :: > :: What are the proportion of swap size for RAM size ? > :: ex. I have 128 mb RAM, what are the best size of my partiiion/file s= wap ? > :: > :: Tanks > :: > > This would be a better question for a newsgroup, but in answer... > Whatever you need. Depends on your machine, your applications, etc. > Try searching dejanews or Usenet for more info. > > -- > Matthew Vanecek > Course of Study: http://www.unt.edu/bcis > Visit my Website at http://people.unt.edu/~mev0003 > For answers type: perl -e 'print $i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,= H)-2),oct(115),10);' > ***************************************************************** > For 93 million miles, there is nothing between the sun and my shadow > except me. I'm always getting in the way of something... > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ > Please read the FAQ at http://www.tux.org/lkml/ - - ------------------------------ End of linux-kernel-digest V1 #3681 *********************************** To subscribe to linux-kernel-digest, send the command: subscribe linux-kernel-digest in the body of a message to "Majordomo@vger.rutgers.edu". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-linux-kernel": subscribe linux-kernel-digest local-linux-kernel@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "linux-kernel-digest" in the commands above with "linux-kernel". - - --=_ORCL_27260304_0_0-- Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: Dag Wieers Date: Sat, 17 Apr 1999 00:52:05 +0200 (CEST) Subject: segfaults if HD is full ok, can't we do something to attract the user's attention ? a friends Eterm just gave a segmentation fault (coredump) (and it couldn't even coredump). not very helpfull as it couldn't even coredump. [maybe: segmentation fault (coredump failed: disk full) as he suggested ;)] it's just very annoying that it never gave you a clue that your disk is full, maybe the kernel could write something to console ? send something to syslog ? i guess the coredump-issue is glibc-related. is this problem already taken care of ? - - -- dag wieers, , http://dag.life.be/ _| _ _ for life is quite absurd, (_|(_|(_| and death's the final word. -- Monty Python | Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: V Ganesh Date: Sat, 17 Apr 1999 04:59:30 +0530 (IST) Subject: Re: bad lmbench numbers for mmap > From: David Miller > From: V Ganesh > > I just posted the raw numbers and we are roughly twice as slow as > solaris. > > At least it is consistant with the fact that the solaris run had to > touch roughly half as much memory during the benchmark than Linux did. not really, unless I'm really mistaken. lat_mmap's man page says: ... The benchmark maps in and unmaps the first size bytes of the file repeatedly and reports the average time for one mapping/unmapping. ... Output format is "%0.2f %d\n", megabytes, usecs, i.e., 8.00 1200 so from the raw output for linux's lat_mmap run, we get stuff like 16.777216 17745 33.554432 35039 and from solaris, we get 16.777216 9321 of course we can't use the 32M mmap on linux for comparison (which is what I mistakenly did at first), but surely we can compare the two 16 meg mmaps ? and solaris is definitely consistently faster by a factor of roughly 2. total memory size is irrelevant unless you directly (and wrongly) compare the "make see" output of machines which don't have identical amts of RAM. ganesh ganesh Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: "Richard B. Johnson" Date: Fri, 16 Apr 1999 19:35:58 -0400 (EDT) Subject: mm/page_alloc.c low_on_memory variable. Hello mm gurus, In page_alloc.c, defined in /include/linux/mm.h, is this wonderful global variable that I'd love to see from a driver module. Unfortunately, even though it is global, it is somehow invisible. It becomes an undefined symbol if I attempt to use it in my module. If I am not supposed to use this, how do I prevent a driver from crashing the system by eating up all the free pages? The driver that I am implementing should not have a fixed amount of pages that it can use because it should be able to use more if there is more memory available and less if less. Presently, if I allocate pages to buffer an incomming data stream, and using failure to obtain a free page as a throttle, it is way too late. The machine will die a horrible death with out-of-memory errors for everything including init. So I have to be able to check something before I attempt to allocate another page. Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.2.5 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology. Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: Steve Dodd Date: Sat, 17 Apr 1999 00:51:19 +0100 Subject: Re: Linux ping flood on localhost On Fri, Apr 16, 1999 at 09:45:15PM +0400, kuznet@ms2.inr.ac.ru wrote: > Ping rate is unlimited for any kernel version. Unless you use /proc/sys/net/ipv4/icmp_echoreply_rate, presumably. - - -- Never count your chickens before they rip your lips off Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: Gregory Maxwell Date: Fri, 16 Apr 1999 20:31:57 -0400 (EDT) Subject: Re: Static Swap HEhe.. I've got an A2000 with an 030 12megs of f-king GVP ram.. :) Sorry, was thinging too much in the 'general purpose modern desktop/server' mindset. On Fri, 16 Apr 1999, Marc Espie wrote: > In article you write: > > >Heheh... > > >I'm not quite sure why you would want to do this with ram and hdd > >prices today, on a normal system you should plan on having 2x more swap > >then you will ever need so if you are actually getting close to running > >out then you have bigger problems. > > Think `laptop'. > > Or think `older machine with special memory', like an amiga with a GVP G-Force > accelerator. Those still take pricey memory. > > I can understand developpers not wanting to go out of their way to cater > for those machines, but... just to put things into perspective. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ > Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: David Miller Date: Fri, 16 Apr 1999 17:38:59 -0700 Subject: Re: bad lmbench numbers for mmap Date: Sat, 17 Apr 1999 04:59:30 +0530 (IST) From: V Ganesh > At least it is consistant with the fact that the solaris run had to > touch roughly half as much memory during the benchmark than Linux did. not really, unless I'm really mistaken. You're of course right. I think Jakub's profiling results show where the possible problem is. Later, David S. Miller davem@redhat.com Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ From: "Stephen C. Tweedie" Date: Sat, 17 Apr 1999 01:51:17 +0100 (BST) Subject: Re: 2.2.5 optimizations for web benchmarks? Hi, On Fri, 16 Apr 1999 00:15:31 -0700 (PDT), Cacophonix Gaul said: > I'd like some help with optimizing linux (and apache) > for a web benchmark. OK. Most of the important points have been covered already. Especially the tuning of the apache server itself is one of the most significant issues. > Does anyone have any empirical ideas about > _specific_ values that would work well for: > inode-max, bdflush, buffermem, freepages, kswapd, pagecache No advice right now: these should be OK out of the box. However, having said that, there is a group of people working quite hard to optimise the kernel fairly aggressively for large server loads like this. It's not necessarily something you want to get involved with if you just want to take a fair benchmark of the existing kernels, but if you really want to get the best out of a large memory machine then it may be worthwhile looking up the scalability work being done at http://www.citi.umich.edu/projects/citi-netscape/ In particular we've been working on bottlenecks in the page, buffer and dentry hashing mechanisms and have found fairly impressive performance gains to be had by tuning that. Updates will be posted as we come up with tested patches. Cheers, Stephen. Please read the FAQ at http://www.tux.org/lkml/ - ------------------------------ End of linux-kernel-digest V1 #3682 *********************************** To subscribe to linux-kernel-digest, send the command: subscribe linux-kernel-digest in the body of a message to "Majordomo@vger.rutgers.edu". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-linux-kernel": subscribe linux-kernel-digest local-linux-kernel@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "linux-kernel-digest" in the commands above with "linux-kernel". - --=_ORCL_27261906_0_0-- Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Jamie Lokier Date: Sat, 17 Apr 1999 03:11:45 +0200 Subject: Re: bad lmbench numbers for mmap David Miller wrote: > 2) The freeing up of page tables at munmap > > I think #2 could be a possible culprit. > > Linus, did you see any performance degration of lat_mmap when you > added the free_pgtables() stuff into 2.2.x? I think such a problem > would trigger if lat_mmap is doing large enough mmap's and they are in > the right place. Speaking of which. In principle, freeing page tables should make munmap() *faster*, because then you don't have to clear the page tables. I note 2.2.6-pre3 isn't doing that. - -- Jamie Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: David Miller Date: Fri, 16 Apr 1999 18:17:10 -0700 Subject: Re: bad lmbench numbers for mmap Date: Sat, 17 Apr 1999 03:11:45 +0200 From: Jamie Lokier Speaking of which. In principle, freeing page tables should make munmap() *faster*, because then you don't have to clear the page tables. I note 2.2.6-pre3 isn't doing that. Yes do have to clear them, for two reasons: 1) So that the hardware MMU doesn't see valid entries after the tlb flush. (or in the case of clever software TLB miss strategies like that implemeted in the Alpha PAL code or in our sparc64 port, making sure the virtual page table mappings go away properly too) 2) For the sake of the page table caching we do on all ports now. For #2, if a page table chunk is cached, it works so efficiently because it knows the chunks have been cleared out by the callers at some point before being free'd. Later, David S. Miller davem@redhat.com Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Y2K Date: Fri, 16 Apr 1999 18:11:28 -0700 (PDT) Subject: Re: updated proposal for cap in elf On Fri, 16 Apr 1999, David L. Parsley (lkml account) wrote: > Finally, I also suggest a small change in the capability semantics. > Currently, files have a capability set fE, which are the effective bits > which immediately get raised for the file. Andrej Presern noted, and I > agree, that this does nothing to enhance security, since an exploit can You are right it is for compatibility reasons only and I think still potentialy useful. A dumb could have that permission turned off so it could not accidently use it but it could be turned on for someone else. Smart programs should have it set to 0, dumb should be some subset of the permisible including maybe the null set. > trivially raise all effective bits; they might as well be raised on > execution for all current tools. Note that for capability-aware Most are too dumb to raise, only smart ones can and should raise as needed. > applications, the process effective set pE can still be useful to insure > an operation doesn't have side effects; so I'm leaving the behavior of pE > alone. > > I'm suggesting that fE be redefined as fM, an 'inheritable Mask', which > will drop inheritable bits in the process being exec'ed. The effect of > this is to cause certain (or all) inheritance to 'dead-end' during this > exec. When considering design of a secure distribution, I thought this > would be a useful feature. fE is basicly not fM, I think the formula should be: pI' = pI pP' = fP | ( fI & pI & pP) pE' = fE & pP' How exactly would you fit fE into the formulas that would improve these equations? If I understand you correctly you want pE' = (!fM) & pP' which gains you nothing. either way stuff dead-ends. I did kind of like someones idea for f_min so that if (f_min != (f_min&pE') then EPERM Used very sparingly f_min might be good. Without elf I beleive the defaults should be: fE=pP, fI=pI, fP=0, f_min=0 in untrusted elf headers (not marked with suid or sticky or whatever): pI' = pI pP' = fI & pI & pP pE' = fE & pP' Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: Jamie Lokier Date: Sat, 17 Apr 1999 03:21:45 +0200 Subject: Re: bad lmbench numbers for mmap David Miller wrote: > Yes do have to clear them, for two reasons: > > 1) So that the hardware MMU doesn't see valid entries after the > tlb flush. (or in the case of clever software TLB miss strategies > like that implemeted in the Alpha PAL code or in our sparc64 port, > making sure the virtual page table mappings go away properly too) In the hardware case, this isn't true (correct me) if you flush the TLB after clearing the page directory entries, surely? > 2) For the sake of the page table caching we do on all ports now. > > For #2, if a page table chunk is cached, it works so efficiently > because it knows the chunks have been cleared out by the callers at > some point before being free'd. Point taken. #2 means nothing would be gained. (Unless clearing a whole page is faster than clearing one pte at a time..) - -- Jamie Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ From: David Miller Date: Fri, 16 Apr 1999 18:25:52 -0700 Subject: Re: bad lmbench numbers for mmap Date: Sat, 17 Apr 1999 03:21:45 +0200 From: Jamie Lokier David Miller wrote: > Yes do have to clear them, for two reasons: > > 1) So that the hardware MMU doesn't see valid entries after the > tlb flush. (or in the case of clever software TLB miss strategies > like that implemeted in the Alpha PAL code or in our sparc64 port, > making sure the virtual page table mappings go away properly too) In the hardware case, this isn't true (correct me) if you flush the TLB after clearing the page directory entries, surely? We do, and do it right on x86 etc. but that scheme really doesn't work for the clever Alpha/sparc64 methods in all cases. I discussed with Linus adding a "flush_tlb_pgtables(mm, begin, end)" method or similar to deal with this. I think Alpha might get lucky in this case because it does a full mm flush for tlb range flushes (which will happen right before flush_pgtables is called), whereas on sparc64 we do a more finegrained tlb flush for ranges which won't take care of the virtual page table mappings used by the TLB miss scheme. Point taken. #2 means nothing would be gained. (Unless clearing a whole page is faster than clearing one pte at a time..) Clearing a whole page is faster on UltraSparc, because it would use the high speed VIS block memory stores which avoid cache pollution. Similar tricks could be done on the modern Pentiums... Later, David S. Miller davem@redhat.com Please read the FAQ at http://www.tux.org/lkml/ ------------------------------ End of linux-kernel-digest V1 #3683 *********************************** To subscribe to linux-kernel-digest, send the command: subscribe linux-kernel-digest in the body of a message to "Majordomo@vger.rutgers.edu". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-linux-kernel": subscribe linux-kernel-digest local-linux-kernel@your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "linux-kernel-digest" in the commands above with "linux-kernel". --=_ORCL_27262309_0_0-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/