don't want any more..thanks
------ =_NextPart_000_01BC75BB.5F2AB5E0
Content-Type: text/plain; name="ATT00000.txt"
Content-Transfer-Encoding: quoted-printable
linux-kernel-digest Tuesday, 10 June 1997 Volume 01 : =
Number 941
In this issue:
Re: 2.0.30 floppy problem
Re: support of Universal Disc Format (UDF)?
Re: POSIX.6 (or 1.b now or something)
Re: Problem with pppd
Re: Ext2 oddities ?
Re: POSIX.6 (or 1.b now or something)
Re: Non-executable stack patch
how to make kernel patches
Re: 2.1.42
Re: Non-executable stack patch
Re: "obsolete" hardware
Re: Ext2 oddities ?
Re: how to make kernel patches
Re: POSIX.6 (or 1.b now or something)
Re: POSIX.6 (or 1.b now or something)
Re: "obsolete" hardware
UNKNOWN sockets in 2.1.42
PCI netcards that are good for Linux
Almost complete lockup of ppp with pre-2.0.30-2
pre-2.0.31-1 crash
GP with 2.0.30 + pre2 patch : ksymoops + gdb info included
Re: pre-2.0.31-1 crash
Re: Non-executable stack patch
Re: GP with 2.0.30 + pre2 patch : ksymoops + gdb info included
Re: PCI netcards that are good for Linux
Re: Bug in chown -- always kills suid/sgid bits.
Re: low memory buffer cachebug fix, need some testers...
Re: [2.1.41] kernel: a.out: Exception at ...
Re: low memory buffer cachebug fix, need some testers...
Re: Non-executable stack patch
Re: Non-executable stack patch
2.0.30 Oops with portslave
Re: Loop Encryption
Re: Ext2fs and hashed table.
Re: another pre-2.0.31 problem
Re: Non-executable stack patch
Re: PCI netcards that are good for Linux
Re: another pre-2.0.31 problem=20
Re: Repeat the Ending
Re: Repeat the Ending
Re: another pre-2.0.31 problem=20
Re: do the resource limits still work?
Re: Problems with 'objdump' compiling 2.0.30 kernel
Re: PCI netcards that are good for Linux
Re: Non-executable stack patch
See the end of the digest for information on subscribing to the =
linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Sam Ockman <ockman@cs.stanford.edu>
Date: Mon, 9 Jun 1997 12:28:43 +0000
Subject: Re: 2.0.30 floppy problem
Just ran into this problem myself, searched my archives of this list and
found this message. Has there been any work on this in the last two
months? Is it fixed on some kernel vers? Or is it close to being =
fixed?
(I found it with 2.0.30.)
Also if I boot with floppy=3Dnodma, does that only effect the speed of
floppy access, or does it have other effects?
Thanks,
Sam
Message from Alain Knaff (alknaff@hal.local.host) on 4-14-97:
> >I got a message "floppy1 unable to allocate DMA memory" I had tried =
to
> >mount and "ls" an msdos floppy. I was in another virtual console =
when I
> >received the message. There has been a lot of discussion recently on
> >floppy drivers so maybe this problem has already been solved.
> >
> > Donald Harter Jr.
> >
>=20
> This problem is well known, but unfortunately there is no clean fix
> for it yet :-( The source of the problem is that only memory below
> 16M is suitable for DMA. The way how memory allocation works is that
> the memory manager first searches for suitable memory which is already
> free, and if none is found, it tries to free some more by swapping or
> tossing away buffers. Unfortunately, the last part of the algorithm
> (freeing more memory) doesn't have any knowledge of the _kind_ of
> memory requested. Hence this part will say "there is plenty of memory
> available", but all that memory will be above 16M. Thus the upper
> layer will fail because it still can't find any suitable memory.
>=20
> One workaround for this problem is to boot with floppy=3Dnodma.
- --=20
VA Research Linux Workstations | The VArServer 4000 File Server
| Four 200Mhz Intel Pentium Pro =
CPUs
http://www.varesearch.com | 512MB 60ns EDO ECC/100 GB Raid-5
Sam Ockman - (415)934-3666, ext. 133 | RedHat Linux - $44,339
------------------------------
From: Dan Hollis <goemon@sasami.anime.net>
Date: Mon, 9 Jun 1997 12:39:16 -0700 (PDT)
Subject: Re: support of Universal Disc Format (UDF)?
On Sun, 8 Jun 1997, Shay Rojansky wrote:
> And while on subject: Anyone taking care of DVD-ROM drivers for Linux?
> I hear they're been sold in the US nowadays for relatively little.
AFAIK they are just another IDE-cdrom device, and shouldn't require any
special driver. After all, they can still read normal CDs.
The only special drivers required should be UDF filesystem.
- -Dan
------------------------------
From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
Date: Mon, 9 Jun 1997 12:48:43 -0700 (PDT)
Subject: Re: POSIX.6 (or 1.b now or something)
I was digging through the code planning to add privs such that:=20
- - you could restrict a port to a specific uid (i.e. tcp 113 can be =
opened
by news and root only)
- - you could restrict the range used to generate the "random" port of a
listening socket with unspecified port (i.e. > 1023, not in =
6000..6099)
Does POSIX.6 define this sort of thing too? Any sample source out =
there?
Dean
On Mon, 9 Jun 1997, Chris Evans wrote:
>=20
> Hi,
>=20
> I think POSIX.6 security would be a great thing to have in Linux 2.2.
> Surely a POSIX.6 implementation (or one based on its ideas) is not too
> much hassle. In fact with finals concluding soon I may attempt it =
myself
> :)
>=20
> However -- I know someone was hacking at POSIX.6 a while back, D. =
Moffat
> was it? There was even a preliminary patch. Is work still ongoing? =
Anyone
> got an offical spec. sheet for the thing?
>=20
> I ask because I have the number of suid binaries on my system down to =
a
> very low number, and the following remaining are just begging for a =
subset
> of root privs:=20
>=20
> ping, traceroute: priv =3D open raw socket
> ssh,rlogin,rcp,r<etc> priv =3D open socket num < 1024
>=20
> Other useful privilege subsets would of course be read any file, tty
> chowning/chmoding, etc.
>=20
> Cheers,
> Chris
>=20
>=20
------------------------------
From: Amy <root@internet-frontier.net>
Date: Mon, 9 Jun 1997 12:53:14 -0700 (PDT)
Subject: Re: Problem with pppd
On Sun, 8 Jun 1997, Enrico Lorenzetti wrote:
> I' ve got a strange and annoying problem with pppd on two Linux =
Boxes.
> Every now and then pppd doesn't seem to detect the loss of the =
carrier and
> keeps running. Obviously at this point mgetty can't regain control of =
the
> serial line and nobody can connect to that modem.
> After a while (generally a few hours) the pppd process nearly chokes =
the
> CPU (the top command has reported a 212% usage once, and generally =
reports
> a 90+% CPU usage when this problem appears) and nobody can connect to =
any
> modem.
> Killing the process solves the problem.
I have experienced this too, and at least in all the cases here, the
problem has been WinNT. If the option "Accept only encrypted
authentication" is selected, the WinNT system will *never* be able to
login to the Linux system, and you will experience the CPU hogging and
hund pppd processes. If you change the option to "Accept any =20
authentication including plain text", the user can login without =
problems.
The option in question is under My Computer->Dial-up
Networking->Properties->Security->Authentication and Encryption Policy
Hope this helps
Amy :)
------------------------------
From: Dan Hollis <goemon@sasami.anime.net>
Date: Mon, 9 Jun 1997 13:28:11 -0700 (PDT)
Subject: Re: Ext2 oddities ?
On Mon, 9 Jun 1997, Philippe Strauss wrote:
> I have three patches applied in addition of 2.0.31-pre-2:
> - ncrBsd 1.18i
^^^^^^^^^^^^
> - Solar's stack not-exec patch
> - Stephan latest IO-handling patch for Ext2
But 2.0.31-pre-2 has ncrBsd 1.18i by default! If you applied a patch,
perhaps it backed out 1.18i to something earlier.
- -Dan
------------------------------
From: Elliot Lee <sopwith@redhat.com>
Date: Mon, 9 Jun 1997 16:31:16 -0400 (EDT)
Subject: Re: POSIX.6 (or 1.b now or something)
On Mon, 9 Jun 1997, Dean Gaudet wrote:
> I was digging through the code planning to add privs such that:=20
>=20
> - you could restrict a port to a specific uid (i.e. tcp 113 can be =
opened
> by news and root only)
>=20
> - you could restrict the range used to generate the "random" port of a
> listening socket with unspecified port (i.e. > 1023, not in =
6000..6099)
>=20
> Does POSIX.6 define this sort of thing too? Any sample source out =
there?
There is a very-much-alive linux-privs project that is implementing
POSIX.6 & etc. - you may want to see what they have before you try doing
anything.=20
- -- Elliot http://www.redhat.com/
How do you explain school to a higher intelligence?
-- Elliot, "E.T."
------------------------------
From: Dan Hollis <goemon@sasami.anime.net>
Date: Mon, 9 Jun 1997 13:31:57 -0700 (PDT)
Subject: Re: Non-executable stack patch
On Mon, 9 Jun 1997, Ingo Molnar wrote:
> On Sat, 7 Jun 1997, Solar Designer wrote:
> What about mapping libc always onto addresses that have a 0xab******
> pattern, and then forbidding character '0xab' in argv[] and envp[] =
strings
> [done by the kernel].
This will probably break multibyte encodings. Can you pass
EUC/SJIS/Unicode in argv/envp?
- -Dan
------------------------------
From: "Jeremy A. Gilbert" <grath@gryphon.ccs.brandeis.edu>
Date: Mon, 9 Jun 1997 16:32:55 -0400 (EDT)
Subject: how to make kernel patches
hey all,
Can someone tell me if there is a good trick for making
compilations of kernel diffs? Just a command which compares two kernel
trees and only includes the neccesary files to patch from one to =
another.
It seems there should be some sort of utility for doing it, (knowing to
ignore *.o and .config and .depend, etc) but i haven't been able to =
find
one. diff(1) -r doesn't seem to be working too well for this. Thanks,
Jeremy
------------------------------
From: Michael Harnois <mharnois@sbt.net>
Date: 09 Jun 1997 15:43:18 -0500
Subject: Re: 2.1.42
Aaron Tiensivu <tiensivu@pilot.msu.edu> writes:
> Cry me a river. Procps had a good year to get rid of the old code.
Children are so annoying to work with ...
------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Mon, 9 Jun 1997 21:59:16 +0100 (BST)
Subject: Re: Non-executable stack patch
> What about mapping libc always onto addresses that have a 0xab******
> pattern, and then forbidding character '0xab' in argv[] and envp[] =
strings
> [done by the kernel].
Legal utf8 path ... you might not be able to run some klingon apps then
------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Mon, 9 Jun 1997 21:55:00 +0100 (BST)
Subject: Re: "obsolete" hardware
> But I really see no reason to have 386 support (and I'd say drop =
math
> emulation too so that people can use FP in the kernel) in the 2.1.x =
and
> later kernels. None of the new features are really worth implementing =
on
> such old hardware. Is anyone really going to have an IPv6 modem pool? =
And
> if you're doing IPv6 routing wouldn't you want a 486 anyways?
Why go to the extra work of dropping it. Anyway there are people using =
MCA
bus 386's with Arcnet quite happily in 2.1.x. I dont see why IPv6 =
routing
needs a 486 either
------------------------------
From: Philippe Strauss <philou@lili.urbanet.ch>
Date: Mon, 9 Jun 1997 23:09:05 +0200
Subject: Re: Ext2 oddities ?
On Jun 9, Dan Hollis wrote
> On Mon, 9 Jun 1997, Philippe Strauss wrote:
> > I have three patches applied in addition of 2.0.31-pre-2:
> > - ncrBsd 1.18i
> ^^^^^^^^^^^^
> > - Solar's stack not-exec patch
> > - Stephan latest IO-handling patch for Ext2
>=20
> But 2.0.31-pre-2 has ncrBsd 1.18i by default! If you applied a patch,
> perhaps it backed out 1.18i to something earlier.
Naaaaa I'm an ass, I forgot to apply pre-2 on this source tree..
I just noticed this after seeing a reject of latest DaveM vm patch
while applying it to this tree.
So I was running plain 2.0.30 with ncrBsd 1.18i, stack not-smash,
ext2fs error handling..
Maybe plain 2.0.30 and ext2fs new error handling don't mix too well :)
Cheers, Philippe.
>=20
> -Dan
- --=20
Philippe Strauss <philou@lili.urbanet.ch>
Urbanet SA, Vallombreuse 51, 1004 Lausanne -- 021 / 625.28.14
Homepage & PGP key: http://lili.urbanet.ch
Never insult an alligator until you've crossed the river.
- --
------------------------------
From: Elliot Lee <sopwith@redhat.com>
Date: Mon, 9 Jun 1997 17:36:54 -0400 (EDT)
Subject: Re: how to make kernel patches
On Mon, 9 Jun 1997, Jeremy A. Gilbert wrote:
> Can someone tell me if there is a good trick for making
> compilations of kernel diffs? Just a command which compares two kernel
> trees and only includes the neccesary files to patch from one to =
another.
> It seems there should be some sort of utility for doing it, (knowing =
to
> ignore *.o and .config and .depend, etc) but i haven't been able to =
find
> one. diff(1) -r doesn't seem to be working too well for this. Thanks,
The gendiff script following my .sig is a standard part of rpm, but is
useful in other situations as well :-)
Basically, whenever you want to make a patch to a file, you save the
original with your special extension - i.e. I save the originals of =
files
I modify with a '.sopwith' extension ('cp filename.c =
filename.c.sopwith').
Then when you want to get The Patch for, say, /usr/src/linux, just run:
cd /usr/src
gendiff linux .sopwith > /tmp/mycoolkernel.patch
Hope this helps,
- -- Elliot http://www.redhat.com/
How do you explain school to a higher intelligence?
-- Elliot, "E.T."
#!/bin/bash
[ -z "$1" -o -z "$2" ] && {
# usage
echo "usage: $0 <directory> <diff-extension>" 1>&2
exit 1
}
find $1 \( -name "*$2" -o -name ".*$2" \) -print |
while read f; do
diff -u $f ${f%%$2}
done
------------------------------
From: "Andrew G. Morgan" <morgan@parc.power.net>
Date: Mon, 9 Jun 1997 14:05:23 -0700 (PDT)
Subject: Re: POSIX.6 (or 1.b now or something)
Chris Evans wrote:
> I think POSIX.6 security would be a great thing to have in Linux 2.2.
> Surely a POSIX.6 implementation (or one based on its ideas) is not too
> much hassle. In fact with finals concluding soon I may attempt it =
myself
> :)
>=20
> However -- I know someone was hacking at POSIX.6 a while back, D. =
Moffat
> was it? There was even a preliminary patch. Is work still ongoing? =
Anyone
> got an offical spec. sheet for the thing?
Darren has got a job working on Trusted Solaris: he sometimes has time =
to
contribute comment to the list now...
> I ask because I have the number of suid binaries on my system down to =
a
> very low number, and the following remaining are just begging for a =
subset
> of root privs:=20
>=20
> ping, traceroute: priv =3D open raw socket
> ssh,rlogin,rcp,r<etc> priv =3D open socket num < 1024
>=20
> Other useful privilege subsets would of course be read any file, tty
> chowning/chmoding, etc.
In the latest draft, privileges got renamed "capabilities" and happily =
they
are 99% implemented now. (Zefram and I finished up what Darren had
started a month or so ago.)
Work is still progressing. It is hampered by the fact that few have a =
copy
of the draft standard. If you want to get on the list, subscribe to
linux-privs-request@mit.edu
(which is manually maintained by Ted Ts'o).
For patches against 2.0.30
http://parc.power.net/morgan/Orange-Linux/linux-privs/index.html
I am currently working on the auditing component. Remy Card is =
reportadly
working on the ACL stuff although this has been somewhat delayed because =
of
a Linux book he has been writing.
Best wishes
Andrew
- --=20
Linux-PAM, libpwdb, Orange-Linux and Linux-GSS
http://parc.power.net/morgan/index.html
------------------------------
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Date: Mon, 9 Jun 1997 18:14:47 -0400
Subject: Re: POSIX.6 (or 1.b now or something)
Date: Mon, 9 Jun 1997 20:02:46 +0100 (BST)
From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
I think POSIX.6 security would be a great thing to have in Linux 2.2.
Surely a POSIX.6 implementation (or one based on its ideas) is not =
too
much hassle. In fact with finals concluding soon I may attempt it =
myself
:)
Actually, it's very complicated. There's some filesystem work that
needs to go into it --- there are currently separate filesystem patches,
which I will (hopefully within a few weeks) have the time to work on
getting them folded into the mainline Linux kernel.
Then there are all of the changes in the kernel to handle all of the
various capabilities. =20
Finally (and most importantly), you need a lot of good user tools to
manage all of the various POSIX.6 tuning knobs, or you may end up with a
system which is *less* secure, because it's so complicated that the
system administrator can't keep track of it all.
The list where the people who are working on all of this is
linux-privs@mit.edu (which I see you've already subscribed yourself to,
but I mention it for the benefit of others who are interested in this
topic.)
- Ted
------------------------------
From: "Michael H. Warfield" <mhw@wittsend.com>
Date: Mon, 9 Jun 1997 18:21:58 -0400 (EDT)
Subject: Re: "obsolete" hardware
Alan Cox enscribed thusly:
> > But I really see no reason to have 386 support (and I'd say drop =
math
> > emulation too so that people can use FP in the kernel) in the 2.1.x =
and
> > later kernels. None of the new features are really worth =
implementing on
> > such old hardware. Is anyone really going to have an IPv6 modem =
pool? And
> > if you're doing IPv6 routing wouldn't you want a 486 anyways?
> Why go to the extra work of dropping it. Anyway there are people using =
MCA
> bus 386's with Arcnet quite happily in 2.1.x. I dont see why IPv6 =
routing
> needs a 486 either
Yeah... And most of my routers are 386 systems which use to be
workstations which were then retired. 386's make great routers and =
firewalls.
Great use for those old ex-workstations that nobody wants anymore. Why =
should
I now have to toss them out as well and upgrade all of my routers just
because someone thinks that this perfectly good, perfectly functional
box is now obsolete. I would much rather spend x number of dolars (for =
any
value of x) on new hardware that is sitting in front of my engineers and
relegate the older hardware to specialized jobs that they are perfectly
capable of performing. The routers and firewalls are generation 3 =
hand-me-
downs. In another year or two, maybe I won't have anymore 386's there,
but maybe they will be somewhere else...
Mike
- --=20
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 925-8248 | =
http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of =
all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
------------------------------
From: Evan Jeffrey <ejeffrey@eliot213.wuh.wustl.edu>
Date: Mon, 09 Jun 1997 17:52:44 -0500
Subject: UNKNOWN sockets in 2.1.42
What causes sockets to go into the "unknown" (as reported by netstat) =
state?=20
I have seen them before, but today I got 11 of them. 8 were from the =
same
host, connecting to my "auth" port, as such:
tcp 1 1 eliot213.wuh.wust:auth jalapeno.ucs.ind:38188 =
UNKNOWN root
The other 3 were all from a second host, all three ftp (transfer, not
master) sockets, like so:
tcp 1 1 eliot213.wuh.wustl.:20 spr186.pp.dlc.fi:1072 =
UNKNOWN root
In general, I have seen them appear more often from particular hosts, =
but
never in such great numbers at once. Typically, this happens on either
smpt, auth, or port 20, but then again, those are the ports most =
commonly
used...
=3D=3D=3D
Evan Jeffrey
erjeffre@artsci.wustl.edu
Let us go. Let us leave this festering hell hole. Let us think the
unthinkable, let us do the undoable. Let us prepare to grapple with the
ineffable itself, and see if we may not eff it after all.
--Dirk Gently
------------------------------
From: Aaron Tiensivu <tiensivu@pilot.msu.edu>
Date: Mon, 9 Jun 1997 19:07:34 -0400
Subject: PCI netcards that are good for Linux
I'm curious about a certain PCI card that our work just got
for a few of our machines. How do the SMC EtherPower PCI cards hold out =
under
load and performance-wise in general and under Linux? I noticed it was =
based
off a Digital chip and I vaguely remember hearing bad things on the list =
about
lots of the 'tulip' cards that were as bad as the ne2000 cards.
Any info would be grand. :)
------------------------------
From: renehl@post1.tele.dk (Rene Hoejbjerg Larsen)
Date: 9 Jun 1997 23:18:33 GMT
Subject: Almost complete lockup of ppp with pre-2.0.30-2
I just experienced an almost complete lockup of ppp networking with
pre-2.0.30-2. The link came up fine (except the first time when pppd
somehow failed to get the remote ip address), but the link was almost
dead. A few packages managed to get through, though, as some packets =
were
returned from ping, and ftp sessions were sometimes established. This
happened after four days of solid uptime. I tried reconnecting several
times, both with and without Van Jacobsen compression.
The reason I believe this to be a Linux problem (you could think it was =
an
ISP problem) is that netstat --inet -n gave some funny output:
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address =
State =20
tcp 0 0 127.0.0.1:1274 127.0.0.1:1273 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1273 127.0.0.1:1274 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1276 127.0.0.1:1275 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1275 127.0.0.1:1276 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1330 127.0.0.1:1277 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1277 127.0.0.1:1330 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1332 127.0.0.1:1331 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1331 127.0.0.1:1332 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1334 127.0.0.1:1333 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:1333 127.0.0.1:1334 =
ESTABLISHED=20
tcp 0 0 192.168.0.1:23 192.168.0.2:1027 =
ESTABLISHED=20
tcp 0 0 194.239.143.129:11355 128.2.196.124:80 =
ESTABLISHED=20
tcp 0 1 194.239.143.129:11712 193.162.153.172:80 =
FIN_WAIT1 =20
tcp 0 0 194.239.143.188:12032 193.162.153.172:80 =
ESTABLISHED=20
tcp 696 1 194.239.143.188:12299 194.239.134.164:110 =
LAST_ACK =20
tcp 0 1 194.239.143.188:12331 193.162.153.172:80 =
FIN_WAIT1 =20
tcp 0 1 194.239.143.188:12354 207.121.184.84:80 =
FIN_WAIT1 =20
tcp 0 0 127.0.0.1:12379 127.0.0.1:119 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:119 127.0.0.1:12379 =
ESTABLISHED=20
tcp 0 0 194.239.143.188:12402 193.162.153.172:80 =
ESTABLISHED=20
tcp 0 0 194.239.143.188:12404 137.92.14.2:80 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:3128 127.0.0.1:12406 =
CLOSE_WAIT =20
tcp 0 0 127.0.0.1:3128 127.0.0.1:12432 =
CLOSE_WAIT =20
tcp 0 0 194.239.143.188:12439 193.162.153.172:80 =
ESTABLISHED=20
tcp 0 0 194.239.143.188:12463 193.162.153.172:80 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:3128 127.0.0.1:12473 =
CLOSE_WAIT =20
tcp 0 0 194.239.143.188:12477 193.162.153.172:80 =
ESTABLISHED=20
tcp 0 1 194.239.143.188:12508 194.182.149.12:21 =
LAST_ACK =20
tcp 0 0 194.239.143.175:12528 128.2.196.124:80 =
ESTABLISHED=20
tcp 0 0 194.239.143.175:12609 130.225.51.30:21 =
FIN_WAIT2 =20
tcp 0 0 194.239.143.175:12677 193.162.146.11:119 =
ESTABLISHED=20
tcp 0 0 194.239.143.175:12690 130.225.128.158:23 =
ESTABLISHED=20
tcp 0 0 127.0.0.1:12725 127.0.0.1:3128 =
FIN_WAIT2 =20
tcp 0 0 127.0.0.1:3128 127.0.0.1:12725 =
CLOSE_WAIT =20
tcp 0 0 127.0.0.1:12731 127.0.0.1:3128 =
FIN_WAIT2 =20
tcp 0 0 127.0.0.1:3128 127.0.0.1:12731 =
CLOSE_WAIT =20
tcp 0 0 194.239.143.175:12770 193.162.153.172:80 =
ESTABLISHED=20
tcp 0 0 194.239.143.175:12771 193.162.153.172:80 =
ESTABLISHED=20
tcp 1 0 127.0.0.1:12779 127.0.0.1:676 =
TIME_WAIT =20
tcp 0 0 194.239.143.175:12793 193.162.153.172:80 =
ESTABLISHED=20
tcp 0 0 194.239.143.175:12798 193.162.153.172:80 =
ESTABLISHED=20
tcp 0 0 194.239.143.175:12800 130.225.51.30:21 =
FIN_WAIT2 =20
tcp 1 0 127.0.0.1:997 127.0.0.1:676 =
TIME_WAIT =20
I.e. a lot of connections in FIN_WAITX states. Besides, the connection
works fine now after a reboot (sigh).
The networking parts of .config are as follows:
#
# Networking options
#
CONFIG_FIREWALL=3Dy
CONFIG_NET_ALIAS=3Dy
CONFIG_INET=3Dy
CONFIG_IP_FORWARD=3Dy
CONFIG_IP_MULTICAST=3Dy
CONFIG_SYN_COOKIES=3Dy
CONFIG_RST_COOKIES=3Dy
CONFIG_IP_FIREWALL=3Dy
# CONFIG_IP_FIREWALL_VERBOSE is not set
CONFIG_IP_MASQUERADE=3Dy
#
# Protocol-specific masquerading support will be built as modules.
#
CONFIG_IP_MASQUERADE_IPAUTOFW=3Dy
CONFIG_IP_MASQUERADE_IPPORTFW=3Dy
CONFIG_IP_MASQUERADE_ICMP=3Dy
CONFIG_IP_TRANSPARENT_PROXY=3Dy
CONFIG_IP_ALWAYS_DEFRAG=3Dy
CONFIG_IP_ACCT=3Dy
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_IP_MROUTE is not set
CONFIG_IP_ALIAS=3Dy
#
# (it is safe to leave these untouched)
#
# CONFIG_INET_PCTCP is not set
# CONFIG_INET_RARP is not set
# CONFIG_NO_PATH_MTU_DISCOVERY is not set
CONFIG_IP_NOSR=3Dy
CONFIG_SKB_LARGE=3Dy
#
# =20
#
CONFIG_IPX=3Dm
# CONFIG_IPX_INTERN is not set
# CONFIG_ATALK is not set
# CONFIG_AX25 is not set
# CONFIG_BRIDGE is not set
# CONFIG_NETLINK is not set
#
# Network device support
#
CONFIG_NETDEVICES=3Dy
CONFIG_DUMMY=3Dm
# CONFIG_EQUALIZER is not set
# CONFIG_DLCI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=3Dy
#
# CCP compressors for PPP are only built as modules.
#
# CONFIG_SLIP is not set
# CONFIG_NET_RADIO is not set
CONFIG_NET_ETHERNET=3Dy
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
CONFIG_NET_ISA=3Dy
# CONFIG_AT1700 is not set
# CONFIG_E2100 is not set
# CONFIG_DEPCA is not set
# CONFIG_EWRK3 is not set
# CONFIG_EEXPRESS is not set
# CONFIG_EEXPRESS_PRO is not set
# CONFIG_FMV18X is not set
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_HP100 is not set
# CONFIG_ETH16I is not set
CONFIG_NE2000=3Dy
# CONFIG_NI52 is not set
# CONFIG_NI65 is not set
# CONFIG_SEEQ8005 is not set
# CONFIG_SK_G16 is not set
# CONFIG_NET_EISA is not set
# CONFIG_NET_POCKET is not set
# CONFIG_TR is not set
# CONFIG_FDDI is not set
# CONFIG_ARCNET is not set
I realize this is not much to go on, but my logs show NOTHING unusual. I
don't know if this is reproducable or not (I only installed the =
pre-patch
a week ago or so), but I thought you would like to know about this. Too
bad I didn't think about doing a tcpdump when this happened :-(
- --=20
/'"`\ zzzZ | My PGP Public Key is available at:
( - - ) | <http://home1.inet.tele.dk/renehl/>
- ----oooO--(_)--Oooo-------------------------------------------=20
Math and alcohol don't mix: Do not drink and derive!
------------------------------
From: Jon Lewis <jlewis@inorganic5.fdt.net>
Date: Mon, 9 Jun 1997 19:19:54 -0400 (EDT)
Subject: pre-2.0.31-1 crash
I was just trying to wipe a disk clean before returning it to =
Micropolis,
and did:
dd if=3D/dev/zero of=3D/dev/sdb bs=3D10240 count=3D419328
It ran for a bit, and wiped out parts of /dev/sdb, but the system =
started
thrashing the boot disk a bit, so I stopped it, echo'd 512 1024 1536 to
freepages, and tried again. It ran longer the second time, but =
eventually
started doing lots of access on the boot/swap disk and then started
spitting out lots of:
try_to_free_page: state(0) stop(9) i(xxx) sleep instead of fail
xxx started as a small number but was growing large and negative. I let
it run this way for a bit, and noticed the keyboard seemed totally dead.
After a few minutes of this scrolling, I hit the reset button.
The system used was my tomcat II dual P120, 64mb RAM, both disks on a
BT-946, running an SMP kernel without any of the special SMP deadlock
patches.
- ------------------------------------------------------------------
Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will
Network Administrator | be proof-read for $199/message.
Florida Digital Turnpike | =20
________Finger jlewis@inorganic5.fdt.net for PGP public key_______
------------------------------
From: Dan Hollis <goemon@sasami.anime.net>
Date: Mon, 9 Jun 1997 16:26:10 -0700 (PDT)
Subject: GP with 2.0.30 + pre2 patch : ksymoops + gdb info included
Linux 2.0.30 with pre-2 patch.
SYN and RST protection enabled.
No modules configured, everything is static.
I am getting this GP about once a day, it is always caused by squid.
general protection: 0000
CPU: 0
EIP: 0010:[<001460e4>]
EFLAGS: 00010213
eax: f000e987 ebx: 00000000 ecx: 00c3303c edx: f000f84d
esi: 00c330d8 edi: 000001a1 ebp: 00c33018 esp: 015b2ee8
ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
Process squid (pid: 6498, process nr: 28, stackpage=3D015b2000)
Stack: 00c33018 015b2f7c 00000000 00000800 1122da8a 00c3303c 00000000 =
000001a1=20
03408018 01e83828 0123d136 00150a02 00c33018 015b2f78 00000e5e =
00000800=20
00000000 015b2f7c 00000fff 01e837e0 0820b828 01e8386c 00136d03 =
01e8386c=20
Call Trace: [<00150a02>] [<00136d03>] [<00122627>] [<0010a54d>]=20
Code: 8a 40 0d a8 02 74 04 ff 4c 24 10 8b 7c 24 10 39 7b 30 0f 87=20
>>EIP: 1460e4 <tcp_recvmsg+170/40c>
Trace: 150a02 <inet_recvmsg+72/88>
Trace: 136d03 <sock_read+ab/c0>
Trace: 122627 <sys_read+b3/d8>
Trace: 10a54d <system_call+55/7c>
Code: 1460e4 <tcp_recvmsg+170/40c> movb 0xd(%eax),%al
Code: 1460e7 <tcp_recvmsg+173/40c> testb $0x2,%al
Code: 1460e9 <tcp_recvmsg+175/40c> je 1460ef <tcp_recvmsg+17b/40c>
Code: 1460eb <tcp_recvmsg+177/40c> decl 0x10(%esp,1)
Code: 1460ef <tcp_recvmsg+17b/40c> movl 0x10(%esp,1),%edi
Code: 1460f3 <tcp_recvmsg+17f/40c> cmpl %edi,0x30(%ebx)
Code: 1460f6 <tcp_recvmsg+182/40c> ja 90909018 <_EIP+90909018>
(gdb) l *0x001460e4
0x1460e4 is in tcp_recvmsg (tcp.c:1666).
1661 while (skb !=3D (struct sk_buff =
*)&sk->receive_queue)
1662 {
1663 if (before(*seq, skb->seq))
1664 break;
1665 offset =3D *seq - skb->seq;
1666 if (skb->h.th->syn)
1667 offset--;
1668 if (offset < skb->len)
1669 goto found_ok_skb;
1670 if (skb->h.th->fin)
(gdb) l *0x00150a02
0x150a02 is in inet_recvmsg (af_inet.c:863).
858
859 /* We may need to bind the socket. */
860 if(inet_autobind(sk) !=3D 0)
861 return(-EAGAIN);
862
863 return(sk->prot->recvmsg(sk, ubuf, size, noblock, =
flags,addr_len));
864 }
865
866
867 static int inet_sendmsg(struct socket *sock, struct msghdr *msg, =
int size, int noblock,=20
(gdb) l *0x00136d03
0x136d03 is in sock_read (socket.c:353).
348 msg.msg_iovlen=3D1;
349 msg.msg_control=3DNULL;
350 iov.iov_base=3Dubuf;
351 iov.iov_len=3Dsize;
352
353 return(sock->ops->recvmsg(sock, &msg, =
size,(file->f_flags & O_NONBLOCK), 0,&msg.msg_namelen));
354 }
355
356 /*
357 * Write data to a socket. We verify that the user area =
ubuf..ubuf+size-1 is
(gdb) l *0x00122627
0x122627 is in sys_read (read_write.c:132).
127 if (error)
128 goto out;
129 error =3D verify_area(VERIFY_WRITE,buf,count);
130 if (error)
131 goto out;
132 error =3D file->f_op->read(inode,file,buf,count);
133 out:
134 fput(file, inode);
135 bad_file:
136 return error;
(gdb) l *0x0010a54d
No source file for address 0x10a54d.
------------------------------
From: Dan Hollis <goemon@sasami.anime.net>
Date: Mon, 9 Jun 1997 16:44:25 -0700 (PDT)
Subject: Re: pre-2.0.31-1 crash
On Mon, 9 Jun 1997, Jon Lewis wrote:
> try_to_free_page: state(0) stop(9) i(xxx) sleep instead of fail
>=20
> xxx started as a small number but was growing large and negative. I =
let
> it run this way for a bit, and noticed the keyboard seemed totally =
dead.
> After a few minutes of this scrolling, I hit the reset button.
>=20
> The system used was my tomcat II dual P120, 64mb RAM, both disks on a
> BT-946, running an SMP kernel without any of the special SMP deadlock
> patches.
The *exact* same thing happened to our news server during an expire a =
few
days ago.
Single CPU P90, 64mb RAM, NCR 53c8xx using the BSD ported driver.
I thought it was a fluke, but I guess it's not.
- -Dan
------------------------------
From: Solar Designer <solar@false.com>
Date: Tue, 10 Jun 1997 04:53:21 -0300 (GMT+3)
Subject: Re: Non-executable stack patch
Hello!
=20
> What about mapping libc always onto addresses that have a 0xab******
> pattern, and then forbidding character '0xab' in argv[] and envp[] =
strings
> [done by the kernel].
Well, there's a similar idea which I already implemented, and which I =
like
better (since people need characters like 0xab allowed).
It is to map libc at 0x00001000+ so there's always a zero byte in the
address. That way it's not possible to pass any parameters to the =
function
being called, since in most cases you have to overflow with an ASCIIZ =
string.
And even if there's a suitable function with no parameters, you would =
have to
overwrite the return address only, not fill with a pattern =
(unfortunately
x86s are little endian, so the address itself can be put in ASCIIZ; it =
will
terminate the string though).
Here goes a dirty kernel patch for mmap(), use it in addition to my
non-executable stack patch. Warning: this is x86-only, I should make a
#define in some architecture-specific includes in the real patch =
instead.
- --- /extra/linux-2.0.30/mm/mmap.c Fri Nov 22 11:25:17 1996
+++ linux/mm/mmap.c Mon Jun 9 02:20:25 1997
@@ -308,7 +308,7 @@
if (len > TASK_SIZE)
return 0;
if (!addr)
- - addr =3D TASK_SIZE / 3;
+ addr =3D 0x00001000;
addr =3D PAGE_ALIGN(addr);
=20
for (vmm =3D find_vma(current->mm, addr); ; vmm =3D vmm->vm_next) {
I'm running this right now, no problems so far (both ELF and a.out =
binaries
work just fine).
Signed,
Solar Designer=20
------------------------------
From: "David S. Miller" <davem@jenolan.rutgers.edu>
Date: Mon, 9 Jun 1997 20:42:01 -0400
Subject: Re: GP with 2.0.30 + pre2 patch : ksymoops + gdb info included
I'm beginning to suspect some things about this bug, they are always
reported to crash in the same place and I have yet to find a way that
the receive queue can become corrupt.
Can you send me the results of gcc's compiling of this file on _your_
system. My current theory is that gcc is miscompiling net/ipv4/tcp.c
with the version you are using. Just do
make net/ipv4/tcp.s
cat net/ipv4/tcp.s | mail davem@caip.rutgers.edu
Thanks.
------------------------------
From: fb <fb@chibacity.com>
Date: Mon, 9 Jun 1997 20:53:24 -0500 (EST)
Subject: Re: PCI netcards that are good for Linux
just to put my two cents in:
i have had a great time with cheap ne2k clones
i have two linux boxen linked up each with $26 pci ne2k clones and i
routienely get > 1000k/s (compressed data) on ftp xfers between them
excusse the speeling
nick
fb@chibacity.com
On Mon, 9 Jun 1997, Aaron Tiensivu wrote:
> I'm curious about a certain PCI card that our work just got
> for a few of our machines. How do the SMC EtherPower PCI cards hold =
out under
> load and performance-wise in general and under Linux? I noticed it was =
based
> off a Digital chip and I vaguely remember hearing bad things on the =
list about
> lots of the 'tulip' cards that were as bad as the ne2000 cards.
>=20
> Any info would be grand. :)
>=20
>=20
>=20
------------------------------
From: Jeremy Fitzhardinge <jeremy@zip.com.au>
Date: Tue, 10 Jun 1997 11:32:33 +1000
Subject: Re: Bug in chown -- always kills suid/sgid bits.
Geoffrey D. Bennett wrote:
> > I don't
> > know what SUID does for directories,
>=20
> AFAIK, SUID does nothing for directories. Anyone else know?
Setting SGID on a directory means that all new files created in the
directory inherit the directory's group, and new directories within it
also get SGID. It's useful for having something like a project
directory, so all files belonging to the project have the same group.
The potential security concern is that if the SGID directory is writable
to all, and someone not in the directory's group creates a file there,
they get to own a file in a group they don't belong to. This would (in
theory) allow them to set SGID on that file, and be able to become a
member of that group. In practice, Linux prevents them from setting
SGID on their file, but there's a bug because chmod silently fails
rather than with an EPERM. This seems to be deliberate, so I'm not sure
if its worth fixing (fs/inode.c:inode_change_ok() silently squashes the
SGID bit rather than returning -EPERM).
J
------------------------------
From: "David S. Miller" <davem@jenolan.rutgers.edu>
Date: Mon, 9 Jun 1997 22:02:01 -0400
Subject: Re: low memory buffer cachebug fix, need some testers...
Date: Mon, 9 Jun 1997 13:34:06 +0200
From: "Dr. Werner Fink" <werner@suse.de>
--- /usr/src/linux/mm/page_alloc.c Sat Aug 17 20:19:29 1996
+++ /tmp/page_alloc.c Mon Jun 9 13:30:16 1997
@@ -214,7 +214,7 @@
return 0;
}
restore_flags(flags);
- if (priority !=3D GFP_BUFFER && try_to_free_page(priority, dma, 1))
+ if (try_to_free_page(priority, dma, 1))
goto repeat;
return 0;
}
Without this change your patch may not have any effect on the swap =
behaviour.
Aha, good eyes. I've put this into my tree.
The only remaining issue is how try_to_free_page() does not try hard
enough, this is what causes gcc to die with a signal. My old "sleep
instead of fail" hack is not going back in, it is a kludge and can
create other problems.
I will look into a better fix for that one.
- ---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
- -----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
------------------------------
From: "David S. Miller" <davem@jenolan.rutgers.edu>
Date: Mon, 9 Jun 1997 22:15:24 -0400
Subject: Re: [2.1.41] kernel: a.out: Exception at ...
Date: Mon, 2 Jun 1997 02:15:05 +0200 (CEST)
From: Regis Duchesne <regis@via.ecp.fr>
The small piece of code (at the end of this mail) triggers a =
reproducible
exception :
Celine kernel: a.out: Exception at [<c015c1de>] (c017c5cb)
Where my System.map shows :
c015c1a8 T devinet_ioctl <-- in net/ipv4/devinet.c
c015c5e4 T destroy_sock
This is probably because the 3rd argument of ioctl() is NULL instead =
of
being a struct ifreq * (according to man ioctl_list). Neithertheless,
shouldn't this be checked instead of letting it cause an exception?
Is it normal?
Note that the ioctl rightly returns -1 with errno=3D"Bad address" =
though.
This behavior is completely correct, the kernel message is just for
debugging (showing that the bad address was caught and the situation
has been corrected) which is why you get the right return value back.
There is no bug.
- ---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
- -----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
------------------------------
From: Bill Hawes <whawes@star.net>
Date: Mon, 09 Jun 1997 23:05:51 -0400
Subject: Re: low memory buffer cachebug fix, need some testers...
David S. Miller wrote:
> The only remaining issue is how try_to_free_page() does not try hard
> enough, this is what causes gcc to die with a signal.
Another issue that might be affecting the ability to free up pages is
that the current read-ahead algorithm doesn't seem to be sensitive to
the system memory levels. Reading a file will cause the read-ahead to
vacuum up any free pages, and even though they're only loosely bound as
inode cache, it may take a couple of sweeps of shrink_mmap to free them
again.
Has anyone experimented with shutting off read-ahead when the available
memory drops below some threshold?
- -Bill
------------------------------
From: fb <fb@chibacity.com>
Date: Mon, 9 Jun 1997 23:28:14 -0500 (EST)
Subject: Re: Non-executable stack patch
Hey man, btw I love your John the Ripper
frostbyte
fb@chibacity.com
On Tue, 10 Jun 1997, Solar Designer wrote:
> Hello!
> =20
> > What about mapping libc always onto addresses that have a 0xab******
> > pattern, and then forbidding character '0xab' in argv[] and envp[] =
strings
> > [done by the kernel].
>=20
> Well, there's a similar idea which I already implemented, and which I =
like
> better (since people need characters like 0xab allowed).
>=20
> It is to map libc at 0x00001000+ so there's always a zero byte in the
> address. That way it's not possible to pass any parameters to the =
function
> being called, since in most cases you have to overflow with an ASCIIZ =
string.
> And even if there's a suitable function with no parameters, you would =
have to
> overwrite the return address only, not fill with a pattern =
(unfortunately
> x86s are little endian, so the address itself can be put in ASCIIZ; it =
will
> terminate the string though).
>=20
> Here goes a dirty kernel patch for mmap(), use it in addition to my
> non-executable stack patch. Warning: this is x86-only, I should make a
> #define in some architecture-specific includes in the real patch =
instead.
>=20
> --- /extra/linux-2.0.30/mm/mmap.c Fri Nov 22 11:25:17 1996
> +++ linux/mm/mmap.c Mon Jun 9 02:20:25 1997
> @@ -308,7 +308,7 @@
> if (len > TASK_SIZE)
> return 0;
> if (!addr)
> - addr =3D TASK_SIZE / 3;
> + addr =3D 0x00001000;
> addr =3D PAGE_ALIGN(addr);
> =20
> for (vmm =3D find_vma(current->mm, addr); ; vmm =3D vmm->vm_next) {
>=20
> I'm running this right now, no problems so far (both ELF and a.out =
binaries
> work just fine).
>=20
> Signed,
> Solar Designer=20
>=20
>=20
------------------------------
From: Ingo Molnar <mingo@pc7537.hil.siemens.at>
Date: Tue, 10 Jun 1997 07:31:29 +0200 (MET DST)
Subject: Re: Non-executable stack patch
On 9 Jun 1997, Aaron M. Ucko wrote:
> Ingo Molnar <mingo@pc7537.hil.siemens.at> writes:
>=20
> > What about mapping libc always onto addresses that have a 0xab******
> > pattern, and then forbidding character '0xab' in argv[] and envp[] =
strings
> > [done by the kernel].
>=20
> That's an incredibly bad idea, in part because 0xab is a legitimate
> character in many sets, including ISO 8859-1 (in which it's a left
> guillemot).
just think one step forward, most (one-byte ...) character sets have
'illegal' characters, get the point? Anyways, Solar Designer's zero
character idea is really elegant and much simpler ;)=20
- -- mingo
------------------------------
From: Jon Lewis <jlewis@inorganic5.fdt.net>
Date: Tue, 10 Jun 1997 02:04:32 -0400 (EDT)
Subject: 2.0.30 Oops with portslave
This is from a friend's system. /usr/local/port/bin/pppd really did not
exist at the time...but should that have resulted in such damage?
Jun 9 20:28:40 ts-1 port[S5]: Connected - waiting for login
Jun 9 20:28:41 ts-1 port[S5]: Detected login for AutoPPP
Jun 9 20:28:41 ts-1 port[S5]: PPP frames detected - switching to PPP =
mode
Jun 9 20:28:41 ts-1 port[S5]: /usr/local/port/bin/pppd: No such file or =
directory
Jun 9 20:28:41 ts-1 port[S5]: Session done.
Jun 9 20:28:41 ts-1 kernel: Unable to handle kernel paging request at
virtual address 00000004
Jun 9 20:28:41 ts-1 kernel: current->tss.cr3 =3D 00a95000, Lr3 =3D =
00a95000
Jun 9 20:28:41 ts-1 kernel: *pde =3D 00000000
Jun 9 20:28:41 ts-1 kernel: Oops: 0002
Jun 9 20:28:41 ts-1 kernel: CPU: 0
Jun 9 20:28:41 ts-1 kernel: EIP: 0010:[<0011c75e>]
Jun 9 20:28:41 ts-1 kernel: EFLAGS: 00010207
Jun 9 20:28:41 ts-1 kernel: eax: 0000001b ebx: 0000001b ecx: =
00000006
edx: 00da6000
Jun 9 20:28:41 ts-1 kernel: esi: 00da6000 edi: 400b9000 ebp: =
002815b8
esp: 00acff58
Jun 9 20:28:41 ts-1 kernel: ds: 0018 es: 002b fs: 002b gs: 002b
ss: 0018
Jun 9 20:28:41 ts-1 kernel: Process portslave (pid: 210, process nr: =
26,
stackpage=3D00acf000)
Jun 9 20:28:41 ts-1 kernel: Stack: 00000018 00a7c500 00000000 00001000=20
00dd21f8 00000000 00000000 00000000=20
Jun 9 20:28:41 ts-1 kernel: 00000000 00000001 00000001 00000000=20
00000000 00000000 00000000 0012247e=20
Jun 9 20:28:41 ts-1 kernel: 00dd21f8 00a7c500 400b9000 00001000=20
00ad9810 00001000 400b9000 bffff260=20
Jun 9 20:28:41 ts-1 kernel: Call Trace: [<0012247e>] [<0010a602>]=20
Jun 9 20:28:41 ts-1 kernel: Code: f3 a5 83 e3 03 89 d9 f3 a4 07 ff 4d =
14
01 44 24 44 01 44 24=20
>>EIP: 11c75e <sys_mlock+16/74>
Trace: 12247e <grow_files+6a/84>
Trace: 10a602 <reschedule+2/10>
Code: 11c75e <sys_mlock+16/74> repz movsl %ds:(%esi),%es:(%edi)
Code: 11c760 <sys_mlock+18/74> andl $0x3,%ebx
Code: 11c763 <sys_mlock+1b/74> movl %ebx,%ecx
Code: 11c765 <sys_mlock+1d/74> repz movsb %ds:(%esi),%es:(%edi)
Code: 11c767 <sys_mlock+1f/74> popl %es
Code: 11c768 <sys_mlock+20/74> decl 0x14(%ebp)
Code: 11c76b <sys_mlock+23/74> addl %eax,0x44(%esp,1)
Code: 11c76f <sys_mlock+27/74> addl %eax,0x0(%esp,1)
Code: 11c773 <sys_mlock+2b/74> nop
Code: 11c774 <sys_mlock+2c/74> nop
Code: 11c775 <sys_mlock+2d/74> nop
- ------------------------------------------------------------------
Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will
Network Administrator | be proof-read for $199/message.
Florida Digital Turnpike | =20
________Finger jlewis@inorganic5.fdt.net for PGP public key_______
------------------------------
From: Rogier Wolff <wolff@adder.et.tudelft.nl>
Date: Mon, 9 Jun 1997 22:29:03 +0200 (MET DST)
Subject: Re: Loop Encryption
>=20
> On Jun 06, 1997 at 02:40:06PM, Andrew E. Mileski wrote:
> > It appears there are two possible deadlocks caused by the loop =
driver.
> > 1) Running out of requests
> > 2) Running out of buffers.
>=20
> Btw, what happens if you leave "holes" in the file which is mounted=20
> by loop filesystem, fill the fs with the loop file in it, and then try =
to=20
> fill the loop fs.. Will there be a -ENOSPC or a crash?
Currently loop already "panics" when it finds a hole in a file that
it mounts. Should be fixed.... :-)
Roger.
------------------------------
From: Rogier Wolff <wolff@adder.et.tudelft.nl>
Date: Mon, 9 Jun 1997 22:35:31 +0200 (MET DST)
Subject: Re: Ext2fs and hashed table.
>=20
> Hi,
>=20
> smurf@work.smurf.noris.de (Matthias Urlichs) writes:
>=20
> The main reasons that dump goes to disk directly are (a) to allow
> offline backup of unmounted devices, but more importantly (b)
> performance. Dump goes through the system in inode order, scanning
> blocks sequentially where possible, rather than going through the
> nearly random order that a directory scan would imply.
I find the "performance" thing questionable:
I once rewrote "fsck" (*) to do things efficiently. Instead of=20
doing things as they pop up, the "queue" of things to do was sorted
by block number. The whole fsck would be done in 5 passes through the
queue. (So the head would only do about 5 passes from block 0 through
the higher numbers....)
The result was about 10 or 20 percent faster than the "default" fsck
that didn't do the ordering right. I gave up then....
Roger.
(*) minix fsck, on Minix....
------------------------------
From: Rogier Wolff <wolff@adder.et.tudelft.nl>
Date: Mon, 9 Jun 1997 22:27:22 +0200 (MET DST)
Subject: Re: another pre-2.0.31 problem
Ruud van Hemert wrote:
> I had the same problems as you did, also with a masqueraded local =
network
> and a Teles 16.3 ISDN-card.(also tried several kernel-versions and
> patches)
> For some reasons however I had set (a long time ago) the MTU for the =
eth0
> at 1500 on my masqueraded hosts and for the ippp0 on the gateway at =
576
> After changing the eth0 MTU-size on all my masqueraded hosts also at =
576,
> the problem went away....
> Don't now the technical details about it, but I can imagine that a =
sort
> of overflow will occur when you try to transmit packages with a size =
of
> 1500, and the gateway have to resize the packages to 576
Nono. This is not a "you can fix it by doing this", but a "because
it goes away when I do this, the bug must be THERE".
You possibly found the conditions to trigger this bug: masquerading=20
with different MTUs on the different channels. The networking-experts
should have a look at trying to reproduce this, and fixing it....
Roger.
------------------------------
From: Hans Lermen <lermen@elserv.ffm.fgan.de>
Date: Tue, 10 Jun 1997 10:34:39 +0200 (MET DST)
Subject: Re: Non-executable stack patch
On Tue, 10 Jun 1997, Solar Designer wrote:
>=20
> It is to map libc at 0x00001000+ so there's always a zero byte in the
^^^^^^^^^^
Which definitively will break dosemu and all other VM86 stuff.
Hans
<lermen@fgan.de>
------------------------------
From: Thomas Pornin <bip@nostromo.ens.fr>
Date: Tue, 10 Jun 1997 10:37:41 +0200
Subject: Re: PCI netcards that are good for Linux
In article <Pine.LNX.3.95.970609205145.22376C-100000@penfold.local.net> =
you write:
>just to put my two cents in:
>
>i have had a great time with cheap ne2k clones
>i have two linux boxen linked up each with $26 pci ne2k clones and i
>routienely get > 1000k/s (compressed data) on ftp xfers between them
Well, the fact is even those cards can do that; we have here a small
ethernet network (a dozen computers), allmost all of them have ne2000
clones, and we often have the 1 MB/s. But, during such a ftp, the linux
boxes spend much cpu, as the cards are not smart enough to do anything =
by
themselves. I once had a 486 which could not go faster than 500 kB/s =
with
the same card.
Anyway, when you do no nfs, ne2000 are just fine. PCI ne2000 clones are
some strange things which are useful when you are short of IRQ's and ISA
slots.
My 2 cents also.
--Thomas Pornin
------------------------------
From: Eric.Schenk@dna.lth.se
Date: Tue, 10 Jun 1997 10:47:17 +0200
Subject: Re: another pre-2.0.31 problem=20
Rogier Wolff <wolff@adder.et.tudelft.nl> writes:
>Nono. This is not a "you can fix it by doing this", but a "because
>it goes away when I do this, the bug must be THERE".
>
>You possibly found the conditions to trigger this bug: masquerading=20
>with different MTUs on the different channels. The networking-experts
>should have a look at trying to reproduce this, and fixing it....
Exactly. I've caught the PPP driver doing something silly along these
lines, and I'll be looking over the ISDN stuff as soon as I get enough
free time. Hopefully within the week. I'd already been suspicious of
something going wrong in that code, and this pretty much confirms it.
- --=20
Eric Schenk www: =
http://www.dna.lth.se/~erics
Dept. of Comp. Sci., Lund University email: =
Eric.Schenk@dna.lth.se
Box 118, S-221 00 LUND, Sweden fax: +46-46 13 10 21 ph: +46-46 222 96 =
38
------------------------------
From: "Mike A. Harris" <mharris@blackwidow.saultc.on.ca>
Date: Tue, 10 Jun 1997 04:49:13 -0400 (EDT)
Subject: Re: Repeat the Ending
On Mon, 9 Jun 1997, Geert Uytterhoeven wrote:
> We could use a redesign of the console system. Things I'd like to see:
>=20
> - separation between generic console stuff and low-level (VGA) stuff
> - scrollback on all VCs, using a decent implementation (i.e. not =
depending
> on VGA features, since they're of no use to me)
>=20
> The way GGI does it (using the `scroller' interface) could be a start =
(but GGI
> isn't perfect neither, for machines without a hardware text mode).
>=20
> If you want to know more about the machines without VGA text mode, =
please let
> me know.
I have 18 local consoles, 5 to 10 of which I'm always logged in
on. Since my VGA is only a 1meg card, the scrollback buffers are
virtually useless to me, even more so if X is running. I'd
definately like to see the console system re-written to allow a
user defined buffer size for individual consoles. That way you
could have consoles with and consoles without a buffer, and each
console could have a different sized buffer. The vga hardware
method is not very good IMHO.
I'm very much interested in your thoughts.
TTYL
Mike A. Harris | =
http://blackwidow.saultc.on.ca/~mharris
Computer Consultant | Coming soon: =
dynamic-IP-freedom...
My dynamic address: =
http://blackwidow.saultc.on.ca/~mharris/ip-address.html
Email: mharris at blackwidow.saultc.on.ca <-- Spam proof address
Close windows, and OpenDOS! http://www.caldera.com/dos/dos.htm
------------------------------
From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
Date: Tue, 10 Jun 1997 11:07:45 +0200 (MET DST)
Subject: Re: Repeat the Ending
On Tue, 10 Jun 1997, Mike A. Harris wrote:
>On Mon, 9 Jun 1997, Geert Uytterhoeven wrote:
>
>> We could use a redesign of the console system. Things I'd like to =
see:
>>=20
>> - separation between generic console stuff and low-level (VGA) =
stuff
>> - scrollback on all VCs, using a decent implementation (i.e. not =
depending
>> on VGA features, since they're of no use to me)
>>=20
>> The way GGI does it (using the `scroller' interface) could be a start =
(but GGI
>> isn't perfect neither, for machines without a hardware text mode).
>>=20
>> If you want to know more about the machines without VGA text mode, =
please let
>> me know.
>
>I have 18 local consoles, 5 to 10 of which I'm always logged in
>on. Since my VGA is only a 1meg card, the scrollback buffers are
>virtually useless to me, even more so if X is running. I'd
>definately like to see the console system re-written to allow a
>user defined buffer size for individual consoles. That way you
>could have consoles with and consoles without a buffer, and each
>console could have a different sized buffer. The vga hardware
>method is not very good IMHO.
>
>I'm very much interested in your thoughts.
You can find my abstract console patch at
http://www.cs.kuleuven.ac.be/~geert/bin/abscon-native-2.1.42.diff.gz
(for Linux/m68k 2.1.42: abscon-m68k-2.1.42.diff.gz)
Here are some explanations, and my console wishes:
- =
-------------------------------------------------------------------------=
-------
Amigas and Ataris don't have a text mode, so we use bitmapped graphics =
through
our frame buffer device. Other features we have:
- console.c always writes in a shadow image of the screen and then =
calls
optimized drawing operations (through struct consw in =
<linux/console.h>).
- scrolling up/down is done through a hardware trick
- each virtual console can have a different size. This is especially
important if you have more than one video board, with different =
resolutions
on each video board. Support for more than one video board is
work-in-progress.
What we don't have:
- scrollback support
SPARCs don't have text mode neither, and the same is true for the TGA =
driver.
My `abstract console' patch merges our console.c (which was
arch/m68k/kernel/console.c) with drivers/char/console.c. After applying =
it all
m68k console stuff is fully integrated.
What I'd like to see is a full split-off of the high-level and low-level
drawing operations.
- high-level:
o console.c performs all operations on a shadow image of the =
screen and
calls the low-level driver through an API similar to our struct consw.
o the shadow screen is large enough to provide a scrollback buffer =
for
all virtual consoles (not only for the current, cfr. VGA), without
using VGA tricks.
o the shadow screen could be 32-bit, allowing for 16-bit =
characters
(unicode), 4-bit foreground/background color, and 8 bit extra
attributes. VGA color can't draw bold or underlined color characters,
but bitmapped displays can!
o to speed up scrolling, the shadow screen can be a circular =
buffer.
- low-level:
o provides operations for
- block clear and copy
- draw one or more characters
- scroll (a part of) the screen
- draw/hide cursor
- blank the screen
- get/set font
- set palette
o characters are translated from the 32-bit representation to =
something
that fits on the screen.
This way a low-level driver can be written for
- hardware text mode
- bitmapped graphics text mode emulation
There also exist graphics board with a separate CPU (and memory) that =
can only
be accessed through some I/O registers (e.g. boards with a Texas =
Instruments
TMS34010 Graphical Signal Processor like the A2410 and DMI Resolver on =
Amiga).
These boards don't have memory visible from the host CPU but they are =
supported
through our struct consw. Jes Soerensen wrote a driver for his board, =
but it's
not yet integrated in the main source tree due to legal problems.
If you have some comments or questions, don't hesitate to tell me!
- =
-------------------------------------------------------------------------=
-------
Greetings,
Geert
- --
Geert Uytterhoeven =
Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/m68k on Amiga =
http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- =
Belgium
------------------------------
From: Gestor de Sistemes <sistema@readysoft.es>
Date: Tue, 10 Jun 1997 11:16:04 +0200 (MET DST)
Subject: Re: another pre-2.0.31 problem=20
On 10 Jun, Eric.Schenk@dna.lth.se wrote:
>=20
> Rogier Wolff <wolff@adder.et.tudelft.nl> writes:
>>Nono. This is not a "you can fix it by doing this", but a "because
>>it goes away when I do this, the bug must be THERE".
>>
>>You possibly found the conditions to trigger this bug: masquerading=20
>>with different MTUs on the different channels. The networking-experts
>>should have a look at trying to reproduce this, and fixing it....
>=20
> Exactly. I've caught the PPP driver doing something silly along these
> lines, and I'll be looking over the ISDN stuff as soon as I get enough
> free time. Hopefully within the week. I'd already been suspicious of
> something going wrong in that code, and this pretty much confirms it.
I=B4ve lived with this bug for the last year with all kernel versions =
and
ipppd releases.
When the MTUs are different (eth and ippp), 2 things can happen:
- -the kernel hangs completely when someone dials in
- -not everything is reachable from the masqueraded hosts:
* some web images don=B4t go through the gateway
* cannot pop mimed mail from an external host
=09
And the last one I=B4ve discovered is when you choose 1500 as the MTU =
for
all the interfaces. After a few bytes socket tranmissions stop
completely. For instance listing an FTP directory and starting MC. The
ISDN connection remains, but I have to kill the hang apps.
My final workaround has been setting an MTU of 576. Till now everything
seems to work ok, but I still haven=B4t tested it enough to be 100% =
sure.
If you nedd further testing I=B4ll be pleased to help in anything I can.
Thank you
Pau Aliagas
Ready Soft
------------------------------
From: Olaf Titz <olaf@bigred.inka.de>
Date: Tue, 10 Jun 1997 11:11:17 +0200
Subject: Re: do the resource limits still work?
> I was able to dynamically malloc/statically allocate objects with
> more than 3MB.
> Any suggestion?
Try _writing_ to that memory. Memory that is allocated but never
accessed does not count other than for virtual size.
Look at the "swapout" program delivered with ftape. I called it from
conf.modules to allocate 10M and it reliably failed, until I realized
I had set a 10M data limit earlier :-)
olaf
------------------------------
From: Martin Mares <mj@atrey.karlin.mff.cuni.cz>
Date: Tue, 10 Jun 1997 13:04:45 +0200
Subject: Re: Problems with 'objdump' compiling 2.0.30 kernel
Hi,
> I ran into a problem compiling the 2.0.30 kernel. I had some problems
> regarding 'objdump' which didn't understand the '-k -q' switches. I =
traced
> the problem down to my brandnew 'objdump' from binutils 2.8.=20
>=20
> I've checked an older version of 'objdump' from a machine I installed
> recently and that version supports the '-k -q' switches. I contacted =
some
> guy (who's E:mail address I found in a Linux newsgroup ) who told me =
that
> he heard about a fix for this problem. I guess that the fix is =
changing
> the parameters for the 'objdump' step in one of the make files. The
> problem is that I'm not sure which parameters I should use.
>=20
> The only problem is that this helpfull guy didn't know where to find =
the
> fix. Luckily he gave me this E:mail address to ask further questions.
> Could you please help me with my (relatively small) problem ?
The problem is probably that you were upgrading to binutils 2.8 from
an older version and an obsolete "encaps" utility was not deleted. The =
2.0.X kernel
makefiles recognize version of binutils by testing if encaps is there
or not and choose the appropriate set of parameters based on this.
Deleting /usr/bin/encaps (or renaming it) should help.
Martin
------------------------------
From: Martin Mares <mj@atrey.karlin.mff.cuni.cz>
Date: Tue, 10 Jun 1997 13:08:08 +0200
Subject: Re: PCI netcards that are good for Linux
Hi,
> I'm curious about a certain PCI card that our work just got
> for a few of our machines. How do the SMC EtherPower PCI cards hold =
out under
> load and performance-wise in general and under Linux? I noticed it was =
based
> off a Digital chip and I vaguely remember hearing bad things on the =
list about
> lots of the 'tulip' cards that were as bad as the ne2000 cards.
I didn't test 10Mbit SMC's, but the 100Mbit ones are really =
excellent.
10.5 MByte per second between two PC's! (e.g., 3Coms on the same setup
were capable of transmitting approx. 7 MB/sec).
On the other hand, I think such questions are a bit off-topic on this =
list.
Martin
------------------------------
From: Eric Youngdale <eric@andante.jic.com>
Date: Tue, 10 Jun 1997 07:42:11 -0400 (EDT)
Subject: Re: Non-executable stack patch
On Mon, 9 Jun 1997, Ingo Molnar wrote:
> this way it would be harder to generate a valid libc address via =
parameter
> overflow? [i'm assuming that the only open communication channel to =
get
> attack code into the process is argv[] and envp[]]
>=20
> Also, an attack warning could be issued if the kernel detects =
'illegal'
> characters in parameter strings (for priviledged processes only). [how
> 'illegal' is defined depends on locale settings]
There is another point I haven't seen anyone mention. When the
kernel delivers a signal (on i386 anyways), we push a small sequence of
instructions onto the stack that effectively make the sigreturn() =
syscall.
For this to work, the stack must be executable, since that is where the
small little code fragment that makes the sigreturn syscall can be =
found.
Blindly prohibiting all stacks from being executable will essentially
completely break signal handling.
- -Eric
------------------------------
End of linux-kernel-digest V1 #941
**********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@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".
------ =_NextPart_000_01BC75BB.5F2AB5E0--