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.

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>

From: Jonas Thornblad <jonas@thornblad.net>

There is a problem in the hpt366.c driver where the function
ide_config_drive_speed(drive, speed) is called without using the correct
speed variable.  The speed variable should use the value returned by
hpt3xx_ratefilter which decides the speed after checking against the bad
drives list.

I believe the following patch fixes the problem.

Slightly reworked by me - Bart.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

 - Reduce large stack usage in ide_config() by using kmalloc(), down
   from 0x4a4 bytes to 0x64 bytes (x86-32).
 - Little whitespace cleanup. 
 - Move function comment block to immediately above the function. 

Module loaded and unloaded, otherwise not tested (no hardware).
Signed-off-by: Randy Dunlap <rddunlap@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

- setup hwgroup->handler/timer in ->prehandler() (after checking
  drive status) and in do_rw_taskfile() only send a command
- make pre_task_mulout_intr() transfer first data block itself
  instead of calling ->handler() so we don't have to play tricks
  with hwgroup->handler/timer in task_mulout_intr()
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

- update rq counters directly in task_buffer_sectors()
- use task_buffer[_multi]_sectors() in taskfile PIO
  handlers (CONFIG_IDE_TASKFILE_IO=n and flagged ones) so:
  (a) rq->hard_cur_sectors is used for rq mapping
  (b) in case of error valid rq->sector is reported
  (c) we can s/rq->current_nr_sectors/rq->nr_sectors/ later
- uninline task_buffer_sectors()
- remove not needed !rq->bio code from ide_[un]map_buffer()
  (it is used only for fs requests which are always bio based)
- remove no longer needed task_rq_offset()
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

REQ_DRIVE_TASKFILE requests aren't retried so don't clear rq->errors
in CONFIG_IDE_TASKFILE_IO=n PIO handlers and in CONFIG_IDE_TASKFILE_IO=y
PIO handlers clear rq->errors only for fs requests, flagged_* PIO
handlers were already okay.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

- split __task_sectors() out of task_sectors()
- add bio and buffer versions of task[_multi]_sectors()
- use task_bio_sectors() instead of task_sectors() in pdc4030.c
- move task[_buffer]_sectors() to ide-taskfile.c
- uninline task[_multi]_sectors()
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Move common code from task_mulin_intr() and task_mulout_intr()
(CONFIG_IDE_TASKFILE_IO=y) to a task_multi_sectors() helper.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

They are off by default and conflict with the future changes.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We should wait for the last IRQ after all data is sent.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Check drive->mult_count in flagged_taskfile() and fail request early
if necessary so there is no need to do it later in the PIO handlers.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

If the drive times out the final status check we should fail the request
instead of setting another handler for the next IRQ.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

ide_end_drive_cmd() should only be called for "flagged" taskfiles
which have separate PIO handlers so use driver->end_request() instead.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Remove checks for hwgroup->handler == NULL from task_[in,mulin,out]_intr()
(CONFIG_IDE_TASKFILE_IO=n versions).  These functions can be called only from
ide_intr() or ide_timer_expiry() and both set hwgroup->handler to NULL first.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Low-level drivers' ->ioctl() gets a userland pointer from scsi_ioctl();
prototype annotated, so is scsi_debug instance.

Fixes for direct dereferencing of userland pointers in i2o_config.c

isdn_writebuf_stub() was always called for userland pointers.

Killed the argument telling whether it's kernel or userland pointer,
killed dead code, updated callers.

 - trivial annotation in several places in drivers/mtd
 - a bunch of debugging printks switched from %x to %llx (they get 64bit
   values)
 - in doc200[01].c fixed type of (unused) last argument in their
   doc_read_ecc().

DVD_LU_SEND_{AGID,TITLE_KEY} can be legitimately rejected; in that case
we should not spew into logs.

Updating my source to 2.6.7 I see that you applied some
nonsense garbage patch. Please undo.

[ Note by Linus: the fact that DOS_EXTENDED_PARTITION is 5, and we're
  iterating over slots 1-4 in the partition table, are two totally
  unrelated things. Using the symbolic constant does indeed not make
  any sense at all here, as Andries so eloquently points out. ]

The exception rewrite contains a small bug that prevents bring up of CPUs
on logically partitioned machines.

The kernel is trying to zero the backlink on the new stack while running
with relocation disabled, which potentially cause it to try to access an
address outside of the region allowed in real mode.  This seem to be a
leftover from previous code as we also zero the backlink later after
turning off the MMU. 

This patch removes the offending bit.

The whitespace in arch/ppc64/kernel/head.S is a bit all over the place. 
This patch fixes it up.  This patch changes nothing other than
whitespace. 
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Anton noticed in some traces that we were spending an awfully long time
doing a memset.  The ppc64 memset is basically unchanged from the ppc32
version, and it only does 4-byte stores and doesn't unroll the loop. 
Here's a memset that performs a bit better.

I have been using it for 3 weeks now, and Anton has tested it on a
variety of machines, without problems. 
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Somebody back in the mists of time decided that call_prom and rtas_call
should return longs even though both of those bits of firmware run in
32-bit mode and produce a 32-bit result.  To make life more interesting,
the 32-bit result gets zero-extended to 64 bits, which makes checking
for a -1 return value more complicated than it should be.

This patch changes call_prom and rtas_call to return an int, and makes
the corresponding changes to use ints for the variables used to hold
those return values. 

While I was doing this I finally got annoyed enough with the strings of
prom_print() and prom_print_hex() calls that we do to write a simple
prom_printf.  I deliberately didn't use snprintf because the execution
environment is weird at this point - we aren't running at the address we
are linked at just yet - and I didn't want to inflict that on any code
outside this file.  I also did a prom_debug() macro, which eliminated a
few ifdefs. 

There are also a bunch of other minor cleanups.  This patch makes very
few algorithmic changes but does get rid of a lot of casts.  :)

I have been running with this patch for a couple of weeks, and Anton has
tested it too.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

When I made get_user_pages support looking up a pte for the "gate" area, I
assumed it would be part of the kernel's fixed mappings.  On x86-64 running
a 32-bit task, the 32-bit vsyscall DSO page still has no vma but has its
pte allocated in the user mm in the normal fashion.  This patch makes it
use the generic page-table lookup calls rather than the shortcuts.
With this, ptrace on x86-64 can access a 32-bit process's vsyscall page.

The behavior on x86 is unchanged.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>