During the Simple Pairing process the HCI disconnect timer must be
disabled. The way to do this is by holding a reference count of the
HCI connection. The Simple Pairing process on both sides starts with
an IO Capabilities Request and ends with Simple Pairing Complete.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The class of device value can only be retrieved via inquiry or during
an incoming connection request. Outgoing connections can't ask for the
class of device. To compensate for this the value is stored and copied
via the inquiry cache, but currently only updated via inquiry. This
update should also happen during an incoming connection request.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Some minor cosmetic cleanups to the HCI event handling to make the
code easier to read and understand.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Bluetooth specification supports the default link policy settings
on a per host controller basis. For every new connection the link
manager would then use these settings. It is better to use this instead
of bothering the controller on every connection setup to overwrite the
default settings.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The connection packet type can be changed after the connection has been
established and thus needs to be properly tracked to ensure that the
host stack has always correct and valid information about it.

On incoming connections the Bluetooth core switches the supported packet
types to the configured list for this controller. However the usefulness
of this feature has been questioned a lot. The general consent is that
every Bluetooth host stack should enable as many packet types as the
hardware actually supports and leave the decision to the link manager
software running on the Bluetooth chip.

When running on Bluetooth 2.0 or later hardware, don't change the packet
type for incoming connections anymore. This hardware likely supports
Enhanced Data Rate and thus leave it completely up to the link manager
to pick the best packet type.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

When trying to establish an eSCO link between two devices then it can
happen that the remote device falls back to a SCO link. Currently this
case is not handled correctly and the message dispatching will break
since it is looking for eSCO packets. So in case the configured link
falls back to SCO overwrite the link type with the correct value.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The authentication status is not communicated to both parties. This is
actually a flaw in the Bluetooth specification. Only the requesting side
really knows if the authentication was successful or not. This piece of
information is however needed on the other side to know if it has to
trigger the authentication procedure or not. Worst case is that both
sides will request authentication at different times, but this should
be avoided since it costs extra time when setting up a new connection.

For Bluetooth encryption it is required to authenticate the link first
and the encryption status is communicated to both sides. So when a link
is switched to encryption it is possible to update the authentication
status since it implies an authenticated link.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Bluetooth specification allows to enable or disable the encryption
of an ACL link at any time by either the peer or the remote device. If
a L2CAP or RFCOMM connection requested an encrypted link, they will now
disconnect that link if the encryption gets disabled. Higher protocols
that don't care about encryption (like SDP) are not affected.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Recent tests with various Bluetooth headsets have shown that some of
them don't enforce authentication and encryption when connecting. All
of them leave it up to the host stack to enforce it. Non of them should
allow unencrypted connections, but that is how it is. So in case the
link mode settings require authentication and/or encryption it will now
also be enforced on outgoing RFCOMM connections. Previously this was
only done for incoming connections.

This support has a small drawback from a protocol level point of view
since the host stack can't really tell with 100% certainty if a remote
side is already authenticated or not. So if both sides are configured
to enforce authentication it will be requested twice. Most Bluetooth
chips are caching this information and thus no extra authentication
procedure has to be triggered over-the-air, but it can happen.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Getting the remote L2CAP features mask is really important, but doing
this as less intrusive as possible is tricky. To play nice with older
systems and Bluetooth qualification testing, the features mask is now
only retrieved in two specific cases and only once per lifetime of an
ACL link.

When trying to establish a L2CAP connection and the remote features mask
is unknown, the L2CAP information request is sent when the ACL link goes
into connected state. This applies only to outgoing connections and also
only for the connection oriented channels.

The second case is when a connection request has been received. In this
case a connection response with the result pending and the information
request will be send. After receiving an information response or if the
timeout gets triggered, the normal connection setup process with security
setup will be initiated.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Fix some issues in pagemap_read noted by Alexey:

- initialize pagemap_walk.mm to "mm" , so the code starts working as
  advertised

- initialize ->private to "&pm" so it wouldn't immediately oops in
  pagemap_pte_hole()

- unstatic struct pagemap_walk, so two threads won't fsckup each other
  (including those started by root, including flipping ->mm when you don't
  have permissions)

- pagemap_read() contains two calls to ptrace_may_attach(), second one
  looks unneeded.

- avoid possible kmalloc(0) and integer wraparound.

Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
[ Personally, I'd just remove the functionality entirely  - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

These two macros are useful beyond lock debugging. Moved definitions from
include/linux/debug_locks.h to include/linux/kernel.h, so code that needs
them does not have to include the former, which would have been a less
intuitive choice of a header.
Signed-off-by: NEduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Acked-by: NPekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  softlockup: print a module list on being stuck

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86 ACPI: fix resume from suspend to RAM on uniprocessor x86-64
  x86 ACPI: normalize segment descriptor register on resume

Don't use a static entry, so as to prevent races during concurrent use
of this function.
Reported-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
  ide: ide_unregister() locking bugfix
  ide: ide_unregister() warm-plug bugfix
  ide: fix hwif->gendev refcounting

Commit ea0c62f7 tried to clear all
bits in irq_stat but it didn't actually achieve that as irq_stat was
anded with port_map right after read.  This patch makes ahci driver
always use the unmasked value to clear irq_status.

While at it, add explanation on the peculiarities of ahci IRQ
clearing.

This was spotted by Linus Torvalds.
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Holding ide_lock for ide_release_dma_engine() call is unnecessary
and triggers WARN_ON(irqs_disabled()) in dma_free_coherent().
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Fix ide_unregister() to work for ports with no devices attached to them.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

class->dev_release is called by device_release() iff dev->release
is not present so ide_port_class_release() is never called and the
last hwif->gendev reference is not dropped.

Fix it by removing ide_port_class_release() and get_device() call
from ide_register_port() (device_create_drvdata() takes a hwif->gendev
reference anyway).

This patch fixes hang on wait_for_completion(&hwif->gendev_rel_comp)
in ide_unregister() reported by Pavel Machek.

Cc: Pavel Machek <pavel@suse.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Most places in the kernel that go BUG: print a module list
(which is very useful for doing statistics and finding patterns),
however the softlockup detector does not do this yet.

This patch adds the one line change to fix this gap.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Since the trampoline code is now used for ACPI resume from suspend to RAM,
the trampoline page tables have to be fixed up during boot not only on SMP
systems, but also on UP systems that use the trampoline.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=10923Reported-by: NDionisus Torimens <djtm@gmx.net>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: pm list <linux-pm@lists.linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Some Dell laptops enter resume with apparent garbage in the segment
descriptor registers (almost certainly the result of a botched
transition from protected to real mode.)  The only way to clean that
up is to enter protected mode ourselves and clean out the descriptor
registers.

This fixes resume on Dell XPS M1210 and Dell D620.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=10927Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: pm list <linux-pm@lists.linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Tested-by: NKirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Flags considered internal to the mempolicy kernel code are stored as part
of the "flags" member of struct mempolicy.

Before exposing a policy type to userspace via get_mempolicy(), these
internal flags must be masked.  Flags exposed to userspace, however,
should still be returned to the user.
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  xen: fix address truncation in pte mfn<->pfn conversion
  arch/x86/mm/init_64.c: early_memtest(): fix types
  x86: fix Intel Mac booting with EFI

Even the newer ENE controllers have bugs in their DMA engine that make
it too dangerous to use. Disable it until someone has figured out under
which conditions it corrupts data.

This has caused problems at least once, and can be found as bug report
10925 in the kernel bugzilla.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Document the kernel boot parameter: relax_domain_level=.
Signed-off-by: NPaul Jackson <pj@sgi.com>
Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
Reviewed-by: NLi Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

 # cat /devcg/devices.list
 a *:* rwm
 # echo a > devices.allow
 # cat /devcg/devices.list
 a *:* rwm
 a 0:0 rwm

This is odd and maybe confusing.  With this patch, writing 'a' to
devices.allow will add 'a *:* rwm' to the whitelist.

Also a few fixes and updates to the document.
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: Paul Menage <menage@google.com>
Cc: Balbir Singh <balbir@in.ibm.com>
Cc: James Morris <jmorris@namei.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Acked-By: NDebora Velarde <debora@linux.vnet.ibm.com>
Cc: <zohar@linux.vnet.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There is a bug in the output of /sys/devices/system/node/node[n]/meminfo
where the Active and Inactive values are in pages instead of Kbytes.

Looks like this occurred back in 2.6.20 when the code was changed
over to use node_page_state().

Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In linux-next there is a commit ("x86: Add performance variants of cpumask
operators") which, as part of the 4096 cpu support work adds some new APIs
for dealing with cpu masks.  Add trivial versions of these now so that
subsystems can update in a timely manner and avoid conflicts in linux-next
and the next merge window.

Cc: Mike Travis <travis@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The CaFe chip has a hardware bug that ends up with us getting a timeout
value that's too small, causing the following sorts of problems:

[   60.525138] mmcblk0: error -110 transferring data
[   60.531477] end_request: I/O error, dev mmcblk0, sector 1484353
[   60.533371] Buffer I/O error on device mmcblk0p2, logical block 181632
[   60.533371] lost page write due to I/O error on mmcblk0p2

Presumably this is an off-by-one error in the hardware.  Incrementing
the timeout count value that we stuff into the TIMEOUT_CONTROL register
gets us a value that works.  This bug was originally discovered by
Pierre Ossman, I believe.

[thanks to Robert Millan for proving that this was still a problem]
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Cc: Pierre Ossman <drzeus-list@drzeus.cx>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This has been sitting around unloved for way too long..

The Marvell CaFe chip's SD implementation chokes during card insertion
if one attempts to set the voltage and power up in the same
SDHCI_POWER_CONTROL register write.  This adds a quirk that does
that particular dance in two steps.

It also adds an entry to pci_ids.h for the CaFe chip's SD device.
Signed-off-by: NAndres Salomon <dilinger@debian.org>
Cc: Pierre Ossman <drzeus-list@drzeus.cx>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch changes the way we determine the maximum number of outstanding
commands for each controller.

Most Smart Array controllers can support up to 1024 commands, the notable
exceptions are the E200 and E200i.

The next generation of controllers which were just added support a mode of
operation called Zero Memory Raid (ZMR).  In this mode they only support
64 outstanding commands.  In Full Function Raid (FFR) mode they support
1024.

We have been setting the queue depth by arbitrarily assigning some value
for each controller.  We needed a better way to set the queue depth to
avoid lots of annoying "fifo full" messages.  So we made the driver a
little smarter.  We now read the config table and subtract 4 from the
returned value.  The -4 is to allow some room for ioctl calls which are
not tracked the same way as io commands are tracked.

Please consider this for inclusion.
Signed-off-by: NMike Miller <mike.miller@hp.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The old one bounces.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Andreas Dilger <adilger@sun.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Provide a little documentation for the two new fields, Cpus_allowed_list
and Mems_allowed_list, that were added to each /proc/<pid>/status file a
while back.
Signed-off-by: NPaul Jackson <pj@sgi.com>
Acked-by: NMichael Kerrisk <mtk.manpages@gmail.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The build of the Alpha Linux kernel currently fails[1] with inconsistent
kallsyms data.  As I never saw that before, I thought about hardware
problems.  But in fact it is a bug in the Linux kernel.

The end of the rodata section is marked with the "__end_rodata" symbol.
This symbol have different aligning constraints than the inittext parts
and therefor the start marked "_sinittext".  Because of that the
__end_rodata symbol shifts between < _sinittext and == _sinittext.  The
later variant is seen as a code symbol and recorded in the kallsyms data.

On fix would be to move the exception table a little bit and get some
space between that two areas.

[1]: http://buildd.debian.org/fetch.cgi?pkg=linux-2.6&arch=alpha&ver=2.6.25-5&stamp=1213919009&file=log&as=raw

Cc: maximilian attems <max@stro.at>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The filesystem capability support meaning for CAP_SETPCAP is less powerful
than the non-filesystem capability support.  As such, when filesystem
capabilities are configured, we should not permit CAP_SETPCAP to 'enhance'
the current process through strace manipulation of a child process.
Signed-off-by: NAndrew G. Morgan <morgan@kernel.org>
Acked-by: NSerge Hallyn <serue@us.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>