>> Under 2.2.13 some programs cause the kernel error messages
>>
>> fd_offset is not page aligned. Please convert program: foo
>> N_TXTOFF is not page aligned. Please convert library: bar.so.6.0
>>
>> And what is worse, such programs now segfault where they
>> worked fine under 2.2.12.
>
>Drop the patch to fs/binfmt_aout. (You only actually want to drop the bits
>that dont rate limit the messages but thats not an issue for a private box)
>
>I'll dump that diff in 2.2.14pre1. Andrea - this looks like your zmagic
>fix has some problems.
Note Alan, that you didn't merged the patch I proposed. As you can see
from the quoted email, the patch I proposed you was "zmagic-only-fix" that
looks like this:
--- 2.2.13pre14/fs/binfmt_aout.c Tue Sep 28 18:32:37 1999
+++ /tmp/binfmt_aout.c Sat Oct 2 23:32:33 1999
@@ -424,7 +424,7 @@
if (!file->f_op || !file->f_op->mmap) {
sys_close(fd);
- do_mmap(NULL, 0, ex.a_text+ex.a_data,
+ do_mmap(NULL, N_TXTADDR(ex), ex.a_text+ex.a_data,
PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_FIXED|MAP_PRIVATE, 0);
read_exec(bprm->dentry, fd_offset,
and zmagic-only-fix is an obviously right one liner that will only fix a
bug.
andrea@alpha:~/kernel/kernel.org > find -name zmagic-only-fix\*
./patches/v2.2/2.2.13pre14/zmagic-only-fix.bz2
./patches/v2.2/2.2.13pre14/zmagic-only-fix.gz
You instead included into 2.2.13pre18 another patch called "zmagic-5" and
that's other stuff and I have not proposed it for inclusion into the
official 2.2.13.
andrea@alpha:~/kernel/kernel.org > find -name zmagic-5\*
./patches/v2.2/2.2.13pre17/zmagic-5.gz
Maybe you did a browse of my ftp area and you find out zmagic-5.gz and you
applyed it thinking it was the zmagic-only-fix patch? Unfortunately
zmagic-5 was still code under testing in beta release (I considered it
right, but this is another story).
Of course the name was similar (as both the two patches plays with zmagic
stuff) but the "only-fix" was a very small _subset_ of the zmagic-5 patch
and I generated the "only-fix" exactly to only fix the bug fast just in
2.2.13 without adding new features.
When I seen my zmagic-5 in the pre18 I thought "hug, strange, how can
zmagic-5 be in the pre patches? Probably Alan is interested in such
fature and agreed with the code.".
I'll go into the zmagic-5 reports now and I'll provide a fix (or I'll
simply confirm as the right one one of the fixes just present on the
list). I'll at least take advantage of this additional (not expeted)
testing of the zmagic-5 patch, to be more productive. Then I'll port the
fixes to 2.3.x as well later.
On Mon, 11 Oct 1999, Andrea Arcangeli wrote:
>
>Date: Mon, 11 Oct 1999 16:03:46 +0200 (CEST)
>From: Andrea Arcangeli <andrea@suse.de>
>To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
> Linus Torvalds <torvalds@transmeta.com>
>Cc: linux-kernel@vger.rutgers.edu, Bernd Kaindl <bk@suse.de>
>Subject: Andrea's pending 2.2.x patches
>
>These are all the patches that I would like to see included into 2.2.x.
>They are all against 2.2.13pre15.
>
>Of course the oom patch for example is not suggested to be included into
>the soon 2.2.13 as it breaks all archs except Alpha and i386 (the only two
>ones I have just fixed myself), but I would like to see it included into
>the future 2.2.14. Also the SMP scheduler is only an improvement and so it
>can be delayed too even if it replaces some SMP not optimal heuristc.
>
>o buffer-races-2.2.10-A -> set_blocksize and invalidate_buffers
> may follow a refiled buffer on
> a wrong buffer lru list.
>o free_page-2.2.12 -> cleanedup the new page_alloc
> __free_page code (see the
> patch, it's strightforward).
>o oom-2.2.12-I -> oom fixes for potential DoS
> that can lockup the machine
> also incidentally due OOM. Avoid
> init to get a sigsegv during OOM.
> Fix alpha sigbus with shared
> mappings. On i386 avoid sigkill
> to iopl() tasks.
> Breaks all arch except Alpha and
> i386.
>o probe-irq-2.3.14-pre2-1 -> If an irq was pending right now
> it's marked as spurious.
>o mknod-unixsock-nosymlink -> Avoid mknod and bind on
> unix sockets to follow symlinks
> (obviously right one liner).
> Probably you just did that
> in your tree as I seen
> you said Linux will do that too.
>o smp-reschedule-boot-2.3.13-1 -> Avoid to lockup at boot due
> the idle task of a secondary
> cpu rescheduled on the master
> cpu due too long SMP
> boot time (lots of CPUs).
>o wait-event-smp-races -> obviously right necessary mb()s.
>o wait4-smp-race -> Fix for a subtle wait4() race
> that will show up as an userspace
> deadlock where the parent remains
> blocked in wait4() while
> the zombie child exited under the
> parent. (can happen only if
> the parent masks SIGCHLD before
> calling wait4, exactly as
> bash does every time it spawn
> a task).
>o wakeup_bdflush-2.2.10-A -> avoid deadlock with blocking
> request_fn callbacks (e.g.
> lo_request).
>o zmagic-only-fix -> fix a bug in the a.out code that
> will cause a segfault if triggers.
>o clear-backlog-2 -> fix a SMP race in the common
> device backlog (where the irq
> queue packets that will be
> processed from net_bh()).
>o hashed-buffers-2.2.10 -> increase decrease the stats
> in the right place (can't harm
> as the stats will show up only
> in SYSRQ+M).
>o kupdate-sigstop-2.2.11 -> allow to stop/start kupdate
> with a SIGSTOP/SIGCONT
> (right now you must set the
> interval to zero to stop it).
>o no-needed-comment-2.2.12-final3 -> reverse some code merged
> from the large-fd set patch
> (make no assembler difference).
>o no-swapout-2.2.10-B -> allow 2.2.x to run on big
> machines during heavy I/O load
> without swapin/swapouts all the
> time.
>o shrink_all_cache-2.2.10-A -> avoid limits to the minimum level
> of cache (iteresting for
> big memory machines, for others
> won't make a real difference).
>o trashing-mem-2.2.10-A -> use a per-TASK lowmemory bit
> instead of a global low_on_memory.
> This block very much the hog
> and let the system to run
> smootly under swap. The algorithm
> is the same, only a bit more
> biased.
>o xtime-lock-alpha -> allow alpha to compile
> kernel/time.c (you just know
> about that, my due, sorry).
>o SMP-scheduler-2.2.11-E -> reschedule_idle SMP rewrite
> (SMP performance patch).
>o endbase-2.2.10 -> use the EDBA to know the
> endbase address, but this patch
> won't break the old machines and
> it allows some new machine to
> run fine.
> The endbase address can also
> be overidden with the endbase
> kernel parameter (I updated
> also the Documentation/ relevant
> txt file).
>o inode-leak-2.2.10 -> avoid any kind of inode leak
> (problem with sockets). I don't
> consider this one optimal of
> course (2.3.20 with dynamic
> inodes is better ;), but
> at least the kernel won't silenty
> leak memory.
>
>You'll find all the patches I described above in this directory:
>
> ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/proposed/v2.2/2.2.13pre15/
>
>As they are not controversial they can be applyed with any order.
>
>Andrea
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>Please read the FAQ at http://www.tux.org/lkml/
>
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/