Return Message

orarepl (orarepl@us.oracle.com)
16 Apr 99 16:36:34 -0700

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Theodore Y. Ts'o: "Re: caps in elf headers: use the sticky bit!"
Previous message: Richard B. Johnson: "mm/page_alloc.c low_on_memory variable."

--=_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
Errors-To:owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
Message-Id:<19990416224654Z160329-11366+5425@vger.rutgers.edu>
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>

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 <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 > >

"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" <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.

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 <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 > > >

"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 <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--

- 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: Theodore Y. Ts'o: "Re: caps in elf headers: use the sticky bit!"
Previous message: Richard B. Johnson: "mm/page_alloc.c low_on_memory variable."