into angband.namesys.com:/home/green/bk_work/reiser3-linux-2.5

  C99 struct initialisers

An acct flag was added to do_munmap, true everywhere but in mremap's
move_vma: instead of updating the arch and driver sources, revert that
that change and temporarily mask VM_ACCOUNT around that one do_munmap.

Also, noticed that do_mremap fails needlessly if both shrinking _and_
moving a mapping: update old_len to pass vm area boundaries test.

If we support mmap MAP_NORESERVE, we should support it on shared
anonymous objects: too bad that needs a few changes.  do_mmap_pgoff pass
VM_ACCOUNT (or not) down to shmem_file_setup, flag stored into shmem
info, for use by shmem_delete_inode later.  Also removed a harmless but
pointless call to shmem_truncate.

Update Doc and remove FIXME comment from fork.c now accounting right.

do_mmap_pgoff's (file == NULL) check was incorrect: it caused shared
MAP_ANONYMOUS objects to be counted twice (again in shmem_file_setup),
and again on fork(); whereas the equivalent shared /dev/zero objects
were correctly counted.  Conversely, a private readonly file mapping
was (correctly) not counted, but still not counted when mprotected to
writable: mprotect_fixup had pointless "charged = 0" changes, now it
does vm_enough_memory checking when private is first made writable
(but later we may want to refine behaviour on a noreserve mapping).

Also changed correct (flags & MAP_SHARED) test in do_mmap_pgoff to
equivalent (vm_flags & VM_SHARED) test: because do_mmap_pgoff is
dealing with vm_flags rather than the input flags by that stage.

Remove vm_unacct_vma function: it's only used in one place,
which can do it better by using vm_unacct_memory directly.

do_mmap_pgoff clears MAP_NORESERVE from vm_flags when VM accounts
strictly: but it's not in vm_flags, it's in flags (and tested there).

There is no point in do_mremap clearing MAP_NORESERVE from its flags:
it has already validated that only the MREMAP_ flags can be set,
and it has no use for MAP_NORESERVE in the code that follows anyway.

shmem_notify_change and shmem_file_write be careful about overflowingly
large loff_t before shifting it into unsigned long for vm_enough_memory.
Rename SHMEM_MAX_BLOCKS to SHMEM_MAX_INDEX (to avoid confusion with
512-byte blocks), define SHMEM_MAX_BYTES from it.

But 2.5 vmtruncate lacked the s_maxbytes error handling which
shmem_notify_change now expects: bring it in from the -dj tree.
shmem_file_write error handling needs a closer look later on.

Repeated overnight kernel builds in tmpfs showed insane Committed_AS
by morning.  The main bug was that shmem_file_write was passing
(newsize-oldsize)>>PAGE_SHIFT to vm_enough_memory, but it has to be
((newsize>>PAGE_SHIFT)-(oldsize>>PAGE_SHIFT)) - imagine 1k writes.

But actually, if we're going to do strict accounting, then we should
round up to next page not down - use VM_ACCT macro throughout (needs
unusual mix of PAGE_CACHE_SIZE with PAGE_SHIFT); and must count one
page for a long symlink.

Currently there is no way to find out the effective object size of a slab
cache.  XFS has lots of IRIX-derived code that want to do zalloc() style
allocations on zones (which are implemented as slab caches in XFS/Linux)
and thus needs to know about it.  There are three ways do implement it:

a) implement kmem_cache_zalloc
b) make the xfs zone a struct of kmem_cache_t and a size variable
c) implement kmem_cache_size

The current XFS tree does a) but I absolutely don't like it as encourages
people to use kmem_cache_zalloc for new code instead of thinking about how
to utilize slab object reuse.  b) would be easy, but I guess kmem_cache_size
is usefull enough to get into the kernel.  Here's the patch:

actual implementation and avoid confusion.

I just duplicated the method used in drivers/net/tulip/de2104x.c

This should do the trick.

I found a situation where page->index for a pagetable page can be set
to 0 instead of the correct value.  This means that ptep_to_address
will return the wrong answer.  The problem occurs when remap_pmd_range
calls pte_alloc_map and pte_alloc_map needs to allocate a new pte
page, because remap_pmd_range has masked off the top bits of the
address (to avoid overflow in the computation of `end'), and it passes
the masked address to pte_alloc_map.

Now we presumably don't need to get from the physical pages mapped by
remap_page_range back to the ptes mapping them.  But we could easily
map some normal pages using ptes in that pagetable page subsequently,
and when we call ptep_to_address on their ptes it will give the wrong
answer.

The patch below fixes the problem.

There is a more general question this brings up - some of the
procedures which iterate over ranges of ptes will do the wrong thing
if the end of the address range is too close to ~0UL, while others are
OK.  Is this a problem in practice?  On i386, ppc, and the 64-bit
architectures it isn't since user addresses can't go anywhere near
~0UL, but what about arm or m68k for instance?

And BTW, being able to go from a pte pointer to the mm and virtual
address that that pte maps is an extremely useful thing on ppc, since
it will enable me to do MMU hash-table management at set_pte (and
ptep_*) time and thus avoid the extra traversal of the pagetables that
I am currently doing in flush_tlb_*.  So if you do decide to back out
rmap, please leave in the hooks for setting page->mapping and
page->index on pagetable pages.

include/linux/timer.h needs to include <linux/stddef.h>
to get the definition of NULL.

	linux-2.5.28/drivers/block_dev.c has a new do_open that broke
initial ramdisk support, because it now requires devices that "manually"
set bdev->bd_openers to set bdev->bd_inode->i_size as well.  The
following single line patch, suggested by Russell King, fixes the
problem.

	There does not appear to be anyone acting as maintainer for
rd.c, so I posted to lkml yesterday to ask if anyone objected to my
submitting the patch to you, and I also emailed the message to Russell
King and Al Viro.  Nobody has complained.  I have been running the
patch for almost a day without problems.

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

Al Viro pointed out there was a fair bit of redundancy here.  We
remove many include files from the serial layer, leaving those
which are necessary for it to build.  This has been posted to lkml,
no one complained.

This cset also combines a missing include of asm/io.h in 8250_pci.c
(unfortunately I've lost the name of the reporter, sorry.)

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

jfs_rmdir and jfs_unlink have always called d_delete, but it hasn't
caused a problem until 2.5.28.  The call is an artifact of the 2.2
kernel, which had gone unnoticed in 2.4 and 2.5.

These were totally unused for a long time.  It's interesting how
many files include swapctl.h, though..

I did this ages ago but never submitted it because I never got round to
testing it. I still haven't tested it, but it ought to work, and the code
is definitely broken without it...

Noticed by Zwane Mwaikambo.

8250_pci.c contains some old compatibility cruft for when __devexit
wasn't defined by the generic kernel.  It is now, so it's gone.

I removed the PF_INVALIDATE debug check from buffercache
leaks, too.  It's non-functional - the flag should have been
set across truncate_inode_pages(), not invalidate_inode_pages().

used.

This fixes a lockup in synchronize_irq() on x86.

the attached patch is a comment update of sched.c and it also does a small
cleanup in migration_thread().

Modified the MODE_SENSE write-protect test in sd.c to issue a SCSI
request with the request_bufflen the same size as the MODE_SENSE
command being issued requests.