Re: [PATCH] 2.4.0-prerelease: preemptive kernel.
On Thu, Jan 04, 2001 at 08:35:02AM +0100, Daniel Phillips wrote: > A more ambitious way to proceed is to change spinlocks so they can sleep > (not in interrupts of course). There would not be any extra overhead Imagine what happens when a non sleeping spinlock in a interrupt waits for a "sleeping spinlock" somewhere else... I'm not sure if this is a good idea. Sleeping locks everywhere would imply scheduled interrupts, which are nasty. I think a better way to proceed would be to make semaphores a bit more intelligent and turn them into something like adaptive spinlocks and use them more where appropiate (currently using semaphores usually causes lots of context switches where some could probably be avoided). Problem is that for some cases like your producer-consumer pattern (which has been used previously in unreleased kernel code BTW) it would be a pessimization to spin, so such adaptive locks would probably need a different name. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Abort x86 assemble code
hugang <[EMAIL PROTECTED]> wrote:
> I have following code ,and I can not understand the mark line,who can tell
>me.thanks.
> 0ec7 xorl 0x400dec(,%eax,4),%ecx<-What it
>to do.
extern u_int32_t eax;
extern u_int32_t ecx;
{
u_int32_t *ptr;
ptr = (u_int32_t *)((eax * 4) + 0x400dec);
ecx ^= *ptr;
}
Commonly used in the above form (with a fixed displacement) to access a
32bit value within an array of 32bit values.
The array start offset would be hardwired at 0x400dec, the zero based
index into the array is provided by eax.
--
Darryl Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: So, what about kwhich on RH6.2?
Silly question: can't we just hardwire `kgcc' into the build system and be done with all this kwhich stuff? It's just a symlink - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Journaling: Surviving or allowing unclean shutdown?
Alex Belits wrote: > > On Wed, 3 Jan 2001, Daniel Phillips wrote: > > > I don't doubt that if the 'power switch' method of shutdown becomes > > popular we will discover some applications that have windows where they > > can be hurt by sudden shutdown, even will full filesystem data state > > being preserved. Such applications are arguably broken because they > > will behave badly in the event of accidental shutdown anyway, and we > > should fix them. Well-designed applications are explicitly 'serially > > reuseable', in other words, you can interrupt at any point and start > > again from the beginning with valid and expected results. > > I strongly disagree. All valid ways to shut down the system involve > sending SIGTERM to running applications -- only broken ones would > live long enough after that to be killed by subsequent SIGKILL. > > A lot of applications always rely on their file i/o being done in some > manner that has atomic (from the application's point of view) operations > other than system calls -- heck, even make(1) does that. Nobody is forcing you to hit the power switch in the middle of a build. But now that you mention it, you've provided a good example of a broken application. Make with its reliance on timestamps for determining build status is both painfully slow and unreliable. What happens if you adjust your system clock? That said, Tux2 can preserve the per-write atomicity quite easily, or better, make could take advantage of the new journal-oriented transaction api that's being cooked up and specify its requirement for atomicity in a precise way. Do you have any other examples of programs that would be hurt by sudden termination? Certainly we'd consider a desktop gui broken if it failed to come up again just because you bailed out with the power switch instead of logging out nicely. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: soffice, 2.2.18, cpu 97% idle, loadavg 6.05
What is the compiler? On Wed, 3 Jan 2001 [EMAIL PROTECTED] wrote: > linux 2.2.18 with VM-global patch > 128MB RAM > AMD K6-3/366 > Star Office 5.2 > > I exiting StarOffice, and a little later noticed my loadavg display > widget was showing a high load average. top reports it at 6. > > Poking about, I found all the soffice.bin processes still hanging > around. > > Looking with top, all the soffice.bin processes are in the 'D N' state. > In top's 'no idle' mode they are listed. > > The CPU is hanging around 97% idle, the loadavg has been sitting > at 6+ for almost 15 minutes. It seems likely this state will > continue forever. > > I tried a 'kill' on all the soffice.bin process and there was > no change. a 'kill -9' also had no effect. > > What is going on? > > Shouldn't I be able to tear down the processes? > > Here is status on the soffice.bin process with the lowest PID: > > # cat /proc/5294/status > Name: soffice.bin > State: D (disk sleep) > Pid:5294 > PPid: 775 > Uid:101 101 101 101 > Gid:101 101 101 101 > Groups: 101 0 10 228 229 500 > VmSize: 103600 kB > VmLck: 0 kB > VmRSS: 49588 kB > VmData:13008 kB > VmStk: 1104 kB > VmExe:88 kB > VmLib: 73604 kB > SigPnd: 4100 > SigBlk: 8000 > SigIgn: 80001000 > SigCgt: 0003bfc064ff > CapInh: > CapPrm: > CapEff: > > Thanks, > > -- > Brian Litzinger <[EMAIL PROTECTED]> > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: generic_file_write code segment in 2.2.18
On Wed, Jan 03, 2001 at 09:29:48PM -0800, Asang K Dani wrote:
> hi everyone,
>I was trying to understand following piece of code in
> 'generic_file_read' (mm/filemap.c) for 2.2.18 kernel. The code
> segment
> is as follows:
>
>
> dest = (char *) page_address(page) + offset;
> if (dest != buf) { /* See comment in
> update_vm_cache_cond. */
> bytes -= copy_from_user(dest, buf, bytes);
> flush_dcache_page(page_address(page));
> }
> status = -EFAULT;
> if (bytes)
> status = inode->i_op->updatepage(file, page,
>
> offset, bytes, sync);
>
> unlock:
> /* Mark it unlocked again and drop the page.. */
> clear_bit(PG_locked, &page->flags);
> wake_up(&page->wait);
> page_cache_release(page);
>
> if (status < 0)
> break;
>
> written += status;
> count -= status;
> pos += status;
> buf += status;
>
> copy_from_user returns the number of bytes copied from userspace
> to 'dest'. In case it succeeds, 'bytes' will be set to 0 after the
> call. However, 'status' is set to -EFAULT. So wouldn't it break
> out of the while loop (prematurely)?
The code is buggy as far as I can see. copy_from_user doesn't return the
number of bytes copied, but the number of bytes not copied when an error
occurs (or 0 on success).
Correct would be:
--- linux-work/mm/filemap.c-o Wed Jan 3 17:37:27 2001
+++ linux-work/mm/filemap.c Thu Jan 4 08:48:42 2001
@@ -1685,11 +1685,11 @@
*/
dest = (char *) page_address(page) + offset;
if (dest != buf) { /* See comment in update_vm_cache_cond. */
- bytes -= copy_from_user(dest, buf, bytes);
+ if (copy_from_user(dest, buf, bytes))
+ status = -EFAULT;
flush_dcache_page(page_address(page));
}
- status = -EFAULT;
- if (bytes)
+ if (!status)
status = inode->i_op->updatepage(file, page, offset, bytes,
sync);
unlock:
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: try_to_swap_out() return value problem?
On Thu, 4 Jan 2001, Marcelo Tosatti wrote:
>
> Your latest changes to try_to_swap_out() does not seem to be obviously
> correct.
Heh. What a polite way of saying that you think I'm full of sh*t ;)
> Having swap_cnt == 0 does not necessarily mean that we successfully freed
> a page (look at the page aging and locking checks in try_to_swap_out).
No.
What it means, though, is that we did finish what we set out to do.
Nothing more.
> Now refill_inactive() relies on the assumption that swap_out() returning
> 1 means we successfully freed a page:
>
> while (swap_out(priority, gfp_mask)) {
> made_progress = 1;
> if (--count <= 0)
> goto done;
> }
Well, refill-inactive really relies on the assumption that _some_ progress
was made, which was certainly true. "swap_out()" returning 1 has not
actually meant that a page has been free'd for a _long_ long time: it's
meant that _something_ changed (ie "we added one page to the swap cache"
or similar).
I agree that the return value of swap_out() is fairly meaningless. It's
been fairly meaningless for a long time now, and it's entirely possible
that the "while (swap_out())" loop should be just something like
/* Scan the VM space, try to clean up the page tables a bit */
for (i = 0 ; i <= nr_threads >> priority; i++)
swap_out(gfp_mask);
which just tries to move pages out of the page tables, so that the _real_
page freeing logic (ie page_launder() and friends) have more to work with.
This is especially true these days as swap_out() really doesn't do any IO
at all (and has thus finally become completely misnamed: it's not so much
swapping stuff out, as just aging the page tables).
As it is, I think that the above is fairly close to what the code
effectively ends up actually _doing_. Even if it's not really written that
way.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.0-prerelease: preemptive kernel.
ludovic fernandez wrote: > The following patch makes the kernel preemptable. > It is against 2.4.0-prerelease on for i386 only. > It should work for UP and SMP even though I > didn't validate it on SMP. > Comments are welcome. I was expecting to see this sometime in 2.5, not quite so soon... The key idea here is to disable preemption on spin lock and reenable on spin unlock. That's a practical idea, highly compatible with the current way of doing things. Its a fairly heavy hit on spinlock performance, but maybe the overall performance hit is small. Benchmarks are needed. A more ambitious way to proceed is to change spinlocks so they can sleep (not in interrupts of course). There would not be any extra overhead for this on spin_lock (because the sleep test is handled off the fast path) but spin_unlock gets a little slower - it has to test and jump on a flag if there are sleepers. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
try_to_swap_out() return value problem?
Hi Linus,
Your latest changes to try_to_swap_out() does not seem to be obviously
correct.
- if (mm->swap_cnt)
- mm->swap_cnt--;
+ if (!mm->swap_cnt)
+ return 1;
+
+ mm->swap_cnt--;
Having swap_cnt == 0 does not necessarily mean that we successfully freed
a page (look at the page aging and locking checks in try_to_swap_out).
Now refill_inactive() relies on the assumption that swap_out() returning
1 means we successfully freed a page:
while (swap_out(priority, gfp_mask)) {
made_progress = 1;
if (--count <= 0)
goto done;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: So, what about kwhich on RH6.2?
>Date:Wed, 03 Jan 2001 22:08:33 -0800 >From: Pete Zaitcev <[EMAIL PROTECTED]> > >Are we going to use Miquel's patch? I cannot build fresh 2.2.x on >plain RH6.2 without it. The 2.2.19-pre6 comes out without it. Or >is "install new bash" the official answer? Alan? > > I do not understand, I just got a working 2.2.19-pre6 build on one of > my 6.2 Sparc64 systems, what kind of failure do you see? Oops. I cannot reproduce it anymore. Since I am quite sure in my recollection of this problem, I conclude that there was a kernel (perhaps 2.2.19-pre3), that called kwhich with several arguments. No problem now on the pre6. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Hollis wrote: > On Wed, 3 Jan 2001, Gerhard Mack wrote: > > On Wed, 3 Jan 2001, Dan Hollis wrote: > > > On Wed, 3 Jan 2001, Gerhard Mack wrote: > > > > Your comparing actual security with stack guarding? Stack guarding mearly > > > > makes the attack diffrent.. rootkits are already available to defeat it. > > > url? > > Ugh do you have any idea how hard it is to find 2 year old exploits? > > Heres the best I could find on short notice: > > http://www.insecure.org/sploits/non-executable.stack.problems.html > > http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html > > You said there were rootkits specifically targetting stackguard. > > These URLs simply describe attacks on stackguard, where are the > stackguard rootkits? I'll correct myself then: there were non exec stack patches. Keep in mind part of the problem is that some compilors actually use that feature look up "trampolines" for more info. Also I was in error to refer to it as stack guarding.. Stack guard is a compilor. I acually use libsafe it's preferable for 2 reasons. 1 It's entirely userspace and it works fine. 2 If someone manages to render it useless I'll simply uninstall it. Gerhard PS Although personally I think linux reoutation is most harmed by distribs who insists on installing software with bad security records. But that's not relevent to linux-kernel. -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH] TLB flush changes for S/390
From: Ulrich Weigand <[EMAIL PROTECTED]> Date:Mon, 1 Jan 2001 23:15:26 +0100 (MET) * Is there some reason why ptep_test_and_clear_young should *not*, after all, flush the TLB? Yes, because the accuracy of that state bit is not required to be %100 perfect. Less SMP tlb flushing traffic from vmscan runs is desirable, thus no flush. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Network Performance?
This may not be the right forum to ask this. If not, please let me know where to ask. I have a Debian box with 2 NICs. Both 100/full duplex. This machine is running as a ftp proxy (T.Rex suite). As part of the traffic going through the box, some streams have 1000k window size for a certain reason. How do I tune the NICs to handle the streams better? There are ways of doing this on other OSs. Right now, the box only does about 1.8Mb when it should be doing 80+Mb. Thanks, Tim PS: This is really something to do with the window size and WAN latency. The ultimate source and destination points are either Solaris or AIX boxes. The files being sent are > 1GB in size. The box does well when traffic goes in one NIC and out the other, as long as the end point is local When it hits the WAN, it all dies. Traffic not going through the box just flies right along, as long as both the end points have the large tcp window size. Putting the Linux box in the middle is a severe choke point. :( -- Tim Sailer <[EMAIL PROTECTED]> Cyber Security Operations Brookhaven National Laboratory (631) 344-3001 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: So, what about kwhich on RH6.2?
Date:Wed, 03 Jan 2001 22:08:33 -0800 From: Pete Zaitcev <[EMAIL PROTECTED]> Are we going to use Miquel's patch? I cannot build fresh 2.2.x on plain RH6.2 without it. The 2.2.19-pre6 comes out without it. Or is "install new bash" the official answer? Alan? I do not understand, I just got a working 2.2.19-pre6 build on one of my 6.2 Sparc64 systems, what kind of failure do you see? Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
__get_swap_page() minor problem
Hi,
If the check for "count >= SWAP_MAP_MAX" in __get_swap_page is true, we
will end up trying to unlock a not-yet-locked spinlock.
Here goes a patch to change this.
--- linux/mm/swapfile.c.origThu Jan 4 04:10:08 2001
+++ linux/mm/swapfile.c Thu Jan 4 04:10:12 2001
@@ -90,8 +90,12 @@
int type, wrapped = 0;
entry.val = 0; /* Out of memory */
- if (count >= SWAP_MAP_MAX)
- goto bad_count;
+ if (count >= SWAP_MAP_MAX) {
+ printk(KERN_ERR "get_swap_page: bad count %hd from %p\n",
+ count, __builtin_return_address(0));
+ return entry;
+ }
+
swap_list_lock();
type = swap_list.next;
if (type < 0)
@@ -130,11 +134,6 @@
out:
swap_list_unlock();
return entry;
-
-bad_count:
- printk(KERN_ERR "get_swap_page: bad count %hd from %p\n",
- count, __builtin_return_address(0));
- goto out;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Abort x86 assemble code
Hello all I have following code ,and I can not understand the mark line,who can tell me.thanks. -- 0eb8 movb (%ebx),%al <> 0eba incl %ebx 0ebb movl %edi,%ecx 0ebd shrl $0x8,%ecx 0ec0 movl %edi,%edx 0ec2 xorb %dl,%al 0ec4 movzbl %al,%eax 0ec7 xorl 0x400dec(,%eax,4),%ecx <-What it to do. 0ece movl %ecx,%edi 0ed0 movl %esi,%eax <-- jmp here 0ed2 decl %esi 0ed3 orl%eax,%eax 0ed5 jne0eb8 0ed7 movl %edi,0x406894 <- 1-4 see here 0edd popl %esi 0ede popl %edi 0edf popl %ebx thanks . - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
So, what about kwhich on RH6.2?
Are we going to use Miquel's patch? I cannot build fresh 2.2.x on plain RH6.2 without it. The 2.2.19-pre6 comes out without it. Or is "install new bash" the official answer? Alan? -- Pete --- linux-2.2.19-pre3/scripts/kwhichSun Dec 10 16:49:45 2000 +++ linux-2.2.19-pre3-p3/scripts/kwhich Sat Dec 23 21:10:33 2000 @@ -7,7 +7,7 @@ exit 1 fi -IFS=: +IFS=":$IFS" for cmd in $* do for path in $PATH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Here's a nickel, kid.
Go write yourself a real OS. 45k text OS design sketch. Forth meets UNIX meets AmigaDos meets INTERCAL meets a Teletype Model 37. ftp://linux01.gwdg.de/pub/cLIeNUX/interim/design Rick Hohensee Forth, unix, cLIeNUX, and worse. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Prerelease kernel will not hotplug a USB host-controller when it is inserted into a Cardbus slot.
David Brownell wrote: > The root cause seems to be the Cardbus/PCI hotplug invocation not > happening for you. Yep. > Was this with or without the "pcmcia_cs" package installed? My > own take on it is that 2.4 _should_ hotplug that controller > just fine if "pcmcia_cs" isn't installed. Otherwise, I'd be > pleasantly surprised to know it works properly. You are more or less correct. I've looked a little bit at the source and now understand a little bit better. It turns out that parts of the Cardbus code in the kernel source includes code from the pcmcia_cs package. The "cs:" messages in the log are generated by this code. I *think* this code reads configuration files from /etc/pcmcia, but I haven't found the place in the code that does it. Anyhow, these messages: cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x280-0x28f 0x378-0x37f 0x3a0-0x3a7 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. change when I modify /etc/pcmcia/config.opts. The /etc/pcmcia/config* files get installed by the pcmcia_cs package, so even when I am only using the cardbus functionality, there seems to be some need to pcmcia_cs, since the config.opts file contains "magic" good defaults numbers for safe irqs, ports and memory ranges. As I have already discussed with David Brownell, there is huge a problem getting a usable cardbus solution with the current pcmcia_cs package. Even when I tell it I am using a 2.4.0 kernel and that I want to use the development kernel's drivers, it maps loads of device IDs to the pcmcia_cs drivers which don't exist in this configuration! For example, it maps the 3c575 device ID to 3c575_cb instead of 3c59x. >> For the Cardbus hotplug event, is it expected that the hotplug >> debug info would be dumped after the insert event is processed >> and the required driver is loaded? > > > No -- you were seeing the USB hotplug event, not the cardbus one. > > Plugging a cardbus OHCI into your machine should cause two hotplug > events ... first for PCI, eventually modprobing "usb-ohci", and > then as that module initializes you'll get a second one for USB, > reporting a new (root) hub. > > So you should see an invocation "arguments (pci) env (...)" > followed by "arguments (usb) env (...)"; but you reported the > second one. Well, I have no idea why the "arguments (pci) env (...)" message wasn't emitted. I do know that with the test12-pre5 kernel I get working hotplug for the BusPort Mobile. Thanks for all your help! Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
generic_file_write code segment in 2.2.18
hi everyone,
I was trying to understand following piece of code in
'generic_file_read' (mm/filemap.c) for 2.2.18 kernel. The code
segment
is as follows:
dest = (char *) page_address(page) + offset;
if (dest != buf) { /* See comment in
update_vm_cache_cond. */
bytes -= copy_from_user(dest, buf, bytes);
flush_dcache_page(page_address(page));
}
status = -EFAULT;
if (bytes)
status = inode->i_op->updatepage(file, page,
offset, bytes, sync);
unlock:
/* Mark it unlocked again and drop the page.. */
clear_bit(PG_locked, &page->flags);
wake_up(&page->wait);
page_cache_release(page);
if (status < 0)
break;
written += status;
count -= status;
pos += status;
buf += status;
copy_from_user returns the number of bytes copied from userspace
to 'dest'. In case it succeeds, 'bytes' will be set to 0 after the
call. However, 'status' is set to -EFAULT. So wouldn't it break
out of the while loop (prematurely)?
Please post/CC your comments to me if this is not of general interest
to the list and is too silly to be answered there.
regards,
Asang Dani
__
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease-ac5 : 'make dep' error
On Wed, 3 Jan 2001 23:51:31 -0500, Frank Davis <[EMAIL PROTECTED]> wrote: >Hello, > I received the following make dep error while compiling >prerelease-ac5 . >make -C acpi fastdep >make[4]: Entering directory `/usr/src/linux/drivers/acpi' >/usr/src/linux/Rules.make:224: *** Recursive variable `CFLAGS' references >itself (eventually). Stop. Which version of make are you running, make --version? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-prerelease: System dies after leaving XF86_4.0.2
Hallo, I've tested 2.4.0prerelease pure - ac1-ac2-ac3-ac4-ac5 and my system crashed whenever I left X. Having switched back to 2.4.0-test13pre7 all is fine. I'm no developer, so if you need more information, give me some hints. kind regards Norbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
On Thu, 4 Jan 2001, Alexander Viro wrote: > > I bet it long predates dcache though.. > > Not too likely. It went in in 2.1.93. Apr 2 1998... > Dcache was there ~50 versions before that. Huh. Is there anything that prevents fragmentation in, say, growing maildirs, where there's nothing but locality to hold the directory inode in cache? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
On Wed, 3 Jan 2001, Oliver Xymoron wrote: > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > On Wed, 3 Jan 2001, Stephen C. Tweedie wrote: > > > > > Having preallocated blocks allocated immediately is deliberate: > > > directories grow slowly and remain closed most of the time, so the > > > normal preallocation regime of only preallocating open files and > > > discarding preallocation on close just doesn't work. > > > > Erm. For directories we would not have the call of discard_prealloc() > > on close(2) - they have NULL ->release() anyway and for them it would > > happen only on ext2_put_inode(), i.e. upon the final dput(). Which would > > not happen while some descendent would stay in dcache. > > I bet it long predates dcache though.. Not too likely. It went in in 2.1.93. Apr 2 1998... Dcache was there ~50 versions before that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-prerelease-ac5 : 'make dep' error
Hello, I received the following make dep error while compiling prerelease-ac5 . Regards, Frank make -C acpi fastdepmake[4]: Entering directory `/usr/src/linux/drivers/acpi'/usr/src/linux/Rules.make:224: *** Recursive variable `CFLAGS' references itself (eventually). Stop.make[4]: Leaving directory `/usr/src/linux/drivers/acpi'make[3]: *** [_sfdep_acpi] Error 2make[3]: Leaving directory `/usr/src/linux/drivers'make[2]: *** [fastdep] Error 2make[2]: Leaving directory `/usr/src/linux/drivers'make[1]: *** [_sfdep_drivers] Error 2make[1]: Leaving directory `/usr/src/linux'make: *** [dep-files] Error 2
Re: [PATCH] Remove more compile warnings in 2.4.0-prerelease
On Tue, 2 Jan 2001, Rich Baum wrote: > Here is a patch that removes more compile warnings from 2.4.0- > prerelease. I left out files that have been fixed by Alan or myself in > the ac kernels. I'll add more options to my config tomorrow to try to > find more of these warnings. > -#endif I2C_PCF8584_H > +#endif /* I2C_PCF8584_H */ [etc.] Here, try this: find -name "*.[ch]" | xargs perl -ne 'print "$ARGV:$_" if /#endif\s+\w/i' You'll find a few hundred of them. Then try this (untested): find -name "*.[ch]" | xargs perl -i -pe 's/#endif\s+(\w.*)/#endif \/\* $1 \/\*/i' ..and save yourself quite a bit of tedium. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bdflush synchronous IO on prerelease-diff
Mind checking out the current prerelease-diff? It fixes this, and cleans up some remaining things (now that we don't task-switch into bdflush for all our cleanup, 'nrefill' should really be much lower to get smoother behavior). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [RFC] ext2_new_block() behaviour
On Wed, 3 Jan 2001, Alexander Viro wrote: > On Wed, 3 Jan 2001, Stephen C. Tweedie wrote: > > > Having preallocated blocks allocated immediately is deliberate: > > directories grow slowly and remain closed most of the time, so the > > normal preallocation regime of only preallocating open files and > > discarding preallocation on close just doesn't work. > > Erm. For directories we would not have the call of discard_prealloc() > on close(2) - they have NULL ->release() anyway and for them it would > happen only on ext2_put_inode(), i.e. upon the final dput(). Which would > not happen while some descendent would stay in dcache. I bet it long predates dcache though.. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: is eth header is not transmitted
On Thu, Jan 04, 2001 at 09:39:43AM +0530, Sourav Sen wrote: > > Ya, I also noticed if it is skb_push() it may work, but where is > skb_push() called?? ... the following > is part of the fn. call trace for udp send : > > in ip_build_xmit() > > sock_alloc_send_skb() -- allocates the sk_buff > skb_reserve() -- advances the data pointer to by > sizeof(hard_hdr) amt. > skb_put() -- puts the ip_hdr > >> getfrag() --> udp_getfrag_nosum()(assuming chksum off) -- >sets udp_hdr. > memcpy_fromiovecend() -- puts the data after that. > > r->u.dst.output() -- > dev_queue_xmit() -- queues the pkt. dst.output() normally points to ip_output(), which fills the hh in (using appropiate other neighbour callbacks or the hh cache) > Another question is why in sock_alloc_send_skb() , 15 is added to > length field? So that you can use long word accesses and it doesn't fault when the packet happens to be at the end of memory. Actually it is not required anymore with the current memory allocator. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bdflush synchronous IO on prerelease-diff
On Wed, 3 Jan 2001, Marcelo Tosatti wrote: > > Hi Linus, > > I've noticed you changed bdflush to do synchronous IO on page_launder(). > > That seems to be a performance problem, since kflushd will have to wait > for dirty buffers to get synced instead looping on the inactive dirty > list more often. > > Here is a patch to change this. > > --- linux.orig/fs/buffer.c Wed Jan 3 22:43:24 2001 > +++ linux/fs/buffer.c Thu Jan 4 00:28:50 2001 > @@ -2710,7 +2710,7 @@ > > flushed = flush_dirty_buffers(0); > if (free_shortage()) > - flushed += page_launder(GFP_KERNEL, 1); > + flushed += page_launder(GFP_KERNEL, 0); > > /* > * If there are still a lot of dirty buffers around, And here are some dbench numbers: 12 clients / 64M ram without the patch: 10.04 Mb/s with the patch: 14.47 Mb/s 48 clients / 256M ram without the patch: 14.40 Mb/s with the patch: 15.69 Mb/s - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Dell PERC RAID Controller
Oh, and I forgot to mention I'm not subscribed to this mailing list, so please be sure to reply privately with any comments, questions, etc. Regards, Kevin - Original Message - From: "Kevin Traas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 03, 2001 9:22 AM Subject: Dell PERC RAID Controller > Greetings everyone, > > After much frustration in trying to get Debian GNU/Linux (my distro of > choice) installed on a Dell PowerEdge 2450, I've finally found success! > > My problem was finding kernel support for the onboard PERC 3/Si RAID > Controller (Adaptec OEM chipset) so that I could store my root fs with a > RAID array container. Turns out that Adaptec has recently open-sourced the > driver; however, it hasn't been accepted into any of the Linux kernel trees > as of yet. So, I tracked down the driver sources (many thanks to Matt), > patched them (5 patches in total) into 2.2.18, and built my own, new patch > file to incorporate the aacraid 1.0.6 driver into this kernel in one, easy > step. > > For anyone who's interested, you'll find the patch, a patched 2.2.18 kernel > source archive, Debian (potato) installation disk images (with this new > kernel), and other info at: > > http://www.merilus.com/~kevin/aacraid.html > > > Regards, > Kevin Traas > Chief Information Officer > Merilus Technologies, Inc. .:|| Thinking inside the box ||:. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Dell PERC RAID Controller
Greetings everyone, After much frustration in trying to get Debian GNU/Linux (my distro of choice) installed on a Dell PowerEdge 2450, I've finally found success! My problem was finding kernel support for the onboard PERC 3/Si RAID Controller (Adaptec OEM chipset) so that I could store my root fs with a RAID array container. Turns out that Adaptec has recently open-sourced the driver; however, it hasn't been accepted into any of the Linux kernel trees as of yet. So, I tracked down the driver sources (many thanks to Matt), patched them (5 patches in total) into 2.2.18, and built my own, new patch file to incorporate the aacraid 1.0.6 driver into this kernel in one, easy step. For anyone who's interested, you'll find the patch, a patched 2.2.18 kernel source archive, Debian (potato) installation disk images (with this new kernel), and other info at: http://www.merilus.com/~kevin/aacraid.html Regards, Kevin Traas Chief Information Officer Merilus Technologies, Inc. .:|| Thinking inside the box ||:. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: is eth header is not transmitted
Ya, I also noticed if it is skb_push() it may work, but where is skb_push() called?? ... the following is part of the fn. call trace for udp send : in ip_build_xmit() sock_alloc_send_skb() -- allocates the sk_buff skb_reserve() -- advances the data pointer to by sizeof(hard_hdr) amt. skb_put() -- puts the ip_hdr >> getfrag() --> udp_getfrag_nosum()(assuming chksum off) -- sets udp_hdr. memcpy_fromiovecend() -- puts the data after that. r->u.dst.output() -- > dev_queue_xmit() -- queues the pkt. still the data ptr is after hh_hdr, ie. as follows : +--+ | hh_hdr | ip_hdr | udp_hdr | payload | +--+ ^^ ^ || | sk->head sk->data sk->end On a hadr_start_xmit(), ie say for rtl8129_start_xmit(), the data sending takes place from skb->data and not from head. So is hh_hdr not transmitted?? Another question is why in sock_alloc_send_skb() , 15 is added to length field? Sorry to disturb u like this :) sourav On Thu, 4 Jan 2001, Andi Kleen wrote: > On Thu, Jan 04, 2001 at 09:08:06AM +0530, Sourav Sen wrote: > > > > Hi, > > How can it be skb_put(), it only increments the tail/len ptr ?? > > Oops typo, it's skb_push() for the header. > > > > -Andi > > > sourav > > > > On Wed, 3 Jan 2001, Andi Kleen wrote: > > > > > On Wed, Jan 03, 2001 at 10:59:48PM +0530, Sourav Sen wrote: > > > > > > > > Hi, > > > > In the function ip_build_xmit(), immediately after > > > > sk_alloc_send_skb(), skb_reserve(skb, hh_len) is called. Now > > > > skb_reserve(skb,len) only increment the data pointer and tail pointer by > > > > len amt. > > > > > > > > Now in a particular hard_start_xmit() say for rtl8139, the data > > > > transfer is taking place from skb->data : > > > > outl(virt_to_bus(skb->data), ioaddr + TxAddr0 + entry*4) > > > > > > > > So, I cannot understand, if transfer starts from data and not head, is > > > > ethrnet header not transmitted? what I am missing? > > > > > > An skb_put() > > > > > > > > > -Andi > > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-Prerelease :smp_num_cpus undefined while compiling without smp for Athlon
in smp.h macro #define smp_num_cpus etc... have no effect on the kernel_stat.h file . if might be undefined or declared elsewhere as an int or such...I added #define smp_test_num_cpus and replaced the occurence in kernel_stat.h and it worked ok and tried to find where the smp_num_cpus define was getting screwed... no success. this have the effect of unbuildable kernel with options: smp off and athlon on, i don't know about other problematic configurations. I have gcc version 2.96 and make 3.78.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
"Why We Should All Test the New Linux Kernel" on Advogato
I just submitted an article entitled "Why We Should All Test the New Linux Kernel" to http://advogato.org the article is at http://advogato.org/article/224.html If you're not familiar with it, Advogato is an online community for Free Software developers. I would venture to say any Linux kernel developer would qualify for a membership. I hope you like what I have to say. Perhaps if you'd like to encourage a friend to test the kernel you could forward them the URL. Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits
Andi Kleen <[EMAIL PROTECTED]> writes: > On Wed, Jan 03, 2001 at 10:20:37PM -0500, David Huggins-Daines wrote: > > Dan Aloni <[EMAIL PROTECTED]> writes: > > > > > This preliminary, small patch prevents execution of system calls which > > > were executed from a writable segment. > > > > How does signal return work, then? > > Newer glibc sets a sa_restorer. Hmm, maybe sigaction(2) should stop documenting it as "obsolete and should not be used" then :-) -- David Huggins-Daines- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits
On Wed, Jan 03, 2001 at 10:20:37PM -0500, David Huggins-Daines wrote: > Dan Aloni <[EMAIL PROTECTED]> writes: > > > This preliminary, small patch prevents execution of system calls which > > were executed from a writable segment. > > How does signal return work, then? Newer glibc sets a sa_restorer. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits
Dan Aloni <[EMAIL PROTECTED]> writes: > This preliminary, small patch prevents execution of system calls which > were executed from a writable segment. How does signal return work, then? -- David Huggins-Daines- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
bdflush synchronous IO on prerelease-diff
Hi Linus, I've noticed you changed bdflush to do synchronous IO on page_launder(). That seems to be a performance problem, since kflushd will have to wait for dirty buffers to get synced instead looping on the inactive dirty list more often. Here is a patch to change this. --- linux.orig/fs/buffer.c Wed Jan 3 22:43:24 2001 +++ linux/fs/buffer.c Thu Jan 4 00:28:50 2001 @@ -2710,7 +2710,7 @@ flushed = flush_dirty_buffers(0); if (free_shortage()) - flushed += page_launder(GFP_KERNEL, 1); + flushed += page_launder(GFP_KERNEL, 0); /* * If there are still a lot of dirty buffers around, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Prerelease kernel will not hotplug a USB host-controller whenitisinserted into a Cardbus slot.
Hi Miles, >The whole > "Bad PCI invocation" error was a red herring, sorry. Not an endangered species ... even if Tux does like to snack on them! :-) > I have since gone in a tested test12-pre5, test12-pre6 and > test12-pre8. test12-pre5 works. test12-pre6 fails utterly. That's for "Cardbus hotplug". I've had USB hotplugging fine, with the iffy bits being when it combines with the network hotplugging ... those async changes seem to have created some deadlocking paths (while removing some others). > It looks like Cardbus was just completely hosed in that > tree, because I can't get my network card (3c575) to be recognized > by that kernel, either. I checked the patches and Andrew's > "04X" change went into test12-pre8. I just tested test12-pre8 > with both your latest hotplug script, David, and with the > pertinent "0x" locations changed to "04x". Both scripts fail > to load usb-ohci. The root cause seems to be the Cardbus/PCI hotplug invocation not happening for you. Was this with or without the "pcmcia_cs" package installed? My own take on it is that 2.4 _should_ hotplug that controller just fine if "pcmcia_cs" isn't installed. Otherwise, I'd be pleasantly surprised to know it works properly. > For the Cardbus hotplug event, is it expected that the hotplug > debug info would be dumped after the insert event is processed > and the required driver is loaded? No -- you were seeing the USB hotplug event, not the cardbus one. Plugging a cardbus OHCI into your machine should cause two hotplug events ... first for PCI, eventually modprobing "usb-ohci", and then as that module initializes you'll get a second one for USB, reporting a new (root) hub. So you should see an invocation "arguments (pci) env (...)" followed by "arguments (usb) env (...)"; but you reported the second one. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb dc2xx quirk
> > The proximate cause of that Oops looked to be in one of the
> > UHCI drivers, but of course it's also possible that it was
> > triggered by driver misbehavior.
>
> You didn't look hard enough. 8;)
I suspected you had ... :-)
> hub_thread got a disconnect event, called usb_disconnect,
> which tried to call driver->disconnect, which wasn't there
> due to using __devexit without CONFIG_HOTPLUG defined.
Ah, and moved the __devexit code into the
"__exit" segment, which got removed because clearly such
devices could never get removed (no hotplugging).
> > Have we identified anything that actually does anything with
> > code labeled __dev{in,ex}it (or data), beyond putting it into
> > a different section? If so, what's it doing?
>
> That's a great question. I'd like to know the answer also.
(Calling it and oopsing ... sorry, wrong answer! :-)
> Then we can see what the correct fixes should be.
> This patch could just be a short-lived 2.4.0-prerel
> fix-the-oops patch.
Put it into 2.4.0-next, sure.
I suspect the simplest thing is to say that no USB devices
should use those __dev{in,ex}it #defines ... we'd suspected
they were harmless; evidently not.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.0-prerelease: preemptive kernel.
Hello, For hackers, The following patch makes the kernel preemptable. It is against 2.4.0-prerelease on for i386 only. It should work for UP and SMP even though I didn't validate it on SMP. Comments are welcome. NOTES: since the lock implementation is modified, you need obviously to re-compile all your modules. I introduced a dependency between spinlock.h and sched.h and this has some bad side effects: Some files will generate warnings during the compilation complaining that disable_preempt()/enable_preempt() are not defined. The warnings should be harmless but I was too lazy to fix all of them. If the compilation fails because of that, there is big chance to fix things by including sched.h in the cfile. Ludo. diff -u --recursive linux-2.4-prerelease.org/arch/i386/kernel/apic.c linux-2.4-prerelease/arch/i386/kernel/apic.c --- linux-2.4-prerelease.org/arch/i386/kernel/apic.cWed Jan 3 17:19:44 2001 +++ linux-2.4-prerelease/arch/i386/kernel/apic.cWed Jan 3 12:58:57 2001 @@ -726,6 +726,7 @@ * interrupt lock, which is the WrongThing (tm) to do. */ irq_enter(cpu, 0); + disable_preempt(); smp_local_timer_interrupt(regs); irq_exit(cpu, 0); } @@ -746,6 +747,8 @@ if (v & (1 << (SPURIOUS_APIC_VECTOR & 0x1f))) ack_APIC_irq(); + disable_preempt(); + /* see sw-dev-man vol 3, chapter 7.4.13.5 */ printk(KERN_INFO "spurious APIC interrupt on CPU#%d, should never happen.\n", smp_processor_id()); @@ -776,6 +779,9 @@ 6: Received illegal vector 7: Illegal register address */ + + disable_preempt(); + printk (KERN_ERR "APIC error on CPU%d: %02lx(%02lx)\n", smp_processor_id(), v , v1); } diff -u --recursive linux-2.4-prerelease.org/arch/i386/kernel/entry.S linux-2.4-prerelease/arch/i386/kernel/entry.S --- linux-2.4-prerelease.org/arch/i386/kernel/entry.S Wed Jan 3 17:19:44 2001 +++ linux-2.4-prerelease/arch/i386/kernel/entry.S Wed Jan 3 12:58:57 2001 @@ -79,6 +79,8 @@ need_resched = 20 tsk_ptrace = 24 processor = 52 +preemptable = 56 + ENOSYS = 38 @@ -203,6 +205,9 @@ call *SYMBOL_NAME(sys_call_table)(,%eax,4) movl %eax,EAX(%esp) # save the return value ENTRY(ret_from_sys_call) + movl $1, %edx + lock + xaddl %edx, preemptable(%ebx) #ifdef CONFIG_SMP movl processor(%ebx),%eax shll $CONFIG_X86_L1_CACHE_SHIFT,%eax @@ -213,13 +218,22 @@ testl SYMBOL_NAME(irq_stat)+4,%ecx # softirq_mask #endif jne handle_softirq - + cmpl $0, %edx # task is preemptable ? + jne check_signal ret_with_reschedule: cmpl $0,need_resched(%ebx) jne reschedule +check_signal: +#if 0 + movl EFLAGS(%esp), %eax # mix EFLAGS and CS + movb CS(%esp), %al + testl $(VM_MASK | 3), %eax # return to user mode ? + je restore_all # no bypass signal check +#endif cmpl $0,sigpending(%ebx) jne signal_return restore_all: + decl preemptable(%ebx) RESTORE_ALL ALIGN @@ -270,14 +284,22 @@ #endif jne handle_softirq +/* + * ret_from_intr is the common path used to return + * from interruptions (either hard of soft) and exceptions. + * At that point the preemption is disabled + * (see do_IRQ and handle_softirq) + * Reenable the preemption, verify that the current thread + * is preemptable and check for a pending scheduling request. + */ ENTRY(ret_from_intr) GET_CURRENT(%ebx) - movl EFLAGS(%esp),%eax # mix EFLAGS and CS - movb CS(%esp),%al - testl $(VM_MASK | 3),%eax # return to VM86 mode or non-supervisor? - jne ret_with_reschedule - jmp restore_all - + cmpl $1, preemptable(%ebx) + jne restore_all + cmpl $0, state(%ebx)# current task is running ? + jne restore_all + jmp ret_with_reschedule + ALIGN handle_softirq: call SYMBOL_NAME(do_softirq) @@ -286,6 +308,7 @@ ALIGN reschedule: call SYMBOL_NAME(schedule)# test + decl preemptable(%ebx) jmp ret_from_sys_call ENTRY(divide_error) @@ -316,6 +339,13 @@ movl %edx,%ds movl %edx,%es GET_CURRENT(%ebx) +/* + * All exceptions are called with the preemption disabled. + * In addition, some of them (page_fault) are not reentrant + * and need to be atomic until the preemption can be disabled. + */ + incl preemptable(%ebx) + sti call *%edi addl $8,%esp jmp ret_from_exception @@ -334,6 +364,7 @@ pushl $-1 # mark this as an int SAVE_ALL GET_CURRENT(%ebx) + incl preemptable(%ebx) pushl $ret_from_exception movl %cr0,%eax testl $0x4,%eax # EM (math emulation bi
Re: [RFC] prevention of syscalls from writable segments, breaking bug exploits
On Wed, Jan 03, 2001 at 04:54:38PM -0500, Alexander Viro wrote: > > Win: 0 > Loss: cost of find_vma() (and down(&mm->mmap_sem), BTW) on every system It could actually be optimized a lot, e.g. by just read/writing to a byte in the caller's current code page and handling the exception. But I agree with you that it's rather useless. It'll break some existing exploits, but it's so easy to workaround that exploit writers would quickly adapt and then you have a ugly check with no purpose after a few weeks. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Prerelease kernel will not hotplug a USB host-controller when it isinserted into a Cardbus slot.
There was also a big change to pci/setup_bus.c and pci/setup_bus.h from Ivan Kokshaysky in test12-pre6. Those changes seem like another likely candidate. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Prerelease kernel will not hotplug a USB host-controller when it isinserted into a Cardbus slot.
Here's the pci.c patch from test12-pre6. Does anything in this patch
look like it might cause the cardbus device detection and calling of
hotplug to break?
diff -u --recursive --new-file v2.4.0-test11/linux/drivers/pci/pci.c
linux/drivers/pci/pci.c
--- v2.4.0-test11/linux/drivers/pci/pci.c Sun Nov 19 18:44:12 2000
+++ linux/drivers/pci/pci.c Tue Dec 5 11:04:39 2000
@@ -354,16 +354,16 @@
run_sbin_hotplug(struct pci_dev *pdev, int insert)
{
int i;
- char *argv[3], *envp[7];
- char id[20], sub_id[24], bus_id[64], class_id[20];
+ char *argv[3], *envp[8];
+ char id[20], sub_id[24], bus_id[24], class_id[20];
if (!hotplug_path[0])
return;
- sprintf(class_id, "PCI_CLASS=%X", pdev->class >> 8);
+ sprintf(class_id, "PCI_CLASS=%X", pdev->class);
sprintf(id, "PCI_ID=%X/%X", pdev->vendor, pdev->device);
sprintf(sub_id, "PCI_SUBSYS_ID=%X/%X", pdev->subsystem_vendor,
pdev->subsystem_device);
- sprintf(bus_id, "PCI_BUS_ID=%s", pdev->slot_name);
+ sprintf(bus_id, "PCI_SLOT_NAME=%s", pdev->slot_name);
i = 0;
argv[i++] = hotplug_path;
@@ -376,6 +376,7 @@
envp[i++] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
/* other stuff we want to pass to /sbin/hotplug */
+ envp[i++] = class_id;
envp[i++] = id;
envp[i++] = sub_id;
envp[i++] = bus_id;
@@ -539,15 +540,9 @@
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany,
int rom)
{
unsigned int pos, reg, next;
- u32 l, sz, tmp;
- u16 cmd;
+ u32 l, sz;
struct resource *res;
- /* Disable IO and memory while we fiddle */
- pci_read_config_word(dev, PCI_COMMAND, &cmd);
- tmp = cmd & ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
- pci_write_config_word(dev, PCI_COMMAND, tmp);
-
for(pos=0; posresource[pos];
@@ -578,10 +573,10 @@
res->start |= ((unsigned long) l) << 32;
res->end = res->start + sz;
pci_write_config_dword(dev, reg+4, ~0);
- pci_read_config_dword(dev, reg+4, &tmp);
+ pci_read_config_dword(dev, reg+4, &sz);
pci_write_config_dword(dev, reg+4, l);
- if (l)
- res->end = res->start + (((unsigned
long) ~l) << 32);
+ if (sz)
+ res->end = res->start + (((unsigned
long) ~sz) << 32);
#else
if (l) {
printk(KERN_ERR "PCI: Unable to handle
64-bit address for device %s\n", dev->slot_name);}
res->name = dev->name;
}
- pci_write_config_word(dev, PCI_COMMAND, cmd);
}
void __init pci_read_bridge_bases(struct pci_bus *child)
@@ -755,7 +749,7 @@
pci_read_config_dword(dev, PCI_PRIMARY_BUS, &buses);
DBG("Scanning behind PCI bridge %s, config %06x, pass %d\n",
dev->slot_name, buses & 0xff, pass);
- if ((buses & 0xff) && !pcibios_assign_all_busses()) {
+ if ((buses & 0x00) && !pcibios_assign_all_busses()) {
/*
* Bus already configured by firmware, process it in
the first
* pass and just note the configuration.
@@ -772,8 +766,10 @@
if (cmax > max) max = cmax;
} else {
int i;
+ unsigned int cmax = child->subordinate;
for (i = 0; i < 4; i++)
child->resource[i] = &dev->resource[PCI_BRIDGE_RESOURCES+i];
+ if (cmax > max) max = cmax;
}
} else {
/*
Thanks,
Miles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Printing to off-line printer in 2.4.0-prerelease
On Thu, Jan 04, 2001 at 02:09:56AM +0100, Peter Osterlund wrote: > should say that it is obsolete. I think obsolete means "you should never > ever have to use this stuff". Agreed. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc2.96 + prerelease BUG at inode.c:372
> Diego Liziero <[EMAIL PROTECTED]> wrote: > > > >->1: The sound module for my mad16 based card plays the bytes swapped > > (the same module recompiled with egcs-2.91.66 works fine). > > Could you try to figure this one out a bit more? This sounds like a real > compiler issue, whether it is because egcs just happens to get the right > result for bogus kernel source, of whether gcc-2.96 has problems.. I've just recompiled the kernel with the gcc 2.96-69 upgrade from RedHat and the sound module works ok. So it seems a known compiler bug. Diego Liziero ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] isdn_net: release resources on failure
Please apply.
- Arnaldo
--- linux-2.4.0-prerelease/drivers/isdn/isdn_net.c Mon Jan 1 14:42:26 2001
+++ linux-2.4.0-prerelease.acme/drivers/isdn/isdn_net.c Wed Jan 3 18:02:44 2001
@@ -19,7 +19,10 @@
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
+ *
+ * Changes:
+ * Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
+ * - release resources on failure in isdn_net_new - 2001/01/03
*/
#include
@@ -2325,6 +2328,7 @@
memset(netdev, 0, sizeof(isdn_net_dev));
if (!(netdev->local = (isdn_net_local *) kmalloc(sizeof(isdn_net_local),
GFP_KERNEL))) {
printk(KERN_WARNING "isdn_net: Could not allocate device locals\n");
+ kfree(netdev);
return NULL;
}
memset(netdev->local, 0, sizeof(isdn_net_local));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dcache 2nd chance replacement
On Wed, Jan 03, 2001 at 09:09:01PM -0200, Rik van Riel wrote: > Ever heard of slocate / updatedb ? ever heard of somebody killing all other tasks while updatedb is running? Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Printing to off-line printer in 2.4.0-prerelease
On Thu, Jan 04, 2001 at 01:08:01AM +0100, Peter Osterlund wrote: > What do you think about the following patch? It also works for all the > tests mentioned in my previous message. I'm worried somebody needed to disable LP_CAREFUL to print, probably it's not a big deal to keep it. About the lp_wait_ready that's what I had in mind with the "rework" thing and it looks fine. However parport_write can still could silenty discard data, but maybe it can't notice errors with some handshake. I didn't checked the details of the DMA based handshake so Tim needs to comment if this can be considered a final/right fix (I hope it's not ;). Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Hollis wrote: > On Wed, 3 Jan 2001, Gerhard Mack wrote: > > Your comparing actual security with stack guarding? Stack guarding mearly > > makes the attack diffrent.. rootkits are already available to defeat it. > > url? Ugh do you have any idea how hard it is to find 2 year old exploits? Heres the best I could find on short notice: http://www.insecure.org/sploits/non-executable.stack.problems.html http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb dc2xx quirk
If this makes it go away, then by all means apply this patch;
though I don't quite see what the failure mode would be.
The proximate cause of that Oops looked to be in one of the
UHCI drivers, but of course it's also possible that it was
triggered by driver misbehavior.
Have we identified anything that actually does anything with
code labeled __dev{in,ex}it (or data), beyond putting it into
a different section? If so, what's it doing?
I just tried plug/unplug of a dc-240, albeit on a kernel
with HOTPLUG defined (and using OHCI) and it worked without
any Oops.
- Dave
- Original Message -
From: Randy Dunlap <[EMAIL PROTECTED]>
To: josh <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; l-u-d
<[EMAIL PROTECTED]>
Sent: Wednesday, January 03, 2001 11:23 AM
Subject: Re: usb dc2xx quirk
> Hi,
>
> Looks like dc2xx.c shouldn't use __devinit/__devexit
> [patch attached]
> or you should enable CONFIG_HOTPLUG under General Setup.
>
> David?
>
> The ov511 (usb) driver is the only other USB device driver
> that uses __devinit/__devexit.
>
> ~Randy
>
> josh wrote:
> >
> > Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
> > Platform: ix86 (PIII)
> > Problem Hardware: Kodac DC280, firmware 1.01
> >
> > Ever since test10 or after, removing my dc280 from the usb
> > bus causes khubd to crash. I have tried both UHCI drivers
> > and they produce the same effect.
> >
> > dmesg, syslog, messages, and .config can be found at:
> > http://mammoth.org/~skulcap/usb-problem
> >
> > I have looked throug the archives and havent found anything
> > like this, so I'm sorry if it has been covered already.
> >
> > Thanks in advance!
> --
> ___
> |randy.dunlap_at_intel.com503-677-5408|
> |NOTE: Any views presented here are mine alone|
> |& may not represent the views of my employer.|
> ---
> --- linux/drivers/usb/dc2xx.c.org Sun Nov 12 20:40:42 2000
> +++ linux/drivers/usb/dc2xx.c Wed Jan 3 11:15:11 2001
> @@ -353,7 +353,7 @@
>
>
>
> -static void * __devinit
> +static void *
> camera_probe (struct usb_device *dev, unsigned int ifnum, const struct usb_device_id
*camera_info)
> {
> int i;
> @@ -451,7 +451,7 @@
> return camera;
> }
>
> -static void __devexit camera_disconnect(struct usb_device *dev, void *ptr)
> +static void camera_disconnect(struct usb_device *dev, void *ptr)
> {
> struct camera_state *camera = (struct camera_state *) ptr;
> int subminor = camera->subminor;
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Loopback filesystem still hangs on 2.4.0-test13-pre7
On Wed, Jan 03 2001, William Stearns wrote: > Good day, all, > This is just meant as an informational message, not a complaint. > Ted, could you note that this still exists on 2.4.0-test13-pre7 in the > todo page? Many thanks. > > [1.] One line summary of the problem: > Loopback filesystem writes still hang on 2.4.0-test13-pre7. Could you try with this patch: *.kernel.org/pub/linux/kernel/people/axboe/patches/2.4-prerelease/loop-remap-2 it survives 10 runs of your script and dbench abuse etc. If there are still problems, I'd like to know... Should be faster too :-) -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Fix for Real Audio IP Masquerade
Also attaching a file of the diff since stuff got munged through the email. -Original Message- From: Villalovos, John L [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 03, 2001 4:17 PM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: Fix for Real Audio IP Masquerade Diff against 2.2.19pre6 though the file hasn't changed since Oct 27, 1998. This fixes a problem in the ip_masq_raudio.c module where it assumes that all TCP headers are 20 bytes long. Some implementations of the Real Player clients use the TCP options section of the TCP header. Thus these TCP headers are longer than 20 bytes long and then break the RTSP portion of the IP masquerading code. This fix uses the header length field in the TCP header to calculate the correct offset into the data portion of the TCP packet. John --- ip_masq_raudio.cTue Oct 27 09:57:19 1998 +++ /usr/src/linux/net/ipv4/ip_masq_raudio.cWed Jan 3 16:03:21 2001 @@ -169,7 +169,10 @@ skb = *skb_p; iph = skb->nh.iph; th = (struct tcphdr *)&(((char *)iph)[iph->ihl*4]); -data = (char *)&th[1]; + + /* Make sure we take into account the size of the TCP packet. This is +* because there may be TCP options in the TCP packet */ + data = ((char *)&th[0]) + (th->doff * 4); data_limit = skb->h.raw + skb->len; @@ -315,7 +318,10 @@ skb = *skb_p; iph = skb->nh.iph; th = (struct tcphdr *)&(((char *)iph)[iph->ihl*4]); -data = (char *)&th[1]; + + /* Make sure we take into account the size of the TCP packet. This is +* because there may be TCP options in the TCP packet */ + data = ((char *)&th[0]) + (th->doff * 4); data_limit = skb->h.raw + skb->len; John Villalovos Intel Corporation 2111 NE 25TH AVE STOP JF2-70 HILLSBORO, OR 97124-5961 (503) 264-1320 Fax: (503) 264-6380 GPG 1.+/PGP 5.+/ DSS/Diffie Helman http://www.sodarock.com/JohnVillalovos-gpgkey.txt 1024D/1A25D86C 2F24 AD89 E5D5 C92B 7FE2 F878 7ED5 2D38 1A25 D86C ip_masq_raudio.diff
Re: Printing to off-line printer in 2.4.0-prerelease
On Thu, 4 Jan 2001, Andrea Arcangeli wrote: : I'm worried somebody needed to disable LP_CAREFUL to print, probably : it's not a big deal to keep it. I removed it because otherwise I would have had to do twice as many tests to convince myself that all combinations of flags and printer states worked correctly. I can reinsert it if you think that's necessary. But then I don't think the tunelp man page and the comments in the kernel should say that it is obsolete. I think obsolete means "you should never ever have to use this stuff". : However parport_write can still could silenty discard data, but maybe : it can't notice errors with some handshake. At least with my printer, it only discards data when it is powered off. If you power off the printer between the times when lp_wait_ready returns and parport_write is called, I think it is ok to lose data. After all, if the power off had occurred a few ms later, the data would already have been in the printer when it was powered off, and then you would have lost data anyway. : I didn't checked the details of the DMA based handshake so Tim needs : to comment if this can be considered a final/right fix (I hope it's : not ;). I don't understand the lowlevel parport details, so I can not comment on this. -- Peter Österlund [EMAIL PROTECTED] Sköndalsvägen 35http://home1.swipnet.se/~w-15919 S-128 66 Sköndal+46 8 942647 Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OT Re: RFC: /xproc -> /proc files in xml grammer?
> Anything else, and somebody like you will be tempted to muck with it. > We've seen spelling changes and column alignment break things. We've > seen parsers break on /proc/cpuinfo because someone decided whitespace > and extra columns might be nice. XML wouldn't be immune to the recent lol... i think this is worthy of a "kernel list newbie alert"... WT! WOOOT! KERNEL LIST NEWBIE :) ~elijah - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: usb dc2xx quirk
> From: David Brownell [mailto:[EMAIL PROTECTED]]
>
> If this makes it go away, then by all means apply this patch;
> though I don't quite see what the failure mode would be.
Josh didn't have HOTPLUG defined and he has
confirmed to me that this patch fixes the oops.
I'll forward it again.
> The proximate cause of that Oops looked to be in one of the
> UHCI drivers, but of course it's also possible that it was
> triggered by driver misbehavior.
You didn't look hard enough. 8;)
hub_thread got a disconnect event, called usb_disconnect,
which tried to call driver->disconnect, which wasn't there
due to using __devexit without CONFIG_HOTPLUG defined.
> Have we identified anything that actually does anything with
> code labeled __dev{in,ex}it (or data), beyond putting it into
> a different section? If so, what's it doing?
That's a great question. I'd like to know the answer also.
Then we can see what the correct fixes should be.
This patch could just be a short-lived 2.4.0-prerel
fix-the-oops patch.
> I just tried plug/unplug of a dc-240, albeit on a kernel
> with HOTPLUG defined (and using OHCI) and it worked without
> any Oops.
Yes, HOTPLUG (and #define of __devexit) is the key.
~Randy
> - Dave
>
>
> - Original Message -
> From: Randy Dunlap <[EMAIL PROTECTED]>
> To: josh <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; l-u-d
> <[EMAIL PROTECTED]>
> Sent: Wednesday, January 03, 2001 11:23 AM
> Subject: Re: usb dc2xx quirk
>
>
> > Hi,
> >
> > Looks like dc2xx.c shouldn't use __devinit/__devexit
> > [patch attached]
> > or you should enable CONFIG_HOTPLUG under General Setup.
> >
> > David?
> >
> > The ov511 (usb) driver is the only other USB device driver
> > that uses __devinit/__devexit.
> >
> > ~Randy
> >
> > josh wrote:
> > >
> > > Kernel Version: 2.4.0-test11 - 2.4.0-prerelease
> > > Platform: ix86 (PIII)
> > > Problem Hardware: Kodac DC280, firmware 1.01
> > >
> > > Ever since test10 or after, removing my dc280 from the usb
> > > bus causes khubd to crash. I have tried both UHCI drivers
> > > and they produce the same effect.
> > >
> > > dmesg, syslog, messages, and .config can be found at:
> > > http://mammoth.org/~skulcap/usb-problem
> > >
> > > I have looked throug the archives and havent found anything
> > > like this, so I'm sorry if it has been covered already.
> > >
> > > Thanks in advance!
> > --
> > ___
> > |randy.dunlap_at_intel.com503-677-5408|
> > |NOTE: Any views presented here are mine alone|
> > |& may not represent the views of my employer.|
> > ---
>
>
> --
> --
>
>
> > --- linux/drivers/usb/dc2xx.c.org Sun Nov 12 20:40:42 2000
> > +++ linux/drivers/usb/dc2xx.c Wed Jan 3 11:15:11 2001
> > @@ -353,7 +353,7 @@
> >
> >
> >
> > -static void * __devinit
> > +static void *
> > camera_probe (struct usb_device *dev, unsigned int ifnum,
> const struct usb_device_id
> *camera_info)
> > {
> > int i;
> > @@ -451,7 +451,7 @@
> > return camera;
> > }
> >
> > -static void __devexit camera_disconnect(struct usb_device
> *dev, void *ptr)
> > +static void camera_disconnect(struct usb_device *dev, void *ptr)
> > {
> > struct camera_state *camera = (struct camera_state *) ptr;
> > int subminor = camera->subminor;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Gerhard Mack wrote: > On Wed, 3 Jan 2001, Dan Hollis wrote: > > On Wed, 3 Jan 2001, Gerhard Mack wrote: > > > Your comparing actual security with stack guarding? Stack guarding mearly > > > makes the attack diffrent.. rootkits are already available to defeat it. > > url? > Ugh do you have any idea how hard it is to find 2 year old exploits? > Heres the best I could find on short notice: > http://www.insecure.org/sploits/non-executable.stack.problems.html > http://darwin.bio.uci.edu/~mcoogan/bugtraq/msg00335.html You said there were rootkits specifically targetting stackguard. These URLs simply describe attacks on stackguard, where are the stackguard rootkits? -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Prerelease kernel will not hotplug a USB host-controller when it isinserted into a Cardbus slot.
David Brownell wrote: >> I am writing to let you know that in all test12-pre6+ kernels, >> I get a "Bad PCI invocation" error when hotplug attempts to >> handle the insertion of a USB host-controller into a Cardbus >> slot. > > > That's new info ... you'd previously thought that it wasn't even > invoking /sbin/hotplug! I fscked up that test. The results I reported as being with prerelease were actually with a messed up test11. The whole "Bad PCI invocation" error was a red herring, sorry. I have since gone in a tested test12-pre5, test12-pre6 and test12-pre8. test12-pre5 works. test12-pre6 fails utterly. It looks like Cardbus was just completely hosed in that tree, because I can't get my network card (3c575) to be recognized by that kernel, either. I checked the patches and Andrew's "04X" change went into test12-pre8. I just tested test12-pre8 with both your latest hotplug script, David, and with the pertinent "0x" locations changed to "04x". Both scripts fail to load usb-ohci. Bottom line, I have yet to see a test12-pre6+ kernel load usb-ohci whether or not I use "04x" in the hotplug script. Something else is messed up here. > The scripts I know about will produce that message when they're > invoked without PCI_CLASS set. That's a sanity check which was > needed for the intial PCI hotplug support, which wouldn't pass > that info -- needed to hotplug devices using class drivers, such > as USB host controllers. > > But they'll also dump all the arguments and environment of > hotplug before they get that far, if you set DEBUG=yes; please > enable that and let us know the whole environment that's getting > passed ! For the Cardbus hotplug event, is it expected that the hotplug debug info would be dumped after the insert event is processed and the required driver is loaded? With test12-pre5, I get this when I insert the BusPort Mobile: Jan 3 15:00:15 agate kernel: cs: cb_alloc(bus 5): vendor 0x1045, device 0xc861 Jan 3 15:00:15 agate kernel: got res[1100:11000fff] for resource 0 of PCI device 1045:c861 Jan 3 15:00:15 agate kernel: PCI: Enabling device 05:00.0 ( -> 0002) Jan 3 15:00:15 agate kernel: PCI: Found IRQ 11 for device 05:00.0 Jan 3 15:00:15 agate kernel: PCI: The same IRQ used for device 00:04.0 Jan 3 15:00:15 agate kernel: PCI: Setting latency timer of device 05:00.0 to 64 Jan 3 15:00:15 agate kernel: usb-ohci.c: USB OHCI at membase 0xc585, IRQ 11 Jan 3 15:00:15 agate kernel: usb-ohci.c: usb-05:00.0, PCI device 1045:c861 Jan 3 15:00:15 agate kernel: usb.c: new USB bus registered, assigned bus number 1 Jan 3 15:00:15 agate kernel: Product: USB OHCI Root Hub Jan 3 15:00:15 agate kernel: SerialNumber: c585 Jan 3 15:00:15 agate kernel: hub.c: USB hub found Jan 3 15:00:15 agate kernel: hub.c: 2 ports detected Jan 3 15:00:16 agate /sbin/hotplug: arguments (usb) env (TYPE=9/0/0 ACTION=add DEVFS=/proc/bus/usb TERM=dumb DEVICE=/proc/bus/usb/001/001 HOSTTYPE=i386 PATH=/bin:/sbin:/usr/sbin:/usr/bin HOME=/ SHELL=/bin/bash DEBUG=kernel OSTYPE=Linux PRODUCT=0/0/0 SHLVL=1 _=/usr/bin/env) Thanks and sorry for the inaccurate info last night. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-prerelease - "APIC error on CPU0"
The beginning of of the dmesg output is unfortunately lost. This is an Intel Nightshade mobo with dual PIII/450. It's happy under 2.2.x. PAT present. PSE present. MMX present. FXSR present. XMM present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. XMM present. Bus #0 is PCI Bus #1 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 1, trig 1, bus 1, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 1, trig 1, bus 1, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 1, trig 1, bus 1, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 1, trig 1, bus 1, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 1, trig 1, bus 1, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 1, trig 1, bus 1, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 1, trig 1, bus 1, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 1, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 1, trig 1, bus 1, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 1, trig 1, bus 1, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 1, trig 1, bus 1, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 1, trig 1, bus 1, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 0, IRQ 2c, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 0, IRQ 34, APIC ID 2, APIC INT 15 Int: type 0, pol 3, trig 3, bus 0, IRQ 35, APIC ID 2, APIC INT 16 Int: type 0, pol 3, trig 3, bus 0, IRQ 3c, APIC ID 2, APIC INT 14 Int: type 0, pol 3, trig 3, bus 0, IRQ 40, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 0, IRQ 4b, APIC ID 2, APIC INT 16 Lint: type 3, pol 1, trig 1, bus 1, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 1, trig 1, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=2.4.0pre ro root=805 BOOT_FILE=/boot/vmlinuz-2.4.0-prerelease Initializing CPU#0 Detected 448.882 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 894.56 BogoMIPS Memory: 255640k/262080k available (1105k kernel code, 6048k reserved, 81k data, 204k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU0: Intel Pentium III (Katmai) stepping 02 per-CPU timeslice cutoff: 1464.52 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 100 Getting ID: e00 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: CPU present map: 3 Booting processor 1/0 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Initializing CPU#1 CPU#1 (phys ID: 0) waiting for CALLOUT Startup point 1. Waiting for send to finish... +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 894.56 BogoMIPS Stack at about c1449fbc CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff
PATCH(prerelease) - knfsd fix
Linus/Alan,
please accept the following patch for knfsd in 2.4.0-prerelease.
What it does is extend the protection offered by s_nfsd_free_path_sem
to cover the first call to nfsd_iget.
I had previously avoided this as I didn't think it was necessary and
it ment that the semaphore wasn't claimed at all on the common path.
However Chip Salzenberg managed to convince me that it is needed.
I think that his case-in-point is mentioned towards the end of
http://www.cnn.com/2001/TECH/computing/01/03/linux.mission.idg/index.html
under "Taking the plunge".
There is actually more that I would like to do to this code, but I
don't think now is the right time. This is the minimal change that
will fix a real bug.
NeilBrown
--- ./fs/nfsd/nfsfh.c 2001/01/04 00:09:13 1.1
+++ ./fs/nfsd/nfsfh.c 2001/01/04 00:09:37 1.2
@@ -346,7 +346,7 @@
struct dentry *dentry, *result = NULL;
struct dentry *tmp;
int found =0;
- int err;
+ int err = -ESTALE;
/* the sb->s_nfsd_free_path_sem semaphore is needed to make sure that only one
unconnected (free)
* dcache path ever exists, as otherwise two partial paths might get
* joined together, which would be very confusing.
@@ -360,19 +360,18 @@
* Attempt to find the inode.
*/
retry:
+ down(&sb->s_nfsd_free_path_sem);
result = nfsd_iget(sb, ino, generation);
- err = PTR_ERR(result);
- if (IS_ERR(result))
- goto err_out;
- err = -ESTALE;
- if (! (result->d_flags & DCACHE_NFSD_DISCONNECTED))
- return result;
-
- /* result is now an anonymous dentry, which may be adequate as it stands, or
else
-* will get spliced into the dcache tree */
-
- if (!S_ISDIR(result->d_inode->i_mode) && ! needpath) {
- nfsdstats.fh_anon++;
+ if (IS_ERR(result)
+ || !(result->d_flags & DCACHE_NFSD_DISCONNECTED)
+ || (!S_ISDIR(result->d_inode->i_mode) && ! needpath)) {
+ up(&sb->s_nfsd_free_path_sem);
+
+ err = PTR_ERR(result);
+ if (IS_ERR(result))
+ goto err_out;
+ if ((result->d_flags & DCACHE_NFSD_DISCONNECTED))
+ nfsdstats.fh_anon++;
return result;
}
@@ -380,14 +379,6 @@
* location in the tree.
*/
dprintk("nfs_fh: need to look harder for %d/%ld\n",sb->s_dev,ino);
- down(&sb->s_nfsd_free_path_sem);
-
- /* claiming the semaphore might have allowed things to get fixed up */
- if (! (result->d_flags & DCACHE_NFSD_DISCONNECTED)) {
- up(&sb->s_nfsd_free_path_sem);
- return result;
- }
-
found = 0;
if (!S_ISDIR(result->d_inode->i_mode)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: /xproc -> /proc files in xml grammer?
> Would XML be considered human readable enough for /proc files? If not, > how about a /xproc filesystem ( maybe as a kernel build option ), same > as /proc but uses an xml grammer for reporting. > I can see tons of uses for this, no more 'fuzzy' parsing for gui > configuration tools, resource monitors, etc. No. No XML. No colons. No newlines. No embedded whitespace. No quoting. No field names. No other screwing around. Option 1 looks like this:42 8842 0 4234 898 33 221 2512 Option 2 is a raw array of 64-bit binary data Anything else, and somebody like you will be tempted to muck with it. We've seen spelling changes and column alignment break things. We've seen parsers break on /proc/cpuinfo because someone decided whitespace and extra columns might be nice. XML wouldn't be immune to the recent "features" vs. "flags" problem, but the two options above are. Now, what is your problem? Grab libgtop (GPL) or libproc (LGPL) and be happy. All of "ps" is in fact under the LGPL, so you can grab anything else you might need. (LGPL: not just for libraries anymore) You get libproc and ps here: http://www.cs.uml.edu/~acahalan/procps/ (maybe wait a week or two before you grab that -- new one coming) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fix for Real Audio IP Masquerade
Diff against 2.2.19pre6 though the file hasn't changed since Oct 27, 1998. This fixes a problem in the ip_masq_raudio.c module where it assumes that all TCP headers are 20 bytes long. Some implementations of the Real Player clients use the TCP options section of the TCP header. Thus these TCP headers are longer than 20 bytes long and then break the RTSP portion of the IP masquerading code. This fix uses the header length field in the TCP header to calculate the correct offset into the data portion of the TCP packet. John --- ip_masq_raudio.cTue Oct 27 09:57:19 1998 +++ /usr/src/linux/net/ipv4/ip_masq_raudio.cWed Jan 3 16:03:21 2001 @@ -169,7 +169,10 @@ skb = *skb_p; iph = skb->nh.iph; th = (struct tcphdr *)&(((char *)iph)[iph->ihl*4]); -data = (char *)&th[1]; + + /* Make sure we take into account the size of the TCP packet. This is +* because there may be TCP options in the TCP packet */ + data = ((char *)&th[0]) + (th->doff * 4); data_limit = skb->h.raw + skb->len; @@ -315,7 +318,10 @@ skb = *skb_p; iph = skb->nh.iph; th = (struct tcphdr *)&(((char *)iph)[iph->ihl*4]); -data = (char *)&th[1]; + + /* Make sure we take into account the size of the TCP packet. This is +* because there may be TCP options in the TCP packet */ + data = ((char *)&th[0]) + (th->doff * 4); data_limit = skb->h.raw + skb->len; John Villalovos Intel Corporation 2111 NE 25TH AVE STOP JF2-70 HILLSBORO, OR 97124-5961 (503) 264-1320 Fax: (503) 264-6380 GPG 1.+/PGP 5.+/ DSS/Diffie Helman http://www.sodarock.com/JohnVillalovos-gpgkey.txt 1024D/1A25D86C 2F24 AD89 E5D5 C92B 7FE2 F878 7ED5 2D38 1A25 D86C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
How to power off with ACPI/APM?
I have an ASUS P3V4X motherboard with an ACPI BIOS. This is a desktop machine, and while APM is normally of concern for laptops, it seems to me from what I read in the kernel config help that I should be able to make the machine power itself off. If I have ACPI enabled but not APM, when I do "shutdown -h now", I see these messages at the end: Power Down ACPI: S5 failed and the machine stays powered on. Looking back in the ACPI kernel config help, it says you can use ACPI if you also have APM enabled, which I didn't do at first. I enabled it, and the "S5 failed" message goes away at the end, but my machine still doesn't power down. I notice in the kernel messages at boot time that ACPI says something like "APM already enabled, exiting". This isn't that big a deal to me personally (I can always hit the power switch) but if it's a kernel bug I want to help track it down. Alternatively, if it's something I'm doing wrong I can help clarify and document the procedure for making this work. I'm using 2.4-prerelease-ac5, which generally seems to be working pretty good for me. Other exciting details of this machine are that it has an adaptec 28160 Ultra160 SCSI host bus adapter that works fine with the disk. I'll try burning a CD with it shortly. It's got a Pentium III 667 with 128MB of ram running at 133 MHz, a 3C905B 10/100 ethernet card and a ATI Rage Millenium with 32 MB of video ram. I've got XFree86 4.0.1 on it with DRI working (and DRM and AGP enabled in the kernel) with a VIA chipset on the motherboard - I generally had little luck ever getting accellerated drivers to work under XFree86 3.x, but things went much better with 4. I get on the internet with the ppp_async module via a 56k external modem. Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Printing to off-line printer in 2.4.0-prerelease
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Wed, Jan 03, 2001 at 10:00:59PM +0100, Peter Osterlund wrote:
> > off. Apparently the printer tells the computer it is OK to send data
> > to it when it is off.
>
> So then parport_write is probably buggy because it's losing data silenty while
> the printer is off. So the below is probably a band aid. Really some printer
> acts in a different way (see the LP_CAREFUL hack in 2.2.x) so it maybe that
> parport_write is ok on some printer and it would need something like a
> LP_CAREFUL option to work also on some other printer. Or maybe some parport
> handshake is badly designed in hardware and it cannot report errors (or maybe
> there's the hardware compatibility mode that cannot know about LP_CAREFUL to
> workaround some printer behaviour). In such case your patch is probably the
> only way to go (but almost certainly for the software compatibility mode it
> should be possible to report errors via parport_write as we do in 2.2.x).
The tunelp man-page seems to think there are printers that need the
LP_CAREFUL handling. I also noted that if I disconnect my printer from
the computer, the data will no longer be lost. Apparently the printer
confuses the parallel port when it is powered off.
> > I also only get one DMA write timeout when putting the printer in
> > offline mode during sending, instead of repeated timeouts as I got
> > with the previous patch.
>
> I see, it makes sense to try to parport_write only when errors goes away, but I
> think it's nicer to have lp_error or lp_check_status that loops internally in
> interruptible mode if LP_ABORT isn't set via lptune. probably the code should
> be restructured a bit.
What do you think about the following patch? It also works for all the
tests mentioned in my previous message.
--- linux-2.4.0-prerelease/drivers/char/lp.c.orig Wed Jan 3 18:48:39 2001
+++ linux-2.4.0-prerelease/drivers/char/lp.cThu Jan 4 00:45:52 2001
@@ -188,10 +188,7 @@
int error = 0;
unsigned int last = lp_table[minor].last_error;
unsigned char status = r_str(minor);
- if ((status & LP_PERRORP) && !(LP_F(minor) & LP_CAREFUL))
- /* No error. */
- last = 0;
- else if ((status & LP_POUTPA)) {
+ if ((status & LP_POUTPA)) {
if (last != LP_POUTPA) {
last = LP_POUTPA;
printk(KERN_INFO "lp%d out of paper\n", minor);
@@ -210,8 +207,7 @@
}
error = -EIO;
} else {
- last = 0; /* Come here if LP_CAREFUL is set and no
- errors are reported. */
+ last = 0; /* Come here if no errors are reported. */
}
lp_table[minor].last_error = last;
@@ -222,6 +218,21 @@
return error;
}
+static int lp_wait_ready(int minor)
+{
+ int error = 0;
+ do {
+ error = lp_check_status (minor);
+ if (error && (LP_F(minor) & LP_ABORT))
+ break;
+ if (signal_pending (current)) {
+ error = -EINTR;
+ break;
+ }
+ } while (error);
+ return error;
+}
+
static ssize_t lp_write(struct file * file, const char * buf,
size_t count, loff_t *ppos)
{
@@ -259,7 +270,7 @@
parport_set_timeout (lp_table[minor].dev,
lp_table[minor].timeout);
- if ((retv = lp_check_status (minor)) == 0)
+ if ((retv = lp_wait_ready (minor)) == 0)
do {
/* Write the data. */
written = parport_write (port, kbuf, copy_size);
@@ -279,9 +290,9 @@
if (copy_size > 0) {
/* incomplete write -> check error ! */
- int error = lp_check_status (minor);
+ int error = lp_wait_ready (minor);
- if (LP_F(minor) & LP_ABORT) {
+ if (error) {
if (retv == 0)
retv = error;
break;
@@ -453,10 +464,7 @@
LP_F(minor) &= ~LP_ABORTOPEN;
break;
case LPCAREFUL:
- if (arg)
- LP_F(minor) |= LP_CAREFUL;
- else
- LP_F(minor) &= ~LP_CAREFUL;
+ /* Obsolete */
break;
case LPWAIT:
LP_WAIT(minor) = arg;
--- linux-2.4.0-prerelease/drivers/parport/ieee1284.c.orig Wed Jan 3 18:50:02
2001
+++ linux-2.4.0-prerelease/drivers/parport/ieee1284.c Wed Jan 3 21:32:28 2001
@@ -524,7 +524,8 @@
PARPORT_STATUS_PAPEROUT,
PARPORT_STATUS_PAPEROUT);
2.4.0-prerelease IDE CD-ROM problem
If I mount and unmount a CD on my ThinkPad 600X under 2.4.0-prerelease, the drive never unlocks and I can't eject the CD. It doesn't matter whether I read any data from it or not before the umount command. Subsequent attempts to access the drive in any way -- mount, dd, etc. -- hang and the processes can't be killed, even with kill -9. I have to reboot to get out of it. The rest of the system continues to work normally, except that within a few minutes, I start getting temporary hangs (about 5 seconds duration) every couple of minutes. The keyboard locks, the screen freezes, then a few seconds later everything unfreezes and it works OK for another few minutes. Playing an audio CD doesn't trigger this problem; only mounting and unmounting does. Since I haven't been using my CD drive much lately, I'm not certain exactly when this problem started. It happens under both the "original" 2.4.0-prerelease and one patched with the latest prerelease-diff. I'm pretty certain it didn't happen under 2.4.0-test12, but I can't remember if I used the CD under any of the test13-pre versions or not. My system is pretty much standard Slackware 7.1, except for the 2.4.0 kernel and upgrades to modutils, binutils, etc. to bring everything into sync with what's specified in Documentation/Changes. The compiler is egcs-2.91.66. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Gerhard Mack wrote: > Your comparing actual security with stack guarding? Stack guarding mearly > makes the attack diffrent.. rootkits are already available to defeat it. url? -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Hollis wrote: > On Thu, 4 Jan 2001, Dan Aloni wrote: > > Anyway, while it is agreed that you can't completely eliminate exploits, > > it is recommended that, it should be at least harder to create them, maybe > > it can even minimize the will to write them. > > The argument against these sort of protection mechanisms seems to be "well > its not perfect, so we shouldnt have it at all". > > Lets use that argument against uid/gid then. Since it's impossible to > protect against exploits, let's dispose of uid/gid entirely and run > everything as root ;-) > > "stack guarding is a false sense of security". Well, so is ipchains, so > lets discard that as well...? > > Really, these arguments cut both ways. If you are going to argue against > something because it's not perfect, you should be aware that you're > arguing against other kernel protection mechanisms also. > Your comparing actual security with stack guarding? Stack guarding mearly makes the attack diffrent.. rootkits are already available to defeat it. Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
soffice, 2.2.18, cpu 97% idle, loadavg 6.05
linux 2.2.18 with VM-global patch 128MB RAM AMD K6-3/366 Star Office 5.2 I exiting StarOffice, and a little later noticed my loadavg display widget was showing a high load average. top reports it at 6. Poking about, I found all the soffice.bin processes still hanging around. Looking with top, all the soffice.bin processes are in the 'D N' state. In top's 'no idle' mode they are listed. The CPU is hanging around 97% idle, the loadavg has been sitting at 6+ for almost 15 minutes. It seems likely this state will continue forever. I tried a 'kill' on all the soffice.bin process and there was no change. a 'kill -9' also had no effect. What is going on? Shouldn't I be able to tear down the processes? Here is status on the soffice.bin process with the lowest PID: # cat /proc/5294/status Name: soffice.bin State: D (disk sleep) Pid:5294 PPid: 775 Uid:101 101 101 101 Gid:101 101 101 101 Groups: 101 0 10 228 229 500 VmSize: 103600 kB VmLck: 0 kB VmRSS: 49588 kB VmData:13008 kB VmStk: 1104 kB VmExe:88 kB VmLib: 73604 kB SigPnd: 4100 SigBlk: 8000 SigIgn: 80001000 SigCgt: 0003bfc064ff CapInh: CapPrm: CapEff: Thanks, -- Brian Litzinger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
Excuse-me but, am I wrong or is this thread completely useless? Since Alan Cox and I said that Solar Design has done a complete patch to do the same, and since this patch is alvailble to everybody at http://www.openwall.com in that way that everybody can download it and have the choice to install it or not, do we still need to discuss over a way to include a similar patch into the kernel? Regards, -- Nicolas Noble - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc2.96 + prerelease BUG at inode.c:372
In article <[EMAIL PROTECTED]>, Diego Liziero <[EMAIL PROTECTED]> wrote: > >->1: The sound module for my mad16 based card plays the bytes swapped > (the same module recompiled with egcs-2.91.66 works fine). Could you try to figure this one out a bit more? This sounds like a real compiler issue, whether it is because egcs just happens to get the right result for bogus kernel source, of whether gcc-2.96 has problems.. >->2: after two day under heavy load I've got the following BUG: > (I don't know if it's related to the compiler, that's why I'm reporting > this.) Unrelated. This one is a known bug that hits if you are a bit unlucky with a race on deleting the pages from the inode page-lists. Fixed in the current prerelease patches on ftp.kernel.org. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: /xproc -> /proc files in xml grammer?
On 2001.01.04 Kervin Pierre wrote: > > hello, > > Would XML be considered human readable enough for /proc files? If not, > how about a /xproc filesystem ( maybe as a kernel build option ), same > as /proc but uses an xml grammer for reporting. > I can see tons of uses for this, no more 'fuzzy' parsing for gui > configuration tools, resource monitors, etc. > > ? > > just thinking aloud really, More aloud thinkin... I have seen some times this thread appear on the list. One of the problems: you will have to force drivers to register in two file systems... Perhaps there are tools yet to do what I'm thinkin of: a ghost file system that just mirrors /proc, changing format of output. Say you clone the procfs to a fake fs driver (for example, procfs.xml) that just translates each fs access system call to /fproc/xml/path/to/file_or_dir (fproc==formatted proc) to /proc/path/to/file_or_dir reads its contents and reformats them to give the desired output (now thinkin on read-only, main people interest seems to be in syntax-ing the out of /proc). So actual /proc stays, not breaking anything, and theres a way to write proc info formatters. Even there could be many common code between all the possible procfs. things to ease maintenance. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.2.19-pre6 #1 SMP Wed Jan 3 21:28:10 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Thu, 4 Jan 2001, Dan Aloni wrote: > Anyway, while it is agreed that you can't completely eliminate exploits, > it is recommended that, it should be at least harder to create them, maybe > it can even minimize the will to write them. The argument against these sort of protection mechanisms seems to be "well its not perfect, so we shouldnt have it at all". Lets use that argument against uid/gid then. Since it's impossible to protect against exploits, let's dispose of uid/gid entirely and run everything as root ;-) "stack guarding is a false sense of security". Well, so is ipchains, so lets discard that as well...? Really, these arguments cut both ways. If you are going to argue against something because it's not perfect, you should be aware that you're arguing against other kernel protection mechanisms also. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Thu, 4 Jan 2001, Dan Aloni wrote: > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > > > without breaking anything. It also reports of such calls by using printk. > > > > Get real. > > > > > > Why do you always have to be insulting alex? Sheesh. > > > > Sigh... Not intended to be an insult. Plain and simple advice. Idea is > [..] > > Did you notice that question was ambiguous? I understood that sentence in > its other meaning, i.e, someone insulting Alex ;-) > > Anyway, while it is agreed that you can't completely eliminate exploits, > it is recommended that, it should be at least harder to create them, maybe > it can even minimize the will to write them. > > -- > Dan Aloni > [EMAIL PROTECTED] > You are much better off working on ways to reduce the number of processes that need to be root.. As for these protections my system emails me when a process overflows it's buffers, But that's not a kernel function. ;) Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prelease freezes on serial event
On 03 Jan 2001 21:53:50 +, Graham Murray <[EMAIL PROTECTED]> wrote: >My 2.4.0-prerelease freezes solid on certain serial port events. The >ones I have seen (and are both repeatable) are when powering off the >modem and powering it on causes the system to hang solid. Also if an >incoming call is received on the telephone, the system hangs ( I >assume that this is when the modem sends 'RING' and asserts the RI >hardware signal.) Does your cpu have an APIC? SMP boxes always do, most non-mobile P6 UP systems do. If you have an APIC and assuming it is a software lockup, install the kdb patch[*]. If your box is UP, under General setup select APIC for UP then select NMI for UP. Under Kernel hacking, select kdb. You need a recent modutils, see Documentation/Changes. Ideally you should use a serial console and run a null modem to a second machine, see Documentation/serial-console.txt. Boot the kdb enhanced kernel and cat /proc/interrupts to see if NMI is non-zero. Only if NMI is non-zero, reproduce the problem. Five seconds after the lockup, the NMI watchdog should trip and drop you into kdb. The backtrace (bt) command will show where you are hung. Capture the backtrace on the second machine or hand copy the backtrace, in either case mail the backtrace to l-k. [*]ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.7-2.4.0-prerelease.gz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Announce: LOMAC v1.0 released
Hi! I've just released LOMAC v1.0 - an LKM for Linux 2.2 kernels that implements a form of Low Water-Mark Mandatory Access Control (MAC) to protect the integrity of processes and data from viruses, Trojan horses, malicious remote users, and compromised root daemons. LOMAC is designed for simplicity and compatibility with existing software. It implements kernel-space MAC at the system-call interface without modifying any kernel sources. Although it lacks some of the advanced MAC features found in more complex and powerful schemes, LOMAC provides a simple and useful form of MAC integrity protection that requires no kernel patches, no modifications to existing applications, no modifications to existing configuration files, and no site-specific policy configuration. A good number of features and fixes remain to be implemented. However, LOMAC is presently functional enough to thwart script kiddies, and is sufficiently stable for everyday use. (I'm using it now.) Further information can be found via LOMAC's Freshmeat page, at http://freshmeat.net/projects/lomac - Tim Fraser, NAI Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [IrDA+SMP] Lockup in handle_IRQ_event
Marc ZYNGIER wrote:
>
> Hi all,
>
> Having just started playing with IrDA on my dual celeron (Abit "APIC
> error..." BP6), I managed to kill it every single time (NMI watchdog
> in handle_IRQ_event) while connecting to my mobile phone (in fact,
> when closing the connection to the phone. even 'cat /dev/ircomm0' will
> do...). This is perfectly repeatable.
>
Try this:
--- linux-2.4.0-prerelease/net/irda/irqueue.c Tue Nov 21 20:11:22 2000
+++ linux-akpm/net/irda/irqueue.c Thu Jan 4 10:14:10 2001
@@ -436,7 +436,7 @@
/* Release lock */
if ( hashbin->hb_type & HB_GLOBAL) {
- spin_unlock_irq( &hashbin->hb_mutex[ bin]);
+ spin_unlock_irqrestore( &hashbin->hb_mutex[ bin], flags);
} else if ( hashbin->hb_type & HB_LOCAL) {
restore_flags( flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dcache 2nd chance replacement
On Wed, 3 Jan 2001, Andrea Arcangeli wrote: > On Wed, Jan 03, 2001 at 05:47:39PM -0200, Rik van Riel wrote: > > Not really. Under very high VFS loads we'd just scan > > through the list twice and free the entries anyway. > > You're obviously wrong. > > The higher was the load, the faster your working set was getting > dropped from the dcache. (with the patch the working set will > have a chance to remains in cache also with polluting going on > instead, > The example with only pollution in the cache doesn't make sense, Ever heard of slocate / updatedb ? regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Yet more benchmarks for 2.4.0-prerelease and -ac[4,5]
> recent kernels. It looks like there may be a slight drop > in performance for -ac5. For -ac4 and -ac5, the throughput -ac5 touches stuff which would have performance effects. That would be reasonable to suspect. - Rik's partial page changes - A couple of other minor vm touches If it is relaed to those then you should see the same loss of speed on the testing/prerelease file on ftp.kernel.org. > dropped on run #3. That's probably just a fluke. I'll repeat > these runs later when I get a chance. 4 doesnt change anything except for FATfs and writing raw off end of disks so for now lets assume fluke Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] add PF_MEMALLOC to __alloc_pages()
Rik van Riel <[EMAIL PROTECTED]> writes:
> Hi Linus, Alan, Mike,
>
> the following patch sets PF_MEMALLOC for the current task
> in __alloc_pages() to avoid infinite recursion when we try
> to free memory from __alloc_pages().
>
> Please apply the patch below, which fixes this (embarrasing)
> bug...
>
[snip]
>* free ourselves...
>*/
> } else if (gfp_mask & __GFP_WAIT) {
> + current->flags |= PF_MEMALLOC;
> try_to_free_pages(gfp_mask);
> + current->flags &= ~PF_MEMALLOC;
> memory_pressure++;
> if (!order)
> goto try_again;
>
Hm, try_to_free_pages already sets the PF_MEMALLOC flag!
--
Zlatko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RFC: /xproc -> /proc files in xml grammer?
hello, Would XML be considered human readable enough for /proc files? If not, how about a /xproc filesystem ( maybe as a kernel build option ), same as /proc but uses an xml grammer for reporting. I can see tons of uses for this, no more 'fuzzy' parsing for gui configuration tools, resource monitors, etc. ? just thinking aloud really, -Kervin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Thu, 4 Jan 2001, Dan Aloni wrote: > Did you notice that question was ambiguous? I understood that sentence in > its other meaning, i.e, someone insulting Alex ;-) Well, _that_ definitely takes more than posting a patch ;-) > Anyway, while it is agreed that you can't completely eliminate exploits, > it is recommended that, it should be at least harder to create them, maybe > it can even minimize the will to write them. large overhead to every syscall and protection that can be defeated in a couple of instructions. Doesn't look like a good tradeoff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breaking bug
> On Linux, they use INT 80 system calls to execute functions in the kernel > as root, when the stack is smashed as a result of a buffer overflow bug in > various server software. > > This preliminary, small patch prevents execution of system calls which > were executed from a writable segment. It was tested and seems to work, > without breaking anything. It also reports of such calls by using printk. And I swap the int80 for a jmp to an int80 at a predictable location in ld.so If you are going to do stack tricks then look at Solar Designers patches, he has at least worked through the issues and even thought about using null bytes in jump targets for libraries to stop some operations (string stuff) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
LVM 0.9 vgscan problem
Hi, I have a strange problem (preventing me from testing the latest 2.4 kernel ... *sigh*) with my LVM setup. The latest LVM utils + the latest kernel works just fine on my test machine, but breaks horribly on my workstation. The only difference I have found is that one PV of my VG has "NOT available" as PV Status ... --- Physical volume --- PV Name /dev/hda5 VG Name vg0 PV Size 4.4 GB / NOT usable 2.56 MB [LVM: 124 KB] PV# 3 PV Status NOT available Allocatable yes Cur LV0 PE Size (KByte) 4096 Total PE 1125 Free PE 1125 Allocated PE 0 Any chance of getting the LVM utilities fixed ? I'd hate to see LVM be the showstopper for 2.4 (then again, the way the LVM team has neglected everything from backwards compatability to even documenting such is pretty much a showstopper in itself ...) regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Alexander Viro wrote: > > > On Wed, 3 Jan 2001, Mark Zealey wrote: > > > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > > > > > > > > On Wed, 3 Jan 2001, Dan Hollis wrote: > > > > > > > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > > On Wed, 3 Jan 2001, Dan Aloni wrote: > > > > > > without breaking anything. It also reports of such calls by using printk. > > > > > Get real. > > > > > > > > Why do you always have to be insulting alex? Sheesh. > > > > > > Sigh... Not intended to be an insult. Plain and simple advice. Idea is > > > broken for absolutely obvious reasons (namely, every real-life program > > > > This doesnt stop syscalls, only syscalls from writable areas. > > And? Syscall is a couple of bytes. 0xcd and 0x80. Find one in non-writable > area, put whatever you want into registers and jump to the address where > these two bytes sit. Voila. If all such places are in writable areas - > there you go, the process you've attacked could not perform any > system calls itself. And the ret and other stuff, you now have to search thru memory for a 10-byte sequance (sya?) to do the correct thing, what are the chances of finding that, never mind coding all the stuff to find that into a faked packet or whatever, this is gonna make the r00ter's life (do they have one? ;) a lot harder, plus it will take a while to make a solution that works. > > Come on, folks, you can't be serious - think for a couple of minutes and > you'll come up with a trivial way to work around such protection. In a > dozen bytes or so. > > > -- Mark Zealey (aka JALH on irc.openprojects.net: #zealos and many more) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] UL$ (GCM/GCS/GS/GM)GUG! dpu? s-:-@ a15! C+++>$ P++$>+++@ L+++>+$ !E---? W+++>$ N++@>+ o->+ w--- !M--? !V--? PS- PE--@ !PGP? r++ !t---?@ !X---? !R- b+ !DI---? e->+ h+++*! y- (www.geekcode.com) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Mark Zealey wrote: > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > > > > On Wed, 3 Jan 2001, Dan Hollis wrote: > > > > > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > On Wed, 3 Jan 2001, Dan Aloni wrote: > > > > > without breaking anything. It also reports of such calls by using printk. > > > > Get real. > > > > > > Why do you always have to be insulting alex? Sheesh. > > > > Sigh... Not intended to be an insult. Plain and simple advice. Idea is > > broken for absolutely obvious reasons (namely, every real-life program > > This doesnt stop syscalls, only syscalls from writable areas. And? Syscall is a couple of bytes. 0xcd and 0x80. Find one in non-writable area, put whatever you want into registers and jump to the address where these two bytes sit. Voila. If all such places are in writable areas - there you go, the process you've attacked could not perform any system calls itself. Come on, folks, you can't be serious - think for a couple of minutes and you'll come up with a trivial way to work around such protection. In a dozen bytes or so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > without breaking anything. It also reports of such calls by using printk. > > > Get real. > > > > Why do you always have to be insulting alex? Sheesh. > > Sigh... Not intended to be an insult. Plain and simple advice. Idea is [..] Did you notice that question was ambiguous? I understood that sentence in its other meaning, i.e, someone insulting Alex ;-) Anyway, while it is agreed that you can't completely eliminate exploits, it is recommended that, it should be at least harder to create them, maybe it can even minimize the will to write them. -- Dan Aloni [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Alexander Viro wrote: > > > On Wed, 3 Jan 2001, Dan Hollis wrote: > > > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > On Wed, 3 Jan 2001, Dan Aloni wrote: > > > > without breaking anything. It also reports of such calls by using printk. > > > Get real. > > > > Why do you always have to be insulting alex? Sheesh. > > Sigh... Not intended to be an insult. Plain and simple advice. Idea is > broken for absolutely obvious reasons (namely, every real-life program This doesnt stop syscalls, only syscalls from writable areas. > contains at least one syscall that it _can_ execute). Expecting _any_ > part of userland to be rewritten into the form that would not have > such places (i.e. all IO is done by trusted processes that poll > memory areas shared with the programs needing said IO, exit is done > either by explicit kill() from another process or by dumping core, signals > are done by putting request into shared area and letting a trusted process > do the thing, etc.) warrants such suggestion, doesn't it? If somebody > seriously believes that it can be done (and that's the only way how this > patch could give any protection)... Well, scratch "get real", I've got a > nice bridge for sale. That's a bit OTT, no? ;) > > > -- Mark Zealey (aka JALH on irc.openprojects.net: #zealos and many more) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] UL$ (GCM/GCS/GS/GM)GUG! dpu? s-:-@ a15! C+++>$ P++$>+++@ L+++>+$ !E---? W+++>$ N++@>+ o->+ w--- !M--? !V--? PS- PE--@ !PGP? r++ !t---?@ !X---? !R- b+ !DI---? e->+ h+++*! y- (www.geekcode.com) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-pre able to mount SHM twice
This is probably due to the source being 'none', but the shm mount point can be mounted twice at the same mount point. Shouldn't mount(2) return -EBUSY in this case? # cat /etc/mtab /dev/hda4 / ext2 rw,errors=remount-ro,errors=remount-ro 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/hda1 /boot ext2 rw 0 0 /dev/hda3 /mnt/win vfat rw 0 0 none /proc/bus/usb usbdevfs rw 0 0 # mount /dev/shm # cat /etc/mtab /dev/hda4 / ext2 rw,errors=remount-ro,errors=remount-ro 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/hda1 /boot ext2 rw 0 0 /dev/hda3 /mnt/win vfat rw 0 0 none /proc/bus/usb usbdevfs rw 0 0 none /dev/shm shm rw 0 0 # mount /dev/shm # cat /etc/mtab /dev/hda4 / ext2 rw,errors=remount-ro,errors=remount-ro 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/hda1 /boot ext2 rw 0 0 /dev/hda3 /mnt/win vfat rw 0 0 none /proc/bus/usb usbdevfs rw 0 0 none /dev/shm shm rw 0 0 none /dev/shm shm rw 0 0 # umount /dev/shm # cat /etc/mtab /dev/hda4 / ext2 rw,errors=remount-ro,errors=remount-ro 0 0 proc /proc proc rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/hda1 /boot ext2 rw 0 0 /dev/hda3 /mnt/win vfat rw 0 0 none /proc/bus/usb usbdevfs rw 0 0 Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Happy new year^H^H^H^Hkernel..
Kai Germaschewski writes: > The patch is right, the explanation was wrong. Sorry, I didn't CC l-k when > I found what was really going on. Other source files used a global > initialized variable "divert_if" as well, so this became the same one as > the one referenced in isdn_common.c. That's why it wasn't zero, it was > explicitly initialized elsewhere. However, making divert_if static in > isdn_common.c fixes the problem, because now it's really local to this > file and therefore initialized to NULL. Maybe someone should compile the kernel with everything built in and -fno-common to catch stuff like this? Maybe we should always compile the kernel with -fno-common? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Hollis wrote: > On Wed, 3 Jan 2001, Alexander Viro wrote: > > On Wed, 3 Jan 2001, Dan Aloni wrote: > > > without breaking anything. It also reports of such calls by using printk. > > Get real. > > Why do you always have to be insulting alex? Sheesh. Sigh... Not intended to be an insult. Plain and simple advice. Idea is broken for absolutely obvious reasons (namely, every real-life program contains at least one syscall that it _can_ execute). Expecting _any_ part of userland to be rewritten into the form that would not have such places (i.e. all IO is done by trusted processes that poll memory areas shared with the programs needing said IO, exit is done either by explicit kill() from another process or by dumping core, signals are done by putting request into shared area and letting a trusted process do the thing, etc.) warrants such suggestion, doesn't it? If somebody seriously believes that it can be done (and that's the only way how this patch could give any protection)... Well, scratch "get real", I've got a nice bridge for sale. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Yet more benchmarks for 2.4.0-prerelease and -ac[4,5]
I ran dbench 48 four times in succession for the following recent kernels. It looks like there may be a slight drop in performance for -ac5. For -ac4 and -ac5, the throughput dropped on run #3. That's probably just a fluke. I'll repeat these runs later when I get a chance. This was performed with a Dell 420 dual P-III ( 256 MB, 733 MHz), with a ST317221A ATA DISK drive and ReiserFS 3.6.23. Each test was done under the same conditions, running KDE 2.0, one xterm, right after booting. My script did not wait between runs. 2.4.0-prerelease: average 10.9536 MB/sec Throughput 11.1771 MB/sec (NB=13.9714 MB/sec 111.771 MBit/sec) Throughput 10.7172 MB/sec (NB=13.3965 MB/sec 107.172 MBit/sec) Throughput 10.8443 MB/sec (NB=13.5554 MB/sec 108.443 MBit/sec) Throughput 11.0758 MB/sec (NB=13.8447 MB/sec 110.758 MBit/sec) 2.4.0-prerelease-ac4: average 11.4729 MB/sec Throughput 11.4646 MB/sec (NB=14.3307 MB/sec 114.646 MBit/sec) Throughput 13.3765 MB/sec (NB=16.7206 MB/sec 133.765 MBit/sec) Throughput 9.81891 MB/sec (NB=12.2736 MB/sec 98.1891 MBit/sec) Throughput 11.2315 MB/sec (NB=14.0393 MB/sec 112.315 MBit/sec) 2.4.0-prerelease-ac5: average 9.2181 MB/sec Throughput 9.18921 MB/sec (NB=11.4865 MB/sec 91.8921 MBit/sec) Throughput 9.06864 MB/sec (NB=11.3358 MB/sec 90.6864 MBit/sec) Throughput 7.69499 MB/sec (NB=9.61874 MB/sec 76.9499 MBit/sec) Throughput 10.9196 MB/sec (NB=13.6495 MB/sec 109.196 MBit/sec) Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
On Wed, 3 Jan 2001, Petr Vandrovec wrote:
> On 3 Jan 01 at 10:54, Tom Rini wrote:
> > I agree this sounds good. I just think it's too late to do it now. :)
> >
> > The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
> > now to remove it) but documented as obsolete, and removed in 2.5.
>
> I personally prefer 'video=matrox:vesa:0x105' over
> 'video=matrox:1024x768-8', as with matroxfb you can modify this mode with
> 'left', 'right', 'fv', 'fh'... options, and without these parameters it is
> unusable on fixed sync monitors (f.e. 'sync' is vital to specify
> sync-on-green feature).
>
> If someone will create modedb, which will allow specifying all parameters
> of fb_var_screeninfo, I'll remove this parsing code from matroxfb. But
> without it I think that 'vesa' will survive forever... And as I can test
> only vga16fb and matroxfb, I'm not probably right one to do this.
Just add these options to the fb_find_mode() parser in modedb.c, and they'll
work on all fbdev drivers that use modedb. There's no reason to duplicate that
code in each fbdev.
Since matroxfb has the richest set of features (even more than atyfb ;-),
you're actually in the right position to do this :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Wed, 3 Jan 2001, Dan Aloni wrote:
> +
> +void print_bad_syscall(struct task_struct *task)
> +{
> + printk("process %s (%d) tried to syscall from an executable segment!\n",
>task->comm, task->pid);
> +}
Hmm, should be "writable segment", perhaps ;-)
--
Dan Aloni
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: System crash killing idle task
[1.] System crash killing idle task [2.] I returned home after 8 hours of disuse to find the system crashed with various jibberish on the screen. As I could get no response, I could not copy all of the information I saw, but wrote down the final lines after the screenfull of jibberish: Code: 89 10 b8 01 00 00 00 c7 43 04 00 00 00 00 c7 03 00 00 00 00 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! Interrupt killer - not syncing [3.] kernel crash killing idle task [4.] Linux version 2.4.0-test12 (root@dominia) (gcc version 2.95.3 20001229 (prerelease)) #2 Mon Jan 1 13:43:25 EST 2001 [5.] I did not see an oops message. I have logged the output of ksymoops anyway, so if you need this information please notify me. [6.] No sequence of events identified [7.1.] -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux dominia 2.4.0-test12 #2 Mon Jan 1 13:43:25 EST 2001 i586 unknown Kernel modules 2.3.23 Gnu C 2.95.3 Gnu Make 3.79.1 Binutils 2.10.1.0.2 Linux C Library> libc.2.2 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.6 Mount 2.10q Net-tools 2.05 Console-tools 0.2.3 Sh-utils 2.0.11 Modules Loaded ppp_async ppp_generic slhc rtc [7.2.] processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping: 5 cpu MHz : 120.275 fdiv_bug: no hlt_bug : no f00f_bug: yes coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 bogomips: 240.03 [7.3.] ppp_async 6320 1 (autoclean) ppp_generic12928 3 (autoclean) [ppp_async] slhc4720 1 (autoclean) [ppp_generic] rtc 5408 0 (autoclean) [7.4.] (/proc/iomem) -0009fbff : System RAM 0009fc00-0009 : System RAM 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-02ff : System RAM 0010-00209e1f : Kernel code 00209e20-0021b003 : Kernel data f000-f01f : Trident Microsystems TGUI 9440 f020-f020 : Trident Microsystems TGUI 9440 - : reserved (/proc/ioports) -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(set) 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(set) 0cf8-0cff : PCI conf1 3000-300f : Intel Corporation 82371FB PIIX IDE [Triton I] 3000-3007 : ide0 3008-300f : ide1 [7.5.] lspci command not found, here is output of 'scanpci -vvv' pci bus 0x0 cardnum 0x00 function 0x: vendor 0x8086 device 0x122d Intel 82437 Triton STATUS0x2200 COMMAND 0x0006 CLASS 0x06 0x00 0x00 REVISION 0x01 HEADER0x00 LATENCY 0x20 pci bus 0x0 cardnum 0x07 function 0x: vendor 0x8086 device 0x122e Intel 82471 Triton STATUS0x0280 COMMAND 0x000f CLASS 0x06 0x01 0x00 REVISION 0x02 HEADER0x80 LATENCY 0x00 pci bus 0x0 cardnum 0x07 function 0x0001: vendor 0x8086 device 0x1230 Intel 82371 bus-master IDE controller STATUS0x0280 COMMAND 0x0005 CLASS 0x01 0x01 0x80 REVISION 0x02 BIST 0x00 HEADER 0x00 LATENCY 0x20 CACHE 0x00 BASE4 0x3001 addr 0x3000 I/O BYTE_00x8000a377 BYTE_1 0x00 BYTE_2 0x806aee0 BYTE_3 0x pci bus 0x0 cardnum 0x09 function 0x: vendor 0x1023 device 0x9440 Trident TGUI 9440 STATUS0x0200 COMMAND 0x0003 CLASS 0x03 0x00 0x00 REVISION 0xe3 BASE0 0xf000 addr 0xf000 MEM BASE1 0xf020 addr 0xf020 MEM MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0c [7.6.] No SCSI in system [7.7.] I am unaware of any further information to look for. As you can see by the kernel information, I have compiled this kernel only a few days ago, but have been running 2.2.4-test12 for a little while longer than that. I had recompiled in an attempt to get sound working properly. This is the first time I have seen anything of this magnitude happen. Thank you, Jon Eisenstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] big udelay's in fb drivers (2.4.0-prerelease)
On Wed, Jan 03, 2001 at 11:32:52PM +0200, Marko Kreen wrote: > -udelay(15000); /* delay for 50 (15) ms */ > +mdelay(15); /* delay for 50 (15) ms */ Per Mark Hahn suggestion here is a patch that fixes the weird comments too. This is cumulative to the previous patch. -- marko --- linux/drivers/video/atyfb.c.origThu Jan 4 00:08:24 2001 +++ linux/drivers/video/atyfb.c Thu Jan 4 00:09:11 2001 @@ -1722,7 +1722,7 @@ aty_st_8(CRTC_GEN_CNTL + 3, old_crtc_ext_disp | (CRTC_EXT_DISP_EN >> 24), info); -mdelay(15); /* delay for 50 (15) ms */ +mdelay(15); /* delay for 15 ms */ program_bits = pll->program_bits; locationAddr = pll->locationAddr; @@ -1754,7 +1754,7 @@ aty_st_8(CLOCK_CNTL + info->clk_wr_offset, old_clock_cntl | CLOCK_STROBE, info); -mdelay(50); /* delay for 50 (15) ms */ +mdelay(50); /* delay for 50 ms */ aty_st_8(CLOCK_CNTL + info->clk_wr_offset, ((pll->locationAddr & 0x0F) | CLOCK_STROBE), info); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
On Wed, 3 Jan 2001, Tom Rini wrote:
> On Wed, Jan 03, 2001 at 06:44:59PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 3 Jan 2001, Tom Rini wrote:
> > > Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
> >
> > I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so
> > it will work automagically for all drivers on PowerMac.
> >
> > I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of
> > the archictecture-neutral `x[-][@]' and
> > `[-][@]' arguments (which already work on mac, BTW).
>
> Quite wonderfully, almost. My monitor (ViewSonic G810) claims it can do
> 1280x1024@90, but when i boot with that on my x86 box, it comes up at 87.5
> or so (and shifted to the left ~1 penguin). But anyways..
>
> > You can already use `mac' instead of `vmode:'.
>
> Ah, is this documented anywhere? I'm sure it'd make some peoples life
> easier.
It's not documented, but read macmodes.c and modedb.c. The Mac modes have names
`mac1' to `mac20', so they can be specified using the `[-]' syntax.
> > IMHO, the less PowerMac-specific code in _each_ driver, the better.
>
> I agree this sounds good. I just think it's too late to do it now. :)
>
> The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late
> now to remove it) but documented as obsolete, and removed in 2.5.
Yep, too late for 2.4.0.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[IrDA+SMP] Lockup in handle_IRQ_event
Hi all, Having just started playing with IrDA on my dual celeron (Abit "APIC error..." BP6), I managed to kill it every single time (NMI watchdog in handle_IRQ_event) while connecting to my mobile phone (in fact, when closing the connection to the phone. even 'cat /dev/ircomm0' will do...). This is perfectly repeatable. This is with 2.4.0-prerelease (with prerelease-diff as of Wed Jan 3 15:31 UTC 2001), but also crashes with test13-pre7. Didn't test previous kernel yet, but will do if asked. hina:~$ ksymoops irda_oops-1 ksymoops 2.3.5 on i686 2.4.0-prerelease. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-prerelease/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. activating NMI Watchdog ... done. cpu: 0, clocks: 1002414, slice: 334138 cpu: 1, clocks: 1002414, slice: 334138 NMI Watchdog detected LOCKUP on CPU0, registers: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0002 eax: 0001 ebx: c15bc1e0 ecx: edx: esi: c02d1860 edi: 0003 ebp: 0003 esp: cd9e9d10 ds: 0018 es: 0018 ss: 0018 Process gsmctl (pid: 271, stackpage=cd9e9000) Stack: c02eed00 c02d1860 0003 cd9e9d48 c010a7f6 0003 cd9e9d50 c15bc1e0 cdbe2da0 cdbe2da0 c15bc1e0 c0108fbc cdbe2da0 cfab8d20 cdbe2da0 cfab8d2c cfab0018 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: a1 44 cd 2e c0 a8 01 75 f7 be 01 00 00 00 f6 43 07 20 75 01 >>EIP; c010a5e5<= Trace; c010a7f6 Trace; c0108fbc Trace; d0836181 <[irda]hashbin_remove+121/13c> Trace; d082f84e <[irda]irlmp_disconnect_request+66/98> Trace; d0837299 <[irda]irttp_disconnect_request+f1/f8> Trace; d0878d58 <[ircomm]ircomm_ttp_disconnect_request+14/18> Trace; d0878767 <[ircomm]ircomm_state_conn+83/b8> Trace; d08787c0 <[ircomm]ircomm_do_event+24/2c> Trace; d0878467 <[ircomm]ircomm_disconnect_request+17/20> Trace; d0838438 <[irda]__irias_delete_attrib+0/30> Trace; d087d2eb <[ircomm-tty]ircomm_tty_state_ready+47/a4> Trace; d087d36c <[ircomm-tty]ircomm_tty_do_event+24/2c> Trace; d087c92a <[ircomm-tty]ircomm_tty_detach_cable+72/a8> Trace; d087bfac <[ircomm-tty]ircomm_tty_shutdown+88/b8> Trace; d087b8fa <[ircomm-tty]ircomm_tty_close+c2/16c> Trace; c017e960 Trace; c017efc9 Trace; c0132af1 Trace; c0131aa2 Trace; c01184fb Trace; c0118cd3 Trace; c0118e4a Trace; c0108efb Code; c010a5e5 <_EIP>: Code; c010a5e5<= 0: a1 44 cd 2e c0mov0xc02ecd44,%eax <= Code; c010a5ea 5: a8 01 test $0x1,%al Code; c010a5ec 7: 75 f7 jne0 <_EIP> Code; c010a5ee 9: be 01 00 00 00mov$0x1,%esi Code; c010a5f3 e: f6 43 07 20 testb $0x20,0x7(%ebx) Code; c010a5f7 12: 75 01 jne15 <_EIP+0x15> c010a5fa activating NMI Watchdog ... done. cpu: 0, clocks: 1002374, slice: 334124 cpu: 1, clocks: 1002374, slice: 334124 1 warning issued. Results may not be reliable. hina:~$ grep c02ecd44 /usr/src/linux/System.map c02ecd44 B global_irq_lock Irk... CPU1 stuck in an interrupt, or global_irq_lock not released ? Any idea anyone ? .config upon request. M. PS: if you reply to this mail from the IrDA ML, please CC to me as I'm only subscribed to linux-kernel... -- Places change, faces change. Life is so very strange. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32: Error linking 2.4.0-prerelease
> I get the following errors during the final linking of 2.4.0-prerelease > on a Sparc IPX (sun4c). .config available upon request. sun4c is badly broken at the moment for other reasons. However the problems you are seeing should be fixed in cvs. Anton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] prevention of syscalls from writable segments, breakingbug exploits
On Thu, 4 Jan 2001, Dan Aloni wrote: > On Wed, 3 Jan 2001, Alexander Viro wrote: > > > > This preliminary, small patch prevents execution of system calls which > > > were executed from a writable segment. It was tested and seems to work, > > > without breaking anything. It also reports of such calls by using printk. > > > > Get real. Attacker can set whatever registers he needs and jump to one > > of the many instances of int 0x80 in libc. There goes your protection. > > But unlike syscalls, offsets inside libc do change. Aren't they? > Programs don't have to use libc, they can be compiled as static. Yes. And they will exit without system calls... how, exactly? Dumping core? Libc or not, you _will_ have 0xcd 0x80 that can be executed. It's not like searching for these two bytes was a problem, after all - several instructions is all it takes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
