Return Message

orarepl (orarepl@us.oracle.com)
16 Apr 99 18:43:17 -0700

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: V Ganesh: "Re: bad lmbench numbers for mmap"
Previous message: Brandon S. Allbery KF8NH: "Re: Lockups with Intel EtherExpress Pro 10/100"
Next in thread: Gerhard Mack: "mail loop !!!!!!Re: Return Message"
Reply: Gerhard Mack: "mail loop !!!!!!Re: Return Message"

--=_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
Errors-To:owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
Message-Id:<19990417011144Z160769-11364+5589@vger.rutgers.edu>
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 <abob@dpd130.rh.psu.edu>

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "orarepl" <orarepl@us.oracle.com>
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:<owner-linux-kernel-digest-outgoing@vger.rutgers.edu>
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" <root@chaos.analogic.com>
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 <casey@sgi.com>
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 <lkd@tantalophile.demon.co.uk>
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 <davem@twiddle.net>
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 <ganesh@vxindia.veritas.com>

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 <davem@twiddle.net>
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 <ganesh@vxindia.veritas.com>

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 <jj@sunsite.mff.cuni.cz>
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 <ganesh@vxindia.veritas.com>
Date: Sat, 17 Apr 1999 04:28:47 +0530 (IST)
Subject: Re: bad lmbench numbers for mmap

> From: David Miller <davem@twiddle.net>
[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 <tiensivu@pilot.msu.edu>
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 <davem@twiddle.net>
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 <ganesh@vxindia.veritas.com>

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 <ganesh@vxindia.veritas.com>
Date: Sat, 17 Apr 1999 04:38:41 +0530 (IST)
Subject: Re: bad lmbench numbers for mmap

> From: David Miller <davem@twiddle.net>
>
> 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" <orarepl@us.oracle.com>
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:<owner-linux-kernel-digest-outgoing@vger.rutgers.edu>
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 <rgammans@computer-surgery.co.uk>
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 <rgammans@computer-surgery.co.uk>
>
> 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" <sct@redhat.com>
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
<jeremy@goop.org> 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 <ganesh@vxindia.veritas.com>
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" <bmacy@sunshinecomputing.com>
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)" <kparse@salem.k12.va.us>
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)" <kparse@salem.k12.va.us>
>
> 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 <dlang@diginsite.com>
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 <Walter.Hofmann@physik.stud.uni-erlangen.de>
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" <sct@redhat.com>
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 <ganesh@vxindia.veritas.com>
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" <sct@redhat.com>
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
<lists@cyclades.com> 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 <viro@math.psu.edu>
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" <sct@redhat.com>
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
<roques@scalar.pond.sub.org> said:

> Just a thought,
> "Stephen C. Tweedie" <sct@redhat.com> 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 <tim@cyberelk.demon.co.uk>
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" <tytso@MIT.EDU>
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 <dlang@diginsite.com>

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 <dlang@diginsite.com>
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 <dlang@diginsite.com>
>
> 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
>
>

- - - -----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" <root@chaos.analogic.com>
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" <sct@redhat.com>
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 <ggoodrum@perigee.ncd=
c.noaa.gov> 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" <tytso@MIT.EDU>
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 <dlang@diginsite.com>
X-Sender: dlang@dlang

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 <dag@life.be>
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

Please read the FAQ at http://www.tux.org/lkml/

- - ------------------------------

From: "David L. Parsley (lkml account)" <kparse@salem.k12.va.us>
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 <jj@sunsite.mff.cuni.cz>
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.

Please read the FAQ at http://www.tux.org/lkml/

- - ------------------------------

From: Gerard Roudier <groudier@club-internet.fr>
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 <dlang@diginsite.com>
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
>
>
>

- - - -----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 <lists@cyclades.com>
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)" <kparse@salem.k12.va.us>
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 <mev0003@unt.edu>
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 <philb@gnu.org>
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?

Please read the FAQ at http://www.tux.org/lkml/

- - ------------------------------

From: Casey Schaufler <casey@sgi.com>
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 <riel@nl.linux.org>
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 <ganesh@vxindia.veritas.com>
Date: Sat, 17 Apr 1999 03:36:17 +0530 (IST)
Subject: Re: bad lmbench numbers for mmap

> From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
[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" <allbery@kf8nh.apk.net>
Date: Fri, 16 Apr 1999 18:11:13 -0400
Subject: Re: Swap size proportion

Please set a valid email address.

In message <aBKR2.1816$t56.5221@sunsite.auc.dk>, "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 <tzs@tzs.net>
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<RETURN>" 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 <rgooch@atnf.csiro.au>
Date: Sat, 17 Apr 1999 08:40:11 +1000
Subject: Re: [PATCH] Capabilities, this time in elf section

Horst von Brand writes:
> Richard Gooch <rgooch@atnf.csiro.au> 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" <root@chaos.analogic.com>
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 <sweetin@ix.netcom.com>
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 <dag@life.be>
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 ?

Please read the FAQ at http://www.tux.org/lkml/

- ------------------------------

From: V Ganesh <ganesh@vxindia.veritas.com>
Date: Sat, 17 Apr 1999 04:59:30 +0530 (IST)
Subject: Re: bad lmbench numbers for mmap

> From: David Miller <davem@twiddle.net>
> From: V Ganesh <ganesh@vxindia.veritas.com>
>
> 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

Please read the FAQ at http://www.tux.org/lkml/

- ------------------------------

From: "Richard B. Johnson" <root@chaos.analogic.com>
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 <dirk@loth.demon.co.uk>
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 <linker@z.ml.org>
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 <Pine.LNX.3.96.990413175624.15190A-100000@z.ml.org> 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 <davem@twiddle.net>
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 <ganesh@vxindia.veritas.com>

> 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" <sct@redhat.com>
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
<cacophonix@yahoo.com> 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

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 <lkd@tantalophile.demon.co.uk>
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 <davem@twiddle.net>
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 <lkd@tantalophile.demon.co.uk>

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 <y2k@y2ker.com>
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 <lkd@tantalophile.demon.co.uk>
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 <davem@twiddle.net>
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 <lkd@tantalophile.demon.co.uk>

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

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/

Next message: V Ganesh: "Re: bad lmbench numbers for mmap"
Previous message: Brandon S. Allbery KF8NH: "Re: Lockups with Intel EtherExpress Pro 10/100"
Next in thread: Gerhard Mack: "mail loop !!!!!!Re: Return Message"
Reply: Gerhard Mack: "mail loop !!!!!!Re: Return Message"