2.4.21pre5aa1

2.4.21pre5aa1

[Andrea Arcangeli]

URL:

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.21pre5aa1.gz
	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.21pre5aa1/

diff between 2.4.21pre4aa3 and 2.4.21pre5aa1 [notably an hard to trigger
race that could lead to a deadlock is been fixed, such race could happen
only in 2.4.21pre4aa3, not in any other version]

Only in 2.4.21pre5aa1: 00_backout-set_cpus_allowed-1

	This is just provided by the o1 sched.

Only in 2.4.21pre5aa1: 00_clean-inode-fix-1

	Reset r_dev.

Only in 2.4.21pre5aa1: 00_close-root-fd-1

	Let init get the right fd for stdin/out with initrd.

Only in 2.4.21pre4aa3: 00_elevator-backmerge-1
Only in 2.4.21pre4aa3: 00_mmap-TASK_SIZE-len-1
Only in 2.4.21pre4aa3: 00_msgrcv-smp-race-1
Only in 2.4.21pre4aa3: 00_nfs-xid-smp-1
Only in 2.4.21pre4aa3: 00_reiserfs-o_direct-1
Only in 2.4.21pre4aa3: 00_sbp2-1
Only in 2.4.21pre4aa3: 00_scx200-1
Only in 2.4.21pre4aa3: 00_tcp-retrans-collapse-1
Only in 2.4.21pre4aa3: 00_vmalloc-ltp-crash-1

	Merged in mainline.

Only in 2.4.21pre4aa3: 00_extraversion-19
Only in 2.4.21pre5aa1: 00_extraversion-20
Only in 2.4.21pre4aa3: 00_rwsem-fair-35
Only in 2.4.21pre4aa3: 00_rwsem-fair-35-recursive-8
Only in 2.4.21pre5aa1: 00_rwsem-fair-36
Only in 2.4.21pre5aa1: 00_rwsem-fair-36-recursive-8
Only in 2.4.21pre5aa1: 00_sched-O1-aa-2.4.19rc3-10.gz
Only in 2.4.21pre4aa3: 00_sched-O1-aa-2.4.19rc3-9.gz
Only in 2.4.21pre4aa3: 00_silent-stack-overflow-17
Only in 2.4.21pre5aa1: 00_silent-stack-overflow-18
Only in 2.4.21pre4aa3: 20_pte-highmem-28.gz
Only in 2.4.21pre5aa1: 20_pte-highmem-29.gz
Only in 2.4.21pre4aa3: 50_uml-patch-2.4.19-50.gz
Only in 2.4.21pre5aa1: 50_uml-patch-2.4.19-50-1.gz
Only in 2.4.21pre4aa3: 82_x86_64-suse-7
Only in 2.4.21pre5aa1: 82_x86_64-suse-9
Only in 2.4.21pre4aa3: 9931_io_request_scale-drivers-2
Only in 2.4.21pre5aa1: 9931_io_request_scale-drivers-3
Only in 2.4.21pre4aa3: 9995_frlock-gettimeofday-2
Only in 2.4.21pre5aa1: 9995_frlock-gettimeofday-4
Only in 2.4.21pre4aa3: 9999_gcc-3.3-2
Only in 2.4.21pre5aa1: 9999_gcc-3.3-3

	Rediffed.

Only in 2.4.21pre4aa3: 00_nfs-2.4.17-pathconf-2
Only in 2.4.21pre5aa1: 30_14-pathconf-2

	Renamed.

Only in 2.4.21pre4aa3: 00_radeon-Mobility9000-1
Only in 2.4.21pre5aa1: 00_radeon-Mobility9000-2

	Add a missing 'braek'.

Only in 2.4.21pre5aa1: 00_smp-timers-not-deadlocking-1

	Corrected varsion of the smp timers that can deadlock in 2.5
	and in all kernels that were used to incorporate this patch,
	including jam. This is fixed so that a timer reinserting
	itself to run immediate, won't loop forever deadlocking
	a CPU spinning in a tight loop. This bug was present in
	ancient 2.4 kernels too and this is been fixed after bugreports
	in both 2.2 and again in 2.4 because we forgotten to forward
	port it to 2.4, these fixes must be forward ported today
	to 2.5 too. Fixed also run_all_timers to correctly convert
	the logical to physical cpu id (doesn't matter on x86, but
	run_all_timers doesn't matter either on x86, other archs
	may need this fix to avoid crashing too). This patch
	was originally written from Ingo Molnar, David Miller with the help of
	Alexey Kuznetsov, for more details see the timer.c added credit lines.

Only in 2.4.21pre5aa1: 22_sched-deadlock-mmdrop-1

	Backport from 2.5 (in a more icache friendy way) an anti-deadlock
	fix for the o1 scheduler that can otherwise send a cross IPI with
	irq disabled.

Only in 2.4.21pre5aa1: 30_00_fix_symlink-1
Only in 2.4.21pre5aa1: 30_01_fix_softirq-1
Only in 2.4.21pre4aa3: 30_03_call-reserve2-1
Only in 2.4.21pre5aa1: 30_03_call-reserve2-2
Only in 2.4.21pre4aa3: 30_09_o_direct-2
Only in 2.4.21pre5aa1: 30_09_o_direct-3
Only in 2.4.21pre5aa1: 30_15-xprt_fixes-1
Only in 2.4.21pre5aa1: 30_16_rpciod-lock-1
Only in 2.4.21pre5aa1: 30_17-fix_read-1

	Various nfs updates. This fixes several highmem issues with nfs.
	From Trond, Chuck and various sources, for more details read:

		http://www.fys.uio.no/~trondmy/src/2.4.21-pre5/

Only in 2.4.21pre4aa3: 51_uml-o1-3
Only in 2.4.21pre5aa1: 51_uml-o1-4

	Added some o1 sched support to UML and let
	schedule_tail be called for UP too accordingly with the
	sched-deadlock-mmdrop bugfix.

Only in 2.4.21pre4aa3: 60_tux-timer_t-1
Only in 2.4.21pre5aa1: 60_tux-timer_t-2.gz

	Part of it obsoleted by smptimers.

Only in 2.4.21pre4aa3: 9900_aio-17.gz
Only in 2.4.21pre5aa1: 9900_aio-18.gz

	Cleaned up the whole asm/kmap_types.h mess, moved
	kmap_types.h into linux/, this must be visible
	for aio and it has to be the same for all archs so it doesn't belong to
	asm/.

Only in 2.4.21pre4aa3: 9910_shm-largepage-10.gz
Only in 2.4.21pre5aa1: 9910_shm-largepage-11.gz

	64bit cleanups.

Only in 2.4.21pre4aa3: 9920_kgdb-6.gz
Only in 2.4.21pre5aa1: 9920_kgdb-7.gz

	Documentation bits.

Only in 2.4.21pre5aa1: 9985_blk-atomic-aa6-jfs-1

	Fix collision with blk-atomic.

Only in 2.4.21pre4aa3: 9998_lowlatency-fixes-11
Only in 2.4.21pre5aa1: 9998_lowlatency-fixes-12

	Fixed deadlock bug in write_some_buffers (see l-k for details).

Only in 2.4.21pre5aa1: 9999_fsync-msync-async-errors-1

	Allow userspace to always be notified about async write failures
	when calling msync and fsync even if they happened long before
	the systemcall run.

Only in 2.4.21pre5aa1: 9999_sched_yield_scale-1

	Use a sched_yield that scales well by default, this should
	help with JVM or applications with huge lock contention in
	the current libpthread, but it will hurt interactivity
	of those apps if there's some background load. For openoffice
	set the sysctl back to 0, you don't mind if sched_yield
	doesn't allow the colliding-workloads to scale well. The
	scale-behaviour is also the preferred one for all sched_yield
	usages in the kernel. Over time nothing should call sched_yield()
	anymore, this is an hack for now.

Andrea

Re: 2.4.21pre5aa1

[Marc-Christian Petersen]

On Friday 14 March 2003 10:08, Andrea Arcangeli wrote:

Hi Andrea,

> Only in 2.4.21pre4aa3: 60_tux-timer_t-1
> Only in 2.4.21pre5aa1: 60_tux-timer_t-2.gz
^^ hmm, this file is empty?

> 	Part of it obsoleted by smptimers.


ciao, Marc

Re: 2.4.21pre5aa1

[Andrea Arcangeli]

On Fri, Mar 14, 2003 at 11:15:55AM +0100, Marc-Christian Petersen wrote:
> On Friday 14 March 2003 10:08, Andrea Arcangeli wrote:
> 
> Hi Andrea,
> 
> > Only in 2.4.21pre4aa3: 60_tux-timer_t-1
> > Only in 2.4.21pre5aa1: 60_tux-timer_t-2.gz
> ^^ hmm, this file is empty?
> 
> > 	Part of it obsoleted by smptimers.

it was "all of it" then ;)

Andrea

Re: 2.4.21pre5aa1

[Andrew Morton]

Andrea Arcangeli <andrea@suse.de> wrote:
>
> Only in 2.4.21pre5aa1: 00_clean-inode-fix-1
> 
> 	Reset r_dev.

oops.  What problem was this observed to cause btw?

> Only in 2.4.21pre5aa1: 00_smp-timers-not-deadlocking-1
> 
> 	Corrected varsion of the smp timers that can deadlock in 2.5
> 	and in all kernels that were used to incorporate this patch,
> 	including jam.

OK, I'll take a look at that thanks.

> 	This is fixed so that a timer reinserting
> 	itself to run immediate, won't loop forever deadlocking
> 	a CPU spinning in a tight loop. This bug was present in
> 	ancient 2.4 kernels too and this is been fixed after bugreports
> 	in both 2.2 and again in 2.4 because we forgotten to forward
> 	port it to 2.4, these fixes must be forward ported today
> 	to 2.5 too. Fixed also run_all_timers to correctly convert
> 	the logical to physical cpu id (doesn't matter on x86, but
> 	run_all_timers doesn't matter either on x86, other archs
> 	may need this fix to avoid crashing too). This patch
> 	was originally written from Ingo Molnar, David Miller with the help of
> 	Alexey Kuznetsov, for more details see the timer.c added credit lines.

This code is buggy.  See

http://linux.bkbits.net:8080/linux-2.5/user=akpm/cset@1.786.202.5?nav=!-|index.html|stats|!+|index.html|ChangeSet@-6M


> Only in 2.4.21pre5aa1: 9999_fsync-msync-async-errors-1
> 
> 	Allow userspace to always be notified about async write failures
> 	when calling msync and fsync even if they happened long before
> 	the systemcall run.

The code in shrink_cache() has a couple of problems.

a) If someone else is truncating the file at the same time,
   block_write_full_page() will see the page is outside i_size and will
   return -EIO.  That will be propagated into the address_space and
   userspace will see a bogus I/O error.

   Fix: just return zero from writepage-outside-i_size.  There are several
   instances.

b) Can't touch `mapping' after calling writepage().  The page can now be
   unlocked, truncated off the inode and the inode could be freed up.

   No, I don't have a testcase ;)

   The fix is to lock the page again, see if it still has a ->mapping,
   then set mapping->error.

Re: 2.4.21pre5aa1

[Marc-Christian Petersen]

On Friday 14 March 2003 10:08, Andrea Arcangeli wrote:

Hi Andrea,

> Only in 2.4.21pre5aa1: 22_sched-deadlock-mmdrop-1
>
> 	Backport from 2.5 (in a more icache friendy way) an anti-deadlock
> 	fix for the o1 scheduler that can otherwise send a cross IPI with
> 	irq disabled.
I get _tons_ of these messages:

Initializing RT netlink socket
rq->prev_mm was c025b0e0 set to c025b0e0 - swapper
dffddf4c c0115786 c023b1a0 c025b0e0 c025b0e0 dffdc24e dffddfbc dffce02c 
       dffdc000 00000000 dffdc000 dffddfbc c0105000 0008e000 c01072bd 00000700 
       c0125d00 c02916a8 dffddfbc c0105000 0008e000 00000002 c01e0018 dffd0018 
Call Trace: [<c0115786>]  [<c0105000>]  [<c01072bd>]  [<c0125d00>]  
[<c0105000>]  [<c01e0018>]  [<c0105685>]  [<c0125faf>]  [<c0125d00>]  
[<c0105043>]  [<c01050
00>]  [<c010568e>]  [<c0105030>] 
rq->prev_mm was c025b0e0 set to c025b0e0 - keventd
dffcff4c c0115786 c023b1a0 c025b0e0 c025b0e0 dffce24e 00000011 dffdc02c 
       dffce000 00000000 dffce570 dffce580 dffce256 dffce000 c0125e2d 00000011 
       dffcffa0 00000000 dffce570 dffce580 dffce000 00000001 00000000 83e58955 
Call Trace: [<c0115786>]  [<c0125e2d>]  [<c0105000>]  [<c0105000>]  
[<c010568e>]  [<c0125d00>] 
rq->prev_mm was c025b0e0 set to c025b0e0 - ksoftirqd_CPU0
dffcdf9c c0115786 c023b1a0 c025b0e0 c025b0e0 dffcc24e dffcc24e dffdc02c 
       dffcc000 00000000 dffcc000 dffcc000 dffcc000 0008e000 c011d8fe dffcc24e 
       c023ae48 00000000 00010f00 dffddfb8 c0105000 c010568e 00000000 c011d880 
Call Trace: [<c0115786>]  [<c011d8fe>]  [<c0105000>]  [<c010568e>]  
[<c011d880>] 
Starting kswapd
rq->prev_mm was c025b0e0 set to c025b0e0 - kswapd
dffcbf84 c0115786 c023b1a0 c025b0e0 c025b0e0 dffca24e 0fe45589 dffdc02c 
       dffca000 00000000 dffca000 dffcbfc4 ffffffff 0008e000 c0134306 c01071c4 
       00000000 dffca000 c025e490 c025e490 00000000 0008e000 00000000 dffd0018 
Call Trace: [<c0115786>]  [<c0134306>]  [<c01071c4>]  [<c0105000>]  
[<c010568e>]  [<c0134270>] 
bigpage subsystem: allocated 0 bigpages (=0MB).
rq->prev_mm was c025b0e0 set to c025b0e0 - bdflush
dffc9f78 c0115786 c023b1a0 c025b0e0 c025b0e0 dffc824e 3dd3ac3f dffdc02c 
       dffc8000 00000000 00000286 c023afca dffc8256 dffc9fd8 c0115b3f 00000000 
       dffc8000 c025ee04 c025ee04 00000000 00000282 000001f4 c023afca 000001f4 
Call Trace: [<c0115786>]  [<c0115b3f>]  [<c0140c5a>]  [<c0105000>]  
[<c010568e>]  [<c0140b90>] 
rq->prev_mm was c025b0e0 set to c025b0e0 - kupdated
dffc7f64 c0115786 c023b1a0 c025b0e0 c025b0e0 dffc624e 0001080d dffdc02c 
       dffc6000 00000000 0000021e dffc7fac dffc6000 dffc6000 c0121265 dffc7fac 
       83080da2 45890cec c02cbb44 c02cbb44 0000021e dffc6000 c01211f0 c02cb320 
Call Trace: [<c0115786>]  [<c0121265>]  [<c01211f0>]  [<c0140cfc>]  
[<c0105000>]  [<c010568e>]  [<c0140c70>] 
aio_setup: num_physpages = 32760
aio_setup: sizeof(struct page) = 44

....

rq->prev_mm was c40dddc0 set to c40ddf00 - grep
cb795f64 c0115786 c023b1a0 c40dddc0 c40ddf00 cb79424e c011bd9d cb7fc02c 
       cb794000 00000000 c16fa7a0 c158d200 cb794000 00000000 c011c1da cb794000 
       c16fa7a0 cb794000 4012e8c4 00000000 bffff838 c011c233 00000000 c010720f 
Call Trace: [<c0115786>]  [<c011bd9d>]  [<c011c1da>]  [<c011c233>]  
[<c010720f>] 
rq->prev_mm was c40ddf00 set to cb78a0c0 - grep
cb789f64 c0115786 c023b1a0 c40ddf00 cb78a0c0 cb78824e c011bd9d cb7fc02c 
       cb788000 00000000 c16fa760 c158d200 cb788000 00000000 c011c1da cb788000 
       c16fa760 cb788000 4012e8c4 00000000 bffff838 c011c233 00000000 c010720f 
Call Trace: [<c0115786>]  [<c011bd9d>]  [<c011c1da>]  [<c011c233>]  
[<c010720f>]



Machine:

Celeron 1,3GHz, UP, 512MB RAM, IDE.


ciao, Marc

Re: 2.4.21pre5aa1

[Rik van Riel]

On Fri, 14 Mar 2003, Andrea Arcangeli wrote:

> Only in 2.4.21pre4aa3: 9900_aio-17.gz
> Only in 2.4.21pre5aa1: 9900_aio-18.gz
> 
> 	Cleaned up the whole asm/kmap_types.h mess, moved
> 	kmap_types.h into linux/, this must be visible
> 	for aio and it has to be the same for all archs so it doesn't belong to
> 	asm/.

Maybe I'm dense, maybe it's early on a friday morning, maybe
even both ... but I don't understand why architectures without
highmem should have kmap_types.h

Re: 2.4.21pre5aa1

[Marc-Christian Petersen]

On Friday 14 March 2003 14:39, Marc-Christian Petersen wrote:

Hi Andrea,

> I get _tons_ of these messages:

> rq->prev_mm was c40dddc0 set to c40ddf00 - grep
> cb795f64 c0115786 c023b1a0 c40dddc0 c40ddf00 cb79424e c011bd9d cb7fc02c
>        cb794000 00000000 c16fa7a0 c158d200 cb794000 00000000 c011c1da
> cb794000 c16fa7a0 cb794000 4012e8c4 00000000 bffff838 c011c233 00000000
> c010720f Call Trace: [<c0115786>]  [<c011bd9d>]  [<c011c1da>]  [<c011c233>]
> [<c010720f>]
> rq->prev_mm was c40ddf00 set to cb78a0c0 - grep
> cb789f64 c0115786 c023b1a0 c40ddf00 cb78a0c0 cb78824e c011bd9d cb7fc02c
>        cb788000 00000000 c16fa760 c158d200 cb788000 00000000 c011c1da
> cb788000 c16fa760 cb788000 4012e8c4 00000000 bffff838 c011c233 00000000
> c010720f Call Trace: [<c0115786>]  [<c011bd9d>]  [<c011c1da>]  [<c011c233>]
> [<c010720f>]
> Machine:
> Celeron 1,3GHz, UP, 512MB RAM, IDE.

hmm dunno why the following line were not in the pastings above.

Call Trace: [do_schedule+471/656] [do_exit+522/560] [sys_exit+19/32] 
[system_call+51/56]

ciao, Marc

Re: 2.4.21pre5aa1

[Marc-Christian Petersen]

On Friday 14 March 2003 14:39, Marc-Christian Petersen wrote:

Hi Andrea,

> > Only in 2.4.21pre5aa1: 22_sched-deadlock-mmdrop-1
> > 	Backport from 2.5 (in a more icache friendy way) an anti-deadlock
> > 	fix for the o1 scheduler that can otherwise send a cross IPI with
> > 	irq disabled.

> I get _tons_ of these messages:
>
> Initializing RT netlink socket
> rq->prev_mm was c025b0e0 set to c025b0e0 - swapper
> dffddf4c c0115786 c023b1a0 c025b0e0 c025b0e0 dffdc24e dffddfbc dffce02c
>        dffdc000 00000000 dffdc000 dffddfbc c0105000 0008e000 c01072bd
> 00000700 c0125d00 c02916a8 dffddfbc c0105000 0008e000 00000002 c01e0018
> ....

I am going to rip out 22_sched-deadlock-mmdrop-1 because I dunno how to fix 
this. The trace is annoying ;)

ciao, Marc

Re: 2.4.21pre5aa1

[Andrea Arcangeli]

On Fri, Mar 14, 2003 at 04:50:29AM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > Only in 2.4.21pre5aa1: 00_clean-inode-fix-1
> > 
> > 	Reset r_dev.
> 
> oops.  What problem was this observed to cause btw?

some apps complains that the file in ocfs is a raw device while it's
really a regular file.

> 
> > Only in 2.4.21pre5aa1: 00_smp-timers-not-deadlocking-1
> > 
> > 	Corrected varsion of the smp timers that can deadlock in 2.5
> > 	and in all kernels that were used to incorporate this patch,
> > 	including jam.
> 
> OK, I'll take a look at that thanks.

thanks

> 
> > 	This is fixed so that a timer reinserting
> > 	itself to run immediate, won't loop forever deadlocking
> > 	a CPU spinning in a tight loop. This bug was present in
> > 	ancient 2.4 kernels too and this is been fixed after bugreports
> > 	in both 2.2 and again in 2.4 because we forgotten to forward
> > 	port it to 2.4, these fixes must be forward ported today
> > 	to 2.5 too. Fixed also run_all_timers to correctly convert
> > 	the logical to physical cpu id (doesn't matter on x86, but
> > 	run_all_timers doesn't matter either on x86, other archs
> > 	may need this fix to avoid crashing too). This patch
> > 	was originally written from Ingo Molnar, David Miller with the help of
> > 	Alexey Kuznetsov, for more details see the timer.c added credit lines.
> 
> This code is buggy.  See
> 
> http://linux.bkbits.net:8080/linux-2.5/user=akpm/cset@1.786.202.5?nav=!-|index.html|stats|!+|index.html|ChangeSet@-6M

yet another kernel crashing bug in the smptimers :(, I'll backport the
fix thanks!

> 
> 
> > Only in 2.4.21pre5aa1: 9999_fsync-msync-async-errors-1
> > 
> > 	Allow userspace to always be notified about async write failures
> > 	when calling msync and fsync even if they happened long before
> > 	the systemcall run.
> 
> The code in shrink_cache() has a couple of problems.
> 
> a) If someone else is truncating the file at the same time,
>    block_write_full_page() will see the page is outside i_size and will
>    return -EIO.  That will be propagated into the address_space and
>    userspace will see a bogus I/O error.
> 
>    Fix: just return zero from writepage-outside-i_size.  There are several
>    instances.

sorry but this is a bug in writepage if something not a bug in
9999_fsync-msync-async-errors-1, msync just checks the writepage retval
today, but it only checks it for the synchronous writepages that it
submits, not the async one from the vm.

> b) Can't touch `mapping' after calling writepage().  The page can now be

more precisely can't touch the mapping on a unlocked page (unless we
reference the mapping through the inode and not though the page),
agreed, it can race.

>    unlocked, truncated off the inode and the inode could be freed up.
> 
>    No, I don't have a testcase ;)
> 
>    The fix is to lock the page again, see if it still has a ->mapping,
>    then set mapping->error.

so the problem is in vmscan.c:

 			if ((gfp_mask & __GFP_FS) && writepage) {
+				int err;
+
 				ClearPageDirty(page);
 				SetPageLaunder(page);
 				page_cache_get(page);
 				spin_unlock(&pagemap_lru_lock);
 
-				writepage(page);
+				err = writepage(page);
+				if (unlikely(err))
+					mapping->error = err;
+
 				page_cache_release(page);

locking the page again is very ugly, and there's a worse problem with
your proposed fix that makes it not an option: we risk to get the lock
on the page and to set the error _after_ msync/fsync returned no errors
to usersapce. So this could invalidate the feature despite it would make
the kernel stable again.

The only fix I can see is to change all writepage to set error by
themself before unlocking the page, then the above vmscan diff can go
away. And well, the prepare write should do the same too, the patch
takes care of the data failures in the prepare-write case in the I/O
completion handler, but not of the metadata failure. And even for the
prepare write data failures, it is broken because the write_io_error
information is passed over only during bh collection, not at msync or
fsync time. I think I'll drop this patch completely since it's useless
in its current form and the above bug will crash the kernel.

Thank you very much for the helpful review!

Andrea

Re: 2.4.21pre5aa1

[Andrea Arcangeli]

On Fri, Mar 14, 2003 at 08:53:09AM -0500, Rik van Riel wrote:
> On Fri, 14 Mar 2003, Andrea Arcangeli wrote:
> 
> > Only in 2.4.21pre4aa3: 9900_aio-17.gz
> > Only in 2.4.21pre5aa1: 9900_aio-18.gz
> > 
> > 	Cleaned up the whole asm/kmap_types.h mess, moved
> > 	kmap_types.h into linux/, this must be visible
> > 	for aio and it has to be the same for all archs so it doesn't belong to
> > 	asm/.
> 
> Maybe I'm dense, maybe it's early on a friday morning, maybe
> even both ... but I don't understand why architectures without
> highmem should have kmap_types.h

it's the aio code that does some kmap_atomic in the common code, and the
kmap_atomic pretends to get a km_type parameter. Of course the km_type
parameter is optimized away at compile time if highmem is disabled, but
this allows to use kmap_atomic in common code.

Andrea

Re: 2.4.21pre5aa1

[Andrea Arcangeli]

On Fri, Mar 14, 2003 at 06:10:54PM +0100, Marc-Christian Petersen wrote:
> On Friday 14 March 2003 14:39, Marc-Christian Petersen wrote:
> 
> Hi Andrea,
> 
> > > Only in 2.4.21pre5aa1: 22_sched-deadlock-mmdrop-1
> > > 	Backport from 2.5 (in a more icache friendy way) an anti-deadlock
> > > 	fix for the o1 scheduler that can otherwise send a cross IPI with
> > > 	irq disabled.
> 
> > I get _tons_ of these messages:
> >
> > Initializing RT netlink socket
> > rq->prev_mm was c025b0e0 set to c025b0e0 - swapper
> > dffddf4c c0115786 c023b1a0 c025b0e0 c025b0e0 dffdc24e dffddfbc dffce02c
> >        dffdc000 00000000 dffdc000 dffddfbc c0105000 0008e000 c01072bd
> > 00000700 c0125d00 c02916a8 dffddfbc c0105000 0008e000 00000002 c01e0018
> > ....
> 
> I am going to rip out 22_sched-deadlock-mmdrop-1 because I dunno how to fix 
> this. The trace is annoying ;)

the fix for this was supposed to be included in the o1 scheduler patch,
there is been clearly a merging error, just drop the #ifdef CONFIG_SMP
around schedule_tail in arch/i386/kernel/entry.S and it'll work fine.

Andrea

Re: 2.4.21pre5aa1

[Marc-Christian Petersen]

On Friday 14 March 2003 18:38, Andrea Arcangeli wrote:

Hi Andrea,

> the fix for this was supposed to be included in the o1 scheduler patch,
> there is been clearly a merging error, just drop the #ifdef CONFIG_SMP
> around schedule_tail in arch/i386/kernel/entry.S and it'll work fine.
hmm, I wonder where I did the error. You are right. TYVM! Sorry for the noise.

ciao, Marc

Re: 2.4.21pre5aa1

[Andrea Arcangeli]

On Fri, Mar 14, 2003 at 07:04:57PM +0100, Marc-Christian Petersen wrote:
> hmm, I wonder where I did the error. You are right. TYVM! Sorry for the noise.

No problem, I rechecked everything and it looks correct, no merging
error.

Andrea