nitdata=s;
> __tmp_init_str;})
I think this would fail if used in structure initialisations ?
Philipp Rumpf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
?
Philipp Rumpf
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Mar 22, 2001 at 01:14:41AM -0700, Eric W. Biederman wrote:
> Rik van Riel <[EMAIL PROTECTED]> writes:
> Is there ever a case where killing init is the right thing to do?
There are cases where panic() is the right thing to do. Broken init
is such a case.
> My impression is that if init
On Wed, Mar 21, 2001 at 08:48:54PM -0300, Rik van Riel wrote:
> On Wed, 21 Mar 2001, Patrick O'Rourke wrote:
>
> > Since the system will panic if the init process is chosen by
> > the OOM killer, the following patch prevents select_bad_process()
> > from picking init.
>
> One question ... has
On Wed, Mar 21, 2001 at 08:48:54PM -0300, Rik van Riel wrote:
On Wed, 21 Mar 2001, Patrick O'Rourke wrote:
Since the system will panic if the init process is chosen by
the OOM killer, the following patch prevents select_bad_process()
from picking init.
One question ... has the OOM
On Fri, Mar 09, 2001 at 09:09:13PM +0100, Jamie Lokier wrote:
> Rik van Riel wrote:
> > > Just raise the priority whenever the task's in kernel mode. Problem
> > > solved.
> >
> > Remember that a task schedules itself out at the timer interrupt,
> > in kernel/sched.c::schedule() ... which is
On Mon, Mar 12, 2001 at 06:03:22PM +1100, Keith Owens wrote:
> In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
> other options, the user has no control over them. It is useful for the
> kernel build process to know which variables are derived and which
> variables the
On Mon, Mar 12, 2001 at 06:03:22PM +1100, Keith Owens wrote:
In 2.4.2-ac18 there are 130 CONFIG options that are always derived from
other options, the user has no control over them. It is useful for the
kernel build process to know which variables are derived and which
variables the user
On Thu, Mar 08, 2001 at 06:10:16PM -0300, Rik van Riel wrote:
> --- linux-2.4.2-doc/include/linux/mm.h.orig Wed Mar 7 15:36:32 2001
> +++ linux-2.4.2-doc/include/linux/mm.hThu Mar 8 09:54:22 2001
> @@ -39,32 +39,37 @@
> * library, the executable area etc).
> */
> struct
On Thu, Mar 08, 2001 at 06:10:16PM -0300, Rik van Riel wrote:
--- linux-2.4.2-doc/include/linux/mm.h.orig Wed Mar 7 15:36:32 2001
+++ linux-2.4.2-doc/include/linux/mm.hThu Mar 8 09:54:22 2001
@@ -39,32 +39,37 @@
* library, the executable area etc).
*/
struct vm_area_struct
With the current rd.c code, we can get into a situation where there is
a buffer-only page for data which is also in a page cache page with
page->buffers != NULL. The current vmscan.c code never frees the page
cache page in this scenario, effectively doubling ramdisk memory
requirements.
Linus,
With the current rd.c code, we can get into a situation where there is
a buffer-only page for data which is also in a page cache page with
page-buffers != NULL. The current vmscan.c code never frees the page
cache page in this scenario, effectively doubling ramdisk memory
requirements.
Linus, I
On Sun, Mar 04, 2001 at 10:34:31PM +, Alan Cox wrote:
> > Does kmalloc() make any guarantees of the alignment of allocated
> > blocks? Will the returned block always be 4-, 8- or 16-byte
> > aligned, for example?
>
> There are people who assume 16byte alignment guarantees. I dont think
On Sun, Mar 04, 2001 at 10:34:31PM +, Alan Cox wrote:
Does kmalloc() make any guarantees of the alignment of allocated
blocks? Will the returned block always be 4-, 8- or 16-byte
aligned, for example?
There are people who assume 16byte alignment guarantees. I dont think anyone
has
On Mon, Mar 05, 2001 at 03:37:04PM +0300, Andrey Panin wrote:
> Attached patch (2.4.2-ac11) makes some changes in serial driver:
> adds ioremap() return code checks, removes panic() calls
> and adds better error handling in start_pci_pnp_board() function.
Did you test it ?
> diff -u
On Mon, Mar 05, 2001 at 03:37:04PM +0300, Andrey Panin wrote:
Attached patch (2.4.2-ac11) makes some changes in serial driver:
adds ioremap() return code checks, removes panic() calls
and adds better error handling in start_pci_pnp_board() function.
Did you test it ?
diff -u
On Sun, Mar 04, 2001 at 12:19:07AM +0100, Francis Galiegue wrote:
> Well, from reading the source, I don't see how this can break APM... What am I
> missing?
apm_bios_call must not be called with two identical pointers for
two different registers.
-
To unsubscribe from this list: send the line
On Sun, Mar 04, 2001 at 12:19:07AM +0100, Francis Galiegue wrote:
Well, from reading the source, I don't see how this can break APM... What am I
missing?
apm_bios_call must not be called with two identical pointers for
two different registers.
-
To unsubscribe from this list: send the line
On Fri, Mar 02, 2001 at 10:55:39AM +, Tigran Aivazian wrote:
> On Fri, 2 Mar 2001, Tigran Aivazian wrote:
> > On Thu, 1 Mar 2001, Alan Cox wrote:
> > > 2.4.2-ac8
> > > o Stop two people claiming the same misc dev id (Philipp Rumpf)
> >
> > is this
On Fri, Mar 02, 2001 at 03:05:32PM +0900, tachino Nobuhiro wrote:
>
> Hello,
>
> At Fri, 02 Mar 2001 00:42:28 -0500,
> <[EMAIL PROTECTED]> wrote:
> >
> > actually, its not just ps/2 mice -- it seems to be something generic to char
> > devices. agpgartis failing to register itself, too.
> >
>
On Fri, Mar 02, 2001 at 03:05:32PM +0900, tachino Nobuhiro wrote:
Hello,
At Fri, 02 Mar 2001 00:42:28 -0500,
[EMAIL PROTECTED] wrote:
actually, its not just ps/2 mice -- it seems to be something generic to char
devices. agpgartis failing to register itself, too.
what changed
On Sat, Feb 24, 2001 at 10:25:42AM -0700, Jeff Lessem wrote:
> In your message of: Sat, 24 Feb 2001 09:54:47 CST, you write:
> >Jeff, are you using the e820 memory map at all ? In particular, are you
> >using grub or some other buggy bootloader that insists on specifying a
> >mem= option on the
On Sat, Feb 24, 2001 at 05:36:47AM -0800, Linus Torvalds wrote:
> On Sat, 24 Feb 2001, Jeff Lessem wrote:
> >
> > >Also, how much memory does this machine have? That "13ff" does worry
> > >me a bit..
> >
> > The comptuer has 320MB. At this point I am ready to conclude that the
> > computer
On Sat, Feb 24, 2001 at 05:36:47AM -0800, Linus Torvalds wrote:
On Sat, 24 Feb 2001, Jeff Lessem wrote:
Also, how much memory does this machine have? That "13ff" does worry
me a bit..
The comptuer has 320MB. At this point I am ready to conclude that the
computer is broken in
On Sat, Feb 24, 2001 at 10:25:42AM -0700, Jeff Lessem wrote:
In your message of: Sat, 24 Feb 2001 09:54:47 CST, you write:
Jeff, are you using the e820 memory map at all ? In particular, are you
using grub or some other buggy bootloader that insists on specifying a
mem= option on the kernel
While misc_register() semantics are different in 2.0 from 2.[24], and the
2.[24] code would actually work in 2.0, the 2.0 code doesn't.
This fixes (I think) the case where you have softdog and a hardware
watchdog driver on the same box (and obviously want to use the hardware
watchdog).
diff -ur
misc_register() overrides misc devices with the same minor that have been
registered earlier, so if you enable both softdog and a hardware watchdog
the current initialization order will leave you with softdog only.
Should be fixed by (untested, 2.2):
diff -ur linux/drivers/char/misc.c
On Tue, 20 Feb 2001, Keith Owens wrote:
> On Mon, 19 Feb 2001 16:04:07 + (GMT),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> Using wait_for_at_least_one_schedule_on_every_cpu() has no penalty
> except on the process running rmmod. It does not require yet more
> spinlocks and is architecture
> diff -urN linux-2.4.1/arch/i386/kernel/entry.S
> linux-2.4.1-setprocuid/arch/i386/kernel/entry.S
> --- linux-2.4.1/arch/i386/kernel/entry.SThu Nov 9 02:09:50 2000
> +++ linux-2.4.1-setprocuid/arch/i386/kernel/entry.S Mon Feb 19
> 22:12:00 2001
> @@ -645,6 +645,7 @@
> .long
diff -urN linux-2.4.1/arch/i386/kernel/entry.S
linux-2.4.1-setprocuid/arch/i386/kernel/entry.S
--- linux-2.4.1/arch/i386/kernel/entry.SThu Nov 9 02:09:50 2000
+++ linux-2.4.1-setprocuid/arch/i386/kernel/entry.S Mon Feb 19
22:12:00 2001
@@ -645,6 +645,7 @@
.long
On Tue, 20 Feb 2001, Keith Owens wrote:
On Mon, 19 Feb 2001 16:04:07 + (GMT),
Alan Cox [EMAIL PROTECTED] wrote:
Using wait_for_at_least_one_schedule_on_every_cpu() has no penalty
except on the process running rmmod. It does not require yet more
spinlocks and is architecture
misc_register() overrides misc devices with the same minor that have been
registered earlier, so if you enable both softdog and a hardware watchdog
the current initialization order will leave you with softdog only.
Should be fixed by (untested, 2.2):
diff -ur linux/drivers/char/misc.c
While misc_register() semantics are different in 2.0 from 2.[24], and the
2.[24] code would actually work in 2.0, the 2.0 code doesn't.
This fixes (I think) the case where you have softdog and a hardware
watchdog driver on the same box (and obviously want to use the hardware
watchdog).
diff -ur
On Mon, 19 Feb 2001, Russell King wrote:
> Philipp Rumpf writes:
> > That still won't catch keventd oopsing though - which I think might happen
> > quite easily in real life.
>
> Maybe we should panic in that case? For example, what happens if kswapd
> oopses? krecl
On Mon, 19 Feb 2001, Alan Cox wrote:
> > So you fixed the nonexistent race only. The real race is that the module
>
> Umm I fixed the small race. You are right that there is a second race.
There's just one race. The small race is nonexistent since
put_mod_name always acts as a memory barrier.
On Mon, 19 Feb 2001, Alan Cox wrote:
> > so you hold a spinlock during copy_from_user ? Or did you change
> > sys_init_module/sys_create_modules semantics ?
>
> The only points I need to hold a spinlock are editing the chain and
> walking it in a case where I dont hold the kernel lock.
>
> So
On Mon, 19 Feb 2001, Alan Cox wrote:
> > Rusty had a patch that locked the module list properly IIRC.
>
> So does -ac now. I just take a spinlock for the modify cases that race
> against faults (including vmalloc faults from irq context)
so you hold a spinlock during copy_from_user ? Or did
On Mon, 19 Feb 2001, Andrew Morton wrote:
> David Woodhouse wrote:
> > [EMAIL PROTECTED] said:
> > > Why bother ? It looks like a leftover debugging message which
> > > doesn't make a lot of sense once the code is stable (what might make
> > > sense is checking keventd is still around, but
On Tue, 20 Feb 2001, Keith Owens wrote:
> On Mon, 19 Feb 2001 06:15:22 -0600 (CST),
> Philipp Rumpf <[EMAIL PROTECTED]> wrote:
> No need for a callin routine, you can get this for free as part of
> normal scheduling. The sequence goes :-
>
> if (use_count == 0)
On Mon, 19 Feb 2001, Keith Owens wrote:
> On Mon, 19 Feb 2001 11:35:08 + (GMT),
> Alan Cox <[EMAIL PROTECTED]> wrote:
> >The problem isnt running module code. What happens in this case
> >
> >mod->next = module_list;
> >module_list = mod; /* link it in */
> >
> >Note no
On Mon, 19 Feb 2001, Alan Cox wrote:
> mod->next = module_list;
put_mod_name() here.
> module_list = mod; /* link it in */
>
> Note no write barrier.
put_mod_name calls free_page which always implies a memory barrier. This
isn't beautiful but it won't blow up either.
On Sun, 18 Feb 2001, Kenn Humborg wrote:
> in the .config, I can get schedule_task() to fail with:
>
>schedule_task(): keventd has not started
This shouldn't be a failure case, just a (bogus) printk.
> When starting bdflush and kupdated, bdflush_init() uses a semaphore to
> make sure that
On Thu, 15 Feb 2001, Alan Cox wrote:
> Question of the day for the VM folks:
> If CPU1 is loading the exception tables for a module and
> CPU2 faults.. what happens 8)
"loading" == in sys_create_module ?
The module list is modified atomically, so either we search the new table
On Thu, 15 Feb 2001, Alan Cox wrote:
Question of the day for the VM folks:
If CPU1 is loading the exception tables for a module and
CPU2 faults.. what happens 8)
"loading" == in sys_create_module ?
The module list is modified atomically, so either we search the new table
or
On Sun, 18 Feb 2001, Kenn Humborg wrote:
in the .config, I can get schedule_task() to fail with:
schedule_task(): keventd has not started
This shouldn't be a failure case, just a (bogus) printk.
When starting bdflush and kupdated, bdflush_init() uses a semaphore to
make sure that the
On Mon, 19 Feb 2001, Alan Cox wrote:
mod-next = module_list;
put_mod_name() here.
module_list = mod; /* link it in */
Note no write barrier.
put_mod_name calls free_page which always implies a memory barrier. This
isn't beautiful but it won't blow up either.
On Mon, 19 Feb 2001, Keith Owens wrote:
On Mon, 19 Feb 2001 11:35:08 + (GMT),
Alan Cox [EMAIL PROTECTED] wrote:
The problem isnt running module code. What happens in this case
mod-next = module_list;
module_list = mod; /* link it in */
Note no write barrier.
On Tue, 20 Feb 2001, Keith Owens wrote:
On Mon, 19 Feb 2001 06:15:22 -0600 (CST),
Philipp Rumpf [EMAIL PROTECTED] wrote:
No need for a callin routine, you can get this for free as part of
normal scheduling. The sequence goes :-
if (use_count == 0) {
module_unregister
On Mon, 19 Feb 2001, Andrew Morton wrote:
David Woodhouse wrote:
[EMAIL PROTECTED] said:
Why bother ? It looks like a leftover debugging message which
doesn't make a lot of sense once the code is stable (what might make
sense is checking keventd is still around, but that's not what
On Mon, 19 Feb 2001, Alan Cox wrote:
Rusty had a patch that locked the module list properly IIRC.
So does -ac now. I just take a spinlock for the modify cases that race
against faults (including vmalloc faults from irq context)
so you hold a spinlock during copy_from_user ? Or did you
On Mon, 19 Feb 2001, Alan Cox wrote:
so you hold a spinlock during copy_from_user ? Or did you change
sys_init_module/sys_create_modules semantics ?
The only points I need to hold a spinlock are editing the chain and
walking it in a case where I dont hold the kernel lock.
So I
On Mon, 19 Feb 2001, Alan Cox wrote:
So you fixed the nonexistent race only. The real race is that the module
Umm I fixed the small race. You are right that there is a second race.
There's just one race. The small race is nonexistent since
put_mod_name always acts as a memory barrier.
On Mon, 19 Feb 2001, Russell King wrote:
Philipp Rumpf writes:
That still won't catch keventd oopsing though - which I think might happen
quite easily in real life.
Maybe we should panic in that case? For example, what happens if kswapd
oopses? kreclaimd? bdflush? kupdate? All
On Wed, 14 Feb 2001, Grant Grundler wrote:
> Philipp Rumpf wrote:
> > Jeff Garzik wrote:
> > > Looks ok, but I wonder if we should include this list in the docs.
> > > These is stuff defined by the PCI spec, and this list could potentially
> > > get lo
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Wed, 14 Feb 2001, Tim Waugh wrote:
> > +/**
> > + * pci_find_capability - query for devices' capabilities
> > + * @dev: PCI device to query
> > + * @cap: capability code
> > + *
> > + * Tell if a device supports a given PCI capability.
> > + * Returns
On Wed, 14 Feb 2001, Tim Waugh wrote:
> + * pci_find_subsys - begin or continue searching for a PCI device by
>vendor/subvendor/device/subdevice id
> + * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
> + * @device: PCI device id to match, or %PCI_ANY_ID to match all
On Wed, 14 Feb 2001, Tim Waugh wrote:
+ * pci_find_subsys - begin or continue searching for a PCI device by
vendor/subvendor/device/subdevice id
+ * @vendor: PCI vendor id to match, or %PCI_ANY_ID to match all vendor ids
+ * @device: PCI device id to match, or %PCI_ANY_ID to match all vendor
On Wed, 14 Feb 2001, Jeff Garzik wrote:
On Wed, 14 Feb 2001, Tim Waugh wrote:
+/**
+ * pci_find_capability - query for devices' capabilities
+ * @dev: PCI device to query
+ * @cap: capability code
+ *
+ * Tell if a device supports a given PCI capability.
+ * Returns the address of
On Wed, Jan 10, 2001 at 05:55:05PM +0100, Daniel Phillips wrote:
> Mark Hindley wrote:
> > I am running 2.4.0 final. I got the following failed paging request which
> > produced a complete freeze.
> >
> > As you can see it was precipitated by cron starting to run some
> > housekeeping stuff
On Wed, Jan 10, 2001 at 05:55:05PM +0100, Daniel Phillips wrote:
Mark Hindley wrote:
I am running 2.4.0 final. I got the following failed paging request which
produced a complete freeze.
As you can see it was precipitated by cron starting to run some
housekeeping stuff overnight.
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
> It must be wrong.
>
> If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but without a writepage function ? or pages
whose writepage function fails ? The current code seems
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but without a writepage function ? or pages
whose writepage function fails ? The current code seems to
}
If we want to rely solely on the add_timer_randomness checks, we should
remove the autorepeat check completely.
Philipp Rumpf
-
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/
solely on the add_timer_randomness checks, we should
remove the autorepeat check completely.
Philipp Rumpf
-
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/
On Sun, Dec 17, 2000 at 12:52:59AM -0800, Drew Hess wrote:
> It also contains an experimental patch to drivers/pci/quirks.c that forces
> standby mode for pool C RDRAM devices. I've seen some benchmarks
> comparing the Intel D850GB motherboard to the ASUS P4T and attributing the
> better
On Sun, Dec 17, 2000 at 12:52:59AM -0800, Drew Hess wrote:
It also contains an experimental patch to drivers/pci/quirks.c that forces
standby mode for pool C RDRAM devices. I've seen some benchmarks
comparing the Intel D850GB motherboard to the ASUS P4T and attributing the
better performance
On Fri, Dec 08, 2000 at 10:47:46AM +0100, Willy Tarreau wrote:
> |Bus 0, device 2, function 1:
> | Unknown class: Intel OEM MegaRAID Controller (rev 5).
> |Medium devsel. Fast back-to-back capable. BIST capable. IRQ 10. Master
> Capable. Latency=64.
> |Prefetchable 32 bit
On Fri, Dec 08, 2000 at 10:47:46AM +0100, Willy Tarreau wrote:
|Bus 0, device 2, function 1:
| Unknown class: Intel OEM MegaRAID Controller (rev 5).
|Medium devsel. Fast back-to-back capable. BIST capable. IRQ 10. Master
Capable. Latency=64.
|Prefetchable 32 bit memory at
On Fri, Dec 01, 2000 at 08:04:52PM -0500, Jeff Dike wrote:
> boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar
> with (arch/um), that is usable from the beginning of start_kernel. I don't
> know about the other arches.
setup_arch does the necessary initialization
On Fri, Dec 01, 2000 at 08:04:52PM -0500, Jeff Dike wrote:
boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar
with (arch/um), that is usable from the beginning of start_kernel. I don't
know about the other arches.
setup_arch does the necessary initialization on
On Mon, Nov 27, 2000 at 10:36:34AM -0800, H. Peter Anvin wrote:
> Followup to: <[EMAIL PROTECTED]>
> By author:Philipp Rumpf <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> >
> > I hope count isn't provided by userspace here ?
> >
> &g
On Mon, Nov 27, 2000 at 10:36:34AM -0800, H. Peter Anvin wrote:
Followup to: [EMAIL PROTECTED]
By author:Philipp Rumpf [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
I hope count isn't provided by userspace here ?
1. What happens if the user space memory is swapped to disk
On Sun, Nov 26, 2000 at 02:21:31PM +0100, Anders Torger wrote:
> memcpy_toio(iobase, user_space_src, count);
I hope count isn't provided by userspace here ?
> 1. What happens if the user space memory is swapped to disk? Will
> verify_area() make sure that the memory is in physical RAM
On Sun, Nov 26, 2000 at 10:37:07AM +, Tigran Aivazian wrote:
> On Sat, 25 Nov 2000, Tim Waugh wrote:
> > Why doesn't the compiler just leave out explicit zeros from the
> > 'initial data' segment then? Seems like it ought to be tought to..
>
> yes, taught to, _BUT_ never let this to be a
On Sun, Nov 26, 2000 at 04:25:05AM +, Alan Cox wrote:
> static int a=0;
>
> says 'I thought about this. I want it to start at zero. I've written it this
> way to remind of the fact'
>
> Sure it generates the same code
I agree it would be best if gcc would generate the same code;
On Sun, Nov 26, 2000 at 04:25:05AM +, Alan Cox wrote:
static int a=0;
says 'I thought about this. I want it to start at zero. I've written it this
way to remind of the fact'
Sure it generates the same code
I agree it would be best if gcc would generate the same code;
On Sun, Nov 26, 2000 at 02:21:31PM +0100, Anders Torger wrote:
memcpy_toio(iobase, user_space_src, count);
I hope count isn't provided by userspace here ?
1. What happens if the user space memory is swapped to disk? Will
verify_area() make sure that the memory is in physical RAM when
On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
> > _trylock functions return 0 for success.
>
> Not spin_trylock
Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean
unlocked. You're correct, and obviously this should be fixed.
-
To unsubscribe from this
On Sat, Nov 25, 2000 at 03:49:25PM -0200, Rik van Riel wrote:
> On Sat, 25 Nov 2000, Roger Larsson wrote:
>
> > Questions:
> > What are _trylocks supposed to return?
>
> It depends on the type of _trylock ;(
>
> > Does spin_trylock and down_trylock behave differently?
> > Why isn't the
On Sat, Nov 25, 2000 at 03:49:25PM -0200, Rik van Riel wrote:
On Sat, 25 Nov 2000, Roger Larsson wrote:
Questions:
What are _trylocks supposed to return?
It depends on the type of _trylock ;(
Does spin_trylock and down_trylock behave differently?
Why isn't the expected
On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote:
_trylock functions return 0 for success.
Not spin_trylock
Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean
unlocked. You're correct, and obviously this should be fixed.
-
To unsubscribe from this list:
On Fri, Nov 10, 2000 at 02:21:28AM -0500, Jeff Garzik wrote:
> The following is a piece of code from the latter half of
> schedule_timeout, in kernel/sched.c. Is it possible that
> schedule_timeout could return an incorrect value, if the jiffy value
> wraps between the first and last lines shown
On Fri, Nov 10, 2000 at 02:21:28AM -0500, Jeff Garzik wrote:
The following is a piece of code from the latter half of
schedule_timeout, in kernel/sched.c. Is it possible that
schedule_timeout could return an incorrect value, if the jiffy value
wraps between the first and last lines shown
On Sun, Nov 05, 2000 at 06:19:21PM +0100, Heusden, Folkert van wrote:
> I wrote a daemon that fetches (as root-user) random numbers from the RNG in
> the i82808 (found on 815-chipsets).
> You can download it from http://www.vanheusden.com/Linux/random.php3 .
> Currently, I'm trying to rewrite
On Sun, Nov 05, 2000 at 06:19:21PM +0100, Heusden, Folkert van wrote:
I wrote a daemon that fetches (as root-user) random numbers from the RNG in
the i82808 (found on 815-chipsets).
You can download it from http://www.vanheusden.com/Linux/random.php3 .
Currently, I'm trying to rewrite things
>
> 3. Security
>
> * Fix module remove race bug (still to be done: TTY, ldisc, I2C,
>video_device - Al Viro) (Rogier Wolff will handle ATM)
TBD: sysctl, kernel_thread
* drivers/input/mousedev.c dereferences userspace pointers directly. We
should make this fail for a bit to
3. Security
* Fix module remove race bug (still to be done: TTY, ldisc, I2C,
video_device - Al Viro) (Rogier Wolff will handle ATM)
TBD: sysctl, kernel_thread
* drivers/input/mousedev.c dereferences userspace pointers directly. We
should make this fail for a bit to catch
On Sat, Oct 28, 2000 at 11:50:22AM -0400, Brian Gerst wrote:
> Philipp Rumpf wrote:
> >
> > On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
> > > Yes, but they can be called (and sleep) with module refcount == 0. This
> > > is because the file des
On Sat, Oct 28, 2000 at 11:50:22AM -0400, Brian Gerst wrote:
Philipp Rumpf wrote:
On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
Yes, but they can be called (and sleep) with module refcount == 0. This
is because the file descripter used to perform the ioctl isn't
On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
> Yes, but they can be called (and sleep) with module refcount == 0. This
> is because the file descripter used to perform the ioctl isn't directly
> associated with the network device, thereby not incrementing the
> refcount on open.
On Sat, Oct 28, 2000 at 09:37:28AM -0400, Brian Gerst wrote:
> Philipp Rumpf wrote:
> > - you can't copy_(from|to)_user in the module exit function (which would
> > be copies from/to rmmod anyway)
>
> Unfortunately, you need to be able to use copy_*_user() from
On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
> Look, this modules stuff is really bad. Phillip Rumpf proposed
> a radical alternative a while back which I felt was not given
While it might be a "radical alternative", it doesn't require any changes
to the subsystems that have
On Fri, Oct 27, 2000 at 10:49:53PM +1100, Andrew Morton wrote:
Look, this modules stuff is really bad. Phillip Rumpf proposed
a radical alternative a while back which I felt was not given
While it might be a "radical alternative", it doesn't require any changes
to the subsystems that have
On Sat, Oct 28, 2000 at 09:37:28AM -0400, Brian Gerst wrote:
Philipp Rumpf wrote:
- you can't copy_(from|to)_user in the module exit function (which would
be copies from/to rmmod anyway)
Unfortunately, you need to be able to use copy_*_user() from the network
ioctls
On Sat, Oct 28, 2000 at 09:55:21AM -0400, Brian Gerst wrote:
Yes, but they can be called (and sleep) with module refcount == 0. This
is because the file descripter used to perform the ioctl isn't directly
associated with the network device, thereby not incrementing the
refcount on open.
On Fri, Oct 20, 2000 at 10:47:45AM -0700, Linus Torvalds wrote:
> On Fri, 20 Oct 2000, Philipp Rumpf wrote:
> >
> > Single Unix specifies that 0-byte reads, as well as 0-byte writes, should
> > "return 0 and have no other results". Our current implementation vio
Single Unix specifies that 0-byte reads, as well as 0-byte writes, should
"return 0 and have no other results". Our current implementation violates
the first requirement and makes it very easy to violate the second one.
read(page_cache_fd, invalid_ptr, 0) returns -EFAULT; IMHO, this is a
Single Unix specifies that 0-byte reads, as well as 0-byte writes, should
"return 0 and have no other results". Our current implementation violates
the first requirement and makes it very easy to violate the second one.
read(page_cache_fd, invalid_ptr, 0) returns -EFAULT; IMHO, this is a
On Fri, Oct 20, 2000 at 10:47:45AM -0700, Linus Torvalds wrote:
On Fri, 20 Oct 2000, Philipp Rumpf wrote:
Single Unix specifies that 0-byte reads, as well as 0-byte writes, should
"return 0 and have no other results". Our current implementation violates
the first requirement
how much of a problem this is going to be yet,
> but I'm sure it's going to be fun :-)
512 byte pages, 4 bytes per pte ? Ouch. Can you fill the TLB manually ?
OTOH, I think mapping all physical memory makes sense with the three page
table setup.
Philipp Rumpf
-
To unsubscribe
1 - 100 of 136 matches
Mail list logo
