--PAF00195.896102052/wigner.cstc.org
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Mon, 25 May 1998 06:30:06 +0200
from pol@wigner.cstc.org [192.168.1.2]
----- The following addresses had transient non-fatal errors -----
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"
(expanded from: <pol@wigner.cstc.org>)
----- Transcript of session follows -----
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... mbox.est.it: Name server timeout
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... Deferred: Name server: host name lookup failure
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
--PAF00195.896102052/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Mon, 25 May 1998 06:30:06 +0200
Final-Recipient: RFC822; <pol@wigner.cstc.org>
X-Actual-Recipient: RFC822; |exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1@wigner.cstc.org
Action: delayed
Status: 4.4.3
Last-Attempt-Date: Mon, 25 May 1998 15:14:12 +0200
Will-Retry-Until: Sat, 30 May 1998 06:30:06 +0200
--PAF00195.896102052/wigner.cstc.org
Content-Type: message/rfc822
Return-Path: <linux-kernel@vger.rutgers.edu>
Received: from wigner.cstc.org (pol@wigner.cstc.org [192.168.1.2])
by wigner.cstc.org (8.8.8/8.8.8/Debian/GNU) with ESMTP id GAA01363
for <pol@wigner.cstc.org>; Mon, 25 May 1998 06:30:06 +0200
From: linux-kernel@vger.rutgers.edu
Received: from mbox.est.it
by wigner.cstc.org (fetchmail-4.3.9 POP3)
for <pol/wigner.cstc.org> (single-drop); Mon, 25 May 1998 06:30:06 CEST
Message-ID: <294167@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 25 May 1998 05:31:18 GMT +0100
Subject: linux-kernel-digest V1 #2012
<<< Questo messaggio e' la parte 2 di un precedente messaggio >>>
+ else if (selector == (reg_fs & ~3)) {
+ which = "FS";
+ require = SEG_NEED_VALID | SEG_NEED_READ | SEG_NEED_NZ;
+ }
+ else if (selector == (reg_gs & ~3)) {
+ which = "GS";
+ require = SEG_NEED_VALID | SEG_NEED_READ | SEG_NEED_NZ;
+ }
+ if (which)
+ printk(KERN_WARNING "write_ldt: selector %04x in use by %s\n",
+ selector, which);
- - lp = (unsigned long *) (LDT_ENTRY_SIZE * ldt_info.entry_number + (unsigned long) mm->segments);
+ lp = (__u32 *) ((selector & ~7) + (char *) ldt);
+
/* Allow LDTs to be cleared by the user. */
- - if (ldt_info.base_addr == 0 && ldt_info.limit == 0
- - && (oldmode ||
- - ( ldt_info.contents == 0
- - && ldt_info.read_exec_only == 1
- - && ldt_info.seg_32bit == 0
- - && ldt_info.limit_in_pages == 0
- - && ldt_info.seg_not_present == 1
- - && ldt_info.useable == 0 )) ) {
- - *lp = 0;
- - *(lp+1) = 0;
- - return 0;
+ if (ldt_info.base_addr == 0 && ldt_info.limit == 0) {
+ if (oldmode ||
+ (ldt_info.contents == 0 &&
+ ldt_info.read_exec_only == 1 &&
+ ldt_info.seg_32bit == 0 &&
+ ldt_info.limit_in_pages == 0 &&
+ ldt_info.seg_not_present == 1 &&
+ ldt_info.useable == 0 )) {
+ entry_1 = 0;
+ entry_2 = 0;
+ attrib |= SEG_IS_ZERO;
+ goto out_check;
+ }
}
- - *lp = ((ldt_info.base_addr & 0x0000ffff) << 16) |
+
+ entry_1 = ((ldt_info.base_addr & 0x0000ffff) << 16) |
(ldt_info.limit & 0x0ffff);
- - *(lp+1) = (ldt_info.base_addr & 0xff000000) |
- - ((ldt_info.base_addr & 0x00ff0000)>>16) |
+ entry_2 = (ldt_info.base_addr & 0xff000000) |
+ ((ldt_info.base_addr & 0x00ff0000) >> 16) |
(ldt_info.limit & 0xf0000) |
- - (ldt_info.contents << 10) |
((ldt_info.read_exec_only ^ 1) << 9) |
+ (ldt_info.contents << 10) |
+ ((ldt_info.seg_not_present ^ 1) << 15) |
(ldt_info.seg_32bit << 22) |
(ldt_info.limit_in_pages << 23) |
- - ((ldt_info.seg_not_present ^1) << 15) |
0x7000;
- - if (!oldmode) *(lp+1) |= (ldt_info.useable << 20);
- - return 0;
+ if (!oldmode)
+ entry_2 |= (ldt_info.useable << 20);
+
+ /* N.B. perform validation checks */
+ if (ldt_info.read_exec_only)
+ attrib |= SEG_IS_NOTWRITE;
+ if (!(ldt_info.contents & MODIFY_LDT_CONTENTS_CODE))
+ attrib |= SEG_IS_NOTCODE;
+
+ /*
+ * Check whether any attributes conflict with requirements.
+ */
+out_check:
+ if (require & attrib)
+ goto out_busy;
+
+ /* OK to change the entry ... */
+ *lp = entry_1;
+ *(lp+1) = entry_2;
+ error = 0;
+#ifdef LDT_PARANOIA
+printk("write_ldt: loaded %04x, entry=(%08x, %08x)\n",
+selector, entry_1, entry_2);
+#endif
+out:
+ return error;
+
+out_busy:
+ error = -EBUSY;
+ printk("write_ldt: can't change %04x to (%08x, %08x)\n",
+ selector, entry_1, entry_2);
+ goto out;
}
asmlinkage int sys_modify_ldt(int func, void *ptr, unsigned long bytecount)
{
- - int ret;
+ int ret = -ENOSYS;
lock_kernel();
- - if (func == 0)
+ switch (func) {
+ case 0:
ret = read_ldt(ptr, bytecount);
- - else if (func == 1)
- - ret = write_ldt(ptr, bytecount, 1);
- - else if (func == 0x11)
- - ret = write_ldt(ptr, bytecount, 0);
- - else
- - ret = -ENOSYS;
+ break;
+ case 1:
+ ret = write_ldt(ptr, bytecount, 1, (struct pt_regs *) &func);
+ break;
+ case 0x11:
+ ret = write_ldt(ptr, bytecount, 0, (struct pt_regs *) &func);
+ break;
+ }
unlock_kernel();
return ret;
}
- --- linux-2.1.103/arch/i386/kernel/traps.c.old Tue May 5 11:20:01 1998
+++ linux-2.1.103/arch/i386/kernel/traps.c Sun May 24 17:37:52 1998
@@ -66,6 +66,10 @@
unlock_kernel(); \
}
+/*
+ * N.B. The use of %fs in these macros can cause problems
+ * if the selector is invalid ... use another register?
+ */
#define get_seg_byte(seg,addr) ({ \
register unsigned char __res; \
__asm__("pushl %%fs;movl %%ax,%%fs;movb %%fs:%2,%%al;popl %%fs" \
@@ -83,6 +87,21 @@
__asm__("movl %%fs,%%ax":"=a" (__res):); \
__res;})
+#define _gs() ({ \
+register unsigned short __res; \
+__asm__("movl %%gs,%%ax":"=a" (__res):); \
+__res;})
+
+#define _ldt() ({ \
+register unsigned short __res; \
+__asm__("sldt %%ax":"=a" (__res):); \
+__res;})
+
+#define _tr() ({ \
+register unsigned short __res; \
+__asm__("str %%ax":"=a" (__res):); \
+__res;})
+
void page_exception(void);
asmlinkage void divide_error(void);
@@ -129,17 +148,23 @@
esp = regs->esp;
ss = regs->xss & 0xffff;
}
+
printk("CPU: %d\nEIP: %04x:[<%08lx>]\nEFLAGS: %08lx\n",
smp_processor_id(), 0xffff & regs->xcs, regs->eip, regs->eflags);
printk("eax: %08lx ebx: %08lx ecx: %08lx edx: %08lx\n",
regs->eax, regs->ebx, regs->ecx, regs->edx);
printk("esi: %08lx edi: %08lx ebp: %08lx esp: %08lx\n",
regs->esi, regs->edi, regs->ebp, esp);
- - printk("ds: %04x es: %04x ss: %04x\n",
- - regs->xds & 0xffff, regs->xes & 0xffff, ss);
- - store_TR(i);
- - printk("Process %s (pid: %d, process nr: %d, stackpage=%08lx)\nStack: ",
- - current->comm, current->pid, 0xffff & i, 4096+(unsigned long)current);
+ printk("ds: %04x es: %04x ss: %04x fs: %04x gs: %04x\n",
+ regs->xds & 0xffff, regs->xes & 0xffff, ss, _fs(), _gs());
+
+ i = (current->tarray_ptr - &task[0]);
+ printk("Process %s (pid: %d, process nr: %d, stackpage=%08lx)\n",
+ current->comm, current->pid, i, 4096+(unsigned long)current);
+ printk("ldt: %04x tss.ldt: %04x LDT: %04x tr: %04x TSS: %04x\n",
+ _ldt(), current->tss.ldt, (__u16)_LDT(i), _tr(), (__u16)_TSS(i));
+
+ printk("Stack: ");
stack = (unsigned long *) esp;
for(i=0; i < kstack_depth_to_print; i++) {
if (((long) stack & 4095) == 0)
- --- linux-2.1.103/kernel/fork.c.old Sun May 17 12:19:40 1998
+++ linux-2.1.103/kernel/fork.c Sun May 24 21:28:14 1998
@@ -310,6 +310,10 @@
if (clone_flags & CLONE_VM) {
mmget(current->mm);
+ /*
+ * Set up the LDT descriptor for the clone task.
+ */
+ copy_segments(nr, tsk, NULL);
SET_PAGE_DIR(tsk, current->mm->pgd);
return 0;
}
- --------------D6E59D8048D9105C22BE315F--
------------------------------
From: "Michael J. McGillick" <mike@dungeon.ne.mediaone.net>
Date: Sun, 24 May 1998 22:33:30 -0400 (EDT)
Subject: Re: Upgrading to a test kernel
Hello:
I'm gonna ask a dumb question here, but this script assumes that I have
NFS support either built-in or as a module, correct?
- - Mike
On Sun, 24 May 1998, Riley Williams wrote:
> Hi there.
>
> >> Looking for some help from the Red Hat users on this list (or
> >> knowledgable others). I've tried a couple of times before to
> >> upgrade my existing RH 5.0 system to one of the test kernels, but
> >> I usually end up screwing up one thing or another. I have read the
> >> documentation, and I've tried to upgrade almost of the packages
> >> necessary as listed by the minimum version numbers in the
> >> documentation.
>
> >> If anyone is currently running RH 5.0, and has successfully gotten
> >> to the point of running a test kernel, I would like to discuss the
> >> steps that you took to get to that point.
>
> In my case, here's the procedure I used to update to the latest of
> everything...I use the RedHat mirror on SunSite.doc.ic.ac.uk but the
> following should also work with RedHat's own site...
>
> Q> #!/bin/bash
> Q> mkdir /redhat
> Q> mount -t nfs -o ro,soft,rsize=8192,wsize=8192 \
> Q> 193.63.255.4:/public/Mirrors/ftp.redhat.com/ /redhat
> Q> cd /redhat/pub/redhat/current/updates/i386
> Q> for Z in *.i386.rpm ; do
> Q> X=`echo $Z | sed 's/-[0-9]*\./ /' | cut -d ' ' -f 1`
> Q> Y=`rpm -q $X 2> /dev/null`
> Q> if [ "$Y" != '' ]; then
> Q> if [ $Y.i386.rpm != $Z ]; then
> Q> echo "Updating $Y.i386.rpm to $Z" >&2
> Q> rpm -Uvh $Z
> Q> fi
> Q> fi
> Q> done
> Q> cd /
> Q> umount /redhat
> Q> rmdir /redhat
>
> The result of the above sequence is that ALL of your currently
> installed RedHat-supplied RPM's are updated to the latest versions,
> thus reducing the problems caused by old versions...
>
> Best wishes from Riley.
>
------------------------------
From: Kevin Lentin <kevinl@cs.monash.edu.au>
Date: Mon, 25 May 1998 12:36:46 +1000
Subject: Re: size of files in /proc
On Fri, May 22, 1998 at 03:47:57PM +0000, Ton Hospel wrote:
> > I don't get this bit. Why can't there be a race? File gets created, size 0.
> > NFS stats. File gets written to. NFS says no data in file. EOF.
> Valid behaviour. NFS sampled a file property (size), and since it's zero,
> this also implies the file contents (empty).
> > Comapred to:
> > File has 100 bytes. NFS stats. File gets appended to. NFS reads and returns
> > 200 bytes.
> That's what NFS does, and is what I would expect from a program with
> copy semantics.
So why do you accept different behaviour in the two situations. Why not
argue that NFS should accept the answer from stat or try the read, not do
different things depending on the result?
- --
[======================================================================]
[ Kevin Lentin Email: K.Lentin@cs.monash.edu.au ]
[ finger kevinl@fangorn.cs.monash.edu.au for PGP public key block. ]
[ KeyId: 06808EED FingerPrint: 6024308DE1F84314 811B511DBA6FD596 ]
[======================================================================]
------------------------------
From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Sun, 24 May 1998 19:39:59 -0700
Subject: Re: Modularized x86 math emulation PATCH against pre-2.1.104-1
Michael Chastain <mailto:mec@shout.net> writes:
>In arch/i386/config.in, your patch redefines the default processor type
>from Pentium to 386 -- this looks gratuitous.
You're right. That was an accident. We build our kernels
here for 386 so that they will run on all x86 micprocessors, including
ones that do not have a bswap instruction. I failed to filter out
that difference.
>I'm more concerned about the use of CONFIG_MATH_EMULATION_MODULE in
>arch/i386/kernel/traps.c. I think that math_emulate_hook is fine.
>But I think that it's bad to make the resident kernel be different
>depending on whether or not a particular module is compiled. So I
>recommend taking out these tests and compiling in math_emulate_hook
>and the new code in math_emulate unconditionally.
Rather than using words like "good" or "bad", if you
state your concerns in terms of cause and effect, and let the
goodness or badness of those effects speak for themselves, people
who read your posting will better understand the dynamics of the
problem your are describing.
By using CONFIG_MATH_EMULATION_MODULE, I was able to
ensure that if this patch is integrated into the kernel, users
who choose not to modularize the math emulation will not lose
a single CPU cycle to accomodate the math being available as a
loadable module. Speed tends to be a particularly important metric
for math, even software math emulation on a 386, unlike, say, with
the code Advanced Power Management or control of the keyboard lights.
If your concern is about maintainability, I disagree and I
agree. I disagree that the selection of modular math emulation
makes the code so different when one is writing source code. The
semantics of the three interface routines that talk to the math
emulation (math_emulate, {save,restore}_i387_soft) are unchanged.
Hook variables are a popular easily understood programming technique,
and the concept of replacing these hook variables with direct
references to their corresponding routines when those routines
are being compiled in is also a commonly practiced optimization
technique.
So, I think the relatively small complexity increase is
worth the benefit to users who really want FPU emulation to go fast
(probably people running donated used computers in school, or trying
to build minimum cost embedded devices). After all, in the case of
math_emulate, we're talking about something that gets executed on
every floating point instruction. There is actually some further
optimization to the code path to math_emulate that I was thinking
of doing, that would make it more consistent with the way
{save,restore}_i387_state works, by the way.
On the other hand, I do agree with the objective of
basically having just one kernel for ordinary situations. As you
may recall, we have that here. We have a "./configure" script in
the kernel that basically modularizes everything that can be
modularized, answers "yes" to all boolean questions and takes
the default values for everything else, with a few special
cases. This is how I think most people should build the
Linux kernel, "./confiugre ; make all ; make install", just like
most other pieces of free software. (The install builds an
initial ramdisk that does Plug'n'Play hardware probes to
mount the root partition.) Ultimately, I think "make config",
and "make xconfig" will, for most users, will fade into
obscurity. At that point, it might make sense to look at
the kernel and consider deleting most of the infrastructure for
having most kernel modules "compiled in", because then the
memory savings, minor additional performance benefits and
much bigger code simplication benefits will probably outweigh
this optimization to the code path for math emulation; it may
even be a win on performance alone at that point.
I do not actually feel that strongly about this issue,
especially if I do fix the code path for math_emulate() in
he modularized case. I'd be happy to see modularized math
emulation integrated into the main kernel distribution or on
vger or anywhere else in either form.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 205
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
------------------------------
From: Dean Gaudet <dgaudet-list-linux-kernel@arctic.org>
Date: Sun, 24 May 1998 20:27:52 -0700 (PDT)
Subject: Re: threaded apps and default file descriptor flags
I wrote the below message a while back while the list was broken... or
at least I wasn't receiving messages. So I'm including it for those who
don't have the context. You may want to skip down and read it first.
A larger problem, which I didn't even attack in my previous message, is that
threaded servers can easily run out of file descriptors. There are the
following demands on file descriptors in a server such as Apache:
- log files
- listening network sockets
- client sockets
- outgoing proxy sockets
- read-only open file handles
I'll skip the demands that other libraries may impose, such as database
connections.
Consider for a moment also that Linux may need sendfile() (aka
<<< Continua nel prossimo messaggio >>>
--PAF00195.896102052/wigner.cstc.org--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu