Async-io is completely untested, if somebody adapts the user libs and
test it I'd love to hear if it really works :). thanks.
URL:
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19rc3aa4.gz
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19rc3aa4/
Only in 2.4.19rc3aa4: 00_coherent-oops-locking-1
Lock around the printk in mm/fault.c too (from Benjamin LaHaise).
Only in 2.4.19rc3aa3: 00_extraversion-2
Only in 2.4.19rc3aa4: 00_extraversion-3
Bump extraversion (popular request).
Only in 2.4.19rc3aa4: 00_stack-overflow-detection-1
Detect stack overflows dynamically during irqs (from Benjamin LaHaise)
Only in 2.4.19rc3aa4: 05_vm_20_cleanups-1
Avoid a few minor compile warnings.
Only in 2.4.19rc3aa3: 10_rawio-vary-io-10
Only in 2.4.19rc3aa4: 10_rawio-vary-io-11
Fix typo.
Only in 2.4.19rc3aa3: 10_sched-o1-hyperthreading-1
Only in 2.4.19rc3aa4: 10_sched-o1-hyperthreading-2
Fix another typo, and reorganized algorithm
from J.A. Magallon.
Only in 2.4.19rc3aa4: 50_uml-patch-2.4.18-47.gz
Only in 2.4.19rc3aa3: 52_uml-sys-read-write-3
Only in 2.4.19rc3aa4: 52_uml-sys-read-write-4
Latest uml updates from Jeff.
Only in 2.4.19rc3aa3: 70_xfs-1.1-4.gz
Only in 2.4.19rc3aa4: 70_xfs-1.1-5.gz
Rediffed.
Only in 2.4.19rc3aa3: 90_module-oops-tracking-2
Only in 2.4.19rc3aa4: 90_module-oops-tracking-3
Fix a typo (noticed with an impressive low latency by Keith Owens ;)
Only in 2.4.19rc3aa4: 9900_aio-1.gz
Merged async-io from Benjamin LaHaise after purifying it from the
/proc/libredhat.so mess that made it not binary compatible with 2.5.
While merging I did a number of cleanups and fixes, to mention a few of
them I fixed a shell root exploit in map_user_kvect by using
get_user_pages (that honours VM_MAYWRITE), it avoids corruption of
KM_IRQ0 by doing spin_lock_irq in aio_read_evt, and a number of other
minor not security and not stability related changes. Left out the
networking async-io, it can be merged trivially at a later stage (if
needed :).
This breaks all archs except x86 again. I just took care of the most
obvious bits like highmem and kmap-types in the kiovec api, but still
the wtd semaphores are missing and they go down to asm. So to compile
on alpha s390 and s390x for now you can simply backout this patch
called 9900__aio-1.gz and it should work fine then.
Only in 2.4.19rc3aa4: 9900_aio-API-x86-1
Implement a real API to use async-io with true registered syscalls
(to avoid the not 2.5 forward compatible dynamic syscalls and
/proc/libredhat.so hack).
Patch for 2.5 to register the true syscalls in mainline is here:
http://www.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.5/2.5.29/aio-api-1
Andrea
> Only in 2.4.19rc3aa4: 9900_aio-1.gz
>
> Merged async-io from Benjamin LaHaise after purifying it from the
> /proc/libredhat.so mess that made it not binary compatible with 2.5.
As there is no finished aio ABI for 2.5 it can't be binary compatible. But
unlike your version Ben's patch is not very likely to conflict with new
2.5 features soon. An no, there is no such thing as /proc/libredhat.so in
his patch.
On 20020730 Andrea Arcangeli wrote:
>
> Only in 2.4.19rc3aa3: 10_sched-o1-hyperthreading-1
> Only in 2.4.19rc3aa4: 10_sched-o1-hyperthreading-2
>
It works fine this time....
BTW, are you aware of this in -aa ? I need this patch:
--- linux/include/asm-i386/processor.h Fri Jul 19 00:37:45 2002
+++ linux/include/asm-i386/processor.h~ Fri Jul 19 00:38:48 2002
@@ -401,7 +401,7 @@
{ [0 ... 7] = 0 }, /* debugging registers */ \
0, 0, 0, \
{ { 0, }, }, /* 387 state */ \
- 0,0,0,0,0,0, \
+ 0,0,0,0,0, \
0,{~0,} /* io permissions */ \
}
to shut up gcc and match the struct definition:
/* floating point info */
union i387_union i387;
/* virtual 86 mode info */
struct vm86_struct * vm86_info;
unsigned long screen_bitmap;
unsigned long v86flags, v86mask, saved_esp0;
/* IO permissions */
int ioperm;
unsigned long io_bitmap[IO_BITMAP_SIZE+1];
Coud be serious to have io_bitmap == 0 instead of == ~0 ??
--
J.A. Magallon \ Software is like sex:
junk.able.es \ It's better when it's free
Mandrake Linux release 9.0 (Cooker) for i586
Linux 2.4.19-rc3-jam4 (gcc 3.2 (Mandrake Linux 9.0 3.2-0.2mdk))
On Tue, Jul 30, 2002 at 09:42:02AM +0100, Christoph Hellwig wrote:
> > Only in 2.4.19rc3aa4: 9900_aio-1.gz
> >
> > Merged async-io from Benjamin LaHaise after purifying it from the
> > /proc/libredhat.so mess that made it not binary compatible with 2.5.
>
> As there is no finished aio ABI for 2.5 it can't be binary compatible. But
> unlike your version Ben's patch is not very likely to conflict with new
Yes, my version will clash if the API changes in 2.5, but I will adapt it with
whatever API will showup in 2.5. This is in developement process of course.
I just need to ship something right now and in order to do that without the
libredhat I've to risk to be incompatible for a short period of time.
> 2.5 features soon. An no, there is no such thing as /proc/libredhat.so in
> his patch.
it may not be in /proc to save some byte of kernel ram but it doesn't matter
where such bytecode is located.
Andrea
On Tuesday 30 July 2002 16:36, J.A. Magallon wrote:
> BTW, are you aware of this in -aa ? I need this patch:
>
> --- linux/include/asm-i386/processor.h Fri Jul 19 00:37:45 2002
> +++ linux/include/asm-i386/processor.h~ Fri Jul 19 00:38:48 2002
> @@ -401,7 +401,7 @@
> { [0 ... 7] = 0 }, /* debugging registers */ \
> 0, 0, 0, \
> { { 0, }, }, /* 387 state */ \
> - 0,0,0,0,0,0, \
> + 0,0,0,0,0, \
> 0,{~0,} /* io permissions */ \
> }
>
> to shut up gcc and match the struct definition:
>
> /* floating point info */
> union i387_union i387;
> /* virtual 86 mode info */
> struct vm86_struct * vm86_info;
> unsigned long screen_bitmap;
> unsigned long v86flags, v86mask, saved_esp0;
> /* IO permissions */
> int ioperm;
> unsigned long io_bitmap[IO_BITMAP_SIZE+1];
>
> Coud be serious to have io_bitmap == 0 instead of == ~0 ??
It should be written "= {.io_bitmap = {~0}}" but that's still
bogus: only the first array element gets the ones, probably not
what was intended.
--
Daniel
On Tue, Jul 30, 2002 at 08:02:18AM +0200, Andrea Arcangeli wrote:
> Merged async-io from Benjamin LaHaise after purifying it from the
> /proc/libredhat.so mess that made it not binary compatible with 2.5.
>
> While merging I did a number of cleanups and fixes, to mention a few of
> them I fixed a shell root exploit in map_user_kvect by using
> get_user_pages (that honours VM_MAYWRITE), it avoids corruption of
> KM_IRQ0 by doing spin_lock_irq in aio_read_evt, and a number of other
> minor not security and not stability related changes. Left out the
> networking async-io, it can be merged trivially at a later stage (if
> needed :).
Care to explain the problem and provide a separate patch for all the
people who aren't using your tree of patches? If there's a problem
as you claim, then it likely affects map_user_kiobuf too.
-ben
On Wed, Jul 31, 2002 at 05:08:02PM -0400, Benjamin LaHaise wrote:
> On Tue, Jul 30, 2002 at 08:02:18AM +0200, Andrea Arcangeli wrote:
> > Merged async-io from Benjamin LaHaise after purifying it from the
> > /proc/libredhat.so mess that made it not binary compatible with 2.5.
> >
> > While merging I did a number of cleanups and fixes, to mention a few of
> > them I fixed a shell root exploit in map_user_kvect by using
> > get_user_pages (that honours VM_MAYWRITE), it avoids corruption of
> > KM_IRQ0 by doing spin_lock_irq in aio_read_evt, and a number of other
> > minor not security and not stability related changes. Left out the
> > networking async-io, it can be merged trivially at a later stage (if
> > needed :).
>
> Care to explain the problem and provide a separate patch for all the
> people who aren't using your tree of patches? If there's a problem
I'm sorry but I'm too busy with another thing at the moment to extract
patches, (I should have time after 13 August). In the meantime you can
see the most important changes by diffing memory.c and aio.c yourself.
The VM_MAYWRITE sec fix is the get_user_pages change in the core of
map_user_kiovec, that should be very visible, the other one was just a
missing _irq around a spinlock to protect KM_IRQ0 from irq races, that
should be very visible too by diffing aio.c against aio.c. The other
changes should be mostly cosmetical or related to the purification from
the dyanmic syscall (ah, and I dropped the nosense _GPL,
EXPORT_SYMBOL_GPL doesn't make sense as said in one of my last emails of
such thread, I've no idea why it's not been nucked from modutils and 2.5
yet, as said either the ksyms linkage is a GPL barrier or it isn't,
there is no such intermediate thing as a EXPORT_SYMBOL_GPL non GPL
barrier).
_GPL doesn't make any sense for a very simple reason: anybody can write
a regular EXPORT_SYMBOL function that just calls your _GPL exported
function once inside the kernel to bypass the _GPL tag. And if you claim
that the wrapper is illegal then all non GPL modules are illegal in the
first place, so making the _GPL tag again a nosense.
> as you claim, then it likely affects map_user_kiobuf too.
kiobuf side in been fixed in mainline some time ago, it only affects
the map_user_kiovec in your patch as far I can tell, but it would be
nice if you could double check, thanks.
Andrea