This renames the x86 implementation of the spinlock_t's 'lock' field to
'slock', to protect against spinlock_t/rwlock_t type mismatches.

This way, if you use a spinlock where a rwlock is expected (or vice
versa), you'll get an obvious compile failure.

build- and boot-tested on x86 SMP+PREEMPT and SMP+!PREEMPT.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Trivial but untested (but also currently unused - wait
for BKL PREEMPT to start using them soon).

This introduces the following 3 new locking primitives:

  spin_can_lock(lock)
  read_can_lock(lock)
  write_can_lock(lock)

which are a nonintrusive test to check whether the real (intrusive)
trylock op would succeed or not.  Semantics and naming is completely
symmetric to the trylock counterpart.

Architectures that want to support PREEMPT will need to add these
definitions.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

cleanup: remove stale semicolon from linux/spinlock.h and stale space
from asm-i386/spinlock.h.

	Ingo
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

It's a bootup dependancy, you can't just increase it randomly, and
it breaks booting with LILO.

Pointed out by Janos Farkas and Adrian Bunk.

Cset exclude: ak@suse.de[torvalds]|ChangeSet|20050115232300|01174

rwlocks can't be "locked". They can be "locked for read", or
"locked for write", but not both. The confusion this caused is
evident in the long discussion about this on linux-kernel ;)

They had their time and place, but right now they are using
infrastructure that is getting re-done, and we're better off
just dropping them.

The locking tests were wrong, and the fixes are up in the air. In the
meantime, the get-it-working patch is to just not do this.

Cset exclude: mingo@elte.hu[torvalds]|ChangeSet|20050115174045|30241

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

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

My ALPS touchpad is not recognized because the device gets confused by
the Kensington ThinkingMouse probe.  It responds with "00 00 14"
instead of the expected "00 00 64" to the "E6 report".

Resetting the device before attempting the ALPS probe fixes the
problem.
Signed-off-by: Peter Osterlund <petero2@telia.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

We could screw up and warn for opcodes that weren't write-safe and the
user tried to use without having write permissions.

Not so bad in itself, but that also destroyed the cmd type information.

Noticed by Michal Schmidt

From: Christoph Hellwig
Signed-off-by: Dave Jones <davej@redhat.com>

into delerium.kernelslacker.org:/mnt/data/src/bk/agpgart

- any device teardown must happen between agp_remove_bridge and
  agp_put_bridge, before agp_remove_bridge users can still call into
  the code
- it's releasing a reference to the wrong device

Original patch from: Christoph Hellwig
Further munging from Roland Dreier and myself.
Signed-off-by: Dave Jones <davej@redhat.com>

From: Christoph Hellwig
Signed-off-by: Dave Jones <davej@redhat.com>

From: Alan Hourihane
Signed-off-by: Dave Jones <davej@redhat.com>

When drivers other than loopback were using the LLTX
feature a race window was present.  While sending
queued packets, the packet scheduler layer drops the
queue lock then calls directly into the drivers xmit
handler.  The driver then grabs it's private TX lock
and goes to work.

However, as soon as we've dropped the queue lock another
thread doing TX processing for that card can execute
a netif_stop_queue() due to the TX queue filling up.
This race window causes problems because a properly coded
driver should never end up in it's ->hard_start_xmit()
handler if the queue on the device has been stopped and
we even BUG() trap for this condition in all of the device
drivers.  That is how this race window was discovered
by Roland and the Infiniband folks.

Various suggestions were made to close this race.  One
of which involved holding onto the queue lock all the
way into the ->hard_start_xmit() routine.  Then having
the driver drop that lock only after taking it's private
TX lock.  This solution was deemed grotty because it is
not wise to put queueing discipline internals into the
device drivers.

The solution taken here, which is based upon ideas from
Stephen Hemminger, is twofold:

1) Leave LLTX around for purely software devices that
   need no locking at all for TX processing.  The existing
   example is loopback, although all tunnel devices could
   be converted in this way too.

2) Stop trying to use LLTX for the other devices.  Instead
   achieve the same goal using a different mechanism.

For #2, the thing we were trying to achieve with LLTX
was to eliminate excess locking.  We accomplish that
now by letting the device driver use dev->xmit_lock directly
instead of a seperate priv->tx_lock of some sort.

In order to allow that, we had to turn dev->xmit_lock into
a hardware IRQ disabling lock instead of a BH disabling one.
Signed-off-by: David S. Miller <davem@davemloft.net>

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

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

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

into coreworks.de:/home/kaber/src/net/net-2.6-sched

Both HFSC and CBQ leak unclassified skbs with CONFIG_NET_CLS_ACT.
Move freeing to enqueue where it belongs. Same change for in HTB/prio,
they just don't leak because they don't have unclassified packets.
Signed-off-by: Patrick McHardy <kaber@trash.net>

handle is computed wrong, this makes creating a filter not using
"from" fail.
Signed-off-by: Patrick McHardy <kaber@trash.net>

I believe that compilers are clever enough, but anyway...
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Patrick McHardy <kaber@trash.net>

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

The continue is supposed to continue the outer loop, not break
out of the do { } while (0) loop. cls_route.c is also changed
in a similar way for clarity, although it behaved correctly.
Signed-off-by: Patrick McHardy <kaber@trash.net>

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

From: Roland McGrath <roland@redhat.com>

The fxsave instruction does not save the x87 tag word (only the
empty bits), and we re-created the old-style x87 tags incorrectly.
The registers are saved in "stack order" in the save area, but the
tag word bits are in "hardware order", and we need to get the right
register state.

Both x86 and x86-64 needed this fix.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

Signed-off by: James Lamanna <jlamanna@gmail.com>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Marcel Sebek <sebek64@post.cz>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>