* in floppy drivers and ps2esdi - replaced with use of ->rq_disk;
floppy drivers already have information about "type" part of device number
- they had stored that information in floppy_open(), so all we need is a
"which drive" part.  And that is available from ->rq_disk.
	* DAC960: changed ->private_data initialization - instead of pointing
it to controller (which we already have as disk->queue.queuedata) we simply
store a disk number in there.  That had simplified ->revalidate_disk() and
allowed to kill the use of ->rq_dev in request handler.

	* killed the uses of ->rq_dev in printks - several drivers.

	* uses in ll_rw_blk.c and elevator.c eliminated - ->rq_disk has
everything we need.

	* eliminated, since we actually wanted the name, not device number
(BTW, that had also killed calculation of name that used to duplicate sd.c
one)

	_Now_ we can clean the scsi_get_request_dev() up.  Indeed, for
any SCSI request we either have ->rq_dev == NODEV and ->rq_disk == NULL
or ->rq_disk->private_data points to address of template in question.
IOW, scsi_get_request_dev() becomes simply
{
	struct gendisk *p = req->rq_disk;
	return p ? *(struct Scsi_Device_Template **)p->private_data : NULL;
}
and that allows to kill ->max_major, ->min_major and ->major in
Scsi_Device_Template, along with the last non-trivial use of ->rq_dev.

	Ditto for sg.c

	Ditto for sd.c

	Ditto for sr.c

	Ditto for st.c

	Next 5 chunks prepare cleanup of scsi_get_request_dev().  Namely,
scsi_disk/scsi_cd/... get a new field - pointer to Scsi_Device_Template.
It is initialized with address of that driver's template.  sr.c and sd.c
have disk->private_data pointing to that field (instead of pointing to
entire structure).  osst.c, st.c and sg.c get gendisk - allocated, but
not registered (obviously) with ->private_name set in the same way.  When
they set ->rq_dev, they also set ->rq_disk.
	This chunk does it for osst.c

	->open() of st and osst sets file->private_data to Scsi_Tape in
question, other methods use it (same as in sg.c)

	* new inlined helper: tape_name(tape)
	* most of TAPE_NR() uses replaced with that animal
("st%d ...", TAPE_NR(STp), ... -> "%s ...", tape_name(STp), ... )

	* new inlined helper: tape_name(tape)
	* most of TAPE_NR() uses replaced with that animal
("osst%d ...", TAPE_NR(STp), ... -> "%s ...", tape_name(STp), ... )

- isapnp: asm/io.h is needed for inb() etc.;
- sync up with 2.5.44 vmlinux.lds changes.

OK, that's my f*ckup in rd.c (not on initrd path, actually) + couple of
f*ckups from Pat (mine: forgot to bump ->bd_count in rd_open(), Pat's:
dropped reference to gendisk on del_gendisk(), resulting in use of
kfree'd object + tried to remove a symlink that didn't exit).

This fixes these.  It also changes order of blkdev_put()/del_gendisk()
in initrd_release() - better safe than sorry.

It got initrd working on my boxen...

into home.transmeta.com:/home/torvalds/v2.5/linux

The posix acls are implemented as extended attributes and are compatible
with ext2/ext3 posix acls.

into shaggy.austin.ibm.com:/shaggy/bk/jfs-2.5

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

Dear David,

please find attached two patches for the latest 2.5.44-ia64. They fix
some problems and simplify things a bit.

remove_nodeid-2.5.44.patch:
This comes from Kimi. In 2.5.44 we suddenly had two definitions for
numa_node_id(), one was IA64 specific (local_cpu_data->nodeid) while
the other one is now platform independent:
__cpu_to_node(smp_processor_id()). After some discussions we decided
to remove the nodeid from the local_cpu_data and keep the definition of
all other platforms. With using the cpu_to_node_map[] we are also
faster when doing multiple lookups, as all node ids come in a single
cache line (which is not bounced around, as it's content is only
read).


ia64_topology_fixup-2.5.44.patch:
I'm following here the latest fixup for i386 from Matthew Dobson. The
__node_to_cpu_mask() macro now accesses an array which is initialized
after the ACPI CPU discovery. It also simplifies
__node_to_first_cpu(). A compiler warning has been fixed, too.


Please apply these to your kernel tree.

The hyper-threading in /proc/cpuinfo patch introduced a compile warning
under UP.

Fixed thus.

This trivial patch causes the TLS to be cleared on execve (code is in
flush_thread).  This is necessary to avoid ESRCH errors when
set_thread_area is asked to choose a free TLS entry after several nested
execve's.

The LDT also has a similar problem, but it is less serious because the
LDT code doesn't scan for free entries.  I'll probably send a patch to
fix this too, unless there is something important relying on this
behavior.

into home.transmeta.com:/home/torvalds/v2.5/linux

As per comment:

  restoring APIC_LVTPC can trigger an apic error because the delivery
  mode and vector nr combination can be illegal. That's by design: on
  power on apic lvt contain a zero vector nr which are legal only for
  NMI delivery mode. So inhibit apic err before restoring lvtpc

We need to use u64 because the future 64-bit ports can theoretically
return the same value for two different dentries, as pointed out by
Ulrich Weigand.

The patch also changes return value of the syscall to give length of
data copied, needed for valgrind support (this bit is by Philippe Elie).

Note this is not a complete fix for mixed 32/64: userspace needs to
figure out the kernel pointer size when reading from the buffer. But
that's another fix...

NOTE! any oprofile users will need to upgrade after this goes in, and
the user-space equivalent is checked into CVS.  Sorry for the inconvenience

Companion to the previous patch: all the support needed for non-ia32
architectures.

Patch from Ravikiran G Thirumalai <kiran@in.ibm.com>

1. Break out disk stats from kernel_stat and move disk stat to blkdev.h

2. Group cpu stat in kernel_stat and make them "per_cpu" instead of
   the NR_CPUS array

3. Remove EXPORT_SYMBOL(kstat) from ksyms.c (as I noticed that no module is
   using kstat)

Uninlines some large functions in the ipc code.

Before:
   text    data     bss     dec     hex filename
  30226     224     192   30642    77b2 ipc/built-in.o

After:
   text    data     bss     dec     hex filename
  20274     224     192   20690    50d2 ipc/built-in.o

Patch from Mingming, Rusty, Hugh, Dipankar, me:

- It greatly reduces the lock contention by having one lock per id.
  The global spinlock is removed and a spinlock is added in
  kern_ipc_perm structure.

- Uses ReadCopyUpdate in grow_ary() for locking-free resizing.

- In the places where ipc_rmid() is called, delay calling ipc_free()
  to RCU callbacks.  This is to prevent ipc_lock() returning an invalid
  pointer after ipc_rmid().  In addition, use the workqueue to enable
  RCU freeing vmalloced entries.

Also some other changes:

- Remove redundant ipc_lockall/ipc_unlockall

- Now ipc_unlock() directly takes IPC ID pointer as argument, avoid
  extra looking up the array.

The changes are made based on the input from Huge Dickens, Manfred
Spraul and Dipankar Sarma.  In addition, Cliff White has run OSDL's
dbt1 test on a 2 way against the earlier version of this patch.
Results shows about 2-6% improvement on the average number of
transactions per second.  Here is the summary of his tests:

                        2.5.42-mm2      2.5.42-mm2-ipclock
			-----------------------------
Average over 5 runs     85.0 BT         89.8 BT
Std Deviation 5 runs     7.4  BT         1.0 BT

Average over 4 best     88.15 BT        90.2 BT
Std Deviation 4 best     2.8 BT          0.5 BT


Also, another test today from Bill Hartner:

I tested Mingming's RCU ipc lock patch using a *new* microbenchmark - semopbench.
semopbench was written to test the performance of Mingming's patch.
I also ran a 3 hour stress and it completed successfully.

Explanation of the microbenchmark is below the results.
Here is a link to the microbenchmark source.

http://www-124.ibm.com/developerworks/opensource/linuxperf/semopbench/semopbench.c

SUT : 8-way 700 Mhz PIII

I tested 2.5.44-mm2 and 2.5.44-mm2 + RCU ipc patch

>semopbench -g 64 -s 16 -n 16384 -r > sem.results.out
>readprofile -m /boot/System.map | sort -n +0 -r > sem.profile.out

The metric is seconds / per repetition.  Lower is better.

kernel              run 1     run 2
                    seconds   seconds
==================  =======   =======
2.5.44-mm2          515.1       515.4
2.5.44-mm2+rcu-ipc   46.7        46.7

With Mingming's patch, the test completes 10X faster.

From Hugh

Instate Ingo's shmem_populate on top of the previous patches, now using
shmem_getpage(,,,SGP_QUICK) for the nonblocking case (its find_lock_page
may block, but rarely for long).  Note install_page will need redefining
if PAGE_CACHE_SIZE departs from PAGE_SIZE; note pgoff to populate must
be in terms of PAGE_SIZE; note page_cache_release if install_page fails.

filemap_populate similarly needs page_cache_release when install_page
fails, but filemap.c not included in this patch since we started out
from 2.5.43 rather than 2.5.43-mm2: whereas patches 1-8 could go
directly to 2.5.43, this 9/9 belongs with Ingo's population work.

Ingo's remap_file_pages patch.  Supported on ia32, x86-64, sparc
and sparc64.  Others will need to update mman.h and the syscall
tables.

With large highmem machines and many small cached files it is possible
to encounter ZONE_NORMAL allocation failures.  This can be demonstrated
with a large number of one-byte files on a 7G machine.

All lowmem is filled with icache and all those inodes have a small
amount of highmem pagecache which makes them unfreeable.

The patch strips the pagecache from inodes as they come off the tail of
the inode_unused list.

I play tricks in there peeking at the head of the inode_unused list to
pick up the inode again after running iput().  The alternatives seemed
to involve more widespread changes.

Or running invalidate_inode_pages() under inode_lock which would be a
bad thing from a scheduling latency and lock contention point of view.

The kernel will presently reclaim swapcache pages as they come off the
tail of the inactive list even if they are referenced.  That's the
"use-once" pagecache path and shouldn't be applied to swapcache pages.

This affects very few pages in practice because all those pages tend to
be mapped into pagetables anyway.

If we're about to return to userspace after performing some swap
readahead, the pages in the deferred-addition LRU queues could stay
there for some time.  So drain them after performing readahead.

Use lru_cache_add_active() so ensure that pages which are, or will be
mapped into pagetables are started out on the active list.

This is the first in a series of patches which tune up the 2.5
performance under heavy swap loads.

Throughput on stupid swapstormy tests is increased by 1.5x to 3x.
Still about 20% behind 2.4 with multithreaded tests.  That is not
easily fixable - the virtual scan tends to apply a form of load
control: particular processes are heavily swapped out so the others can
get ahead.  With 2.5 all processes make very even progress and much
more swapping is needed.  It's on par with 2.4 for single-process
swapstorms.


In this patch:

The code which tries to start mapped pages out on the active list
doesn't work very well.  It uses an "is it mapped into pagetables"
test.  Which doesn't work for, say, swap readahead pages.  They are not
mapped into pagetables when they are spilled onto the LRU.

So create a new `lru_cache_add_active()' function for deferred addition
of pages to their active list.

Also move mark_page_accessed() from filemap.c to swap.c where all
similar functions live.  And teach it to not try to move pages which
are in the deferred-addition list onto the active list.  That won't
work, and it's bogusly clearing PageReferenced in that case.

The deferred-addition lists are a pest.  But lru_cache_add used to be
really expensive in sime workloads on some machines.  Must persist.

Davem said:

"Ho hum, it is tricky :-)))

 At bio_map_user() you need to see the user's most recent write to the
 page if you are going "user --> device".  So if "user --> device"
 bio_map_user() must flush_dcache_page().

 I find the write_to_vm condition confusion which is probably why I am
 sitting here spelling this out :-)

 At bio_unmap_user(), if we are going "device --> user" you have to
 flush_dcache_page().  And actually, this flush could just as
 legitimately occur at bio_map_user() time.

 Therefore, the easiest thing to do is always flush_dcache_page() at
 bio_map_user().

 All the other cases are going to be like this, so we might as well
 cut to the chase and flush_dcache_page() for all the pages inside of
 get_user_pages()."