Vasiliy Kulikov [Wed, 3 Aug 2011 00:52:32 +0000 (10:52 +1000)]
On thread exit shm_exit_ns() is called, it uses shm_ids(ns).rw_mutex. It
is initialized in shm_init(), but it is not called yet at the moment of
kernel threads exit. Some kernel threads are created in
do_pre_smp_initcalls(), and shm_init() is called in do_initcalls().
Static initialization of shm_ids(init_ipc_ns).rw_mutex fixes the race.
It fixes a kernel oops:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
[<c0320090>] (__down_write_nested+0x88/0xe0) from [<c015da08>] (exit_shm+0x28/0x48)
[<c015da08>] (exit_shm+0x28/0x48) from [<c002e550>] (do_exit+0x59c/0x750)
[<c002e550>] (do_exit+0x59c/0x750) from [<c003eaac>] (____call_usermodehelper+0x13c/0x154)
[<c003eaac>] (____call_usermodehelper+0x13c/0x154) from [<c000f630>] (kernel_thread_exit+0x0/0x8)
Code: 1afffffae597c00ce58d0000e587d00c (e58cd000)
Reported-by: Manuel Lauss <manuel.lauss@googlemail.com> Reported-by: Richard Weinberger <richard@nod.at> Reported-by: Marc Zyngier <maz@misterjones.org> Tested-by: Manuel Lauss <manuel.lauss@googlemail.com> Tested-by: Richard Weinberger <richard@nod.at> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Will Drewry [Wed, 3 Aug 2011 00:52:30 +0000 (10:52 +1000)]
This patch makes two changes:
- check for trailing characters after parsing PARTNROFF=%d
- disable root_wait if a syntax error is seen
The former assures that bad input like
root=PARTUUID=<validuuid>/PARTNROFF=5abc
properly fails by attempting to parse an extra character after the
integer. If the integer is missing, sscanf will fail, but if it is
present, and there is a trailing non-nul character, then the extra
field will be parsed and the error case will be hit.
The latter assures that if rootwait has been specified, the error
message isn't flooded to the screen during rootwait's loop. Instead of
adding printk ratelimiting, root_wait was disabled. This stays true to
the rootwait goal of support asynchronous device arrival while still
providing users with helpful messages. With ratelimiting or disabling
logging on rootwait, a range of edge cases turn up where the user would
not be informed of an error properly.
Signed-off-by: Will Drewry <wad@chromium.org> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Will Drewry [Wed, 3 Aug 2011 00:52:30 +0000 (10:52 +1000)]
Expand root=PARTUUID=UUID syntax to support selecting a root partition by
integer offset from a known, unique partition. This approach provides
similar properties to specifying a device and partition number, but using
the UUID as the unique path prior to evaluating the offset.
For example,
root=PARTUUID=99DE9194-FC15-4223-9192-FC243948F88B/PARTNROFF=1
selects the partition with UUID 99DE.. then select the next
partition.
This change is motivated by a particular usecase in Chromium OS where the
bootloader can easily determine what partition it is on (by UUID) but
doesn't perform general partition table walking.
That said, support for this model provides a direct mechanism for the user
to modify the root partition to boot without specifically needing to
extract each UUID or update the bootloader explicitly when the root
partition UUID is changed (if it is recreated to be larger, for instance).
Pinning to a /boot-style partition UUID allows the arbitrary root
partition reconfiguration/modifications with slightly less ambiguity than
just [dev][partition] and less stringency than the specific root partition
UUID.
Signed-off-by: Will Drewry <wad@chromium.org> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Namhyung Kim <namhyung@gmail.com> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Anderson Lizardo [Wed, 27 Jul 2011 21:40:09 +0000 (18:40 -0300)]
Bluetooth: use recommended LE connection parameters
The new connection parameters now match the recommended values for
Proximity and Health Thermometer profiles. The previous values were
ramdomly chosen, and are either too low or too high for most cases.
New values:
Scan Interval: 60 ms
Scan Window: 30 ms
Minimum Connection Interval: 50 ms
Maximum Connection Interval: 70 ms
Supervision Timeout: 420 ms
See "Table 5.2: Recommended Scan Interval and Scan Window Values" and
"Table 5.3: Recommended Connection Interval Values" for both profiles
for details. Note that the "fast connection" parameters were chosen,
because we do not support yet dynamically changing these parameters from
initiator side.
Additionally, the Proximity profile recommends (section "4.4 Alert on
Link Loss"):
"It is recommended that the Link Supervision Timeout (LSTO) is set to 6x
the connection interval."
Minimum_CE_Length and Maximum_CE_Length were also changed from 0x0001 to
0x0000 because they are informational and optional, and old value was
not reflecting reality.
Signed-off-by: Anderson Lizardo <anderson.lizardo@openbossa.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Mat Martineau [Fri, 22 Jul 2011 21:53:59 +0000 (14:53 -0700)]
Bluetooth: Handle fragmented skbs in bt_sock_stream_recvmsg()
ERTM reassembly will be more efficient when skbs are linked together
rather than copying every incoming data byte. The existing stream recv
function assumes skbs are linear, so it needs to know how to handle
fragments before reassembly is changed.
Mat Martineau [Fri, 22 Jul 2011 21:53:58 +0000 (14:53 -0700)]
Bluetooth: Linearize skbs for use in BNEP, CMTP, HIDP, and RFCOMM
Fragmented skbs are only encountered when receiving ERTM or streaming
mode L2CAP data. BNEP, CMTP, HIDP, and RFCOMM generally use basic
mode, but they need to handle fragments without crashing.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Peter Hurley [Thu, 14 Jul 2011 12:48:32 +0000 (08:48 -0400)]
Bluetooth: Allow ACL packets over USB in HCI_RAW mode
Removed tests which prevent transmission of ACL packets
when the device is in HCI_RAW mode. These tests verified that
there are ACL or LE links currently tracked by the HCI
connection manager. However, a HCI_RAW mode device does not
use the connection manager. In these circumstances, the connection
counts will be zero, and thus, transmitted ACL packets dropped.
The acl_num test is actually a vestige of a previous bulk URB
scheme that is no longer used by this driver (bulk URBs were not
started until at least one ACL connection was created). This was
incompatible with some endpoint implementations and was dropped -
see commit 43c2e57f94.
The utility of these tests is marginal - currently, the hci tx
scheduler cannot send an ACL or LE packet for an untracked connection
(except if the device is in HCI_RAW mode).
Lastly, no other transport layer driver enforces these same tests.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Acked-by: Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
projects / karo-tx-linux.git / log