into ppc970.osdl.org:/home/torvalds/v2.6/linux

into hera.kernel.org:/home/davem/BK/sparc-2.6

The sysv-ipc code uses mm/shmem.o, which in turn uses VM stuff and is
only compiled on MMU systems.
Signed-off-by: Miles Bader <miles@gnu.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Miles Bader <miles@gnu.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

[Since many archs use the same implementation of find_next_bit, it might
be nice to have `generic_find_next_bit' or something.]
Signed-off-by: Miles Bader <miles@gnu.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Miles Bader <miles@gnu.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off-by: Miles Bader <miles@gnu.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

PDC20265 seems to not like large LBA48 requests.

Thanks to Adolfo Gonzalez Blazquez for help in debugging this problem.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

From: Jens Axboe <axboe@suse.de>

I need this patch to survive suspend on my powerbook, if the drive is
sleeping when suspend is entered.  Otherwise it freezes on resume when it
tries to read from the drive.

Acked by Ben.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

This fixes two things.

On the one hand we have the old "cruft" mount option, that sometimes was
enabled automatically, for ridiculously large files or CDROMs.  But what
was ridiculous ten years ago, no longer is.  So, only decide that
something is cruft when the user said so. 

On the other hand, sometimes we get negative sizes.  That is caused by
assignments inode->i_size = isonum_733(), where the latter was declared
integer.  I made it unsigned int, as the standard also does.

(Someone with problems replied:
  >> Could you test the below?
  > Ok I did, the patch seems to work great!  Thanks!
)

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@redhat.com>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@redhat.com>

into lips.borg.umn.edu:/export/music/bkroot/xfs-linux-2.6

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into kernel.bkbits.net:/home/davem/net-2.6

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Patch from Nicolas Pitre

This is only basic support so the LCD pannel becomes usable
on Mainstone. No PXA270 specific capabilities were added.
The Mainstone defconfig also updated to enable LCD by default.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

We can't do

	&some_inline_function();
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Now we always care about one part of nameidata --- ->depth.  And we need
to make sure it's always initialized.

generic_readlink() was missing that part.

into kroah.com:/home/greg/linux/BK/pci-2.6

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@redhat.com>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@redhat.com>

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@redhat.com>

A few things popped up when using current gcc cvs.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@redhat.com>

into nuts.davemloft.net:/disk1/BK/net-2.6

jffs2 switched; leaks plugged.

befs switched; leaks plugged.

shm switched (it almost belongs to SL3, but it does some extra stuff
after the link traversal).

xfs switched to new scheme; leaks plugged.

smbfs - switched from on-stack allocation of buffer for link body (!) to
__getname()/putname(); switched to new scheme.

cases that can simply reuse ext2 helpers (page_follow_link_light() and
page_put_link()).

trivial cases - ones where we have no need to clean up after pathname
traversal (link body embedded into inode, etc.).

Plugged leak in devfs_follow_link(), while we are at it.

        ext2 conversion (helper functions for that one will be actually
used a lot by other filesystems, so to fs/namei.c they go)

This patch-kit gets past the limit on nested symlinks, without
incompatible API changes _and_ with killing code duplication in most of
the readlink/follow_link pairs.  And no, it's not the old ->getlink()
crap - procfs et.al.  are not special-cased there. 

Here's how it works:
 * ->follow_link() still does what it used to do - replaces
   vfsmount/dentry in the nameidata it got from caller.  However, it can
   also leave a pathname to be resolved by caller. 
 * we add an array of char * into nameidata; we always work with
   nd->saved_names[current->link_count].  nd_set_link() sets it,
   nd_get_link() returns it.
 * callers of ->follow_link() (all two of them) check if ->follow_link()
   had left us something to do.  If it had (return value was zero and
   nd_get_link() is non-NULL), they do __vfs_follow_link() on that name.
   Then they call a new method (->put_link()) that frees whatever has to
   be freed, etc. 

Note that absolute majority of symlinks have "resolve a pathname" as
part of their ->follow_link(); they can do something else and some don't
do that at all, but having that pathname resolution is very, very
common. 

With that change we allow them to shift pathname resolution part to
caller.  They don't have to - it's perfectly OK to do all work in
->follow_link().  However, leaving the pathname resolution to caller
will
   a) exclude foo_follow_link() stack frame from the picture
   b) kill 2 stack frames - all callers are in fs/namei.c
and they can use inlined variant of vfs_follow_link().

That reduction of stack use is enough to push the limit on nested
symlinks from 5 to 8 (actually, even beyond that, but since 8 is common
for other Unices it will do fine). 

For those who have "pure" ->follow_link() (i.e.  "find a string that
would be symlink contents and say nd_set_link(nd, string)") we also get
a common helper implementing ->readlink() - it just calls
->follow_link() on a dummy nameidata, calls vfs_readlink() on result of
nd_get_link() and does ->put_link().  Using (or not using) it is up to
filesystem; it's a helper that can be used as a ->readlink() for many
filesystems, not a reimplementation of sys_readlink().  However, that's
_MANY_ filesystems - practically all of them. 

Note that we don't put any crap like "if this is a normal symlink, do
this; otherwise call ->follow_link() and let it do its magic" into
callers - all symlinks are handled the same way.  Which was the main
problem with getlink proposal back then. 

That covers almost everything; the only cases left are nfs, ncpfs and
cifs.  Those will go later - we are backwards compatible, so it's not a
problem. 

First patch: infrastructure - helpers allowing ->follow_link() to leave
a pathname to be traversed by caller + corresponding code in callers. 

Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>