Re: 2.4.23pre6aa1

[Marcelo Tosatti]

On Sun, 5 Oct 2003, Andrea Arcangeli wrote:

> > > Only in 2.4.23pre6aa1: 00_get_request_wait-race-1
> > > 
> > > 	Add missing smb_mb().

Ok I see you add smp_mb() in get_request_wait_wakeup()... Can you please 
explain me in more detail why this is required? 

> > > Only in 2.4.23pre6aa1: 00_proc-readlink-1
> > > 
> > > 	Remeber to free tmp buffer (from spender)

Merged.

> > > 
> > > Only in 2.4.23pre6aa1: 00_sync-buffer-scale-1
> > > 
> > > 	Don't take the bkl (the same paths runs w/o the bkl elsewhere), from
> > > 	Chris Mason.

I prefer not applying this one.

> > > Only in 2.4.23pre6aa1: 01_softirq-nowait-1
> > > 
> > > 	We must really keep executing softirqs or it may take
> > > 	a too long time before ksoftirqd gets some cpu time.
> > > 	For an embedded device you may want to remove this,
> > > 	on a server we need this still.
> > > 
> > > Only in 2.4.23pre6aa1: 30_19-nfs-kill-unlock-1
> > > 
> > > 	Ignore errors on exiting lock cleanups. From Trond.

Talked with Trond and he has other fixes pending... Should have them by 
the weekend.

> > > Only in 2.4.23pre6aa1: 9999900_BH_Sync-remove-1
> > > 
> > > 	To really be able to help and not just waste some
> > > 	seek and cpu, wait_on_buffer should honour the
> > > 	BH_Sync, but this is late in 2.4, and so I prefer
> > > 	to get rid of it instead of giving it the full power
> > > 	it should have.
> > > 
> > > Only in 2.4.23pre6aa1: 9999_z-execve-race-1
> > > 
> > > 	Fix race in exit_mmap.
>
> I recall I sent one of these to you privately already (though not all of
> them). the ones to merge are these:
> 
> 	00_e-nodev-1
> 	00_get_request_wait-race-1
> 	00_proc-readlink-1
> 	00_sync-buffer-scale-1
> 	30_19-nfs-kill-unlock-1
> 	9999900_BH_Sync-remove-1
> 	9999_z-execve-race-1
> 
> I benchmarked BH_Sync as a worthless logic, it increases cpu usage and
> slowdown I/O a little due suprious unplugs, basically it makes no sense
> until we change wait_on_buffer not to call run_task_queue if the BH is
> BH_Sync, but personally I prefer to nuke it than to go mangle
> wait_on_buffer, it wouldn't be a huge optimization anyways (and it's a
> noop without more than one spindle running).

I want to look with more time into this one...

> as you know I tried to fix the execve race w/o removing the fast path,
> but the lazy tlb code didn't work correctly, I'm unsure exactly what
> went wrong with it. The above fix is obviously safe instead and it
> indeed works fine. I'll be busy today and early next week. If something
> doesn't apply cleanly let me know and I can fix it for you.

Thats merged as well.

Apart from this there's a huge pile of fixes all over in -aa. It would be
good if we had them merged in.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/