Oops in 3.10.99 -- NULL pointer dereference in radeon_fence_ref

The following patch to radeon_sa_bo_new that went into 3.10.99 commit 8d5e1e5af0c667545c202e8f4051f77aa3bf31b7 Author: Nicolai Hähnle Date: Fri Feb 5 14:35:53 2016 -0500 drm/radeon: hold reference to fences in radeon_sa_bo_new commit

Oops in 3.10.99 -- NULL pointer dereference in radeon_fence_ref

The following patch to radeon_sa_bo_new that went into 3.10.99 commit 8d5e1e5af0c667545c202e8f4051f77aa3bf31b7 Author: Nicolai Hähnle Date: Fri Feb 5 14:35:53 2016 -0500 drm/radeon: hold reference to fences in radeon_sa_bo_new commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

On Mon Nov 19, 2007 at 07:52:37PM +0100, Ingo Molnar wrote: > > * Erik Andersen <[EMAIL PROTECTED]> wrote: > > > On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote: > > > > > > By popular demand, here is release -v24 of the CFS scheduler pa

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote: > > By popular demand, here is release -v24 of the CFS scheduler patch. > > It is a full backport of the latest & greatest scheduler code to > v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be > downloaded from the

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote: By popular demand, here is release -v24 of the CFS scheduler patch. It is a full backport of the latest greatest scheduler code to v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be downloaded from the usual

Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7

On Mon Nov 19, 2007 at 07:52:37PM +0100, Ingo Molnar wrote: * Erik Andersen [EMAIL PROTECTED] wrote: On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote: By popular demand, here is release -v24 of the CFS scheduler patch. It is a full backport of the latest greatest

Re: userspace pagecache management tool

On Sat Mar 03, 2007 at 02:26:09PM -0800, Andrew Morton wrote: > On Sat, 03 Mar 2007 17:19:00 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote: > > > > It is *not* a global instruction. It uses setenv, so the user's policy > > > affects only the target process and its forked children. > > > > ...

Re: userspace pagecache management tool

On Sat Mar 03, 2007 at 02:26:09PM -0800, Andrew Morton wrote: On Sat, 03 Mar 2007 17:19:00 -0500 Rik van Riel [EMAIL PROTECTED] wrote: It is *not* a global instruction. It uses setenv, so the user's policy affects only the target process and its forked children. ... and all other

Re: [RFC] Limit the size of the pagecache

On Wed Jan 24, 2007 at 06:58:42AM -0800, Christoph Lameter wrote: > On Wed, 24 Jan 2007, Nick Piggin wrote: > > > I can't argue that a smaller pagecache will be subject to a > > higher turnaround given the same workload, but I don't know why > > that would be a good thing. > > Neither do I.

Re: [RFC] Limit the size of the pagecache

On Wed Jan 24, 2007 at 06:58:42AM -0800, Christoph Lameter wrote: On Wed, 24 Jan 2007, Nick Piggin wrote: I can't argue that a smaller pagecache will be subject to a higher turnaround given the same workload, but I don't know why that would be a good thing. Neither do I. Wonder why we

Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)

On Wed Jan 17, 2007 at 08:29:53AM +1100, Andi Kleen wrote: > AMD is looking at the issue. Only Nvidia chipsets seem to be affected, > although there were similar problems on VIA in the past too. > Unless a good workaround comes around soon I'll probably default > to iommu=soft on Nvidia. I just

Re: data corruption with nvidia chipsets and IDE/SATA drives (k8 cpu errata needed?)

On Wed Jan 17, 2007 at 08:29:53AM +1100, Andi Kleen wrote: AMD is looking at the issue. Only Nvidia chipsets seem to be affected, although there were similar problems on VIA in the past too. Unless a good workaround comes around soon I'll probably default to iommu=soft on Nvidia. I just tried

Re: O_DIRECT question

On Fri Jan 12, 2007 at 05:09:09PM -0500, Linus Torvalds wrote: > I suspect a lot of people actually have other reasons to avoid caches. > > For example, the reason to do O_DIRECT may well not be that you want to > avoid caching per se, but simply because you want to limit page cache >

Re: O_DIRECT question

On Fri Jan 12, 2007 at 05:09:09PM -0500, Linus Torvalds wrote: I suspect a lot of people actually have other reasons to avoid caches. For example, the reason to do O_DIRECT may well not be that you want to avoid caching per se, but simply because you want to limit page cache activity. In

Re: [patch] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h

On Sat Dec 16, 2006 at 01:42:11PM -0500, Mike Frysinger wrote: > On 11/30/06, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > >but there are a few other > >cases which still contain compound preprocessor directives such as: > > > > #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2) >

Re: [patch] scrub non-__GLIBC__ checks in linux/socket.h and linux/stat.h

On Sat Dec 16, 2006 at 01:42:11PM -0500, Mike Frysinger wrote: On 11/30/06, Robert P. J. Day [EMAIL PROTECTED] wrote: but there are a few other cases which still contain compound preprocessor directives such as: #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ 2) having

Re: [PATCH] support HDIO_GET_IDENTITY in libata

On Thu Dec 14, 2006 at 03:31:30PM -0500, Jeff Garzik wrote: > Erik Andersen wrote: > >+if (!atapi_enabled && dev->class == ATA_DEV_ATAPI) { > > This seems like an impossible condition? Hmm, suppose so. Do you think that simply doing: if (d

[PATCH] support HDIO_GET_IDENTITY in libata

drive. Perhaps enough other people care about this ioctl that it might make it into the official libata tree. Well tested with a number of months of use. Signed-off-by: Erik Andersen <[EMAIL PROTECTED]> -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This messag

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Thu Dec 14, 2006 at 11:23:11AM +0200, Muli Ben-Yehuda wrote: > > I just realized that booting with "iommu=soft" makes my pcHDTV > > HD5500 DVB cards not work. Time to go back to disabling the > > memhole and losing 1 GB. :-( > > That points to a bug in the driver (likely) or swiotlb

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Thu Dec 14, 2006 at 11:23:11AM +0200, Muli Ben-Yehuda wrote: I just realized that booting with iommu=soft makes my pcHDTV HD5500 DVB cards not work. Time to go back to disabling the memhole and losing 1 GB. :-( That points to a bug in the driver (likely) or swiotlb (unlikely), as

[PATCH] support HDIO_GET_IDENTITY in libata

other people care about this ioctl that it might make it into the official libata tree. Well tested with a number of months of use. Signed-off-by: Erik Andersen [EMAIL PROTECTED] -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post

Re: [PATCH] support HDIO_GET_IDENTITY in libata

On Thu Dec 14, 2006 at 03:31:30PM -0500, Jeff Garzik wrote: Erik Andersen wrote: +if (!atapi_enabled dev-class == ATA_DEV_ATAPI) { This seems like an impossible condition? Hmm, suppose so. Do you think that simply doing: if (dev-class == ATA_DEV_ATAPI) { here

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Mon Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote: > We could not reproduce the data corruption anymore if we boot > the machines with the kernel parameter "iommu=soft" i.e. if we > use software bounce buffering instead of the hw-iommu. I just realized that booting with "iommu=soft"

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Mon Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote: > Last week we did some more testing with the following result: > > We could not reproduce the data corruption anymore if we boot the machines > with the kernel parameter "iommu=soft" i.e. if we use software bounce > buffering

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Mon Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote: Last week we did some more testing with the following result: We could not reproduce the data corruption anymore if we boot the machines with the kernel parameter iommu=soft i.e. if we use software bounce buffering instead of

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Mon Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote: We could not reproduce the data corruption anymore if we boot the machines with the kernel parameter iommu=soft i.e. if we use software bounce buffering instead of the hw-iommu. I just realized that booting with iommu=soft makes my

[PATCH] make sata_promise PATA ports work

what I would expect, so this (or something very much like it) should be applied upstream. Signed-off-by: Erik Andersen <[EMAIL PROTECTED]> -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- diff --git a/drive

[PATCH] make sata_promise PATA ports work

what I would expect, so this (or something very much like it) should be applied upstream. Signed-off-by: Erik Andersen [EMAIL PROTECTED] -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- diff --git a/drivers/ata

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Sat Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote: > The issue was basically the following: > I found a severe bug mainly by fortune because it occurs very rarely. > My test looks like the following: I have about 30GB of testing data on > my harddisk,... I repeat verifying

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

On Sat Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote: The issue was basically the following: I found a severe bug mainly by fortune because it occurs very rarely. My test looks like the following: I have about 30GB of testing data on my harddisk,... I repeat verifying sha512

Re: [RFC] Splitting out kernel<=>userspace ABI headers

On Fri Sep 02, 2005 at 10:53:19PM -0700, H. Peter Anvin wrote: > Erik Andersen wrote: > >On Fri Sep 02, 2005 at 10:22:20PM -0700, H. Peter Anvin wrote: > > > >>Exportable types need to be double-underscore types, because the header > >>files in user space that

Re: [RFC] Splitting out kernel=userspace ABI headers

On Fri Sep 02, 2005 at 10:53:19PM -0700, H. Peter Anvin wrote: Erik Andersen wrote: On Fri Sep 02, 2005 at 10:22:20PM -0700, H. Peter Anvin wrote: Exportable types need to be double-underscore types, because the header files in user space that would include them can generally not include

Re: [RFC] Splitting out kernel<=>userspace ABI headers

On Fri Sep 02, 2005 at 10:22:20PM -0700, H. Peter Anvin wrote: > Exportable types need to be double-underscore types, because the header > files in user space that would include them can generally not include > . I'm not talking about kernel headers that have to worry about eventually being

Re: [RFC] Splitting out kernel<=>userspace ABI headers

On Sat Sep 03, 2005 at 12:07:58AM +, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Erik Andersen <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > > > That would be wonderful. > > > > > > It wo

Re: [RFC] Splitting out kernel<=>userspace ABI headers

On Fri Sep 02, 2005 at 04:51:49PM -0400, Kyle Moffett wrote: > On Sep 2, 2005, at 09:41:09, Erik Andersen wrote: > >Have you seen the linux-libc-headers: > >http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ > >which, while not an official part of the kernel, do

Re: [RFC] Splitting out kernel<=>userspace ABI headers

On Thu Sep 01, 2005 at 11:00:16PM -0400, Kyle Moffett wrote: > A while ago there was a big discussion about splitting out the > userspace-accessible portions of the kernel headers into a separate > directory, "kabi", "kernel-abi", "linux-abi", or a half-dozen other > suggestions. Linus sprinkled

Re: [RFC] Splitting out kernel=userspace ABI headers

On Thu Sep 01, 2005 at 11:00:16PM -0400, Kyle Moffett wrote: A while ago there was a big discussion about splitting out the userspace-accessible portions of the kernel headers into a separate directory, kabi, kernel-abi, linux-abi, or a half-dozen other suggestions. Linus sprinkled a bit of

Re: [RFC] Splitting out kernel=userspace ABI headers

On Fri Sep 02, 2005 at 04:51:49PM -0400, Kyle Moffett wrote: On Sep 2, 2005, at 09:41:09, Erik Andersen wrote: Have you seen the linux-libc-headers: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ which, while not an official part of the kernel, do a pretty good job... Well

Re: [RFC] Splitting out kernel=userspace ABI headers

On Sat Sep 03, 2005 at 12:07:58AM +, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Erik Andersen [EMAIL PROTECTED] In newsgroup: linux.dev.kernel uClibc maintainer hat on That would be wonderful. /off It would be especially nice if everything targeting

Re: [RFC] Splitting out kernel=userspace ABI headers

On Fri Sep 02, 2005 at 10:22:20PM -0700, H. Peter Anvin wrote: Exportable types need to be double-underscore types, because the header files in user space that would include them can generally not include stdint.h. I'm not talking about kernel headers that have to worry about eventually

Re: BKCVS broken ?

On Thu Mar 17, 2005 at 04:10:53PM -0800, Larry McVoy wrote: > I got swamped, I'll look at this after dinner. But you might take a look > at this: http://www.bitkeeper.com/press/2005-03-17.html which is a link > to a very simple open source BK client. It doesn't do much except track > the head of

Re: BKCVS broken ?

On Thu Mar 17, 2005 at 04:10:53PM -0800, Larry McVoy wrote: I got swamped, I'll look at this after dinner. But you might take a look at this: http://www.bitkeeper.com/press/2005-03-17.html which is a link to a very simple open source BK client. It doesn't do much except track the head of the

Re: [BK] upgrade will be needed

On Mon Feb 14, 2005 at 11:29:20AM -0800, Larry McVoy wrote: > On Mon, Feb 14, 2005 at 09:49:32AM -0800, lm wrote: > > If it were spread out over the thousands of sites like your > > usage is then it would be more, there's a lot more overhead. There are > > currently more than 2,200 top level

Re: [BK] upgrade will be needed

On Mon Feb 14, 2005 at 11:29:20AM -0800, Larry McVoy wrote: On Mon, Feb 14, 2005 at 09:49:32AM -0800, lm wrote: If it were spread out over the thousands of sites like your usage is then it would be more, there's a lot more overhead. There are currently more than 2,200 top level domains

Re: [ANNOUNCE] hotplug-ng 001 release

On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote: > It's not only pci, but all types of busses need this kind of "coldplug" > functionality. And yes, I have plans to provide that functionality in > this package too. > > In fact, if anyone looking to contribute some well defined and easy to

Re: [ANNOUNCE] hotplug-ng 001 release

On Fri Feb 11, 2005 at 09:01:44AM -0800, Greg KH wrote: It's not only pci, but all types of busses need this kind of coldplug functionality. And yes, I have plans to provide that functionality in this package too. In fact, if anyone looking to contribute some well defined and easy to test

Re: test11-pre6

On Thu Nov 16, 2000 at 08:45:10PM -0700, Jeff V. Merkey wrote: > > > > - pre6: > > - Intel: start to add Pentium IV specific stuff (128-byte cacheline > > etc) > > - David Miller: search-and-destroy places that forget to mark us > > running after removing us from a

Re: test11-pre6

On Thu Nov 16, 2000 at 08:45:10PM -0700, Jeff V. Merkey wrote: - pre6: - Intel: start to add Pentium IV specific stuff (128-byte cacheline etc) - David Miller: search-and-destroy places that forget to mark us running after removing us from a wait-queue. Level I

Re: Q: Linux rebooting directly into linux.

On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote: > > All mkelfImage does is the pasting of initrd's, command lines, > and just a touch of argument conversion code. You can link in an initrd using linker magic, i.e. $(OBJCOPY) --add-section=image=kernel

Re: Q: Linux rebooting directly into linux.

On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote: All mkelfImage does is the pasting of initrd's, command lines, and just a touch of argument conversion code. You can link in an initrd using linker magic, i.e. $(OBJCOPY) --add-section=image=kernel

Re: Q: Linux rebooting directly into linux.

On Thu Nov 09, 2000 at 01:18:24AM -0700, Eric W. Biederman wrote: > > I have recently developed a patch that allows linux to directly boot > into another linux kernel. Looks very cool. I'm curious about your decision to use ELF images. This makes it much less conveinient to use due to the

Re: PATCH: killing read_ahead[]

On Wed Oct 25, 2000 at 02:15:05PM -0600, Jeff V. Merkey wrote: > > > Alexander Viro wrote: > > > > On Wed, 25 Oct 2000, Jeff V. Merkey wrote: > > > > > Al, > > > > > > Thanks. I'll print this one out and post it on the wall for tonight's > > > debugging session. > > [snip] > > > > (e.g.

Re: Patch for /proc/mounts problems on 2.2.x

On Wed Oct 25, 2000 at 12:16:40PM -0700, H. Peter Anvin wrote: > Erik Andersen wrote: > > > > On Wed Oct 25, 2000 at 11:43:02AM -0700, H. Peter Anvin wrote: > > > > > > There is another good reason to ditch /etc/mtab: as a static file, it > > >

Re: Patch for /proc/mounts problems on 2.2.x

On Wed Oct 25, 2000 at 11:43:02AM -0700, H. Peter Anvin wrote: > > There is another good reason to ditch /etc/mtab: as a static file, it And it is supposed to be writable though it lives in /etc. It should live in /var. Has the LSB ever gotten around to addressing this wart? This is a pita

Re: Patch for /proc/mounts problems on 2.2.x

On Wed Oct 25, 2000 at 08:16:07PM +0200, Andries Brouwer wrote: > > Your web page misses the loop device info. > > Another point of difference is the name of the root device. > /proc/mounts has /dev/root, while /etc/mtab usually has > whatever was listed for / in /etc/fstab. > > For some

Re: Patch for /proc/mounts problems on 2.2.x

On Wed Oct 25, 2000 at 08:16:07PM +0200, Andries Brouwer wrote: Your web page misses the loop device info. Another point of difference is the name of the root device. /proc/mounts has /dev/root, while /etc/mtab usually has whatever was listed for / in /etc/fstab. For some applications

Re: Patch for /proc/mounts problems on 2.2.x

On Wed Oct 25, 2000 at 11:43:02AM -0700, H. Peter Anvin wrote: There is another good reason to ditch /etc/mtab: as a static file, it And it is supposed to be writable though it lives in /etc. It should live in /var. Has the LSB ever gotten around to addressing this wart? This is a pita for

Re: Patch for /proc/mounts problems on 2.2.x

On Wed Oct 25, 2000 at 12:16:40PM -0700, H. Peter Anvin wrote: Erik Andersen wrote: On Wed Oct 25, 2000 at 11:43:02AM -0700, H. Peter Anvin wrote: There is another good reason to ditch /etc/mtab: as a static file, it And it is supposed to be writable though it lives in /etc

Re: PATCH: killing read_ahead[]

On Wed Oct 25, 2000 at 02:15:05PM -0600, Jeff V. Merkey wrote: Alexander Viro wrote: On Wed, 25 Oct 2000, Jeff V. Merkey wrote: Al, Thanks. I'll print this one out and post it on the wall for tonight's debugging session. [snip] (e.g. generic_commit_write have to

Re: 2.2.18pre and Duron detection

On Thu Oct 05, 2000 at 02:09:24PM +0200, Meelis Roos wrote: > 2.2.18pre12 detects Duron 600 almost fine (even reports 64K cache) but > fails to identify some cpu flags (6, 14, 17). /proc/cpuinfo output: > I see the same thing on my Athlon. Funny I never noticed it before... andersen@slag:~$

Re: 2.2.18pre and Duron detection

On Thu Oct 05, 2000 at 02:09:24PM +0200, Meelis Roos wrote: 2.2.18pre12 detects Duron 600 almost fine (even reports 64K cache) but fails to identify some cpu flags (6, 14, 17). /proc/cpuinfo output: I see the same thing on my Athlon. Funny I never noticed it before... andersen@slag:~$ cat

Re: Soft-Updates for Linux ?

On Sun Oct 01, 2000 at 04:54:05PM +0100, Alan Cox wrote: > > What of those journalled file systems are more prominent to success 2.5. > > jffs is in 2.4 (but its a log structured fs for flash memory not generic) > ext3 and reiserfs are both being used in production boxes as add ons Unless

Re: Soft-Updates for Linux ?

On Sun Oct 01, 2000 at 04:54:05PM +0100, Alan Cox wrote: What of those journalled file systems are more prominent to success 2.5. jffs is in 2.4 (but its a log structured fs for flash memory not generic) ext3 and reiserfs are both being used in production boxes as add ons Unless someone

Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

On Wed Sep 27, 2000 at 07:42:00PM +0200, Andrea Arcangeli wrote: > > You should of course poll the /proc/meminfo. (/proc/meminfo works in O(1) in > 2.4.x so it's just the overhead of a read syscall) Or sysinfo(2). Same thing... -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This

Re: [patch] vmfixes-2.4.0-test9-B2 - fixing deadlocks

On Wed Sep 27, 2000 at 07:42:00PM +0200, Andrea Arcangeli wrote: You should of course poll the /proc/meminfo. (/proc/meminfo works in O(1) in 2.4.x so it's just the overhead of a read syscall) Or sysinfo(2). Same thing... -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This

Re: the new VMt

On Tue Sep 26, 2000 at 06:08:20PM +0100, Stephen C. Tweedie wrote: > Hi, > > On Tue, Sep 26, 2000 at 11:02:48AM -0600, Erik Andersen wrote: > > > Another approach would be to let user space turn off overcommit. > > No. Overcommit only applies to pageable memory.

Re: the new VMt

On Tue Sep 26, 2000 at 05:04:06PM +0100, Stephen C. Tweedie wrote: > Hi, > > On Tue, Sep 26, 2000 at 09:17:44AM -0600, [EMAIL PROTECTED] wrote: > > > Operating systems cannot make more memory appear by magic. > > The question is really about the best strategy for dealing with low memory. In my

Re: Calling userspace apps from within kernel

On Tue Sep 26, 2000 at 03:18:54PM +1000, Daniel Walls wrote: > Hi, > > I was wondering if it is possible to execute a userspace application from > within the kernel (particularly binfmt_elf.c)... > something along the lines of execl()... > > If so, what is the name of the function used

Re: Calling userspace apps from within kernel

On Tue Sep 26, 2000 at 03:18:54PM +1000, Daniel Walls wrote: Hi, I was wondering if it is possible to execute a userspace application from within the kernel (particularly binfmt_elf.c)... something along the lines of execl()... If so, what is the name of the function used to do

Re: the new VMt

On Tue Sep 26, 2000 at 05:04:06PM +0100, Stephen C. Tweedie wrote: Hi, On Tue, Sep 26, 2000 at 09:17:44AM -0600, [EMAIL PROTECTED] wrote: Operating systems cannot make more memory appear by magic. The question is really about the best strategy for dealing with low memory. In my

Re: the new VMt

On Mon Sep 25, 2000 at 02:04:19PM -0600, [EMAIL PROTECTED] wrote: > > > all of the pending requests just as long as they are serialised, is > > this a problem? > > I think you are solving the wrong problem. On a small memory machine, the kernel, > utilities, and applications should be

Re: the new VMt

On Mon Sep 25, 2000 at 02:04:19PM -0600, [EMAIL PROTECTED] wrote: all of the pending requests just as long as they are serialised, is this a problem? I think you are solving the wrong problem. On a small memory machine, the kernel, utilities, and applications should be configured to use

Re: Proposal: Linux Kernel Patch Management System

On Wed Sep 13, 2000 at 02:49:01AM -0700, David S. Miller wrote: >From: Daniel Quinlan <[EMAIL PROTECTED]> >Date: Wed, 13 Sep 2000 02:49:51 -0700 (PDT) > >> Very simply, (drumroll please) I want to run diff. :-) > >I think this is an orthogonal problem. Realtime diffs are good

Re: Proposal: Linux Kernel Patch Management System

On Wed Sep 13, 2000 at 02:49:01AM -0700, David S. Miller wrote: From: Daniel Quinlan [EMAIL PROTECTED] Date: Wed, 13 Sep 2000 02:49:51 -0700 (PDT) Very simply, (drumroll please) I want to run diff. :-) I think this is an orthogonal problem. Realtime diffs are good for