This is the pid-max patch, the one i sent for 2.5.31 was botched.  I
have removed the 'once' debugging stupidity - now PIDs start at 0 again.
Also, for an unknown reason the previous patch missed the hunk that had
the declaration of 'DEFAULT_PID_MAX' which made it not compile ...

This contains Daniel's suggested fix that allows a parent to
PTRACE_ATTACH to a child it forked.  That fixes the incorrect BUG_ON()
assert that Ogawa's patch was intended to fix, and we thus undo Ogawa's
patch.

I've tested various ptrace uses and they appear to work just fine.

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

We want do so on all architectures for consistency, and i386 will need
the preprocessing soon anyway.

My previous patch added procs i2c_fill_inode and i2c_dir_fill_inode that
Al Viro deemed unnecessary.  i2c developers are in contact with Al to
get the latest scoop.  Meantime lets reverse the change before he flies
off at me about procfs abuse.

Tthis one seems to have been around since 2.5.31 and nobody has fixed it
yet...

BTW, while merging aio from 2.5 to 2.4 and fixing and porting the libaio
(in particular thanks to one of Ben's testcases that was checkin for
this specific case) I found this bug in 2.5

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

	OK, before the next bunch of gendisk merges, here comes a couple
of 2.5 IDE cleanups.

	a) exclusion between rereading partition tables and open() is done
in fs/block_dev.c these days, so homegrown one in ide.c is redundant - that
code _never_ blocks now.  Removed, just as it had been done with counterparts
in other drivers.

	b) blk_ioctl() calls are done in blkdev_ioctl() now; driver doesn't
need to handle them.  Again, removed as it had been done in all other drivers.

if a new edge happened while we were still processing the previous
one.

Then, if a _third_ edge came in, it would actually cause a reentrant
irq handler invocation, because the original INPROGRESS bit was now
lost.

This was actually seen on IDE in PIO mode.

Unify the PCI device ID constants used by AGP with the normal Linux ones.

create_elf_tables in fs/binfmt_elf.c now sets up the list of aux table
entries in a buffer on the kernel stack before copying it to the user
stack.

Unfortunately, while the buffer is big enough for most architectures, it
isn't big enough on PPC, which uses 5 extra aux table entries (put on
with ARCH_DLINFO).  The following patch increases the buffer to be big
enough for PPC.  (Note that each aux table entry uses two elements of
the elf_info array.)

to the bottom of the aux table.

into au1.ibm.com:/fuego/paulus/kernel/for-linus-ppc

The BK merging was a little too smart for the conflicting changes.
Add back what we lost with the last changeset.

We need to sync the blockdevice mapping at umount although sync_blockdev
already does it as we need to make sure everything hits the disk before
we mark the superblock clean.

Found by Dave Kleikamp.

This removes list_t, which is a gratuitous typedef for a "struct
list_head".  Unless there is good reason, the kernel doesn't usually
typedef, as typedefs cannot be predeclared unlike structs.

Frankly, I'm amazed the kernel worked for long without this.

Every linker script thinks the section is called .data.percpu.
Without this patch, every CPU ends up sharing the same "per-cpu"
variable.

This might explain the wierd per-cpu problem reports from Andrew and
Dave, and also that nagging feeling that I'm an idiot...

 This makes daemonize() call reparent_to_init() itself, as long
suggested for 2.5, and fixes the callers so they don't call it again.
Also fixes callers which set current->tty to NULL themselves (also
no longer neccessary).

This sets child_reaper to the idle thread upon creation, so that
ksoftirqd's reparent_to_init call doesn't get the swapper as parent.

RELOC_HIDE got miscompiled on gcc3.1/x86-64 in the access to softirq.c's per
cpu variables.  This fixes the problem.

Clearly to hide the relocation the addition needs to be done after the
value obfuscation, not before.

I don't know if it triggers on other architectures (x86-64 is especially
stressf here because it has negative kernel addresses), but seems like the
right thing to do.

Teach usb/storage/sddr09.c how to return less than a full page of sense
data.

In sd.c we call MODE SENSE (6) in order to find out whether the
device is write protected. The info we need is in byte 2, the
header of the MODE SENSE answer, but in the request we have to
specify (i) what page(s) we want, and (ii) how many bytes we want.

Long ago we asked for 12 bytes from page 1 (Daniel Roche, 1.3.35).
Matthew Dharm made this 8 bytes from page 3F (all pages), patch-2.4.0-test8.
In patch-2.4.10 the 8 was increased to 255.

I found on the one hand devices that only react to page 0
(the vendor page), and return an error for page 3F.
And on the other hand devices that are unable to handle requests
for more bytes than they actually have.

So, it seems that the cautious way to ask for MODE SENSE data is
to first ask for the header only, see how much is available,
and then ask for everything.

The patch below first separates out the MODE SENSE call,
and then tries it three times: on all pages (3F), only the first
four bytes; on the vendor page (0), only the first four bytes;
on all pages (3F), 255 bytes.

This should be at least as robust as our current code.
I tried it on 8 SCSI devices (of which 2 fail under 2.5.33)
and found no problems.

A patch from Martin Bligh which cleans up the open-coded uses of
mem_map for ia32.  Basically it replaces

mem_map + pagenr

with

pfn_to_page(pagenr)

in lots of places.  Because mem_map[] doesn't work like that with
discontigmem.

It also fixes a bug in bad_range, that happens to work for contig mem
systems, but is incorrect.  Tested both with and without discontigmem
support.

 - All the support macros which assume a linear mem_map[] have been
   wrapped in !CONFIG_DISCONTIGMEM.  pfn_to_page, page_to_pfn,
   page_to_phys, pmd_page, kern_addr_valid.

 - Move some initialsation macros into setup.h so they can be used in
   the i386 discontig.c (INITRD_START, INITRD_SIZE).

 - Alternate version of the bootmem allocator

 - add i386 discontig support and numaq support.

 - Pull the middle out of one_highpage_init() so that the i386 NUMA
   patch can call it on a per-page basis.

 - Move a few lines out of mem_init() into the new
   set_max_mapnr_init(), which the i386 NUMA code requires.

This restructures setup_arch() for i386 to make it easier to include the
i386 numa changes (for CONFIG_DISCONTIGMEM) I've been working on.  It
also makes setup_arch() easier to read.  A version of this patch is the
in 2.4 aa tree.

This does not depend on the other patches I'm submitting today, but my
discontigmem patch does depend on this one.

I've tested this patch on the following configurations: UP, SMP, SMP
PAE, multiquad, multiquad PAE.

I've had ia32-discontigmem under test for a month, uneventfully.  Possibly
because I don't have a machine to test it on....

A major part of this work is a general move to convert the low-level
memory management to consistently use pageframe numbers.  It's a bit
schizo at present..

This patch was written by Martin Bligh.  A version of this patch is in
the 2.4 aa tree.

It changes the unsigned longs node_start_paddr and zone_start_paddr to
page frame numbers.  This is necessary because a PAE address is 36 bits
and cannot be represented in an unsigned long.

 - The per-node physical memory start address node_start_paddr becomes
   a pfn, node_start_pfn.

 - The per-zone physical memory start address zone_start_paddr becomes
   a pfn, zone_start_pfn.

 - free_area_init_node() takes a pfn rather than a physical address.

Patricia has tested this patch on the following configurations: UP,
SMP, SMP PAE, multiquad, multiquad PAE, multiquad DISCONTIGMEM,
multiquad DISCONTIGMEM PAE.

The rmap locking inlines are causing some header file
dependency/ordering problems - move them out of page-flags.h and into
their own header file.