#
# CAIF net configurations
#
menuconfig CAIF
tristate "CAIF support"
select CRC_CCITT
default n
---help---
The "Communication CPU to Application CPU Interface" (CAIF) is a packet
based connection-oriented MUX protocol developed by ST-Ericsson for use
with its modems. It is accessed from user space as sockets (PF_CAIF).
Say Y (or M) here if you build for a phone product (e.g. Android or
MeeGo ) that uses CAIF as transport, if unsure say N.
If you select to build it as module then CAIF_NETDEV also needs to be
built as modules. You will also need to say yes to any CAIF physical
devices that your platform requires.
See Documentation/networking/caif for a further explanation on how to
use and configure CAIF.
config CAIF_DEBUG
bool "Enable Debug"
depends on CAIF
default n
---help---
Enable the inclusion of debug code in the CAIF stack.
Be aware that doing this will impact performance.
If unsure say N.
config CAIF_NETDEV
tristate "CAIF GPRS Network device"
depends on CAIF
default CAIF
---help---
Say Y if you will be using a CAIF based GPRS network device.
This can be either built-in or a loadable module,
If you select to build it as a built-in then the main CAIF device must
also be a built-in.
If unsure say Y.
config CAIF_USB
tristate "CAIF USB support"
depends on CAIF
default n
---help---
Say Y if you are using CAIF over USB CDC NCM.
This can be either built-in or a loadable module,
If you select to build it as a built-in then the main CAIF device must
also be a built-in.
If unsure say N.
et-next.git/'>summaryrefslogtreecommitdiff
pid: fix lockdep deadlock warning due to ucount_lock
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
4.10.0-rc2-00024-g4aecec9-dirty #118 Tainted: G W
---------------------------------------------------------
swapper/1/0 just changed the state of lock:
(&(&sighand->siglock)->rlock){-.....}, at: [<ffffffffbd0a1bc6>] __lock_task_sighand+0xb6/0x2c0
but this lock took another, HARDIRQ-unsafe lock in the past:
(ucounts_lock){+.+...}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Chain exists of: &(&sighand->siglock)->rlock --> &(&tty->ctrl_lock)->rlock --> ucounts_lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(ucounts_lock);
local_irq_disable();
lock(&(&sighand->siglock)->rlock);
lock(&(&tty->ctrl_lock)->rlock);
<Interrupt>
lock(&(&sighand->siglock)->rlock);
*** DEADLOCK ***
This patch removes a dependency between rlock and ucount_lock.
Fixes: f333c700c610 ("pidns: Add a limit on the number of pid namespaces")
Cc: stable@vger.kernel.org
Signed-off-by: Andrei Vagin <avagin@openvz.org>
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>